When to Write Test Cases

Among the many tasks that QA engineers perform, test planning and the writing of test cases should be given high priority for QA teams. Due to how crucial test cases are to the whole testing process, choosing the optimum time for when to write test cases is also very important. In this post, we will look at how to determine the best point in the development cycle to write your test cases.

Requirements and Development

There are two points in the software development process that you should use to determine the best time to write test cases.

• Requirements If you create test cases before requirements are ready, the test case writing process will take longer and be inefficient , because you will end up writing test cases for scenarios that will ultimately be abandoned or changed dramatically. Having to maintain test cases before they have even been executed is energy better spent elsewhere. It’s best to wait until the requirements are as complete as possible before beginning.
• Development The second time span to look at is when development is scheduled to begin and end. You may want to write test cases before the start of development, but I’ll explain below why writing the test cases during the development phase can provide added team benefits.

Writing Tests within Agile Sprints

When an iterative approach is being applied to software development and work is contained in “sprints”, the definition of tasks performed for the sprint tasks might include writing test cases for each task in the sprint. Some teams may choose to use separate tasks for creating tests and executing tests, so if this is the case, test cases may be written in one sprint and then tested in another. With this iterative approach, it would likely make the most sense to write the test cases for tasks that are also being developed in that sprint.

Write Test Cases in Parallel to Development

Writing tests in parallel to the development of the task enhances team collaboration, and here’s why. Before starting work on a requirement, developers and quality assurance will ask questions to identify dependencies in preparation for the work. At this point, QA is brainstorming test cases to write and developers are laying out a plan for implementation. There are still some unknowns at this point.

When the actual work starts, more questions come up. Some scenarios may need clarification, or the UI might need to be adjusted and the requirements updated. If QA and development are coding and writing test cases in parallel, the changes can be addressed in real-time when team members can discuss the changes while they work on them.

What about Estimates?

Most development cycles are likely to involve providing estimates at some stage. Developers and QA estimate the story points ,or the time needed to develop and test the work. You might find it difficult to accurately estimate the time required to execute test cases if they haven’t been written yet.

If estimates are required before completing test cases, a high-level set of test cases should be created. Because estimates are done before the work is started, a high-level estimate of story points should be provided based on the details known at the time. Some teams may want to estimate the test case writing and the test case execution tasks separately.

Don’t Forget Reviews

Having test cases reviewed by your QA peers, developers or production may be a regular part of the process. Be sure to account for this when deciding on your schedule.

Don’t Delay

Writing test cases should be at the top of every team’s QA priority list. Even so, creating test cases can often get delayed. Sometimes it’s regression for a release or a production issue that takes center stage, derailing your well laid out plans. While the best time to start writing test cases coincides with development milestones, it’s also good to note that getting started early is better than starting late. Kicking off early may result in some cases being thrown away (due to requirement changes,) but it may also lead to early discoveries that could change the scope of the project. These discoveries (such as a gap in the requirements) will benefit the team in the long run.

Test Case Maintenance

How about test case maintenance? Should maintaining test cases be scheduled for a certain time? The answer to maintenance is simple; do it immediately. Test case management as part of an agile development process can require a lot of maintenance because of ever-evolving requirements. One of the worst scenarios for a QA team is having a bunch of obsolete or invalid test cases. Aim to update or delete invalid test cases before they get away from you. When the time comes for regression testing the work or selecting test cases from a test suite, they should be accurate. If it can’t be done right away, create a task and put it at the top of your backlog. Test case maintenance should be quick and painless if it is handled as soon as the information becomes available. Wait too long with this and your test case repository will become a mess in no time.

Conclusion

While every team may follow a different sequence of events, the completion of requirements and the start of development are key milestones for a lot of QA planning. Use these elements for gauging the best time to initiate test case writing. Start too early and you’ll likely spend extra time revising the test cases. Start too late and you could end up creating an unnecessary bottleneck. The sweet spot is the period when the product owner, development team, and QA team can best collaborate to identify the scope of work.