DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

NAME OF THE SUBJECT : Software Testing

Subject code : IT6004

Regulation : 2017

UNIT IV – TEST MANAGEMENT

IT6004 SOFTWARE TESTING

UNIT IV
TEST MANAGEMENT

People and organizational issues in testing – Organization structures for testing teams –
Testing services – Test Planning – Test Plan Components – Test Plan Attachments – Locating
Test Items – test management – test process – Reporting Test Results – The role of three groups
in Test Planning and Policy Development – Introducing the test specialist – Skills needed by a
test specialist – Building a Testing Group.

People and organizational issues in testing

Perceptions and Misconceptions about Testing:
1. Testing is not Technically Challenging
2. Testing does not provide me a career path or growth
3. I am put in Testing – What is wrong with me?
4. These folks are my Adversaries
5. Testing is what I can do in the end if I get time
6. There is no sense of Ownership in Testing
7. Testing is only Destructive

Testing is not Technically Challenging:

This argument may have been true about twenty years ago when most of the testing was
manual and products were somewhat simplistic. In the present scenario it is not the case because
of the following
• Requires a holistic understanding of the entire product rather than just a single module
• Requires thorough understanding of multiple domains
• Specialization in languages
• Use of tools
• Opportunities for conceptualization and out of the box thinking
• Significant investments are made in testing today- sometimes a lot more than in
development
• An internal test tool today could very well be one of those expensive test automation tools
of tomorrow
Testing does not provide me a career path or growth
Testing is not a devil and development is not an angel. Opportunities abound equally in
testing and development
I’m put in testing- what is wrong with me?
If a person is not suitable for development, for the same or similar reason, he or she may
not be suitable for testing either
These folks are my adversaries
Testing and Development teams should reinforce each other and not be at loggerheads
Testing is what I can do in the end if I get time
Testing is not what happens in the end of a project – it happens throughout and continues
even beyond a release

1
IT6004 SOFTWARE TESTING

There is no sense of Ownership in Testing:

Testing has deliverables just as development has and hence testers should have the same
sense of ownership
Testing is only Destructive:
Testing is destructive as much it is constructive, like the two sides of a coin
Comparison between Testing and Development Functions
• Testing is often a crunch time function
• Generally more elasticity is allowed in projects in earlier phases
• Testing functions are arguably the most difficult ones to staff
• Testing functionalities usually carry more external dependencies than development
functions
Providing Career paths for testing professionals:
The areas of progression people look for in a testing career
 technical challenge
 learning opportunities
 increasing responsibility and authority
 increasing independence
 ability to have a significant influence on an organization’s success
 rewards and recognition
Career progression for testing professionals:

Responsibilities of a test engineer:

2
IT6004 SOFTWARE TESTING

Responsibilities of a senior test engineer:

Responsibilities of a test lead:

3
IT6004 SOFTWARE TESTING

Responsibilities of a test manager / department head:

Organization Structures for Testing Teams

An appropriately designed organization structure can provide accountability to results
Dimensions of organization structures
1. Organization type
2. Geographic distribution
Types of Organizations
1. Product organizations
2. Service organizations
Product organizations – produce software products and take responsibility for the entire product
Service organizations – they do not take complete responsibility for the product. In testing context
they are organizations that provide testing services to other organizations that require them.
Geographic distribution of organization
1. Single site organization
2. Multi-site organization
Single site organization – all members are located in one single place
Multi-site organization – the team is scattered across multiple locations

Structures in single product companies:

4
IT6004 SOFTWARE TESTING

Structures in single product companies

Testing Team Structures for Single Product Companies:

Typical organization structures in early stages of a product

In a small organization in the early stages of development, there is very little management
hierarchy and people playing the roles of manager, leads and so on actually are also engineers
who are expected to act as individual contributors as well.
Advantages of the model adopted in small organizations
• Exploits the rear-loading nature of the testing activities
• Enables engineers to gain experience in all aspect of life style
• Is amenable to the fact that the organization mostly only has informal processes
• Some defects may be detected early
Disadvantages
• Accountability for testing and quality reduces
• Developers do not in general like testing and hence the effectiveness of testing suffers
• Schedule pressures generally compromise testing
• Developers may not be able to carry out the different types of tests
As the product matures and the processes evolve, a homogenous single product
organization doing both development and testing, splits into two distinct groups, one for
development and one for testing
Precautions to be take in the model are:
• Project manager should not buckle under pressure and ignore the findings and
recommendations of the testing team

5
IT6004 SOFTWARE TESTING

• Project manager should ensure that the development and testing teams do not view each
other as adversaries
• The testing team must participate in the project decision making and scheduling right
from the start

Organization Hierarchy
Structures for multi-product companies:

Structures for multi-product companies

