How to prepare Test Cases from Requirements will be discussed later, but let's start by explaining the structure of a Test Case.
Before writing Test Cases, let's look at the definition of a Test Case. A Test Case is a set of steps to carry out, along with the expected correct result of those steps, in order to test some functionality. So you're all ready to start writing Test Cases. The standard Test Case format is:
The format is generally:
Test Step Number - to keep your Test Steps in order and to give a point of reference when you find a defect, e.g. "It happened in Test Step 8"
Action - this is the action to be taken by the Tester executing the Test Case.
Expected Result - this is what should happen when the Tester takes the action specified.
Each Test Case would normally have a Test Case ID and a title.
Each Test Step should be a logical continuation of the previous Test Step. This is a very basic example, and generally Test Cases are much more involved, but this is only to illustrate a point:
There are two principal fields of thought with regard to the level of detail that Test Steps should have. The first is similar to the example I just gave, where each step of the login process is specified, with the result of that step also specified. The other is that only a general instruction needs to be given, for example:
Both approaches have their advantages and their disadvantages. The more detailed approach is more time-consuming both to write and to execute. But it can be executed by someone who has little or no prior knowledge of the application. In the instance of logging in to an application, this is perhaps a trite example, as a login process is fairly standardised. But say, for example, you started a new job and were faced with a Test Step that said simply:
then you wouldn't know what to do. How do you raise an order, create a contract, or issue a refund? And you'll notice that these Test Steps don't have an Expected Result - just an Action.
Other Tester's, who are familiar with the application, can probably do these things without even thinking about it, but you can't. In this situation, step by step instructions would be very useful to you.
In their absence, you would need instruction in how to do these things. One option is to ask someone else. The upside of this is that when you have started a new job as a Tester, talking to people is good and helps to develop a good relationship with your new colleagues. The downside is that they will probably be busy, and since most people are not natural teachers, they would probably not teach you very well. This is another factor that helps to lead to the impression that Testers don't know much.
The other option is to read the company documentation on the procedure - the only drawback with this is that, in my experience, most companies don't have it - "we haven't got around to producing that documentation", "we've been meaning to do that", "we're always so busy", "maybe that's something that you could do", etc, etc, or sometimes the documentation does exist, but it is out of date.
And the final option - which is also the most common - is to just battle through until you have worked it out by yourself.
When you become more familiar with the application, you too, will be able to raise an order, create a contract, issue a refund, without detailed instructions.
When you reach this stage, you would probably find the step by step instructions to be laborious and time-consuming, and would just automatically give each of them a Pass until you reached the part of the application that you needed to test.
Detailed instructions, though, allow the Test Case to be executed by anyone - not just by someone who is starting a new job. If one of the Test Team is off sick, or you just have a lot of tests to get through to meet a deadline, you can borrow a Tester from another team, and they will be able to start executing tests immediately.
One of my clients had a particular issue with Test Cases. They had acquired another company, which had an application for which general tests had been written. No-one in the acquired company knew how to execute the tests - they had all been written by temporary contract Testers who had moved on (just to add to the issue, the Developers were also temporary contract Developers who had moved on, and nobody knew where the Specifications were). My client wanted to integrate this application with it's own systems, but to do so, they needed their Developers and Testers to know how it worked.
The only option open to them was to get some frontline users to demonstrate the various functions of the application.
To cut a long story short, it cost my client a lot of time and money, just to get to the point where they were ready to start the integration.
Shortly afterwards, they introduced a new policy on Test Case clarity, which was that all Test Cases should be sufficiently clear to allow an unfamiliar Tester to execute them. The aim of writing the Test Case at that point becomes one of striking a happy medium as "sufficiently clear" is subjective - what is clear to one person isn't clear to someone else, so it is a matter of keeping a balance between being excessively detailed and giving next to no detail.
Now that you have begun to get an idea of the 'how', the next question is 'where?'.
Most of the time, you will find yourself using a Test Management Tool. This allows you to enter your Testable Conditions and ensure that each of them is covered by at least one Test Case. It also allows you (or your Test Manager) to produce reports on Test Coverage, how many tests have been executed, how many passed, how many failed, on which version of the application, etc, etc.
When executing the tests, each Test Step will be presented to you with the Action to take and the Expected Result. You will then mark each Test Step as a Pass or as a Fail (there are other possibilities, but we won't go into them here).
Sometimes, though, you won't have a Test Management Tool. In these instances, you will probably find yourself writing (and executing) your tests in a word processor or a spreadsheet (in the examples above, I have used a spreadsheet). This is a very rare occurrence, but it does still happen from time to time.
Of these two options, the spreadsheet is the easiest, as you can make columns for Test Step, Action, Expected Result, Pass/Fail, and then write out the Test Steps in each row.
If you find yourself using a word processor, then you are best off inserting template tables with fields to specify Test Step, Action, Expected Result, Pass/Fail.
For the spreadsheet and word processor options, you should always keep your originals in a separate folder so that you can quickly make a usable copy whenever you have to re-execute a test. Each Test Execution should also specify the version of the application that was tested.
Before writing Test Cases, let's look at the definition of a Test Case. A Test Case is a set of steps to carry out, along with the expected correct result of those steps, in order to test some functionality. So you're all ready to start writing Test Cases. The standard Test Case format is:
The format is generally:
Test Step Number - to keep your Test Steps in order and to give a point of reference when you find a defect, e.g. "It happened in Test Step 8"
Action - this is the action to be taken by the Tester executing the Test Case.
Expected Result - this is what should happen when the Tester takes the action specified.
Each Test Case would normally have a Test Case ID and a title.
Each Test Step should be a logical continuation of the previous Test Step. This is a very basic example, and generally Test Cases are much more involved, but this is only to illustrate a point:
There are two principal fields of thought with regard to the level of detail that Test Steps should have. The first is similar to the example I just gave, where each step of the login process is specified, with the result of that step also specified. The other is that only a general instruction needs to be given, for example:
Both approaches have their advantages and their disadvantages. The more detailed approach is more time-consuming both to write and to execute. But it can be executed by someone who has little or no prior knowledge of the application. In the instance of logging in to an application, this is perhaps a trite example, as a login process is fairly standardised. But say, for example, you started a new job and were faced with a Test Step that said simply:
or
or
then you wouldn't know what to do. How do you raise an order, create a contract, or issue a refund? And you'll notice that these Test Steps don't have an Expected Result - just an Action.
Other Tester's, who are familiar with the application, can probably do these things without even thinking about it, but you can't. In this situation, step by step instructions would be very useful to you.
In their absence, you would need instruction in how to do these things. One option is to ask someone else. The upside of this is that when you have started a new job as a Tester, talking to people is good and helps to develop a good relationship with your new colleagues. The downside is that they will probably be busy, and since most people are not natural teachers, they would probably not teach you very well. This is another factor that helps to lead to the impression that Testers don't know much.
The other option is to read the company documentation on the procedure - the only drawback with this is that, in my experience, most companies don't have it - "we haven't got around to producing that documentation", "we've been meaning to do that", "we're always so busy", "maybe that's something that you could do", etc, etc, or sometimes the documentation does exist, but it is out of date.
And the final option - which is also the most common - is to just battle through until you have worked it out by yourself.
When you become more familiar with the application, you too, will be able to raise an order, create a contract, issue a refund, without detailed instructions.
When you reach this stage, you would probably find the step by step instructions to be laborious and time-consuming, and would just automatically give each of them a Pass until you reached the part of the application that you needed to test.
Detailed instructions, though, allow the Test Case to be executed by anyone - not just by someone who is starting a new job. If one of the Test Team is off sick, or you just have a lot of tests to get through to meet a deadline, you can borrow a Tester from another team, and they will be able to start executing tests immediately.
One of my clients had a particular issue with Test Cases. They had acquired another company, which had an application for which general tests had been written. No-one in the acquired company knew how to execute the tests - they had all been written by temporary contract Testers who had moved on (just to add to the issue, the Developers were also temporary contract Developers who had moved on, and nobody knew where the Specifications were). My client wanted to integrate this application with it's own systems, but to do so, they needed their Developers and Testers to know how it worked.
The only option open to them was to get some frontline users to demonstrate the various functions of the application.
To cut a long story short, it cost my client a lot of time and money, just to get to the point where they were ready to start the integration.
Shortly afterwards, they introduced a new policy on Test Case clarity, which was that all Test Cases should be sufficiently clear to allow an unfamiliar Tester to execute them. The aim of writing the Test Case at that point becomes one of striking a happy medium as "sufficiently clear" is subjective - what is clear to one person isn't clear to someone else, so it is a matter of keeping a balance between being excessively detailed and giving next to no detail.
Now that you have begun to get an idea of the 'how', the next question is 'where?'.
Most of the time, you will find yourself using a Test Management Tool. This allows you to enter your Testable Conditions and ensure that each of them is covered by at least one Test Case. It also allows you (or your Test Manager) to produce reports on Test Coverage, how many tests have been executed, how many passed, how many failed, on which version of the application, etc, etc.
When executing the tests, each Test Step will be presented to you with the Action to take and the Expected Result. You will then mark each Test Step as a Pass or as a Fail (there are other possibilities, but we won't go into them here).
Sometimes, though, you won't have a Test Management Tool. In these instances, you will probably find yourself writing (and executing) your tests in a word processor or a spreadsheet (in the examples above, I have used a spreadsheet). This is a very rare occurrence, but it does still happen from time to time.
Of these two options, the spreadsheet is the easiest, as you can make columns for Test Step, Action, Expected Result, Pass/Fail, and then write out the Test Steps in each row.
If you find yourself using a word processor, then you are best off inserting template tables with fields to specify Test Step, Action, Expected Result, Pass/Fail.
For the spreadsheet and word processor options, you should always keep your originals in a separate folder so that you can quickly make a usable copy whenever you have to re-execute a test. Each Test Execution should also specify the version of the application that was tested.
