Developers Hand Off to QA, Then What?

One of the oldest practices in software development is when Development (Dev) is done programming and the "feature" or "version" is handed to Quality Assurance (QA).  QA can spend hours, days, and sometimes weeks reviewing documentation, executing test cases, and holding bug-bash parties.  This may sound efficient and fun at first but the party is short-lived when bugs are reported and the Devs starts fixing bugs and sometimes defending themselves.

The romance Dev and QA feel when a project starts always begins with happiness and enthusiasm but quickly turns mutinous when Dev fortifies itself against the never ending bug reports and feature-creep requests from QA and User-Acceptance-Testing (UAT).

Code -> Code -> Code -> QA -> Fix Bugs -> QA -> UAT -> Code ... Release?

Instead of narrating every permutation of Dev vs. QA conflict, which is inevitable in a traditional software development shop, I'm going to skip ahead and describe a different way using Embedded QA and a definition of Done (DoD) based on Agile/Lean Methodology.

Each group of Devs work on one "feature" at a time.  By "feature" I mean something very small and useful that can be tested.  In Agile Methodology, this unit of work is called a Story.  The Devs start work on the next Story only when the previous Story is totally complete. That is, each Story is Done only when QA has reviewed it and it has been accepted by the end-user.  That's right!  Devs should not start new work-in-process until QA and UAT is complete by the Product Owner.  The DoD should be specific and consistent across all Stories to attain high quality software.

There are two key elements at play which make this model work.  Devs are code-complete on a small, testable, piece of functionality (a Story).  QA only has to manually test one small piece of functionality at a time (the same story).  The glue which holds these two elements together is what I call Embedded QA.

My description of Embedded QA is when the Dev team and the QA team are the same team! The Devs and QA work on the same thing at the same time.  The first objection most traditionalists have to this practice is, "Won't that make Devs less efficient?"  The second objection most traditionalists have is, "Won't waiting for Dev to finish make QA less efficient?"  The short answers are surprisingly, Yes and Yes.

To address the first objection, "won't that make Devs less efficient?",  I answer Yes!  Dev's will be less efficient individually because they will be working on one thing at a time.  But working as a team rather than individuals, they will have higher team throughput.  That is, the software development team will have higher global throughput because there will be less context shifting, more knowledge sharing, less cognitive load, more accountability, less over-engineering, and ultimately less rework so you shouldn't care about individual Dev efficiency.

To address the second objection, "won't waiting for Dev to finish make QA less efficient?",  I again answer Yes! QA will be less efficient as individuals because they won't be filing as many bug reports — they can simply show their Dev teammate the problem and watch it get fixed in minutes. QA will be less efficient because they won't need to test as much software.  That is, the software development team will have less rework and therefore QA won't have to retest the same feature over and over.  The team's global throughput will be higher with quicker QA turnaround, no need for extensive documentation, less rework, and a high standard of quality -- all because Devs and QA have meet the DoD before moving on to the next Story.  There’s no reason to keep a list of defects or have an extensive QA time if the Story is accepted by the Product Owner when the Dev work is Done.  Also, many Devs choose to write automated tests to help QA go faster.

Code/QA/Demo -> Code/QA/Demo -> Code/QA/Demo -> Release!

The core condition for belief in the Embedded QA model (and Agile/Lean in general) is that accountability and capability are coupled.  Or phrased another way, having QA and Dev on the same team makes the Devs accountable right away.

It is true!  Devs and QA can live and work together in harmony when they share ideas instead of hand-off, talk to each other instead of documenting defects, and have a shared vision of being Done.

** Some other elements which contribute to a successful Dev & QA Embedded team is the use of a Continuous Integration (CI) server, high Product Owner involvement, automated test suites, story tasking, retrospectives, and many other Agile and Lean practices.

Read the original article.

This blog post is brought to you by SolutionsIQ, the largest pure-play Agile consultancy in the industry. We have the people, passion and expertise to make Agile at any scale a reality. If you're looking for more of the latest, greatest Agile content, check out our resource library chock full of webinars, case studies, white papers, podcasts and more!