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.

Scrum Cycle
Rate of Adoption of Agile Methodologies


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.

The Problem

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.

Cost of Fixing Defects

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

  • How are test cases tracked? (e.g., Zephir for JIRA, Rally, others?)
  • Is this information accessible to everybody in the team?
  • How do you evaluate which test cases should be be automated so they can have a significant impact on the SDLC?

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.

  • How do you define and report defects? (e.g., Zephir for JIRA, Rally, others?)
  • Do you specify ACTUAL vs EXPECTED behavior?
  • How do you communicate that a defect has been created? is ready to be tested again?
  • Do you have a process to close the defect?
  • Do you differentiate defects found during testing versus defects found by users in the field?

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.)

Identify Test Types

Occasionally, a Sprint introduces a feature that may require a new type of testing (e.g., load, stress).

  • What kind of test are you executing manually? (e.g., regression, integration, functional, UI, etc.)
  • Do you keep track of code coverage?
  • Do you follow the Test Pyramid principles (i.e., more low-level unit tests than high level end-to-end tests running through a GUI).

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.