Sunday, July 8, 2018

Why automate tests in an agile environment | Supreme Agile

Agile teams will fail if they don’t use frameworks to automate different aspects of the development, such as tests, builds, test environments, and so on. To understand why a lack of automation causes failure, we first need to know that the main focus of all agile teams is to successfully deliver real value to the customer, which can be translated into delivering working software at the end of the sprint (in other words, short releases in a fast-changing environment).

To achieve this goal, an agile team should be able to test their deliverables often, quickly and with great coverage. In this article, I will review some of the most common reasons that agile teams have to achieve this important goal and the challenges they face.



Why automate?

There are multiple reasons why agile teams will want to automate their tests besides the knowledge that everyone else is doing it, including the following:

Manual testing takes too long

This is the most basic reason for an agile team to automate their tests. Manual testing and long regressions simply take too long to complete in an environment that does not provide the same testing time as traditional software development methodologies (such as the waterfall model).

As an application gets bigger and more complex over time, the test matrix grows longer and longer, and the team will not have time during the sprint to manually complete the regression tests needed to guarantee they meet the highest quality standards.

Running a full regression suite during a sprint is just an incorrect practice in an agile environment. You simply cannot do it with manual execution. If your current practices do not contain any automation coverage, don’t let that stop you from starting now.

Manual testing leads to technical debt  

If you execute your regression testing manually, you already know that it takes a huge amount of time that you simply do not have in an average of two weeks of work. In addition, it is common practice for agile teams to run regressions every day, every iteration (which does not make any sense to do manually).

If your regression tests are executed manually, it will not allow the team to keep pace with coding. Then programmers have to free up their time to help with the testing, which leads to technical debt and increases frustration among the team.

Automation techniques improve team knowledge

Automation can allow the team to get a better understanding of the product architecture. Using advanced techniques such as Test-Driven Development (TDD), where code tests are written prior to the actual code, allows programmers to gain a deeper understanding of the requirements, design, and architecture of the product.

Automated tests provide fast, early and frequent feedback

If there is no change in the automated test script, we can expect it to pass until the functionality of the application is changed. When a programmer modifies the application code, he also needs to maintain the automated tests to accommodate them.

If the programmer changed the automated script to support the code changes, and automated tests still fail unexpectedly, a regression bug may have been produced by the code modification. This is a great indicator of the efficiency of the automated test design.

Another thing we need to know is that when the team runs an automated suite of tests for all new and modified code that is checked in, this ensures that regression defects will be caught at an early stage. Bugs caught early are cheaper to fix and will not add major risk in advanced phases of the development process.

Now, what does it mean to receive quick feedback from the automated tests? The main thing here is that once the defect is found early (a matter of minutes to hours from the time that the programmer adds the code), the change is still fresh in the programmer’s mind and thus will be easier to troubleshoot than if it was found days later, during the manual testing process.


Automation as a key factor for continual stable builds  

Due to the nature of agile development, it is hugely important that the team not spend their already limited time on unwanted problems such as partial or corrupted builds that will prevent the team from finishing their work.

Partial or corrupted builds are one of the top time consumers during agile development. There is no way that the team will succeed in delivering their commitments without having an automated CI/CD system that will allow the team to have continual stable builds throughout the iteration.

Automation will help free up the team’s time

The creation of test automation takes time, and of course, there is more time spent on maintenance, but once the team succeeds in creating the greater portion of this system, it will reduce the time they used to spend on executing manual test scripts, running numerous repeatable tests and endless manual regression cycles.

Now that the team has reliable automation that can replace the manual execution of regression cycles, the team will have the energy and time to focus on new test scenarios and learning more about the product and how it works, which increases the overall quality of the team deliverables.

Automated regression tests as a safety net

Knowing that the code has sufficient test coverage by automated regression tests gives the team a great amount of confidence while modifying or adding new code. This confidence is not a small thing in the agile development process where new code is checked-in and tested on a daily basis.

Automated regression tests will provide the team with a safety net that will help them find unexpected defects caused by the newly added or modified code within a matter of minutes (for unit, component, and integration-level tests) or hours (if at a higher functional level, such as system or end-to-end tests).

Now, if the team fails to invest their time in building a solid automated suite of tests at all levels of the application (unit, component, integration, and system) to act as a safety net, the programmers will start to treat the testers themselves as safety nets, which will lead to "mini" waterfalls during the development process.

Teams that have good coverage from automated regression tests can work in a more reliable environment that will allow them to write their code and add it to the main branch fearlessly because they do not need to wonder how this new code will break the build and what hidden defects may arise. The tests will tell them in a very short time frame whether or not they broke anything. 

Manual processes are more vulnerable to human error

Manual processes and manual testing are more vulnerable to human error. That's just a simple fact that we can explain by saying that manual testing is a repetitive process that gets very boring for a team member who needs to follow the same testing scripts over and over again.

And when people get bored, stupid mistakes are more likely to happen, obvious bugs are overlooked, testing scripts are not executed as they were the first time, and as we know, people will cut corners to complete work when facing tight deadlines.

The simple solution is to automate all tests that contribute to the team ROI from sprint to sprint. The direct result is the reduction of human error, risk mitigation, and creating a constant development process that will increase the efficiency of the team.

I already mentioned the word consistency earlier, which is key in the agile development process. Consistency is achieved by the team once they reduce the manual processes and automate processes (testing included), which will reduce the possibility of human error because each process and test is done exactly the same way over and over again. Automated frameworks will not cut corners to achieve deadlines.


Thanks to Tally Helfgott for proofreading :) 

Linkedin Profile

No comments:

Post a Comment

My Presentations