11–20 of 81 posts
Imho, the problem with Lighthouse (and Pagespeed before it) isn't that they're not perfect, it's that they assign scores/grades. When Google assigns a score to something, people understand it to mean highest score = best and start optimizing for the grade Google gives them, not for performance and user experience, which the grade is supposed to represent. It would be more fruitful to list the issues and their severit…
All of tools like lighthouse, axe-core etc. run a subset of tests that gives a false sense of security about accessibility. Similarly, tools like Accessibility Insights for Web has a fast-pass option, which does the same thing where it runs a subset of tests to catch the most common issues on a website.
But it does not and cannot(at this moment) catch all the issues that require semantic analysis of a website, like checking that the alt text on an image has meaningful text. For tests like those, a human is needed to perform a comprehensive assessment, something like Accessibility insights for web offers as an Assessment option.
In my opinion, all of the tools are doing one thing good and that is raise awareness about the problems that users with a disability face daily, when trying to use a website. They are making accessibility a must. Tools still needs more work and I feel confident that it will continue to improve. It all kind of comes down to how much time a development team puts in to make their website completely accessible, which ideally every team should budget and plan for.
I really enjoyed this part
Basically, I think automated testing is a very good thing, and we should definitely try to do as much of it as possible.
So we can clear the way for more useful and meaningful human testing.
I've always thought that the engineers in QC should be just as skilled and qualified as the ones building the product.
Part of what they should do, is design and build really cool automated tests, but I think that they should also be figuring out how to "monkey-test" the products, and get true users (this is 1000% required for usability and accessibility testing) banging on the product.
"True users" != anyone even remotely connected with the product development or testing, beyond a contract agreement.
But I'm kind of a curmudgeonly guy, and my opinions are not always welcomed.
I do write about why I prefer using test harnesses, as opposed to [automated] unit tests, here: https://medium.com/chrismarshallny/testing-harness-vs-unit-4...
Imho, the problem with Lighthouse (and Pagespeed before it) isn't that they're not perfect, it's that they assign scores/grades. When Google assigns a score to something, people understand it to mean highest score = best and start optimizing for the grade Google gives them, not for performance and user experience, which the grade is supposed to represent. It would be more fruitful to list the issues and their severit…
As an industry, I'm wary of having a single company define these scores. It seems like a conflict of interest. I'd rather have this in control by a standards group.
One of the "philosophers' stone" goals of the software industry is to completely replace human testing with automated testing. Basically, I think automated testing is a very good thing, and we should definitely try to do as much of it as possible. So we can clear the way for more useful and meaningful human testing. I've always thought that the engineers in QC should be just as skilled and qualified as the ones build…
I agree, but then they need to be equally well payed... and I don't think it is possible to find a manager willing to pay them as much
One of the "philosophers' stone" goals of the software industry is to completely replace human testing with automated testing. Basically, I think automated testing is a very good thing, and we should definitely try to do as much of it as possible. So we can clear the way for more useful and meaningful human testing. I've always thought that the engineers in QC should be just as skilled and qualified as the ones build…
>I've always thought that the engineers in QC should be just as skilled and qualified as the ones building the product. I agree, but then they need to be equally well payed... and I don't think it is possible to find a manager willing to pay them as much
It was just some weird metric we were chasing that involved making sure we go through each function and superficially test calls, regardless of the fact that some of the stuff we were testing gave us no confidence on the actual internals. I will not even mention that code coverage became this number that he/she believed was this standard, even though no attempts were made to build the codebase via TDD from the get to (making chasing the code coverage metric after the fact laughable). What could I say? The person appealed to the authority of the code coverage metric.
But hey, we got that code coverage percentage up :)