How Do You Write A High-Quality Manual Test Case that even your Grandparent can run?

By
How to Write a Manual Test Case - Photo by Negative Space

If your dear Grandparents are already in the Software Testing profession and know how to write test cases then this article might not be for you.

If however you are looking of a way to create clear, concise and easy to follow manual test cases so that anyone in your team can run them then read on.

Ideally this is for QA/test teams, however anyone who is involved in any kind of software testing can benefit from this.

So here’s the deal.

As a Test Manager, I want to make sure that we have a good set of regression suites available or at least have good quality manual test cases.

Not a lot to ask for is it?

Have you ever found yourself in situations where you’ve had to run existing test cases but find that they just aren’t up to the mark?

In fact, its probably more effort in working out what they mean as opposed to just executing them?

One of my biggest embarrassments is when you have to send out test cases to wider stakeholders for review and the quality is so poor, you just want to a hole to open up in the ground and vanish.

Me too!

OR do you just need help with test case writing best practice?

Table of Contents

Why am I writing this article?

I’m hoping that with the use of some best practice techniques, this article will help you write very high quality test cases step by step.

I’m absolutely sick and tired of the number of times I’ve tried to make sense of inherited test cases that don’t make sense.

I’m tired of expecting a high quality test pack which has low quality test scripts.

I’ve had enough of Project Managers constantly standing over my shoulder telling me that we “should” have a regression pack we can run…..but we can’t because the quality is so low!

I’m annoyed at Test Analysts not following any kind of best practice and churning out low quality just to hit a deadline.

I’m tired of being embarrassed by other teams that look at a test Teams as being a ‘quality’ function, but in reality, we aren’t able to achieve the quality bar I expect.

What is a Test Case in Software Testing

To avoid any confusion, let’s use this opportunity to clarify some terminology and concepts.

Test cases and test scripts are used interchangeably in many organisations.  I’m also guilty of this too.

A Test Case in Software Testing is a series of steps that confirm whether requirements have been met for an application.  Steps consist of an input and output (expected result).  Each requirement can consist of numerous conditions.

More detail on how a Test case looks like will be described below.

Why are Test Cases important in Software Testing?

Test cases are incredibly important.

For those of you that design them already, you’ll know that they can be very time consuming.

There are many benefits to writing test cases, which include;

  • Identify coverage early on including any gaps
  • Figuring out the complexity of the test.  This can include things like data setup.
  • Finding any ambiguous requirements and getting them clarified as early as possible.  This will also help you write better quality tests. 
  • Providing long term reusable test cases as part of a regression suite.
  • Less effort for colleagues who wish to run the test cases in the future.

Advantages and Disadvantages of writing High Quality Manual Test Cases

As always there are both advantages and disadvantages to writing test cases using this approach.

Pros

  • The majority if not all of the hard work has been done for you.  It should be as easy as running the steps and capturing the evidence or raising defects.
  • Little initial knowledge is required when running the test cases.  However, you should ALWAYS obtain domain knowledge.
  • Detailed coverage means higher quality testing and finding better quality defects.
  • You can write tests at a very granular level to ensure many different angles of the requirement have been covered. 
  • Can be used as part of a regression pack

Cons

  • Writing high-quality test cases can be very time consuming
  • Most work is carried out up-front so there is effort involved. 
  • Writing test cases usually requires a learning curve.  This can be small or large depending on the application.

Before you write your Test Case – Preparation

Gather your requirements documentation in order

Before you start writing any test cases, you’ll need specifications or requirements. 

Without requirements, your test cases will be a bit of a non-starter and you’ll struggle to proceed.

The collection of all these requirements documentation is called the “Test Basis”.

The Test basis can be in the form of Business Requirements, Functional/Non-Functional specifications, High Level Design documents and so on.

Your test design is only as good as the requirements you have.

Granted that sometimes we can work miracles. 😊

However, I prefer we use a more structured black box testing approach.

Once you have these, I usually put all requirements into a Requirements Traceability Matrix (RTM).  

That is the basis of my coverage.

Anyway, I digress. 

What I’m trying to say is;

Make sure you have a golden source of your coverage.  The RTM is perfect for this.  I’ll discuss the Requirements Traceability Matrix in another article.

So, now that we’ve got that addressed let’s move on.

Test Artefacts You’ll Need

Create a Requirements Traceability Matrix

I won’t go into how you create a RTM. 

That’s an article for another day.

However if you were on MY team, you would absolutely be required to create one before your test design work begins.

I’ve found that having this from the outset REALLY helps in the long term.

