Following my thinking about the fact that functional testing was the dividing barrier between specialized developer and tester roles, I found in the book “Agile Testing” by Lisa Crispin and Janet Gregory an excellent list of fears that QA teams could express against agile adoption:
“Testers cling to the concept of an independent QA team for many reasons, but the main reason is fear, specifically:
* Fear that they will lose their QA identity
* Fear that if they report to a development manager, they will loose support and programmers will get priority
* Fear that they lack the skills to work in an agile team and will lose their jobs
* Fear that when they’re dispersed into development teams they won’t get the support they need
* Fear that they, and their managers, will get lost in the new organizations
We often hear of QA managers asking questions such as “My company is implementing agile development. How does my role fit in?”. This is directly related to the “loss of identity” fears.”
Source: “Agile Testing”, Lisa Crispin and Janet Gregory, Addison-Wesley
i think the quotes you mention are bit shallow and are not from anyone serious about testing.
“Fear that they will lose their QA identity”
-the role of a tester would continue to be the same in the agile setting. Their identity would not be lost since that is how they are perceived by the others
“Fear that if they report to a development manager, they will loose support and programmers will get priority”
-this is true in a sense. there is a natural conflict of interest here. Does it make sense to have the same person build your house and have it inspected by them. Of course there is tendency to look the other way if we are trying to deliver when issues arises
“Fear that they lack the skills to work in an agile team and will lose their jobs”
-a tester is not a developer thats for sure. I don’t see what special skills are required to work in an agile setting that differ from other software development life cycles.
We often hear of QA managers asking questions such as “My company is implementing agile development. How does my role fit in?”. This is directly related to the “loss of identity” fears.”
-this is crap, as a tester, clarifying and understanding what the current context is part of the job. This does not relate at all to fears or loss of identity
At the end of the day, the QA role (ideally and in the most simplistic way) is to represent the client/end user and present their observations, bugs and recommendations to the team/management so that they can make the decision to ship or not.
If the QA team “represents” the customer, what does the developer “represent” ? Does this mean that developers don’t care for the customer needs or that the customer cannot speak for himself? ;o)
I think this is pertinent – surveys suggest that cultural resistance is the biggest obstacle to introducing any Agile methodology.
Most of the Agile methodologies are based around multi-disciplinary teams – and at the end of the day, if the developers are more focused on delivering tested software that meets requirements, then inevitably that means less testers required.
(As with anti-virus software, the growth of software testing as a specialist job is a reflection on poor quality engineering practices).
The problem is pretending otherwise – in trying to introduce an agile methodology without any change in organisation or responsibility – especially given that the claims of agile practitioners are that you are going to be able to deliver the right product, faster and cheaper (which QED means with less man hours / staff per project).
In respect to Basim’s comments – one of the key points in almost all the methodologies is increasing the developers responsibility towards what they deliver – which means changing the way they perceive their job – from writing code, to delivering working functionality. Really they are ceasing to be just ‘developers’.
If you keep the functional separation – consultant, designer, developer, tester – with ‘power’ in that order, that’s missing one of the big benefits.
Also, in the absolute ideal agile world, the customer is representing themselves, on an almost daily basis – one of the key points is to try and cut out a lot of the problems caused by the many layers between the client and the software.
So I think the answer is – if your testing skills simply mean testing every single field handles bad data, then you should be worried, but otherwise it is an opportunity. (Reality – unless you are starting from scratch, there are likely to be non-coding roles in any agile team).