How should you React to Someone Reviewing a Test Plan Prepared by you

How should you React to Someone Reviewing a Test Plan Prepared by you

As a software testing engineer, you rightly feel that you have done a commendable job of doing fair research on the entity to be tested, examining reports of past tests of similar function, consulting other experts, studying the likely customer usage, and comparing your findings with other consumers of your test plan.

Now a million-dollar question arises, as to after pumping huge amount of efforts in putting down your test plan on to a paper, should any other person(s) be made to sit over it and judge it?

Now lets see this point from the perspective of different type of people:

# Inexperienced testers would probably view the review of their test plan with apprehensions, almost as if they are handing over a examination paper to a teacher for grading. They fear that others will find flaws in what they have created; and of course flaws will be found.
# The point of a test plan review is not to provide a venue for others to praise you for a job well done.
# The point of a test plan review is to improve your plan. That is why you should happily welcome your test plan reviews. Because of the varied experiences, backgrounds, and insights, reviewers will think

of lot many things you probably did not. These things will certainly help you find more bugs or avoid wasting your effort.# A good test plan review is the one in which many people come out with fascinating new scenarios or identify those which you can combine or avoid altogether.
# Good programmers are generally critical by nature. They are detail-oriented personnel who, if they think hard enough, can find a flaw just in anything.
# Remember that if you send your test plan out for review and never hear anything back, it does not mean that people were deeply impressed by your thoroughness or were awed by your cleverness. It probably means they never read it.

Methodology of conducting review of test plans:
Test plan reviews can be conducted by either sending the plan out and;

1) Asking the reviewers to send their comments to you by a particular date, or
2) Calling a meeting with key reviewers and carefully crawling through the plan page by page.

The second approach will almost always deliver a better review, both because it forces everyone to actually look at the plan, and also because the verbal interchange often triggers more ideas.

In larger organizations, getting all participants together at one place may not be feasible, and you will have to adopt the first approach of “send it out and hope”. To trigger a sense of motivation among the reviewers, you can make few phone calls to your most important reviewers to let them know how much you value their comments which can go a long way towards achieving decent results.

Irrespective of the approach used, test plan reviews generally move two phases like 1) Internal reviews 2) External reviews.

Internal Reviews:

An internal review is the first opportunity you have for others to comment on your plan. By internal, we mean the review is confined to the own team of the software testing engineer. This is the chance for the entire team to help each other out and synchronize their efforts.

Experienced testers are able to suggest improvements to the plans of their peers, as well as offer guidance to those with less experience.

New testers are able to study the approaches used by others – and their fresh perspective may generate natural questions which can in fact lead to interesting new scenarios.

Finally, testers working on related functions are able to identify and eliminate gaps or overlaps with each other�s plans and discover areas ripe for collaboration.

External Reviews:

Once the internal review is complete, the plan is made available to other groups for the external review.

The software�s designers and developers should be included, as should any other test teams before or after yours in the process. If practical, the software�s ultimate end users should be given a chance to offer their insights as well.

Information developers who will be writing the software�s documentation will certainly have a different perspective on the software than testers or developers, and so may generate additional scenario ideas. Simply put, your goal is to get your plan in front of anyone who might be able to make it better.

Depending on your organization�s process, you may also need to send your plan to one or more approvers to gain final sign off. However, once internal and external reviews have taken place and you have incorporated the resulting comments into your plan, this approval cycle is normally a mere formality.

Interesting Conclusions about a Test Plan:

1) Remember that a test plan is just a tool to help you find bugs; It should not be viewed as the finish line in a race to see how much paper you can generate.

2) Test plan acts as a road map for the tester as well as product release managers to follow and a yardstick to track and measure progress against it.

3) New testers would consider a test plan as an educational tool.

4) Auditors use a test plan as a tool use to determine if you know what you�re doing.

5) Ultimate consumer could use a test plan to assess if deployment will go smoothly.

6) It also provides a vehicle for others to review your (tester�s) ideas and offer more suggestions.

7) Basic theme behind putting a test plan down on a paper is so that others can review it.

8) Last Conclusion is that a Good Software testing engineer should always love to see his/her test plan being reviewed by as many concerned & competent people as possible.

Many More Articles on Test Planning & Management

0 0 votes

Article Rating