Tuesday, August 21, 2018

What can we automate in an agile environment? | Supreme Agile


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, just 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 simple and logical, a 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 be able to 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 that greatest ROI of any automation effort:  
  • CI allows for immediate feedback at the unit-test level (in case that 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 allows for multiple check-ins per day.
  • It improves communication because team members can receive a notification once the build is ready without needing to check 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 they can. 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 continues integration and build the framework as soon as they can. 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 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 specific 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, but in some cases, we really need to think about 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 important 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 is crucial in reducing problems that when found in that layer of testing won’t become a bigger problem later.

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 in 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 a whole system.


Performance, load and Stress tests

If you’ve ever been involved in the testing process that included one of the testing types mentioned above, you probably know that it’s almost impossible and certainly ineffective to use manual testing methods as the preferred way to run them. Furthermore, there is a wide range of tests that you simply 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.

Thanks to Tally Helfgott for proofreading :) 


Linkedin Profile

No comments:

Post a Comment

My Presentations