Manual Test Cases Writing Hacks

As technologies advance, automated testing is becoming a norm. However, automated testing alone is not sufficient in many cases; thus, the need to write manual test cases. An essential part of any software QA exercise, manual test cases can be difficult to write. Here are some hacks to get through the process.

Effectiveness

It may be a common understanding that running a lot of tests might give more coverage. However, a lot of poorly crafted test cases are a drain on project resources and time. Fewer cases that are effective lead to higher coverage with less time and money spent. Effectiveness of a test case may be improved by breaking it down into manageable sub-sets (that may even be common for some test scenarios).

Simplicity

A test case must be understandable, without any complexity into what it is testing for, what are the inputs and outputs of the test case, etc. An ideal way is to use a template so that everyone is able to see each test case under a similar light, making things simpler in the long run.

Understanding

To develop an understanding of what makes and breaks the software you are testing, you can use some of the most common techniques that are sure to bring out errors (unless handled specifically). This includes leaving out blank fields in a form, providing the wrong type of content, and forcing division by zero, etc.

Reusability

Even though we are to write manual test cases, nothing stops us from using what has been already done previously by the QA team. Therefore, make use of available test cases to write your own, taking help from lessons learned (if available) to improve upon them. Additionally, when making your own test cases, keep in mind that it might be reused in a different scenario, a different but similar project, etc. Therefore, making test cases reusable helps in the future as well.

Regression testing

Whenever the software is update, old tests should be re-run to make sure nothing tested has changed and outputs are the same as expected (or adjusted as per planned modifications). This regressive testing has to be planned out in the test cases written and should be made a part of the test policy. Once tests are re-run, some may give unexpected results which may not always be because of faulty changes in the code but rather a test case that is inappropriate under new circumstances. Therefore, having regressive testing in mind would help re-run and rewrite a test case when changes are made.

Self-review

Once a test case has been written, be sure to walkthrough it in the shoes of a tester. Assess if the case addresses the scenario appropriately and would be easy to execute. Make sure the case is understandable to the tester and the results are meaningful.

End-user orientation

Testing is done to provide the end user with the highest quality software. Errors that they would face and report back are weeded out during the testing process. When making a manual test case, think of the end-user and how the user experience would be affected should the test case fail to cover a scenario the end-user would be in.

Not-features

Most tests are done to test the features offered by a software. However, it is also necessary to test for not-features, i.e. those abilities of the software that should not exist and may be used to exploit the software or data. This helps improve the security of the software as well. To check for these not-features, you should try to perform functions that were not intended to be available by the developer.

Organization

Use of proper organization tools and systems is important for almost every work. With test cases, it is even more important because the count of cases run can escalate very fast. Managing these huge numbers can be difficult if a system of organization is not devised right from the start. While some people use simple spreadsheets, specialized tools are available for every budget to manage test cases more effectively.

Pair testing

One person can overlook certain aspects while checking something, no matter how many times he goes through it. At these times, having a friend go through the same thing brings out immediate results. When writing your test cases, you may want to do so alongside a friend, discussing the test case and its results before execution.

Backwards

When writing a test case, you may want to consider a backwards flow of data and information. This means that instead of thinking what the results would be for a certain input, you can think of what the inputs could be for a certain output. You may then try to get the same output using wrong input or by skipping certain required steps.

Conclusion

With software testing, it is not sufficient to fulfil requirements alone. You have to plan for the unexpected and turn it to expected & addressed.