When writing a test plan, start where you are. Focus on the things the developers are focused on and ride their wave. Regression testing should not be done from an abstract perspective, but from a concrete one where problems are already perceived to exist.
It's always good to know what release you’re on. This might seem elementary, but it’s harder to keep up with than you might think. When developers and managers talk about “the next release,” be sure you know what they’re referring to, especially for so-called minor releases.
Write test cases based on requirements. Even if they’re bad requirements. Don’t try to reverse-engineer requirements and create test cases off those, unless you really have no choice. If you have any kind of requirements at all, create test cases for them. Reverse-engineering requirements will result in thrashing and will make you feel as though nothing is being accomplished.
Document all testing, including tests done on the fly. Not doing this will also feel like thrashing. Even if the program is hopelessly unstable.
Test what you can. Of course you should use the database to verify your testing results, but if you don’t know where to look, this will waste time and be unproductive in the long run. Ask for help in querying the DB to get the results you want, but don’t wait for help to continue testing something else. Often DBA’s and developers are too busy to help; you must anticipate this. Testing what you can will mean finding the bugs you can, which is better than finding fewer bugs but knowing how the DB works.
To test effectively, you can't just go through the motions of a test case. You have to think. This will mean running test cases will take more time, but you'll find more bugs that way.
Comments