basic software testing principles and obectives.pptx

Basics of software testing

1. Srihari Techsoft Unit 1 Software Testing Fundamentals An overview

2. Srihari Techsoft Introduction & Fundamentals What is Software Testing? Why testing is necessary? Who does the testing? What has to be tested? When is testing done? How often to test?

3. Srihari Techsoft Most Common Software problems Incorrect calculation Incorrect data edits & ineffective data edits Incorrect matching and merging of data Data searches that yields incorrect results Incorrect processing of data relationship Incorrect coding / implementation of business rules Inadequate software performance

4. Srihari Techsoft Confusing or misleading data Software usability by end users & Obsolete Software Inconsistent processing Unreliable results or performance Inadequate support of business needs Incorrect or inadequate interfaces with other systems Inadequate performance and security controls Incorrect file handling

5. Srihari Techsoft Objectives of testing Executing a program with the intent of finding an error . To check if the system meets the requirements and be executed successfully in the Intended environment. To check if the system is “ Fit for purpose”. To check if the system does what it is expected to do.

6. Srihari Techsoft Objectives of testing A good test case is one that has a probability of finding an as yet undiscovered error. A successful test is one that uncovers a yet undiscovered error. A good test is not redundant. A good test should be “best of breed”. A good test should neither be too simple nor too complex.

7. Srihari Techsoft Objective of a Software Tester Find bugs as early as possible and make sure they get fixed. To understand the application well. Study the functionality in detail to find where the bugs are likely to occur. Study the code to ensure that each and every line of code is tested. Create test cases in such a way that testing is done to uncover the hidden bugs and also ensure that the software is usable and reliable

8. Srihari Techsoft VERIFICATION & VALIDATION Verification - typically involves reviews and meeting to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walkthroughs, and inspection meeting. Validation - typically involves actual testing and takes place after verifications are completed. Validation and Verification process continue in a cycle till the software becomes defects free.

9. Defect, Error, Bug, Failure and Fault Testing is the process of identifying defects, where a defect is any variance between actual and expected results. “A mistake in coding is called Error, error found by tester is called Defect, defect accepted by development team then it is called Bug, build does not meet the requirements then it Is Failure.”

10. DEFECT: It can be simply defined as a variance between expected and actual. The defect is an error found AFTER the application goes into production. It commonly refers to several troubles with the software products, with their external behavior or with its internal features. In other words, a Defect is a difference between expected and actual results in the context of testing. It is the deviation of the customer requirement. ERROR: An error is a mistake, misconception, or misunderstanding on the part of a software developer. For example, a developer may misunderstand a de-sign notation, or a programmer might type a variable name incorrectly – leads to an Error

11. BUG: A bug is the result of a coding error. An Error found in the development environment before the product is shipped to the customer FAILURE: A failure is the inability of a software system or component to perform its required functions within specified performance requirements. When a defect reaches the end customer it is called a Failure. During development, Failures are usually observed by testers. FAULT: An incorrect step, process or data definition in a computer program that causes the program to perform in an unintended or unanticipated manner. A fault is introduced into the software as the result of an error.

12. Software Testing Principles Principle 1 : Testing shows presence of defects: 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. Principle 2 : Exhaustive testing is impossible: Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. Instead of exhaustive testing, we use risks and priorities to focus testing efforts.

13. Principle 3 : Early testing: Testing activities should start as early as possible in the software or system development life cycle and should be focused on defined objectives. Principle 4 : Defect clustering: A small number of modules contain most of the defects discovered during pre-release testing or show the most operational failures. Defect clustering simply means that a small number of features have caused the majority of quality issues in an application.

14. Principle 5 : Pesticide paradox: If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new bugs. To overcome this 'pesticide paradox', the test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects.

15. Principle 6 : Testing is context dependent: Testing is done differently in different contexts. For example, safety-critical software is tested differently from an e-commerce site. Principle 7 : Absence-of-errors fallacy: Finding and fixing defects does not help if the system built is unusable and does not fulfill the users' needs and expectations.

16. Code Inspections A code inspection is a set of procedures and error-detection techniques for group code reading. Most discussions of code inspections focus on the procedures, forms to be filled out, and so on.

