Testing ppt
- 2. Testing process . oracle s s test strategy compare input set of input set of input expected output real output test results
- 3. Observations about testing “Testing is the process of executing a program with the intention of finding errors.” – Myers “Testing can show the presence of bugs but never their absence.” - Dijkstra
- 4. Levels of testing Unit Testing Integration Testing Validation Testing Regression Testing Alpha Testing Beta Testing Acceptance Testing
- 5. Unit testing Algorithms and logic Data structures (global and local) Interfaces Independent paths Boundary conditions Error handling
- 6. Why integration testing is necessary? One module can have an adverse effect on another Sub-functions, when combined, may not produce the desired major function Individually acceptable imprecision in calculations may be magnified to unacceptable levels
- 7. Validation testing Determine if the software meets all of the requirements defined in the SRS Having written requirements is essential Regression testing is performed to determine if the software still meets all of its requirements in light of changes and modifications to the software Regression testing involves selectively repeating existing validation tests, not developing new tests
- 8. ALPHA AND BETA TESTING It’s best to provide customers with an outline of the things that you would like them to focus on and specific test scenarios for them to execute. Provide with customers who are actively involved with a commitment to fix defects that they discover.
- 9. ACCEPTANCE TESTING Similar to validation testing except that customers are present or directly involved. Usually the tests are developed by the customer
- 10. TESTING METHODS White box or glass box testing Black box testing Top-down and bottom-up for performing incremental integration ALAC (Act-like-a-customer)
- 11. WHITE BOX TESTING 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 (i.e. black-box testing). In white-box testing an internal perspective of the system, as well as programming skills, are used to design test cases.
- 12. BLACK BOX TESTING Black-box testing is a method of software testing that examines the functionality of an application without peering into its internal structures or workings. This method of test can be applied to virtually every level of software testing: unit, integration, system and acceptance. It typically comprises most if not all higher level testing, but can also dominate unit testing as well.
- 13. Top down Testing: In this approach testing is conducted from main module to sub module. if the sub module is not developed a temporary program called STUB is used for simulate the submodule. Advantages: - Advantageous if major flaws occur toward the top of the program. - Once the I/O functions are added, representation of test cases is easier. Disadvantages: - Stub modules must be produced - Stub Modules are often more complicated than they first appear to be. - Before the I/O functions are added, representation of test cases in stubs can be difficult. - Test conditions ma be impossible, or very difficult, to create. - Observation of test output is more difficult. - Allows one to think that design and testing can be overlapped. - Induces one to defer completion of the testing of certain modules.
- 14. Bottom up testing In this approach testing is conducted from sub module to main module, if the main module is not developed a temporary program called DRIVERS is used to simulate the main module. Advantages: - Advantageous if major flaws occur toward the bottom of the program. - Test conditions are easier to create. - Observation of test results is easier. Disadvantages: - Driver Modules must be produced. - The program as an entity does not exist until the last module is added.
- 15. Act-like-a-customer Act-like-a-customer (ALAC) software testing is a method in which tests are developed based on knowledge of how customers use the software product. ALAC tests are based on the principle that complex software products have many bugs. ALAC tests allow us to focus on finding those bugs that customers are most likely to find. Acting like a customer also means developing tests that: a) Do it wrong; b) Use wrong or illegal combinations of input; c) Do not do enough; d) Do nothing; e) Do too much.
- 16. Dynamic testing classification: DYNAMIC TESTING STATIC TESTING REVIEW PEAR VIEW WALK THROUGH STRUCTURAL TESTING NON- FUNCTIONAL TESTING Usability Security performance FUNCTIONAL TESTING EP(EQUIVALE NT PARTION BVA(BOUND ARY VALUE ANALYSIS) UCA(USE CASE ANALYSIS)
- 17. Usability testing: Usability testing is a way to see how easy to use something is by testing it with real users. Users are asked to complete tasks, typically while they are being observed by a researcher, to see where they encounter problems and experience confusion.
- 18. Security testing: Security testing is a testing technique to determine if an information system protects data and maintains functionality as intended. It also aims at verifying 6 basic principles as listed below: Confidentiality Integrity Authentication Authorization Availability Non-repudiation
- 19. PERFORMANCE TESTING The process of determining the speed or effectiveness of a computer, network, software program or device. This process can involve quantitative tests done in a lab, such as measuring the response time or the number of MIPS (millions of instructions per second) at which a system functions.
- 20. PERFORMANCE TESTING TYPES: LOAD TESTING VOLUME TESTING STRESS TESTING
- 21. Load testing The process of putting demand on a software system or computing device and measuring its response. Load testing is performed to determine a system's behaviour under both normal and anticipated peak load conditions.
- 22. Volume testing Volume testing is a Non-functional testing that is performed as part of performance testing where the software is subjected to a huge volume of data. It is also referred as flood testing.
- 23. Stress testing Stress testing is the process of determining the ability of a computer, network, program or device to maintain a certain level of effectiveness under unfavourable conditions. The process can involve quantitative tests done in a lab, such as measuring the frequency of errors or system crashes.
- 24. DOCUMENTATION Testing documentation involves the documentation of artifacts that should be developped before or during the testing of Software. Test Plan Test Scenario Test Case Traceability Matrix
- 25. Test Plan A test plan outlines the strategy that will be used to test an application, the resources that will be used, the test environment in which testing will be performed, and the limitations of the testing and the schedule of testing activities. Typically the Quality Assurance Team Lead will be responsible for writing a Test Plan.
- 26. Test Scenario It is a one line statement that notifies what area in the application will be tested. Test scenarios are used to ensure that all process flows are tested from end to end. A particular area of an application can have as little as one test scenario to a few hundred scenarios depending on the magnitude and complexity of the application.
- 27. Test Case Test cases involve a set of steps, conditions, and inputs that can be used while performing testing tasks. The main intent of this activity is to ensure whether a software passes or fails in terms of its functionality and other aspects. There are many types of test cases such as functional, negative, error, logical test cases, physical test cases, UI test cases, etc. However, the following components are always available and included in every test case: Test case ID Product module. Product version Revision history Purpose Assumptions Pre-conditions Steps Expected outcome. Actual outcome Post-conditions
- 28. Traceability Matrix Traceability Matrix (also known as Requirement Traceability Matrix - RTM) is a table that is used to trace the requirements during the SDLC. It can be used for forward tracing (i.e. from Requirements to Design or Coding) or backward (i.e. from Coding to Requirements). There are many user-defined templates for RTM. Each requirement in the RTM document is linked with its associated test case so that testing can be done as per the mentioned requirements. Furthermore, Bug ID is also included and linked with its associated requirements and test case. The main goals for this matrix are: Make sure the software is developed as per the mentioned requirements. Helps in finding the root cause of any bug. Helps in tracing the developed documents during different phases of SDLC.