Since most of my friends are actually not involved in the world of software development, when trying to describe what I do and how we do it, I tend to try and make comparisons to real life scenarios they can relate to. Today, I thought I’d share a wonderful example I stumbled across a little while ago;
The Crossword Effect by Clarke Ching (Clarke Ching’s Rocks And Snowballs)
Wish I had come up with that one myself….
Last week when I was looking for inspiration for my blog, a colleague suggested “Why don’t you write about QA?” The simple answer is, I hadn’t actually thought about it that much. Sure, I do my own share of Business Acceptance Testing, but I never really thought that much about how exactly our QA team have had to adapt, now that we are working in agile scrum as opposed to waterfall. I guess I was so busy with all the changes to my own process, I didn’t take the time to look around and see how exactly it impacts everybody else. It’s not that we forgot about Quality, naturally during the change process, it came up in meetings and planning sessions, I just never personally thought about how to best integrate the QA process.
At least until now. After my colleague suggested it, I spent some time talking to my colleagues who are currently on our QA team. Our testers are integrated in our scrum teams, as is usually the case and we use both manual and automated testing. Initially, it was challenging to adapt the process to test during the release, to write test scripts on the go and to avoid testing in silos. The team has made huge progress and is really getting some great results, finding defects much earlier in the process. There is still a bit of a culture of not wanting to find defects, then again that is inherent in the process rather than a symptom of the agile approach. If anything, the fact that business analysts, testers and developers are now on the same scrum team has helped in bridging the gap and reducing the “blame game” when it comes to finding and resolving defects. Being on the same team inspires greater collaboration and also greater confidence in each other.
Following the initial conversation, I did a little snooping around the web to see what other interesting thoughts are out there regarding Quality Assurance in agile, and came across this article on The Agile Warrior. It discusses the changing landscape within software development, changing from clearly defined roles of Analyst, Developer, Tester to more of a hybrid, where analysts also develop, developers also test and testers also analyze. No longer is it each man on their own island, the roles, responsibilities and skill set overlap and get intertwined. I wouldn’t say that we have reached a point where anybody can jump in and do any of the roles, certainly not in my organization, but it is an interesting thought, as knowing all areas of the process certainly would add value to any team and ultimately improve its Quality.