UNIT 2 TESTING TECHNIQUES Testing begins with a proposal for software/system application development/maintenance and end with the system is formally accepted by the user/customer

Proposal Testing A Proposal is made to the customer on the basis of Request for Proposal(RFP) or Request for Quotation(RFQ) Any proposal prepared in response to such request is reviewed by organisation before sending it to the customer. Technical review –Technical feasibility, Overall approach Commercial Review- financial feasibility Validation of Proposal – development of prototype or proof of concept

Requirements Testing Requirements creation involves gathering of requirements and arranging them in a form to verify and validate them. Clarity Complete Measurable Testable Not Conflicting Identifiable Validation of Requirements – writing use cases

Design Testing The System Architect starts with system high level architectural designing Clarity Complete Traceable Implementable Testable Validation of design – creation DFD, activity diagrams, information flow diagram and state transition. Flow interrupted – design is not complete

Code Review Reviewing code files, databases, classes and methods. Clarity Complete Traceable Maintainable

Unit Testing Smallest part of a software system which is testable Individual units and components Throwaway drivers and stubs Debugger mode to find how variables are changed during execution- not termed as Black box testing Gray Box testing – code details with its functioning Derived from use cases

Difference between Debugging and Testing DebuggingTesting Code checking to locate the cause of defect Checks the defect Code may be updatedCorrections are not involved Test cases are not definedTest cases are defined Cover only positive casesPositive as well as negative cases

Module Testing Many units come together and form a module Stub/driver This testing is done on related unit tested components to find whether individually tested units can work together as a module or not. Test cases must be traceable

Integration Testing Integration testing involves integration of units to make a module of modules to make a system. The objective is to take unit tested components and build a program structure that has been dictated by design.

10 Bottom-Up Testing Begins construction and testing with atomic modules (lowest level in hierarchy) drivers are replaced one at a time, "depth first" worker modules are grouped into builds and integrated A B C DE FG cluster

Bottom up approach is Suitable for Object Oriented design. Low level Components Stubs/Drivers: These are Special Purpose arrangements to test the units individually Stub: A Piece of Code emulating a called function Driver: A piece of code emulating a calling function

Advantages Tested first for its correctness and if is working correctly, then only it goes for further integration Robust Incremental Integration testing- Individual components are tested Disadvantages Top level components are more important which is tested at the last