What to Know Before You Start Agile Testing

Whether you are looking to expand your customer base, or your service is the go-to in the market, I have found performance and functional testing offer a wide range of benefits. From highlighting functionality errors, bottlenecks, and security risks, to avoiding website outages, I have discovered the the importance of agile testing in the product development cycle. 

Of course, there is more than one model for testing. These have been created adhering to the different  software development cycles and project procedure models. I learned that the most popular testing models can be roughly divided in two: (i) the classic plan-driven or sequential model, commonly known as waterfall, and (ii) the agile methodology, based on iterative and incremental development.

In this blog, I will discuss what I wish I knew about agile testing, my favorite types of testing under the agile testing umbrella, and ways you can incorporate them into your strategy.

What I Wish I Knew About Agile Testing

Agile testing is iterative, flexible, and incremental, following a more natural and collaborative product development process. Testing is done continuously so that performance and functional issues are identified and addressed as early as possible.

For me, one of the most important principles of agile testing is customer satisfaction. By delivering and testing products frequently, and by welcoming continuous feedback, myself and my team can quickly respond to changing requirements and performance issues. Agile testing also meant less documentation for us and generated savings in development costs, time, and resources. 

With superior adaptability, rapid and frequent product delivery, the ability to detect issues early on, and client satisfaction principles, agile testing quickly became the clear best choice for me, my team, and our clients. 

Agile Testing vs. Waterfall Testing

As I began my agile testing journey, I compared it to the waterfall model. It follows a sequence of test stages where every step starts only when the previous has been completed. This means that the requirements for each phase of development must be well-defined and testing is only carried out at the end of the development cycle. While this linearity made the model look easy and efficient to implement, it left very limited room for clients, developers, and end users to identify and address functionality and performance issues until all previous development stages have been completed.

In short, it involved a lot of waiting on my end.

That being said, I will say not everything about waterfall testing is negative. Waterfall testing is advantageous in cases where testing requirements are fully defined, and when testing needs to be simple, low in resource requirements, and well-documented. This explains why this method continues to be used by developers and quality assurance engineers for certain projects.

How I Used Functional Testing in Agile

Functional testing looks at the behaviour of a feature when it interacts with the rest of the system, customers, and users. When I use functional testing, my main goal is to evaluate whether the product works as the users expect it and as developers designed it to.

Under waterfall methods, functional testing is done by a group of testers during the testing phase of a project. Since agile testing is done throughout the development process, the distinction between developers and testers can be less clear. However, by capturing the most recent input from clients and users, we can provide a product that better meets the current and evolving requirements of users.

As I progressed along my agile testing journey, I took a wide range of approaches to see what worked best. Below are some of my favorites:

1. Acceptance Test-Driven Development (ATDD)

With this method, I integrated the perspectives and needs of the tester, developer, and customer. My initial goal was to create an acceptance test that is based on the customer’s point of view. By doing this, the testing is focused on what could go wrong from the user’s perspective. This gives developers direct insight into what customers want and how the product will be used, removing ambiguity from the process and reducing the chances of large errors being made.

2. Behavior-Driven Development (BDD)

This method runs scenario- or example-based communications between developers, testers, and business analysts. I created scenarios that included clear information about how different inputs and situations would affect the behaviour of a particular feature.

3. Exploratory Testing

Using exploratory testing allowed me to design, execute, analyse, and learn from non-scripted tests. This made my testing highly adaptable to changes, and allowed myself and the team to identify issues in the functionality of a product through seemingly random exploration. Based on the finding of each exploration, we learned and designed future test plans.

How I Used Performance Testing in Agile

In my experience, performance issues are problematic. While an application may meet the functional requirements defined by the customer, it may not do so within the time, resources, scale, and availability expected.

When I run performance tests in an independent stage, as done under waterfall methodology, they may be detrimental to the project because possible performance issues cannot be solved by simple code changes at the end of product development. In fact, I have found the remedies often involve architectural changes or an increase in resource demand. Addressing these changes at the end of the development cycle becomes highly costly and time-consuming.

That is why I found it critical to run performance testing in parallel with the development process. In agile testing, performance testing is done at three different stages. First, in parallel to the coding of a new feature. Second, after any functional tests of that new feature, to understand the time and resources needed to implement it. And finally, after the integration of new functions with the rest of the system, to check that major performance issues are not introduced in the system. When I execute these three stages, it reduces the chances that a new feature leads to major architectural changes or increased resource demand.

Bottom Line

I learned a lot in my agile testing journey. It helps greatly to have a team with the right skills, tools, methods, culture, and mentality for moving towards the success of the software development cycle. In my experience, BlazeMeter offers all the agile testing components you need to shift left, along with the speed, reliability, and performance that your team and customers need. 

START TESTING NOW

Related Resources

• 7 Principles of Good Agile at Scale