Quantity or Quality.

It seems the QA testing team is the one interested party in agile scrum that tends to get a little neglected. Nobody disputes the necessity or indeed the importance of testing the new code, however in my experience, our testing team have received the least amount of training and support to change to this new methodology.

In our project, we are very lucky in that the vast majority of our testers have been with us for many months, they are familiar with our application, have met some of our users and are therefore very well equipped in understanding what we need the system to do. Each of our scrum teams have their own QA resources that are involved in the discussions around each story. Of course, in agile, testing happens much sooner in the development cycle which has certainly helped us in mitigating risk before going to production.

However, I am personally not quite convinced that we haven’t shifted our focus ever so slightly away from the quality of our QA. It’s not that we are finding more defects now or that the team are putting in less effort to trouble shoot everything. But to me it seems that we have taken away some of the focus off QA, as it no longer functions in its own testing cycle. Where before, everybody on the project team was 100% focused on QA and bug fixing for several weeks, now that the process is built in the scrum cycle, it really is predominantly the testing team that are in charge of QA.

Is that a problem? Frankly, I am not quite sure… Based on our recent experience, I get the impression that there are ever so slightly more defects that we are surprised with when going to production. It’s not that we would have fixed every single defect prior to go-live previously, but I do think that we usually  found them beforehand and were able to mitigate that risk by communicating with our user community.

So, I do ask myself the question: Is the constant push for production ready code at the end of every sprint putting too much focus on quantity at the expense of quality?

Quality Q&A

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.