Test Items in IEEE829

Question

Can anybody tell with example what is the meaning of Test Items in test Plan document (as per IEEE 829). Most of the sites just specify only theoretical aspects without mentioning practical examples. I am not sure what is the item that we are not testing. Obviously all the items have to be tested. Also we have separate sections for Features to be tested and not to be tested. Is this not redundant with features to be tested? Also if we indicate the list of features not to be tested, why we need to indicate the list f features to be tested? When features are listed in requirement document, obviously all of them have to be tested. But exclusions if any may be listed in Features Not to be Tested I guess.

Additional Comments dated 23-August My question is how Items to be tested is different from features to be tested?Also, requirement document keeps changing. So SRS and release notes could be input to test team.Features not to be tested could be features that may not be testable or may be tested elsewhere or few features that are not included in the current release as indicated in the release document. Accordingly such exceptions could be specified in Features Not to be tested section. So the point is that features to be tested need not be there in test plan, instead specify only Features not to be tested. Obviously features to be tested = All requirements from the SRS - Features not to be tested.

Answer 1

Test Items were:

•   Version of product (what you are testing at each stage)

•   Design decomposition (relationship of specific modules to test plan, test cases)

•   Limitations of product under test (restrictions, assumptions, caveats, etc.)

•   Other product-level restraints on testing

Answer 2

For the part of your question

"Also we have separate sections for Features to be tested and not to be tested. Is this not redundant with features to be tested? Also if we indicate the list of features not to be tested, why we need to indicate the list f features to be tested? When features are listed in requirement document, obviously all of them have to be tested. But exclusions if any may be listed in Features Not to be Tested I guess."

I will try to explain this to you in a simple way. If we are both referring to the standard template of the test plan then both these parts "Features to be tested" and "Features not to be tested" come under the header "Scope". Now unless and until we define the scope it is "Undefined". This is also correct in terms of Synonyms & Antonym (Define, Undefined) and also in terms of Maths i.e. anything which is not define is undefined = infinity. So, if you don't define the scope then it means your scope is infinite and you are in trouble at that time, because "Infinite - X = Infinite".

Requirement documents are for our understanding, analysis and reference. Once you have created your test plan you should stick to it and execute your testing as per this plan only, so you should very clearly know from this plan that what, when and how you need to test and what you don't need to test or worry about.

In addition to it, the moment you say to your manager and/or client that you don't know the scope included and excluded, you are gone. Both of them want everything to be clearly communicated to whole team in black & white so that everyone is on same page, as there are always exceptions associated to Requirement documents. And as part of QA too you should be very clear about your scope of testing. Without this you are like a person in middle of sea without any magnetic compass.

Features to be tested + Features not to be tested = Scope = Requirement document, but don't say it like Features not to be tested = Requirement document - Features to be tested. As scope is being built by these two sub-sections, not the other way round.

Live example

I'm too working on a test plan where we are defining the same things, and while doing so many a times you will have to again break a use case and a features into sub parts like one of the feature is creating a new record and then digitally sign it using bio-metric authentication via a finger print scanner or a iPad. Now, out of this whole feature we can't test the bio-metric authentication part as hardware is required for the same which is not available, so we have clearly mentioned this part in out of scope section. So, that client and team know that this thing has not been validated and provided effort also doesn't include some part of the feature (a justification for effort too). Once the scope is clear and defined we can start our testing.

It is not always 'Everything or all items are to be tested' - It is this can/will be tested and this can't/will not be tested (where this = definite value); depending upon multiple factors like Resources, Skills, Timeline, Priority and Complexity etc. This is how things work practically.