In Part 1 of this series, we looked at how important it is to have documentation of what you expect your system to do and the value of making a plan. Now we want to take a closer look at writing the test cases, themselves.

Lesson #3: Write Test Cases

Test PlanDon’t have a specialized testing application? That’s okay, you don’t need one. Create a spreadsheet and add 5 columns: Step #, Description, Expected Result, Actual Result, Pass/Fail. Congratulations, you now have a test case template! You will want to create a separate document for each test case you plan on executing. Make sure your test cases are separated out into manageable chunks. Don’t try to cram everything into one document. This will enable you to delegate test cases to different people and speed up your testing execution.

Start with the first item in your test plan, and document the steps of a successful scenario. Some details to think through for your scenario’s test plan are:

  • Entering all required data as it should be entered
  • Submitting through each page as you would expect
  • Looking for emails that should be generated
  • Verifying security groups are added
  • Imagining everything an end-user could be expected to do

Then, look at the negative test cases -- add steps to skip required information, enter invalid information, click next and then go backwards, etc. Remember that when testing web-based applications, users should be expected to use different browsers, and you should incorporate this into your testing.

At the end of each test case, review what you have completed in order to determine the next logical step. For example, if your case walks through how to create a new user in the system, once you’ve completed the process, you will want to try logging in with the new user to confirm it was created correctly. Perhaps you will want to use that new user to test the change access workflows that are in place; and of course at the end, you will want to try out that termination workflow you have in place.

When considering the next steps, you may want to make edits to your current test case to specify the creation of 3 separate users, or 2 employees and 2 non-employees, etc. These variations will differ depending on your environment and how you’re planning to use your solution.

Don’t forget to get the input of your development team as well; they will be able to point out some valuable areas that you will want to incorporate into your testing. For example, when testing account provisioning, make sure you include any closed-loop systems in your requests as well any target systems you may have set to automatically provision.

That’s a lot of work to get a proper test plan together, but as you can see it’s well worth the effort!

In Part 3, we’ll look more into executing your test cases.

 

SCUID Operations Data Sheet

Bryan Cole

Bryan Cole