7.8. Manual Test Cases
When it comes to manual testing, you need to take into consideration that the tests will need to be run multiple times. The most effective way to support this is to create test cases around the parts of the application which you want to be able to retest on a new build. These test cases are generally run either when that area of the application has changed or just before a release to verify everything is working as you expect. Having the test cases in place means you can quickly run through the cases without having to rethink all the possible combinations and areas of concern. This provides you with a safety net to ensure that everything has been covered correctly.
When writing manual test cases you will notice that they have some similarities to automated test cases. For instance, a manual test case should be targeted to one particular task, feature, or item to check. This is to make them concise and allow you to only run the cases which are actually required at that point in time as speed is an issue. Being manual, they take much longer to run than automated cases which means at times you need to be able to very easily pick and choose which cases are required to be run. The more focused they are, the easier this is to do. However, manual test cases do have the advantage that you are able to test multiple things at the same time because it is a human verifying the results and so can be more flexible. A single test case could verify different parts of the UI; this does mean the test cases take longer to run, it is harder to decide on the parts which should or shouldn't be tested, and reporting failures becomes more complex as it is harder to tell which part of the test failed. As a result, you should generally try and keep the tests targeted to one particular area and test one particular item.
To run the tests quickly the tests should be written in a very clear and concise fashion. Ideal test cases should be understandable by anyone on the team, no matter how much experience they have with the product or testing in general. To help with this they shouldn't use technical terminology and should be structured in a step-by-step style. By doing this, you can quickly follow the steps and verify the result at the end.
An example of how this might be structured is shown next:
Title: Test to verify a product can be added to the shopping cart.
Steps:
Launch Internet Explorer and visit the WroxPizza homepage.
Navigate to the Products page.
Navigate to the Pizza category.
Add the first product in the list to the basket.
Verify you have been navigated to the shopping cart page.
Verify the product you added is in the shopping cart.
Given this example you can quickly take the test case, run the steps manually, and verify the results — marking each test as a passfail to indicate if there were any problems. You could also structure them in a similar style to your acceptance tests in Chapter 6, the only difference being how they were actually executed to verify the result.
When you run manual test cases you are always looking out for things beyond the test case, not with your full attention but simply ensuring that the page has rendered correctly, the text is in place as expected, and it generally feels correct — looking for the type of problems discussed in the "Beyond Simply Breaking the Application" section.
However, in WroxPizza you wouldn't create this type of test case because it is already covered by automation. The manual test cases should be in place to enhance your automation efforts, covering the areas of the application which are too difficult or costly to automate. You feel that manual test cases should be secondary to automation, favoring the automated route whenever possible for the reasons described throughout this book.
Just as with automated test cases, manual test cases also might require a set-up stage and have preconditions which must be met before the test can begin. These set-up stages allow you to configure your environment and test data to begin testing. By having this as a separate set-up stage you can re-use the logic between different test cases improving the maintenance and readability of the test cases. If these steps can be automated, as described in the "Part Automation" section, then they should be, to save time and effort.
Common set-up tasks involve producing test data to allow you to test the site. Ideally you want realistic-looking data so that you can verify how the system is expected to behave. As we described in Chapter 5, you could use a Test Data Builder and create some C# code which would insert test data into your system in an automated fashion.
The other approach is to use tools such as Microsoft Visual Studio for Database Professionals (Data Dude) or Red Gate SQL Data Generator. These tools allow you to generate realistic-looking data based on a series of rules and your schema. The screenshot of SQL Data Generator is in Figure 7-6. Based on your database schema, the tool has generated a preview of the type of data it will generate. You can then configure and modify the data based on your requirements to produce a large data set.
Figure 7-6. Red Gate SQL Data Generator.
Tools such as this can be invaluable when manually testing an application. Another invaluable tool for manual testing is virtual machines. Virtual machines allow you to run complete operating systems within your main OS. This means you can have a different configuration, setup, and environment to your actual main machine. After it is set up, you can clone the environments and undo changes after a set of testing has been performed. This is great for testing. You can set up your machine, perform tests which you wish, and then simply revert the machine back to a previous point in time within moments. There are a number of tools available to help with this including Microsoft Hyper-V and VMWare Workstation, as used in Figure 7-7.
Figure 7-7. Windows 2008 running within VMWare while main OS is Windows 7
When writing automated test cases, the point at which you actually write the test case is fairly well-defined. During TDD you write the test case before the code. With acceptance tests, you write the test before the code and the implementation of the test after. With manual testing, that point becomes more blurred and it actually varies a lot based on the project.
Sometimes you know ahead of time which tests you will need to perform manually. This generally occurs when you are attempting to write the acceptance tests for the piece of functionality, however, you feel that it would be more suited to a manual test case due to the nature of the functionality or the cost involved with replicating the functionality or behavior of the user in an automated fashion.
This often occurs when customers have reported problems with the software. Ideally, you should automate these problems to ensure they don't arise again in the future; however, in our experience customer problems generally are complex and could take a long period of time to automate. As a result, it might make more sense to write it as a manual test case. You should always consider automation, and for a serious problem they should be automated to ensure they don't happen again, but sometimes it makes more sense for them to be manual. We recommend that you keep customer regressions in a separate location to your manual functional tests so you can easily identify which tests you want to run and at what point. If you have them mixed together it can be more confusing to identify the type of test they are.
In a similar fashion, when you are performing exploratory testing you might find the test cases you are thinking of and trying are useful to re-run in the future to ensure that the functionality still works as expected. In this situation you should make the effort to either automate or write a manual test around the area of functionality to maintain a record of what was tried and allowing you to try again in the future when you need to re-run your test cases. This is why recording can be useful, as you can note a position within the video which should be turned into a manual test case but continue with the exploratory testing. When you have finished, or need a break, simply return to the video and create manual test cases based on the steps you performed. This allows you to remain focused while not forgetting anything in terms of future test cases.
As with automated test cases, sometimes you do need to remove manual test cases. Just as with automated test cases you should have a nice streamlined set of tests which accurately reflect the functionality of the site. There should be no duplication and everything should test a particular part of the application. This is difficult to achieve and will come with practice, the scary thing is that duplication and redundant test cases can creep up on you if you are not careful. The main thing is to make sure you are reviewing your test cases, your structure, and the steps to ensure that you are on the right path.
As the application is developing and maturing, the manual test cases should be updated in sync with this. When functionality changes you need to revisit any test cases you have and update them to reflect the change. For this to happen effectively the team needs a good understanding about the test cases and what type of test case covers which area of the application. This is simply about good communication and a good organization of the test cases.
When functionality has changed, then sometimes you can simply update the steps to reflect the change in the application; however, sometimes the test cases need to be removed. You shouldn't be afraid of removing test cases if they do not relate to the application.
This brings us to the topic of how to store and structure your test cases. There are many off-the-shelf products which attempt to solve the problem of handling multiple test cases. Each tool varies wildly in price, functionality, and actual usability. Tools such as HP Quality Center, Microsoft Visual Studio Team Edition for Software Testers, and smaller software houses such as TestLog can provide you with functionality to manage manual test cases. However, many people simply use Microsoft Excel to manage the test cases. All tools have their own set of advantages and how much you invest depends on how heavily you plan to depend on the manual test cases.