Page - 116 - in The Future of Software Quality Assurance

116 Z.Nikolova Fig. 4 Agile testing pyramid makingsurethatautomationispartof thestandardDefinitionofDoneandtheeffort isplannedaccordinglyby the teamin eachSprint. TheproductlifecycleandBCGmatrixofferamorebusiness-orientedviewonthe question of investment in automation. Now let’s look at the technical perspective. Mike Cohn’s testing pyramid [4] offers a nice visualization of the system layers where test automationshallbe considered,and to whatextent (Fig.4). In our traditional way of working, most of the testing is done manually, and it typically requires access through a UI layer. This means that testing happens quite late, and it requires significant development effort upfront, hence potentially a lot of defects piling up and being discovered quite late when rework is more costly. As discussed in the previous section, the focus is on finding bugs and product critique, and this is an expensiveway to address quality. No wonder that it is often compromised, especially when we are late with deadlines and there is pressure to deliver. Not to mention that manual testing is also muchslower, of course, and this makes thingsevenworse. In theAgileparadigm,weneedtoreversethepyramid,asshownontherightside of thepicture.Thebiggesteffort forautomationisdoneontheunit test level.This is whereongoingdevelopmentgetsimmediatefeedbackandbugsarequicklyremoved as part of the regular development process. On the next layer, we can automate acceptance tests based on cross-unit and cross-component functional calls within a certain use case or user story, but not necessarily involving the user interface. This integrationtestingisaperfectwaytoensureworkingincrementsduringsprints.The highest layer is testingend-to-endscenariosvia theUIof thesystem. Naturally, the cost of automation raises as we go up the pyramid—automating on the UI layer is typically resource consuming, and automated tests are hard to