Your plans, your cases, and your results

- Authoring a test plan is as much about the software you are testing as it is about how you're going to test it. It's a document designed to set a strategy for ensuring a product is thoroughly evaluated. This strategy incorporates the concepts, best practices and most important techniques you expect to use to ensure that you're delivering a comprehensive and effective approach to delivering a quality product. Good test plans will list your potential test cases and even suites of test options. However, it's not likely you'll be including how you plan to execute these cases in suites. This is where it gets sticky. Specific procedures often become second nature to quality testers. One test engineer will know the how and why of executing a test case. However, different organizations have differing levels of documentation. Let me be candid here. Other than those of us who like to write, documenting test procedures cases and suites is a mundane and often frustrating process. It's really complicated. And it often feels kind of useless to create documentation around the fluid and constantly shifting processes associated with testing. However, let's be clear. It's vitally important and absolutely necessary. The documentation surrounding how you conduct testing should be thought of as a roadmap for executing your project. You will be building a library of processes and procedures to ensure that when the product arrives you know how you plan to test it. But, that's not where it ends. This document also provides analysis of your scope, care and forethought of how the product will be handled during test. Documenting the various techniques allows you to demonstrate that your approach is well founded and researched. It shows you grasp the product, understand what needs to be evaluated and that you have a strategy. Test plans incorporate a long list of processes that will deliver test results. The output of each process is an evaluation of a portion of the product. The output of the plan is a quality product. When you create a test plan you'll be citing these processes. If anyone questions what you are doing or how you plan to deliver, it's super convenient to have this on hand to demonstrate your operation isn't simply flying by the seat of your pants. Creating documentation around your techniques allows you to keep a persistent and consistent process flow around your execution. Measuring how much you've accomplished and what remains outstanding. Once you have a plan, you'll be sharing this with a variety of team members. You'll be incorporating your list of test techniques broken down by portions of the product being tested. It's a document that will be reviewed by engineers, marketing teams and other partners who have a vested interest in the success of the product. Your plan should be clear to every reader on what you anticipate accomplishing. You are going to hear me throwing around a lot of industry terms in this course. The processes, techniques and approaches to testing have standard aims that you will want to know and understand. However, what these things are called and the associated terminology are similar to when a doctor speaks to you about medical issues. They aren't using terms people understand or even use. Chatting in casual communication with your partnering teams about black box testing may garnish a lot of confusing stares. To other team members what you do is just testing. And the various esoteric names and practices I'll be exploring, make sense to you for documenting in your test plans, discussing best practices on your team and reviewing your results. However, they will make little sense to anyone outside the quality world. For example, I encourage you to learn why you might use equivalence partitioning during your test phase. But I discourage you from referring to it in your test plan and when communicating results. This is one of many tests to ensure input field responses work properly. However, you're using such a technical term may frustrate and even confuse your internal development teams and project partners. Communicate your strategy and results using a very binary but detailed response. Your teams want to know what works, what doesn't and what needs to happen to ensure it won't be repeated in future releases. Focus on communicating how the results of your testing challenge the project and product and why specific failures are impacting the product. If someone questions how you got your results, you can always re-direct them to your test plan and explain the technique you used. Use your plan as a bridge for building understanding of the techniques you have adopted to test and what you hope to achieve with this testing. If you are measuring the input fields for accuracy, just call it input field test in your plan. If your product has a field that fails during your tests, it will be easier to communicate that the input fields are broken. Than to explain how the software failed equivalent partitioning testing. Testing and the techniques used are part of a collaborative environment to help ensure the common goals of achieving a quality product. The way you communicate your test plan, your test cases and most important Your test results will directly impact whether your team's approach to the quality testing is viewed as successful. Build each carefully with your partners in mind and you'll find you'll have their confidence and respect.