SOFTWARE VERIFICATION AND VALIDATION

To err is human, to find a bug, divine.

(obert !unn

Death, taxes, and bugs are the only certainties in the life of a programmer. Kernighan To understand the concept of software testing correctly, we need to understand a few related concepts.
1.1 Verification and Validation

Verification and validation are the processes in which we check a product against its specifications and the expectations of the users who will be using it. Barry Boehm According to a known software engineering expert Berry Boehm, verification and validation are distinguished as follows
Verification

!oes the product meet system specifications" #ave you built the product right"

Validation

!oes the product meet user expectations" #ave you built the right product"

$t is possible that a software application may fulfill its specifications but it may deviate from users% expectations or their desired behavior. That means software is verified but not validated. #ow is it possible" $t is possible because during the re&uirements engineering phase, user needs might not have been captured precisely or the analyst might have missed a ma'or stakeholder in the analysis. Therefore, it is important to verify as well as validate the software product.

A defect is a varian ce from a desire d produ ct attrib ute.

1.2

Defect

The second ma'or and a very important concept is !efect. A defect is a variance from a desired product attribute. These attributes may involve system specifications well as user expectations. Anything that may cause customer dissatisfaction is a defect. )hether these defects are in system specifications or in the software products, it is essential to point them out and fix. Therefore software defect is that phenomenon in which software deviates from its expected behavior. This is non*compliance from the expected behavior with respect to written specifications or the stakeholder needs. +oftware and defects go side by side in the software development life cycle. According to famous sayings Death and taxes are inevitable. ** #aliburton +oftware and defects cannot be separated, however, it is important to learn how discovering the defects at an appropriate stage improves the software &uality. Therefore, software application needs to be verified as well as validated for a successful deployment.

2 Software Testing
)ith these concepts, we are in a position to define software testing. +oftware testing is the process of examining the software product against its re&uirements. Thus it is a process that involves verification of product with respect to its written re&uirements and conformance of re&uirements with user needs. ,rom another perspective, software testing is the process of executing software product on test data and examining its output vis*-*vis the documented behavior.
2.1 Software Testing Objective

The correct approach to testing a scientific theory is not to try to verify it, but to seek to refute the theory. That is to prove that it has errors. ./opper 01234 The goal of testing is to expose latent defects in a software system before it is put to use.

2.2

A software tester tries to break the system. The ob'ective is to show the presence of a defect not the absence of it. Testing cannot show the absence of a defect. $t only increases your confidence in the software. This is because exhaustive testing of software is not possible 5 it is simply too expansive and needs virtually infinite resources.
Successful Test

,rom the following sayings, a successful test can be defined If you think your task is to find problems then you will look harder for them than if you think your task is to verify that the program has none 5 6yers 0171. test is said to be successful if it discovers an error. 5 !octor%s analogy. The success of a test depends upon the ability to discover a bug not in the ability to prove that the software does not have a defect. As, it is impossible to check all the different scenarios of a software application, however, we can apply techni&ues that can discover potential bugs in the application. Thus a test that helps in discovering a bug is a successful test. $n software testing phase, our emphasis is on discovering all the ma'or bugs that can be identified by running certain test scenarios. #owever it is important to keep in mind that testing activity has certain limitations.
2.3 imitations of Testing

)ith the help of the following example, we shall see how difficult it may become to discover a defect from a software application. $n order to prove that a formula or hypothesis is incorrect all you have to do to show only one example in which you prove that the formula or theorem is not working. 8n the other hand, million of examples can be developed to support the hypothesis but this will not prove that it is correct. These examples only help you in coming up with a hypothesis but they are not proofs by themselves and they only enhance your comfort level in that particular hypothesis or in this particular case, in your piece of software. 9ou cannot test a program completely because o The domain of the possible inputs is too large to test. o There are too many possible paths through the program to test. According to !iscrete 6athematics o To prove that a formula or hypothesis is incorrect you have to show only one example. o To prove that it is correct any numbers of examples are insufficient. 9ou have to give a formal proof of its correctness.

2.!

"#ample $adapted from %ac&'ouse(

This is a function that compares two strings of characters stored in an array for e&uality. The tester who has to test this function has devised the following test cases in which different combinations of inputs are tried and their expected behavior is documented. ,rom the look of this table, it seems that almost all ma'or combinations of inputs have been documented.
2.!.1 )nputs and "#pected Outputs

