Page - 114 - in The Future of Software Quality Assurance

114 Z.Nikolova testsmanually ishardlypossible, especially ifweareaimingfor frequentandquick feedback and minimized waste of waiting time. Naturally, the paradigm of Agile testing involvesmovingfrommanual to automated testing. It is easier said thandone though,unfortunately.In reality,manyteamsare faced with a huge legacy of inherited code, written for over 10+years, and productively usedbyrealcustomers.Often, toautomate testing forsuchsystemsrequirescertain refactoring, which on the other hand is quite risky when unit tests are missing. It is a Catch 22 situation. Moreover, in some cases systems are written in proprietary languages (take SAP’s ABAP, for example) that lack properopen-source tools and infrastructure for test automation. Investing a big effort in automation might be a good idea froma purelyengineeringviewpoint,but it mightbe hard to justify from a return-on-investment perspective. Doesn’t it sound familiar? The constant fight between the teamandtheProductOwneronhowmuchweshall invest in removing technicaldebt! When planning our strategies for automated testing we need to consider a few aspects that might play a role in this decision-making exercise. First of all, it is important to acknowledge where our product is in terms of product lifecycle (Fig.2). The graphic represents the standard concept of product lifecycle with respect to its market penetration, applied to software products. In this context, there are slight differences as compared to physical products. First of all, with software products, especially following the ideas of the Lean startup and Agile business- oriented testing, we might see much earlier exposure to the market—already in the Conception and Creation phase. This means that we need to think about quality aspects quite early, as technical debt tends to build up in these early stages of software development and this leads to impediments in the growth stage. At the Fig. 2 Software product lifecycle