UNIT-6 Testing Policies

Test Planning, Components, Attachments, Locating Test Items, Test Reports, Role of Three Critical Groups,
Building A Test Group, Structure, Technical training and certification, Career paths, Integrating testing activities

6.1 Test Planning

A plan is a document that provides a framework or approach for achieving a set of goals. Test planning is an essential
practice for any organization that wishes to develop a test process that is repeatable and manageable.
A plan describes what specific tasks must be accomplished, who is responsible for each task, what tools, procedures,
and techniques must be used, how much time and effort is needed, and what resources are essential. A plan also contains
milestones.
Milestone: Milestones are tangible events that are expected to occur at a certain time in the project’s lifetime.
Managers use them to determine project status.
Essential high-level Items of test plan: Software Quality Assurance (V&V)
1. Overall test objectives. Plan
2. What to test (scope of the tests)?
3. Who will test?
4. How to test? Master Test Plan Review plan: Inspection and walkthroughs
5. When to test?
6. When to stop testing?
Unit Test Integration Test Plan System Test Plan Acceptance Test Plan
Plan
[Figure 6.1.1: Hierarchy of Test Plan]

At the top of the plan hierarchy there may be a software quality assurance plan. This plan gives an overview of all
verification and validation activities for the project, as well as details related to other quality issues such as audits, standards,
configuration control, and supplier control. Below that in the plan hierarchy there may be a master test plan that includes an
overall description of all execution-based testing for the software system. A master verification plan for reviews inspections/
walkthroughs would also fit in at this level.
The master test plan itself may be a component of the overall project plan or exist as a separate document. Depending
on organizational policy, another level of the hierarchy could contain a separate test plan for unit, integration, system, and
acceptance tests.

6.2 Components (of test planning)

The basic test plan components should appear in the master test plan and in each of the level based test plans (unit,
integration, etc.) with the appropriate amount of detail.
1) Test Plan Identifier: Each test plan should have a unique identifier so that it can be associated with a specific project
and become a part of the project history. The project history and all project-related items should be stored in a project
database or come under the control of a configuration management system. Organizational standards should describe the
format for the test plan identifier and how to specify versions, since the test plan, like all other software items, is not
written in stone and is subject to change. A mention was made of a configuration management system. This is a tool that
supports change management.
2) Introduction: In this section the test planner gives an overall description of the project, the software system being
developed or maintained, and the software items and/or features to be tested. It is useful to include a high-level
description of testing goals and the testing approaches to be used. References to related or supporting documents should
also be included in this section, for example, organizational policies and standards documents, the project plan, quality
assurance plan, and software configuration plan.
3) Items to be tested: This is a listing of the entities to be tested and should include names, identifiers, and version/revision
numbers for each entity. The items listed could include procedures, classes, modules, libraries, subsystems, and systems.
References to the appropriate documents where these items and their behaviors are described such as requirements and
design documents, and the user manual should be included in this component of the test plan.
4) Features to be tested: In this component of the test plan the tester gives another view of the entities to be tested by
describing them in terms of the features they encompass. Features may be described as distinguishing characteristics of
a software component or system. In this component of the test plan references to test design specifications for each
feature and each combination of features are identified to establish the associations with actual test cases
5) Approach: This section of the test plan provides broad coverage of the issues to be addressed when testing the target
software. Testing activities are described. The level of descriptive detail should be sufficient so that the major testing
tasks and task durations can be identified. The planner should also include for each feature or combination of features,
the approach that will be taken to ensure that each is adequately tested. Tools and techniques necessary for the tests
should be included. Expectations for test completeness and how the degree of completeness will be determined should
be described. Constraints on testing should be also be included in this section, such as time and budget limitations. The
planner should also describe how the testing process will be monitored to insure it is going according to plans. Criteria
to be used for making decisions on when to stop testing must also be included.
6) Items to pass/fail criteria: Given a test item and a test case, the tester must have a set of criteria to decide on whether
the test has been passed or failed upon execution. The master test plan should provide a general description of these
criteria
7) Suspension and Resumption Criteria: In this section of the test plan, criteria to suspend and resume testing are
described. In the simplest of cases testing is suspended at the end of a working day and resumed the following morning.
For some test items this condition may not apply and additional details need to be provided by the test planner. The test
plan should also specify conditions to suspend testing based on the effects or criticality level of the failures/defects
observed. Conditions for resuming the test after there has been a suspension should also be specified. For some test items
resumption may require certain tests to be repeated.
8) Test Deliverables: Execution-based testing has a set of deliverables that includes the test plan along with its associated
test design specifications, test procedures, and test cases. Deliverables may also include other documents that result from
testing such as test logs, test transmittal reports, test incident reports, and a test summary report Each organization should
decide which of these documents is required for a given project. Another test deliverable is the test harness. This is
supplementary code that is written specifically to support the test efforts, for example, module drivers and stubs.
9) Testing Tasks: In this section the test planner should identify all testing-related tasks and their dependencies. A Work
Breakdown Structure is a hierarchical or tree like representation of all the tasks that are required to complete a project.
High-level tasks sit at the top of the hierarchical task tree. Leaves are detailed tasks sometimes called work packages that
can be done by 1–2 people in a short time period, typically 3–5 days. The WBS is used by project managers for defining
the tasks and work packages needed for project planning.
10) The Testing Environment: The test planner describes the software and hardware needs for the testing effort. For
example, any special equipment or hardware needed such as emulators, telecommunication equipment, or other devices
should be noted. The planner must also indicate any laboratory space containing the equipment that needs to be reserved.
The planner also needs to specify any special software needs such as coverage tools, databases, and test data generators.
Security requirements for the testing environment may also need to be described.
11) Responsibilities: The staff who will be responsible for test-related tasks should be identified. This includes personnel
who will be:
 transmitting the software-under-test;
 developing test design specifications, and test cases;
 executing the tests and recording results;
 tracking and monitoring the test efforts;
 checking results;
 interacting with developers;
 managing and providing equipment;
 developing the test harnesses;
 interacting with the users/customers.
