Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.


this slide is useful for basic testing learners.

  • Login to see the comments


  1. 1. Presenter Name: Mahendra Siingh Role of Testing in SDLC December 7, 2007
  2. 2. Role of Testing in SDLC " Quality is free… but only to those who are willing to pay heavily for it." (Lister, DeMarco: "Peopleware") Rahul Agrawal Radhu Gupta
  3. 3. Agenda <ul><li>SDLC </li></ul><ul><li>Software Process Models </li></ul><ul><li>Software Test Life Cycle </li></ul><ul><li>Test Plan </li></ul><ul><li>Use Case </li></ul><ul><li>Scenarios </li></ul><ul><li>Test Cases </li></ul><ul><li>Bug Life Cycle </li></ul>
  4. 4. SDLC (Software Development Life Cycle) <ul><li>Software Process Models. </li></ul><ul><ul><li>Waterfall Model </li></ul></ul><ul><ul><li>V-Model </li></ul></ul>SDLC is the process of developing information systems through investigation, analysis, design, implementation and maintenance.
  5. 5. Waterfall Model <ul><li>Limitation of Waterfall Model. </li></ul><ul><li>Implies that given stage is to be completed before moving to next stage. </li></ul><ul><li>The model makes no allowance for prototyping. </li></ul><ul><li>The model implies that once the product is finished, everything else is in maintenance. </li></ul>Design Feasibility Study Requirement Analysis Implementation Testing Coding Maintenance Waterfall Model <ul><li>Software Metrics </li></ul><ul><li>SRS Format </li></ul>
  6. 6. V-MODEL
  7. 7. V-MODEL: Detailed View
  8. 8. Integrated Testing The V Model .Verification guidelines .Verification Procedures .Validation g u i d e l in e s .Validation Procedure Verification Validation Project Initiation Finalization of Specs. Finalization of Design Coding Build Software Build System Release for Use Development Activity Contract Code Review Design Review Revised Test Plan Specs Review Test Plan Product Quality Info. Functional Testing Integration Testing V & V Activities
  9. 9. Software Testing Life Cycle
  10. 10. Test Plan <ul><li>Purpose </li></ul><ul><li>Scope </li></ul><ul><li>Test Strategy (Approach, Test Deliverables, etc.) </li></ul><ul><li>Project Management </li></ul><ul><li>Schedule </li></ul><ul><li>Risk and Contingencies </li></ul><ul><li>Test Plan Template of RSI </li></ul>A document that defines the overall testing approach is called Test Plan .
  11. 11. Test Strategy – Types of Testing 1. Unit Testing It is a procedure used to validate that a particular module of source code is working properly. 2. Integration Testing Testing two or more modules or functions together with the intent of finding interface defects between the modules or functions. 3. Functional Testing Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions . 4. System Testing Testing that attempts to discover defects that are properties of the entire system rather than of its individual components.
  12. 12. Types of Testing – System <ul><li>Usability Testing </li></ul><ul><li>Performance Testing (Load, Stress and Volume) </li></ul><ul><li>Smoke and Sanity Testing </li></ul><ul><li>Monkey and Gorilla testing </li></ul><ul><li>Ad-hoc Testing </li></ul><ul><li>Exploratory Testing </li></ul><ul><li>Regression Testing </li></ul><ul><li>Installation Testing </li></ul>9. Globalization Testing 10. Localization Testing 11. Security Testing 12. Compatibility Testing 13. Configuration Testing 14. Reliability testing 15. Acceptance Testing (Alpha, Beta..)
  13. 13. Use Case <ul><li>Use Case: is a technique for capturing </li></ul><ul><li>functional requirement of systems and system </li></ul><ul><li>of-systems </li></ul><ul><li>Benefits of Use Case: </li></ul><ul><li>HLD Review </li></ul><ul><li>LLD Review </li></ul><ul><li>Use cases have proved to be easily understandable by business users, and so have proven an excellent bridge between software developers and end users. </li></ul><ul><li>Test Cases(System, User Acceptance and Functional)can be directly derived from the use cases </li></ul>
  14. 14. Template of Use Case
  15. 15. Test Deliverables - Scenarios A scenario is an instance of a use case, and represents a single path through the use case. <ul><li>One may construct a scenario for the main flow through the use case </li></ul><ul><li>Scenarios for each possible variation of flow through the use case (e.g., </li></ul><ul><li>triggered by options, error conditions, security breaches, etc.). </li></ul><ul><li>Scenarios may be depicted using sequence diagrams. </li></ul>
  16. 16. Extracting Scenarios from Use Cases Valid Valid Pass Valid Invalid Fail Valid Blank Fail Invalid Invalid Fail Invalid Blank Fail Invalid Valid Fail Blank Valid Fail Blank Invalid Fail Blank Blank Fail User Id Password Status
  17. 17. Test Cases <ul><ul><li>Preparation of Test Case and RTM </li></ul></ul><ul><ul><li>Review of Test Cases </li></ul></ul><ul><ul><li>Execution of Test Case </li></ul></ul><ul><li>Test Case Review Check List </li></ul>Set of procedures in order to find out the defects according to Client’s Requirements.
  18. 18. Test Cases – Testing Techniques <ul><ul><li>Equivalence Partitioning </li></ul></ul><ul><ul><li>Boundary Value Analysis </li></ul></ul><ul><ul><li>Error Guessing </li></ul></ul>
  19. 19. Equivalence Partitioning A subset of data that is representative of a larger class <ul><li>For example, a program which edits credit limits within a given range ($10,000 - $15,000) would have 3 equivalence classes: </li></ul><ul><ul><li>Less than $10,000 (invalid) </li></ul></ul><ul><ul><li>Between $10,000 and $15,000 (valid) </li></ul></ul><ul><ul><li>Greater than $15,000 (invalid) </li></ul></ul>
  20. 20. Boundary Analysis A technique that consists of developing test cases and data that focus on the input and output boundaries of a given function <ul><li>In the same credit limit example, boundary analysis would test: </li></ul><ul><ul><li>Low boundary plus or minus one ($9,999 and $10,001) </li></ul></ul><ul><ul><li>On the boundary ($10,000 and $15,000) </li></ul></ul><ul><ul><li>Upper boundary plus or minus one ($14,999 and $15,001) </li></ul></ul>
  21. 21. Error Guessing For example, in an example where one of the inputs is the date, a test engineer might try February 29,2000 or 9/9/99 Based on the theory that test cases can be developed based on experience of the Test Engineer
  22. 22. BUG Life Cycle
  23. 23. Thanks!!!! <ul><ul><li>Looking for the feedback at: </li></ul></ul><ul><ul><li>[email_address] </li></ul></ul><ul><ul><li>Radhu.gupta </li></ul></ul>