Page - 12 - in The Future of Software Quality Assurance

12 S. Amann and E. Jürgens Sinceourdeveloperoptedforamanualexploratorytest, thereisnoregressiontest for this particular functionality.However, since TGA is aware of the chronological order of changes and test coverage, it will again report a test gap should the functionality ever change in the future. Thanks to this safety net, it is reasonable toopt foraquickmanualcheck insteadofwritinganautomatedUI testoramanual test forcode that isunlikely to everchangeagain. 4.3 Closing theLoop At this point, our developer is satisfied with her changes and sends them to one of herpeersforcodereview.Oncesheandtherevieweragreethat thechangesarefine, he merges the feature branch. In response, our CI environment runs our entire test suite. This ensures that the main product line is error free, even if TIA should have mistakenly excluded a relevant test, and also records coverage and test execution times to keep our data up to date. Note that the vast majority of CI runs still benefits from TIA, since merging feature branches happens much less frequently thancommittingchanges to featurebranches. Before each Teamscale release (as of this writing, every 6 weeks) a test architect inspectsall remainingtestgapsonchangessince the last releaseacross the entire system.Thisprovidesuswith a secondqualitygate, to ensure thatnocritical functionalityaccidentallyslipped throughtesting. In thisprocess, thearchitectuses the same data that was used in the development process of the features, but on a treemap that represents the entire code instead of only the code changes for an individual feature. Figure 9 shows a section of this global test-gap treemap, representingoneofTeamscale’sUIcomponents. Fig. 9 Test-gapTreemapforaUIcomponentofTeamscale. Aglobalanalysisof remaining test gaps serves as an additional quality gate before a release