Modern QA role on Agile SDLC

Reference: http://www.headspring.com/blog/what-the-tech/the-confusion-around-qa-why-doesnt-the-industry-agree/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+jeffreypalermo+%28Jeffrey+Palermo+%28.com%29%29

Most people in the industry are undoubtedly familiar with the Software Development Lifecycle (SDLC).

Reference: Wikipedia

I was having lunch with a recruiter colleague, and I was learning about the QA requests from lots of customers.  Most defined the QA role well within the “Testing” oval as shown in the picture.  From my questioning, it appears that the agile movement has done little to alter this SDLC.  In fact, this process is still alive and very will, even within agile teams.  The difference is in the batch size.  Rather than doing analysis on a batch of 50 features and then moving that full batch to design, the agile movement has reduced that batch size considerably, and in some cases reduced it down to a batch size of 1.  Lean agile teams are likely to use a batch size of 1 and continuously pull features through the lifecycle.  As an aside, I find that even when working on a single feature, this cycle is still in play, although the feature is more likely to jump backward and redo a portion of the phase before if new information is found.

The reason for the reflection on QA is that my recruiter colleague still predominantly  receives requests for QA folks to fill the roll of the testing phase.  This means that the QA involvement happens after analysis, after design, after implementation, and only when defects can no longer be prevented.  They can only be discovered.  Inspectors at the end of an assembly line are powerless to prevent defective parts.  They can only discover them through inspection and serve a Quality Control role to prevent defective parts from being shipped.  The same is true in software, and many others have written the same.

I shared a very successful project where we incorporated what would otherwise be a very traditional QA Manager into an agile process and yielded great results and a very low defect rate.  When crafting the team’s process, the QA Manager worked in between the analysis and design phases of a given feature to understand and then define the test cases.  That is, based on the current understanding of the feature, how will we test it?  The work required to create the test cases was sufficient to find analysis gaps early and force them to be filled.  The additional information and context contained in the test cases added the design activity as well and yield, in my opinion, a more robust design that was less prone to defects of oversight.  In this project, we saw the time spent coding reduced to less than 50% of the overall project effort.  In fact, at the beginning of the project, programmers were about 50% of project staff, and half-way through, the programmer staff had been reduced to 1/3 of overall project staff.  By crafting a process that pulled thoughts of QA to the beginning of the process, we modified the environment to one in which it was hard for defects to be created in the first place.  In the end, we found no need to create a defect tracking database, and the team was applauded for its quality.  The production launch, which always carries some risk, was a trivial affair, and the system is currently being used by many to perform their daily job.

Our industry stills see QA not as assuring quality, but merely controlling quality through inspection.  Some savvy development managers already have changed traditional QA job descriptions, but there is a long way to go before these notions reach the mainstream of the industry.

What are your experiences with QA?