Planning a test

A test plan is a document detailing the objectives, resources, and processes for a specific test for
a software or hardware product. The plan typically contains a detailed understanding of the
eventual workflow.

What is a Test Plan?

A Test Plan refers to a detailed document that catalogs the test strategy, objectives, schedule,
estimations, deadlines, and the resources required for completing that particular project. Think
of it as a blueprint for running the tests needed to ensure the software is working properly –
controlled by test managers.

A well-crafted test plan is a dynamic document that changes according to progressions in the
project and stays current at all times. It is the point of reference, based on which testing
activities are executed and coordinated among a QA team.

The test plan is also shared with Business Analysts, Project Managers, Dev teams, and anyone
else associated with the project, This mainly offers transparency into QA activities so that all
stakeholders know how the software will be tested.

The plan is built by QA managers or leads based on input from QA (and sometimes, non-QA)
team members. Creating it should not take more than 1/3rd of the time allocated for the entire
project.

Why are Test Plans important?

They help individuals outside the QA teams (developers, business managers, customer-facing
teams) understand exactly how the website or app will be tested.They offer a clear guide for QA
engineers to conduct their testing activities.

They detail aspects such as test scope, test estimation, strategy, and so on. Collating all this
information into a single document makes it easier to review by management personnel or to
re-use for other projects.

Components of a Test Plan

Scope: Details the objectives of the particular project. Also, it details user scenarios to be used in
tests. If necessary, the scope can specify what scenarios or issues the project will not cover.

Schedule: Details start dates and deadlines for testers to deliver results.

Resource Allocation: Details which tester will work on which test.

Environment: Details the nature, configuration, and availability of the test environment.

Tools: Details what tools are to be used for testing, bug reporting, and other relevant activities.

Defect Management: Details how bugs will be reported, to whom and what each bug report
needs to be accompanied by. For example, should bugs be reported with screenshots, text logs,
or videos of their occurrence in the code?

Risk Management: Details what risks may occur during software testing, and what risks the
software itself may suffer if released without sufficient testing.

Exit Parameters: Details when testing activities must stop. This part describes the results that
are expected from the QA operations, giving testers a benchmark to compare actual results to.
How to create a Test Plan?

Creating a Test Plan involves the following steps:

Product Analysis

Designing Test Strategy

Defining Objectives

Establish Test Criteria

Planning Resource Allocation

Planning Setup of Test Environment

Determine test schedule and estimation

Establish Test Deliverables

1. Product Analysis

Start with learning more about the product being tested, the client, and the end-users of similar
products. Ideally, this phase should focus on answering the following questions:

Who will use the product?

What is the main purpose of this product?

How does the product work?

What are the software and hardware specifications?

*In this stage, do the following:

Interview clients, designers, and developers

Review product and project documentation

Perform a product walkthroug

2. Designing Test Strategy

The Test Strategy document is developed by the test manager and defines the following:

*Project objectives and how to achieve them.

*The amount of effort and cost required for testing.

More specifically, the document must detail out:

Scope of Testing: Contains the software components (hardware, software, middleware) to be

Risks and Issues: Describes all possible risks that may occur during testing – tight deadlines,
insufficient management, inadequate or erroneous budget estimate – as well as the effect of
these risks on the product or business.

Test Logistics: Mentions the names of testers (or their skills) as well as the tests to be run by
them. This section also includes the tools and the schedule laid out for testing

3. Defining Objectives

This phase defines the goals and expected results of test execution. Since all testing intends to
identify as many defects as possible, the objects must include:

*A list of all software features – functionality, GUI, performance standards- that must be tested.

*The ideal result or benchmark for every aspect of the software that needs testing. This is the
benchmark to which all actual results will be compared.

4. Establish Test Criteria

Test Criteria refers to standards or rules governing all activities in a testing project. The two
main test criteria are:

*Suspension Criteria: Defines the benchmarks for suspending all tests. For example, if QA team
members find that 50% of all test cases have failed, then all testing is suspended until the
developers resolve all of the bugs that have been identified so far.

*Exit Criteria: Defines the benchmarks that signify the successful completion of a test phase or
project. The exit criteria are the expected results of tests and must be met before moving on to
the next stage of development. For example, 80% of all test cases must be marked successful
before a particular feature or portion of the software can be considered suitable for public use.

5. Planning Resource Allocation

*This phase creates a detailed breakdown of all resources required for project completion.
Resources include human effort, equipment, and all infrastructure required for accurate and
comprehensive testing.

*This part of the test plan decides the measure of resources (number of testers and equipment)
the project requires. This also helps test managers formulate a correctly calculated schedule and
estimation for the project.

6. Planning Setup of Test Environment

The test environment refers to software and hardware setup on which QAs run their tests.
Ideally, test environments should be real devices so that testers can monitor software behavior
in real user conditions. Whether it is manual testing or automation testing, nothing beats real
devices, installed with real browsers and operating systems are non-negotiable as test
environments. Do not compromise your test results with emulators or simulators.