The RTM will seriously cover your butt so make sure you have one.

You will know exactly what you’ve covered and be able to identify any outstanding gaps.

Good Quality Test Case Template

You’ll need a good quality test case template that you can literally use.

It doesn’t have to be overly detailed or complicated, it just needs to have the main fields present.

More on this below.

Keep reading.

My Test Design Approach

My approach to most things in life is;

“If you’re going to do something, then do it properly, otherwise don’t do it all”

Unknown

There are plenty of different versions of this quote and I don’t claim this to be mine. 

When you work in the Software testing industry, this becomes even more true since you are a quality based function.

Quality is the name of the game!

Everything you do is about exceptional quality.  Good quality just isn’t enough.

Stakeholders, end users and teams rely and expect you to ensure the software they will use is of high quality. 

This means as testers we need to find defects that other teams will not.

Not only defects but you are expected to ensure high quality coverage of what you are testing.

So, when it comes to designing test cases, I like to go the extra mile.

I like to design them step by step to the minute detail.

I write them to the level where all the hard work (design) is already done so the person executing the test case doesn’t have to even think about what they are executing….well sort of!

This demonstrates that the person writing the test has an in depth knowledge of the application and has used some flair and creativity to create their tests.

Here’s an experiment for you to try.

  1. Write a test case with a number of steps.
  2. Give it to someone in your team or organisation who has no knowledge of the application under test.
  3. Ask them to run the testcase without any help from you.
  4. Can they run the entire test case from start to finish without stopping, asking how to do something or if something is unclear?

In most cases they won’t be able to do it.

**cue mission impossible music**

Your job….should you choose to accept, is to create a test case that can be run seamlessly from start to finish by an end user without interruption!

So how do you create test cases like this?

Good question.

Read on

A good template will mean that the most common fields are ready for you to fill out. 

This will help you be more efficient with time.

You won’t need to spend too much time thinking about what you’ve missed.

You can work in a more methodical and systematic fashion.

Make a Mental Note of Key Areas of the Software Application

One of the things I like to do is to familiarise myself with the application under test (AUT) from a very high level.

This gives me an idea of key areas of functionality.

It allows me to then make a mental note of key flows.

Once I have this understanding, I can create some very high level test scenarios from which I can create test cases and group requirements together.

How to actually write Manual Test Cases Using an Excel Sheet – Step by Step

The basic skeleton structure of a test case

There is no “one size fits all” when it comes to writing test cases. 

However, there are some absolute minimum pieces of information you should include. 

They have been highlighted in blue.

I like to tweak my test cases to fit the organisation I am working for. 

This means following their governance processes, ways of working but still adhering to testing best practices.

My typical test case template would consist of the following columns in a Spreadsheet.

Note: A lot of these are optional and you should only use those that you need.  There is no point in overcomplicating things.

Agree?

I’ve added them to give you an idea of how you expand and customise where necessary.

Components of a Test Case

Below are the fields you should include as part of your Test Case Template design. 

  1. Test case ID (mandatory)
  2. Test Case Title (mandatory)
  3. Test Case Description (mandatory)
  4. Requirement ID
  5. Pre conditions (mandatory)
  6. Test Step (Input) – (mandatory)
  7. Expected Result (Output) – (mandatory)
  8. Actual Result (mandatory)
  9. Execution Status (optional)
  10. Open Issues (optional)
  11. Closed Issues (optional)
  12. Defect ID (optional)
  13. Post condition (mandatory)
  14. Data Setup (optional)
  15. Access Required (optional)
  16. Support Required (optional)
  17. Date Started (optional)
  18. Date Completed (optional)
  19. Testing Environment (optional)
  20. Application Name (optional)
  21. Release/Build Version (optional)
  22. Estimated Execution Time (optional)
  23. Comments/Notes (optional)

Populating Your Test Case Template

Test case ID (mandatory)

  • Your naming convention should be something that conforms to your organisation.  If you do not have one then use some common sense here.  For example TC + + .
    • TC-SAP-INVOICE-SYSTEM-0001   

Test Case Title (mandatory)

  • This is your ‘one liner’.  I’m not referring to a witty “come back” or a joke but a sentence which gives a very concise and accurate overview of your test case.
  • Think of the title as the ‘purpose’ or ‘what’ you are trying to test.
  • The title MUST be meaningful and be relevant to what you are testing.
  • Have a clear unambiguous test case title
  • You HAVE to understand what you’re testing and so it’s important to ensure a clear and concise title.
  • Another way to think about it is “WHAT”, I testing?

