UNIT 2TESTING 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

Debugging TestingCode checking to locate the cause of defect

Checks the defect

Code may be updated Corrections are not involved

Test cases are not defined Test cases are definedCover only positive cases Positive 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 TestingBegins construction and testing with atomic modules (lowest level in hierarchy)

drivers are replaced one at a drivers are replaced one at a time, "depth first"time, "depth first"

worker modules are grouped into worker modules are grouped into builds and integratedbuilds and integrated

AA

BB

CC

DD EE

FF GG

clustercluster

• Bottom up approach is Suitable for• Object Oriented design.• Low level ComponentsStubs/Drivers:These are Special Purpose arrangements to test

the units individuallyStub: A Piece of Code emulating a called functionDriver: 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