[Diagram] The Shift Left for Quality Assurance (QA)
While quality assurance (QA) has always been important to the reliability of software applications, it has often been shunted aside or squeezed in favor of development priorities. That was especially true prior to the introduction of “agile” methodologies in 2001, when Waterfall and V-Model predominated.
Waterfall Sweeps Testing to the Side
The Waterfall model is a sequential design process with progress viewed as flowing steadily downward—like a waterfall. It is lengthy, taking months to years to complete, with each phase dependent on completion of the one above. During the first three phases, the QA team twiddles their collective thumbs while important development tasks happen “above.” Fixing defects is also a lengthy process: in a worst-case scenario, imagine refactoring six months of development work!
Enter V-Model Where QA Gains Some Respect
V-Model is a little more humane, like a waterfall with fountains. QA is more involved at each step of product creation, with testing at each phase. However, the release process is still long, dependent on phase completions and quality gates for progress, with no allowance for quick changes.
Both methodologies are long and relatively inflexible processes, with little tolerance for requirements changes discovered during development, simple code refactoring or even major components rewrites. Ownership of the final product is split among siloed groups that handle change requests and defect resolution with multiple meetings, review sessions and approval levels. QA owns testing but is always isolated to the right of the process.
What if the lines were more porous? What if QA shifted to the left side?
Agile methodology suggests we do just that!
Agile Integrates QA in an Iterative Development Process
Agile most often takes the form of Scrum/iterative development, with time-boxed efforts called sprints. At the beginning of each sprint, the Scrum team conducts a sprint planning session, driven by user stories or requirements prioritized by the product owner. The outcome is a decision on which product features to implement and which go to product backlog. Sprint duration varies from two weeks to a month, depending on business needs, available resources and other practical constraints.
The entire team commits to interaction in a 24-hour cycle called the daily Scrum meeting or stand-up. Since the goal of each sprint is to produce working software, each sprint goes through all phases of the software development life cycle (SDLC). Testing is an integral part of the SDLC, and feature testing must be completed during each sprint.
Agile promotes iterative code development. Testing and test documentation are also done iteratively. Test plans and test documents are continuously refined, logged and reported, seamlessly in synch with code development. The QA team is tasked to:
- Test Early – in fact, it’s an integral part of development
- Test Often – sprints are short, so test features and fix defects now
- Collaborate – as a product-focused team
How Does It All Work?
- Product owner and business users create product backlog which describes in detail desired features, expressed as user stories, with all pass conditions. Essentially, all requirements must be clearly defined and testable.
- Product owner works with development and QA to prioritize features to be delivered during each sprint.
- Development team implements a feature, working with product owner and business users to understand scope and run unit tests to verify feature operates as expected at code level.
- QA is involved from start of sprint planning and owns feature testing. QA team designs or updates feature test case, based on user story and pass conditions. Unit tests might be leveraged or built on as well. Test automation scripting typically begins at this point.
- Once feature development is complete, it is deployed for feature integration testing.
- QA tester executes full feature test to verify implemented feature behaves as expected.
What Happens When You Encounter the Unexpected?
The iterative method applies to rework and maintenance as well:
- If feature test fails, defect record is created and assigned to developer.
- All steps are repeated until defect is resolved and feature test passes.
- All features in the build are developed and tested in parallel, following steps above.
- A build containing all passed features is created and deployed to dedicated QA environment for regression testing.
- QA testers run regression tests (ideally automated tests) to verify all features behave as expected.
- If the build fails, any defects uncovered are triaged and resolved by development and retested.
- Once build regression test passes, deployment to production environment is scheduled.
With QA fully integrated in the mix, development is accelerated and quality assured.
Source: Galmont Software Quality Assurance