WHEN SYSTEM TESTING, BE A SYSTEM TESTER
When you integrate everything and test it, it is still integration testing. System testing begins when you test the system as a whole, based on the system specification of the system. System testing requires a different mindset than integration testing. That is why system tests are usually done by a separate QA team. Students projects often do not have the luxury of a QA team. However, try to change your mindset when you transition from integration testing to system testing. Another trick that could help here is to plan system testing so that each one tests functionalities he/she did not implement.
ALLOCATE MANPOWER TO MINIMIZE RISK
Here are some tactics to mitigate risks during system testing:
duplicate testing: let the same functionality be tested by more than one person
get test cases reviewed: test cases can be wrong too. get your test cases reviewed by another team member
USE ERROR SEEDING TO GAUGE THE TEST COVERAGE
After the 'tester' of your code says he/she is done testing it, you can purposely insert subtle bugs into your code (this is called error seeding) and see how the test cases respond. If no test case failed, the tester has not done a good job. If a large number of test cases failed and the tester had to scratch his head for hours to figure out what to put in the a bug report, the coverage is good but not the quality of the test cases.
You can make it a fun game; you get points for sneaking in a bug that is not caught by the test cases.
KEEP THE FOREST IN VIEW
While testing needs to be meticulous and thorough, there is no point being stupid about it. If you get bogged down by trying to achieve high coverage over one part of the system, you might end up not testing some other parts at all.
Start with core/primitive functions. You may have to fix those before you test the rest.
Start with obvious and simple tests. If any such case fails, developers will want to know it sooner rather than later. While you need to check invalid and unexpected input, check valid and expected input first.
Test broadly before you go deep. Check all parts of the program quickly before focusing.
START BY WRITING CONCEPTUAL TEST CASES
Before you implement test cases in code, you may want to define them at conceptual level. These are easier to cross-check against the specification. Doing this early will help you in test planning and estimating the testing effort.
Here are some example test cases specified at conceptual level:
* Test the scroll bar of the browser for long web pages
* Test the scroll bar for displaying non-html objects, such as images
* ...
As you can see from the above examples, these can later go into the documentation of test cases.
LOOK IN THE RIGHT PLACES
Pragmatic Software Testing says "hunt where the birds are, fish where the fish are", meaning, test where the bugs are likely to be. Be smart about where you focus your testing energy. Do not test areas randomly. Do not test functionality in the order they appear in the API. Examples of places where bugs are likely to be:
Parts recently modified
Where you found the last bug. More bugs found could mean more bugs hidden (bugs like to hang out together).
More complicated parts of the system (metrics like cyclomatic complexity or function points can help here)
Parts done by weak programmers of your team
MAKE BUG REPORTS WORK
Your bug report should not stop at saying "hey, I found a bug"; it should help your colleague as much as it can to locate the bug. When a test case fails, investigate further. See if similar failures occur elsewhere in the system. Figure out the minimum required input that can reproduce the failure. Try to characterize the failure in a more general manner.
An example:
"Test case 1103 failed" [not very helpful]
"System fails when I enter the text '100% coverage expected
"System fails when I enter symbols such as '%' into any text field in the 'new policy' UI. This does not happen with other UIs" [much more helpful]
Some useful policies for bug reporting:
When you create a bug report, always assign it to someone. If you are not sure to whom, just pick the most likely candidate. Reason: if you leave it unassigned, it will not get picked up for fixing
A bug should be assigned to a single person. Reason: this makes it clear who is the one person in charge of handling the bug
A bug assigned to you should be accepted or reassigned ASAP (say, within 24 hours?). Reason: to avoid someone sitting on a bug for a long period and then throwing it to someone else
Only the person who filed the bug report can close it. Reason: this will make sure the issue was actually handled
DO NOT FORGET TO TEST FOR NON-FUNCTIONAL QUALITIES
The system may need to be checked for performance, usability, scalability, installability, uninstallability, portability, ...