Quality Assurance

Where are we? Specification Design Testing Code & Test Quality Assurance

Is SWTesting important?

Why SW errors are inevitable?

Is it sufficient to test the code alone?

What is Quality Assurance?

Why SWT need planning?

Who test well? Independent Tester?

What are the good qualities of a test case?

What are the attributes of testable software?

What are we going to discuss today?

To show a system works correctly

OR

To identify errors and deficiencies

Which SW company gives Money Back Guarantee?

Which is the aim of SW Testing ?

What Testing Shows? errors requirements conformance performance an indication of quality © SEPA

SW Testing starts with coding But, Quality Assurance is a continuous process Testing is an incremental process. Starts from small modules and integrated to higher level modules. But, planning the testing process should be started early in system engineering state. When Testing Starts?

When Testing Starts? SystemEngineering Requirement Analysis Design Coding Test Plan Unit Test Integration Test ValidationTest SystemTest plans plans System test plan. SW+HW Function performance etc. BB some GB BB GB Acceptance Test Developer Tester Developer Tester Tester User

Quality Assurance: monitoring and improving the whole SW development process. Includes, Verification : Are we building right SW? and Validation : Did we build the SW right? Requirement Specification SW Verify Validate walkthrough, inspection static, dynamic Testing is part of SW Quality Assurance essential

Testing is the process of exercising a program with the intent of finding errors within set time and effort prior to delivery to the end user. Not to show that a SW is working correctly! OK! Why Testing such Essential? Testing not only executing

1999 Oct - Missing in Action (125 Million US$)

NASA Spacecraft

Cause- missing initialization

1996 July- Lost in Action (500 Million US$)

Ariane 5 Spacecraft

Cause - 64 bit real to 16 bit integer

1992 Oct- Ambulance Crash (20 people’s live)

London Ambulance Service

Cause- not fully tested under full load

Simple Errors may Cause Terrible Disasters

NO ! To err is human.

Errors not only occur in code- it may originate from specification

Why errors introduced in SW?

Communication errors (different situation)

may be due to problem complexity

Programmer’s errors ( normal- 1 per 10 lines)

ego may play a role

Can’t we avoid errors if we program carefully?

Testing should be planned well

For safety-critical SW testing costs 80%

For commercial application about 40%

Pareto Principle: 80% of errors are likely to be found in 20% of code- How to isolate?

Exhaustive testing is not possible (e.p.?)

Need to find suitable representatives ( test cases ] for the whole input domain

Exhaustive Testing There are 10 14 possible paths! If we execute one test per millisecond, it would take 3,170 years to test this program!! © SEPA loop < 20 X

Test Cases

Quality, not quantity, matters (example?)

What are good qualities of test cases?

- has a high probability of finding a new bug

- not redundant

- covers variety of error types

- not complex and not simple

Test Cases (Example)

Module: doubleDigit

Purpose: To print all integers between 0-99 in double digits

Input : integer X

Precondition: 0 <= X <= 99

Output: X printed on screen

Post condition: If 0<=X<=9, ‘0X’ printed o/w ‘X’ printed

Implementation ( wrong! )

if x < 9 Exhaustive Testing : try all 0-99 numbers , or all numbers

print ‘0’; Or use random number generator, Test case quality?

else But, what are the best test cases?

print x; -1,0,1,5,8,9,10,50,98,99,100 why?

Testing is a ‘destructive’ process?

A test is successful if it reveals a new error

Testing is best done by independent testers

Developers, if you test your own code, change to ‘destructive’ mood!

Developers should help testers.

Pay now or pay much later!

Why need independent tester? Developer Independent tester Advantage : Already knew the system. but, will test "gently" and, is driven by "delivery" Disadvantage : Must learn the system but, will attempt to break it and, is driven by quality © SEPA

Testability

Operability —it operates cleanly

Visibility / Observability —the results of each test case are readily observed

Controllability —the degree to which testing can be automated and optimized

Decomposability —testing can be targeted

Simplicity —reduce complex architecture and logic to simplify tests

Stability —few changes are requested during testing

Understandability —of the design

A set of good characteristics of a SW that has a high degree of testability

What we learned ?

Can’t avoid bugs- testing is essential

Testing is a part of whole QA process

Independent Testers test better

Testing should be planned well

Planning starts from beginning

Testing is incremental

Test case Qualities (?) matter

Testability - easy to test - A SW quality (?)

