Quality assurance and/or quality control is an integral part of the software development process. It ensures you conform to your requirements, meaning that you are delivering what your customer wants, and isn’t that what we are all striving toward in a nutshell?
Agile advocates test driven development or TDD, and many Agile or Scrum teams use it. But that’s a big topic on its own. I want to focus this post on how you portray testing or QA on your sprint backlog, whether it’s a TDD type activity, or manual testing or automation testing or any aspect of the testing lifecycle be it planning, design, execution, defect tracking, process improvement etc. These are tasks that you would typically have even on an Agile/Scrum team if you follow a modicum test management process. These need to be done for each story on your sprint backlog. E.g if your story is about creating a way to login to your system, or adding an item to a shopping cart, you still want to write high level and detailed testcases for each requirement pertaining to this story, then have a task for executing these testcases, have a task for defect logging if necessary etc. You will probably need tasks for setting up any initial conditions such as test environment or specific data setup. You will need tasks for obtaining approvals for your testcases, or following up on defects etc. You also might need tasks for other admin type activities such as setting up your test tools, assigning appropriate roles to team members, ensuring that your developers are set up right in the defect management systems so that you can assign your open bugs to them etc. etc. etc. The list is endless and you may do some or all of these depending on your organization, your team and the minimum artifacts you need to produce from an audit or compliance standpoint. I have not even touched on tasks relating to regression, integration etc.
Lets pause a second to take a deep breath. Does this seem like a lot of work? QA or testing almost always is. It takes a lot of due diligence to ensure sufficient test coverage and it’s the last step before you release your baby into the big bad world. So how do you portray all this on a sprint backlog? Create cards for each and every small thing, or just clump some things under a ‘miscellaneous’ heading?
This is what my experience has been. As you work on successive sprints, you start realizing the myriad small tasks or things that need to be done to reach the point of say, executing a testcase, and you gradually start creating separate tasks for them. This may appear to be overkill initially but it has its advantages. You increase visibility into what you do, and make the entire team aware of the nuances of a typical QA function. You make it easier for your team to understand your estimates – it is easier for everyone to follow several tasks that are 2-4 hours than having one number such as 20 hours or 40 hours that most will think you pulled out of your hat. This also builds greater understanding in everyone’s mind about the impact any changes to requirements or code will have on QA. So you get it – the advantages are manifold.
Getting down a bit further to brass tacks, I have generally had specific tasks such as designing and documenting testcases, executing them, adding defects as part of specific stories, and then I have a separate story I call the ‘QA story’. All my administrative tasks go here e.g. resource onboarding, tool setup, work requests, status calls, mentoring, knowledge transfers etc. etc.
One big advantage of this is that I already know what most of the tasks are going to be each sprint, and it makes it easier all around during part two of the sprint planning meeting. Each tester can focus on the stories they are going to work on, with only one or two ‘new’ tasks they may need for a specific story. This saves time being an almost repeatable process. Of course, it has taken me time and several different projects to come up with this.
What do you think of this post? How do you portray your QA tasks on your sprint backlog? Do you have different tasks each sprint, or do you feel that you are doing similar things for each story? I would love to know your views and experiences.
No comments:
Post a Comment