Quality Assurance and Testing should never be an afterthought in project schedule. We present it here as your QA team will start testing the software as individual features are available for Show and Tell. Show and Tell, demonstrating features as early as possible in the development cycle, is essential in software development as users often don’t know what they want until they see it. This was the topic of our last entry. This week, let’s discuss QA and its impact to the schedule. The topic of QA in software development is massive and we won’t be delving too much into specifics.
Some items to consider for your schedule, specific to QA:
1. Test planning, setup, development, execution and reporting.
2. Bug submissions and reviews.
3. Development rework, retesting features.
4. Nightly/continuous build testing.
5. Release testing.
Let’s look each of these and their impact on the schedule.
1. Test planning, setup, development, execution and reporting. These tasks are analogous to development work. On the schedule you can add these tasks to specific features or feature groups. You may also develop a parallel sub-schedule that has dependencies on development milestones (I prefer this method as it makes the schedule cleaner). Similar to development tasks, you should get estimates from QA people (those doing the work), otherwise use some standard defaults. Often, there is a relationship to the amount of development work and the amount of QA work.
2. Bug submissions and reviews: bug submissions and reviews can be costly but they are necessary. QA and Developers need to submit bugs, meet and review them, prioritize the bugs and then schedule a new release of the product for testing and general release.
3. Development rework: Often this work needs to be scheduled after the original schedule is put in place. This is usually unpopular. You can model this by adding buffers to high risk task and then replace the buffers by specific tasks.
4. Build Testing: After bugs have been fixed, there is usually an automatic build triggered. Testing the software’s baseline functionality and testing for fixed bugs takes time. This is where automated testing can save some time but maybe not as much as you think. Bug fixes are notoriously hard to automate in some instances. It’s easier to automate testing when you’re testing a new block of functionality.
5. Release testing: This is testing of the final product to be shipped to customers. It takes a few tries. This may also be the first time that the quality of the release notes, documentation, and the proper position of files is evaluated. I usually estimate at least 3 tries at getting the final release image right.
It’s incredibly easy to underestimate the amount of QA work involved in the software development cycle. Treat it like a separate, dependent-on-development project and you won’t be too far off in your overall schedule estimates.