A :cat; :; :hen; :hen; :; :cat; :#=<; :rat; : ;

2.!.2 *esults of Testing

B :dog; :; :hen; :he<; :ball; :; :hen; :door; : ;

Expected result ,alse True True ,alse ,alse ,alse ,alse ,alse True
Table 0

The tester runs all the above*mentioned test cases and function returns the same results as expected. But it is still not correct. )hat can be a problem" To analy>e the problem, lets look at the code of this string e&ual routine
2.!.3 +ode of ,unction

bool isStringsEqual(char a[], char b[]) { bool result; if (strlen(a) != strlen(b)) result = false; else { for (int i =0; i < strlen(a); i++) if (a[i] == b[i]) result = true; else result = false; return result;
2.!.! Anal-sis of +ode

$t passes all the designated tests but fails for two different strings of same length ending with the same character. ,or example, :cut; and :rat; would results in true that is not correct.

Testin g 'as a life c-cle parall el to softw are devel opme nt.

The above*mentioned defect signifies a clear limitation of the testing process in discovering a defect that is not very fre&uent. #owever, it should be noted from this example that a tester cannot generate all possible combinations of test cases to test an application as the number of scenarios may become exhaustive.
2.. Test +ases and Test Data

$n order to test a software application, it is necessary to generate test cases and test data that is used in the application. Test cases correspond to application functionality such that the tester writes down steps that should be followed to achieve certain functionality. Thus a test case involves $nput and output specification plus a statement of the function under test. +teps to perform the function =xpected results that the software application produces

#owever, test data includes inputs that have been devised to test the system.
2./ Testing vs. Development

Testing is an intellectually demanding activity and has a lifecycle parallel to software development. A common misperception about testing is that it is not a challenging activity. $t should be noted here that the testing demands grip over the domain and application functionality as is re&uired from an analyst or a designer who has to develop the application from re&uirements. As without having an in*depth knowledge about the system and the re&uirements from users, a tester cannot write test cases that can verify and validate software application with respect to documented specifications and user needs. )riting test cases and generating test data are processes that demand scenario*building capabilities. These activities essentially re&uire destructive instincts in a tester for the purpose of breaking system to discover loopholes into its functionality. At the time when these two activities are being performed, merely initial design of the application is completed. Therefore, tester uses his?her imagination to come up with use patterns of the application that can help him?her in describing exact steps that should be executed in order to test a particular functionality. 6oreover, tester needs to figure out loose points in the system from where he?she can discover defects. All these

activities are highly imaginative and a tester is supposed to possess above average .if not excellent4 analytical skills. )e shall explain the testing activities parallel to development activities with the help of ,igure 0

,igure 0 Testing vs. !evelopment Activities

2.0

,unctional specification document is the starting point, base document for both testing and the development (ight side boxes describe the development, whereas, left side boxes explain the testing process !evelopment team is involved into the analysis, design and coding activities. )hereas, testing team too is busy in analysis of re&uirements, for test planning, test cases and test data generation. +ystem comes into testing after development is completed. Test cases are executed with test data and actual results .application behavior4 are compared with the expected results, @pon discovering defects, tester generates the bug report and sends it to the development team for fixing. !evelopment team runs the scenario as described in the bug report and try to reproduce the defect. $f the defect is reproduced in the development environment, the development team identifies the root cause, fixes it and sends the patch to the testing team along with a bug resolution report. Testing team incorporates the fix .checking in4, runs the same test case?scenario again and verifies the fix. $f problem does not appear again testing team closes down the defect, otherwise, it is reported again.
T'e Developer and Tester

Development

Testin

!evelopment is a creative activity 8b'ective of development is to show that the program works

Testing is a destructive activity 8b'ective of testing is to show that the program does not work
Table A

+cenarios missed or misunderstood during development analysis would never be tested correctly because the corresponding test cases would either be missing or would be incorrect. $n Table A the left side column is related to the development, and the right side describes the testing. !evelopment is a creative process, as developers have to build the system, whereas, testing is a destructive activity as the goal of a tester is to break the system to discover the defects. 8b'ective of development is to show that the program works, whereas, the ob'ective of testing is to show that program does not work. #owever, ,+ is the base document for both of these activities. Tester analy>es ,+ with respect to testing the system whereasB developer analy>es ,+ with respect to designing and coding the system. $f developer does not understand the ,+ correctly then he cannot implement and test it right. Thus if the same person who has developed a system, tests it, chances of carrying the same misunderstanding in testing will be very high. Therefore, an independent testing can only prove his understanding wrong. Therefore, it is highly recommended that developer should not try to test his?her own work.
2.1 2sefulness of Testing

