Several of us here at Making Sense have been doing testing for several years and we have worked on projects organized in both traditional and agile ways. One thing we’ve all noted is that there are differences in the way a QA process is carried out. Apart from organizational differences, the testing process that is performed in agile methodologies does not follow some of the standards that we have learned throughout our career. This might generate some uncertainty in testers who prefer working within a more structured process.

The fact that agile testing does not follow traditional forms is due to the fact that in agile methodologies such as Scrum, the QA area is not intended as an area, but rather as a series of testing tasks performed by team members. It is not the intention of agile methodologies to have a team in which there are people whose exclusive role testing. Rather, there are developers who can also test.

In practice, agile methodologies are adapted to the needs of each project. As the theory goes, this is why it is difficult to implement agile methodologies. For this reason, there are usually testing teams in agile projects, where traditional QA tasks are executed partially (or with restrictions). This ensures they are able to adapt to the iterative and incremental development rate, guaranteeing the quality of the product.

Testing Agile vs. Traditional Testing

Agile methodologies do not consider testing task as a separate process, but as an integral part of software development as well as programming, since tasks are developed throughout the development cycle and not at the end of it, as in the Traditional model.

This approach leads to changes in the tasks performed in the traditional test model, and thus, it reduces the generated documentation, encouraging informal communication between groups, prioritizing the early detection of bugs and giving prominence to automated testing. Traditional test techniques can be used but reducing the time allocated to the design of test cases and focusing on early execution is important.
Let’s analyse some of the tasks involved with both approaches:

Agile Testing Classic Testing
Testing is done throughout the development cycle The testing is a phase, which is executed once the development is completed
Automated tests have more prominence (unit tests, regression, smoke) Most of the tests are manual
Seeks to prevent bugs Bug detection is priority
The design of evidence is reduced to particular cases. Scenario lists are used Much time is spent on designing and maintaining tests
Tester and developers work together Testers and developers work separately
Testers are involved from the requirements phase Testers are not always involved in the requirements phase
Each iteration has its own regression The regression is executed after the whole development is completed

Since iterations have a short length of action, the selection of test scenarios must be optimized. In order to do so, we can use different techniques:

  • Equivalence partitioning: The input and output results are grouped into different classes. For each of these classes, the program behaves in the same way for each member of the class. Therefore, the test of a value of each class is equivalent to the test of any other value of the same class.
  • Limit value analysis: the test cases are designed based on the values ​​of the limits of a validation.
  • Decision schemes: These diagrams are intended to show the range of possible outcomes and subsequent decisions made after the initial decision.
  • State transition: Tests are designed to execute valid and invalid state transitions.
  • Use case tests: Describes the interactions between actors (who can be users or systems) which produce a result and which add value. These can be derived test cases.

Tasks related to Agile Testing

As we mentioned earlier, testing is done from the beginning of the sprint, and is performed by all team members, not just the testers. For example, there will be testing related tasks performed by developers, the analyst and certainly, by testers.

For this, the development team can use test-oriented techniques such as Test Driven Development (TDD) where a test is written and verified to fail. The code that makes the test pass satisfactorily is implemented and then the written code is refactored.
On the other hand we can automate unit tests instead of executing them manually. The code is modified over and over again. For this there are multiple frameworks.

At the requirements stage, both the analyst and the testers can walk through the documentation or code to detect errors or misunderstandings at an early stage.

The testing team should:

  • Automate the largest number of possible tests (regression or smoke tests)
  • Reduce the time allocated to the design of test cases (for example, to register them in a reduced form as a checklist or list of scenarios)
  • Encourage the use of exploratory testing (in which the learning of the functionality, list of scenarios and execution occur simultaneously)
  • Use tools for performance and stress

The testing process should incorporate tools and methodologies to guarantee the quality of the product following the rhythm of continuous development, typical of agile methodologies.

Lastly, the most important point for all of the above to be successful within a project, is the quality in the communication of the team. Equally important is the conviction that changes in the traditional testing processes are indispensable, and that a transformation to an agile process must take place. Only then will the team be able to give added value.