Loading

Test strategy


Test strategy

What's a test strategy?

A test strategy is a clear blueprint of the testing approach to be followed in a software development cycle. Generally prepared by the Project manager, a test strategy aims to inform the team leaders and their group of professionals, about the primary testing objectives, the methodologies to be pursued, potential hurdles and the ways to overcome them and finally a definite timeline with the schedules within which the testing process should be finished.

What constitutes a Test strategy?

  1. Test levels:

    Software testing is performed along three levels i.e. unit, integration and system testing with unit testing chiefly a domain of developers and the latter two, responsibility of the test specialists. The test strategy informs of the level on which the software product needs to be performed.

  2. Delegation of duties:

    This includes a clear and well defined mention of all the members in the testing teams, team leaders, project managers with their responsibilities at each stage of testing. This segment of planning has to be reviewed and approved not only by the managerial heads but also the developers.

  3. Testing environment:

    This covers the type of platform on which the product needs to run on. The platform can be a particular operating system, devices, the most commonly used browsers or networks with their different bandwidths.

  4. Choice of test approach:

    Tt is one of the most carefully thought out aspects of test strategy. Depending on the scale and the complexity of the project, the economics involved and the time constraints, the project has to make a crucial choice between manual testing and automated testing. It has been well documented that a combination of manual and automated testing suits most of the organisations in their testing endeavours.

  5. Risk mitigation:

    Sometimes during the course of testing there is a likelihood of minor alterations in the codes of the product being tested. A good test strategy takes into account the measures which can mitigate such risks.

  6. Test schedule:

    The testing process consists of many requirements to be fulfilled before completion. The faults detected after running of all test cases have to be rectified by the developers. This is followed by a retest of the rectified version and regression testing to see to it that the developers didn't harm the codes at the time of correction. All this needs to be taken into account before making a final estimate of the time taken to complete the testing process. Another way to compute this time is to look into the previous version of the software and come out with a time which is roughly the double of the previous period.

  7. Grouping of similar tests:

    Some of the functionalities pertaining to software are similar in nature and keeping in mind this similarity; test cases can be built by combining these similar aspects together. For example, a test case can be built for testing all functionalities related to ticket purchase in a railway app such as ticket status, price,etc.

  8. Test priorities:

    Some test cases are critical to the success of the application. Such test cases should get marked with the tag of highest priority in the strategy, as in the product won't get the green light for launch, without their completion.

  9. Test status and reporting:

    The team leaders must report to their managers where the project stands as far as the testing activities go. A status report which informs about how many test cases completed, passed/ failed and time consumed in running them and the like.

  10. Test summary:

    A test summary is prepared with the help of status reports on a monthly or weekly basis. In case the project is of critical importance, then a daily summary is prepared.