Software Testing 101 - How to Write Test Cases That Will Find More Defects in Less Time
Every system will get upgraded occasionally for different reasons such as change of policy, technology or product just to name a few.
Requirement should be used as a baseline for testing to ensure that the existing and new functionality are working.
Test case is derived for each requirement as a way of proving that the system or changes being implemented is ready for day to day business use without error and/or adverse impact on the existing functionality.
Requirement itself changes from time to time and some become obsolete and to be removed.
Although the main activity of being tester is to execute test, maintaining requirement list is crucial to be able to find as many defects as possible in the shortest time.
Associating every case with requirement, as a source, is a good way to manage your time efficiently.
I have seen examples where cases were created without requirement can lead to hours, days and weeks of testing efforts without clear objective.
There is no hard and fast rule how to derive the cases but I find it easier to start thinking from test types.
For example, Requirement: User must have a valid username and password to login.
Question to ask yourself when developing test case would be: 1) what 'functional' capabilities I need to test? 2) what 'non-functional' features to be included? 3) what 'security' constraint? 4) what 'negative' tests should be considered i.
e.
invalid username and/or password..
etc.
As you can see it is very easy to come up with at least two cases, one being positive and one being negative test, from one requirement.
Note that test type is context specific which means specific type(s) are more suitable for specific application.
I would normally finish first round of static test with two aspects without taking too much time and move to the next requirement.
As you understand more how some requirements are linked together scenario based test case can be developed (how to derive it from scenario is out of scope in this topic).
Summary Test case should be derived from requirement and if there isn't one you can verify whether or not new requirement(s) need to be added regardless if it is functional or non-functional.
Maintaining requirement list is important so that your testing efforts have clear objective(s).
Lastly, try thinking different types of testing to create different test cases this way you 1) see the situation from different perspective 2) have a good understanding of the system when several requirements are put together.
Requirement should be used as a baseline for testing to ensure that the existing and new functionality are working.
Test case is derived for each requirement as a way of proving that the system or changes being implemented is ready for day to day business use without error and/or adverse impact on the existing functionality.
Requirement itself changes from time to time and some become obsolete and to be removed.
Although the main activity of being tester is to execute test, maintaining requirement list is crucial to be able to find as many defects as possible in the shortest time.
Associating every case with requirement, as a source, is a good way to manage your time efficiently.
I have seen examples where cases were created without requirement can lead to hours, days and weeks of testing efforts without clear objective.
There is no hard and fast rule how to derive the cases but I find it easier to start thinking from test types.
For example, Requirement: User must have a valid username and password to login.
Question to ask yourself when developing test case would be: 1) what 'functional' capabilities I need to test? 2) what 'non-functional' features to be included? 3) what 'security' constraint? 4) what 'negative' tests should be considered i.
e.
invalid username and/or password..
etc.
As you can see it is very easy to come up with at least two cases, one being positive and one being negative test, from one requirement.
Note that test type is context specific which means specific type(s) are more suitable for specific application.
I would normally finish first round of static test with two aspects without taking too much time and move to the next requirement.
As you understand more how some requirements are linked together scenario based test case can be developed (how to derive it from scenario is out of scope in this topic).
Summary Test case should be derived from requirement and if there isn't one you can verify whether or not new requirement(s) need to be added regardless if it is functional or non-functional.
Maintaining requirement list is important so that your testing efforts have clear objective(s).
Lastly, try thinking different types of testing to create different test cases this way you 1) see the situation from different perspective 2) have a good understanding of the system when several requirements are put together.
