4 ms·

I don't understand why people seem to think that testers could or should be replaced by automated tests. I've worked a lot with test automation, and I find it s

by marxama 10y ago

I don't understand why people seem to think that testers could or should be replaced by automated tests. I've worked a lot with test automation, and I find it super important to have automated tests for any long-living project, but one of their main purposes are to off-load the manual testers from doing repetitive regression testing, and focus on more creative exploratory testing - things that humans (well, some) are good at, but computers are not. In addition, testers should play a central role when it comes to validating requirements - they typically catch issues and inconsistencies that would otherwise go unnoticed until $x has already been spent on going down the wrong path.

brianwawok 10y ago
I have had people I trust a lot more than myself argue this. That humans are better exploratory testers than robots. Totally agree that humans doing manual regressions is bad. I would almost argue that needing humans to do regressions means that something is broke in your coding / testing / deployment process. If page X must REALLY do Y and always work, why aren't you testing it on 30 browsers automatically? Even a very good human would have a hard time matching what you can code automagically. I trust that there is something there though in humans for exploratory testing. And indeed I have worked with good QA people over the years that found awesome stuff. But I have also worked with many man QA that have added massive negative value to projects. Perhaps I let reality taint my taste of QA?
- marxama 10y ago
  One thing is that a lot of testers are still working in a very rigid way. First, design and write down the test cases (based on a specification that is most likely flawed and incomplete). Then, perform the tests. Then, document the results. There is very little room for creativity and exploration in such a process. This is basically what you do when you write automated tests, except the execution (and reporting) steps will be done automatically and repeatedly. Which is super valuable, but when a skilled tester goes at it, there will be ideas and crazy connections flying around everywhere. Even if many of these tests were to be automated (which in many cases really isn't feasible, considering implementation time/execution time/maintainability costs), you'd need someone to even think up the tests, and typically developers don't have the time or breadth of knowledge of their system to do it. I used to work in a team with 5 developers and me as the tester. Besides finding tons of bugs - many of them very subtle - I became the one person who understood the product best since I was the only one touching all parts of it, so I was the one people came to for questions. Now, working as a developer, I do write automated tests, but I refuse to release anything our tester haven't had the time to test yet.
  - brianwawok 10y ago
    Ya the embedded tester thing. I have never really done that, but I can totally see a lot of value. I HAVE had places where the team lead didn't code and basically acted as the embedded QA. That isn't terrible.

by marxama 10y ago

brianwawok 10y ago

I have had people I trust a lot more than myself argue this. That humans are better exploratory testers than robots. Totally agree that humans doing manual regressions is bad. I would almost argue that needing humans to do regressions means that something is broke in your coding / testing / deployment process. If page X must REALLY do Y and always work, why aren't you testing it on 30 browsers automatically? Even a very good human would have a hard time matching what you can code automagically. I trust that there is something there though in humans for exploratory testing. And indeed I have worked with good QA people over the years that found awesome stuff. But I have also worked with many man QA that have added massive negative value to projects. Perhaps I let reality taint my taste of QA?

marxama 10y ago
One thing is that a lot of testers are still working in a very rigid way. First, design and write down the test cases (based on a specification that is most likely flawed and incomplete). Then, perform the tests. Then, document the results. There is very little room for creativity and exploration in such a process. This is basically what you do when you write automated tests, except the execution (and reporting) steps will be done automatically and repeatedly. Which is super valuable, but when a skilled tester goes at it, there will be ideas and crazy connections flying around everywhere. Even if many of these tests were to be automated (which in many cases really isn't feasible, considering implementation time/execution time/maintainability costs), you'd need someone to even think up the tests, and typically developers don't have the time or breadth of knowledge of their system to do it. I used to work in a team with 5 developers and me as the tester. Besides finding tons of bugs - many of them very subtle - I became the one person who understood the product best since I was the only one touching all parts of it, so I was the one people came to for questions. Now, working as a developer, I do write automated tests, but I refuse to release anything our tester haven't had the time to test yet.
- brianwawok 10y ago
  Ya the embedded tester thing. I have never really done that, but I can totally see a lot of value. I HAVE had places where the team lead didn't code and basically acted as the embedded QA. That isn't terrible.