This group may include developers, testers, software quality assurance staff, systems analysts, and customers/users.
12) Staffing and Training Needs: The test planner should describe the staff and the skill levels needed to carry out test
related responsibilities such as those listed in the section above. Any special training required to perform a task should
be noted.
13) Scheduling: Task durations should be established and recorded with the aid of a task networking tool. Test milestones
should be established, recorded, and scheduled. These milestones usually appear in the project plan as well as the test
plan. They are necessary for tracking testing efforts to ensure that actual testing is proceeding as planned. Schedules for
use of staff, tools, equipment, and laboratory space should also be specified. A tester will find that PERT and Gantt charts
are very useful tools for these assignments
14) Risks and Contingencies: Every testing effort has risks associated with it. Testing software with a high degree of
criticality, complexity, or a tight delivery deadline all impose risks that may have negative impacts on project goals.
These risks should be: (i) identified, (ii) evaluated in terms of their probability of occurrence, (iii) prioritized, and (iv)
contingency plans should be developed that can be activated if the risk occurs. It is important for the test planner to
identify test-related risks, analyse them in terms of their probability of occurrence, and be ready with a contingency plan
when any high-priority risk related event occurs.
15) Testing Costs: The IEEE standard for test plan documentation does not include a separate cost component in its
specification of a test plan. This is the usual case for many test plans since very often test costs are allocated in the overall
project management plan. If the test plan is an independent document prepared by the testing group and has a cost
component, the test planner will need tools and techniques to help estimate test costs. Test costs that should be included
in the plan are:
• costs of planning and designing the tests;
• costs of acquiring the hardware and software necessary for the tests
• costs to support the test environment;
• costs of executing the tests;
• costs of recording and analyzing test results;
• tear-down costs to restore the environment.
Other costs related to testing that may be spread among several projects are the costs of training the testers and the costs of
maintaining the test database.
Test cost impact items:
 The nature of the organization; its testing maturity level, and general maturity.
 The nature of the software product being developed.
 The scope of the test requirements.
 The level of tester ability.
 Knowledge of the project problem domain.
 The level of tool support and Training requirements
16) Approvals: The test plan(s) for a project should be reviewed by those designated by the organization. All parties who
review the plan and approve it should sign the document. A place for signatures and dates should be provided

6.3 Attachments (of test planning)

The details needed for organizing and executing the tests, For example, what are the required inputs, outputs, and procedural
steps for each test; where will the tests be stored for each item or feature; will it be tested using a black box, white box, or
functional approach? are generally attached to the test plan as documents.
Test Design Specifications:
 A test design specification is a test deliverable that specifies the requirements of the test approach.
 It is used to identify the features covered by this design and associated tests for the features.
 The test design specification also has links to the associated test cases and test procedures needed to test the features,