8b'ective of testing is to discover and fix as many errors as possible before the software is put to use. That is before it is shipped to the client and the client runs it for acceptance. $n software development organi>ations, a rift exists between the development and the testing teams. 8ften developers are found &uestioning about the significance or even need to have the testing resources in the pro'ect teams. )hoever doubts on the usefulness of the testing team should understand what could happen if the application is delivered to client without testing" At the best, the client may ask to fix all the defects .free of cost4 he would discover during the acceptance testing. At the worst, probably he would sue the development firm for damages. #owever, in practice, clients are often seen complaining about the deliverables and a couple of defected deliverables are sufficient for breaking the relations next to the cancellation of contract. Therefore, it should be well preserved among the community of developers that testers are essential rather inevitable. A good tester has a knack of smelling errors 5 'ust like auditors and it is for the good of the organi>ation not to harm it.
2.3 Testing and Software 4'ases

)ith the help of ,igure A we shall explain different phases of testing

,igure A /hases of Testing

2.3.1

Description of Testing 4'ases 2nit Testing5

testing individual components independent of other components. 6odule Testing5 testing a collection of dependent components 5 a module encapsulates related components so it can be tested independently. Subs-stem Testing5 testing of collection of modules to discover interfacing problems among interacting modules. S-stem Testing5 $ntegrating subsystems into a system and testing this system as a whole. Acceptance Testing5 validation against user expectations. @sually it is done at the client premises. Alp'a Testing5 acceptance testing for customi>ed pro'ects, in*house testing for products. %eta Testing5 field*testing of product with potential customers who agree to use it and report problem before system is released for general use

$n the following two types of testing activities are discussed.

2.17 %lac& %o# Testing

$n this type of testing, a component or system is treated as a black box and it is tested for the re&uired behavior. This type of testing is not concerned with how the inputs are transformed into outputs. As the system%s internal implementation details are not visible to the tester. #e gives inputs using an interface that the system provides and tests the output. $f the outputs match with the expected results, system is fine otherwise a defect is found.
2.11 Structural Testing $8'ite bo#(

As opposed to black box testing, in structural or white box testing we look inside the system and evaluate what it consists of and how is it implemented. The inner of a system consists of design, structure of code and its documentation etc. Therefore, in white box testing we analy>e these internal structures of the program and devise test cases that can test these structures.

2.12 "ffective Testing

The ob'ective of testing is to discover the maximum number of defects with a minimum number of resources before the system is delivered to the next stage. <ow the &uestion arises here how to increase the probability of finding a defect" As, good testing involves much more than 'ust running the program a few times to see whether it works or not. A good tester carries out a thorough analysis of the program to devise test cases that can be used to test the system systematically and effectively. /roblem here is how to develop a representative set of test cases that could test a complete program. That is, selection of a few test cases from a huge set of possibilities. )hat should the sets of inputs be used to test the system effectively and efficiently"
2.12.1 "#ample9 String ":ual

,or how many e&ual strings do $ have to test to be in the comfortable >one" ,or how many une&ual strings do $ have to test to be in the comfortable >one" )hen should $ say that further testing is unlikely to discover another error" Testing types

To answer these &uestions, we divide a problem domain in different classes. These are called =&uivalence Classes.

3 ":uivalence +lasses or ":uivalence 4artitioning

Two tests are considered to be e&uivalent if it is believed that $f one discovers a defect, the other probably will too, and $f one does not discover a defect, the other probably won%t either.

=&uivalence classes help you in designing test cases to test the system effectively and efficiently. 8ne should have reasons to believe that the test cases are e&uivalent. As for this purpose, one would need to understand the system and see in how many partitions it can be divided. These partitions should be devised such that a clear distinction should be marked. Test cases written for one partition should not yield the same results when run for the second partition as otherwise these two partitions should become one. #owever, finding e&uivalence classes is a sub'ective process, as two people analy>ing a program will probably come up with different sets of e&uivalence classes.
3.1 ":uivalence 4artitioning ;uidelines