You’d be surprised how many test case titles I’ve read which were totally irrelevant.

After you have completed the description below, revisit the title and ask yourself if it summarises the key points you are trying to test.

Test Case Description (mandatory)

The description is very important.

You should elaborate on the title written above.

You could cover the high level flow or User journey here.

This is also very useful if your test cases get reviewed/approved by other stakeholders.

I use this to give a high level overview of the coverage for my stakeholders so they know what we’re testing.

The description alongside the title is a really good way for your stakeholders to review the coverage of your test without needing to read each test step.

So for example,

Don’t make this section detailed like test steps but don’t make it vague either.

  • This should be a description of ‘how’ you will test your application.
    • Include Purpose of test
    • Understand and Include High level journey/flow
    • I sometimes also add the requirement ID at the end of each flow.

Requirement ID

Each test step should map back to a requirement ID in your RTM.

This is of paramount importance as it will then allow you and your stakeholders to gauge your test coverage.

Don’t forget to update your RTM with the relevant Testcase ID.  I’ll cover that on a separate article.

  • I haven’t put this as a mandatory field as the ISTQB framework states it isn’t, however, I think it should always be included where you have requirements.
  • This can be a requirement from your RTM or directly from your specification documents.
  • If you don’t have a requirement to test against then what are you testing?

Pre conditions (mandatory)

  • Any dependencies for this step need to be entered here.
    • For example, do  you have to run a specific test case before you run the current one.

Test Step (Input) – (mandatory)

Make your test steps as granular and as detailed as possible.

For example each step should have an action.  Do not group steps and outputs together as one.

This will allow you to prove each step and also identify where potential issues are.

  • A single action a user takes.
  • So for example, ‘User selects the username field’.

Expected Result (Output) – (mandatory)

This should be the expected action as a result of the input. 

Don’t skip the details here.

For example, which URL is the user expected to land on?

What page elements/fields is a user expected to see?

Is some business logic supposed to be processed to give an answer?

It’s REALLY important to include all these here. 

  • Each input should have a corresponding output.  This Allows a very  granular Level of Test coverage and allows detailed issues to be found.
  • Here you will need to present this aesthetically well.  Please try and ensure that your output step aligns up with your inspiration step. 
  • It’s always the little things!

Actual Result (mandatory)

  • This is for the test execution stage.  We won’t cover this here.  Just ensure you include this either against each step or as an overall result for the test.  I prefer to do both.

Execution Status (optional)

  • Ideally this should be filled out, like a drop down with values like; “Not Started”, “In Progress”, “Passed”, “Failed”, “Blocked”, “Invalid”, “Out of Scope”.
  • You can add a few more but I think this is sufficient.
  • Don’t overcomplicate this.

Open Issues (optional)

  • Open Issues are current defects of tickets open.  Include the relevant ticket number here.

Closed Issues (optional)

  • Take the value from above and populate this field when the issue has been closed.

Defect ID (optional)

  • Any defects raised should be captured here.
  • All defects should be captured in your defect tracking tool or spreadsheet.

Post Condition (mandatory)

  • This column must be included in your template.
  • However, you do not need to fill this out for every step.  Use it as and when required.

Data Setup (optional)

  • This one is REALLY important.  Especially from a continuity and knowledge transfer perspective.  This field allows you to tell the test analyst HOW to get the data in the right state in order to run the test.
  • This might be the actual values you will be entering into the system or a summary of how you should setup the data.
  • However you do it, this section is very important and I have found that it has saved me tons of time and headache.

Access Required (optional)

  • This tells the Analyst what system access they will require.
  • Include as much detail as you need.  For example, a specific user profile, permissions etc. 
  • Also include any lead time that is required to get this setup if you have historical data.

Support Required (optional)

  • I add this when I want to know which wider stakeholders or teams need to be engaged as part of the test.
  • If for example the Ops or Application Support teams are required to help then this MUST be listed here.
  • This is so that there are no surprises to the relevant teams, resourcing can be planned and it’s also very courteous to let people know in advance without any surprises.
  • If you don’t engage with them early on, they might not help you.

Date Started (optional)

  • This will be the “actual” day you started your test.  I don’t usually fill this out unless it’s an absolute requirement.  In most cases it’s more trouble than its worth.

Date Completed (optional)

  • This is the actual date the test was completed.
  • I find this and the above fields very useful when it comes to test planning.
  • Sometimes we estimate a particular test when the actuals are different.

