Building software is more like creating a work of art. It requires creativity in design, and plenty of craftsmanship to do well.
Agile methodologies help teams respond to unpredictability through incremental, iterative work cadences, known as Sprints.
In the last three years the adoption of Agile methodologies worldwide has increased by 23%.
In spite of that, many organizations still struggle to implement Agile QA, even when they are already using other Agile methodologies!
This document describes the Nearsoft approach to integrating Agile QA into the software development lifecycle. We hope it can help you get started on this path.
When it comes to QA, most of today’s available testing methodologies are historically based on traditional waterfall development methods where the testing phase is at the end of the process.
As a result, you end up detecting defects late in the process when they are most expensive to fix.
The High Cost of Delayed Testing
The cost of fixing a bug can be 100 times higher if discovered after the software is released versus discovering it during design.
Unfortunately, many businesses still engage in what could be described as reactive testing
Nearly half of the organizations (45%) start testing after the development phase, in a reactive way. This is too late to influence application quality.
As many as 61% say that they have no plans to introduce quality earlier in their lifecycle. They obviously don’t know how much they are paying for this unwise decision.
Other Side-effects of Delayed Testing
Reactive testing practices have other consequences as well, such as,
- Damage to your product’s image.
In certain industries, like healthcare and aerospace, undiscovered defects can even impact people’s lives.
You Get What You Pay For (If You’re Lucky)
Organizations that take quality seriously realize that it cannot be achieved without an adequate investment.
QA budgets have grown from 18% in 2012 to 23% in 2013 of the total IT budget and it is expected to increase by 5% more in the next two years.
Agile Testing at Nearsoft
It includes at least these things,
- QA starts when the projects starts.
- A priori review of test cases.
- Sprints are always time boxed.
- Stories and defects are tracked together.
- Common understanding of “DONE.”
- Defects are tracked.
- Identify test types.
QA Starts When the Projects Starts
QA is not something that can be effectively patched on in the middle of a development project. It must be considered from the beginning.
Test Cases Are Reviewed Up Front
It is important that developers, QA folks, and Product Owner get together to review each Test Case versus each task (i.e., Story, defect, or technical debt). This must take place before the coding starts in full (and certainly before anything is “done!”).
For each, you must consider its priority, risk, preconditions, steps, expected result, and post-conditions.
Sprints Are Always Time Boxed
Whether it is one, two, or three weeks, it is important to have consistent duration for every Sprint.
For every Sprint you need to go the same cycle of planning the Sprint, keeping the team on track through daily Standup meetings, closing the Sprint with a Demo of the progress made, and capping it with a Retrospective.
Stories and Defects Are Tracked Together
It is a common mistake to think of Stories (i.e., new features) as separate from defects and technical debt.
Instead, Agile QA requires that the team has visibility of all the work, not just the new “shiny” new features.
Common Understanding of “DONE”
- A Story/defect is code complete. There are no TODOs remaining.
- Source code is committed on the server.
- Code has been successfully built with a Continuous Integration tool (e.g., Jenkins).
- Code is deployed to Testing.
- The Story/defect is demoed to QA.
- It was tested and verified by QA.
- Its status has been updated in tracking tool (e.g., Jira).
Defects Are Tracked
Defects are reviewed daily. Then the Product Owner, along with the team decides whether to defer it, fix it right away, or if it’s really a duplicate.
In any case, the decision is recorded in the tracking tool and made known to the whole team.
Identify Test Types
At the beginning of the project the team must decide what types of tests to run (e.g., UI, functional, performance, regression, etc.)
Occasionally, a Sprint introduces a feature that may require a new type of testing (e.g., load, stress).
Agile QA: Road to Success
- Shift from traditional to Agile QA.
- Update your team’s skills set.
- Have a consistent process.
- Tool up for clear communications.
- Keep all available assets reusable.