If error is the same then all types of data that caused it form an equivalent class (a class of equivalent values). Just the same as all typical correct values form another class. This is always useful to distinguish values near boundaries into a separate equivalent class, as well as such values like 0, NULL, undefined, etc.
Now are testing strategy looks almost completed. “Almost” is here because it is built on requirements. Requirements are not always complete if it comes to possible user actions. Do not refrain yourself by the limits of product requirements only. Think beyond. Be creative.
This is a process that makes testing not so easy but also adds so much fun into it ☺
Here are some cases that will demonstrate "thinking beyond what is written" approach:
- Tags and even scripts in notes would be useful.
- Same user logs in twice from different systems and tries manipulating same data.
- Notes, user name and password in a different language (not western European).
- Turn down the database or lock data file to see what system will write to the end users. Make sure the message is informative.
So, this is it! Now I am pretty sure that we will not miss functional issues should they exist. However–to make sure that there is nothing you simply do not know yet–give your testing strategy for review to Dev representative. Based on the knowledge of code structure, they may probably pinpoint where to look for additional equivalent classes.
The Real World
In the reality you may not have enough time to do all above. Sometimes you are just asked to do things quickly and provide your assessment of system quality immediately. There are no written requirements and there is no time to collect and write them down to the paper. Welcome to the real world! If we (as a company) have failed to sell an adequate testing to the customer, you have to do all the best, everything possible and more, to provide the best testing service that the circumstances allow.
For example, if you have no requirements. Well, you need to ground your assumptions about the system on something. Ask project manager or, on his permission, build a direct communication channel to the customer to find out how system works. Even if you can assume how it should behave in the give case ask customer to confirm that your assumption is correct. Guess but verify!
Now, once you have knowledge how system should work you may have a hard choice. On one hand, you want to do things right the first time and to generate written test cases, at least for the critical path testing. On another hand, you were asked to provide test results this evening. Ok. No time to play dolls. Bring it on!
Start from what really matters. Do tests for things that a customer is going to see first. Proceed until you have time. Report problems and risk immediately. Write notes as you do your testing. It will help you cleaning the mess up, once you have time for this.
If you left something not tested (many items, big volumes of data, stress, load, etc.) include it in your report. Let project manager and customer know what the risk level is. Share information. Share your assessment. Share your concerns. You are here not to please people with positive test reports. You are here to guard customer’s interests. Why? Because there is no one else to do it ☺
The Regression Testing
In scope of system functional testing, regression testing is repeating selected functional tests in