A set of good characteristics of a SW that has a high degree of testability

What are we going to discuss now?

A SW may be tested for different purposes

Black box and White box are two important techniques used to identify suitable test cases

WB and BB are complementary, not alternate

WB is a sort of ‘coverage’ test - e.g. path coverage

Basis-path test : representing a module’s logic in flow-graph and identifying linearly independent path and determining test cases

Other WB tests - Loop, Conditional, Dataflow

SW Testing and Purposes

A module may be tested for different purposes

To check functionality against requirements

To ensure efficiency / performance

To evaluate userfriendliness

To ensure security

To check compatibility

To compare it with its rival algo or SW

etc.

Two Important Testing Techniques Black-Box : To test the functionality, behavior and performance against its specification. Implementation logic is not necessary White-Box : To test the correctness of the internal logic of a module. Therefore, Implementation detail is necessary © SEPA boundary-value equivalent Partition white-box methods black-box methods basis-path control structure

Black-Box Testing Functional, Behavior, Performance, requirements (expected output) events input output Internal logic not required © SEPA

White-Box Testing Based on “coverage” : goal is to ensure that all the statements and conditions have been executed at least once … statement edge path To test the internal logic © SEPA

Why Cover? logic errors and incorrect assumptions are inversely proportional to a path's execution probability we often believe that a path is not likely to be executed; in fact, reality is often counter intuitive typographical errors are random; it's likely that untested paths will contain some © SEPA

PATH coverage not feasible There are 10 14 possible paths! If we execute one test per millisecond, it would take 3,170 years to test this program!! © SEPA loop < 20 X

Select Most Suitable Paths - but how? Linearly Independent Paths : each new path introduces at least one different executable or simple conditional statement OR a new edge © SEPA This also ensures statement and edge coverage : every statement (and edge) is executed at least once loop < 20 X

Basis-Path Testing - A White-Box test

STEPS

Start with the internal logic of the module

Draw flow-graph for the program logic

Identify a set of linearly independent paths

Prepare test cases that will force execution

of each path- check for redundancy

Flow Graph  Basic Structures

SEQUENCE

IF-ELSE

CASE

A; B; if ( C ) D; else E; F; case G { g1 : H; g2 : I; else : J; } K; A B C E F D G J K I H

WHILE

REPEAT

while (L) M; N; do { O; } while (P); Q; NODE REGION EDGE L M N O P Q

AND

OR

if R AND S T; else U; V; if R OR S T; else U; V; R S T U V R S U T V

AND

OR

While R AND S T; V; While R OR S T; V; S T V R S T V R

BASIS-PATH example Module : search

Description : To search a ‘target’ value in an array of integers (which is in ascending order) and, if the ‘target’ is found returns 'TRUE' otherwise returns 'FALSE'.

input : array of integers A, integer maxInA

integer N (stands for the number of records in A),

integer target

Pre-condition : maxInA > N >= 0,

A[j] <= A[j+1] for all integer j, 0 < j < N.

Output : boolean found

Post-condition :

((  j, 0 < j < N+1. A[j] = target ) AND (found = TRUE) )

OR

(( V j, 0 < j < N+1. A[j] < > target ) AND (found = FALSE) )

BASIS-PATH example Module : search ( An Implementation)

Processing

j  1;

A[N+1]  target;

while ( A[j] < target )

j  j + 1;

if (j <= N) AND (A[j] == target)

found = TRUE;

else

found = FALSE;

return ( found );

6 1 2 3 4 5 7 8 5 2 1 3 4 8 6 7

Coverage

Statement coverage:

1 2 3 2 4 5 6 8 1 2 4 7 8

Edge Coverage:

1 2 3 2 4 5 6 8 1 2 4 7 8 1 2 4 5 7 8

Path Coverage:

1 2 3 2 4 5 6 8 1 2 4 7 8 1 2 4 5 7 8

1 2 3 2 4 5 7 8 1 2 4 5 6 8 1 2 3 2 4 7 8

But, not possible for complex programs ==> Basis-PATH

5 2 1 3 4 8 6 7

Cyclomatic Complexity ( V(G) ) Number of simple conditions + 1 OR Number of enclosed areas + 1 OR Edges - Nodes + 2 In this case, V(G) = 4

Gives the number of paths in the flow-graph or BASIS-PATH

This is a metric of logic complexity of a program

5 2 1 3 4 8 6 7

