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.