For the past year or so, I’ve been posting questions on my blog and to the development community about the role of testers on agile projects. This summer, I decided that the ship has sailed on the question: “should there be testers on agile projects?” No matter how much pundits on either side of the equation: “no tester role” vs. “tester role” debate it, the market will ultimately decide. What is more interesting to me, is the fact that there are conventional testers on agile projects, and they face unique challenges.
How do Conventional testers end up on Agile projects?
I have experienced or been approached by people seeking help in situations like this:
- the customer tells an agile team they have to have “QA” people on their project
- an agile pilot project has such good results, a development lead from that team is put in charge of a QA group
- a software company with an existing QA department tries some agile methods
- developers who want to learn more about testing request conventional testers to be on an agile project
Moving Forward
I will put a stake in the ground, and answer some of the questions I’ve raised from what I have learned so far. This is the first in a blog series on “what are conventional testers doing on agile projects”? Now that conventional testers are here, what do we do?
I’ve been involved in agile projects, or projects trying out some agile methods as a conventional tester over the past five years. I feel woefully inadequate to really answer these questions, but demand is growing from people who read my ramblings. They are asking me to provide my own thoughts, so here we go. I’ll continue to post my thoughts in this series, which are very much a work-in-progress.
What I seek the most is feedback from you, the reader. Are you a conventional tester on an agile project? If so, what did you do? What worked, and what didn’t? Are you a developer doing agile testing that has worked with conventional testers? What worked well? What didn’t work so well?
As a development community, I challenge each of us to help each other and work together by sharing knowledge and experience. We can leave the debating to the pundits, or for our own pursuit of knowledge. I hope we can get the ball rolling and move towards building better software products, gaining knowledge and skills and serving the customer. After all, the process isn’t what counts to the consumer, it’s the product.
Who Should Read This Blog Series
If you work in Quality Assurance, or are a professional Software Tester, I consider you to be (like me) a “conventional tester”. You tend to do more testing than contributing production code. If you are a conventional tester or a Business Analyst who is joining an agile project as a tester, this blog series is for you. If you are a Testing Manager, or Project Manager on an agile team, you too may find this series helpful. If you are a developer who isn’t sure what to do when a customer asks you to work with people who are full-time testers or Quality Assurance folks, you may also find this series useful.