MAY 2019CIOAPPLICATIONS.COM9deferred until the next release. In Agile, an ideal Scrum team should consist of developers and testers, and story points should not be claimed unless the story has been developed and tested. However, in reality, teams often spend full sprint coding, and testing either happens on the last day of the sprint or gets pushed to the next sprint, which puts the testers one sprint behind the rest of the team. In several companies that I used to work at, there was a concept of "Done*" (Done Star), which meant that the story was completed but not tested. This concept allowed the Scrum team to claim the Story points and meet their Sprint commitments. Testing should be thoroughly embedded into the "Definition of Done" which includes unit, functional, integration and performance to address this undesired side effect of Agile. In addition, every sprint should allocate time for test automation without which regression testing in the Agile delivery model would not be possible. And finally, all members of the Scrum team should be willing and able to pick up testing activities in order to deliver on the team commitments.Technical Debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. It often arises from taking shortcuts on analysis and design and skipping on unit tests and test automation, in order to deliver software at a faster pace. In Agile, where stories are prioritized according to Business Value, technical debt related stories can often end up at the end of the backlog, below the Release line. One way to avoid this pitfall is to include refactoring, unit testing, and test automation as part of the Definition of Done. Another is to encourage the Scrum teams to allocate a significant buffer for each sprint to burning through the Technical Debt.Getting continuous feedback and having processes in place to act upon that feedback is critical to staying afloat and even on top of the Technical Debt. Monitoring KPIs such as Speed to Deployment vs. Bugs Missed, Defect Aging and Mean Time to Recover (MTTR), should provide a good indicator of how good the organization is getting with handling change and raise the alarm at the first sign of trouble. In addition to evolving the tools and processes, QA leadership needs to evolve as well to keep up and thrive in the world of Continuous Testing and Delivery. The key to success in leading cross-functional teams is acquiring the T-shaped skill set, where the vertical bar represents the deep expertise in quality management and leadership, while the horizontal bar depicts the ability to collaborate across areas such as Development, UX Design, Product and Marketing, among others. In addition, strong technical background and innovative thinking can elevate the leader to the next level of thought leadership and help to create a culture of respect, trust, and innovation within the organization.Charles Darwin once said, "It is not the strongest of the species that survive, nor the most intelligent, but the one most adaptable to change." The agile model did not just change the process of delivering quality software, but the very definition of what software means. Our goal as Technology professionals is while adapting to the change not to give in or compromise on Quality. After all, the first underlying principle of the agile manifesto is "to satisfy the customer through early and continuous delivery of VALUABLE software." Tanya Kravtsov
< Page 8 | Page 10 >