8rgani>e your e&uivalence classes. )rite them in some order, use some template, se&uence, or group them based on their similarities or distinctions. These partitions can be hierarchical or organi>ed in any other manner. Boundary conditions determine boundary conditions. ,or example, adding in an empty linked list, adding after the last element, adding before the first element, etc.

1 7

3.2

9ou should not forget invalid inputs that a user can give to a system. ,or example, widgets on a D@$, numeric instead of alphabets, etc.
"#ample9 String 6atc'

$n the following example, we shall see how e&uivalence partitions can be developed for a string matching function.
Organi<ation

,or e&uivalence partitions, we divide the problem in two obvious categories of e&ual strings and the other one for une&ual strings. )ithin these e&uivalent partitions, further partitioning is done. ,ollowing is the description of the e&uivalence partitions and their test cases
Test +ases for ":uivalence 4artitions ":ual

Two e&ual strings of arbitrary length o All lower case :cat; :cat; o All upper case :CAT; :CAT; o 6ixed case :Cat; :Cat; o <umeric values :0AE; :0AE; o Two strings with blanks only : ; : ; o <umeric and character mixed :Cat0; :Cat0; o +trings with special characters :CatF0; :CatF0; Two <@GG strings :; :;

2ne:ual Strings

Two different e&ual strings of arbitrary length o Two strings with different length :cat; :mouse; o Two strings of same length :cat; :dog; Check for case sensitivity o +ame strings different capitali>ation :Cat; :caT; 8ne string is empty o ,irst is <@GG :; :cat; o +econd is <@GG :cat; :;

! %asic +ode Structures and ,low ;rap' =otation

,or structural testing it is important to know about basic coding structures. There are four basic coding structures se&uence, if statement, case statement, and while loop. These four basic structures can be used to express any type of code. $n analysis and design, you have already seen the flow graph notation. $t is used to describe flow of data or control in an application. #owever, we do not use flow graphs to describe decisions. That is, how a branch is taken is not shown in flow graphs.

1 1

$n the following, we are using flow graph notation to describe different coding structures.
Se:uence

+e&uence depicts programming instructions that do not have branching or any control information. +o we lump together several se&uential instructions in one node of the graph.

)f

+econd structural form is the $f statement. $n the following graph, the first node at the left depicts the if statement and the two nodes next to the first node correspond to the successful case .if condition is true4 and unsuccessful case .if condition is false4 consecutively. The control comes to the same instruction from either of these intermediate instructions.

+ase

$n Case statement, control can take either of several branches .as opposed to only two in $f statement.4 ,irst node represents the switch statement .C?CHH4 and nodes in middle correspond to all different cases. /rogram can take one branch and result into the same instruction.

8'ile

A while loop structure consists of a loop guard instruction through which the iteration in the loop is controlled. The control keeps iterating in the loop as long as the loop guard condition is true. $t branches to the last instruction when it becomes false.

1 2

!.1

"#ample9 ,low ;rap' for %ubble Sort

$n the following example, code is given for a bubble sort function. The diagram opposite to the code is the corresponding flow graph model. $t consists of six nodes. <ode one is the while loop instruction that contains loop guard and node six is the ending instruction of the while loop. <ode two corresponds to the for loop instructions. <ode three corresponds to the swapping instruction. <odes five and six correspond to the last instructions of the if statement and the for loop consecutively. /oint to note here is the assignment of node numbers to program instructions. As, the corresponding flow graph model would consist of nodes that correspond to instructions that are ma'or decision points in the code. ,or example, when this function will be invoked, control will certainly come to the while loop instruction and at the minimum it will traverse from node one to node six. #owever, if control enters into the while loop even for a single iteration, it will traverse through nodes two, four and five for certain and node three too if it enters for loop and check in the if condition is true. +o all these combinations are to be tested during white box testing.

4at's

,ollowing are possible paths from starting to the end of this code. /ath0 0*2 /athA 0*A*E*I*3*0*2 /athE 0*A*I*3*0*2 /athI 0*A*I*A*E*I*3*0*2

. 8'ite %o# Testing

As described in the section above, in white box testing we test the structure of the program. $n this techni&ue the test cases are written in a manner to cover different possibilities in code. Below are described three coverage schemes.

1 3

..1

+overage

$n this scheme, statements of the code are tested for a successful test that checks all the statements lying on the path of a successful scenario. %ranc' +overage5 $n this scheme, all the possible branches of decision structures are tested. Therefore, se&uences of statements following a decision are tested. 4at' +overage5 $n path coverage, all possible paths of a program from input instruction to the output instruction are tested. An exhaustive list of test cases is generated and tested against the code.
Statement +overage5