and also describes in detail pass/fail criteria for the features
 The test design specification helps to organize the tests and provides the connection to the actual test inputs/outputs and
test steps.
To develop test design specifications many documents such as the requirements, design documents, and user manual are
useful A test design specification should have the following components according to the IEEE standard
  Test Design Specification Identifier
 Features to Be Tested
 Approach Refinements
 Test Case Identification
 Pass/Fail Criteria
Test Case Specifications: It defines the test cases required to execute the test items named in the associated test design
specification. There are several components in this document.
 Test Case Specification Identifier
 Test Items
 Input Specifications
 Output Specifications
 Special Environmental Needs
 Special Procedural Requirements
 Inter case Dependencies
Test Procedure Specifications: A procedure in general is a sequence of steps required to carry out a specific task. In this
attachment to the test plan the planner specifies the steps required to execute a set of test cases The test procedure specification
has several subcomponents. They are
 Test Procedure Specification Identifier
 Purpose
 Specific Requirements
 Procedure Steps:
Steps in Procedure:
(i) Setup: to prepare for execution of the procedure
(ii) Start: to begin execution of the procedure
(iii) Proceed: to continue the execution of the procedure
(iv) Measure: to describe how test measurements related to outputs will be made
(v) Shut down: to describe actions needed to suspend the test when unexpected events occur
(vi) Restart: to describe restart points and actions needed to restart the procedure from these points
(vii) Stop: to describe actions needed to bring the procedure to an orderly halt
(viii) Wrap up: to describe actions necessary to restore the environment
(ix) Contingencies: plans for handling anomalous events if they occur during execution of this
procedure

6.4 Locating Test Item – Transmittal Reports

Suppose a tester is ready to run tests on an item on the date described in the test plan. She needs to be able to locate the item
and have knowledge of its current status. This is the function of the Test Item Transmittal Report. This document is not a
component of the test plan, but is necessary to locate and track the items that are submitted for test. Each Test Item Transmittal
Report has a unique identifier. It should contain the following information for each item that is tracked
(i) version/revision number of the item;
(ii) location of the item;
(iii) persons responsible for the item (e.g., the developer);
(iv) references to item documentation and the test plan it is related to;
(v) status of the item;
(vi) approvals—space for signatures of staff who approve the transmittal.

6.5 Test Reports

The test plan and its attachments are test-related documents that are prepared prior to test execution. There are additional
documents related to testing that are prepared during and after execution of the tests. The IEEE Standard for Software Test
Documentation describes the following documents
1) Test Log 2) Test Incident Report 3) Test Summary Report
1) Test Log: The test log should be prepared by the person executing the tests. It is a diary of the events that take place
during the test. It supports the concept of a test as a repeatable experiment. The test log is invaluable for use in defect
repair. It gives the developer a snapshot of the events associated with a failure. The test log, in combination with the test
incident report which should be generated in case of anomalous behavior, gives valuable clues to the developer whose
task it is to locate the source of the problem.
The test log is valuable for:
(i) regression testing that takes place in the development of future releases of a software product, and
(ii) circumstances where code from a reuse library is to be reused.
The test log can have many formats. It has the following sections:
• Test Log Identifier
• Description
• Activity and Event Entries
Activity and Event Entries include the following:
1. Execution description
2. Procedure results
3. Environmental information
4. Anomalous events and Incident report identifiers
2) Test Incident Report: The tester should record in a test incident report (sometimes called a problem report) any event
that occurs during the execution of the tests that is unexpected, unexplainable, and that requires a follow-up investigation.
It includes:
1. Test Incident Report identifier
2. Summary
3. Incident description
4. Impact
3) Test Summary Report: This
report is prepared when testing
is complete. It is a summary of
the results of the testing
efforts. It also becomes a part
of the project’s historical
database and provides a basis
for lessons learned as applied
to future projects. When a
project post-mortem is
conducted, the Test Summary
Report can help managers,
testers, developers, and SQA
staff to evaluate the
effectiveness of the testing
efforts.
Test Summary Report
Includes the following: [Figure 6.5.1 Test Documents Hierarchy]
1. Test Summary Report identifier
2. Variances
3. Comprehensiveness assessment
4. Summary of results
5. Evaluation
6. Summary of activities
7. Approvals
6.6 Role of a three critical groups
In the TMM framework three groups
were identified as critical players in the
testing process. They all work together
toward the evolution of a quality testing
process. These groups were managers,
developers/ testers, and users/clients. In
TMM terminology they are called the
three critical views (CV). Each group
views the testing process from a
different perspective that is related to
their particular goals, needs, and
requirements.
 The manager’s view involves
