rare bird

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