Software testing services

The article is a part of Code Inspiration’s software development outsourcing Knowledge Base.

Software testing is one of the last but not the least stages of the software development process. No matter what advanced techniques a QA engineer possesses, one has to keep in mind the importance of testing documentation to arrange effective test coverage.

In the range of testing documentation, a test plan document occupies a special place. Why?  It’s all because a professional tester prepares it for every level of testing, as it clearly describes goals and objectives, which he or she operates on. In many cases, the specific for a given company testing test plans, designed for some specific requirements, turn out to be more productive for QA engineers.

What is test plan?

The document represents itself a detailed description of the outlined test strategy, as well as testing objectives plus the resources required for testing, including software, hardware and manpower. The document should also contain the test schedule, test estimation and test deliverables sections.It has to be a detailed document, as it will serve as a blueprint for all software testing activities, defining the whole testing process.

In this way, we have approached the stage that is bound to test planning.

How to write a test plan

To manage the software testing planning process in an appropriate way, some research has to be done. Here are the steps to undertake.

• Step 1. Analyze the product.

It is obvious that you can’t provide a good testing if you have no information about it. So it is out of the question you have to possess a thorough understanding of the product.

You have to know comprehensive replies to the questions like “Who is the product user? What’s it used for? How will it work?”

Nothing has been still said about product documentation. You will have to review it, as it will help you to understand how the product functions and how to use it. In case you realize some points are unclear, ask for the clarifications the developer or the designer.

• Step 2, which is really critical, is bound to developing the test strategy.

A test strategy is a high-level document, usually developed by a manager’-level staff, as it determines the testing efforts and costs.

• Step 3 will be connected to defining the test objective.

It is quite clear that the key goal of testing is finding the existing software defects. In other words, the objective here is to ensure that the code is bug free.

At this stage, you can also define you concrete actions related to the given software product:

• Verify the software runs smoothly and shows no signs of bugs and errors in business environment;
• Check that UI is working as expected;
• Check the product’s usability: is the developed functionality convenient for users?
• Step 4 would be the definition of the test criteria.

The test criteria is actually a rule or an equivalence standard, according to which the testing process is based and comparing to which the judgment on the testing results is based.

The two types of generally accepted criteria: suspension and exit.

Suspension criteria are called to be applied in the way to “suspend” all or a portion of the testing activities. That means, the suspicion in the existing of bugs will be expressed till the criteria are resolved. Please look at the following scheme:

As for the exit criteria, the sought outcome in this case will be the percentage rate of critical tests’ pass equal to 95.  Some software professionals advice that it’s necessary to define exit criteria by means of setting pass and run rates. You may not know how to calculate them. So here is an example.

Let’s say, your test specification document contains 100 test cases. If a tester only executed only 80, the run rate will be equal: 80 divided by 100 = 0,80 OR 80 %.

To calculate the pass rate, we need to know how many rates passed successfully. Then, if within 100 test cases were performed, and only 75 passed, the formula will be: 75 divided by 100 = 0,75 or 75 %.

Ii is also necessary to say that the run rate must be equal to 100% except for some extraordinary reasons that can’t be avoided. Pass rate depends more on the project scope, but nevertheless it is desirable to reach as high rate as it is possible.

• 5^th step is devoted to resource planning, which is necessary to understand and plan what types of resources and how much of them are required to successfully complete a project task.

You have to take into account, who are the human resource (test manager to manage the project and draw the required resources, tester to decide on the testing techniques, perform the testing itself, etc.) and decide on the system resources (server, testing tools, etc.).

• Step 6 will include planning of test environment.

At this stage, a strong involvement of the development team is required. You can address some important questions to the developers, for example, it users’ PCs require some particular settings to install and run software; if it is a highload system, what is the maximum user connection it is able to handle, etc.

• Estimation

It’s time to calculate, how much time and efforts the testing will require. Thus, what should we estimate? These are resources (people and facilities), times and human skills, which will all result in the budget and costs.

How to complete the estimation? Just follow this algorithm:Remember that each task should be accompanied with estimation, like in the example given below:

Conclusion

Surely, it is not obligatory you should follow exactly the test plan template described above. Nevertheless, it must be underlined it is better to complete and have this document, because in this case a new software product will be more validated. Still, even in the IEEE practice, there is no strict rule to follow concerning the concrete test plan document. Specific test plans adapted to the project and testing staff are more common in daily use.

The article is a part of Code Inspiration’s software development outsourcing Knowledge Base.