..2

"#ample9 Test +ases for "ac' +overage Sc'eme

)ith the help of the following example, we shall see how many test cases are generated for each type of coverage schemes.

Statement +overage5

aJ0,bJ0 $f aJJb then statement A, statement E

%ranc' +overage

+tatement 0 two braches 0*A, 0*E Test case 0 if a J0, bJ0 then statement A Test case A if aJ0,bJA then statement E

4at' +overage

..3

+ame as branch testing

"#ample9 4at's in a 4rogram +ontaining oops

<ow we shall apply the path coverage scheme on a piece of code that contains a loop statement and see how many test cases can possibly be developed.

1 !

4at's

The following is an analysis of the above*mentioned code and the flow diagram. $t determines the number of paths against different iterations of the loop. < J K $f the control does not enter into the loop then only one path will be traversed. $t is 0*3. <J0 Two different paths can possibly be traversed .depending on condition4. o 0*A*I*0*3 o 0*E*I*0*3 <JA o o o o ,our possible paths can be traversed. 0*A*I*0*A*I*0*3 0*A*I*0*E*I*0*3 0*E*I*0*A*I*0*3 0*E*I*0*E*I*0*3

Denerali>ing the relation between loop variable < and the number of possible paths, for the value of <, A< paths are possible

Thus if < J AK it means more then 0 million paths are possible.

..! "#ample9 ,low grap' of a >-pot'etical 4rogram

,ollowing is a flow graph of a hypothetical program whose structure is such that it consists of two loops, one embedded in the other. Geft side of the diagram signifies the loops where inner loop seem to be containing two if statements. +econd loop has a branch and then program finishes. +imple graph of ,igure E contains 0L3A paths with each loop not iterated more than twice

1 .

,igure E ,low Draph of #ypothetical /rogram

Thus, the number of paths in a program that contains loops tends to infinity. $t is impossible to conduct exhaustive testing of a program that may consist of infinite number of test cases. The &uestion arises, how many test cases need to be executed in order to test all the ma'or scenarios in the code at least once" The answer is, calculate the cyclomatic complexity of the code. This will give us a number that corresponds to the total number of test cases that need to be generated in order to test all the statements and branches in the code at least once.
... +-clomatic +omple#it-

The concept of cyclomatic complexity is extremely useful in white box testing when analy>ing the relative complexity of the program to be tested. $t revolves around independent paths in a program which is any path through the program .from start to end4 that introduces at least one new set of processing statements or a new condition. An independent path covers statements and branches of the code. Cyclomatic complexity is a &uantitative measure of the logical complexity of a program. $t defines number of independent paths in the basis set of a program. $t provides an upper bound for the number of tests that must be conducted to ensure that all statements and branches have been executed at least once. Cyclomatic Complexity, V .D4, for a flow graph D is defined as V !"# $ E % N & '

1 /

)here = is the number of edges and < is the number of nodes in the flow graph D. Cyclomatic complexity provides us with an upper bound for the number of independent paths that comprise the basis set.
....1

,ollowing is the same bubble sort program that we discussed above. This time we shall calculate its cyclomatic complexity and see how many test cases are needed to test this function.

"#ample9 Sort 4rocedure

+-clomatic +omple#it-

Num(er o) ed es $ * Num(er o) nodes $ + C !"# $ *%+&' $ ,

4at's to be tested

-.t/01 -.t/'1 -.t/21 -.t/,1

0%+ 0%'%2%,%3%0%+ 0%'%,%3%0%+ 0%'%,%'%2%,%3%0%+

../

)nfeasible 4at's

$nfeasible path is a path through a program that is never traversed for any input data.

1 0

../.1

"#ample

$n the above*mentioned example, there are two infeasible paths that will never be traversed. /ath0 0*A*E*I*3 /athA 0*E*3

A good programming practice is such that minimi>e infeasible paths to >ero. $t will reduce the number of test cases that need to be generated in order to test the application. #ow can we minimi>e infeasible paths, by simply using else part with the if statement and avoid program statements as given above.
6odified +ode Segment

$nfeasible paths can be analy>ed and fixed.

There are no infeasible paths nowM

1 1

