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.
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.
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.
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.
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:
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.
QA Hipster is a Quality Assurance Technical Lead for an software company, mostly working with Macs. I have been in the field since September 2013, and have a bachelor's degree in Management Information Services. I started my studies at Iowa State in Software Engineering. I have been working on moving my company forward with the latest QA techniques.