Quality Engineering in Agile World

Quite often we interchange the usage of the terms – QA and QC. At a high-level Quality Assurance is planning activities to demonstrate quality and quality control is implementing those plans. QA focuses on defect prevention with a set of activities for ensuring quality in the processes whereas QC focuses on quality identification: identifying and correct defects in the actual products produced. Together they help put forward a quality product.

In this article I wanted to write about being a Test Engineer in the Agile world because quite often I have been asked what’s the role of the testing team in Agile? Are the testing team as a concept soon to be an extinct group? In fact, in my experience the role of the testing team has evolved in Agile and the scope is much broader than ever before. Prior to understanding testing in the Agile world, a quick reminder of what Agile prioritizes as per the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

In this context, the role of QA in an Agile world is much more than just writing test cases and reporting bugs to the team.

Here is a snapshot of QA roles and responsibilities in the Agile world:

• In the agile world, testing and development team works together in order to deliver high quality product in less time. They no longer work in silos. The boundaries between the development and testing teams no longer exists. Testing is embedded as part of the agile team.
• Perform Requirement Analysis to resolve all the ambiguities and help the product owner to develop detailed acceptance criteria for their user stories.
• Define what “done” means: QA finalizes the DoD (definition of done) for each user story.
• Attend planning sessions: The early participation allows the QA to understand every single functionality and to identify the possible problem areas.
• Attend daily stand ups: This allows the tester to provide status about their activities, known issues and can bring up any obstacles that’s come up. The developers can concentrate in those areas as well and resolve the issue at the earliest.
• Testing during each sprint: Continuous testing over testing at the end helps to reduce the workload of testing team and helps both teams to identify and resolve the issues in the product,early in the cycle.
• Participate in Release Readiness/Demos.
• Enabling automation testing: Identifying tests that can be automated like the highly repetitive ones or the ones with highly predictive results to create automation testing scripts is also part of the test engineer’s responsibility.
• Documentation: In Agile, rather than completely avoiding documentation we prefer to keep documentation lean.

QA Planning for Agile Projects:

At Amazecodes we use the Agile testing quadrant as we plan the test strategy for our agile projects. It’s based on Brian Marick’s Agile Testing Matrix. Which is a 2 x 2 matrix that categorizes the different kinds of testing for agile development team.This model was popularized by Lisa Crispin and Janet Gregory in their 2009 book “Agile Testing”.

Primarily the quadrants help classify the testing into Business facing testing vs.Technology facing testing. Also helps – classifying the testing as development supporting vs. development critiquing. Development supporting testing is about checking the development work for completeness and if it correctly full fills the business requirement whereas the development critiquing testing is about trying to break the code – to find any unnoticed loop holes/glitch in the system.

These classifications help us strategize on how much of the testing needs to be scripted for automation testing and what needs human intervention. For example, the closer one gets to business-facing tests, the more need for human intelligence to interpret results in real-time.

Quadrant 1 – Technology facing, Supporting the development team: This quadrant is focused to determine code quality.

Quadrant 2- Business facing, Supporting the development team: This quadrant focuses on whether the developed code fulfils business requirements as per the user stories.

Quadrant 3 – Business facing, Critiquing the development team: This quadrant focuses on the realistic use of the product – using methods like exploratory testing.

Quadrant 4 – Technology facing, critiquing the development team: This quadrant focuses primarily on the nonfunctional part of the requirements – security, performance, scalability etc.

Not all quadrants might be needed for every agile project. The quadrants are chosen and the testing scope defined based on the agile project’s scope and requirement.

So, the role of the test engineer in the Agile world has not been sidelined or minimized but rather it has become more integral, collaborative and proactive to ensure delivering high-quality deliverable within a short time frame.