Can we apply 'reduce reuse recycle' to technology?

7 minute read

The three Rs

The three Rs are usually associated to day-to-day waste management and everyone yearns to do more of them for a greener and better future, but do these three Rs mean anything in the technology space? • E-waste management is the elephant in the room for big tech companies, and some are trying to solve it by recycling older hardware and offering repair kits for DIY enthusiasts. • As the hardware side of technology is trying, it made me wonder if the software side of technology needs to think differently and do more with the 3 Rs too.

The three Rs in software

“Even the thought of refactoring legacy code feels like turd polishing”
Refactoring / transforming legacy applications and code may be inevitable at times, however I promise I am not preaching that. I am trying to identify suitability of these three Rs in software development, moreover in the testing space, which I know a thing or two about. The idea is that this might help us in future evolution of testing practice.

Reduce

Over the years we have reduced manual testing across the industry and replaced it or complemented it with test automation – yay!

Along with test automation came pipelines and test runs on a schedule. As it costs pennies, we always schedule more runs than might realistically be required. Occasionally we may even have multiple pipelines doing the same test in parallel.

You might ask why we do it then. The answer is to be safe, to get alerted right away in case something fails and frankly because of an ingrained thought that “there is no such thing as too much testing”.

Action Items

1. If nothing has changed in the environment, do we need to run tests that passed last time just because X hours have elapsed after the last run?
2. How do we achieve a balance between too many test runs vs too few test runs?
3. Can risk-based testing reduce both time to market and number of test runs?
4. Should the end goal be to run regression only for a release candidate, and only have frequent runs over the tests associated with a feature in development?

Reuse

Once upon a time, there were software testers: they used to test everything that was built in the project. Then there came specialisation and special test teams which only concentrated on specific areas of application. Area specific testing teams or not, today we have multiple repositories and test suites which test different components and aspects like functionality, performance etc. of applications.

While this compartmentalisation of testing is good, it does come with an overhead of context switching if it involves the same team and some repetition of tests between suites. Should teams venture into creating a ‘Swiss knife’ kind of framework, where they can test components and end-to-end user journeys independently and seamlessly?

Can an existing framework be reused to:

1. Do API / contract testing?
2. Do frontend functional testing?
3. Do browser x viewport compatibility testing?
4. Do testing on QA, staging and production environments?
5. Integrate with development pipelines and add onto the unit tests?

Recycle

New and exciting testing tools / technologies continue to hit markets on a periodic basis and teams want to embrace these changes in the industry. That means decommissioning existing test suites and commissioning new ones.

While this is good, teams should honestly debate why they want to use a new tool. Is it for personal upskilling? Is there an existing problem that this new tool will solve? Is the cost of change justifiable? Or, should they just follow the good old rule: “if it ain’t broke don’t fix it”?

On occasions, when we do want to migrate to a new tool / framework, should we consider recycling useful things from the existing to-be-deprecated framework?

Teams should evaluate if they can reuse the scenarios / feature files, pipelines, test reporting and even libraries / code of reusable functions if the development language is going to be same. It essentially would depend on how well-structured the current framework is, however an activity to evaluate reusability can be carried out.

These are a few things I put together that I could associate with the three Rs in testing today.

“That's one small blog for [a] tester, one giant leap for Quality Engineering”

By Tushar, Test Engineer III