Cyclomatic Complexity A number of industry studies have indicated that the higher V(G), the higher the probability or errors. V(G) modules modules in this range are more error prone © SEPA

Basis Path Testing- Independent Paths Next, we derive the independent paths: Since V(G) = 4, there are four paths Path 1: 1,2,4,7,8 Path 2: 1,2,4,5,7,8 Path 3: 1,2,4,5,6,8 Path 4: 1,2,3,2,4,.….,8 Finally, we derive test cases to exercise these paths. 5 2 1 3 4 8 6 7

Basis Path Testing- TEST CASES Path 1: 1,2,4,7,8 N=0 , target=2 ,( A is empty ) Path 2: 1,2,4,5,7,8 N=1, target =2, A[1]= 4( any number > 2) Path 3: 1,2,4,5,6,8 N=1, target =2, A[1]= 2 Path 4: 1,2,3, 2, 4,.….,8 N=1, target =2, A[1]= 1 ( any number <2) But, more general cases are better; FALSE FALSE TRUE FALSE 5 2 1 3 4 8 6 7

BASIS-PATH another example ( Module: GCD )

Purpose: To get GCD of two non-zero positive integers

Input : integer X, Y

Precondition: 0 < X , 0 < Y

Output: gcd

Post condition: gcd = GCD ( X, Y]

Implementation (wrong)

do {

if X > Y

X = X - Y;

else

Y = Y - X;

} while ( X ! = Y]

Statement coverage : (X=4, Y=3) (X=3, Y=4) Edge coverage : same BASIS-PATH DRAW Flow-Graph!! FIND independent paths CHOOSE test cases

Graph Matrices - a SW tool

Is a graphical version of flow-graph

May also be used for automating SW testing and code optimization.

Weight - shows just a link available or some other measures like execution probability 2 1 3 4 1 2 3 4 1 2 3 4 from to 1 1 1 1

Some Other White-Box Testing Methods

Loop Testing

Condition Testing

Data Flow Testing

Loop Testing Nested Loops Concatenated Loops Unstructured Loops Simple loop © SEPA

Loop Testing: Simple Loops © SEPA Minimum conditions—Simple Loops 1. skip the loop entirely 2. only one pass through the loop 3. two passes through the loop 4. m passes through the loop m < n 5. (n-1), n, and (n+1) passes through the loop where n is the maximum number of allowable passes

Loop Testing- for module Search

Skip the loop

One pass

Two passes

m passes, m<N

N-1 passes

N passes

N+1 passes

N=2, target =2 A[1]=1, A[2]=3 N=1, target =2 A[1]=4  ? Check for redundancy with already selected test cases

Loop Testing: Nested Loops © SEPA Start at the innermost loop. Set all outer loops to their minimum iteration parameter values. Test the min+1, typical, max-1 and max for the innermost loop, while holding the outer loops at their minimum values. Move out one loop and set it up as in step 2, holding all other loops at typical values. Continue this step until the outermost loop has been tested. If the loops are independent of one another then treat each as a simple loop else* treat as nested loops for example, the final loop counter value of loop 1 is used to initialize loop 2. Nested Loops Concatenated Loops

Conditional Testing

Focus on each logical condition

Conditions are usually complex

e.g. If ( (month==12] && (day + d > daysInMonth] ]

Error may be in, arithmetic expression, relational operator, boolean operator, parenthesis etc.

Branch testing : To test both side of a complex condition and both side of its constitutes

Domain testing- not feasible for complex cases

BRO - Branch and Relational Operator testing

Data-Flow Tesing

Track the usage of a variable from its definition

For each variable, determine test cases to execute along with these links

Coverage is not possible

What are we going to discuss now?

What is tested in Black-box testing?

Two important techniques used to identify suitable test cases : Equivalence Partitioning, and Boundary Value Analysis

In EP, input domain is divided into groups depending on pre and post conditions

It is found that the SW fails usually at boundary values- so test at boundary values

Other BB tests - Graph-based, Orthogonal, Comparison, Special cases

Black-Box Testing

To test functionality, performance and behavior of a module against its specification

Test cases may be developed in early stages based on specification document - logic is not necessary

Only indicates presence or absence of errors- needs logic for debugging

Black-Box Testing

Incorrect or missing functions are identified

Efficiency is measured

Usability is tested

Initialization/Termination is monitored

Interfacing requirements are tested

Data structure links are tested

External database access are monitored

Black-Box Testing Methods

TWO MAIN B-B METHODS

