Ben Weese

Writing a Test Plan

|
Exploratory Testing  – Most of the time when you are first learning the software you will do some exploratory testing. This will help you look around and figure out how things work. Much like the gif shown above Tony is learning to fly by exploring how things work. Here you are investigating how the software behaves, and how you think it should as a user. This is also a very useful way to test, and should be used in conjunction with Functional Testing. Functional Testing or Scripted Testing, test the function of software following a script or step by step process. This way you know what has been tested and what needs to be tested based of the plan that the tester has outlined. When you know the software’s ins and outs, it is time to shake it up a little and use all your knowledge to break the software, by exploring outside the box. That is what makes Exploratory Testing so useful, but remember it is not the only kind of testing.
Defining an Introduction and Scope – So now you are starting to understand the software and you think you can write a test plan. Choose a part of the software you are going to test, in my company these are called views or abilities. For an example I will use a internet browser. Your test plan could cover the settings/preferences, the toolbar, or the file menu. All are good test plans you could write. So once you figured out what you are going to test, and write a test plan on, ask yourself some questions:

  1. What needs to be Tested?
  2. What will you be testing?
  3. How are you going to test it?
  4. What is the Beginning and end Criteria?
  5. What are the risk and dependancies? AKA Setup and Security!

Next think about catering your test plan for expected results, you will want different results depending on failures and successes. 

Now you are ready to write and introduction and scope for your test plan. The introduction is the overall mission, what will be covered and what the tester needs to know. Such as test the security of the login window. This gives future Testers a clear understanding of what the test plan was made for. Next you will want to define a Scope. The scope will tell the tester what they are to be testing and what they are not testing. This helps when you might be testing something in Development and it is not complete or maybe you will be testing the other part in another test plan. This will clearly define the role of the tester. Also within these steps you can define a Setup, What should the tester have setup before they continue or start your test plan. This makes sure the conditions are the same for all testers. Again for Tony he would be defining that he would be testing the glove would go to his hand. The scope would be that single piece and out of scope would be the rest of his armor.

If you are an Agile Tester it is also best to review your test plan with your team.

Adding in Test Cases and Sub Test Cases – Next you will want to build test cases and sub test cases. Test cases make up a Test Plan and a Test Case is made of Sub Test Cases. 

Example Test Case: Login to website. 
Example Sub Test Case: Use wrong username. 

You will be building this like one would script a play, as you will be defining the users actions. Use the answers to the above questions and workflow to figure out the flow for the test plan. A great way to create your test plan is to run through it as you are making it, this helps you test the flow, and can point out anything you may be missing to help you make a thorough test plan. This is where it all comes together as the Iron Man suit is in the gif.

Execution of your Test Plan – Last but not the least is running and executing your test plan, like Iron man executes the tank. This not only is to help you find bugs in the software but also in your test plan. Remember as the software changes so does your test plan. Things are bound to change as bugs are fixed, and design is changed. Remember the test plan is more of a guideline, and exploratory testing will also be needed to find the bugs. At this point you may want to make sure that your test plan is easy to follow, because when you move on it will be the next testers job to run your plan. This will also help the next person learn the software and improve on your plan with ideas of their own. Also remember to come back every once and awhile to trash the old test plan if it no longer works, and write a new one. As you write more and more test plans your skill will improve.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.