Incrimental Agile QA

An Article on how QA. Incremental QA is highly desirable in Scrum. Scrum does not distinguish between development and QA as in waterfall model. It expects that the product feature you are working on is designed, developed and tested by the end of a sprint – One sprint does it all.

This article touches on the background that all Development and QA should happen within the one sprint. I can relate to some of this article. I have found that by using scrum we in QA are involved in close communication with developers on how products are progressing through the Daily Scrum and being part of the team alongside the developers rather than being a separate entity as we were before. We communicate better with the developers, find out which areas of functionality are available for test and any areas require special attention.

By working as part of the team we are also able to start our automated tests earlier. We previously used QAWizard for this but we have progressed to selenium which is more efficient and better suits our needs.

 I would say that a lot of the good points that are highlighted within the article are evident in the way that we work as a team. See how much this relates to your team.

Incrimental Agile QA

Google Tech Talk. Agile Testing

Google Tech Talks
December 9, 2005

Elisabeth Hendrickson

As more teams are adopting Agile practices such as XP and Scrum, software testing teams are being asked to become “Agile” as well. But what does that mean? Is the Agile label yet another buzzword? Or could it be Agile practices are actually changing the way software is built? In this talk Elisabeth Hendrickson shares her perspective on how test teams can be more Agile based on her experiences working as a tester on Agile teams. Along the way, she’ll provide an overview of how Agile practices differ from traditional practices and discuss what those differences mean for independent test teams. Credits: Speaker:Elisabeth Hendrickson

Handling Bugs in an Agile Context

Handling Bugs in an Agile Context

This is an interesting article that was passed to me by a friend, thanks Mel!  The article is based around the handling of Bugs in Agile Development.  This has made me think about the way that my own team handle our Bugs.  As QA and Scrum Master for my Scrum Team i am always on the look out to improve my skills in QA.  Ill be taking some of the points contained in this article into account when performing QA on our team.

An important one is  “Done means implemented, tested, integrated, explored, and ready to ship or deploy. Done doesn’t just mean coded, Done means finished, complete, ready, polished."   This doesn’t only mean that the software works, looks good and performs the way it should, the software should be fully QA’d and known bugs fixed.

How to fit QA into Scrum

 I read an interesting article that addresses some of the problems that my own team has encountered with trying to fit QA into Scrum.  We have found that on some occasions coding new functionality for our site can take up a large part of the sprint, which can have a knock on effect on the time that QA has in the sprint.

We know that this isnt exacly the scrum way of doing things as we should be testing early in the iteration and leaving the testing till late on in the iteration can seem like a waterfall practice, but sometimes needs must.

The article below explains a process that my Scrum team has carried out.  We basically move our QA’ing of the stories into a separate story and have this prioritized in the next iteration thus allowing us to complete the QA without falling behind.

How to fit QA into Scrum

This also leads onto a future article on Automated testing in Scrum 🙂

How Scrum has improved our QA

I have worked at a web based startup company for the past 3 years.  Before we implemented Scrum just  under two years ago now, the QA team, of which I was a part of was a separate unit from all other teams.  We worked with the watrerfall method of development which meant we were involved in testing our functionality late on in the project.

One problem with this was that if the project was over running, then our QA time was cut and we had to work hard to make up the time lost in development by staying late on occasion.  This seems to be a common scenario with testing in the waterfall method.  Another scenario that I found was that the team became stuck in a rut with testing.  We became stuck in a rut of testing products in linear fashion that it felt as though every cycle was like groundhog day.

When we adopted Agile Development we had 4 main areas of expertise that were split into 4 main teams.  The ratio was around 1-5 (QA-Dev / Flash) and QA is part of the Scrum development team.  The Business side is driven by the Product team and our sprints are 2 weeks long.  This was the start of something new for our QA department.  Rather than being stuck at the end of the process, we were now included from the planning stage with Scrum.

We could now see the criteria being set down by the customer in the user stories that were provided to us by the Product Owner and any prototypes that were supplied. We now had an insight as to how the product should look and feel before the planning stage.

At first the planning stage was alien to us.  We had not been involved in any planning before with the waterfall method.  We had usually been given a product spec to write our test cases against before we were given the product to Test.  By the time we got our hands on the final product most of our tests were useless and had to be reworked. Being part of the planning stage felt as though we were now part of the team, rather than something stuck onto the end of a project to make peoples lives a misery.

Taking part in the planning meetings allowed us to gain a more in depth insight into what the product being developed would be expected to do.  Listening to both development sides to our teams plans on how they were going to code the functionality and how both Flash and .net would link together gave me an insight into any problems that may occur that could cause bugs in the code.   I would then be able to ask how I could go about testing these areas and include this in my test case.  This means that we are able to write our test cases earlier with the help of the User Stories and the developers.

Being part of the team during the development means that we are able to test earlier in the process. We have our own development environment which is updated regularly with new builds of the code base.  Once these new builds have been installed we set about testing them and raising bugs.  By testing against the criteria set down in the user stories and in our test cases earlier in the process, we can then find bugs early and have them fixed earlier thus meaning that we are not rushed off of our feet come the end of the iteration or the end of the project, had we been undertaking the waterfall method.  With this in mind QA can help in the process of “defining DONE” for each Sprint which helps to keep the project on track.

Overall I have found an improvement in our working practives by implimenting Scrum.  We have become part of a team rather than a seperate entity which helps us in our goal to try and have fully functioning software that is free of bugs.  Being involved in testing earlier in the project has helped break the ground hog day effect as with the nature of Sprints, we could be testing more than one product at the same time, so this can break down the boredom factor of working on the same product for a long time.  I have certainly found that our products have been going live with less bugs than before Scrum, so identifying these bugs earlier in the project has helped us.