Agile Testing

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

Advertisements

About agilesoma

An aspiring agile coach. I work in one of the leading Telecom Product Companies. I am a CSM and have more than 2 years of experience in working with agile teams. Passionate about agile/scrum and helping people who would benefit from my experiences and understanding.
This entry was posted in Uncategorized and tagged . Bookmark the permalink.

One Response to Agile Testing

  1. Lisa Crispin says:

    It’s exciting to read about another team that is having success with the a similar approach and practices as our own team. I’m interested to know more about how you do pair testing, I think our team would benefit from more pairing, but it’s hard on such a small team. Your refactoring experience is similar to ours, it seems like a constant battle, there is always more refactoring to do! I like how you have balanced automating regression tests/checks and doing exploratory testing (or learning, as you call it – I really like that). Thank you for sharing your experiences!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s