There are some tricks that you can use to quickly improve your testing, but only if you’ve been working at the same place for some time. These tricks rely on your familiarity with the people and processes of your work place, hence the need to invest time in learning them, but they are fast to deploy and use, hence their usefulness.
Test by Fault Lines
Once you become familiar with the development process in your company, you should be able to spot the fault lines: areas where mistakes are commonly made. If you’re lucky, you can jump in at the moment the mistakes start happening and save the day. Otherwise, you will not be able to point out these mistakes until testing begins, but at least you will know where to find them.
Test by Person
Every programmer has a set of bugs he is likely to create in every project. This is because, no matter how much a person tries to learn, we each have a way of thinking that lets some bugs slip through every time. Start testing where you know the programmer is most likely to fail.
Similarly, if you are reviewing documents, you should be able to start where most problems are, based on your familiarity with the document writer.
Test by Team Changes
This is a version of testing by fault-lines, since the transition from team to team is its own fault line. It can also be seen as a version of integration testing, but only where the teams were working on different portions of the project; if the project simply changed hands, the issue is not integration of portions but the smoothness of the transition.
You can do this sort of testing even if you’re new to the company, but a deeper understanding of the differences between the teams helps recognize danger zones.
Test by Project History
With projects that have been around the block a few times, avoid the temptation to keep a steady test-plan that losses and gains tests without changing its basic structure and order. Think instead of all you’ve learned about the project, where problems have accumulated in the past, and see if that gives you an idea of how to re-build the test plan.
Test by Previous Tester
If you are not the first person to be testing a project, think of the weak areas in the previous tester’s habits and start testing there. Testing where a previous tester has already put in a good effort is not as efficient as testing where he didn’t think to go.
Test by Neglected Platforms
If you support several versions of an operating system, start testing where most people neither work nor play, i.e., where they don’t want to test. If your entire company works with Windows 7 and there are five Windows XP virtual machines, start testing with the lonely Vista machine. There be monsters.