When I talk to customers about using test tools, often enough, there are widely varying expectations on what the tool needs to do. Predictably, the generalist testers want a simple, easy to use tool that lets them write and run test cases manually, the automation engineers want all that plus a tool that lets them write and run code. The test leads want the tool to generate reports while the test managers want the tool to have analytics along with reports to help them decide when to ship.
Ok, that’s reasonable – is this all? No wait – is it just these guys that are doing the testing? Nope – we also have the business analyst (BA) that does acceptance testing where she acts as an end user. And sometimes, there is a separate group of testers that do only acceptance testing while the developers do the rest of the functional testing along with writing unit tests. Other times, you have a single team of engineers that dev and test the code themselves – no separate group of testers.
Wow! That’s a lot of people trying to test, and I am not even counting the the specialist testers that want to do perf, security, stress testing etc.
Now, if I were to write a tool for writing and running manual tests only, what would be your choice? A simple browser based tool that anyone can access without a client, or a lightweight rich client that also lets you do some funky stuff like record tests in the background or collect debug logs automatically or one heavy monolith that lets you do the superset of all ops possible on both manual and automated tests?
So, tell me, in your company, who does the testing? 🙂