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

Posted in Uncategorized | Tagged | 1 Comment

Experience of giving the Lightning Talk in Amsterdam Scrum Gathering

This all started with the Special Mentor I met in an Agile event, Jesse Fewell :)
[More about him @ http://www.jessefewell.com/ ]
I told him I was passionate about Agile and wanted to contribute more in this domain.
He told me he would be my mentor and help me in my dream aspiration of becoming an Agile Coach. He asked me to propose a topic for the lightning talk for the Scrum Alliance Amsterdam Gathering. I thought about it and went ahead and posted my Idea:

“No Respect – My life as an Agile Tester”

In brief my idea talked about the below issues:-

- If I’m too young to be taken seriously as a team member, then why is it all the senior people aren’t fixing the problems?
- If Scrum is only about software development, then are we telling the world BAs and Testers don’t matter?
- Does the ScrumMaster need a programming background to be a helpful person?
- Even when it goes right, it goes wrong. Our feature teams having tester-programmer pairs (good), but my Non-functional testing team is still on the outside (bad)

My idea was selected!!! :) Mine was among the few ideas that got selected out of the lot!!! It was a defining moment in my life, a stepping stone toward my dream goal. :)

I started preparing for the presentation. In the mean time I also started trying to get a travel approval to go to the meet. Tried a lot from all directions.. It dint work out. :( 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 :)

On D Day.. I was watching the live streaming of the gathering.
At the allocated time slot.. Gerry came forward and started the video. The video dint work!!! Technical issues!!! My heart stopped!! After all the efforts I had put in.. The video dint work!!! But Gerry dint give up.. He asked the other presenters to present. When all the lightning talks were done Gerry said, lets give the video another try. This time it worked!!! :) It was an amazing feeling. I could see it :)

I took a snapshot of it :)

Once the video was completed. I heard a huge round of applause. I could not believe it that everyone liked it. All the applause was for me!!! :) It was a Wow Feeling.. I still remember tears of joy flowed down my cheeks :)

And all the feedback flowing in thru twitter, mails etc made me feel so happy and proud.
I had done it. :)

My sincere thanks to:
Jesse – my mentor, for pushing me for this.
Gerry – for not giving up on me
Participants – who saw it and appreciated it as well as gave me tips for improvement,
And last but not the least everyone who supported me directly or indirectly [that includes all the companies I have worked in :) for giving me the experiences]
Link of the video: http://www.youtube.com/watch?feature=player_embedded&v=JfoqCvdrflM

Picture taken by Jesse in Amsterdam Gathering:

Some of the twitter feedback:

angel_m: /me too++ RT tumma72 RT @geoffcwatts: Soma Mohanty’s video made me want to donate to the “save the agile testers” fund #sgnl brilliant
about 11 hours ago via web from Binnenstad, Amsterdam • Reply • View Tweet

angel_m: Agile testers of the world have a new spokeswoman: Soma Mohanty. You Rocked!! ;))) #sgnl
about 11 hours ago via web from Binnenstad, Amsterdam • Reply • View Tweet

StefanRoock: RT @geoffcwatts: Soma Mohanty’s video lightning talk made me want to donate to the “save the agile testers” fund #sgnl brilliant
about 11 hours ago via Echofon • Reply • View Tweet

tumma72: /me too RT @geoffcwatts: Soma Mohanty’s video lightning talk made me want to donate to the “save the agile testers” fund #sgnl brilliant
about 12 hours ago via Twitter for iPhone • Reply • View Tweet

karen_greaves: He he RT @geoffcwatts Soma Mohanty’s video lightning talk made me want to donate to the “save the agile testers” fund #sgnl brilliant
about 12 hours ago via TweetDeck • Reply • View Tweet

geoffcwatts: Soma Mohanty’s video lightning talk made me want to donate to the “save the agile testers” fund #sgnl brilliant
about 12 hours ago via Echofon • Reply • View Tweet

llillian: RT @edschepis: Soma Mohanty I respect you. Your video was great. Thanks. #sgnl
about 12 hours ago via TweetDeck • Reply • View Tweet

edschepis: Soma Mohanty I respect you. Your video was great. Thanks. #sgnl
about 12 hours ago via TweetCaster • Reply • View Tweet

ScrumGatherEU: #sgnl Soma Mohanty video: My life as an agile tester
about 12 hours ago via HootSuite • Reply • View Tweet

Posted in Uncategorized | Tagged | Leave a comment

Experience of being a speaker @ Amsterdam Scrum Alliance gathering

Coming soon :)

You can watch the video @

Posted in Uncategorized | Tagged | 2 Comments

Lots of trial and error’s – Part 1

When I joined the new R & D project, there had been an organizational change to adapt to agile. Most of the testers of my team were moved to the component areas where they had to work with the developers as a team on specific area of the project. But some of us were retained as a separate testing team outside of this. So i tried to bend a few tools for our benefit.

  1. Have u heard about pair testing? ;)

In my training I had heard a lot about pair programming. So I thought why not try this with testing. We have certain tests that are manual and repetitive since they need manual intervention and cannot be automated. If a person has to do this alone, it’s really boring. So I thought if two of us do the testing sitting together for all those scenarios, we could do it better without falling asleep.  :)

It really worked!!!! Since we were two people testing the same scenarios, we had different views on how to test them. We started innovating and exploring different ways of testing it. It was fun too. We learn’t with each others experience.

Posted in Agile | Tagged | 1 Comment

What Luck :)

Slowly and steadily, I started reading about it with more interest. No force from the top management so it was more of a personal interest.

I started seeing the benefits of it unfolding right before my eyes.

It broke the invisible barrier between the developers and testers and we began to work as a team.

It made us work in parallel, it helped us solve issues faster and deliver more to the customers.

Then I had to leave and join another company. My current company, a leading Telecom Product Company :)

My project is filled with Agile enthusiasts. I felt at home.

I was given the honor of being the Scrum Master in the team. Now I could try the different tools of agile that I had read about.

To facilitate better, to help my team better.

There were a lot of trial and errors I had to do and that still continues… Since it is after all “AGILE”  :)

Since then, there has been a passion burning inside me, to help people understand agile and to harness its benefits.

Because I know how painful certain situations can be and would never like to see anyone else suffer the same way.

Do you share the same passion?

Posted in Agile | Leave a comment

My Inspiration

The one sentence I would like to quote is from one of the coaches that I have had the privilege of being trained from:

“Agile does not solve all your problems, it makes it so painful that you cannot ignore it anymore.”

-Kati Vilkki

Posted in Agile | Leave a comment

My 1st Acceptance

I was and am still from the testing community and a “tester” by profession.

It was a shock for me when they said that there are no testers or developers, everyone has to take up all the tasks and everyone in an agile team would be called as “Developers”.

But I was happy with that :) cause in India, there is not much of a respect for a tester, socially or professionally.

Reason for making this generalized statement:

If I had to go to a get-together, and when asked what I was doing, I would say that I am into testing.

They would just look down at me and say, “Don’t worry, you will do better in future.. Oh by the way.. Did I tell you? My son is a developer! He is just brilliant!!”

The notion is that, if you are brilliant and top of the class, you get to be a developer else you are shunted into testing. I felt otherwise;

there is nothing wrong in being a tester, we add quality to the product. But that faith dint help. The fear of not getting accepted as a true professional overpowered my faith

So with my efforts of keeping the quality of the product I was working on, I also worked around on how to get accepted in society.

It was simple, I just had to say “Now I am working in an Agile team and I am a developer”  :)

This was my 1st step to accepting Agile.

Posted in Agile | Leave a comment