Change is the Only Constant

Now you see it...

Now you see it…

Change is the only constant – isn’t it?

This statement is true for many aspects of our life, but in the case of software – change is highly visible. Software has become an integral part of our lives. With the widespread usage of web apps, mobile apps and the Internet of things – software has become indispensable.

This massive adoption of software and penetration of technology has created unprecedented demand and competition in the market. To serve consumers in this competitive market, new models to develop and distribute software have evolved. Consumers of this new age have little attention span and the cost of switching to competitors is low. Gone are the days when consumers were obliged to contend with what was offered to them. They have more options, they are more aware and so they are more demanding. Software providers have to add continuous value to retain customers and remain in business now.

All these changes have forced organisations to make their development process lean and efficient. They need to release new software much more frequently than they used to. It’s not uncommon to find organisations that release new versions of their software multiple times a day. This change has a massive impact on the way software is developed.

These market driven changes are now becoming commonplace because tools to support this fast release process have matured. There are plenty of free and commercial tools that support this release process. Tools for things like continuous integration, continuous delivery, test execution, cloud-based deployment and continuous monitoring are readily available. Maturity of these tools, the presence of an eco system around them and the availability of resources skilled in their implementation has made it easier for organisations to adopt this new process.

It is an interesting time to be a software tester. From the process of gathering requirements to delivering software to supporting users and monitoring the health of the system – everything is changing. What is expected and demanded from software testers is also changing. In my opinion, the opportunity to survive, thrive and push our field forward in this changing world makes software testing a very interesting and exciting career choice.

In order to remain relevant, we have to keep up with these changes. We have to acknowledge that some of the things we were good at are no longer relevant. We have to be very critical of the processes and tools we use for testing. The testing mission has to align with the goal of organisation. Quality is still important, but the objectives and context in which organisation is operating often becomes more important than quality. The principles of context driven testing are more important now. With so many changes around us, it is critical to ensure that context is always considered and drives our test strategy.

So how do these changes in the development and release process affect us? In this article, I will reflect on my experience to see how these changes have affected my role as a software tester and how I have coped with these changes.

When I started my career, it used to take couple of hours to build using make files. Compact Discs were the preferred way to distribute enterprise level software and as a result, the cost of releasing new software or a patch was exceptionally high. Understanding of ISO images and familiarity with installers used to be an essential requirement for the job.

Continuous Integration was non-existent and sanity testing or smoke testing was an essential activity. We often rejected builds in the first hour and had to wait for days to get a new build. There were rigid boundaries between users, architects, developers, database administrators, build engineers and testers. Testing was often squeezed, tools for automation were not mature and failed test automation projects were commonplace.   There were no standards, record-and- playback was mainstream and tool vendors limited testers by providing vendor specific language for their tools.

All these problems made delivery of software very inefficient. Everybody was affected by inefficiencies, but testers in my opinion were affected the worst by these problems. It was difficult to remain motivated and many people became testers for the wrong reasons.

In my first project as a tester, I had to ask myself – what am I doing here? How best can I utilise my time? What’s the best way to add value? I eventually found my answers and started focussing on automation.

However the impact of my automation activities was curious to me. Manual testers in my team had no ideas as to what else they might do if most of the things they were checking for had been automated. Developers were equally confused and didn’t see the need of writing code for testing. The client was able to see the value though, and in a service industry that’s all that mattered. Our account became larger and I was asked to expand automation coverage using Visual Test and Silk Test.

The First major change for my career was this shift to automation. I had the right background, projects were complex and clients were supportive. I made the best use of this opportunity and found ways to increase the value of testing using automation.

In early 2000, another interesting change was underway. Many teams started adopting principles of extreme programming and soon I found myself in a team where developers and testers were sitting together. Tools were not mature, there was no continuous integration, builds used to take a long time – but still; we were part of the same team. We often found ways to test early, we paired with developers and finally, developers and testers had the same goal of delivering better software faster.

Suddenly, things like defect count lost their value and developers and testers started the process of understanding and appreciating each other’s world. It was nice to be able to witness this transformation and realise the value of this process first hand.

This was the next big change for me. I learnt to appreciate the complexities of development. I made a conscious effort to bring myself closer to the development world and made myself familiar with their tools and terminology.

With the continuous adoption of these new processes, teams started realising that lack of tools are limiting their effectiveness. The open source movement was also thriving by this time and many people invested their time and energy in making these tools useful for the greater good. Maturity and active community for tools such as Cruise Control, JUnit, FitNesse and Selenium made adaption much easier than might otherwise have been the case.

In the first decade of this century many things related to software testing became irrelevant. Test cases, V-model, test plan, documentation, bureaucracy between tester and development teams became a thing of the past.

With all these changes in the software world, software testing as a field was changing as well. It became easier to find sapient, skilled testers who were willing to share their knowledge. Platforms like twitter, blogs, coaching on Skype and weekend testing groups made it possible for testers to learn and progress.

In my opinion, along with the changes in development processes and tools, we will genuinely become great at software testing because of the multitude of ways in which we can learn and validate our learning.

The attitude of developers towards testing also started changing with time. Availability of good tools and a sense of ownership made them more responsible. Developers no longer shy away from testing. They often do a lot of unit and integration level testing. In many successful teams, automation has become the responsibility of the development team and automated tests have become an indispensable part of the development tool chain. Testers in those teams are expected to help developers, refine their test coverage and spend their time in seeking clarification and exploration. Testers in those teams often work on build pipelines, continuous integration and keep an eye on code quality.

In my first decade I saw that boundaries between various roles such as analyst, development and test teams were reduced. For many projects this has become normal. Over the past few years’ teams have started including operations and support analysts in the team. Many teams use build-it and own-it model and as a result, testers are now exposed to deployment and monitoring using tools such as Puppet, Kibana and Splunk.

I find this change interesting because it makes me understand everything related to application – including architecture, development, deployment, configuration, logging and monitoring. Good testing skills are and will always remain relevant, however I find it useful to expand the definition of essential skills to test software.

I believe that the challenges we faced and the models we created to test past applications are no longer relevant. The nature of software has changed, the development processes used to build the software has changed, tools used to make the software has changed and there is no reason for us to stick to the old ways of testing.

As testers we need to face up to our current challenges and continuously find ways to add value in this fast paced world of software. I believe it’s an exciting time and we need push our boundaries, promote skilled testing, remain relevant and help to move our industry forward.

Keep pushing.

About the Author

Anand Ramdeo is principal test consultant at Testing Geek and founder of

He has played various roles such as individual contributor, manager, facilitator, trainer and consultant in many projects. He has been using open source test automation tools such as Selenium-WebDriver, Cucumber, Calabash, FitNesse, Watir etc from past few years and understand their capabilities & limitations well. He often works as a tool smith and plays a key role in developing automation frameworks and test strategy. He loves to solve various challenges of software testing by using his automation and exploratory testing skills.

He loves to solve interesting problems and is currently trying to make test automation more efficient and effective with He blogs at and can be reached on twitter @testinggeek or on LinkedIn.

You might be interested in... The Dojo

Dojo Adverts-05

Tags: ,