Testing Environment (optional)

  • If you have different environments then it’s always a good idea to capture them here.  For example System Testing, System Integration or UAT.
  • You may even have lower environments that are dedicated to specific functionality or applications.

Application Name (optional)

  • Quite obvious but to always good to include the name of the Application under test.

Release/Build Version (optional)

  • I like to capture the version of the software where possible. 
  • I also like to capture the release version when raising defects.
  • Any subsequent releases should be captured as part of your release management process.
  • This is helpful for tracking and auditing purposes.

Comments/Notes (optional)

  • I usually use this field during test execution and include any updates that are very specific.  This also allows me to refer to this column when I’m writing daily status reports.

I won’t go into all the ways in which you can use Excel or Google sheets to make your data aesthetically more pleasing, but the info above should satisfy most Test Manager’s daily reporting needs.

Below are some things you should consider before you write your tests.

  • Look at the requirements and make a note of the various high level sections/categories etc in the application.
  • Can you group a number of requirements together and test them as a flow?
  • Think of a scenario, end to end flow or journey name
    • This has to be accurate.  I often see the title of the test case not reflecting the actual test.
  • You will have to open up your RTM and use this alongside your test cases.
  • Highlight/Make a list of the requirements you want to test in the RTM

Coverage and mapping back to original requirements

We will assume that you are following some kind of framework.  I like to use the ISTQB Fundamental Test Process as my methodology but this isn’t necessary.

One of the key skills you should learn is how to write a test case from a requirement. 

The main purpose of your test case is to ensure you are proving requirements.

Each test case should therefore mention exactly which requirement you are testing.

This can be easily done by putting the requirement in the “Requirement ID” field of your test case.

I will cover more of that when we discuss the requirements traceability matrix (RTM). 

Test Case Writing Guidelines and Best Practices

Attention to detail is EVERYTHING

It’s all about the details when it comes to writing test cases.

Don’t miss the small things as they may be really important.

For example, how granular do you need to test a business requirement?  In your “Expected Result(s)”, do you need to mention every element on the UI and it’s relevant position?

Understanding data setup requirements

  • Why data setup is so important
  • If you don’t know the exact data then give an overview of how the data should be setup, any things to look out for etc.

I see soo many regression test cases that are incomplete.

One of the key problems is the lack of information on how to setup the data correctly.

Data prep is one of the most time consuming parts of test design.

I often find that I can’t run a test case due to a lack of instructions on data prep/setup.

Seriously, please do yourself and your colleagues a favour by ensuring that you include as much detail as possible.

Want to be creative?…let your test case be your canvas! Think Outside the Box

I often see test cases which are about as creative as a dead Dodo!

Thinking outside of the box is essential to try and work out ways to “break” the system. 

When you look at a requirement, have you considered possible combinations, business logic, different ways that you could test it?

As a tester, you need to be creative and learn new techniques to stay on top of your game.

Use Common Sense

Common sense isn’t very common unfortunately.

When you create your test cases, take a step back and actually think about what you’re testing.

Are you testing the right “thing”?

Can the flow be optimised more?

Can the number of test cases you’ve created be reduced and consolidated further?

Keeping knowledge to yourself is BAD…don’t do it!

I’m sure you’ve all worked with knowledge hoarders. 

That ONE person in the team that doesn’t want to share knowledge because they think they’re special or it gives them job security.

If that’s you then please DON’T DO IT.

Doing the opposite will actually

Avoid putting things in the Pre-Conditions section.

When you add pre-conditions to your test cases, don’t make the pre-conditions more heavy than the actual test step.

What do I mean by this?

Don’t assume that the user knows how to carry out the pre-conditions unless they are explicitly stated clearly somewhere. 

Rather than list a ton of activities that need to be done before running the test case, you can refer to a specific test case or include the pre-conditions as test steps.

Assumptions are the mother of all screw ups!

Never assume that the person executing the test case knows the system.

By having detailed granular Test Cases, it puts you as a Tester in control of how it is executed.

This means there is less chance of error.

It also means that you have control of the order and flow of how test execution is conducted.

Examples of Test Cases

Below re some examples you may be intereted in.

A Final Note

Firstly, for those of you who still haven’t worked out the Grandparent analogy, ill explain.

This concept is something I drill into those I teach test case design and to those I mentor.

It means to make something so easy that anyone with little or knowledge of the subject can still do the job.

Never ever assume anything.  That’s a big mistake. 

I hope you found this article useful and helpful.

Remember, that attention to detail is key.

While there are automation tools that can help you with test design, nothing beats a solid foundation and good best practice to help you build quality test cases.

Related Posts