“Be the change you want to see in the world” Mahatma Gandhi

These words mean much to us and they have unconsciously driven us to work towards a successful transition from the waterfall to the agile testing world. This article contains our collective thoughts about the journey that we went through, what was entailed, the skills we needed, the mindset shift and so on.

When it comes to comparison, it sometimes is assumed that Waterfall is some kind of an archaic thing that we must overcome and outlive. Well, far from it we see it only as a journey and from amongst this group, some testers have seen through projects successfully with waterfall methodology. We must realise that a method is needed to solve a problem in a given context, and the method may be iterative, waterfall or say Scrum. A project may come along and as testers (or as software professionals) we need to be up for any methodology, just as an archaeologist has no hang-ups about terrain or geography.

The Early Days | The Waterfall Tester

Waterfall as a methodology had tradition, solidity, predictability (being sequential) and assurance on its side. As testers, we mostly got involved later in the development life-cycle and meticulously progressed testing with application understanding, analyzing voluminous specs, written tests, defects, some fights, triage meets, multiple test cycles, phases of testing and so on… It was an orderly world that we lived in on one side of the wall and there was even a cushioned sense of protection provided by test leaders / managers, who called the testing shots.

As testers we confined mostly within ourselves and sometimes with the developers and business analysts to elicit, analyse and exchange information. Obviously, testers were closely knit and relations with ‘others’ would flare up at times given the ‘us-versus-them’ syndrome that existed. There were adventurous amongst us who ventured ‘into the beyond’ and even profited but somehow the ‘misdemeanors’ did not spread too much. We did our bit though with great passion, logged defects, negotiated and even suffered anguish when application shipment went through the ‘gate’ despite the ‘unfixed defects’ and  ‘their lack of concern for quality’. The defect leakage was a talking point then too. Sometimes the leaders would protect us from the defect leakages that came from the customer yonder, while at others we would bravely try to withstand the onslaught on our own, providing justification or looking sheepish at other times.

There were good times too, mind you. There were projects which were driven well by project management who looked at us with equal eyes, and led the team as a whole towards a common shared objective. Yes, we recall projects and parties where we bonded well and partied hard and so what if they were not testers! Alongside we learnt about intricacies of stakeholder management, requirements management, program specs, development pitfalls, language jargons and more that was part of their world that we did not see often. We shared the testing bits as well and some empathized.

Today, the role of an Agile Tester

“During my initial days with agile projects, I would see a user story akin to a requirement id like in waterfall and I recall being concerned when each and every little rule was not meticulously detailed by the Product Owner…” Shiv

The advent of Agile has first and foremost meant that the walls did not segregate us. Thus we are now out in the open free to observe, challenge, interact, speak and contribute. The onus is as much on us as on the rest of the team. The notion of a singular team is now reinforced more than ever (even though this happened sometimes within waterfall projects as well).

In our day-to-day tasks, we have to be proactive to pull tasks, coordinate and take to closure. For tasks like effort estimation, for example, we work as a team with each member expressing what effort it would take to complete a work-item.

“This is so much in contrast with how my test manager would come and tell me to do the test design by so and so date” Akshatha

“What I really like is that I can listen in and even contribute to technical discussions be it during look-ahead, planning or common analysis meeting” Apurva

Being in an Agile team environment, we tend to develop into more than just what testing demands from us. Yes, we need to identify at all times the impacted areas and ensure the test coverage is comprehensive enough so that the story is tested and in a shippable state. Or that automation needs to be done alongside development, or performance, usability and other quality criteria checks need to happen early and continuously (rather than later as a distinct time-boxed pre-release activity as it used to happen in another era after a functional test cycle completion). The scope for the tester to grow beyond the testing boundaries and with the cross-functional expectations of Agile has been a huge plus.

“I love the challenge of writing feature files in collaboration with the developer who helps me with the step definitions to be developed in Ruby and in tune with the database. It makes me so much more aware of the development side of things. During the discussions, I also understand the creator’s tools and mindset as much as the developer probably does of me, not just a hammer-man anymore” Akshay

As part of iteration work, we have to configure / manage test environments, create test data, report defects and work with the team to resolve them.

“We do not need to hold triage meets at periodic intervals. They happen every day” Shiv

We constantly need to collaborate with product owners, developers and business stakeholders to clarify the requirements, especially in terms of testability, consistency and completeness.

“Thanks to Agile, we participate in team retrospectives, suggest and help implement improvements. It gives us a sense that each team member is responsible for application quality” Akshatha, Apurva

Challenges we faced switching from Waterfall to Agile

This transition was not easy though, it took a while to get adjusted with the new ways of working. “

“I eventually understood that everything need not be documented in great detail within a story or that it is not the responsibility of the Product Owner alone. I saw first-hand that the story acquires better shape via the refinement it undergoes based on team discussions” Shiv

The team analyses the stories and agrees on the acceptance criteria along with implementation aspects, impact analysis, considerations for automation, responsiveness, usability and so on…

Going Agile meant testing small and continuously rather than waiting for a big build to be deployed to go hammer and tongs at it.

“I had worries about testing smallish elements within stories in isolation and more so about the other stories that I already tested in the previous iterations” Akshay

Automation, Continuous integration and a hardened sprint at the end ensures that the application is fully tested.

“The challenge of automation seemed a mountain at first but when this was conquered by persistence it freed me up to do non-mundane, smart testing” Akshatha, Akshay

Automation also becomes easier given that the developer is close by to help make it effective and more efficient. Collaborating with them has exposed us testers to how development with patterns, standards etc. ought to be and automation is development anyway.

It is accepted that testing has to happen in tandem with the developer, because the team needs to deliver at the end of sprint. This is something very challenging and tricky at times. If a story gets delivered late for testing with the demo date looming, and the story has to make the cut for business reasons then we (and the developer) have to burn the midnight oil. In such cases (rather in general) collaboration with the developer to assess areas impacted, agree tests to perform and say cover off some initial testing in dev environment really helps smoothen what happens  when we test manually or with automated checks…

“I recall my earlier days where finding defects was one of the key motives of a tester, which is no more the only objective.” Apurva

In Agile the focus is on regular delivery of working functionality and to achieve that it is important to avoid or prevent defects in the first place. For times immemorial, this expectation has been set and this is not illogical or unreal. Agile has brought this to the fore and we play a central role.

How did we do it?

As more and more projects turn to Agile, the question for testers today is not when but how. The tester’s successful transition is dependent on how quickly she acclimatises (including in her mind), understands the agile way and starts in earnest.

Our recommended ‘success’ recipe for the agile tester is:

• Positive attitude
• Exploratory / analytical skills
• Communicate, collaborate and actively elicit information from team, technical and business stakeholders
• Test with hands. Test with tools.
• Perspective, ability to see big picture
• Out of box thinking
• Adapt, respond to change quickly
• Get technical to do the job effectively
• Fearlessness
• Growth mindset

Evolution is always good and should be seen in a positive light. As long as there is a demand for quality products, testing will continue… Testers are therefore indispensable, provided we upgrade ourselves to meet the challenges head-on.

We had great fun discussing, brainstorming and putting this together.  It is hoped that this helps a budding software tester make the journey or even for some testers to relive their transition they have had.