What is Agile Testing?

Fifteen years ago, Agile was a buzzword, but nowadays a growing number of software development teams lean toward this approach. Apart from the fact that that it enables the equal involvement of all team members in the process, it also gives a free hand in choosing development methodology and tools. Naturally, such an atypical approach to software creation is marked by the changes in the structure of its endogenous processes, compared to a traditional model.

So, to answer the question — “What is an agile testing methodology?” — we need to gain insight into the Agile software development specifics.

The Core of Agile

First and foremost, to come to grips with Agile testing, aka testing in Agile, we need to clarify that this term refers to the testing process within the Agile software development methodology. Also, since testing is an indispensable part of any software building methodology, we need to figure out what the Agile testing methodology is to understand the essence of Agile software testing methodology.

It was a group of programmers that first introduced the term Agile for software development and put its key principles in a 68-word Manifesto in 2001. The statement opposes critical Agile attributes by the specifics of a waterfall approach, such as:

1.      People and cooperation prevail over procedures and tools
2.      Quality software prevails over extensive documentation
3.      Good communication with customers prevails over contract relations
4.      Prompt reaction to changes prevails over strict adherence to the plan

Alongside these key principles, we can better understand the specifics of Agile by weighing it against the waterfall model:

• Agile projects are incremental, divided into short timespans that iterate multiple times throughout the project. Each iteration is a scaled-down model of a full development cycle and includes coding, concurrent testing and result delivery. By contrast, the waterfall is a monolithic process that has a clear structure and consists of distinctly partitioned successive phases that are longer than iterations.
• Traditional projects are bound by comprehensive instructions and documentation; each stage has a clear description to which you should adhere. The iterative approach deprioritizes technical specification and sticks to meeting the current customer requirements that are likely to change.
•  A project owner gets an overall view of a waterfall-driven solution only after a project is finished. In the iterative model, project owners have an idea of the solution underway and are free to provide their feedback at any time.
• Under Agile, the work on an application can start before a team has a clear project scope, while the waterfall model demands a pre-set plan.

So, the ultimate value of such iterative software development is in the team’s joint efforts throughout the project while abandoning strict planning and excessive documentation. This methodology proved its feasibility, and it fits aptly the fast-paced IT world.

The results of VersionOne’s 10th annual State of Agile survey for 2016 make it clear that a number of organizations that use this model continue to increase. So, 95% out of 3,880 respondents said that their companies use these practices.

Initially, this methodology meant that all team members were interchangeable and substitutable. The idea was that the developers handled all arising issues on their own, which abolished role division and eliminated the need for testers. However, turbulent market conditions have touched up the Agile team structure, which resulted in the separation of the testing role within the model.

Still, despite that the overall goal of testing – a quality and trouble-proof software – stands true for both Agile and waterfall, the testing processes in the two methodologies differ. Agility sets its mark by the necessity to test along with the changes in the requirements and in the product itself.

Also, iterations are short, which compels testers to do their work quickly to release the product on time while providing invariable quality. In the waterfall model, testers fall on software checkup only after the development is complete, not concurrently with it, and take guidance from the comprehensive documentation.

The Core of Testing in Agile

Given that testing has evolved as a critical part of the Agile software development process, it inserts testers between product owners and developers, and this forms an ongoing feedback loop.  Also, this process in traditional projects differs from what is meant by agile testing in the iterative approach. Whatever the wording, the agile testing definition indispensably covers its key attributes, such as:

• Interaction with product owners. Testers communicate with product owners to put their expectations of the project into an illustrative form to make developers understand the requirements and code accordingly. So, testers are more involved as consultants and communicators than in a waterfall model.
• Close communication with developers. Testing is tightly bound into the development process, so Going Agile not only implies checking code for soft spots but also puts a piece of developers’ burden on testers. As a result, such a model incorporates testers into the development team to enable ongoing results reporting and to encourage timely suggestions on solution improvement.
• Total team’s engagement in quality assurance. All team members are passionate about quality, not only the testers. Developers build unit test cases for a smoother process for testers and to enhance the quality of audits. Also, they follow testers’ recommendations for quality improvement and test requirements.

Although it seems that iterations lack structure, the structure is not as blurred as it may appear. During each iteration, a piece of code undergoes the processes that are needed to ensure its output quality. Scrum is the most widely used framework for the projects that require agility, and below we outline the steps of one of the QA processes in Scrum-based projects:

1. The team chooses a sprint backlog and set about development
2. While developers code features, testers write test scenarios, checklists and test cases based on the backlog and user stories
3. After the coding is complete, testers fall on both manual and the automatic testing of the ready features
4. If no issues are revealed and no further development is required, testers proceed to a system and regression testing (this stage can be dropped, depending on the project) and the team delivers the feature to the customer.

The Pros and Cons of Agile Testing

In the context of Agile, it is difficult to overestimate the role of the testing part. A clear understanding of the basics of Agile testing and that it keeps its pace with development allows getting the most out of it. So, non-stop product checkup alongside development allows businesses to enjoy the following benefits of the iteration methodology:

1. Better time-to-market. Unlike a traditional waterfall model, it ensures that testing is concurrent with software building. As each iteration stipulates that a team develops a functioning piece of code that is ready for implementation, this feature-by-feature solution delivery to the customer allows to come up with a new application before their competitors do.
2. Increased profit and bigger market share. Agile allows revealing an error, if any, sooner to reduce the time lapse between software building and testing. So, a company is ahead of competitors with its new offering to capture a bigger market share and earn higher revenue.
3. Reduced costs for bug fixing. A timely fix of revealed errors enables less rework, as opposed to redoing the project after the coding phase is complete. Also, testers’ competencies allow them to participate in the development process, and, consequently, to prevent bugs and avoid extra costs on their elimination.
4. Improved software quality. Having up-to-date testing results reveals vulnerabilities to quickly act upon and encourages the focus on high priority functionalities. Also, integrated Quality Assurance leads to reduced rework and improved product quality.
5. Increased employees’ productivity and satisfaction. Developers and testers collaborate closely to see into each others’ duties in intersectional matters and to optimize workloads. Also, self-organizing teams create a more appropriate development chain and clearer architecture.
6. Customer satisfaction. Product owners see the software during its development, not after it’s ready for deployment. So, the modification of a solution is possible while the project is underway to adjust it to changing customer requirements, shifts in technologies or industrial standards. Also, product owners collaborate closely with the development team* to explain their requirements clearly and prevent gaps.

*  Development team structure varies significantly from company to company, depending on the chosen framework, team size and customer requirements. In SaM Solutions, we utilize Scrum in most cases. However, depending on the project specifics, we allow for some modifications, and then product managers and business analysts merge with our Scrum team.