We will be using this document as an example of a test case template. This document is free to use.
Testing is a vital part of the project process. Whether handling regression testing, edge testing, functionality testing, or simple process/workflow testing a proper test case template can make all the difference.
The argument of who should create a test case document is a contentious one; one that we believe should fall on the business analyst, but really the onus should fall on whoever can handle it based on the setup of your particular project team.
The document that we are sharing has its roots in a project team that was still in its infancy. The important thing to remember is that the template is an ongoing thing. It should always be updated based on the needs of the testers. With that…
What’s Needed | The Header
There is certain pertinent information that should always be included in a test template. First, you want to include what the project is (plus an ID if you have one), who prepared the document, the PM, who is testing, the date, pass/fail, and a description of the work that was done.
When looking at our document, we include other information that may or may not be needed, depending on your needs. This includes priority, prerequisites, and assumptions.
Project Name and ID—The project name and ID should be something that is easily understood by anyone reading it. For our uses, we used the title of the project request form and the PRF number. The importance of this is to be able to quickly link this test case to the epic that was created for the project.
Preparer, PM, Tester—These individuals are important to call out because it allows outsiders to be able to know who to reach out to. If they have a question about who created the document, they can reach out to the preparer. Confused about where the overall project is so you can confirm if it is ready for testing, you can reach out to the PM. Have a question about the findings, reach out to the tester. These three sections tend to be forgotten in a lot of professional templates that are available online and shouldn’t ever be taken for granted, so we included them.
Date—This is a recent addition to the template, and comes out of a need to differentiate individual tests when they are utilizing the same test document. For example, if a user runs through the tests, and returns the document, but it is discovered that there was something that wasn’t quite right and needed to test the work again, you can determine which came first, and when specifically the work was done (for version control).
Pass/Fail—This should go without saying, really. You want to be able to see in the header if the overall tests passed or failed. For our case, we have a dropdown with the values of pass, fail, acceptable, and questionable. For the last two options, we include a notes section at the end of the template so that the tester can provide further information.
Description—For a tester, a detailed description of what is being done can be invaluable. User testers (as well as QA) will have a really good idea of how things fit together. If the tester can know what is being updated, they might know other things that might be affected, and therefore can be more aware of what to look for.
Priority—Testing can be overwhelming; especially when the tester is being inundated with multiple tests for multiple projects. Including a priority field can let them know what is the most important item to focus on. For some, QA might be involved with prioritization meetings, and already have an idea of what is the most important test, but having it documented somewhere can lessen the need for the tester to track this information down.
Prerequisites—This seems to be a bit controversial… strangely. Prerequisites cover anything that the tester will need in order to properly run a test. This might be access to the phone system, the ability to log into a piece of software as a particular user, or the ability to perform specific tasks. It’s been argued that whoever prepares the test case should already know who to reach out to that will cover all of these prerequisites, but it is extremely easy to potentially overlook things. Having this documented in the header can save a lot of time, by giving the tester an idea of what is required of them. If they don’t meet the prerequisites, then they can let the preparer know tout de suite.
Assumptions—Very closely related to prerequisites, but different enough that we created its own section. Assumptions tend to cover things that aren’t necessarily a prerequisite, but more that the preparer is assuming you can do. Things like knowledge of the new client workflow, knowledge of how to forward a call, knowledge of products offered, etc. Much like the prerequisites, assumptions can give the tester the ability to know if they can perform the test at the outset, allowing them to tell the preparer to find someone else.
What’s Needed | The Body
Ok, now to the test process.
First of all, you always always! want to number your test steps. We’ll talk a bit about how to number your test steps, and how to add alternative flows for the tests a bit later. Looking at the document, you will see that we split the regular workflow into its own table and the alternative flow into a second table.
Beyond the numbering scheme, we have the description. The description should include what is needed to be done. For example, “On the home page, click on the log-in button.” The description shouldn’t include what should happen though, only what the agent needs to do.
Next is the expected outcome (see why we didn’t include that shit in the description?). The expected outcome should include a short explanation of what should happen, should the step succeed. In our example, the expected outcome would include “the log-in window launches.”
Our updated template moved notes to the next section. This was in response to our user testers mentioning that it was annoying to be making notes, and then have to look back several columns to see what was being done, or what they were looking for. The notes section should include anything that is observed that might seem out of the ordinary. For example, the user might note that the log-in window launched, but the background turned fuchsia.
Next is the status of the test. This is where the tester can pull from the dropdown to select pass, fail, questionable, or N/A. We included questionable as an option because we realized that testing was frequently subjective. In our example, they might mark the fuchsia background as being questionable, rather than failing it outright.
Finally, we have the actual outcome. In our template, this will be auto-filled, depending on what is selected in the status box. If it passes, the expected outcome gets copied over, if any other option is selected then the notes are copied over. This is primarily for the BA/PM to be able to reference what the tester found, without requiring them to enter the same information twice.
Numbering
We use a standard numbering system. For our normal workflows, we utilize ascending numeric order (1-∞). We keep our standard tests numeric because it makes the numbering for the alt flows easier to be able to track. We’ll cover what alt flows are in the next section.
When numbering our alt-flows, we take the step that is being replaced, say step 5, and append a letter value to it (a, b, c, etc.). So, when reading, you will know that at step 5, you will also need to test this secondary workflow, 5A). It is understood that the alt-flow will typically have multiple steps to it, so we continue to utilize the letter A, as we go through each step (step 5A, 6A, 7A, 8A, etc.). If we have another alternative flow that needs to be tested for the same steps, we use the next letter (step 5B, 6B, 7B, etc).
Alternative Workflows
Sometimes called edge cases, corner cases, or secondary paths (I swear every PM has their own fucking term for this), alternative workflows focus on things that should also be tested, that stray from the typical workflow that would be seen.
The columns are the same as the regular workflow and function the same exact way. The key difference is going to be in the numbering of the values you have in the Alt Flow column.
Following our example, you might have the following values:
1A – Instead of clicking log-in, try to navigate to www.VV.com/agent_home
Expected outcome: Error message is displayed asking you to log-in
2A – Close the error message dialog and refresh the page
Expected outcome: Error message is displayed asking you to log-in
1B – Instead of clicking log-in, try to navigate to www.VV.com/acct_12345
Expected outcome: Error message is displayed asking you to log-in
2B – Close the error message and refresh the page
Expected outcome: Error message is displayed asking you to log-in
Alternative workflows aren’t necessarily needed for everything. Many BAs I’ve spoken with like to leave this to the QA team to fill in, as they will have a better idea of edge cases that need to be followed up on. While this is potentially true, I would argue that the individual that has gathered the requirements is going to know any concerns that the client has, and therefore, would be better equipped to create the alternative workflows.
What Now
Feel free to download this document and utilize it on your teams. Remember that this document is a final document. Templates should never be considered perfect or final, instead, always look to improve on the template, and add things that are vital for your organization to make the testing process easier. Some things that have been discussed with fellow PMs and BAs are:
Requesting Manager/Client – The individual who owns the project request.
Business Contact Person – The best person to contact when further information is needed.
Who to Submit To – Who should receive the updated copy of the document.
Important Email Addresses – This came up a lot, and there is definitely a case for it. Especially when potentially dealing with teams that exist outside of your organization, having the emails of important people in the document can make it easier for the testers to reach out to the appropriate people.
コメント