Who are Generalist Testers?

I have been recently focusing on a project to improve the lives of generalist testers for our next release ‘Rosario.’ In order to improve their lives, I’ve been trying to understand them better, their methods for testing software and what like to eat for lunch. Here’s what I’ve learned so far:

Background: Testers have a different background than developers. While many developers tend to love coding and usually have a technical degree, most manual testers do not have a technical background and do not code or have any desire to do so in the future.

Testing Philosophy: Most testers tend to approach testing differently from developers. While developers like to test their code by unit testing it in small fragments, testers tend to prefer to test end to end scenarios. While developers are comfortable writing code to perform their automation, testers seem to shy away from automation tools, preferring to manually step through written test cases. While testers tend to search for bugs by striving to take the unhappy path through the software, while developers often take the “yellow brick road” when ensuring that their code meets the requirements.

Focus on Quality: Testers seem to be motivated by a desire of creating a quality product. They love to break things, are delighted to find bugs in the product that they are testing, and to hound developers to see to it that they fixed. I find that this differs from most developers who hunger to implement new functionality and who view bug fixing as a chore.

Good Representatives of the Customer: On many software development teams, testers understand the ins and outs of the product in development better than anyone else in the company. They are therefore a very good source of information on the product and of future customer requests.

Treated as Second Class Citizens: We’ve also observed that testers are often treated as second class citizens of the software development process. In some organizations, they are given the worst workspaces in the building (one tester was placed right next to the company foosball table), while in others they are merely not trusted to test the right components in each sprint.

Similarly, they are often not given the best of tools to manage the testing effort. While it seems that every week a new tool is created to allow developers to create a flashier UI and collaborate more easily, manual testers are forced to work with a much more limitted toolset. Many testers author test cases in excel, step through test cases while constantly juggling which window is displayed and struggle to create bugs that provide developers with a clear picture of what needs to be fixed. We are therefore hoping to make a tool that will significantly improve the life of testers and help them to feel like first class citizens. More details on our plans shortly...