Plan Twice – Test Once

I have been in the midst of a kitchen remodeling the past month that has been a few yards short of joyful. As anyone who has been through a remodeling project can attest, initial estimates for construction projects tend to be more optimistic than realistic. What started as a simple floor replacement (okay, maybe not SO simple) has quickly turned into a full-blown remodel – complete with new cabinets, new countertops, and the necessary floor. Throw in the new door and full paint job…well, you get the picture.

Fortunately, I have been blessed with an accomplished home remodeling guru to ease the pain of continuous kitchen improvement. Tape measure in hand, she has systematically walked me through the otherwise painful process of selecting the right fixtures for the size and shape of my kitchen. Before I walked into Home Depot to pick out cabinets, we discussed, opined, debated, and finally, measured. Then she measured again – and then again. Not one step was taken toward the building of the kitchen until she had the exact measurements exactly right. Like all great carpenters, she was demonstrating that construction mantra “Measure Twice, Cut Once”.

Planning and design have been essential in working toward the final goal of a kitchen that will both serve my needs and provide the right aesthetic for my taste. I can visualize the functionality and usability that will fit within my current constraints, thanks in part to the picture I now have of my new kitchen, courtesy of the Home Depot kitchen designer. Abstraction has turned to confidence in having a real place to store my wine glasses.

Test planning and design can have the same effect on a software testing project. Like the carpenter’s measuring tape, planning and design tools can effectively create the model of what needs to be tested, and, perhaps more importantly, what does not. Test execution comes toward the end of a software development project, and time constraints are frequent concerns. Knowing what is important to test and keeping that focus, will ensure successful validation of the product.

Software developers, like accomplished home contractors, build applications according to development standards and customer need. Working alongside the developer is the software tester – checking “measurements”, analyzing plans, ensuring the finished product will meet the customer needs and will be fit for use. Test planning along with development planning is critical in creating effective test models that will allow test execution to focus on features important to the project and the customer.

Standard Test Plans are the first step in creating these effective models. Test plans act as the “blue print” plan for the validation of the finished product. There are many good test plan templates available, but it is content that matters. Every good test plan should concisely define what will be tested, what will not be tested and why (sometimes the effort or costs constrain the testing effort and the risks must be evaluated against the constraints), how will tests be validated, how will risk assessment be performed to determine high complexity and high impacts features that are important to the business, what skill sets are needed to create and execute tests, how will automation be used, and what data will be needed and how will it be created.

A visual model of the application and its integration points should be part of every effective test plan. This visual model displays the data flow, the integration points, and the areas of the system that are high risk that will require intensive testing. A visual test model can convey in one picture what narrative fails to do – capture the impact of testing the right features and functions. A visual model provides an important tool to the project’s non-technical members to understand exactly what will be tested in a picture, rather than in terminology not familiar to the business partners. These business stakeholders are critical to the success of the testing effort, and creating a visual model to promote understanding early in the project reduces the chances of missing critical business needs.

To round out the effective test plan, include another visual aid – a table of resource skill set and responsibilities for each area of testing. This table can be used to create the final planning model – the project plan. Knowing which skill sets are needed when will result in a sourcing strategy that uses the right resources at the right time, allowing project members to utilize their time productively.

Finally, the test plan reviews should occur continuously through the plan’s development. Engage the right stakeholders, include project team members who will be impacted by the plan, and partner with your development team – your expert construction team.
Create and revise, revise and remodel…test plans can direct your test effort early in the project. Bring your test approach to the project table throughout the planning phase of the project, not at the end. Remember to keep the Test Plan alive throughout the project, revising when the project shifts, and the likelihood of a smooth test execution resulting in a happy business customer is high.

This entry was posted in Software Testing. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>