Software testing is undergoing a hard phase with constant focus on it’s value-creation within modern SDLC built on agile and DevOps, and software testers need to spend more and more time on building automated scripts.

Software testing changing is an understatement, and unfortunately, isn’t a lucrative career path for software engineers that have recently finished University. This is because the career of a software tester is not clear in the industry, unlike developers who have clearer roadmaps and lot of role models where programme directors, CIO’ and CTO’s from development backgrounds can help. While software testing as a discipline, it has limited growth provided within organisations and is kept at par with other technology functions, such as application support and project management offices (PMO).

Testers now measure quality and developers build quality. So, at what point of the modern software development lifecycle does the maturity point come? Is it when developers start to build first time right products? An additional pair of eyes in the form of testers are no longer required prior to production release, so have we just resigned to the fact that modern software architecture is so complicated and inter-twinned with other applications, so developers can’t build and check his/her own work comprehensively?

Reducing dependency

From a senior technology management perspective, utopia’s self-fulfilling teams are created (like scrums) and are assigned parts of a project, to build independently before the final product is integrated together and checked against acceptance criteria. If no issues are found, then the product is released to production. The question is, do these self-fulfilling teams need a business analyst, developer and QA (3 amigos model) or can true agile be reached when we do not need to label individuals in a team?

Software testing has had a good run for past 10-15 years, with large TCoE’s (Testing Center of Excellence) and large testing consulting organisations bagging big contracts for independent verification and validations. On average, 40% of project budgets are allocated for testing and organisations are spending more and more to train their test professionals on both their application domain, as well as test automation products to speed up testing. Like the elephant in the room, no one wants to accept that software can be built and managed without human concept, or at least for the need to reduce dependency.

Another challenge for software testing is: how can we effectively measure the ROI of large testing investment? Reduction of production incidents are often regarded as one of the many tools, but is the reduction due to increase issues found in QA cycle, or improve development processes for first-time ethos of developers?

Doom and gloom for testers?

Defects within a QA cycle is another measure to monitor effectiveness, but again, organisations rushing to embrace enterprise-wide agile methodologies and the agile gurus/coaches are preaching not to raise defects within sprint cycles; this can take away the camaraderie of developers and testers, and build walls between them. Focussing on the testing automation pyramid and pressure to build more BDD frameworks, QA members are now even less focussed on test execution and are asked to focus on building feature files in Gherkin; only which are then automated by developers in BDD frameworks and executed in the CI/CD pipeline.

The role of testers in an agile and DevOps world is often debated, and the argument comes back to testing vs checking. By using automated scripts or bots we can check and argue that we need tests to achieve end-to-end testing and exploratory testing. But, is this really true, or just an argument from testing professionals to fight back for its own existence?

So, is it all doom and gloom for software testing as a profession? Testing is now truly just an extension of build processes, which are ultimately developers’ accountability, as well as responsibility – they can no longer abdicate this responsibility to another team of testers like they have been doing.

Testers to tech risk analysts

First and foremost, software test professionals in this new world will not be called testers. Instead, they will need to think and act as technology risk analysts who manage technology risks. As soon as the job title changes from being a test analyst to risk analyst, the mindset will shift from checking to testing.

Technology organisation

The new age technology risk analyst will no longer be reporting to CIO’s, as technology organisations are heavily led by development and project delivery mindsets. Technology risk analysts will work alongside other risk professionals like operational risk, credit risk, market risk etc., and report to risk and compliance organisations.

‘Permit to develop’

New age technology risk analysts will no longer be required to constantly prove their worth or even produce test reports to highlight delivery risks, which often get ignored by programme managers. Instead, they will work alongside technology teams like audit and compliance members, and if they find any risks in production they can be empowered to stop the development process – if need be.

As you see from the points above, neither software testing as an engineering discipline nor software testing as a profession is diminishing or dying. Instead, it’s the mindset that needs to be changed.

Written by Sudeep Chatterjee, Head of QA – FX Horizontal at Bank Of America Merrill Lynch