Equivalence Partitioning – input domain is partitioned into several classes

Boundary Value Analysis - Boundary values are assigned to the data elements

OTHER B-B METHODS

Orthogonal Array Testing - for small input domain

Graph based testing - for integrated portions

Comparison tests (back-to-back)- for critical systems

Special tests - for Real time, GUI, Client/Server, User- Guide , Help etc.

Equivalence Partitioning user queries mouse picks output formats prompts FK input data © SEPA

Sample Equivalence Classes user supplied commands responses to system prompts file names computational data physical parameters bounding values initiation values output data formatting responses to error messages graphical data (e.g., mouse picks) data outside bounds of the program physically impossible data proper value supplied in wrong place Valid data Invalid data © SEPA

Equivalence Partitioning { doubleDigit}

Partition Input domain into classes of data such that ideal test case could detect a class of errors

Purpose: To print all integers between 0-99 in

double digits

(example: ‘9’ printed as ‘09’ and ‘99’ printed as ‘99’ )

Input : integer X

Post condition: If 0<=X<=9, ‘0X’ printed o/w ‘X’

Equivalence Partitioning (e.g doubleDigit )

0 99

VALID INVALID INVALID d < 10 105 - 5 7 22 d > 10 leap leap

Equivalence Partitioning for Typical input

A specific value , one VALID and two INVALID

eg. password- 4 character string

VALID = all four character strings

INVALID1 = all three or less character strings

INVALID2 = all five or greater character strings

A specific member of a set , one VALID and one INVALID

eg. digit - any digit between 0 and 9

VALID = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}

INVALID = set of all the other characters

Equivalence Partitioning for Typical input

A specific range , one VALID and two INVALID sets

eg. month - any number between 1 and 12

VALID = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12}

INVALID1 = set of all numbers less than 1

INVALID2 = set of all numbers greater than 12

A specific boolean value, one VALID and one INVALID set

eg. username: any valid string

VALID = something entered

INVALID = nothing given

Equivalence Partitioning (e.g leap )

module: leap

description: to determine whether a given year is leap

input : integer year

precondition: 1800<=year<=2200

output: boolean leap

post condition:

