- If it is used by a machine, then it can be tested by a machine.
- If it is used by a human, then it must be tested by a human.
- If it is used by a machine, then it can be tested by a machine.
- If it is used by a human, then it must be tested by a human.
Doesn't replace human testing but it does ease the human load and help catch problems and regressions before they get to the human testers.
Can they test for color blindness and myopia?
It’s like you stopped reading to try to score internet points or something. The answer to your question was one more sentence from where you stopped reading
You could also check things like colors etc using Playwright but I would say it's probably the wrong tool for that job. It's more about testing functionality - make sure a page has the right content and works correctly on a technical level.
Without automated tools this type of thing can take a lot of time - in order to ensure quality you would basically have to click through the entire application for every release. Otherwise you might end up with some minor changes to one page breaking a different page and you'd never know until a tester checked it out or a user complained. With Playwright and similar tools you can catch regressions like this automatically.
Developer written tests can’t tell you if your UI is intuitive for novice users.
To use one tiny concrete example. Someone who isn’t aware of U+0022 + U+201C quotation marks will happily use U+0022 everywhere without ever considering the very slightly more aesthetically pleasing option. Independent validation is about redundancy, ideally you don’t want anything to reach that stage but people are really bad at testing for issues the’ve never considered. Usability in terms of colorblindness not just actual blindness yadda yadda good testing is really involved.
But the same also holds for people who are "independent testers" and unaware of the same issues.
What I found is that software developers are bad at testing edge cases while they are in the creation mode (when they focus on happy path), but that good engineers switch to breaking mode once they try to cover things with sufficient tests. TDD also encourages breaking things first, but really, this is a mindset change that is usually skipped.
For what it’s worth, if fuzzing is unlikely to, then I think so is manual testing unless you get really lucky or an expert is trying to break your system because they know of frequent issues with Unicode handling.
When testing automated: you prevent the commit in main sequence nice the regression test is added to the test coverage.
This is the point - adding tests to your automation suite gets cheaper over time and guarantees higher quality than manual QA runs with not much more cost to the business. Not doing so is choosing to take on tech debt. But pretending like random text is something your QA will catch on their own is a pipe dream. You’re better off investing in property tests and fuzzing.
No machine testing can completely (or even mostly) validate a human interface.