Hello everyone, in this article I would take you thru some of my experiences in Agile testing.
About Me:
• Scrum Master
• CSM and CSP from Scrum Alliance
• Working with Agile software development from past 4 years (approx)
• Passionate about Agile
About My Team:
• My team is a pure testing team
• We do Non-functional and E2E testing hence we are on the outside of the component scrum teams
Practices taken from XP tailored for our team:
There were some eXtreme Programming practices that inspired me as a Scrum Master so I modified it to suit our team
Pair Testing:
• This comes from the practice – Pair Programming. This includes testing too but in our case it was very explicit. Hence we called it as Pair testing.
• A person working alone can be a victim of tunnel vision
• Pair Testing is a concept wherein two testers sit and work together on the same piece of application to either test or write test cases over a period of time, exchanging ideas continuously throughout the process
• We time boxed this activity
Advantages:
• It is fun and productive
• This helps in generating a lot of ideas
• Ideation -> Creative process of generating, developing and communicating new ideas
• The best idea would be picked from the lot
• This would always result in new perspective or a change in way of testing thereby improving productivity
• No special process required
• It is more effective than a single person testing
• There is more “Focus”
• Pairing up with new joiner’s helps them understand the system, hands on is always better than theory.
• This helped us in removing bottleneck expertise and Knowledge sharing.
• Pair Testing was done in the Afternoon after lunch so that there is always the other person to poke you and keep you awake 
• Since paring is pretty focused it could be stressful. So it’s best to take a break every half hour or as required by the pair. Also keep toggling the driver role.
• Sometimes even talking out your problems to another can help you understand the issue better
• Another Flavor:
• Team testing:
Our team consisted of 4-5 people.
We went to the meeting room, created and Refactored tests together
Every member was in sync
Everyone had ideas and the best idea was picked
Knowledge and experience sharing
Refactoring of testcases:
Definition of Refactoring:
Changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.
We used the above concept to refactor Test Cases.
- Why did we refactor Test Cases?
• To improve the quality of testcases
• Better maintenance of the test artifacts
• At a point of time we realized that we were just blindly copy pasting the resource files that were not even necessary for that particular test suite. This was also increasing the execution time.
• We had a lot of local copy of resource files, so they had to be removed to point to a central resource file to maintain uniformity
• Suite Setup:
We were creating and deleting the same objects for all the testcases, hence we consolidated pre-requisites like:
Allocation and/or initialization of all resources that are used in the suite setup.
Deploying the common adaptations/metadata
Launching of desktop
Etc
In the suite setup itself
• As and when we started writing the new testcases, we saw that there were a lot of duplicate testcases which were testing the same with a little difference or with some enhancements. So refactoring helped us remove redundancy making our testing process lean with little wastage, in turn the consolidated testcase became more efficient and re-usable in a meaningful format.
• In Non-functional -> destructive testing. We had one script for restarting one particular service, hence we had many scripts for all the required service restarts. So we consolidated all of those into one generic script and pass the service to be restarted as the parameter to it.
• It is better to start refactoring with smaller units which you know and are familiar with than the larger legacy bits.
Automation and Continuous Integration:
[Goes hand in hand]
It is so true when they say: Time is Money
This is where Automation comes into picture:
Advantages:
Test automation and automated functional testing has the capability to decrease the overall cost of testing and improve software quality,
• Reduces Cycle time of testing
• Increases quality
• Decreases Manual efforts so that the people doing the testing can focus on deeper aspects of testing which need manual intervention
• Faster feedback
Team Goal:
• To automate 100% of the User stories under our Non-Functional Area
We are currently using the
• Robot framework for automation of our testcases
• Acceptance Test Driven Development [ATDD] approach
Of course these were based on certain criteria like
• Cost of automation
• If there are any manual intervention required then they cannot be automated
This helped a lot as we dint have to:
• Reduced monotony : we dint have to spend too much time testing the same functionality manually over and over again
• We got faster feedback and were able to take actions immediately if required. [CI system in place for our project helped to get faster feedback]
• Allowed us to do more exploratory tests
• In End-2-End: Starting from generating/triggering a trap for checking in the database and checking the alarms in the desktop. This whole process was automated.
Exploratory Testing:
There was a confusion regarding Exploratory testing in teams. Hence I would like to emphasize on this point:
Exploratory testing is an approach which closely aligns with the essences of the agile manifesto, but we should take care that exploratory testing is not equated with the testing performed on agile projects.
It is widely accepted that the most effective test strategies – Agile or non-agile, include both systematic scripted techniques and exploratory testing. Hence we cannot use a test strategy based solely on exploratory testing.
Advantages we experienced:
• For us it is more of Exploratory Learning
• As per experience, we don’t understand software until we have used it. So we planned to explore the product with each iteration.
• It helps us test, focusing on the customer perspective
• Look for bugs, missing features and opportunities for improvement. – Incases there are critical bugs found, it is best to automate the flow and integrate with the CI suite.
• Pairing up with new joiners and exploring the system. New joiner’s have a fresh view of looking at things. So they might give some valuable inputs of testing the system that we have overlooked since we have been working on it from very long.
• It is a rapid way of testing instantly, no extra documentation, no extra work, just the minimum effort required to succeed in testing the new features.
Conclusion:
Finally I would like to conclude saying that:
These are some of our best practices that have been achieved after a lot of trial and error session
“There are no silver bullets in Agile”
Something which suites one team need not necessarily suite the other teams too.
I would definitely quote the three levels of practice that’s known as the Shu – Ha – Ri which roughly translates into learn, detach, and transcend.
Thank you
I was very dejected. I did not want to miss this opportunity, for me it was the biggest forum I could share my thoughts in!!! I dint want to give up. Then a thought struck me.. So what if I cannot go to the gathering, I could still try and get to tell them what I have to say. So I spoke to the organizer, Gerry Kirk, and asked him if I could do a 5 min video and send it across. I was told that this was the 1st time a lightning talk would be given as a video and it was worth a try. After thanking Gerry profusely, I started my work on my video. I wanted to fit everything I wanted to share within the 5 mins given to me. Being a 1st timer in actually doing a video presentation, I had my own share of challenges. Finally!!! My Video was done. I sent it across and it was all set to be presented 
)) #sgnl