commitment and support for those
activities and tasks related to
improving testing process quality.
 The developer/tester’s view
encompasses the technical
activities and tasks that when
applied, constitute best testing
practices.
The user/client view is defined as a
cooperating or supporting view. [Figure 6.6.1: Summary of critical group roles]
Reaching TMM level 2: summary of critical group roles.

6.7 Building a Testing Group, structure

Major activities required to manage the testing process are:
(1). Organizing: Organizing includes selecting
organizational structures, creating
positions, defining responsibilities, and
delegating authority. Hiring staff for the
testing group, organizing the testing staff
members into teams, motivating the team
members, and integrating the team into the
overall organizational structure
(2). Staffing: Staffing activities include filling
positions, assimilating new personnel,
education and training, and staff evaluation
(3). Directing: Directing includes providing
leadership, building teams, facilitating
communication, motivating personnel,
resolving conflicts, and delegating
authority. Steps in forming a test group [Figure 6.7.1: Steps in forming a test group]
Bartol and Martin’s guidelines for evaluation of employees. It can be applied to any type of team and organization.
They describe four categories for employees based on their performance:
(I). retain,
(II). likely to retain,
(III). likely to release,
(IV). release.
For each category, appropriate actions need to be taken by the manager to help employee and employer.
A test organization is expensive; it is a strategic commitment. Given the complex nature of the software being built, and its
impact on society, organizations must realize that a test organization is necessary and that it has many benefits. By investing
in a test organization a company has access to a group of specialists who have the responsibilities and motivation to:
 maintain testing policy statements
 plan the testing efforts
 monitor and track testing efforts so that they are on time and within budget
 measure process and product attributes
 provide management with independent product and process quality information
 design and execute tests with no duplication of effort
 automate testing
 participate in reviews to insure quality are meet.
The duties of the team members may vary in individual organizations. The following gives a brief description of the duties
for each tester that are common to most organizations.
(1). The Test Manager: In most organizations with a testing function, the test manager (or test director) is the central person
concerned with all aspects of testing and quality issues. The test manager is usually responsible for test policy making,
customer interaction, test planning, test documentation, controlling and monitoring of tests, training, test tool acquisition,
participation in inspections and walkthroughs, reviewing test work, the test repository, and staffing issues such as hiring,
firing, and evaluation of the test team members. He or she is also the liaison with upper management, project
management, and the quality assurance and marketing staffs.
(2). The Test Lead: The test lead assists the test manager and works with a team of test engineers on individual projects. He
or she may be responsible for duties such as test planning, staff supervision, and status reporting. The test lead also
participates in test design, test execution and reporting, technical reviews, customer interaction, and tool training.
(3). The Test Engineer: The test engineers design, develop, and execute tests, develop test harnesses, and set up test
laboratories and environments. They also give input to test planning and support maintenance of the test and defect
repositories.
(4). The Junior Test Engineer: The junior test engineers are usually new hires. They gain experience by participating in
test design, test execution, and test harness development. They may also be asked to review user manuals and user help
facilities defect and maintain the test and defect repositories.

6.8 Technical Training and Certification

With the realization that software testing is an important field of study, many colleges and universities have begun
to offer classes on the subject. If you’re currently in an engineering or computer degree program, it would be well worth your
time to enroll in one of these classes. Even if your plans are to become a programmer or engineer, gaining a better knowledge
of software testing can help you perform your job even better.
Many community and technical colleges are now offering day and evening classes on software testing and the use
of popular software testing tools. Some even award associate degrees and certificates in software testing.
Another option for training is to attend professional software testing conferences. Held throughout the year and in
various parts of the U.S. and even the world, these conferences provide an opportunity for you to hear speakers from across
the testing industry. Class material spans the entire range from very basic to very advanced and technical. The best part of
these conferences is having the opportunity to meet and talk with fellow software testers, sharing ideas, war stories, and
solutions. The following list represents some of the more popular conferences, but definitely not all of them. Presence or
absence doesn’t reflect an endorsement or an opinion.
(A). International Conference and Exposition on Testing Computer Software (TCS), sponsored by the U.S. Professional
Development Institute (www.uspdi.org). TCS features international speakers, presentations of current software testing
best practices by experienced professionals, opportunities to share lessons and experiences with your peers, and a
vendor show of products and services.
(B). International Quality Week, sponsored by Software Research, Inc. (www.soft.com). The mission of the Quality
Week and Quality Week Europe Conferences is to “bring advanced technology R&D work relating to software quality,
 testing and process, contemporary software quality and testing needs, and knowledge and experience from the software
