More Related Content
What's hot (20)
Viewers also liked (20)
Similar to Software testing and process (20)
Recently uploaded (20)
Software testing and process
- 1. Software Testing and Process.. BY GOURAV KALBALIA 1
- 2. Various types of testing in a Software.. Testing Concepts Testing Process Black-Box Testing White-Box Testing Metrics Testing 2
- 3. Testing Concepts… Error, Fault and Failure Test Case, Test Suite and Test Harness Psychology of Testing Level of Testing 3
- 4. Error refers to the discrepancy between a computed value and the true, or theoretically correct value. It is the difference between the actual output of a software and the correct output. Error is also used to refer to human action that results in software containing a defect or fault 4
- 5. Fault is a condition that causes a system to fail in performing its required function. A fault is the basic reason for software malfunction and is practically synonymous with the commonly used term bug, or the somewhat more general term defect. Failure is the inability of a system or component to perform a required function according to its specifications. A software failure occurs if the behaviour of the software is different from the specified behaviour. Failures may be caused by functional or performance factors. 5
- 6. Presence of an error (in the state) implies that a failure must have occurred, and the observance of a failure implies that a fault must be present in the system. However, the presence of a fault does not imply that a failure must occur. The presence of a fault in a system only implies that the fault has a potential to cause a failure. 6
- 7. Test Case, Test Suite, and Test Harness A test case (often called a test) can be considered as comprising a set of test inputs and execution conditions, which are designed to exercise the SUT(software under testing) in a particular manner. A test case also specifies the expected outcome from executing the SUT under the specified execution conditions and test inputs. A testing framework is also sometimes called a test harness. A test harness or a test framework makes the life of a tester simpler by providing easy means of defining a test suite, executing it, and reporting the results. 7
- 8. There is another level of testing, called regression testing. It is performed when some changes are made to an existing system. Besides ensuring the desired behaviour of the new services, testing has to ensure that the desired behaviour of the old services is maintained. Complete regression testing of large systems can take a considerable amount of time, even if automation is used. 8
- 9. Psychology of Testing There are a number of heuristics and rules of thumb for deciding the test cases, selecting test cases is still a creative activity that relies on the ingenuity of the tester. Because of this, the psychology of the person performing the testing becomes important 9
- 10. Levels of Testing Testing detect the faults remaining from earlier stages, in addition to the faults introduced during coding itself. At each level of testing aims to test different aspects of the system. The basic levels are attempt to detect different types of faults. 10
- 11. The first level of testing is called unit testing, it is essentially for verification of the code produced by individual programmers. Then next level of testing is called integration testing. Many unit tested modules are combined into subsystems, which are then tested. The goal here is to see if the modules can be integrated properly. 11
- 12. In System testing and acceptance testing the entire software system is tested. The goal is to see if the software meets its requirements. This is often a large exercise, which for large projects may last many weeks or months. Acceptance testing is often performed with realistic data of the client to demonstrate that the software is working satisfactorily. Acceptance testing tests if the system satisfactorily solves the problems for which it was commissioned. 12
- 13. Testing Process… Testing is a quality control activity which focuses on identifying defects (which are then removed). For each software unit testing, the test cases will have to be designed and then executed. Overall, testing in a project is a complex task which also consumes the maximum effort. Hence, testing has to be done properly in a project The testing process for a project consists of three high-level tasks— Test planning, Test case design, Test execution. 13
- 14. Test case design is a major activity in the testing process. Careful selection of test cases that satisfy the criterion and approach specified is essential for proper testing Another reason for specifying the test cases in a document or a script is that by doing this, the tester can see the testing of the unit in totality and the effect of the total set of test cases. This type of evaluation is hard to do in on-the-fly testing where test cases are determined as testing proceeds. It also allows optimizing the number of test cases as evaluation of the test suite may show that some test cases are redundant 14
- 15. In a project, testing commences with a test plan and terminates with successful execution of acceptance testing. A test plan is a general document for the entire project that defines the scope, approach to be taken, and the schedule of testing, as well as identifies the test items for testing and the personnel responsible for the different activities of testing. The test planning can be done well before the actual testing commences and can be done in parallel with the coding and design activities. The inputs for forming the test plan are: Project plan, Requirements document Architecture or design document. A test plan should contain the following: Test unit specification – Features to be tested – Approach for testing – Test deliverables – Schedule and task allocation 15
- 16. Test Plan and Design The test plan focuses on how the testing for the project will proceed, which units will be tested, and what approaches (and tools) are to be used during the various stages of testing. Test case design has to be done separately for each unit. Based on the approach specified in the test plan, and the features to be tested, the test cases are designed and specified for testing the unit. In a round of testing, the outcome of all the test cases is recorded (i.e., pass or fail). 16
- 17. Test Case Execution With the specification of test cases, the next step in the testing process is to execute them Executing the test cases may require construction of driver modules or stubs. It may also require modules to set up the environment as stated in the test plan and test case specifications. Only after all these are ready can the test cases be executed. During test case execution, defects are found. These defects are then fixed and tesing is done again to verify the fix. To facilitate reporting and tracking of defects found during testing (and other quality control activities), defects found are often logged. During test case execution, defects are found. These defects are then fixed and tesing is done again to verify the fix. To facilitate reporting and tracking of defects found during testing (and other quality control activities), defects found are often logged. Defect logging and tracking is considered one of the best practices for managing a project , and is followed by most software organizations. 17
- 18. There are some good reasons why test cases are specified before they are used for testing. It is known that testing has severe limitations and the effectiveness of testing depends very heavily on the exact nature of the test cases. It is therefore important to ensure that the set of test cases used is of high quality. a formal document or work product is needed, for review of test cases, the test case specification document is required. This is the primary reason for documenting the test cases. 18
- 19. A defect can be found by anyone at anytime. When a defect is found, it is logged in a defect control system, along with sufficient information about the defect. The defect is then in the state “submitted,” Now The assigned person does the debugging and fixes the reported defect. Then defect enters the “fixed” state. However, a defect that is fixed is still not considered as fully done. 19
- 20. The successful fixing of the defect is verified. This verification may be done by another person (often the submitter), or by a test team, and typically involves running some tests. Once the defect fixing is verified, then the defect can be marked as “closed.” In other words, the general life cycle of a defect has three states—submitted, fixed, and closed, A defect that is not closed is also called open. Besides using the log for tracking defects, the data in the log can also be used for analysis purposes 20
- 21. The successful fixing of the defect is verified. This verification may be done by another person (often the submitter), or by a test team, and typically involves running some tests. Once the defect fixing is verified, then the defect can be marked as “closed.” In other words, the general life cycle of a defect has three states—submitted, fixed, and closed, A defect that is not closed is also called open. Besides using the log for tracking defects, the data in the log can also be used for analysis purposes 21
- 22. Thank You 22