Test Case Sources – 6 Test Case Resources

We all aim to write great test cases built from well thought-out requirements or user stories. Working independently or as part of a testing team, the ambition is to send vital feedback to the developers so eventually, everyone can take pride in a great, well functioning new product.

But have you ever thought about moving outside your comfort zone to improve your test cases? This article suggests a few layers of inspiration that could help you to write more meaningful test cases with greater test coverage, to give you the leading edge.

People and Procedures are Valuable Resources

Requirements

Usually, the best place to start when creating test cases from scratch is with requirements and user stories. It can be useful if the person creating the test cases is part of the requirements process at some stage and at the very minimum, the QA engineer should have the opportunity to participate in a requirement review process. It’s also an ideal time for QA to ask questions and take notes about future scenarios and use the opportunity to point out any additional information the team might need for understanding the overall concept. Depending on how your team feels about scheduled meetings, this could happen with the team in attendance or online. It’s worth remembering that each step of this process should not take up too much time. We don’t want discussions to impede progress, although it is vital that any queries are resolved as early as possible in the process.

Once solid requirements are in place, QA can start drafting test cases. Requirements or user stories should have acceptance criteria that will give QA a basic set of tests. From there, QA can consider other scenarios to test, such as negative cases, edge cases, etc.

Wireframes

Typically, a UI design will start with wireframe layouts that can show the desired flow of the application. These are a great resource for writing tests to ensure the application behaves as it should. Does each button take the user to the correct screen shown in the flow? Do the back buttons go back to the correct location? How many times must a user press back to get home? It is surprisingly common to miss an app skipping a screen in the flow, either back or forward.Writing these tests is quick and easy and won’t often need to be done, but they could be a great resource if you choose to automate the tests in the future.

Developers

Both the development and the QA team should already be working closely together during the process because it’s QA testing their software and reporting bugs for them to fix. The relationship needs to be close and, in fact, a lot of organization already include QA members in their individual development teams. The point is this, QA should communicate early and often. Developers might cringe when reading this, thinking of it as an interruption from coding, but when it saves the developer time in the future by preventing bugs, they will know it’s well worth the time. To alleviate constant interruptions, it’s always best for QA to document questions and come back to the developer at a predetermined time if necessary.

Once QA has compiled a set of test cases they believe to be complete, it is then time to go over these with the developers. QA doesn’t necessarily need to ask the developers to read over the tests, but even a verbal summary of what they plan to test could be of massive benefit. First, the test cases that QA have documented may bring up a scenario the developer didn’t anticipate. At the same time, the developers might see a gap in your tests and so, point this out. It’s a win-win. This is why we have a team and ask for an extra set of eyes. This entire “meeting” may not take more than 10-20 minutes but could be extremely valuable to the overall project.

When conducting these informal reviews, remember to include at least one client representative and one from the service developer. Involving both client and service development sides in the meeting might even launch a conversation between the developers that they didn’t realize needed to happen.

Product Owners/Business Analysts

In many organizations, it is standard procedure to have the product owner or the business analyst (the individual charged with creating requirements or user stories), review and approve the test cases. Typically, there will be questions from QA before, during and after the requirements are complete. Because requirements are the #1 source for the development team, it is important that they are scrutinized. For QA, this evaluation of the requirements should happen when authoring test cases but inevitably, there will be questions from QA and developers during the test execution phase. But, any measures taken to have these questions resolved early can prevent major re-work late in the process. Late re-work usually means a delay in delivery or necessitates another round of testing late in the process. (Another potential cause of delay.)

QA Teammates

This might seems like a no-brainer, but getting a test case review from a QA teammate is never a bad idea. A bit like a code-review in that it provides a second set of eyes on your work. In some organizations, a senior level QA engineer might review the cases for the rest of the team. Early in my testing career, I reviewed test cases written by my senior peers to gain insight into how they did their work. No matter the level of experience, a peer test case review is beneficial to both the author and the reviewer.

Collaboration

You (QA) are the expert, and it is your responsibility to first document and execute the tests. Asking questions and discussing the product with teammates reminds us why working as a team is so important. From a quality perspective, it helps us to keep in mind that the quality of the product is dependent on everyone on the team. To take it a step further, a quality product that is delivered in a timely manner requires collaboration early and often. Questions not asked near the beginning of the process can lead to re-work later in the development cycle which is likely to make the project more expensive.

Conclusion

Quality software is the result of a team effort. By including the team in the test case development process, individuals outside of QA are reminded of this fact. When a bug is missed, everyone involved will know that they are a part of the process. Going forward, it can help focus a developer’s attention, probably jogging their memory, to test in a certain scenario before delivering to QA. It can even help the product owner the next time they are creating requirements or user stories. After all is said and done, the goal is to release a quality product with few bugs. When this happens, the entire team can take credit for the success or alternately, accept responsibility for any failure.