Hey – who’s the tester anyway?

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? 🙂

Comments (4)

  1. Trevellyon Newell says:

    I think that this is a very interesting point! Within our company we are all testers in one way or another. We have developers doing the unit and component tests and the test department doing functional system and maintenance. These are the main test focus points but then we have support that have to play with a product enough to understand how a customer can break it and therefore how they can explain to the customer how to fix it, they also find bugs (edge cases but still valid bugs).

    Basically what I am saying is that all departments within the company should be testing the product in some way, no single bug found, should not be reported. Now to get all this to work through a single tool I don’t think it can be done as every company is different, methodologies, process and practices aside if there was one tool that did everything it probably couldn’t be tested.

    However I think all companies have to use a tool that best suits their needs, at that point in the project time frame, if you can get a tool that satisfies more than one area within the company, that in my opinion is an added bonus.

    [Anu] Great point, Trevellyon! Essentially, bug filing would be done by a whole lot of people, but management of test cases is probably restricted to a smaller group is what you are saying. Fair assessment.

  2. Ryan says:

    I agree with the previous comment. Dev will do some basic testing and unit testing, QA will do a more indepth tests and automated ui tests, they work closly with dev. our support team will do some basic acceptance testing and testing/logging of any issues a client has.

    [Anu] Thanks Ryan – does your support team and QA team use the same testing tools to do their testing?

  3. Maan says:

    It is QA team reponsilibity to do the all tests. I do agree that we do not accept the build without a unit test from Dev team. Sometimes we find plenty of bugs after unit test also. So it is ultimtely our QA team who took the sole responsibility of the feature to be delivered.

  4. ravipareek says:

    I agree with Trevellyon. However, there is an important aspect in a tool – shouldnt the bugs (raised by whoever – the client/QA team) also act as future test cases for the developers, so that they shall be regressed by the dev in each release. Hence, a tool should be capable of converting the defects to test cases