Backtracking a bit from my original post,I thought I should cover the planning stage in Agile process and what QA should do in those stages.Different companies have different names for it,but I will give a short explanation of each planning stage
1)Vision
Def:What is the product’s vision for next 2 years(or a long term period,depending on product).Should be defined in a short 2-3 line statement(management speak:elevator pitch)
Normally this is conceptualized by executive management/product management.Sometimes defined in terms of persona.(For e.g product X is normally used by people with age 20-25.Next 2 years make it target people with age 20-30).This can be part of a standard business plan or company strategy plan.Regardless QA gets little to do here/or probably not much to say.But if you are lucky enough to be part of this,as a QA person this can serve as the long term vision for the quality goals of the product and have the testing processes/activities updated according to it.For e.g if the vision is to grow from tens of users to thousands of users,as a QA Manager it’s time to start making noise about getting appropriate hardware for this long term growth.
2)Release planning
Once the vision is defined and list of requirements listed down,the team starts doing release planning.Product management starts writing the wishlist in form of user stories.Engineering(Dev/QA/IT) starts estimating how much time is required for each story.If questions arises,new stories are added.QA should make sure following is done as part of release planning
- Start adding stories which are not defined for a product,but neverthless relevant to successful release(e.g automation/performance testing/migration etc).This way all necessary QA activities are correctly estimated for the release.
- Define Quality Goals for the product for this release.This can be defined in terms of severity of bugs etc.I will try to elaborate on this in a different post.
- Also tag stories which requires some kind of UI and screenshots will be helpful.Normally this is helpful to both Dev/QA,so either one can take a lead.QA can start writing better testcases if they have screenshots.Also it allows product management to visualize what they think and this helps in earlier detection of workflow issues,which UI component to choose etc.
- If there were stories that didn’t make it in previous release,but is important for quality/maintainability of the product,push for those stories to be included in this release
- If the product involves external hardware/software configuration(e.g OS or browsers),get the list narrowed down.Also be aware of yet unreleased OS/browser but available when product releases and ask product management of need to support it.Prospective customers also can define system requirements
At the end of this exercise,after couple of push/pull’s between product management and engineering management,we should have the following
- Release date
- Major milestones
- Resource Allocation(QA lead/manager can now start doing resource planning)
- Software/Hardware Matrix
- Quality Goals
- List of requirements to be finished for this release
Iteration Planning
Each release is divided typically into 2 or 3 weeks of iteration.Agile requires that and end of each iteration we should be able to release the product(but that’s hardly the case in practice),but regardless a good goal to keep in mind.Team gets together and starts pulling in stories from the backlog to be implemented in this iteration.QA needs to do following
- Each story should have estimates for unit testing,bug fixing,optimization.
- QA estimate should include writing testcases,executing testcases and bug verification
- Make sure engineering doesn’t go overboard with story allocation and QA should try to maintain balance between implementing too much with low quality and implementing little with high quality.This is where the initial quality goals come into the picture,we could also have iteration quality goals and adjust iteration planning if we are continuously missing the quality goals.
- As iteration progresses,and our initial estimate is wrong or we overshot ,bring this up in team meeting and have the story moved to next iteration or backlog.This is harder in practice as sometimes it’s hard for QA to explain why he/she feels that the story would not be completed and why it’s important to move it rather than keep it and think about it at end of iteration.
- For each story to be marked completed,all bugs related to it should be fixed(or with reference to iteration quality goals).Help developer achieve this through continous bug reviews(once in a week or twice a week) with product management/engineering management to whittle through “fix it now” vs “ok to fix later” bugs.
Next post,I will go in details about Quality Goals.
