Manual Testing What is Testing?

An examination of the behavior of a program by executing on sample data sets. Testing comprises of set of activities to detect defects in a produced material. To unearth & correct defects. To detect defects early & to reduce cost of defect fixing. To avoid user detecting problems. To ensure that product works as users expected it to.

Why Testing?

To unearth and correct defects. To detect defects early and to reduce cost of defect fixing. To ensure that product works as user expected it to. To avoid user detecting problems.

Testing Techniques Black Box Testing -Testing of a function without knowing internal structure of the program. White Box Testing -Testing of a function with knowing internal structure of the program. Regression Testing -To ensure that the code changes have not had an adverse affect to the other modules or on existing functions. Functional Testing:

Study SRS Identify Unit Functions For each unit function Take each input function Identify Equivalence class Form Test cases Form Test cases for boundary values From Test cases for Error Guessing Form Unit function v/s Test cases, Cross Reference Matrix Find the coverage

Unit Testing:

The most 'micro' scale of testing to test particular functions or code modules. Typically done by the programmer and not by testers . Unit - smallest testable piece of software. A unit can be compiled/ assembled/ linked/ loaded; and put under a test harness.

Unit testing done to show that the unit does not satisfy the functional specification and/ or its implemented structure does not match the intended design structure.

Integration Testing:

Integration is a systematic approach to build the complete software structure specified in the design from unit-tested modules. There are two ways integration performed. It is called Pre-test and Pro-test. Pre-test: the testing performed in Module development area is called Pre-test. The Pre-test is required only if the development is done in module development area.

Alpha testing: * Testing of an application when development is nearing completion minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers. Beta testing: * Testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers. System Testing:

A system is the big component. System testing is aimed at revealing bugs that cannot be attributed to a component as such, to inconsistencies between components or planned interactions between components. Concern: issues, behaviors that can only be exposed by testing the entire integrated system (e.g., performance, security, recovery).

Volume Testing: * The purpose of Volume Testing is to find weaknesses in the system with respect to its handling of large amounts of data during short time periods. For example, this kind of testing ensures that the system will process data across physical and logical boundaries such as across servers and across disk partitions on one server. Stress testing: * This refers to testing system functionality while the system is under unusually heavy or peak load; it's similar to the validation testing mentioned previously but is carried out in a "high-stress" environment. This requires that you make some predictions about expected load levels of your Web site. Usability testing:

* Usability means that systems are easy and fast to learn, efficient to use, easy to remember, cause no operating errors and offer a high degree of satisfaction for the user. Usability means bringing the usage perspective into focus, the side towards the user. Security testing: * If your site requires firewalls, encryption, user authentication, financial transactions, or access to databases with sensitive data, you may need to test these and also test your site's overall protection against unauthorized internal or external access. Test Life Cycle

Identify Test Candidates Test Plan Design Test Cases Execute Tests Evaluate Results Document Test Results Post Shipment Review

Test Plan: * A Test Plan is a detailed project plan for testing, covering the scope of testing, the methodology to be used, the tasks to be performed, resources, schedules, risks, and dependencies. A Test Plan is developed prior to the implementation of a project to provide a well defined and understood project roadmap. Test Specification: * A Test Specification defines exactly what tests will be performed and what their scope and objectives will be. A Test Specification is produced as the first step in implementing a Test Plan, prior to the onset of manual testing and/or automated test suite development. It provides a repeatable, comprehensive definition of a testing campaign