The organization of test teams in multi product companies is dictated by the following facts
1. How tightly coupled the products are in terms of technology
2. Dependence among various products
3. How synchronous are the release cycles of products
4. Customer base for each product and similarity among customer bases for various products
Options available for organizing testing teams for a multi-product company
• A central “test think-tank / brain trust” team, which formulates the test strategy for the
organization.
• One test team for all the products
• Different test teams for each product
• Different test teams for different types of tests
• A hybrid of all the above methods
In order to assign the same level of importance to testing team as to development team, the testing
team is asked to report to the CTO as a peer to the design and development team

6
IT6004 SOFTWARE TESTING

Advantages:
• Developing a product architecture that is testable or suitable for testing
• Testing team will have better product and technology skills
• The testing team can get a clear understanding of what design and architecture are built for
and plan their tests accordingly
• The technical road map for product development and test suite development will be in
better sync.
The testing team reporting to the CTO is made effective by following the guidelines
• The team should be small in number
• It should be a team of equals
• It should have organization wide representation
• It should have decision making and enforcing authority and not just be a recommending
committee
• It should be involved in periodic reviews to ensure that the operations are in line with the
strategy.
The two types of Organizational Structures for distributing testing teams across multiple locations
are:
 Round the clock development / testing model
 Testing competency center model – 2 variants
Challenges in global teams:
• Cultural challenges
• Work allocation challenges
• Parity across teams
• Ability to work effectively
• Dependence on communication infrastructure
• Time difference
Challenges and Issues in Testing Services Organization:
• The outsider effect and estimation of resources
• Domain expertise
• Privacy and customer isolation issues
• Apportioning hardware and software resources and costs
• Maintaining a bench
Success Factors for Testing Organizations:
• Communication and teamwork
• Bringing in customer perspective
• Providing appropriate tools and environment
• Providing periodic skills upgrades

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.

7
IT6004 SOFTWARE TESTING

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
1. Overall test objectives.
2. What to test (scope of the tests)?
3. Who will test?
4. How to test?
5. When to test?
6. When to stop testing?

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.

Test Plan Components

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.

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

8
IT6004 SOFTWARE TESTING

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.
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.
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 behaviours are described such as requirements and design documents, and
the user manual should be included in this component of the test plan.
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.
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
Item 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
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

9
IT6004 SOFTWARE TESTING

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.
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.
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.
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.
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.
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.

10
IT6004 SOFTWARE TESTING

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
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.
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 analysing 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

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.

11
IT6004 SOFTWARE TESTING

Test Plan Attachments

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
 Intercase 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

12
IT6004 SOFTWARE TESTING

