Many people in the software testing field did not choose their career but were placed in the position. As a result, very few individuals are fortunate enough to have actually been trained in testing before they started or even after they've been testing for months. The newly appointed tester is left with many questions about how, what, and when to test. This article will outline a straightforward, five-step approach to tackling these issues.
You're assigned to test and you've never done it before. You didn't request the position and you have no training. Now what? This article will outline a straightforward, five-step approach to tackling everyday testing issues. Each part builds off of the previous level in a progressive manner that can be applied to most methodologies and projects.
Step 1: Identify. When you don't have a previous history from which to build, you have to establish a baseline of expectations, areas to test and strategies
Step 2: Inventory. Catalog these items
Step 3: Prioritize. Use your inventories to evaluate where the most immediate needs are and where to delegate tasks
Step 4: Implement. Decide how to accomplish the tasks you have identified and put your plans into action
Step 5: Analyze. When the smoke clears, take a careful look at what worked and what didn't. Use this information to begin the identify step for the next project
Or, if you like mnemonics, "Insight Is Preferred in Advance."
Step 1: Identify
The first step is to identify what you want to accomplish through testing. If you or your manager think the objective is "bug-free software," you're probably new to the testing game. Even simple projects have a huge number of variables that can cause defects. You have to consider the hardware environment, operating systems, range of inputs, volume of data, data integrity, among other factors. It's a daunting quantity of information to work with. An essential part of software testing is breaking down these areas and finding ways to manage large amounts of data for maximum results. In other words, you'll need to narrow your scope.
Start by picking up a good testing book and read the first chapter or two. The first two chapters of these books usually give a little history of testing and begin to talk about the scope of what it can accomplish, without getting into the fine details. Start to look at testing's role in terms of what must be done, what should be done, and what can be ignored. As you begin to identify these items, start brainstorming lists of resources needed, areas to be tested, and potential risks. You'll also want to be the leading authority on your product.
Much of this knowledge is gained from the program requirements. If there are no documented requirements for your product, interview the project manager, developers, and the people that requested the project be built. Find out what they want the product to do. Record this information and use it to evaluate the functionality of the program. If available, look at manuals or software for earlier versions of the product. Get call logs from customer support on existing products or look at other companies' products that provide similar features.
Finally, identify resources you will need, including equipment, time, and personnel. Also, try to identify as many areas as you can that are products of the testing process, e.g. defect reporting, defect resolution, configuration management, test tracking and so forth. The amount and scope of these items will be directly proportional to your experience. Since nothing in technology remains static, it's okay to add new areas that you identify as you gain experience and more time to improve your process.
Step 2: Inventory
Categorize your information and be sure to list each item under the correct category heading. List contingencies that relate to each category. Keep your inventories broad to begin with, and then fill in specifics as you go along.
The most important area to inventory is the requirements. If your requirements are already in an outline format, this