What kind of tester do we need?
Marc van Lint 060000D5M2 Visits (3935)
While discussing the benefits of using Rational testing tools in their software delivery the customer popped the question: “Maybe a bit off-line, but what kind of tester do we need?”
I want to share the answer I gave to him.
Formerly “the test expert” was a employee who could talk to the customer, analyze the inputs, define approaches, document the test. This last one was probably done in a tool like Excel. Maybe he was also responsible for executing and reporting on it.
Things have changed. Agile is mainstream, new technology emerge and infrastructures become more and more complex. It’s virtual impossible that one person has all the needed technical knowledge. Only maintaining the knowledge to an acceptable level might be a challenge, let go to practice it. If such a person must talk to the customer about their business processes, he might be tempted to dive deep into technology issues – losing the customer. There is no Michelangelo of Testing today, you need to collaborate!
I see various roles emerging in the development process:
I’m not concerned about the correct naming or exact role definition. When you collaborate, you must have things in common. That can be processes, artifacts, knowledge or other things. Furthermore it will be implemented differently in your organization.
Most important is that I see two area’s. One covered by, as I call it, the quality-consultant. He talks to the customer about their processes. Understand their concerns, define priorities, define what to test based on the information available.
The other one is covered by the test-developer. He can focus his work on implementing the defined test in the available test-tools and infrastructure. He can communicate with developers on a equal base about the implementation, maximizing reuse, using common standards, minimizing maintenance and other topics.
The test-developer does understand how to create the test in an automated way. Knows the technology to automate it, get the right level of test virtualization and implement it in a build/deployment process. Automated!
Again they have to collaborate! When the quality-consultant would go for a less thorough test in the old days because of the right balance between quality and manual testing effort, now, with the automation he might choose differently.
You might think that you need two test-specialists instead of just one. That might be right. Keep a close eye on the shift and advantages. Most tests, if not all are automated. When a new build is run, developers get directly feedback on the quality. Not only on their unit test, but also the integrations and even the whole system. That can be run every build or even up on request. You catch defects and regressions where they occur the day that they occur. That are big savings in time and money.
Is it easy to implement? It’s a journey. It’s not a single install. As an organization you have to grow to that goal. Probably you can build it from various applications and carry the hassle of the integrations and limiting the speed of Agile and adoption. An other concept is to capitalize on the IBM Rational toolset. That will give your team a paved road for improvement across the whole software delivery.