(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.

Locating Test Items: Test Item Transmittal Report

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.

Test Management
Test management, process of managing the tests. A test management is also performed
using tools to manage both types of tests, automated and manual, that have been previously
specified by a test procedure.
Test management tools allow automatic generation of the requirement test matrix (RTM),
which is an indication of functional coverage of the application under test (SUT).
Test Management tool often has multifunctional capabilities such as test ware management, test
scheduling, the logging of results, test tracking, incident management and test reporting.

13
IT6004 SOFTWARE TESTING

Test management Structure

Test Management Responsibilities:
 Test Management has a clear set of roles and responsibilities for improving the quality of
the product.
 Test management helps the development and maintenance of product metrics during the
course of project.
 Test management enables developers to make sure that there are fewer design or coding
faults.

Testing process
The general testing process is the creation of a test strategy (which sometimes includes
the creation of test cases), creation of a test plan/design (which usually includes test cases and
test procedures) and the execution of tests. Test data are inputs that have been devised to test the
system Test Cases are inputs and outputs specification plus a statement of the function under the
test.
The stages in the testing process are as follows:
1. Unit testing: (Code Oriented)
2. Module testing
3. Sub-system testing: (Integration Testing) (Design Oriented)
4. System testing
5. Acceptance testing

14
IT6004 SOFTWARE TESTING

Stages of testing phase

Reporting Test Results

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
 Test Log
 Test Incident Report
 Test Summary Report
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 behaviour, 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

15
IT6004 SOFTWARE TESTING

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
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
1. Test Summary Report identifier
2. Variances
3. Comprehensiveness assessment
4. Summary of results
5. Evaluation
6. Summary of activities
7. Approvals

Relationships between all the test-related documents

16
IT6004 SOFTWARE TESTING

The role of three groups in Test Planning and Policy Development

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.
Reaching TMM level 2: summary of critical group roles

Summary of critical group roles

For the TMM maturity goal, “Develop Testing and Debugging Goals,” the TMM recommends
that Project and Upper Management:
• Provide access to existing organizational goal/policy statements and sample testing policies
• Provide adequate resources and funding to form the committees (team or task force) on
testing and debugging
• Support the recommendations and policies of the committee by:
 distributing testing/debugging goal/policy documents to project managers,
developers, and other interested staff,
 appointing a permanent team to oversee compliance and policy change making.

17
IT6004 SOFTWARE TESTING

• Ensure that the necessary training, education, and tools to carry out defined
testing/debugging goals is made available
• Assign responsibilities for testing and debugging.
Developers:
Developers have an important role in the development of testing goals and policies. They serve
as members of the goal/policy development teams. As representatives of the technical staff they
must ensure that the policies reflect best testing practices, are implementable, receive
management support, and support among technical personnel.
The activities, tasks, and responsibilities for the developers/testers include
• Working with management to develop testing and debugging policies and goals.
• Participating in the teams that oversee policy compliance and change management.
• Familiarizing themselves with the approved set of testing/debugging goals and policies,
keeping up-to-date with revisions, and making suggestions for changes when appropriate.
• When developing test plans, setting testing goals for each project at each level of test
that reflect organizational testing goals and policies.
• Carrying out testing activities that are in compliance with organizational policies.
Users and Clients:
Users and clients play an indirect role in the formation of an organization’s testing goals
and polices since these goals and policies reflect the organizations efforts to ensure
customer/client/user satisfaction. Feedback from these groups and from the marketplace in
general has an influence on the nature of organizational testing goals and policies. Successful
organizations are sensitive to customer/client/user needs.
For the the second management-oriented maturity goal at TMM level 2 “Initiate a Test
Planning Process,” input from the three critical Groups are required
Upper management supports this goal by:
• Establishing an organization wide test planning committee with funding.
• Ensuring that the testing policy statement and quality standards support test planning with
commitment of resources, tools, templates, and training.
• Ensuring that the testing policy statement contains a formal mechanism for user input to
the test planning process, especially for acceptance and usability testing.
• Ensuring that all projects are in compliance with the test planning policy.
• Ensuring that all developers/testers complete all the necessary post-test documents such as
test logs and test incident reports.
Project managers support the test planning maturity goal by preparing the test plans for each
project with inputs and support from developers.
Developers:
Developers who are experienced in testing support this maturity goal by participating in
test planning. They assist the project manager in determining test goals, selecting test methods,
procedures and tools, and developing the test case specifications, test procedure specifications,
and other test-related documents Developers are also responsible for ensuring that testability
issues are addressed during the requirements and design phases of development to support test
planning and test design.

User/Client:

18
IT6004 SOFTWARE TESTING

From the user/client point of view support for test planning is in the form of articulating
their requirements clearly, and supplying input to the acceptance test plan. The required
functional and performance-related attributes that are expected by the client/users must be
specified. Users/clients may also participate in the development of an operational profile which
may be used to guide system and acceptance tests. They can also participate in usability test
planning
Introducing the Test Specialist
The maturity goals at TMM level 3 calls for the “Establishment of a test organization.”
This is an important step for a software organization. It implies a commitment to better testing
and higher-quality software. This commitment requires that testing specialists be hired, space be
given to house the testing group, resources be allocated to the group, and career paths for testers
be established.
It also implies that the functional and managerial hierarchy of the organization be
redesigned, changes in the reporting structure be made, as well as changes be made to the
organizational Culture. By supporting a test group an organization acquires leadership in areas
that relate to testing and quality issues.
Responsibilities of Test Specialist / Test Engineers
• maintenance and application of test policies
• development and application of test-related standards
• participating in requirements, design, and code reviews
• test planning
• test design
• test execution
• test measurement
• test monitoring (tasks, schedules, and costs)
• defect tracking, and maintaining the defect repository
• acquisition of test tools and equipment
• identifying and applying new testing techniques, tools, and methodologies
• mentoring and training of new test personnel
• test reporting

Skills needed by a Test Specialist

Personal and Managerial level
• organizational, and planning skills
• the ability to keep track of, and pay attention to, details
• the determination to discover and solve problems
• the ability to work with others and be able to resolve conflicts
• the ability to mentor and train others
• the ability to work with users and clients
• strong written and oral communication skills
• the ability to work in a variety of environments
• the ability to think creatively

Skills needed by a Test Specialist:

19
IT6004 SOFTWARE TESTING

Technical level
• an education that includes an understanding of general software engineering principles,
practices, and methodologies;
• strong coding skills and an understanding of code structure and behaviour;
• a good understanding of testing principles and practices;
• a good understanding of basic testing strategies, methods, and techniques;
• the ability and experience to plan, design, and execute test cases and test procedures on
multiple levels
• a knowledge of process issues;
• knowledge of how networks, databases, and operating systems are organized and how they
work;
• a knowledge of configuration management;
• a knowledge of test-related documents and the role each documents plays in the testing
process;
• the ability to define, collect, and analyse test-related measurements;
• the ability, training, and motivation to work with testing tools and equipment;
• a knowledge of quality issues.

Building a Testing Group

Major activities required to manage the testing process are
• organizing,
• staffing, and
• Directing
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
Staffing:
Staffing activities include filling positions, assimilating new personnel, education and
training, and staff evaluation
Directing:
Directing includes providing leadership, building teams, facilitating communication,
motivating personnel, resolving conflicts, and delegating authority.
Steps in forming a test group

20
IT6004 SOFTWARE TESTING

Step 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.
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
21
IT6004 SOFTWARE TESTING

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.
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.
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.
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.

22