Page - 118 - in The Future of Software Quality Assurance

118 Z.Nikolova we have the catalysts, they can initiate discussions in the Agile teams and create a baseline for starting the transformation. They will need to assess what they are alreadydoingandsuggestwhat wouldbe the next importantmilestoneor objective that the teamneeds to strive for in themidterm(thenext1year, forexample).From therebackwards, theycan thendefinereasonableobjectives for theshort term(let’s saynext3months).Here is anexampleofhowthismight look like. Objective: Enable automated testing for key integration scenarios in the newly developed modules of product XYZ withinQ1’2020 Key results: 80% coverage with unit tests for newly created classes; full coverage of priority 1 integration scenarios as defined by Product Owner This is a close-to-accuratequotationof an objective that we set in a team I used toworkwith.Theyweredevelopinganewadd-inproductontopofa legacysystem that did not offer a very favorable environment even for starting with unit testing. WhenwestartedtalkingaboutapplyingAgile testingconceptstonewdevelopment, the reaction of people was: “This is totally impossible. It would mean that we double or triple the development effort if we also have to write automated unit or integration tests.” Still, theywere somehowconvincedtogive it a try (thepain they felteachtimetheyhadto touchanythingin the legacywasastrongfactor inmaking them more open to experiment).We had to start small and check if we could make it happen at all at a reasonable cost. So, we started with new development only, focusing to cover new classes with unit tests, and key integration scenarios with service-level integration tests. We did not do automated UI testing at this point— manualUI-level testswere runasusual, just tocreateabaseline forus forchecking the effect of automated integration tests as well. It took several sprints before we could really feel the difference.However, in the moment when we started iterating onfeaturesdevelopedacoupleof sprintsearlierbasedon theuser feedbackthatwe got, thebenefitsofautomated integrations testsbecameveryobvious.Therewasno need to convinceanybodyanymore—developershappilyplanned tasks forcreating moreautomatedtests intheirsprintbacklog.Areleaselaterwestartedextendingour strategy to cover with automated unit and integration tests also those legacy parts thatwehadto touchandreworkaspartof thenewdevelopmentefforts.Essentially, we were doing continuous innovation, and it made sense to start investing also in covering theoldpieceswithgood testing. Along with setting objectives and measurable results, we also decided to experiment with techniques such as TDD (test-driven development). It was not an easy mindset shift for developers either, but over time they appreciated the added focus on simplicity that TDD drives. We could experience quality improvement in systemdesign,andgraduallyseeareductionofdefects thatwerediscoveredat later stages.Onthe levelofbusiness requirements,we introducedBDD(behavior-driven development) or “specification by example.” This was a great way to formulate requirements in a way that enabled straightforward creation of integration test cases as well. All of this eventually had a significant impact on both business- and technology-facing aspects of the product and was a good way to minimize