Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Software testing by risk management

•
•
Kobi Vider
Kobi Vider

This document outlines a risk-based software testing methodology. It discusses testing approaches like regression, sanity, performance, functionality, and end-to-end testing. The methodology involves requirements analysis, test planning and design based on risk, and test reporting. Testing is done at the interface, component, requirement, and integration levels using the defined approaches. Test plans include scope, schedule, and results. Challenges are addressed and changes made to the test approach as needed. Open issues are also tracked.

1 of 16
www .KNAPP.c om Software Testing by Risk Management
www .KNAPP.c om Testing methodology  Software testing methodology, as shown at the next slide, implement the approach which supports examination of the project’s requirements, setting priorities based on risk analysis, and then determination of where to focus the testing efforts within the budget and the time constrains  The test planning, based on the risk analysis, presents the testing functional breakdown, and briefly describes each test purpose. The design phase produces several STD documents (for each of the usability, performance, functionality, values range, track, recovery, & stability testing cycles  Each testing phase measurements and defects will be concluded by a Software Test Report. A defects review ought to be done in order to reassess the pre-defined requirements
www .KNAPP.c om Testing methodology Development Testing Life Cycle Life Cycle Requirements Risk Analysis System Requirements Document Risk Analysis Document Test Plan System Test Detailed Plan (STP) System Design Design Test Design System Test Functionality Performance Sanity Regression Coding / Construction Compatibility Recovery Stability Usability End to End Testing Approaches Stress Load Volume Compliance Non Functional System Test Reassessment of Results (STR) Requirements
www .KNAPP.c om Testing Guidelines New Return Requirements Enhancements Single Business Bug Bug Flow Process Regression x x x x x Sanity x x x x x x Performance Functionality x x x x x x System Test x x x x End to End x x Non Functional
www .KNAPP.c om Testing approaches  Regression Regression testing is any type of software testing that seeks to uncover new errors, or regressions, in existing functionality after changes have been made to a system, such as functional enhancements, patches or configuration changes  Sanity A sanity test or sanity check is a basic test to quickly evaluate whether a claim or the result of a calculation can possibly be true. It is a simple check to see if the produced material is rational (that the material's creator was thinking rationally, applying sanity). The point of a sanity test is to rule out certain classes of obviously false results, not to catch every possible error  Performance Performance Testing covers a wide range of engineering or functional evaluations where a material, product, system, or person is not specified by detailed material or component specifications: rather, emphasis is on the final measurable performance characteristics. Testing can be a qualitative or quantitative procedure  Functionality Functional testing is a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output  System Test System testing of software or hardware is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic  End to End End-to-end testing is the process of testing transactions or business level products as they pass right through the computer systems. Thus this generally ensures that all aspects of the business are supported by the systems under test
www .KNAPP.c om Definitions  Functionality the quality or state of being functional; especially: the set of functions or capabilities associated with computer software or hardware or an electronic device  Enhancements Heighten, increase; especially: to increase or improve in value, quality, desirability, or attractiveness  Patches A patch is a piece of software designed to fix problems with, or update a computer program or its supporting data  Configuration changes  Qualitative The term refers to descriptions or distinctions based on some quality or characteristic rather than on some quantity or measured value  Quantitative The term refers to a type of information based in quantities or else quantifiable data  Black-box testing Method of software testing that tests the functionality of an application as opposed to its internal structures or workings (see white-box testing). Specific knowledge of the application's code/internal structure and programming knowledge in general is not required. The tester is only aware of what the software is supposed to do, but not how  White-box testing Also known as clear box testing, glass box testing, transparent box testing, and structural testing) is a method of testing software that tests internal structures or workings of an application, as opposed to its functionality  Compliance Conformity in fulfilling official requirements
www .KNAPP.c om Test Plan and Report– high level structure  Reporting and communication – Test plan – Test cases development and coverage – Test execution progress – Testing results
www .KNAPP.c om Developed Interfaces Testing approach  Regression – Scope / week X / NA  Sanity – Scope / week X / NA  Performance – Scope / week X / NA  Functionality – Scope / week X NA
www .KNAPP.c om Developed Components Testing approach  Regression – Scope / week X / NA  Sanity – Scope / week X / NA  Performance – Scope / week X / NA  Functionality – Scope / week X NA
www .KNAPP.c om Developed Requirments Testing approach  R1 – Regression – Scope / week X / NA – Sanity – Scope / week X / NA – Performance – Scope / week X / NA – Functionality – Scope / week X NA  R2 – Regression – Scope / week X / NA – Sanity – Scope / week X / NA – Performance – Scope / week X / NA – Functionality – Scope / week X NA – End to End - Scope / week X NA
www .KNAPP.c om Integration Requirments Testing approach  Regression – Scope / week X / NA  Sanity – Scope / week X / NA  Performance – Scope / week X / NA  Functionality – Scope / week X NA
www .KNAPP.c om Failed Test Cases Analysis
www .KNAPP.c om Not tested and failed test cases per suite <>  Component X – Failed – To be tested  Component X – Failed – To be tested  Component X – 8 Failed – To be tested  Component X – Failed – To be tested
www .KNAPP.c om Challenges during test  <>
www .KNAPP.c om Changes due to Challenges  <>
www .KNAPP.c om Open Issues  <>

More Related Content

Software testing by risk management

  • 1. www .KNAPP.c om Software Testing by Risk Management
  • 2. www .KNAPP.c om Testing methodology  Software testing methodology, as shown at the next slide, implement the approach which supports examination of the project’s requirements, setting priorities based on risk analysis, and then determination of where to focus the testing efforts within the budget and the time constrains  The test planning, based on the risk analysis, presents the testing functional breakdown, and briefly describes each test purpose. The design phase produces several STD documents (for each of the usability, performance, functionality, values range, track, recovery, & stability testing cycles  Each testing phase measurements and defects will be concluded by a Software Test Report. A defects review ought to be done in order to reassess the pre-defined requirements
  • 3. www .KNAPP.c om Testing methodology Development Testing Life Cycle Life Cycle Requirements Risk Analysis System Requirements Document Risk Analysis Document Test Plan System Test Detailed Plan (STP) System Design Design Test Design System Test Functionality Performance Sanity Regression Coding / Construction Compatibility Recovery Stability Usability End to End Testing Approaches Stress Load Volume Compliance Non Functional System Test Reassessment of Results (STR) Requirements
  • 4. www .KNAPP.c om Testing Guidelines New Return Requirements Enhancements Single Business Bug Bug Flow Process Regression x x x x x Sanity x x x x x x Performance Functionality x x x x x x System Test x x x x End to End x x Non Functional
  • 5. www .KNAPP.c om Testing approaches  Regression Regression testing is any type of software testing that seeks to uncover new errors, or regressions, in existing functionality after changes have been made to a system, such as functional enhancements, patches or configuration changes  Sanity A sanity test or sanity check is a basic test to quickly evaluate whether a claim or the result of a calculation can possibly be true. It is a simple check to see if the produced material is rational (that the material's creator was thinking rationally, applying sanity). The point of a sanity test is to rule out certain classes of obviously false results, not to catch every possible error  Performance Performance Testing covers a wide range of engineering or functional evaluations where a material, product, system, or person is not specified by detailed material or component specifications: rather, emphasis is on the final measurable performance characteristics. Testing can be a qualitative or quantitative procedure  Functionality Functional testing is a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output  System Test System testing of software or hardware is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic  End to End End-to-end testing is the process of testing transactions or business level products as they pass right through the computer systems. Thus this generally ensures that all aspects of the business are supported by the systems under test
  • 6. www .KNAPP.c om Definitions  Functionality the quality or state of being functional; especially: the set of functions or capabilities associated with computer software or hardware or an electronic device  Enhancements Heighten, increase; especially: to increase or improve in value, quality, desirability, or attractiveness  Patches A patch is a piece of software designed to fix problems with, or update a computer program or its supporting data  Configuration changes  Qualitative The term refers to descriptions or distinctions based on some quality or characteristic rather than on some quantity or measured value  Quantitative The term refers to a type of information based in quantities or else quantifiable data  Black-box testing Method of software testing that tests the functionality of an application as opposed to its internal structures or workings (see white-box testing). Specific knowledge of the application's code/internal structure and programming knowledge in general is not required. The tester is only aware of what the software is supposed to do, but not how  White-box testing Also known as clear box testing, glass box testing, transparent box testing, and structural testing) is a method of testing software that tests internal structures or workings of an application, as opposed to its functionality  Compliance Conformity in fulfilling official requirements
  • 7. www .KNAPP.c om Test Plan and Report– high level structure  Reporting and communication – Test plan – Test cases development and coverage – Test execution progress – Testing results
  • 8. www .KNAPP.c om Developed Interfaces Testing approach  Regression – Scope / week X / NA  Sanity – Scope / week X / NA  Performance – Scope / week X / NA  Functionality – Scope / week X NA
  • 9. www .KNAPP.c om Developed Components Testing approach  Regression – Scope / week X / NA  Sanity – Scope / week X / NA  Performance – Scope / week X / NA  Functionality – Scope / week X NA
  • 10. www .KNAPP.c om Developed Requirments Testing approach  R1 – Regression – Scope / week X / NA – Sanity – Scope / week X / NA – Performance – Scope / week X / NA – Functionality – Scope / week X NA  R2 – Regression – Scope / week X / NA – Sanity – Scope / week X / NA – Performance – Scope / week X / NA – Functionality – Scope / week X NA – End to End - Scope / week X NA
  • 11. www .KNAPP.c om Integration Requirments Testing approach  Regression – Scope / week X / NA  Sanity – Scope / week X / NA  Performance – Scope / week X / NA  Functionality – Scope / week X NA
  • 12. www .KNAPP.c om Failed Test Cases Analysis
  • 13. www .KNAPP.c om Not tested and failed test cases per suite <>  Component X – Failed – To be tested  Component X – Failed – To be tested  Component X – 8 Failed – To be tested  Component X – Failed – To be tested
  • 14. www .KNAPP.c om Challenges during test  <>
  • 15. www .KNAPP.c om Changes due to Challenges  <>
  • 16. www .KNAPP.c om Open Issues  <>