4 ms·
I have a dog in this "fight", since my background is test automation and I started the Selenium project and two test infrastructure companies (Sauce Labs & Taps
by hugs 10y ago
I have a dog in this "fight", since my background is test automation and I started the Selenium project and two test infrastructure companies (Sauce Labs & Tapster Robotics). But I get so tired by these arguments. Testing is about mitigating risk and increasing development speed. If you want to go fast and there's low risk of failure, a little manual testing (with little or no automation) is fine. If you want to go fast, and there's a high risk of failure (lost revenue, reputation, etc.), go heavy on automation. If you have lots of time and risk of failure is low, do whatever you want.
- zachsnow 10y agoWhy place them on opposite ends of a spectrum (low failure vs high failure costs)? (Curious not saying it's incorrect). At my company we do both and get very different value from them. Automated testing is great (reproducible, handles regressions automatically, can run all the time) but it's not intelligent. It can't think of things that you forgot to test, or identify dependencies between components you thought were unrelated. You can argue that you should have written better tests, but how do you learn that? In our case... Manual testing! On the other hand, your manual QA person can't test all things at all times, and they definitely won't test the same thing over and over and over forever without finding a new gig! So ideally you take their input to learn not just how to test a particular component better (and fix specific bugs) but how to generally write better tests, so that next time their usual "tricks" won't work.