16103271 software-testing-ppt


Published on


Published in: 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 testing – 2
  • Qp-2
  • 16103271 software-testing-ppt

    2. 2. <ul><li>Software Testing – Introduction </li></ul><ul><li>Quality Principles </li></ul><ul><li>Software Process </li></ul><ul><li>SDLC </li></ul><ul><li>(Software Development Life Cycle) </li></ul><ul><li>Project Management </li></ul>Contents
    3. 3. <ul><li>Requirement Management </li></ul><ul><li>Configuration Management </li></ul><ul><li>Software Testing Fundamentals </li></ul><ul><li>Testing Policy Vs Quality Policy </li></ul><ul><li>Testing Economics and Testing Cost </li></ul><ul><li>Testing Levels </li></ul><ul><li>Testing Techniques </li></ul>Contents
    4. 4. <ul><li>Test Maturity Criteria </li></ul><ul><li>Verification Process </li></ul><ul><li>Test Level Model </li></ul><ul><li>Special Test Types </li></ul><ul><li>Test Standards </li></ul><ul><li>Testing Process </li></ul>Contents
    5. 5. <ul><ul><ul><ul><ul><li>Software Testing </li></ul></ul></ul></ul></ul>STATIC DYNAMIC Structural Testing (White Box testing) Functional Testing (Black Box testing) Logical Errors Nothing else but functioning
    6. 6. <ul><li>Testing </li></ul><ul><li>A Process of evaluating a particular product to determine whether the product contain any defects </li></ul><ul><li>Software Testing </li></ul><ul><ul><li>Software Testing is a process of evaluating a system by manual or automatic means and verify that it satisfies specified requirements or identify differences between expected and actual results. </li></ul></ul>
    7. 7. <ul><li>Why Software Testing ? </li></ul><ul><li>Error Free </li></ul><ul><li>Efficient </li></ul><ul><li>Secured </li></ul><ul><li>Flexible </li></ul><ul><li>Software Testing is important as it may cause mission failure, impact on operational performance and reliable if not done properly. </li></ul>
    8. 8. QUALITY PRINCIPLES <ul><ul><li>Quality is defined as meeting the Customer’s requirements in the First time and Every time. </li></ul></ul><ul><ul><li>Quality is much more than the absence of defects, which allows us to meet customer’s expectations. </li></ul></ul><ul><ul><li>There are five perspective of quality- they are… </li></ul></ul>
    9. 9. Software Quality <ul><li>Critical Quality Attributes </li></ul><ul><ul><li>Maintainability </li></ul></ul><ul><ul><li>Dependability </li></ul></ul><ul><ul><li>Efficiency </li></ul></ul><ul><ul><li>Usability </li></ul></ul><ul><li>Other Attributes </li></ul><ul><ul><li>Completeness </li></ul></ul><ul><ul><li>Compatibility </li></ul></ul><ul><ul><li>Portability </li></ul></ul><ul><ul><li>Internationalization </li></ul></ul><ul><ul><li>Understandability </li></ul></ul><ul><ul><li>Scalability </li></ul></ul><ul><ul><li>Robustness </li></ul></ul><ul><ul><li>Testability </li></ul></ul><ul><ul><li>Reusability </li></ul></ul><ul><ul><li>Customizability </li></ul></ul>
    10. 10. Five perspective of quality <ul><li>1. Transcendent-I know when I see it. </li></ul><ul><li>2. Product based- possesses desired features </li></ul><ul><li>3. User based – Fitness for use. </li></ul><ul><li>4. Development and manufacturing based – Confirms to requirements. </li></ul><ul><li>5. Value based – At an acceptable cost. </li></ul>
    11. 11. Why Quality? <ul><ul><li>Quality is the most important factor affecting an organization's long-term performance. Quality is the way to achieve improved productivity and competitiveness in any organization. </li></ul></ul>
    12. 12. Cost of Quality <ul><li>The three categories of costs associated with producing quality products are </li></ul><ul><li>Prevention cost : Money required to prevent errors and to do the job right the first time. </li></ul><ul><li>Appraisal costs : Money Spent to review completed product against requirement. </li></ul><ul><li>Failure costs : This cost associated with defective products that have been delivered to the user or moved into production. </li></ul>
    13. 13. Quality Assurance Vs Quality Control <ul><li>Quality Assurance </li></ul><ul><li>- process oriented (Software development) </li></ul><ul><li>- Defect prevention </li></ul><ul><li> (Identify & Rectify) </li></ul><ul><li>Quality Control </li></ul><ul><ul><ul><ul><ul><li>Product Oriented (quality of the entire product is checked or tested) </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Defect detection </li></ul></ul></ul></ul></ul>
    14. 14. Software Process <ul><ul><ul><li>A particular method of doing some thing, generally involving a number of steps or operations is a process. </li></ul></ul></ul><ul><ul><ul><li>The process that deals with the technical and management issues of software development is called Software Process. </li></ul></ul></ul>
    15. 15. Software Process <ul><li>Process – Projects – Products </li></ul><ul><li>A software process specifies a method of developing software. </li></ul><ul><li>A software project, on the other hand, is a development project in which a software process is used. </li></ul><ul><li>A Software product is the outcome of a software project. </li></ul>
    16. 16. ACT DO CHECK PLAN Planning & Designing Coding & Production Testing & Evaluating Necessary Actions
    17. 17. <ul><li>Plan : Device a plan. Define your objective and determine and strategy and supporting methods required to achieve that objective. </li></ul><ul><li>Do : executive the plan. Create the conditions and perform the necessary training to execute the plan. </li></ul><ul><li>Check : Check the results. Check to determine whether work is progressing according to the plan and whether the results are obtained. </li></ul>
    18. 18. SDLC (SOFTWARE DEVELOPMENT LIFE CYCLE) <ul><li>Overview of Software Development Activities </li></ul><ul><li>Introduction to Various Lifecycles </li></ul>
    19. 19. Agenda <ul><li>Team Organization Deliverable Turn-in </li></ul><ul><ul><li>Project Assignments to be posted on the web-site </li></ul></ul><ul><li>Introduction to Software Development Activities </li></ul><ul><li>Survey of Lifecycle Models </li></ul>
    20. 20. Software Engineering <ul><li>Layered Technology </li></ul><ul><ul><li>Key Process Areas </li></ul></ul>Tools Methods Process Quality
    21. 21. Capability Maturity Model <ul><li>Developed by SEI(Software Engineering Integration) </li></ul><ul><li>Five Process Maturity Levels </li></ul><ul><ul><li>Level 0: Chaos </li></ul></ul><ul><ul><li>Level 1: Initial </li></ul></ul><ul><ul><li>Level 2: Repeatable </li></ul></ul><ul><ul><li>Level 3: Defined </li></ul></ul><ul><ul><li>Level 4: Managed </li></ul></ul><ul><ul><li>Level 5: Optimizing </li></ul></ul>
    22. 22. Process Principles <ul><li>Prescribes all major activities </li></ul><ul><li>Uses resources, within a set of constraints, to produce intermediate and final products </li></ul><ul><li>May be composed of sub-processes </li></ul><ul><li>Each activity has entry and exit criteria </li></ul><ul><li>Activities are organized in a sequence </li></ul><ul><li>Has a set of guiding principles to explain goals </li></ul><ul><li>Constraints may apply to activity, resource or product </li></ul>
    23. 23. <ul><li>The six Stages of SDLC process are </li></ul><ul><ul><ul><ul><li>Requirement Analysis </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Design </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Development </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Testing </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Implementation </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Maintenance </li></ul></ul></ul></ul>
    24. 24. Requirement Analysis <ul><li>Study done by organization against customer’s requirement is documented as SRAS( software requirement analysis specification) </li></ul><ul><li>The main objective of the requirements analysis is to produce a document that properly specifies all requirements of the customer. </li></ul><ul><li>SRS(Software Requirement Specification) is the primary output of this phase. </li></ul>
    25. 25. Design Process <ul><li>Decompose entire project into units / modules and prepare dataflow diagram and communication. </li></ul><ul><li>CDD(Comprehensive Design Document) </li></ul><ul><ul><ul><ul><ul><li>= HCL + LLD </li></ul></ul></ul></ul></ul>Design Process HCD LLD High Level Design Low Level Design
    26. 26. HLD <ul><li>High-Level Design (system Design) </li></ul><ul><ul><li>High-level design is the phase of the life cycle when a logical view of the computer implementation of the solution to the customer requirements is developed. </li></ul></ul>
    27. 27. LLD <ul><li>Low Level Design (Detailed Design) </li></ul><ul><ul><li>During the detailed design phase, the view of the application developed during the high level design is broken down into modules and programs. Logic design is done for every program. </li></ul></ul>
    28. 28. Coding and unit testing <ul><li>During the build phase, the detailed design is used to produce the required programs in a programming language. </li></ul><ul><li>This stage produces the source code, executable, and databases applicable. </li></ul>
    29. 29. Testing <ul><li>Unit testing </li></ul><ul><li>Integration testing </li></ul><ul><li>System testing </li></ul><ul><li>STATIC(Reviewing) </li></ul><ul><li>DYNAMIC (Execution) </li></ul>
    30. 30. Integration testing <ul><li>Integration is a systematic approach to building the complete software structure specified in the design from unit-tested modules. </li></ul><ul><li>Integration plan must specify the order in which the modules are integrated. </li></ul>
    31. 31. System Testing <ul><li>System testing is an activity to validate the software product against the requirement specification. </li></ul><ul><li>This stage is intended to find defects that can be exposed only by testing the entire system. </li></ul>
    32. 32. Acceptance and Installation <ul><li>Acceptance and installation is the phase in the software life cycle during which a software product is integrated into its operational environment and tested in this environment to ensure that it performs as required. </li></ul><ul><li>The two basic tasks- getting the software accepted and installing the software at the customer site. </li></ul>
    33. 33. Project Management <ul><li>Project Management is nothing but organising, Planning,ans scheduling software projects. </li></ul><ul><ul><li>Project staffing </li></ul></ul><ul><ul><li>Project planning </li></ul></ul><ul><ul><li>Project scheduling </li></ul></ul><ul><ul><li>Project monitoring </li></ul></ul>
    34. 34. Risk Management <ul><li>Software Risks </li></ul><ul><li>1. Risk identification : Identify project, product and business risks. </li></ul><ul><li>2. Risk analysis : Assess the likelihood and consequences of these risks. </li></ul><ul><li>3. Risk planning : Draw up plans to avoid or minimize the effects of the risk. </li></ul><ul><li>4. Risk monitoring : Monitor the risks throughout the project </li></ul>
    35. 35. Requirements Management <ul><li>Requirements management is managing changes in the evolving software in a cost effective manner. Changes may come externally or internally. </li></ul><ul><li>External changes may be due to problem,customer, environment. </li></ul><ul><li>Internal changes may be due to requirements, design, implementation, testing, maintenance </li></ul>
    36. 36. Configuration Management <ul><li>Standards and procedures for managing changes in an evolving software product is configuration management. </li></ul><ul><li>New versions of software systems are created as they change for different machines/OS, offering different functionality. </li></ul><ul><li>Software systems are sometimes called baselines as they are a starting point for further development. </li></ul>
    37. 37. Verification and release management <ul><li>Invent identification scheme for system versions plan when new system version is to be produced. Ensure that version management procedures and tools and properly applied. Plan and distribute new system releases. </li></ul>
    38. 38. version/variants/releases <ul><li>Version : An instance of a system, which is functionally distinct in some way from other system instances. </li></ul><ul><li>Variant: An instance of a system, which is functionally identical but non-functionally distinct from other instances of a system. </li></ul><ul><li>Release : An instance of a system, which is distributed to users outside of the development team. </li></ul>
    39. 39. Version derivation structure V 1.1 V 1.2 V 1.1a V 1.1b V 1.1.1 V 2.0 V 1.0 V 2.1 V 2.2
    40. 40. Software Testing Fundamentals <ul><li>Primary role of software testing? </li></ul><ul><ul><li>determine whether the system meets specification (producer view) </li></ul></ul><ul><ul><li>determine whether the system meets business and user needs (customer view). </li></ul></ul>
    41. 41. STF <ul><li>What is Defects ? </li></ul><ul><ul><li>The purpose of testing is to find defects. A defect is a variance from a desired product attribute. Two categories of defects are </li></ul></ul><ul><ul><li>Variance from product specifications. </li></ul></ul><ul><ul><li>Variance from customer/user expectation. </li></ul></ul>
    42. 42. Defects <ul><li>1. Wrong : The specifications have been implemented incorrectly. This defect is a variance from customer / user specification. (correctly mentioned in specification but wrongly implemented) </li></ul><ul><li>2. Missing : A specified or wanted requirement is not in the built product. This can be a variance from specification, an indication that the specification was not implemented. ( given in specification but missed out in application) </li></ul><ul><li>3. Extra : A requirement incorporated into the product that was not specified. This is always a variance from specifications, but may the user of the product desire an attribute. (any thing that dissatisfies) </li></ul>
    43. 43. Test case <ul><li>Set of procedures written by a tester which execute in our system to find defect. </li></ul><ul><ul><li>Positive test case </li></ul></ul><ul><ul><li>negative test case </li></ul></ul><ul><ul><li>A test case is said to be effective only when both positive and negative cases are prepared. </li></ul></ul>
    44. 44. Testing Economics & Cost <ul><li>Traditional Testing Continuous Testing </li></ul><ul><li> Accumulated Accumulated </li></ul><ul><li>Test cost Error Error Test cost </li></ul><ul><li> Remaining Remaining </li></ul><ul><li> 0 20 10 $ 10 </li></ul><ul><li> 0 40 15 $ 25 </li></ul><ul><li> 0 60 18 $ 42 </li></ul><ul><li>$ 480 12 4 $ 182 </li></ul><ul><li>$1690 0 0 $ 582 </li></ul>Requirement Design Code Testing Production
    45. 45. TESTING LEVELS <ul><li>Unit Testing </li></ul><ul><li>Integration Testing </li></ul><ul><li>System Testing </li></ul><ul><li>Acceptance Testing </li></ul>
    46. 46. Unit Testing <ul><li>Unit testing is a testing in which the individual unit of the software are tested in isolation from other parts of a program. </li></ul><ul><li>Advantage : </li></ul><ul><li>To catch the defects that occurs at the early stage of software development. </li></ul><ul><li>To minimize the ration of defects before moving to next level </li></ul>
    47. 47. Integration Testing <ul><li>Integration testing refers to the testing in which software units of an application combined and tested for a communication interfaces between them. </li></ul><ul><li>Big Bang Testing </li></ul><ul><li>Bottom Up Testing </li></ul><ul><li>Top Down Testing </li></ul>
    48. 48. Big Bang Testing Module - 1 System Module - 4 Module - 2 Module - 3 Module - 5 Module - 6
    49. 49. Big Bang Testing <ul><li>A type of integration in which software components of an application are combined all at once into a overall system according to this approach </li></ul><ul><li>Advantage : </li></ul><ul><li>To check the data flow from one module to another </li></ul><ul><li>Communication between various modules is checked </li></ul>
    50. 50. Integration <ul><li>Bottom-up Integration testing : </li></ul><ul><ul><li>In bottom up integration, all modules are added or combined from lower level hierarchy to higher level hierarchy I.e., the lower level model is tested in isolation first, then the next set of higher level modules are tested with the previously tested lower modules. </li></ul></ul><ul><ul><li>Worker modules are grouped into builds and integrated. </li></ul></ul>