Agile Testing

AGILE TESTING

Introduction

In the traditional model, we could experience a situation during the final project release saying "Critical issue in software on scenario x". Then the entire team will be fed up after hearing this statement from testers.

Obviously the project release date is collapsing because of the last minute defect. How we should address this issue? How do we ensure the system doesn’t break throughout the sprints after doing various source code changes to the project? Agile testing is the best way to avoid the preceding last minute issues by doing the automation/integration testing in the sprints. Let’s discuss this in detail

Agile Tester

The traditional thinking of testers is to find most of the defects in the system, so management will reward the one who identified the most of defects or the most important defects of the project, This habit has motivated the testers to identify the critical defects before the project is released. Instead the testers should concentrate on creating test environments/frameworks for improving the testing to provide a better quality software.

For example: tester’s should put more effort on writing automation scripts, coded UI, to ensure the features developed in one sprint should not break in another sprint because of new features. It's the responsibility of testers to build the scripts/recording the scenarios in the Coded UI. So that it shall run on a daily basis to confirm the features developed so far. But the developers should lay the environment foundation for the testers to carry on writing the automation scripts in the sprints. Agile testers should provide the early feedback to the developers by building automation scripts or coded UI.

Testers should see the defect database as a queue of partly done work. In an Agile methodology there is no more about how many records found by whom. Testers and developers should work as a team to complete the user story on time with quality.

Testing on Developer Bench

In the traditional waterfall model the developers first develop all the user stories and commit in the source safe for delivering it to testing at the end of the sprint, Then the testers do the testing and find some issues, again developers will take the issues and deliver them to testing by fixing it. Here the bug life cycle is too high by moving here and there. Instead, as soon as the developer finishes his/her development he would call the tester to test his functionality by running the corner cases in the development bench itself. These cases might have forgotten from the developer side. This actually shortens the feedback loop. Once the basic test is done, the tester will do exploratory testing on his bench.

Automated Testing

Developers, whenever giving their updates for testing, he should identify the impacted areas for the updates he is delivering and send it to tester, After that testers need to write the automation scripts/Coded UI for the features delivered as well as for the impacted features. Tester’s need to put more effort into writing the automation scripts for all the features delivered, this will be useful to ensure that the happy flow of the application will not be affected.

 

As I said earlier, the developer must lay the foundation / platform for creating the automation scripts or coded UI. On every sprint testers must write the automation scripts for all the user stories developed, going forward this would be very useful in all sprints to ensure the features done so far is working well. Should we require running automation scripts on every commit? Yes, you should, it would help the developers to find and fix the defect at the earlier stage itself. Do you think it takes more time on running automation tests? For that it is possible to run your test suite in multiple threads using the selenium or maven feature. We shall see these topics in details in my next article.

Pair Testing

Pair testing is another technique for testing a software by two members in a team. One person should be a developer and another could be a tester. Both will work together and actively contribute to the PT session. It should be a time boxed activity start and end in 60 - 90 minutes also the both should agree the time they needed to complete.

A tester finds the defects and explains the scenarios to the developer, he then fixes the defect immediately, This actually reduces the barrier among tester and developer and the communication is direct and immediate here. Also the tester doesn’t need to create or reproduce steps and screenshots for uploading the defect in bug tracking system. Also, it eliminates countless emails/discussions about how to reproduce the behavior.

 

Another aspect is that it’s a very focused activity. Usually bug reports come in through a ticketing system and the developer fixes them in a dead moment or in a time that was assigned to bug fixing. This can bring many distractions. The end goal is still fixing the user’s problems. But since that user doesn’t have a face or is not with you, that goal seems very blurry and far away.

 

When you are interacting one-on-one, the goal is satisfying the needs of the user that sits right next to you. This technique is especially useful for eliminating minor bugs like spelling mistakes, issues among various browsers, visualization problems and small behavioral changes. In general, it’s a technique that works really well for bugs that are easy to solve. When you’re getting bugs that affect the entire system or performance bottlenecks, it’s probably better to create a bug report. What you want ideally, is that the developer can keep up with the tester. What we usually do is, when a bug is found that is harder to fix, leave it open and roceed to the next one.

 

At the end of the session, the bugs that were not fixed in the session are then added to the bug tracking system. I have found this technique to be really easy and useful and have applied it various times with success. I consider this type of testing a sort of code review, but from a functional point of view.

Summary

In the Agile testing the defects will be found at the earliest stage itself in various manners like automation testing and pair testing. Agile testers need to come up with the creative ideas to make the quality software rather than always finding defects in the system.