Building a software testing environment


Published on

Building a software testing environment

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Building a software testing environment

  1. 1. Building a Software Testing Environment Dr. Himanshu Hora SRMS College of Engineering & Technology Bareilly (INDIA)
  2. 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. 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. 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. 5. Closing the customer dissatisfaction gap
  6. 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. 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. 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. 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. 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. 11. Testing policy
  12. 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. 13. Economics of Testing
  14. 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. 15. Life Cycle Verification Activities
  16. 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. 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. 18. Test factor/test phase matrix.
  19. 19. Thank You Dr. Himanshu Hora SRMS College of Engineering & Technology Bareilly (INDIA)