Seite - 112 - in The Future of Software Quality Assurance

112 Z.Nikolova responsible for testing, reporting problems, and making sure Definition of Done is satisfied with respect to quality standards. Imagine a situation: it’s the end of the sprint,most storiesarefinishedfromadevelopmentperspective,and theyare in the QAcolumnontheboard.Teams’QAexpertsareworkingaroundtheclocktomake sure they have checked new features thoroughly. Yet, at the Sprint demo they still cannot report full success—developersfinishedacoupleofmorestories in thefinal dayoftheSprint,andtheycouldn’tcompletetesting . . . Sprinthasnotbeenentirely successful, and it is a viciouscircle.Does it soundfamiliar? Unfortunately,I still see theabovesituationwaytoooften,eventhoughweclaim thatAgileapproachesarebynowmainstream.Believe itornot, thiswayofworking stands in the way of true Agile adoption in teams, and requiresa certain change of paradigms,so thatwe canbenefit fromAgile softwaredevelopment. 2 TheShift in TestingParadigms Situations like the one described above happen often when the switch to Agile practices focuses primarily on the question “what methodology shall we apply?” Do we want to do Scrum, Kanban, Scrumban, or something else? While I believe it is an important question, I do not think focusing too much on it really helps us understandandadoptAgilepractices.Frameworksandmethods,suchasScrumand Kanban,are there to support teamsachieveacertaingoal.So,defining thegoal, the purposeofapplyingAgilepractices, is thefirst thing to do. AccordingtothelatestStateofAgilereportfromVersionOne[1],amongthekey reasons foradoptingAgile are the need for faster developmentaswell as enhanced software quality. Yet, in many cases, creeping technical debt and a lot of rework prevail,partiallycausedbychangingrequirements,butalso, toanextent,bydefects foundlate indevelopment. Teams thatare successful inaddressingsuchchallengesapplya differentwayof thinkingabout testing,which is illustratedby theconceptofAgile testingquadrants [2] (or theAgile testing matrix [3]) (Fig.1). The quadrants imply several important aspects of a change in thinking about testing and quality in general. First of all, we shall not think of testing only as a means to discover bugs—this is a very reactive and limiting view on the quality process.Amuchmoreempoweringviewon testingsuggests that it has twofaces— one focused on product critique (finding functional bugs, unwanted behaviors, performance, security, and other nonfunctional flaws) and another focused on supporting the team to take the right decisions upfront, by doing frequent small tests onunit, component,and feature level (the left side of the matrix).This second aspect of testing is largely underutilized though, especially in teams that transition to Agile from other paradigms. Traditionally, we are used to testing for bugs, and this is the common profile for a quality expert. Eventually, we end up with a lot of back loops from testers to developers for fixing issues that can easily be prevented