/ Defect *emoval "fficienc!efect removal efficiency is the ability to remove defects from the application. )e shall further elaborate this idea with the help of the following table.
!e sign $nspe ction Code $nspe ction Puality Assura nce Te sting )orst 6e dia n Be st

EKN E7N 3KN 33N 23N 73N 77N L3N 13N IKN 3EN 23N 7KN LKN L7N 1KN 17N 11N 3KN 2KN 73N LKN L7N 1EN 13N 11N 11.1N

The above table depicts data that was published after analy>ing 03KK pro'ects. $n these pro'ects, four different types of &uality assurance mechanisms were employed. $t is evident from this table that testing alone can only remove 3EN of defects. #owever, testing and &uality assurance mechanisms combine yield up to 23N efficiency. )hereas, if we combine code inspection and testing together, results are up to 73N. +imilarly, design inspections and testing yield up to LKN. 6oreover, combining design inspections, &uality assurance and testing results are up to 13N. $f all four techni&ues are combined, results are up to 11.1N.

/.1

)nspection and +'aotic ?one

,igure I Chaotic Oone

$n ,igure I, a chaotic >one has been defined. $n fact, if defects are not discovered and fixed at the appropriate stage, then at the testing and maintenance phases, these defects are piled up. Therefore, a chaotic >one is formed for the testing and the development teams as the number of defects which are piled up, destabili>e the application and it becomes extremely hard to fix all these defects as some of these bugs may involve changes in re&uirements and design. At testing or the maintenance


Testing re:uires e#ecutio n of a program w'ereas )nspecti on does not.

1 3

phases, fixing a defect in re&uirements or design becomes extremely expensive, as underlying code will have to be changed as well. $f we combine the results of the above two diagrams, it is evident that testing alone does not suffice. )e need to employ inspection techni&ues and combine them with testing to increase the effectiveness of defect removal efficiency.
/.2 Defect Origination

$n inspections the emphasis is on early detection and fixing of defects from the program. ,ollowing are the points in a development life cycle where defects enter into the program. (e&uirements !esign Coding @ser documentation Testing itself can cause defects due to bad fixes Change re&uests at the maintenance or initial usage time

$t is important to identify defects and fix them as near to their point of origination as possible.
/.3 )nspection versus Testing

$nspections and testing are complementary and not opposing verification techni&ues. Both should be used during the verification and validation process. $nspections can check conformance with a specification but not conformance with the customer%s real re&uirements. $nspections cannot check non*functional characteristics such as performance, usability etc. $nspection does not re&uire execution of program and they maybe used before implementation. 6any different defects may be discovered in a single inspection. $n testing, one defect may mask another so several executions are re&uired for inspections, checklists are prepared that contain information regarding defects. (euse domain and programming knowledge of the viewers likely to help in preparing these checklists. $nspections involve people examining the source representation with the aim of discovering anomalies and defects. $nspections may be applied to any representation of the system .re&uirements, design, test data, etc.4 Thus inspection is a very effective techni&ue for discovering errors in a software program.

2 7

/.3.1

A precise specification must be available before inspections. Team members must be familiar with the organi>ation standards. $n addition to it, syntactically correct code must be available to the inspectors. $nspectors should prepare a checklist that can help them during the inspection process.
/.3.2

)nspection pre@+onditions

Checklist of common errors in a program should be developed and used to drive the inspection process. These error checklists are programming language dependent such that the inspector has to analy>e ma'or constructs of the programming language and develop checklists to verify code that is written using these checklists.

)nspection +'ec&lists

0 Summar+oftware validation and verification includes the tests to ensure that the product meets user expectations and also meets system specifications. The primary ob'ective of such test case design is to derive a set of tests that have the highest likelihood for uncovering errors in the software. To accomplish this ob'ective, two different categories of test case design techni&ues are used white box testing and black box testing. )hite box tests focus on the program control structure. Test cases are derived to ensure that all statements in the program have been executed at least once during testing and that all logical conditions have been exercised. Black box tests are designed to validate functional re&uirements without regard to the internal workings of a program. Black box testing techni&ues focus on the information domain of the software, deriving test cases by partitioning the input and output domain of a program in a manner that provides thorough test coverage. =&uivalence partitioning divides the input domain into classes of data that are likely to exercise specific software function. @nit testing concentrates on the functional verification of a component. By applying software testing techni&ues, the software engineer can achieve more complete testing and thereby uncover and correct the highest number of errors before the Qcustomer%s testsQ begin.