What to pack for your "Agile Testing Trip"

Even though the Agile philosophy has been in the market for more than two decades, it has only been in the past few years that the trend of using Agile for software development projects has taken off. Though it is gaining popularity, adopting and integrating this philosophy it is not always simple.

You need to pack some valuable knowledge and skills to help you overcome the obstacles you would find in your transition “trip” from traditional to Agile and insure a smooth switch. The QA activities are one thing you will definitely want to adjust.

Man prepared for the agile testing journey - Day 1

What to Pack for Day 1

1. Sprints (partial deliverables)

In the Agile philosophy, the product to deliver (system) is divided into several pieces; these are developed/tested in different sprints (usually 2-4 weeks each one). The transition to sprints (iterations) may produce some backlash at first. How can we possibly write test cases and execute them so quickly?

Furthermore, in Agile a regression test suite execution is required at the end of each sprint, this is something important to consider for the testing effort estimation.

Though it may seem like QA time has been reduced, in the sprints schema the QA time is properly estimated according to the “value” to be deliver on the iteration; that is because every sprint deliverable is clearly identified so its estimations can be more accurate.

This change, mainly affects the“usual” time allotted for Test Planning (Test Cases) creation, because you do not have to wait until the whole product has been developed to start test execution.

Speech bubble: The QA focus is to deliver value not bugs fixed

2. Communication

A new communication paradigm is required, where all communication ways has been opened inside the project team. A daily meeting is planned to improve the productivity and support others’ activities. During this meeting each team member describes: What they did, what they are going to do and if there are any roadblocks for these activities.

In the QA process, the Test Strategy is reviewed and discussed for all the team members (not just for the QA Team), so all the requirements and assumptions are openly discussed and can be managed accordingly.

In the “Traditional” methodology, the Functional Specification (and other documents) are the “alpha and omega” for all the testing activities and deliverables. Traditional project management did not welcome oral notifications for changes.

In Agile, the Functional Specification is an important source of information. The original instructions may change in order to look for and assimilate the information, irrespective to the way it is displayed (verbal, written, etc.). Face-to-face interaction is a plus.

Speech bubble: Meet when required. Work / Look for your stories

Man prepared for the agile testing journey - Day 2

What to Pack for Day 2

Now that we've reviewed the changes in the Project Deliverables (sprints) and the new communication perspective, let's review the major changes in the testing stage.

3. Testing Team

Traditionally, the testing team has been isolated from the project team, trying to avoid any external influence over the decisions/comments generated from the QA Team. The relationship between the testers and developers was restricted to: found bugs (QA) and fixed bugs (DEV). Even, sometimes the testing team was formed by people outside the project/organization, to ensure transparency in the quality assurance process.

Oppositely, Agile removes the constraints that isolate the QA Team and favors a direct and active interaction (face-to-face) between all the team members. It replaces the Tester/Developer role with the agile Team Member.

Another new concept introduced by Agile is that quality is the project team's responsibility as well and not just QA's responsibility. This means that the development tasks are not over until the product is tested and delivered. So, do not pack your Quality Officer suit, replace it by your Team Member overalls.

Speech bubble: Quality is project's team matters

4. Test Driven Development

Test-Driven development is a process based in two techniques: Test First Development and Refactoring.

In the Test First Development (TFD), the traditional software lifecycle has been modified strategically. The business requirements are converted into Test Cases, but they need to be ready before the Development stage, because they are the main input to ensure source code accomplishment and coverage against the business needs.

The main advantages of the TFD are:

  • TFD avoids writing unnecessary source code.
  • TFD improves the source code quality.
  • TFD usually has a shorter testing time.

Test Driven Development cycle graph

Refactoring, the term Refactoring is older than Agile, however its meaning has been modified accordingly. This technique is based on the repetition of short development cycles that incorporate small changes, extending new capacities but do not affect existing ones. Because of this, the Test Automation is a must to guarantee a clean and smooth iterative cycle (it includes the unit test cases automation).

Speech bubble: Test Driven Development is the core of a successful Agile implementation