Most teams kickoff their new iteration with a planning session. – where they discuss one story at a time, writing & estimating all of the tasks needed to implement it.
Task cards need to be written along with development task cards and estimated realistically.
When writing programming task cards, make sure that coding task estimates include time for writing unit tests and for all necessary testing by programmers.
Testers should help make sure that all necessary cards are written and they have reasonable estimates.
Your job as a tester is to make sure enough time is allocated to testing and to remind the team that testing & quality are the responsibility of the whole team. When the team decides how many stories they can deliver in an iteration, the question isn’t “How much coding can we finish?” but “How much coding and testing can we complete?”
Commit Conservatively – It is always better to bring in another story later than to drop a picked story.
Working closely with customers or customer proxies is one of the most important activities as an agile tester. Good communication usually takes work.
We want “big-picture” tests to help the programmers get started in the right direction on a story. High level tests should convey the main purpose behind the story.
Don’t forget to ask the programmers what they think you might have missed. What are the high-risk areas of the code? Where do they think testing should be focused?
When Testability is an issue, make it the team’s problem to solve.
One beneficial side-effect of reviewing the tests with programmers is the cross-learning that happens.
High level test cases along with executable tests you’ll write during the iteration will form the core of the application’s documentation.
People unfamiliar with agile development often have the misconception that there’s no documentation. In fact, agile projects produce usable documentation that contains executable tests and thus, is always up to date.
Testers in agile must be proactive. Instead of waiting for work to come to them, they get up and go look for ways to contribute.
Working on stories in advance of the iteration may be useful for teams that are split across different geographic locations. By working ahead, there’s time to get information to everyone and give them a chance to give their input.
If we make our iteration planning go faster and reduce the risk of the stories we’re going to undertake, it’s worth doing some research and brainstorming before we start the iteration.
The Pre-Planning Meeting
Go Over stories for the next iteration
The Product owner explains the purpose of each story – business conditions of satisfaction.
Team brainstorms about potential risks and dependencies, asks questions and figures out the simplest path.
Pull in customers to answer questions, get a better idea.
Experiment with short Pre-Iteration discussions and Test-Writing sessions
Invest preparation time when it’s appropriate. There is a risk to ‘working ahead’.
To go Fast – We need to Slow Down First!
Teams that are distributed in multiple locations may do their iteration planning by conference call, online meeting or teleconference. ( And Cut to 2020 – Coronian Times – Every one of us is doing that!! )
One practice that Lisa’s team used was to assign each team a subset of the upcoming stories and have them write task cards in advance.
(I, too, have used this practice – only the Task Cards were in fact story Sub-tasks being created in JIRA for our user story items created by the PO)
If the customers aren’t readily available to answer questions and make decisions, other domain experts who are accessible at all times should be empowered to guide the team by determining priorities and expressing desired system behavior with examples.
(I have experienced that – our Product Owners essentially did this job for us)
Examples are an effective way to learn about and illustrate desired functionality. Using Examples, you can write high level tests to flesh out the story a bit more.
Mock-ups are essential for stories involving UI or a report. Ask your customers to draw up their ideas about how the page should look.
Before the next iteration – triage the outstanding issues with the customer. Those deemed necessary should be scheduled into the next iteration.
When I first heard about risk-based testing, I interpreted it as an approach that could help devise a targeted test strategy. Back then I was working with a product-based research and development team. We were following Scrum and were perpetually working with tight deadlines. These short sprints had lots to test and deliver, in addition to the cross-environment and non-functional testing aspects.
Learning about risk-based testing gave me a new approach to our testing challenges. I believed that analyzing the product as well as each sprint for the impending risk areas and then following them through during test design and development, execution and reporting would help us in time crunches.
But before I could think about adopting this new found approach into our test planning, I had a challenge at hand: to convince my team.
In my recent article published at Gurock’s blog site , I have written about my experience on exploring risk based testing and convincing my agile team about its importance and relevance using their own sprints’ case study.
Using the analysis of a sprint’s user stories, calculating Risk Priority Number (RPN) and the Extent of Testing defined, I was able to showcase in my own team’s case study, ways our testing could benefit and better itself by following risk based approach in a simplified manner.