quality industry together in a balanced technical forum.”
(C). International Software Testing Conference (ISTC), sponsored by the Quality Assurance Institute
(www.qaiusa.com). ISTC is a weeklong conference featuring expert speakers from across the software testing and
quality assurance industry. Topics range from basic software testing to test automation to testing specific new
technologies.
(D). Software Testing Analysis & Review (STAR), sponsored by Software Quality Engineering (www.sqe.com/stareast
and www.sqe.com/starwest). The STAR conferences are focused exclusively on software testing and software
engineering. They provide classes, tutorials, and discussions by software testing experts and hold an exposition where
test tool, technology, and service companies demonstrate their products.
(E). International Conference on Software Quality (ICSQ), sponsored by the Software Division of the American Society
for Quality (www.asq-software.org). ICSQ, like the other conferences, provides an opportunity to share testing ideas
and methods with other software testing and quality assurance professionals.
(F). International Conference on Software Testing (ICSTEST), sponsored by Software Quality Systems
(www.icstest.com). ICSTEST is an international testing conference held in Germany. It’s a forum for presentations,
tutorials, discussions, and exchange of experiences on software testing.
(G). The Second World Congress for Software Quality (2WCSQ) (www.juse.or.jp/e-renmei/2WCSQMAIN.htm).
2WCSQ is a worldwide conference on software quality with members from more than 27 countries. The year 2000
conference was held in Japan.

Internet Links
The Internet has a wealth of material on software testing. You could always do a search for “software testing” or “software
test,” but here’s a list of popular Web sites dedicated to software testing and software bugs that will get you started:
(A). BugNet (www.bugnet.com) publicizes bugs found in commercial software and points you to the appropriate fixes.
(B). Software Testing Hotlist (www.io.com/~wazmo/qa) lists dozens of pointers to software testing–related Web sites and
articles.
(C). Software Testing Online Resources (www.mtsu.edu/~storm) is the self-proclaimed “nexus of Software Testing Online
Resources…designed to be a ‘first-stop’ on the Web for software testing researchers and practitioners.”
(D). QA Forums (www.qaforums.com) provide ongoing discussions of software testing, automated testing, test
management, test tools, and many other topics.
(E). The newsgroup comp.software.testing and its FAQ (frequently asked questions) document at
www.faqs.org/faqs/software-eng/testing-faq provide lots of ongoing discussions by testers and test managers regarding
tools, techniques, and projects.
(F). The newsgroup comp.risks describes and analyzes recent software failures.
(G). The Risks Digest (catless.ncl.ac.uk/Risks/) is a forum on risks to the public in computers and related systems.

Professional Organizations
Several professional nonprofit organizations are dedicated to software, software testing, and software quality assurance that
may be of interest to you. Their Web sites provide details on their specific area of coverage:
(A). The American Society for Quality (ASQ) at www.asq.org and its software division at www.asq-software.org sponsor
the National Quality Forum annually in October (national quality month). They publish journals and articles on quality
and administer the Certified Quality Engineer (CQE) and the Certified Software Quality Engineer (CSQE)
designation.
(B). The Association of Computing Machinery (ACM) at www.acm.org and its Special Interest Group on Software
Engineering (SIGSOFT) at www.acm.org/sigsoft has more than 80,000 members in educational and scientific
computing. The software engineering interest group publishes a bimonthly newsletter with a popular forum titled
“Risks to the Public,” which details recent serious software bugs.
(C). The Society for Software Quality (SSQ) at www.ssq.org lists its vision as “To be recognized as the Society for those
interested in promoting ‘quality’ as a universal goal for software.”
6.9 Career Paths:
The areas of progression people look for in a testing career:
 technical challenge
 learning opportunities
 increasing responsibility and
Test Dept. Head
authority Technical Architect Manager Management
 increasing independence Growth
Test Lead
Growth

 ability to have a significant Sr. Test Engineer

influence on an organization’s success Test Engineer

 rewards and recognition