17. Types of defects which can be easier to find during inspections: Deviations from standards Non-maintainable code Design defects Missing requirements Inconsistent interface specifications

18. During the Review process four-five types of participants that take part in testing are: Moderator : Performs entry check, follow up on rework, coaching team member, schedule the meeting. Author/Programmer : Takes responsibility for fixing the defect found and improves the quality of the document Scribe : does the logging of the defect during a review and attends the review meeting Reviewer : Check material for defects and inspects Manager : Decide on the execution of reviews and ensures the review process objectives are met.

19. Inspection Team An inspection team usually consists of four people. The first of the four plays the role of moderator. The moderator is expected to be a competent programmer , but he or she is not the author of the program and need not be acquainted with the details of the program. Moderator duties include: Distributing materials for, and scheduling, the inspection session. Leading the session. Recording all errors found. Ensuring that the errors are subsequently corrected.

20. Inspection Team The second team member is the programmer . The remaining team members usually are the program’s designer (if different from the programmer) and a test specialist . The specialist should be well versed in software testing and familiar with the most common programming errors.

21. Duties of inspection team The moderator is responsible for ensuring that the discussions proceed along productive lines and that the participants focus their attention on finding errors, not correcting them . The programmer corrects errors after the inspection session. Upon the conclusion of the inspection session, the programmer is given a list of the errors uncovered . If more than a few errors were found, or if any of the errors require a substantial correction, the moderator might make arrangements to reinspect the program after those errors have been corrected. This subsequent list of errors is also analyzed, categorized, and used to refine the error checklist to improve the effectiveness of future inspections.

22. Usually, the defect discovered during static testing are due to: security vulnerabilities, undeclared variables, boundary violations, syntax violations, inconsistent interface, etc.

23. An Error Checklist for Inspections An important part of the inspection process is the use of a checklist to examine the program for common errors.

24. Example

25. Data Reference Errors Does a referenced variable have a value that is unset or uninitialized? This probably is the most frequent programming error, occurring in a wide variety of circumstances. For each reference to a data item (variable, array element, field in a structure), attempt to ‘‘prove’’ informally that the item has a value at that point. 2. For all array references, is each subscript value within the defined bounds of the corresponding dimension?

26. 3 . For all array references, does each subscript have an integer value? This is not necessarily an error in all languages, but, in general, working with non-integer array references is a dangerous practice.

27. For all references through pointer or reference variables, is the referenced memory currently allocated ? This is known as the ‘‘dangling reference’’ problem.

28. Data Declaration Errors

29. Computation Errors

30. Comparison Errors

31. Comparison Errors If you want to determine whether i is between 2 and 10, the expression 2 < i < 10 is incorrect. Instead, it should be (2 < i)&& (i < 10) .

32. Comparison Errors If you want to determine whether i is greater than x or y , i > x || y is incorrect. Instead, it should be ( i > x) || ( i > y) . If you want to compare three numbers for equality, if(a == b == c) does something quite different. If you want to test the mathematical relation x > y > z , the correct expression is (x > y)&&(y > z) .

33. Interface Errors

34. Interface errors

35. Control Flow Errors int f1(int x,int y){ 1 while (x != y){ 2 if (x>y) then 3 x=x-y; 4 else y=y-x; 5 } 6 return x; } Errors in defining the flow of the control flow graph. 1 2 3 4 5 6

36. Input/Output Errors

37. Walkthroughs The code walkthrough, like the inspection, is a set of procedures and error-detection techniques for group code reading. It shares much in common with the inspection process, but the procedures are slightly different, and a different error-detection technique is employed. Like the inspection, the walkthrough is an uninterrupted meeting of one to two hours in duration. The walkthrough team consists of three to five people. One of these people plays a role similar to that of the moderator in the inspection process; another person plays the role of a secretary (a person who records all errors found); and a third person plays the role of a tester

38. Suggestions for the other participants include: A highly experienced programmer A programming-language expert A new programmer (to give a fresh, unbiased outlook) The person who will eventually maintain the program Someone from a different project Someone from the same programming team as the programmer