BVA is done like this,max value = 10 passmax-1 = 9 passmax+1 = 11 failmin = 4 passmin+1 = 5 passmin-1 = 3 fail.Like wise we check the corner values and come out with a details whether theapplication is accepting correct range of values. Sanity testing: Sanity testing is product or project is sane enough(Marked bysound judgment) or not ? just checking the major functionality navigations, screensdisplaying or not Retesting: Is a type of testing that is performed to check for the functionality of an application by using different inputs after the fix is done for the bugs that wererecorded during the earlier testing. Fuzz testing or fuzzing: It is asoftware testingtechnique that provides randomdata ("fuzz") to the inputs of aprogram. If the program fails (for example, bycrashing, or by failing built-in code assertions), the defects can be noted. The great advantage of fuzz testing is that the test design is extremely simple,and free of preconceptions about system behavior. Fuzz testing was developed attheUniversity of WisconsinMadisonin 1989 by ProfessorBarton Millerand thestudents in his graduate Advanced Operating Systems class. Bug Life Cycle & Guidelines In this tutorial you will learn about Bug Life Cycle & Guidelines, Introduction, BugLife Cycle, The different states of a bug, Description of Various Stages, Guidelineson deciding the Severity of Bug, A sample guideline for assignment of PriorityLevels during the product test phase and Guidelines on writing Bug Description. Introduction: Bug can be defined as the abnormal behavior of the software. No software existswithout a bug. The elimination of bugs from the software depends upon theefficiency of testing done on the software. A bug is a specific concern about thequality of the Application under Test (AUT).

Bug Life Cycle: In software development process, the bug has a life cycle. The bug should gothrough the life cycle to be closed. A specific life cycle ensures that the process isstandardized. The bug attains different states in the life cycle. The life cycle of the

bug can be shown diagrammatically as follows: The different states of a bug can be summarized as follows:1. New2. Open3. Assign4. Test5. Verified6. Deferred7. Reopened8. Duplicate9. Rejected and10. Closed Description of Various Stages:1. New: When the bug is posted for the first time, its state will be NEW. Thismeans that the bug is not yet approved. 2. Open: After a tester has posted a bug, the lead of the tester approves that thebug is genuine and he changes the state as OPEN. 3. Assign: Once the lead changes the state as OPEN, he assigns the bug tocorresponding developer or developer team. The state of the bug now is changedto ASSIGN. 4. Test: Once the developer fixes the bug, he has to assign the bug to the testingteam for next round of testing. Before he releases the software with bug fixed, hechanges the state of bug to TEST. It specifies that the bug has been fixed and isreleased to testing team. 5. Deferred: The bug, changed to deferred state means the bug is expected tobe fixed in next releases. The reasons for changing the bug to this state havemany factors. Some of them are priority of the bug may be low, lack of time forthe release or the bug may not have major effect on the software. 6. Rejected: If the developer feels that the bug is not genuine, he rejects thebug. Then the state of the bug is changed to REJECTED. 7. Duplicate: If the bug is repeated twice or the two bugs mention the sameconcept of the bug, then one bug status is changed to DUPLICATE. 8. Verified:

Once the bug is fixed and the status is changed to TEST, the testertests the bug. If the bug is not present in the software, he approves that the bug isfixed and changes the status to VERIFIED. 9. Reopened: If the bug still exists even after the bug is fixed by the developer,the tester changes the status to REOPENED. The bug traverses the life cycleonce again. 10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels thatthe bug no longer exists in the software, he changes the status of the bug to

CLOSED. This state means that the bug is fixed, tested and approved.While defect prevention is much more effective and efficient in reducing thenumber of defects, most organization conducts defect discovery and removal.Discovering and removing defects is an expensive and inefficient process. It ismuch more efficient for an organization to conduct activities that prevent defects. Guidelines on deciding the Severity of Bug: Indicate the impact each defect has on testing efforts or users andadministrators of the application under test. This information is used bydevelopers and management as the basis for assigning priority of work ondefects.A sample guideline for assignment of Priority Levels during the product test phaseincludes:1. Critical / Show Stopper An item that prevents further testing of theproduct or function under test can be classified as Critical Bug. Noworkaround is possible for such bugs. Examples of this include a missingmenu option or security permission required to access a function under test.. 2. Major / High

 A defect that does not function as expected/designed orcause other functionality to fail to meet requirements can be classified asMajor Bug. The workaround can be provided for such bugs. Examples of thisinclude inaccurate calculations; the wrong field being updated, etc.. 3. Average / Medium The defects which do not conform to standards andconventions can be classified as Medium Bugs. Easy workarounds exists toachieve functionality objectives. Examples include matching visual and textlinks which lead to different end points.. 4. Minor / Low Cosmetic defects which does not affect the functionality of the system can be classified as Minor Bugs