To be an expert, Successful and ranked professional tester, there are three stages from which any tester has to pass
through. At the beginning of this stage, the trust and confidence level between the individual and the organization just starts
to evolve. Most professionals, when they start their career with an organized (especially fresh from schools), are simply given
instructions to be followed. At this stage of their career, they have fairly detailed instructions on what tasks they have to do
and how they should go about carrying out the defined task, this is required as both the individual and the organization try to
get a feel of each other’s strengths and evolve a method of working together. Thus at this stage, the work
a. Is fairly task oriented.
b. Comes with detailed instructions; and
c. Leaves little requirement for decision making
A demonstration of capability in the assigned task at the follow stage leads to the individual getting recognized as trustworthy
as well as enables the individual is ready to move from just executing tasks by following instructions to formulating tasks,
for himself as well as for others. At this stage of the career, there is an increased focus on
a. Independent decision making
b. Clarity in communication to assigned work for others; and
c. Interacting with other groups.
When an individual reaches the formulating stage. s/he has demonstrated an ability to plan ahead as well as to delegate and
monitor work. At this stage, the individual has created a competent next level to take on some of the function s/he has been
performing. This takes him or her to the next stage of playing an influencing role to mentor and nurture other individuals.
At this influencing stage, the individual becomes a role model. Others in the organization feel comfortable approaching these
role models for advice and guidance for the chosen tasks. At this stage, these role models are ready to assume additional
responsibilities in other dimensions. When they assume these additional responsibilities, they may begin in the following
stage for the new areas they are starting off, presumable under the tutelage of an existing role model in the new area.
Responsibility of a Test Engineer
Task Follow Formulate Influence
Following the test processes for executing test, maintaining test, and so on 
Filing high-quality defects, usable by developers 
Categorizing defects 
Adhering to schedules specified 
Developing high-quality documentation 
Responsibility of a Sr. Test Engineer
Task Follow Formulate Influence
Following test processes for executing tests, maintaining tests and so on.  
Filing high-quality defects, usable by developers  
Categorizing defects 
Adhering to schedules specified  
Developing high-quality documentation  
Helping development in debugging and problem isolation 
Contribution to enhancing processes for testing 
Generation of metrics related to testing 
Responsibilities of a Test Lead
Task Follow Formulate Influence
Review of test cases, test design and so on at the module level  
 Planning a test strategy and test plan for the module 
Allocating tasks to individuals 
Mentoring tasks given to individuals  
Making technology and tools choices for module testing  
Mentoring team members and assisting them in technical matters. 
Interaction with development teams for debugging and problem reproduction 
Interaction with product documentation teams for debugging and problem reproduction
Generation and analysis of metrics related to testing at a module level  
Overall responsibility for test quality at a module level  
Responsibilities of a Test Manager/Departmental Head
Task Follow Formulate Influence
Planning the test strategy at a product or organizational level  
Driving quality at the product or organizational level  
Allocation of resources across the board.  
Making technology and tool choices  
Risk Management  
Inter-group co-ordination  
Hiring and retaining top talent into the organization  
Helping team members with career planning  
Implementing organizational policies   
Instilling organizational values in the team  
Effective management of meetings  
Keeping everyone in sync by effective communication  

6.10 Integrating Testing Activities

Ultimately, the success of a product depends on the effectiveness of integration of the development and testing activities.
These job functions have to work in tight unison between themselves and with other groups such as product support, product
management and so on. The schedules of testing have to be linked directly to product release. Thus, project planning for the
entire product should be done in holistic way, encompassing the project plan for testing and development. The following are
some of the points to be decided for this planning.
1) Sync points between development and testing as to when different types of testing can commence. For example, when
integration testing could start, when system testing could start and so on. These are governed by objective entry criteria
for each phase of testing (to be satisfied by development).
2) Service level agreements (SLAs) between development and testing as to how long it would take for the testing team to
complete the testing. This will ensure that testing focuses on finding relevant and important defects only.
3) Consistent definition of the various priorities and severities of the defects. This will bring in a shared vision between
development and testing teams, on the nature of the defects to focus on.
4) Communication mechanisms to the documentation groups to ensure that the documentation is kept in sync with the
product in terms of known defects, workarounds and so on.
The purpose of the testing team is to identify the defects in the product and the risks that could be faced by releasing the
product with the existing defects. Ultimately, the decision to release or not is a management decision, dictated by market
forces and weighing the business impact for the organization and the customers.