Greetings. My name is Joachim Herschmann, and I am a Director of Product Management here at Borland located in Borland’s Linz office. I have over 15 years of experience in the software development and testing disciplines, and I am a certified ScrumMaster. I joined Borland in April 2006 through the acquisition of Segue, a leading testing solutions provider, and I am now responsible for Borland’s Lifecycle Quality Management (LQM) (aka testing) products.
When you are developing testing products you are in an interesting position. Not only are you building and evolving the products, but you use them internally on a daily basis as part of your development work! With Borland being in the midst of an Agile transformation, adapting testing to the Agile paradigm has become very important to us. So in my first few posts, I’d love to talk about some of the issues I find interesting and critical to evolving testing and QA for an Agile environment. After all it is quite a change coming from a traditional testing background.
This is the first post in a 3 part series on this topic, and I would like to kick it off by sharing a few observations about how people are affected by Agile's paradigm of team integration (QA and dev team members collaborating as one team) and the implications this has for skill sets. In future posts I’ll touch on testing tools, the increasing importance of test automation in Agile, and the process side of things -- highlighting the necessity for testing early and often.
So let’s talk about team integration.By that I mean the tight interlocking of testers and developers that the Agile approach requires –- e.g. pairing of developer/testing focused team members. I feel like this is quite possibly the most important issue related to testing in Agile, because it is a fundamental change in the way things have always been done. It requires a new, shared responsibility for quality by all team members and not just a dedicated (and separate) QA team.
Without a doubt there are a number of benefits that come with the integration of testers into a development team. Here in Linz, since we have integrated the members of what used to be a centralized “QA team” into our Scrum teams we have seen several of these benefits first-hand. Improved communication is an obvious one, since now our functional test scripts and code are developed in parallel based on the same requirements and changes.
Also, a combined team has an improved ability to meet quality objectives as everyone is now proactively responsible for quality. Our own teams have seen improved test coverage through test pairing and by sharing libraries of unit tests (test scripts created by developers) and functional tests (test scripts created by testers). It also takes us less effort to develop automated scripts and guarantee code-and-test coverage. Because our combined teams are able to isolate defects and quality issues earlier, we have also seen improved velocity since we integrated them.
But all of this doesn’t come for free. To make it work, it is necessary to expand the tester skill set. While the core responsibilities of QA -- identifying the most appropriate implementation approach, implementing, setting up and executing individual tests, logging outcomes, verifying test execution, analyzing and recovering from execution errors –- remain, there is also a need to adapt the traditional testing role to accommodate Agile development practices
Among other things, this means everyone needs to become a member of “the team” and the Dev/Test barrier gets removed. And, removing this barrier is much more than just changing organizational structure and seating arrangements. It’s most definitely a cultural change –- which means an investment in time and training.
To make it all work, it also becomes necessary for testers to develop programming skills –- that is part of the evolution of the tester’s role in an Agile environment. Testers need to get involved in test conception from the beginning. Many roles in software development have evolved over the years and Agile will certainly require testers to become more skilled as well. There are a number of ways this can be achieved and not all involve formal training or classes. For example, allowing the team members to invest a certain percentage of their time for self education and leveraging Agile best practices like pairing will provide team members who don't have a strong development background an opportunity to ramp up their skills.
In my next post, I will explore a more tool-focused topic and talk about the increased importance of test automation in Agile environments. Bye for now.