leap = ((400/year) or ( (4/year) and (100 / year))

Equivalence Partitioning (e.g leap )

1800 2200

VALID INVALID INVALID 400/year 2205 1750 1903 1904 1900 2000 leap leap 4 / year 4 / year but 100 / year 100/year but 400 / year

Equivalence Partitioning (e.g SEARCH )

integer target

Pre-condition : maxInA > N >=0,

Post-condition :

OR

Equivalence Partitioning (e.g SEARCH )

Three Input values

For N : N is an integer, N is a value but it is restricted by precondition. However it can be tested. ( N < 0 , maxInA > N >= 0 , N >= maxInA )

For A : A is also restricted by precondition(values of A are valid integers in ascending order)- and also it is not independent- depends on N (number of elements in the Array A)- but testing this precondition is not feasible

For target : It is an integer (member of a set) from post condition we may derive two cases, target in A and target not in A

We may get two BB test class here

A valid array A with the corresponding integer N with some integer value as target, where target in A and target not in A.

(eg. A= 4,6,8,10 N=4 and target= 7 and 8).

White Box test cases should be checked with BB test cases for redundancy

Boundary Value Analysis "Bugs lurk in corners and congregate at boundaries ..." Boris Beizer WHY ? - unknown Select test cases to cover all the boundary values of input and output data elements and data structures © SEPA

Boundary Value Analysis user queries mouse picks output formats prompts FK input data output domain input domain © SEPA

Boundary Value Analysis { doubleDigit }

Module: doubleDigit

Purpose: To print all integers between 0-99 in

double digits

(example: ‘9’ printed as ‘09’ and ‘99’ printed as ‘99’ )

Input : integer X

Post condition: If 0<=X<=9, ‘0X’ printed o/w ‘X’

-5 0 6 9 30 99 105 -1 0 1 8 9 10 98 99 100

Boundary Value Analysis e.g [ SEARCH )

integer target

Pre-condition : maxInA > N >=0,

Post-condition :

OR

Boundary Value Analysis { SEARCH }

Input Domain

For N: N= 0, 1, maxInA -1, maxInA, maxInA+1

For target : target < A[1], = A[1], A[2], A[N-1], A[N], >A[N]

Data Structure:

For A: No elt, 1 elt, maxInA-1 elts and MaxInA elts

(already covered through N’s boundary values )

Output Domain

For found: found= TRUE/FALSE (target in A and not in A)

Ex: If the SEARCH module also need to return a suitable location (say ‘pos’) for a non existing target in A, modify the specification and find suitable WB and BB test cases

Other Black Box Techniques

Orthogonal Array Testing - for small input domain

Graph based testing - for integrated portions

Comparison tests (back-to-back)- for critical systems

Special type of tests necessary for - for Real time, GUI, Client/Server, User- Guide , Help etc.

Testing is an incremental process SystemEngineering Requirement Analysis Design Coding Test Plan Unit Test Integration Test ValidationTest SystemTest plans plans System test plan. SW+HW Function performance etc. BB some GB BB GB Acceptance Test Developer Tester Developer Tester Tester User

Unit Testing module to be tested test cases results software engineer interface local data structures boundary conditions error handling paths global data effects independent paths loops, conditions ©SEPA

Unit Test Environment Module stub stub driver RESULTS test cases not stand-alone Stubs and drivers are overheads and should be small enough to throw away after their use ©SEPA

DRIVER- example from case-study

A lower level module is ready for testing!

A stub to test the module ‘leap’

void leapDriver ( ){

int year; cout>> ‘give year 1800 -2200’;

cin<< year;

if leap(year)

cout << ‘LEAP’

else

cout << ‘NOT A LEAP’;

}

STUB- example from case-study

A higher level module is ready for testing!

void processReporter( ) {

struct date {

Int day,month,year; }

struct time {

Int hour,min,sec;]

struct instance {

d : date; t : time; }

GetProcessDetail(instance startInst, int duration);

ProcessEndDetail(instance startInst, &instance endInst, int duration);

displayProcessReport(instance startInst, instance , endInst);

}

void getProcessDetail (instance SI, int duration ) { cout >> “in the getProcessDetail”; }

SW Integration Strategies

Options:

• the “big bang” approach

• an incremental construction strategy

“ big bang” approach- disadvantages

• cannot isolate cause of an error

correcting an error may trigger further errors

©SEPA

Top Down Integration top module is tested with stubs stubs are replaced one at a time, "depth first" as new modules are integrated, some subset of tests is re-run A B C D E F G Regression test ©SEPA

Bottom-Up Integration drivers are replaced one at a time, "depth first" A B C D E F G as new modules are integrated, Regression test some subset of tests is re-run. May be automated ©SEPA

Integration Example- Case study processDetail ProcessReporter getProcessDetail determineEndDetail displayProcessRepor t getStartDetail getDuration addTime addDate getStartTime leap getStartDate daysInMonth processReport A cluster for validation

Integration Strategies- A comparison

In Top down integration, program may be felt as an entity at the very early stages, but In Bottom up integration, the whole program is available in the final stage

In Top down integration, major control structures may be tested effectively

In Bottom up integration, the critical lower modules may be tested effectively

In Cluster-based integration, if important functional modules are selected as clusters, it gives advantages of both approaches

Validation Testing

Done on fully assembled SW, but yet to integrate with other elements such as HW, DB etc.

already tested and corrected for logic, interface and functionality

Test SW based on Requirement Specification

- Overall functionality

Performance and Behavioral aspects

On-line help and other help facilities

Documentation, User-Guide sufficiency ,consistency etc.

Error recovery and maintainability

System Testing

Now SW is incorporated with other system elements such as HW, DB, people etc.

Further level of integration and validation test are to be conducted

Some system tests

Recovery Testing – fail it and recover

Security Testing – penetrate and attack

Stress Testing - demand abnormal resources

Performance Testing – reasonable time?

Acceptance Tests Developer’s site customer Alpha Test Beta Test Customer’s site ©SEPA By customers in their normal environment developer customer

The Debugging Process test cases results Debugging suspected causes identified causes corrections regression tests new test cases ©SEPA

Debugging Effort time required to diagnose the symptom and determine the cause time required to correct the error and conduct regression tests ©SEPA

Symptoms & Causes symptom cause symptom and cause may be geographically separated symptom may disappear when another problem is fixed cause may be due to a combination of non-errors cause may be due to a system or compiler error cause may be due to assumptions that everyone believes symptom may be intermittent/irregular ©SEPA

Consequences of Bugs damage mild annoying disturbing serious extreme catastrophic infectious Bug Type Bug Categories: function-related bugs, system-related bugs, data bugs, coding bugs, design bugs, documentation bugs, standards violations, etc. ©SEPA

Debugging Techniques brute force / testing Backtracking Cause elimination by Binary partition induction deduction deduction deduction ©SEPA

Debugging: Final Thoughts Don't run off half-cocked, think about the symptom you're seeing. Use tools (e.g., dynamic debugger) to gain more insight. If at an impasse, get help from someone else. Be absolutely sure to conduct regression tests when you do "fix" the bug. 1. 2. 3. 4. ©SEPA

Object Oriented Testing

OOTesting begins at OOAnalysis stage

Minimum Testable Component is a CLASS, not modules. Unit Testing is a Class Testing

Integrating CLASSES- use based, cluster based (why not Top and Bottom integration?]

Validity Testing- based on use cases

Class level testing - Partition, Random

Inter-Class testing - Random, Scenario

Why wait until classes are coded?

When can OOTesting begin?

OOTesting begins by Evaluating OOAnalysis and OODesign models Seamless transition- everything is class and requests Analysis level model ==> Design level model ==> code Class1 Class2 request1 Class1 Class2 request1 Class1 Class2 request1

public class Date { private int day, month, year; public Date( ) { day=0; month=0;year=0; } public Date(int day, int month, int year) { this.day = day; this.month = month; this.year = year; } public boolean leap( ) { // should change to private return ((year % 400 == 0)|| ((year % 100 > 0) && (year % 4 ==0))); } } public class Instance { private Date date; private Time time; public Instance(Date date, Time time){ this.date = date; this.time = time; } public void getInstance() { date.getDate(); time.getTime(); } } getDate( ) Date day month year getDate( ) displDate( ) addDate( ) dInMonth( ) leap( ) Instance date time getInstance( ) displInstance( ) addInstance( ) Date Day : integer month : integer year : integer getDate( ) displDate( ) addDate(d: integer, nD:Date) -dInMonth( ) -leap( ) Instance date:Date time:Time getInstance( ) displInstance( ) addInstance( )

Minimum testable component is a class

A module alone of a class is meaningless. It has meaning only as an operation of an encapsulated object.

If leap(year) -->

The function call leap(year] is meaningless in OO.

Date StartDate(10,12,2000];

if StartDate.leap( ) // not possible, if ‘leap’ is private

System.out.println (“‘Leap”];

Encapsulation may give trouble while testing

Unit Testing is Class Testing in OO

public class Date {

private int day, month, year;

public Date( ) {

day=0; month=0;year=0;

}

public Date(int day, int month, int year) {

this.day = day; this.month = month; this.year = year;

}

public boolean leap( ) { // should change it to private

return ((year % 400 == 0)||

((year % 100 > 0) && (year % 4 ==0)));

}

BlueJ - Java implementation Minimum testable component is a class

Integrating Classes

Classes are connected like a network, not hierarchical as in a structure chart

Top / Bottom classes are meaningless, so does the Top down/Bottom up integration

Classes are integrated according to

the usage scenario - use based OR

collaboration - cluster based

Structure Chart: hierarchical Class Collaborations: network ProcessReporter getProcessDetail getStartDetail getDuration getStartTime getStartDate Process: Instance:Start Date:Start Time:Start 1.disInst( ) 2. disDate( ) 6. addDate( ) 3.disTime( ) 4. addTime( ) Instance:End 8.Instance( ) Date:End Time:End 9. disDate( ) 10. disTime( ) 5. Time( )

Use Based Integration

Inspect sequence diagrams- independent classes are coded and tested first.

Then the classes that send requests only to those independent classes are integrated

Continue until you get the final integration

In Case Study

start with, Time and Date

then Instance and Process etc.

CASE STUDY - SEQUENCE DIAGRAM

Cluster Based Integration

Start with an important collaboration diagram- classes necessary for the collaboration are coded and tested first.

Then another collaboration is automated

Continue until you get the final integration

In Case-Study

Major collaboration is ‘addInst’ ,

again start with Date and Time then

complete Instance

Cluster : A group of classes that collaborate to perform a particular request Start with receiver classes Instance:Start Date:Start Time:Start 1. addInst( ) 4. addDate( ) 2. addTime( ) Instance:End 8.Instance( ) Date:End Time:End 10. disDate( ) 9. disTime( ) 7. Date( ) 3. Time( ) 5. dInMon( ) 6. leap( )

Unit Testing - Class Level Testing