Ben Weese

Why Excel is so Wildly Used For test plans…

|
Over much of my research I found that a lot of people, to this day use excel for their test plans. There are articles posted all over about how to best use excel. For example this link, talks about how to utilize excel when writing your test plan, and I have attached a template I found on that site that utilizes excel.

Excel Test Plan Template by Eric
File Size:32 kb
File Type: xlsx

Download File

So why is excel so widely used? Well, it is simple and versatile. Each tester has their own ways of doing things and excel allows everyone to have a different set up. When I looked at other testing software such as Test link which is widely used and open sourced test plan software. In the end it took me over an hour to set everything up without a tutorial. It is overly complicated, that might be why it is not used as widely as excel. Another one, I am excited to see how it grows, is Overlook. However, the main page currently says it best “Really Simple Software Test Plan”. It is very basic, but the reason I am excited about it is because it was recently bought by Crowd Soured Testing, and they told me they would be working on integrating it with another new site of theirs, Damn Bugs. Plus they work with the people on their site to help make the best product. I will go over Overlook and Damn bugs at a later time though when I go over free sites that can be of uses to a QA professional.
The problem lies in the software for test plans, it is either not versatile enough, or it is too simple. Excel allows the test plan to be any type. What needs to be made, and you can find within software companies who make their own, is a system that has an integrated test plan, and bug tracking system. This allows for when something is failed, there is a bug, and it is tracked immediately. There are paid systems out there that are good, but again not everyone is going to fork that much money into QA. So in the end, excel just works where others fail.

Also remember that test plans aren’t everything and Exploratory Testing is needed in conjunction with your test plans.

The Layout of a Test Plan

|
We were looking at rewriting all of our old test plans. Most of our test plans were written by our designers. I decided I would start rewriting some and when taking on the task, I researched it heavily taking into consideration what they had in common, and what they all liked. I took what I liked and created the documentation that you can find in the documentation link.

The big things I found were an outline of Non-test case items, Introduction, Scope, Set-up, Test Cases, and Sub-Test Cases.

  • Non-test case items: This is where the tester can fail things they have found, but does not align with something in the test plan.
  • Introduction: This is where you introduce what you are testing and explain to the tester what they need to know. I also like to remind the tester that this is just a guideline and to think outside the box when testing.
  • Scope: Here you clearly define a scope for testing. Maybe you only want them to test a certain part as something is tested else where. You want to tell the tester what they can and cannot test.
  • Set-up: Here we put steps to help the tester set anything up they might need to continue with the test plan. This makes sure they don’t run into anything that was not set-up.
  • Test Cases: This is when you start writing up your test plan. You will define your test case then test that. Then define another. Test plans are made of test cases.
  • Sub-Test Cases: Sub-test cases are all the little steps you can take to make up a test case. This makes sure that it is throughly tested.


Also remember to coordinate your test’s expected results for failures and successes. With my company you also want to make sure anyone can pick up the test plan and work with it. This is a good goal in general so other QA can pick it up and use it.

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.