To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
Ironically I'm struggling through a test plan in my current organization. The funny part is, the issues being raised by my co-workers aren't related to the way I'm testing, but more about how I'm presenting the material in the test spec!
Over the years, I have placed different levels of value on the test strategy document. Rarely does a project succeed without one, but often a project moves forward without referring back to the strategy document. The key values I find in a test strategy document are that, first, the document drives thinking. As the tester authors this document, she is forced to answer questions such as what related software needs to be tested, what configuration settings will be tested, or what security focus is needed.
Secondly, the authoring and sign-off of a test strategy document requires that involved teams read the document and accept the scope being covered. It's a way to force a conversation about the project, and it gives team members the opportunity to weigh in on what should be considered sufficient coverage. So authoring the test document really aids in scoping the project, discovering unwritten requirements, and driving thinking around testing in the project.
In terms of future use, the test strategy doc comes in handy in a couple of scenarios. First, I refer to it frequently when developing or executing test cases. Its sections often become areas in my test case management tool or key structure in automated testing implementation. I also leverage the test plan when performing ad hoc testing -- flipping open to a random section can often stimulate the thought process and lead me to approach an area from a different perspective. When moving to a future version of the application, the test strategy is a great resource to remind me about the previous project and what was important in it. Returning to this document helps me understand where to scope testing and, often, how to approach integration testing of new features into old.
Finally, there are times when the test strategy document becomes a tool in negotiation and in release management. Often teams agree in the planning phase about the importance of a given set of tests (for instance, data migration tests or security penetration tests). In the heat of the release, however, with deadlines looming, it can be tempting for management to want to cut test activities in order to achieve deadlines. Having a test strategy document which was agreed on early in the project can help remind everyone on the team of the perceived importance of a given test activity. At the very least, it helps the group stop and ask, "It seemed important to us then, so what may have changed in the interim which leads us to believe it's not important anymore?" This question generates healthy discussion, helping the team arrive at a decision based on more than schedule pressure. Sometimes the decision is still to cut the testing activity, but the decision has been made consciously.
In agile environments, there is a push to move away from documenting, more toward doing. In such environments, teams rarely want to invest the time or effort in an exhaustive test strategy document. However I've found that, even in these environments, it's helpful to write a high-level document that captures basic testing strategy. Even if it's a quick word doc written in a couple of hours, there's value in gathering your thoughts.
The key to the test strategy document is NOT to let it dictate your work. The document is written to help you and your team achieve the highest possible quality -- not to fill some checkbox. Experiment with what works best, question your current process, and strive to develop a document (or set of documents) that help you get your work done best. In the agile philosophy, do what works!
|
