Tester involvement in Scrum planning and in Estimation
A tester on an Agile team should not just be doing testing after implementation, but should be actively involved all the way through development.
They can spot testability problems and other gaps from the very beginning, help the developers design the implementation with testability in mind, and define the tests before and during development to help the developers hit the right target.
As this is the case, the tester really needs to understand the whole story, not just the testing aspects.
Quality is the responsibility of an Agile team, not any one individual. Offloading quality tasks to Tester people is a handoff that decreases the responsibility as well as the agility of the team.
Offloading will not increase quality in the long run nearly as much has collaborating. These people should be integrated, which means they need to collaborate with the rest of the team on quality tasks as well as collaborate with the team on other tasks (including story pointing).
Two recommendations.
First, if someone is part of the team, then, yes, he should be part of planning and estimation. Don't worry too much about how he will do estimation, he'll figure it out. Since this is a new team, estimation will be challenging for everyone. Don't make a big deal about missed estimates, but do ensure that the team learns and can start to define some model stories to use as baselines.
Second, help the QA person develop a useful role on the team. One of the challenges is to move him away from purely using exploratory, non-repeatable testing (usually much closer to ad hoc testing) to doing mostly defined, repeatable testing. I would recommend that, one the very first day, the QA person pair with a developer and write some manual acceptance tests in Gherkin syntax ( https://github.com/cucumber/cucumber/wiki/Gherkin ). The QA person can then repeat with another developer. When something is ready to test, the QA person needs to focus on getting through the scripted tests first and only do exploratory testing if time permits.
Long term Goal
As the QA person becomes proficient in this style testing, the next step will be to allocate a developer to creating a cucumber-style framework for acceptance tests. This will cost one developer for several iterations to get the basic framework stood up. Be sure to rotate the effort, so that all the developers understand the framework as well as it will require periodic enhancements as the product being developed evolves.
In the long term, the QA person should be transforming from someone doing the secret art of manual testing to someone knowledgeable on various ways of how to do testing. When the developers run into a particularly dicey problem (and they will), the QA person can select some testing approaches that provide an attack vector for that problem.
They can spot testability problems and other gaps from the very beginning, help the developers design the implementation with testability in mind, and define the tests before and during development to help the developers hit the right target.
As this is the case, the tester really needs to understand the whole story, not just the testing aspects.
Quality is the responsibility of an Agile team, not any one individual. Offloading quality tasks to Tester people is a handoff that decreases the responsibility as well as the agility of the team.
Offloading will not increase quality in the long run nearly as much has collaborating. These people should be integrated, which means they need to collaborate with the rest of the team on quality tasks as well as collaborate with the team on other tasks (including story pointing).
Two recommendations.
First, if someone is part of the team, then, yes, he should be part of planning and estimation. Don't worry too much about how he will do estimation, he'll figure it out. Since this is a new team, estimation will be challenging for everyone. Don't make a big deal about missed estimates, but do ensure that the team learns and can start to define some model stories to use as baselines.
Second, help the QA person develop a useful role on the team. One of the challenges is to move him away from purely using exploratory, non-repeatable testing (usually much closer to ad hoc testing) to doing mostly defined, repeatable testing. I would recommend that, one the very first day, the QA person pair with a developer and write some manual acceptance tests in Gherkin syntax ( https://github.com/cucumber/cucumber/wiki/Gherkin ). The QA person can then repeat with another developer. When something is ready to test, the QA person needs to focus on getting through the scripted tests first and only do exploratory testing if time permits.
Long term Goal
As the QA person becomes proficient in this style testing, the next step will be to allocate a developer to creating a cucumber-style framework for acceptance tests. This will cost one developer for several iterations to get the basic framework stood up. Be sure to rotate the effort, so that all the developers understand the framework as well as it will require periodic enhancements as the product being developed evolves.
In the long term, the QA person should be transforming from someone doing the secret art of manual testing to someone knowledgeable on various ways of how to do testing. When the developers run into a particularly dicey problem (and they will), the QA person can select some testing approaches that provide an attack vector for that problem.
Comments
Post a Comment