BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Scott Ambler on the role of testing & QA in Agile projects

Scott Ambler on the role of testing & QA in Agile projects

In this video presentation, Scott Ambler talks to a testing & QA user group (TASSQ in Toronto, Jan 2006) explaining to them how agile software methodologies work and how testing works in an Agile context.  Talking to a group that usually does testing as a full time profession, disconnected from the development team, Scott explains how agile developers unit test before writing code, how they treat accpetance tests as full-fledged requirements artifacts and work with stakeholders to acceptance test throughout the development lifecycle.  Scott argues that agile methodologies have resulted in significantly higher quality than what traditionalists produce, and that we've achieved this with very little input from the testing community (whom he was addressing).  Scott basically concludes that there will be little long term employment opportunities for full time QA or testing people, much to the horror of the audience he was addressing.

Watch The role of testing & QA on Agile projects (81 min)

Around 73 minutes Scott was asked what skills do QA people need to acquire to maintain employability considering that Scott thinks that pure QA roles will not be a safe job, Scott replied:
you'll need to be flexible,  work with others, pick up other skills. You're not going to be testing or QAing or whatever constantly. Just like a data person is not going to be doing data modeling constantly, there gonna be doing a little bit of data stuff, coding stuff, requirements stuff, some testing stuff, go back and do some data stuff and so on. 

You've got to be willing to go back to the diff aspects of software. This is called a generalizing specialist, somebody with one or more specialties, so if you if you wanna be a testing specialist that's great but you've gotta have other skills as well. You've gotta be able to roll up your sleeves and do some progamming, do some coaching, do some modeling, do some deployment,  do some build, you've gotta have thse basic skills, plus an understanding of the domain you're working in,  and be willing to pick up more skills over time... If you wanna be a specialist that that gets something handed to them, you do your thing and then hand it off to someone else, you can find employment doing that but it will be in these traditional more than likely going towards CMM or CMMI organiations which is great but you're being targetted for being outsourced, because if I can hand off something to you, I can just as easily hand off something to India.
I was in attendance at the talk (camera guy) and blogged about it which kicked off a large discussion on TSS. Scott Ambler commented on my blog entry:
Some of the traditional folks in the audience, and there was clearly some "modern thinking" QA folks in the audience too, didn't like parts of my message. That's a good thing, to paraphrase Martha Stewart, because the should feel threatened by the changes coming there way. Some people in the agile community believe that we don't need traditional QA people at all, although a better way to say that might be that we need flexible QA people who are generalizing specialists instead of the overly specialized traditional QA folks that some organizations still have. Quality is clearly job one within the agile community, it's just that we achieve it using significantly different techniques than traditional QA prefer. QA people are more than welcome on agile projects, the bring significant skills to the table, they just need to be flexible enough to do more than just QA stuff.

Rate this Article

Adoption
Style

BT