Once you have produced all your Testable Conditions and allocated them to the various functional areas of the application, you are ready to write your Test Cases. You will write these from a number of angles.
These will include:
1) Ensuring that the product does what it is supposed to do;
2) Ensuring that the product does not do anything that it is not supposed to do;
3) Ensuring that each of the component areas can be integrated together and still work correctly;
4) Ensuring that the whole product works from the beginning to the end.
Here, we will just consider the first of these, which is to ensure that the product does what it is supposed to do. This is Positive Testing, and also goes under names such as Happy Path or Golden Path, indicating that everything is just fine when you do what you are expected to do.
This involves using each of your positive Testable Conditions in one or more Test Cases. When each of these has been used in at least one Test Case, you will have covered all of the requirements for the product, and will therefore have written Test Scripts to test that it does everything it is supposed to do.
A good Test Case should, in principle, be broken into three parts, which for the sake of this illustration, I shall refer to as Test Start, Test Middle, and Test End. These would generally move the User to the area to be tested, then test one or more functions in that area, and finally move the User out of the area that has been tested.
I'll give some examples, but you need to bear in mind that testing is an art rather than a science, so there is not a single a = b + c approach.
Example 1
Test Start
Log onto the application
Test Middle
Navigate to the xyz area of the application
Verify that Testable Condition 1 is met
Test End
Log off of the application
If you had a number of different functions that you needed to test in area xyz, then you could of course put them all into one Test Case, but this would not be good practice. Supposing for example that you have five functions that you need to test in the xyz area, and you put them all into the same Test Case. When you come to execute the test, the first two functions pass, but the third function fails. Now your whole test fails because of one defective function, although two of the functions are actually working correctly, and another two have not been tested because you stopped when you reached a point of failure.
If you had written five separate Test Cases instead, you would have had two Test Cases passed, one failed, and two not run.
But if you have five separate Test Cases, then you can quickly see a problem with Example 1, above. The first Test Case would start with logging the User onto the application, and end with logging the User off of the application - and then you would move onto the second Test Case, which would start with logging the User onto the application.
This is clearly a waste of time, as you were already logged into the application, and you were already in the correct area of the application for your second test. In real life, you wouldn't log off of the application so that you could log in again a minute later - you would just stay logged into the application. The answer is to create your Test Case with a prerequisite. So let's rewrite our example:
Example 2
Test Start
Prerequisite: Logged into application
Test Middle
Navigate to the xyz area of the application
Verify that Testable Condition 2 is met
Test End
Navigate away from xyz area of application
So we still meet our principle of Start, Middle, End - and we've avoided logging off so that we can log back on a minute later, but you may be asking why we are navigating away from xyz area so that we can navigate back to it a minute later. Depending on the application you are testing, you may not need to - but many applications need to close a form or a page before anything new can be done on them. This is a call that you will need to make, based on your own knowledge of the application you are testing - and of course, you will have gained a lot of that knowledge through constantly reading and re-reading the Specifications.
These will include:
1) Ensuring that the product does what it is supposed to do;
2) Ensuring that the product does not do anything that it is not supposed to do;
3) Ensuring that each of the component areas can be integrated together and still work correctly;
4) Ensuring that the whole product works from the beginning to the end.
Here, we will just consider the first of these, which is to ensure that the product does what it is supposed to do. This is Positive Testing, and also goes under names such as Happy Path or Golden Path, indicating that everything is just fine when you do what you are expected to do.
This involves using each of your positive Testable Conditions in one or more Test Cases. When each of these has been used in at least one Test Case, you will have covered all of the requirements for the product, and will therefore have written Test Scripts to test that it does everything it is supposed to do.
A good Test Case should, in principle, be broken into three parts, which for the sake of this illustration, I shall refer to as Test Start, Test Middle, and Test End. These would generally move the User to the area to be tested, then test one or more functions in that area, and finally move the User out of the area that has been tested.
I'll give some examples, but you need to bear in mind that testing is an art rather than a science, so there is not a single a = b + c approach.
Example 1
Test Start
Log onto the application
Test Middle
Navigate to the xyz area of the application
Verify that Testable Condition 1 is met
Test End
Log off of the application
If you had a number of different functions that you needed to test in area xyz, then you could of course put them all into one Test Case, but this would not be good practice. Supposing for example that you have five functions that you need to test in the xyz area, and you put them all into the same Test Case. When you come to execute the test, the first two functions pass, but the third function fails. Now your whole test fails because of one defective function, although two of the functions are actually working correctly, and another two have not been tested because you stopped when you reached a point of failure.
If you had written five separate Test Cases instead, you would have had two Test Cases passed, one failed, and two not run.
But if you have five separate Test Cases, then you can quickly see a problem with Example 1, above. The first Test Case would start with logging the User onto the application, and end with logging the User off of the application - and then you would move onto the second Test Case, which would start with logging the User onto the application.
This is clearly a waste of time, as you were already logged into the application, and you were already in the correct area of the application for your second test. In real life, you wouldn't log off of the application so that you could log in again a minute later - you would just stay logged into the application. The answer is to create your Test Case with a prerequisite. So let's rewrite our example:
Example 2
Test Start
Prerequisite: Logged into application
Test Middle
Navigate to the xyz area of the application
Verify that Testable Condition 2 is met
Test End
Navigate away from xyz area of application
So we still meet our principle of Start, Middle, End - and we've avoided logging off so that we can log back on a minute later, but you may be asking why we are navigating away from xyz area so that we can navigate back to it a minute later. Depending on the application you are testing, you may not need to - but many applications need to close a form or a page before anything new can be done on them. This is a call that you will need to make, based on your own knowledge of the application you are testing - and of course, you will have gained a lot of that knowledge through constantly reading and re-reading the Specifications.
