Building a software testing environment

1. Building a Software Testing Environment
Dr. Himanshu Hora
SRMS College of Engineering & Technology
Bareilly (INDIA)

2. Creating an Environment Supportive of Software Testing
• Senior IT management is responsible for creating an environment in
which software testing is effective and efficient.
• Only management can create that type of environment.
•
If such an environment does not exist, the probability of
dissatisfying project personnel and software users is high.
• The primary objective of software testing is to minimize operational
risk by identifying defects prior to the software being placed into
operation.

3. Management’s role in creating an environment conducive to
software testing by addressing the following topics:
1) Management’s risk appetite for ineffective software
2) The role management assigns to testing
3) The policy for testing
4) The type of support management provides for software
testing
5) The resources allocated for testing
6) The processes and tools that will be used for testing

4. Risk Appetite for Software Quality
• A risk appetite is the amount of risk that management is willing to take so
that the soft-ware placed into operations will be risk-free.
• There are two gaps:– A specifications gap- The IT project group defines the specifications for building
software. The project objective is to implement the specifications as documented by
the IT project group and agreed to by the customer/user. If they fail to deliver the
specifications, or deliver them in an incomplete and inaccurate manner
– A needs gap- This is the gap between what the customer of the software needs and
what was delivered. If the customer needs and the software specifications were the
same, there would be only one gap. However, because the process to gather the
software requirements is often defective, there are, in fact, two gaps.

5. Closing the customer dissatisfaction gap

6. Risks Associated with Implementing Specifications
Risk factors
that can
cause
specifications
not to be
implemented
as specified
include:-
• Inadequate schedule and budget
• Inadequate test processes
• Inadequate competency
• Faulty Software Design
• Designing software with incomplete or erroneous decisionmaking criteria
• Failing to program the software as intended by the customer
(user) or designer
• Omitting needed edit checks for determining completeness of
output data
• Data Problems
• Incomplete data
• Incorrect data
• Obsolete data

7. Risks
Associated
with Not
Meeting
Customer
Needs
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Correctness
File integrity
Authorization
Audit trail
Continuity of processing
Service levels
Access control
Compliance
Reliability
Ease of use
Maintainability
Portability
Coupling
Performance
Ease of operation

8. Developing a Role for Software Testers
• Management needs to evaluate these risks and determine their level of risk
appetite
• The role of all software testing groups is to validate whether the
documented specifications have been implemented as specified
• Additional roles that might be assigned to software testers include the
following:
a. Testing for all or part of the test factors
b. Ensuring that the documented specifications meet the true needs of the
customer
c. Improving the software testing process
d. Improving the developmental test process
e. Participating in acceptance testing
f. Recommending changes to the software system
g. Evaluating the adequacy of the system of controls within the software system

9. Writing a Policy for Software Testing
A
software
testing
policy
serves
two
purposes
• First, it is the basis for defining what
software testers will include in the test
processes
• Second, it explains to outside parties such as
organizational management, IT customers
and users, as well as project personnel, the
role and responsibilities of software testing.

10. Criteria for a Testing Policy
•
•
•
•
Definition of testing
Testing system.
Evaluation
Standards
“Good testing does not just happen, it must be planned; and a testing policy
should be the cornerstone of that plan.”

11. Testing policy

12. Methods for Establishing a Testing Policy
Methods for Establishing a Testing Policy are• Information services consensus policy
• Management directive
• Users’ meeting
Testing is an organizational responsibility. It is the recommendation of the
author that a user committee be convened to develop a testing policy. This
meeting serves the following purposes:
• It permits all involved parties to participate in the development of a
testing policy.
• It is an educational process where users understand the options and costs
associated with testing.
• It clearly establishes for all involved departments that testing is an
organizational responsibility and not just an IT responsibility.

13. Economics of Testing

14. Building a Structured Approach to Software Testing
• The following activities should be performed at each phase:
– Analyze the software documentation for internal testability and adequacy.
– Generate test sets based on the software documentation at this phase.
– Determine that the software documentation is consistent with the software
documentation produced during previous phases.
– Refine or redefine test sets generated earlier.

15. Life Cycle Verification Activities

16. Developing a Test Strategy
• Strategy explains “what to do.”
• Testing tactics explain “how to” implement the strategy
The objective of testing is to reduce the risks inherent in computer systems.
The strategy must address the risks and present a process that can reduce
those risks. The system concerns or risks then establish the objectives for
the test process.
The two components of the testing strategy are the test factors and the test
phase, defined as follows:
Test factor:-The risk or issue that needs to be addressed as part of the test
strategy. The strategy will select those factors that need to be addressed in
the testing of a specific application system.
Test phase:- The phase of the SDLC in which testing will occur.

17. Four steps to develop a customized test strategy
• The test strategy can be represented as the test factor/test phase matrix
– Select and rank test factors
– Identify the system development phases
– Identify the business risks associated with the system under
development.
– Place risks in the matrix

18. Test factor/test phase matrix.

19. Thank You
Dr. Himanshu Hora
SRMS College of Engineering & Technology
Bareilly (INDIA)