You are viewing our old blog site. For latest posts, please visit us at the new space. Follow our publication there to stay updated with tech articles, tutorials, events & more.

The Agile Tester

0.00 avg. rating (0% score) - 0 votes
I have been testing software for quite some time now, I have moved between organizations and also up the organizational ladder. But never have I experienced a role change as great as when we moved to ‘Agile’ model of software development. We are still very young in agile but have made some significant progress in our quest to move out of a ‘Waterfall’ like model to being perfectly ‘Agile’.
 
The main addition to the role of a tester in Agile is that, apart from the traditional role of testing builds/reporting bugs/regression, the purpose is about getting things done. As a tester, you should try to act as a service to the project and ask yourself, “What can I do that is best for the team or for the project?” Since we at our organization (Naukri.com) are still in the process of moving to Agile, I have also realized that testers play a major role in implementing processes in scrums, apart from the absolute roles that a tester must play. For a better understanding of these role changes let’s have a look at the various aspects of an Agile Tester.
 
  1. Planning:
One major responsibility of testers in Agile is to help describe the features. Before the story goes into development, the testers and developers meet with the product owner to discuss the stories to be executed in the iteration. The goal of the conversation is to create an opportunity for a good understanding of what the product owner wants. Testers can make a great contribution here as they are capable of detecting and recognizing ambiguity even before development begins. Applying this skill before development begins, rather than during or after development, will help ensure that the development team is focused on delivering the expected goal for the sprint. Ultimately, testers not only detect issues but also help prevent them.
 
Estimation is another task that is undertaken during an iteration planning meeting, which a tester must participate actively in, while there are various estimation techniques going around, we follow the show of hands technique. A tester must help the team realize impacted areas and corner cases which will help the team estimate accurately.
 
During these meetings testers can take notes and plan their work for the forthcoming iteration. The testers must ask for QA drop dates from the dev teams (we found that this is required when a team is very young in Agile much like ours). This will enable the tester to plan his work for the iteration effectively. Testers must analyze the information provided to make a note of possible automation tasks.
 
  1.  Communication:
In an Agile Environment, testers will find that they become very communicative and end up initiating a lot of the communication and coordination. They interact with developers (who typically are engrossed in the features they are developing or the bugs they are fixing) and the product owners and bridge both the gap in communication and in understanding of the product requirements. From my personal experience I feel that a tester would make the best scrum master if ever a team decides to have one.
 
Great interpersonal skills with clarity in expression can be the greatest assets to a tester in Agile. The tester must be highly motivated to proactively engage everyone who can help add value to the process and the product.
 
Agile principle states that the most efficient and effective method of conveying information to and within a development team is face-to-face conversation. While this holds true, in my opinion communication through designated Project Management/ Bug Reporting tools is also as important, in our case the tool used is Jira. This will help all stake holders get a clear picture of the ongoing/ any previous sprints.
 
 
  1. Automation:
Automation takes a center stage in an Agile model of development. With frequent releases going live, one cannot imagine regression being done manually. A robust automation suite must be in place for an efficient agile eco-system.
 
Here at Infoedge India (naukri.com), we have a single team for manual and automation testing. Testers responsible for the manual testing of a project are also responsible for updating and maintaining the automation scripts for their respective module. Whereas most organizations (like my previous one) have separate teams for manual and automation testing. However, from my experiences, I have come to realize that a single team is the most effective way of doing it.
 
With so many changes happening in the application, the automation scripts also need to be updated on the fly. While some teams update scripts once a change has gone on production, we are working towards updating scripts while the changes are still under development. This can be done using the dev environments and getting at least a basic suite in place before the actual QA drop. Once this is implemented, automation can be used even for the first round of testing, and if we are to move to CI CD, updated scripts before the QA drop become essential. Imagine a time when the developer can test his code with just a click of a button before handing the code over to QA for testing.
 
While all the above points make sense, the question that arises is how to implement this. A team, with proper training and a finalized framework, must first build a ‘base suite’, a suite that covers all major Test Cases of the application in question. In our case, team members created a “Test Case Bank” for their respective applications, a document that contained all possible test cases. Step two, automate these to achieve a robust regression suite.
 
Apart from ensuring that regression will be exhaustive every single time, having a comprehensive automation suite has certain other major advantages for the team. This suite not only enables the testers to automate any new requirements promptly and with ease, but also empowers them to express themselves as manual testers using methods such as the exploratory testing, since he no longer has to worry about the basic test cases being missed.
 
 
  1.  Detecting Bugs/Ambiguities:                
The most essential role of the tester still remains detecting bugs and aiming for a bug free release. In addition to this the tester must make test results visible to enable the team to make collective decisions. The timely reporting is of high importance here because of the tight timelines of a sprint/iteration.The tester must make use of bug reporting tools as well as daily standups to accomplish this effectively.
                
The tight timeline also makes the skill of exploratory testing incredibly valuable. Let’s have a quick look at the definition of exploratory testing. Exploratory testing is all about discovery, investigation and learning. In theory, Test cases are not created in advance but testers check system on the fly. The emphasis is on personal freedom and responsibility of the individual tester.
 
In our experience though, in a team only a few can manage to do exploratory testing alone and succeed. Most testers need a plan/checklist to execute. As stated earlier in the article, a robust and updated Automation Suite is a must to enable the use of exploratory testing without having to worry about missing requirements. The way we decided to go about it is, add the test cases for the new requirements to the already existing Test Case Bank, and add automation scripts for it to the suite. Once this is done the tester has the freedom to use his imagination, think like a user, and really expand his horizons as a manual tester as well.   
                  
Let me reiterate what I have stated before as well, a tester’s role is not just to find defects in the application but also point out ambiguities in the design and contributes in the impact analysis as well. This will greatly help in bringing down the effort and cost of fixing bugs at a later stage of development. Most importantly, we need to find out what the product actually does rather than what we believe it does or how it has been documented to behave. Remember, the biggest mistake that you can make as a tester is assumption.
 
 
 
  1. Retrospection:
Retrospection is another integral aspect of an Agile environment, all the more important when a team is new to agile. Here a scrum team discusses about the past sprint, what went wrong? What was done well? What more should be done? Again, a tester has a huge role to play.
 
While all team members are aware of the issues faced in their respective stories, a tester has an overall view of the iteration and can very easily sum up the rights and wrongs of the iteration. It is a good practice to keep noting down points as the iteration progresses each can be discussed in the retrospection meeting.      
 
                        
 
Agile, is an environment that enables teams to hasten the delivery process and empowers team members to self-manage and make decisions without the interference of “managers”. While agile is a boon for the entire team, I feel it’s the testers that benefits the most, with so many dimensions added to the otherwise(as popular belief) single dimensional role. A tester can thrive and not just survive in an agile environment. But, Agile needs a tester as much as tester needs agile. For the Agile eco-system to work effectively, active participation of testers at every step is essential.
Posted in General