Our dev team estimates work in hours, but we do not include any testing time in the original estimate. For example if the devs say an item will take 4 hours that will become our estimate for that item, but it might take an additional hour for our QA team to test. Do you add that hour to the original estimate of 4 hours making it 5 hours?
Please include as much detail in your answer instead of just saying yes or no.
Also, please don't suggest to use story points as this did not work for us.
The estimate for an item should cover how long it'll take to be done. Assuming what you define as done covers testing as well as development, then it should be in the original estimate.
The best way to ensure everything that needs to be covered to reach done goes into the estimate is to ensure everyone involved (eg the testers) are invited to the sprint planning meeting.
A quick counter question can probably answer this. "Would you deliver to the client after 4 hours of Dev?"
Since you can't deliver after just the dev work, QA's estimate has to be included to the original estimates.
As @David suggested, you should go for the Definition of Done which includes every activity needed to complete the job from initiation to delivery.
A few things to consider:
If the QA finds a bug then the developers have to fix it. Then it is likely the QA will need to re-test to confirm the bug is fixed. So simply saying that the QAs need 2 hours can be quite misleading. Testing impacts on both the developers and the QAs.
If your QA resource is limited and you want to estimate in time units then you need to consider not overloading or underloading the QAs. For example, saying you have 100 hours of development work and 100 hours of QA work only works if you have the same number of developers as QAs.
These complications are why a lot of people prefer to use story points. Story points are an estimate of the relative complexity of the story rather than the time you expect each discipline to spend on it (which is very difficult to guess correctly).
QA estimates must be included in the original estimates, because QA activities will also consume time and impact the project completion milestone.
Development estimates are for the development team, and QA estimates are for the SQA team. We include both development and testing time in the estimates, but separately.
If we merge them - - We cannot identify the estimates for development and QA separately. - We cannot compare the estimates with actual time taken for development and QA separately. - We cannot have separate milestone development complete and QA complete. - We cannot track development and SQA progress separately.
Development and QA are (mostly) done by separate teams, so it is better to separate them.
The estimate from the development team should include time to perform automated testing. In addition, time should be estimated for a release QA period. Additional resources should be accounted for in the release QA period for user experience testing.
My team has found this to be very helpful throughout multiple projects. The automated testing, generally completed through test-driven development, catches issues throughout the normal development cycle. Our User Experience Specialist performs release testing with test users during the release QA period to discover anything not caught in the automated testing.
Having designated release periods for user experience testing also frees up the development team to add polish to the application and incorporate learnings from the user testing that are within scope.
The simple answer is that the scope of the tasks should be made clear, e.g. code, unit test, test, QA etc and then you will know where to allow for testing and all other efforts in your estimates - and if coding is expecting to include an element of testing by the programmer, then this must be included in their estimates
We include testing that will be performed by our devs in our estimate (eg, writing tests for TDD, writing additional unit tests or feature tests for our nightly regression tests).
We also discuss the type of testing that will be performed by the QA team, and the likelihood that they will find problems that we will need to fix (which tracks with various types of complexity or cosmetics). We estimate the amount of additional dev time that will be required to support or iterate with the QA folks, and include that in our estimate.
It's often useful to discuss things from the perspective of the testers, since that may cause us to realize there is some additional complexity, and revise our original dev estimate.
It doesn't actually matter in normal sprint planning as long as you are consistent, i.e. using yesterday's weather (i.e. velocity) to plan, or if you do some sort of traditional capacity planning instead, then you would exclude the available test capacity if you also exclude test from the estimate.
If you are making an offer on a time & materials project or something, you probably do want to include test effort, unless know test costs are being covered with some buffer or something.
In my opinion, the key is to focus on the 'Definition of Done', mainly from the perspective of the Product Owner. Now the team (cross functional team to be more precise) may have some (or a lot of ) questions which needs to be hashed out between the team (remember I am not saying the Developer or Testers) and the PO, so that they have a common 'Definition of Done'. This is where the skills of an experienced Scrum Master come into picture. He/She can really orchestrate the discussion so that both of them find the common ground. Btw, the appropriate place for such a discussion is Sprint Planning meeting.
Quick answer: YES
Always factor ALL the effort your team will need to commit towards a story or piece of work, regardless of the estimation technique used. How you do testing, etc., should be a part of your Definition of Done, and your estimates should reflect that work.
Sorry for grammar/spelling I am on mobile -
