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

Posted by Floyd Marinescu on May 03, 2007 06:00 AM

Community

Agile

Topics

Software Testing

Tags

Testing

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.

1. Back to top

   i can rename column :P

   May 4, 2007 12:33 AM by Rave Man

   i can rename column just like that, you just have to rename it in hibernate mapping xml file. people forget that we all are using ORM.

   Reply

2. Back to top

   I remember this talk...

   May 4, 2007 8:47 AM by Bruce Rennie

   and found the reaction in the audience to be pretty amusing. Heck, it was even brought up at later meetings. Way to make a lasting impression, Scott! As a person who's been involved in agile projects for several years now, Scott's comments were right on. A friend of mine (who's also been involved in agile projects for years) and I would often have conversations about exactly this topic. Often the discussion would turn to our disappointment at the contributions of the testers to the project. Occasionally, we would work with a tester who "got it" and things would be wonderful, but this was the exception rather than the rule. Personally, I think "we" (developers) bear part of the blame here. We've treated testers and testing as an afterthought, as second class citizens for so long that perhaps they shouldn't be blamed for sticking to their comfort zones. After all, in a lot of corporate or non-agile shops, being an aggressive, dynamic, flexible tester isn't always a career enhancing thing. I'm beginning to believe that the only difference between a tester and a developer in an agile team is their mind-set. Developers always tend to be optimists, even on agile teams. Testers are our pessimists. Beyond that, in terms of skills, they really should be identical.

   Reply

3. Back to top

   IBM's view on "traceability"

   May 11, 2007 11:26 AM by Rajesh Duggal

   I wonder when IBM will decide if traceability is a good thing to track and measure or not. Rational RequisitePro http://www.ibm.com/software/awdtools/reqpro/ "Provides detailed traceability views that display parent/child relationships and show requirements that may be affected by upstream or downstream change" Yet, Mr. Ambler of the IBM Methods groups gives thumbs down to traceability. -- It was really confusing, and mischievously fun, to debate with "IBM Rational tools" believers against Scott's AgileModeling.com concepts. I guess IBM isn't in the business of selling paper and pens and whiteboards and markers. I hope Ambler wins, with AUP... http://www.ambysoft.com/unifiedprocess/agileUP.html Go,go,go! :) Raj.

   Reply

• Older >