What can we automate in an agile environment? | David Tzemach
Most types of testing benefit from automation, starting from basic unit tests all through system tests. As you know, unit tests don’t supply enough coverage to catch system regression failures. But running a set of manual tests before every check-in, which could be dozens of times a day, isn't practical.
And this is a problem—a big one. Because when developers can't run tests by simply pushing a button, I can assure you that they will most likely not be motivated to run tests at all.
Let's talk about the kinds of tests that are most suitable for automation. Automation starts with an automated framework that allows developers to check in their code often and receive quick feedback about its impact. So let’s start with this first.
Continues Integration (CI) system
This is where we create the most important, albeit logical and straightforward, ground rule for automation. Due to the nature of agile software development, which is faster than any other approach, agile teams should focus on automating any repetitive or tedious work involved in developing software.
And no candidate is better for this than automating build creation as part of an agile development process. Due to the fast nature of agile development, the team should create numerous builds per day, especially to test newly added code.
CI systems are crucial in an agile environment. Continuous integration and build processes are the two systems that give the most significant ROI of any automation effort:
CI allows for immediate feedback at the unit-test level (if you have the relevant unit tests to support it).
It reduces many of the risks involved in adding new code without testing it.
It allows the team to create and deploy numerous (stable) builds and provides for multiple check-ins per day.
It improves communication because team members can receive a notification once the build is ready without checking the status.
CI systems speed up testing time by reducing the number of errors at the unit level before these errors become apparent in advanced phases of the testing process.
Based on the above, agile teams must implement continuous integration and build the framework as soon as possible. Although it requires continual maintenance, it’s the only option for agile teams to succeed and reduce technical debt in large complex projects.
Based on these simple facts, you may see that agile teams must implement continuous integration and build the framework as soon as possible. Although it requires continual maintenance, it’s the only option for Agile teams to succeed and reduce technical debt in large complex projects.
Development and Test Environments
Agile teams need to test and develop in a fast-changing environment; as a result, there is less room for the creation and maintenance of work environments. Agile teams can use the automated deployment of their environments without multiple hours of manual work. In addition, the team can use automation to handle many other areas related to their work environment:
Creation and cleaning of the testing data and configuration.
Setup of specific topologies and architectures.
Simulating a particular scenario for reproducing a bug.
Testing of the User Interface (UI)
The agile development process embraces the approach that the team must deliver an incremental working functionality at the end of each iteration; as a result, the team will usually execute basic automated regression tests at the GUI level.
As I mentioned earlier, I'm a great believer in automated testing. Still, in some cases, we need to consider whether we want to use it, especially when we want to test the user interface of an application whose GUI changes.
To overcome the challenges of GUI testing, there is great importance in selecting the most suitable tool for the job, one that’s easy to maintain and flexible enough to absorb changes. This is probably the most critical key to successful GUI automation.
Testing all layers of the application
I'm a great believer in automated solutions that can reduce manual testing efforts to the bare minimum necessary. It starts at the first layer of the application by running unit tests that we all agree are crucial in reducing problems that won't become a more significant problem later when found in that layer of testing.
Next, we have the second layer of component tests. Programmers test components as a whole module by using a set of inputs and outputs that the module produces. The third and, for me, the most crucial part of the testing strategy is integration tests, where modules are tested together as one suite. And if that is not enough, why not test the whole system by running the fourth layer of system tests, which test the entire application as an entire system.
Performance, Load and Stress tests
Suppose you’ve ever been involved in the testing process that included one of the testing mentioned above types. In that case, you probably know that it’s almost impossible and undoubtedly ineffective to use manual testing methods as the preferred way to run them. Furthermore, there is a wide range of tests that you cannot run without automation tools.
In addition, using manual tests will not provide the accurate test results we can achieve by using dedicated automation tools that can simulate the exact scenario without any human interference that may affect the testing process and, therefore, the results.