I have been thinking about the evolution of testing in “agile” projects. As the nerds get better at building software more reliably (via automated unit and integration tests) the need for manual testing is thankfully diminishing. This seems to be leading to testers morphing into either:
- QA developers – who are basically developers who spend most of their time working on automated tests and associated frameworks; or
- Tech savvy, proxy customers – who start to act as a type of detail-oriented business analyst.
The types of things I see testers doing more and more are — acting as stand-in customers by gaining a deep understanding of business rules and needs, reviewing acceptance test plans, challenging developers to keep up to date with automated regression/integration tests (which the tester will regularly use) and negotiating compromises.
This new breed of tester provides a link between the detail heavy, day-to-day reality of development and the customer needs. Importantly they act as a customer proxy in the private meetings that a company has where customers aren’t welcome. The very type of meeting where customer needs are often sold short for the convenience of the team. They basically help to keep the team honest.
Agree, but I think the tester needs to take on an extra role. They need to ensure the processes used on projects are up to scratch. They need to own the processes. and ensure that the project team all buy into the processes. This can sometimes be an uphill battle, but if the process is a good one, the team will see the benefits soon enough (particulary when it saves their arses from an embarassing loss of code, or an release going out with all customer raised incidents resolved)..quality processes deliver quality products. We need to be careful that the tester does not start doing the job the BA isn’t doing. I have much to say on this…but it is late…and I have had a testing day. God I love that joke!