Is there value in the heavy detailed Test Plans?

[Marco Foley]

My view on test plans is to keep them relative to the important information which is valuable. I should probably start by stating what I believe a test plan to be as many people have different views on the matter. A test plan combines the tests logistics with the test strategy. I would like to think we can all agree than during testing many things change but how often are test plans updated? In my experience very rarely and if they are it is a costly

In the basic test plans I’ve seen in companies contains some or all of the following(I might have missed some):

• Intro/Background
• Scope/out of scope
• Features to be tested
• Test Items
• Approach/Strategy
• Entry/Exit criteria
• Suspension criteria
• Test Deliverable documents
• Schedule/Estimations
• Staffing
• Risks, Assumptions and Dependencies
• Approvals

Creating documents like these are very expensive while they have very little impact on how the tester tests. What in this plan adds real value?;for me it is the strategy. So much of the above can be managed verbally. Are we really at the point whereby if we have a build doesn’t work and we don’t believe testing can continue we need to state it in a document? The same goes for testing deliverable documents? Do developers create documents to say they will create more documents? Is there not an easier, faster, less costly expensive way to manage the information. Of course there is, a mind map for example is much more effective approach. Less time spent on formatting, the odd spelling mistake, sections that do not impact testing like the background of the project which is in 2-3 other documents.

I’ve experienced a test plan where the feedback was to copy and paste the detail into the template so it looks like the others, add more detail on the background, add in test data before testing starts, confirm you will send daily stats, breakdown the features into finer details and the add in the people on the project. People might argue these are important pieces of information. I think these can be managed within a team or teams using common sense. Not one person questioned how the tester was going to test the product. For them it wasn’t as important as testing logistics. So with all the logistics in place does this really change the quality of testing completed or does it still come down to having a skilled tester doing intellectual testing.

Like to hear peoples views…always an interesting topic

[Krister]

I agree that a typical test plan with the items above will soon be outdated and not maintained. That’s my experience. However the strategy and especially the intended test environment and test automation strategy is important since it requires investment in both equipment and hours. It is nice to have a management agreement on that in writing.
Initially the test plan may be of help to cost estimate the testing part of the project.

Entry / exit / suspension criteria are often overridden in the heat of the moment.

[Marco Foley]

I agree that the automation strategy would need to be documented as it would possible require tools, resources etc. It also needs to be carefully assessed to see if there is a need for it, what is the strategy and how it will be maintained. Too often these aspects are not critically thought about and automation strategies fail; leading to high costs and no value.

Estimation is nearly impossible to know before you start testing. Of course if you are testing a product whereby you have previous experience you might have closer estimates. In my experience testing is estimated at the start and is rarely accurate. So many testers are just not willing to say at this point “I dont know” but in a weeks time I will have a better idea.

[stefan]

“Is there value in the heavy detailed Test Plans?”

Value is something personal for whomever requires those plans. Even if they don’t ever read it, they might require you to do them. You can either do what you’re told or refuse/argue and accept the consequences.

As a tester you could find value with anything that helps you do your job better, even a one page test plan:

https://dojo.ministryoftesting.com/lessons/the-one-page-test-plan

[Archana]

Even I believe that the test plan needs to be documented. You may keep it short but all the necessary points need to be covered. Whenever I take up a testing assignment, I create a test plan that clearly states things like, what is in and out of scope, timelines, deliverables, tools used, risks and get it approved. So, tomorrow if there is any conflict with the client, I always have the document to point to.

[Melvin]

For me, test plans shouldn’t be too much detailed, is good to have room for innovative and creative approaches to test a feature. Nevertheless the test plan should have info enough to be able to “guide” other testers about possible scenarios and steps to take, this is the main value of the detail for me.

In summary not too much, not too little.

[Aleksandra]

And I would say: IT DEPENDS 🙂 In my ideal world we all have time to produce a pretty full-scoped Test Plan, which covers all the points mentioned by @foleym. BUT in fact it’s utopia. So I would suggest to make clear if we have a short-dated project, or the big architecture, if the code is self-explanatory or it’s crazy chaotic etc.

I love possibly highest-detailed Test Cases – but the test plan seems enough when having very rough scope with a crucial focus on features and dependencies.

Of course we should take care of the fact, what is the purpose of the Test Plan. Definitely it’s not even needed to execute tests (e.g.in creative, highly effective exploratory sessions), but for sure the Test Plan is very helpful when there are more testers or the testers are in distributed places.

I’d say also – if we have some manual, instruction, handbook, then the Test Plan can be less detailed and should be rather the set of names (what technology, modules, features) than the prose of round sentences.

[Alexandru]

I also think it depends. Which methodology you use in developing the product: Waterfall, Agile, other? Or type of company: outsourcing(where you might need to show/agree with customer test strategy/plans) or own products one(where company test approach and strategy is defined for all products). Also if it is a safety critical product you might need to comply to regulations and then a detailed test plan might be required.

In Agile days I wouldn’t spent to much time to add heavy details to test plan. I would use a mind map as suggested before, or guidelines more – what to be attentive in testing a product and establish some common sense rules for reporting, planning etc.

Test cases will also be used to calculate coverage (especially when you have automated tests) and serve as test documentation. Also I prefer to have light test scenarios and give the tester some maneuver spare but in the same time to test what it is needed. Test cases linked to requirements will also offer a view on coverage.

Another aspect is the level of experience of testers and how familiar they are with the product they test. For testers at the beginning of their career you might want to have heavier documentation and reporting.

I don;t think there is a “right” or “wrong” approach to this. I always try to find what I gain from test documentation. Having no documentation, definitely not. How detailed – depends.

[sneha shinde]

A test plan is nothing but a written document that in detail describes the activities and the testing scope. It is a part of the formal process of testing any product or software under a project.

Template Design for a Test Plan:

The layout and content of a product test plan differ contingent upon the standards, processes, and test management tools being used.In any case, the accompanying format, which depends on IEEE standard for software test documentation, gives a rundown of what a test plan can/ought to contain.

Responsibilities:
– List down the roles and responsibilities of each test team member.

Risks:
Jot down the risks identified.

Also specify the contingency and mitigation plan for each risk.
[moderated]

[Author]

Posts