Page - 119 - in The Future of Software Quality Assurance

Testing Strategies in an AgileContext 119 effort spent on documentation (such as requirements and test cases) by creating leanexecutablespecifications. Regarding UI testing, we intentionally limited the scope of automated testing. We researcheda few different tools to see howwe can automatepart of the tedious regressiontesting thatwasdonerepeatedlybeforeeachnewrelease.Ourexperience showed that tools tend to cover one of two scenarios. In the first scenario, tests are veryeasy to create by simply recording the manual test case, and then replaying it. However, if any of the screen components change (and this is often the case when usingcertaindevelopmentframeworks that rebuildcomponents,changingtheir IDs at each system build), theeffort to adapt them is quitehigh. In the secondscenario, tools allow for better componentization and identification of screen components, which makes initial effort high but leads to less difficult adaptation in case of changes. In our case, we picked a tool that supported the first scenario, and started automating only basic regression tests on critical user journeys to make sure we can quickly cover high-priority testing needs. In addition to that, we engaged in much more Quadrant 2 testing using low- and high-fidelity prototypes to run early tests with real users. This reduced significantly the need to rework UIs later in development,andminimizedthe effort toupdateUI tests aswell. TheexampleIshared,incombinationwiththeconceptsdiscussedintheprevious sections, might give you a few ideas as to how to start applying some of the Agile testing concepts. When you map your own transformation strategy, however, write it down, start measuring against the KPIs you have defined, inspect, and adapt on a regular basis to make sure that your goals are achievable and you are getting the results that youexpect. 5 ThePeoplePerspective Finally, Iwould like todrawattention toanother importantaspectaswell—creating the appropriate environment for teams and individuals to feel safe in the transition and to effectively achieve an Agile mindset shift. No matter what type of change you are undertaking, having people on board, feeling appreciated and valued, and engagingthemin theprocess is amongthe keyfactors to success. This perspective is a complex one as well. First of all, let’s look at teams as a whole. As we discussed in the beginning, in an Agile context quality is a team responsibility. This means that we need to support the building of this collective ownership by coaching teams into self-organization and focus on common results rather than individual achievements. It might require changing the entire performance management approach that we apply in the organization, switching from individual to team goals and product-related metrics—and many Agile organizations do that. We might also need to rethink the KPIs that we use. I was recently discussing the topic of Agile testing with a quality engineer, and he sharedthat theirworkisbeingevaluatedbythenumberofbugsfound.Whatkindof behaviorsand thinkingdoesaKPI like that support?What wouldbe themotivation