A few weeks ago, we organised a workshop in the company I’m working at for people outside the company with no experience in software testing but eager to learn about it. And what could I have spoken about? Test case design. I do believe in the importance of the test cases, but over the years I realised how boring it can be to write test cases. I tried not to minimise their importance, but also brought my view on what and when test cases should be used.

How did we reach the point asking us “do we still need test cases ?”

During the last year and a half we changed a lot our way of defining and writing test cases and we constantly migrated them from Confluence to excel, trying to find the best way of managing them, a way that suits us best. One day, we decided to give a try to Zephyr and did the setup and moved all our test cases again. You don’t want to imagine what this work meant!

We’re doing the testing based on the acceptance criteria and a big plus for us is that the acceptance criteria is very well defined for the product we’re working on. What we realised at some point was that we used to copy/paste the information from the acceptance criteria and put it into test cases and became very hard to have a filtered information of what is the core functionality. In most of the cases during testing we used to take the acceptance criteria, run the tests we though it would cover it, make the negative, exploratory, regression steps that we had in mind and that was it, we only went to the test case to update its status.

This is the way we ended up using the testing notes.

What are testing notes and how can you make use of them?

Testing notes are a simplified and reduced version of test cases, including:

  1. the happy paths that are not explicitly mentioned in the acceptance criteria;
  2. the negative tests, edge cases, test scenarios that are not included or covered by the acceptance criteria;
  3. test sample data.

Testing notes are added in the user story’s body, as a separate section after the acceptance criteria and we encourage the developers to take a look and review them before and during the user story implementation as it may contain some scenarios that need to be taken into account. In this way, we try to avoid having rejections on the user story when testing by keeping a good communication between QA and developer.

A big plus of using testing notes was that we reduced the time needed for writing the test cases by removing a big number of steps and preconditions known by the team members, we reduced the time needed to update the test cases when the requirements changes and we avoided having obsolete test cases.

Who can use the testing notes approach?

Well, the decision of replacing the test cases and introduce testing notes is context dependent and it is a sure thing that does not suit any project/team. If the stakeholders need to know exactly what was the testing activity, having reports including how many test cases were run, how many of them passed, how many failed and have all the test documentation, then definitely it is not going to be a good idea to propose the introduction of testing notes.

It also depends much on the size of the team, to be a small number of testers and all of them working on all areas of the application, the complexity of the product is being developed and the maturity and experience of the people working on the project. Also it is very important that the testers know well the business of their product and to be in permanent and good communication.

Let’s have an example

Given the following user story:

“As a Pinterest user I want an ability to delete a board that I own, so that I can free up my boards list. Edit function is available and when clicking to Edit, Delete Board option is present. Selecting the delete function will bring up a confirmation message and if Delete Board is pressed, the board is deleted.”

Here is how a testing notes section may look like:

  • check the number of boards decreases after deletion;
  • check the deleted boards can not be accessed anymore using its link;
  • check the total number of pins is updated after deleting the board;
  • create a new board having the same with the deleted one;

As said before, the list of testing notes contains test scenarios a tester can think of and which are not detailed or pointed by the user story.


This is a summary of my experience of replacing test cases with testing notes. Feel free to give it a try if your context is favourable and you can also take a look over a similar concept — “testing checklist”.


Photo credit: Photo by Christian Chen on Unsplash.