7. Determining Test Schedule and Estimation

For test estimation, break down the project into smaller tasks and allocate time and effort
required for each.
Then, create a schedule to complete these tasks in the designated time with the specific amount
of effort.

Creating the schedule, however, does require input from multiple perspectives:

*Employee availability, number of working days, project deadlines, daily resource availability.

*Risks associated with the project which has been evaluated in an earlier stage.

8. Establish Test Deliverables

Test Deliverables refer to a list of documents, tools, and other equipment that must be created,
provided, and maintained to support testing activities in a project.

A different set of deliverables is required before, during, and after testing.

Deliverables required before testing

Documentation on

*Test Plan

*Test Design

Deliverables required during testing

Documentation on

*Test Scripts

*Simulators or Emulators (in early stages)

*Test Data

*Error and execution logs

Deliverables required after testing

Documentation on

*Test Results

*Defect Reports

*Release Notes

A test plan in software testing is the backbone on which the entire project is built. Without a
sufficiently extensive and well-crafted plan, QAs are bound to get confused with vague,
undefined goals and deadlines. This hinders fast and accurate testing unnecessarily, slowing
down results, and delaying release cycles.

The guidelines in this article are meant to help test managers and senior QA professionals with
constructing a test plan that helps with executing cleaner, faster, and more result-oriented tests.
A document called terms of specifications (TOS) helps you plan out your exam. You can also call
the document, table of specifications. It will make your test creation process more
methodological and organized. Creating a solid terms of specification will increase the likelihood
of you creating a test that is valid and reliable.

So how do you create a table of specifications?

Step 1- Determine the coverage of your exam

The first rule in making exams and therefore in making a document called table of specification
is to make sure the coverage of your exam is something that you have satisfactorily taught in
class. Select the topics that you wish to test in the exam. It is possible that you will not be able
to cover all these topics as it might create a test that is too long and will not be realistic for your
students in the given time. So select only the most important topics.

Step 2- Determine your testing objectives for each topic area

In this step, you will need to be familiar with bloom’s taxonomy of thinking skills. Bloom has
identified the hierarchy of learning objectives, from the lower thinking skills of knowledge and
comprehension to the higher thinking skills of evaluation and synthesis.

Bloom’s Taxonomy has six categories: (starting from lower level to highest) - (1) Knowledge, (2)
Comprehension, (3) Application, (4) Analysis, (5) Synthesis and (6) Evaluation

So for each content area that you wish to test, you will have to determine how you will test each
area. Will you test simply their recall of knowledge? Or will you be testing their comprehension
of the matter? Or perhaps you will be challenging them to analyze and compare and contrast
something. Again, this would depend on your instructional objectives in the classroom. Did you
teach them lower thinking skills or did you challenge them by making them think critically?

Your objectives per topic area should use very specific verbs on how you intend to test the
students using the bloom’s taxonomy. For example, for the 2nd level which is Comprehension,
verbs to use for the objectives would be explain or retell if it is in the context of understanding a
story.

For the cognitive level of analysis, verbs you can use for that taxonomy level is analyze, or show
the relationships.

It is important that your terms of specification reflect your instructional procedures during the
semester. If your coverage on a topic mostly dwelt on knowledge and comprehension of
material, then you cannot test them by going up the hierarchy of bloom’s taxonomy. Thus it is
crucial that you give a balanced set of objectives throughout the semester depending on the
nature of your students.

Step 3- Determine the duration for each content area

The next step in making the table of specifications is to write down how long you spent teaching
a particular topic. This is important because it will determine how many points you should
devote for each topic. Logically, the longer time you spent on teaching a material, then the more
questions should be devoted for that area.
Step 4- Determine the Test Types for each objective

Now that you have created your table of specifications for your test by aligning your objectives
to bloom’s taxonomy, it’s time to determine the test types that will accomplish your testing
objectives. For example, knowledge questions can be accomplished easily through multiple
choice questions or matching type exams.

If you want to test evaluation or synthesis of a topic, you will want to create exam type
questions or perhaps you will ask the students to create diagrams and explain their diagrams in
their analysis.

The important thing is that the test type should reflect your testing objective.

Step 5- Polish your terms of specification

After your initial draft of the table of specifications, it’s time to polish it. Make sure that you
have covered in your terms of specification the important topics that you wish to test. The
number of items for your test should be sufficient for the time allotted for the test. You should
seek your academic coordinator and have them comment on your table of specification. They
will be able to give good feedback on how you can improve or modify it.

After their approval, it’s time to put into action your blueprint by creating your exam. It would
be best to use a spreadsheet like Microsoft Excel so you could easily modify your Terms of
Specification in case

(sample yan ng TOS)

http://jenaisle-candidthoughts.blogspot.com/2015/05/sample-table-of-specifications-tos-
for.html?m=1