CMST 5103 EXAM REVIEW 1. FUNDAMENTAL OF ERROR, DEFECT AND FAILURE RELATIONSHIP Error: Human action that create incorrect result. Also known as mistakes. Mistake in syntax, or there is mistake in invocation of variable or might be there is some mistakes in which database connectivity code is faulty. Fault is the adjudged cause of an error. Defect: A flaw in a component or system that can cause the component or sytems to fail to perform its required function. Also known as bug, fault, and flaw. Defects may occurs due to errors(Mistakes in code or document) that cause deviation from actual result. Failure : Deviation of the component or system from its expected delivery, services or result. Also known as deviation. When defect is found by e nd-user then it is called as failure. People make errors which introduce defects in the system and Tester observes the effect of defect which is failure. So developers introduce defects because of errors, tester find the failure and developer again find the defect by debugging i.e. the root cause of the failure and fix it. Then Tester verify the failure i.e. failure is gone or not. In short Failure occurs due to defect and defect occurs due to errors . 2. SEVEN P RINCIPLE OF TESTING (ISTQB Foundation) 1. Testing shows presence of defect Testing can show that defects are present, but cannot prove that there are no defects. Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, it is not a proof of correctness. 2. Exhaustive testing is impossible Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. Instead of exhaustive testing, risk analysis and priorities should be used to focus testing efforts. 3. Early testing To find defects early, testing activities shall be started as early as possible in the software or system development life cycle, and shall be focused on defined objectives. 4. Defect Clustering Testing effort shall be focused proportionally to the expected and later observed defect density of modules. A small number of modules usually contains most of the defects discovered during pre -release testing, or is responsible for most of the operational failure s. 5. Pesticide Paradox If the same tests are repeated over and over again, eventually the sames set of test cases will no longer find any new defects. To overcome this test cases need to be regulary reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to find potentially more defects. 6. Testing is context dependent Testing is done in different contexts. For example, safety -critical software is tested differently from an e -commerce site. 7. Abse nce-of-failure fallacy Finding and fixing defects does not help if the system built is unusable and does not fulfill the user’s needs and expectations. 3. LEVEL OF TESTING –UNIT, INTEGRATION, SYSTEM, ACCEPTANCE, MAINTENANCE, REGRESSION TESTING; WHEN TO US E IT, HOW TO USE, VAUGHN DIAGRAM Unit testing: The first test in the development process is the unit test. Testing of individual software components or modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Unit test depends upon the language on which the project is developed. Integration testing: Testing in which modules are combined and tested as a group. Modules are typically code modules, individual applications, client and server applications on a network, etc. Integration Testing follows unit testing and precedes system testing. System testing: Testing conducted on a complete, integrated system to eval uate 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. Acceptance testing: Testing to verify a product mee ts customer specified requirements. A customer usually does this type of testing on a product that is developed externally. Regression testing: Testing the application as a whole for the modification in any module or functionality. Such testing ensures rep orted product defects have been corrected for each new release and that no new quality problems were introduced in the maintenance process. 4. REGRES SION VS RETESTING Re-Testing : After a defect is detected and fixed, the software should be retested to co nfirm that the original defect has been successfully removed. This is called Confirmation Testing or Re -
Testing Regression testing : Testing your software application when it undergoes a code change to ensure that the new code has not affected other parts of the software. Retesting is done to make sure that bug is fixed and failed functionality is working fine or not, This is kind of verification method followed in testing field for the fixed bugs. Whereas, Regression is re -execution of the test cases for u nchanged part to see that unchanged functionality is working fine are not. Retesting is a planned testing while Regression is known as the generic testing. Retesting is only done for failed Test cases while Regression is done for passed test cases. We shou ld always keep this in mind, Re-testing has higher priority than the regression testing . But in bigger projects Retesting and Regression is done in parallel effort. But never forget importance of both in the success of the project. Regression Testing Retesting Regression testing is a type of software testing that intends to ensure that changes like defect fixes or enhancements to the module or application have not affecting unchanged part. Retesting is done to make sure that the tests cases which failed in last execution are passing after the defects against those failures are fixed. Regression testing is not carried out on specific defect fixes. It is planned as specific area or full regression testing. Retesting is carried out based on the defect fixes. In Regression testing, you can include the test cases which passed earlier. We can say that check the functionality which was working earlier. In Retesting, you can include the test cases which failed earlier. We can say that check the functionality which was failed in earlier build. Regression test cases we use are derived from the functional specification, the user manuals, user tutorials, and defect reports in relation to corrected problems. Test cases for Retesting cannot be prepared before start testing. In Retesting only re -
execute the test cases failed in the prior execution. Automation is the key for regression testing. Manual regression testing tends to get more You cannot automate the test cases for Retesting.
Testing Regression testing : Testing your software application when it undergoes a code change to ensure that the new code has not affected other parts of the software. Retesting is done to make sure that bug is fixed and failed functionality is working fine or not, This is kind of verification method followed in testing field for the fixed bugs. Whereas, Regression is re -execution of the test cases for u nchanged part to see that unchanged functionality is working fine are not. Retesting is a planned testing while Regression is known as the generic testing. Retesting is only done for failed Test cases while Regression is done for passed test cases. We shou ld always keep this in mind, Re-testing has higher priority than the regression testing . But in bigger projects Retesting and Regression is done in parallel effort. But never forget importance of both in the success of the project. Regression Testing Retesting Regression testing is a type of software testing that intends to ensure that changes like defect fixes or enhancements to the module or application have not affecting unchanged part. Retesting is done to make sure that the tests cases which failed in last execution are passing after the defects against those failures are fixed. Regression testing is not carried out on specific defect fixes. It is planned as specific area or full regression testing. Retesting is carried out based on the defect fixes. In Regression testing, you can include the test cases which passed earlier. We can say that check the functionality which was working earlier. In Retesting, you can include the test cases which failed earlier. We can say that check the functionality which was failed in earlier build. Regression test cases we use are derived from the functional specification, the user manuals, user tutorials, and defect reports in relation to corrected problems. Test cases for Retesting cannot be prepared before start testing. In Retesting only re -
execute the test cases failed in the prior execution. Automation is the key for regression testing. Manual regression testing tends to get more You cannot automate the test cases for Retesting.
