Software Development Life Cycle Testingtypes


Published on

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

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

No notes for slide

Software Development Life Cycle Testingtypes

  1. 1. Software Life Cycle The life cycle of the application begins when an application is first conceived and ends when it is no longer in use. It includes the following aspects: initial concept; requirements analysis; functional design; internal design; documentation planning; test planning; coding; document preparation; integration; testing; maintenance; updates; retesting; technical support etc.
  2. 2. Software Development Life Cycle The period of time that begins with the decision to develop a software product and ends when the software is delivered. This cycle typically includes a requirements phase, design phase, implementation phase, test phase, and sometimes, installation and checkout phase. Source: IEEE Std 610.12-1990.
  3. 3. SDLC stages 1. Requirements Analysis : - determine real problem. - decide what is needed to solve it 2. Specification: - define WHAT system will do (the specification) - define acceptance tests 3. Design : - plan HOW to meet specification - Design the program structure (break the program into components (modules) ) - Design the details - Write the design description & module specs 4. Implementation: - code program modules - integrate system - write detailed documentation 5. System Testing and Debugging: - Check the operation - try to FIND and FIX errors 6. Installation: - Train users - Switch from previous system 7. Operation and Maintenance: - Use - Fix problems - Enhance program
  4. 4. SDLC Models Waterfall Model V Model --------------------------- Iterative models: Incremental Delivery Incremental Development Evolutionary Development Spiral Development --------------------------- Prototyping
  5. 5. SDLC: Waterfall Model structure Problem statement Requirements Architecture & Design Implementation System Testing Installation Operation & Maintenance
  6. 6. SDLC: Waterfall Model definitions The waterfall model is a systematic sequential approach to software development modeled after a conventional engineering cycle. One phase is completed before the next is entered **************************************************** A model of the software development process in which the constituent activities, typically a concept phase, requirements phase, design phase, implementation phase, test phase, and installation and checkout phase, are performed in that order, possibly with overlap but with little or no iteration. Source: IEEE Std 610.12-1990.
  7. 7. Problems in Waterfall Model <ul><li>Problems for the Developer </li></ul><ul><li>Client does not know what is needed </li></ul><ul><li>Payment delays (until product is ready) </li></ul><ul><li>Lack of user commitment and input </li></ul><ul><li>Changes in requirements cause a problem </li></ul><ul><li>Problems for the Client </li></ul><ul><li>Developer doesn't understand our problems </li></ul><ul><li>Lack of visible progress </li></ul><ul><li>Cannot change requirements </li></ul><ul><li>Don't know what is possible </li></ul><ul><li>Training problems (late start) </li></ul>
  8. 8. Testing types (a) White-box testing – involves knowledge of code analysis. Analyzes program structure and functionality of particular units and components at code level. Black-Box testing – testing of program without knowing internal code structure, using only external level (GUI, commands).
  9. 9. Testing Types (b) Sequence of testing types in SDLC Unit Testing (white-box testing) Component Testing (white-box testing) ------------------------ Integration Testing System Testing Acceptance Testing ------------------------- B-version testing ------------------------- User Acceptance Testing T i m e
  10. 10. Unit Testing Unit testing is a white-box testing and is dealing with code analysis. *************************************************** Testing a program unit, typically developed by a single individual, to determine that is free of data, logic, or standards errors. Involves code analysis. Requires knowledge of dynamic analysis (equivalent partitioning, boundary value analysis, cause-effect graphing, logic-based testing, random testing, and syntax testing) and static analysis (complete path testing, decision testing, condition testing, and data-flow testing). Source: SWE-BOK CMU/SEI-99-TR-004.
  11. 11. Component Testing Component Testing is usually white-box testing and is dealing with code analysis of program components ********************************************* Testing of individual hardware or software components or groups of related components. Source: IEEE Std 610.12-1990.
  12. 12. Integration Testing Testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them. Source: IEEE Std 610.12-1990.
  13. 13. System Testing Testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. Source: IEEE Std 610.12-1990.
  14. 14. Acceptance Testing Formal testing to determine if a system satisfies its acceptance criteria and to enable the customer to determine whether to accept the system. Source: SEI-93-TR-25 .
  15. 15. Testing Types (b) Functional Testing GUI testing ----------------------- Load Testing Stress Testing Performance Testing --------------------- Testing Documentation --------------------- Specific testing Types
  16. 16. Verification and Validation The process of determining whether the requirements for a system or component are complete and correct, the products of each development phase fulfill the requirements or conditions imposed by the previous phase, and the final system or component complies with specified requirements. Source: IEEE Std 610.12-1990.
  17. 17. Verification Testing <ul><li>Intermediate, structural testing </li></ul><ul><li>The process of evaluating a system or component to determine whether or not the products of a given development phase satisfy the condition imposed at the start of that phase. </li></ul><ul><li>Source: ESI. </li></ul><ul><li>Examples: </li></ul><ul><li>Did the builder put the beams in the right place? </li></ul><ul><li>Is the wiring of the house up to legal code? </li></ul>
  18. 18. Validation testing <ul><li>Final, functional testing </li></ul><ul><li>The process of evaluating a system or component at the end of the development process to determine whether or not it satisfies specified requirements. </li></ul><ul><li>Source: ESI. </li></ul><ul><li>Examples: </li></ul><ul><li>- Does the house have the right number of closets? </li></ul><ul><li>Is the kitchen designed the way the homeowner wants it? </li></ul><ul><li>Did we met the user requirements? </li></ul>
  19. 19. Scalability It is the ability of a computer application or product (hardware or software) to continue to function well as it (or its context) is changed in size or volume in order to meet a user need. Typically, the rescaling is to a larger size or volume. The rescaling can be of the product itself (for example, a line of computer systems of different sizes in terms of storage, RAM, and so forth) or in the scalable object's movement to a new context (for example, a new operating system) Source:,,sid10_gci212940,00.html
  20. 20. Traveling of Bug Report Team Leader – bug review This is not a bug This is known problem This is planned to do in the future This is a bug Information in bug report is insufficient Bug Status rejected Bug Status duplicate Bug Status deferred Bug Status assigned Bug Status: in-review Bug Status fixed Developer – fixing the bug Tester – verifying bug fix Bug is fixed Bug is not fixed Bug Status assigned Bug Status closed Tester – submitting new bug report Bug Status submitted