WIXLIB

Preeti Patelof a “tester,” though at different times. Similarly, a tester also assumes the same two roles but atdifferent times.A developer is also a tester and vice-versa.Certainly, within a software development organization, the primary role of an individualmight be to test and hence this individual assumes the role of a “tester.” Similarly, the primarilyrole of an individual who designs applications and writes code is that of a “developer.”A reference to “tester” in this book refers to the role someone assumes when testing a program.Such an individual could be a developer testing a class she has coded, or a tester who is testing afully-integrated set of components. A “programmer” in this book refers to an individual whoengages in software development and often assumes the role of a tester, at least temporarily.This also implies that the contents of this book are valuable not only to those whose primaryrole is that of a tester, but also to those who work as developers.1.2 Software QualityWe all want high-quality software. There exist several definitions of software quality.Also, one quality attribute might be more important to a user than another. In any case,software quality is a multidimensional quantity and is measurable. So, let us look at whatdefines the quality of software.1.2.1 Quality attributesThere exist several measures of software quality. These can be divided into static anddynamic quality attributes. Static quality attributes refer to the actual code and relateddocumentation. Dynamic quality attributes relate to the behavior of the application while in use.Static quality attributes include structured, maintainable, testable code as well as theavailability of correct and complete documentation. You might have come across complaintssuch as “Product X is excellent, I like the features it offers, but its user manual stinks!” In thiscase, the user manual brings down the overall product quality. If you are a maintenanceengineer and have been assigned the task of doing corrective maintenance on an applicationcode, you will most likely need to understand portions of the code before you make any changesto it. This is where attributes such as code documentation, understandability, and structurecome into play. A poorly-documented piece of code will be harder to understand and hencedifficult to modify. Further, poorly-structured code might be harder to modify and difficult totest.Dynamic quality attributes include software reliability, correctness, completeness,consistency, usability, and performance. Reliability refers to the probability of failure-freeoperation and is considered in the following section. Correctness refers to the correct operationof an application and is always with reference to some artifact. For a tester, correctness is withrespect to the requirements; for a user, it is often with respect to a user manual.Dynamic quality attributes are generally determined through multiple executions of a program.Correctness is one such attribute though one can rarely determine the correctness of a softwareapplication via testing.Completeness refers to the availability of all features listed in the requirements, or in theuser manual. Incomplete software is one that does not fully implement all features required. Ofcourse, one usually encounters additional functionality with each new version of an application.This does not mean that a given version is incomplete because its next version has few newfeatures. Completeness is defined with respect to a set of features that might itself be a subset ofa larger set of features that are to be implemented in some future version of the application. Ofcourse, one can easily argue that every piece of software that is correct is also complete withrespect to some feature set.Completeness refers to the availability in software of features planned and their correctimplementation. Given the near impossibility of exhaustive testing, completeness is often a subjectivemeasure.4

Preeti PatelConsistency refers to adherence to a common set of conventions and assumptions. Forexample, all buttons in the user interface might follow a common color coding convention. Anexample of inconsistency would be when a database application displays the date of birth of aperson in the database; however, the date of birth is displayed in different formats, without anyregard for the user’s preferences, depending on which feature of the database is used.Usability refers to the ease with which an application can be used. This is an area in itselfand there exist techniques for usability testing. Psychology plays an important role in the designof techniques for usability testing. Usability testing also refers to the testing of a product by itspotential users. The development organization invites a selected set of potential users and asksthem to test the product. Users in turn test for ease of use, functionality as expected,performance, safety, and security. Users thus serve as an important source of tests thatdevelopers or testers within the organization might not have conceived. Usability testing issometimes referred to as user-centric testing.Performance refers to the time the application takes to perform a requested task.Performance is considered as a non-functional requirement. It is specified in terms such as “Thistask must be performed at the rate of X units of activity in one second on a machine running atspeed Y, having Z gigabytes of memory.” For example, the performance requirement for acompiler might be stated in terms of the minimum average time to compile of a set of numericalapplications.1.2.2 ReliabilityPeople want software that functions correctly every time it is used. However, thishappens rarely, if ever. Most software’s that are used today contain faults that cause them to failon some combination of inputs. Thus, the notion of total correctness of a program is an ideal andapplies mostly to academic and textbook programs.Correctness and reliability are two dynamic attributes of software. Reliability can be consideredas a statistical measure of correctness.Given that most software applications are defective, one would like to know how often agiven piece of software might fail. This question can be answered, often with dubious accuracy,with the help of software reliability, hereafter referred to as reliability. There are severaldefinitions of software reliability, a few are examined below.ANSI/IEEE STD 729-1983: RELIABILITYSoftware reliability is the probability of failure-free operation of software over a given time interval andunder given conditions.ReliabilitySoftware reliability is the probability of failure-free operation of software in its intended environment.1.3 Requirements, Behavior, and CorrectnessProducts, software in particular, are designed in response to requirements.Requirements specify the functions that a product is expected to perform. Once the product isready, it is the requirements that determine the expected behavior. Of course, during thedevelopment of the product, the requirements might have changed from what was statedoriginally. Regardless of any change, the expected behavior of the product is determined by thetester’s understanding of the requirements during testing.Example 1.3 Here are the two requirements, each of which leads to a different program.Requirement 1:Requirement 2:It is required to write a program that inputs two integers and outputs the Maximum ofthese.It is required to write a program that inputs a sequence of integers and Outputs the sortedversion of this sequence.Suppose that program max is developed to satisfy Requirement 1 above. The expectedoutput of maxwhen the input integers are 13 and 19, can be easily determined to be 19. Now5

Preeti Patelsuppose that the tester wants to know if the two integers are to be input to the program on oneline followed by a carriage return, or on two separate lines with a carriage return typed in aftereach number. The requirement as stated above fails to provide an answer to this question. Thisexample illustrates the incompleteness of Requirement 1.The second requirement in the above example is ambiguous. It is not clear from thisrequirement whether the input sequence is to be sorted in ascending or descending order. Thebehavior of the sortprogram, written to satisfy this requirement, will depend on the decisiontaken by the programmer while writing sort.Testers are often faced with incomplete and/or ambiguous requirements. In suchsituations, a tester may resort to a variety of ways to determine what behavior to expect fromthe program under test. For example, forth above program max, one way to determine how theinput should be typed in is to actually examine the program text. Another way is to ask thedeveloper of max as to what decision was taken regarding the sequence in which the inputs areto be typed in. Yet another method is to execute max on different input sequences anddetermine what is acceptable to max.Regardless of the nature of the requirements, testing requires the determination ofthe expected behavior of the program under test. The observed behavior of the program iscompared with the expected behavior to determine if the program functions as desired.1.3.1 Input domainA program is considered correct if it behaves as desired on all possible test inputs.Usually, the set of all possible inputs is too large for the program to be executed on each input.For example, suppose that the max program above is to be tested on a computer in which theintegers range from –32,768 to 32,767. To test max on all possible integers would require it tobe executed on all pairs of integers in this range. This will require a total of 2 32 executionsof max. It will take approximately 4.3 seconds to complete all executions assuming that testingis done on a computer that will take 1 nanosecond ( 10–9 seconds), to input a pair of integers,execute max, and check if the output is correct. Testing a program on all possible inputs isknown as exhaustive testing.According to one view, the input domain of a program consists of all possible inputs asderived from the program specification. According to another view, it is the set of all possibleinputs that a program could be subjected, i.e., legal and illegal inputs.A tester often needs to determine what constitutes “all possible inputs.” The first step indetermining all possible inputs is to examine the requirements. If the requirements arecomplete and unambiguous, it should be possible to determine the set of all possible inputs. Adefinition is in order before we provide an example to illustrate how to determine the set of allprogram inputs.Input domainThe set of all possible inputs to a program Ρ is known as the input domain, or input space, of P.Example 1.4 Using Requirement 1 from Example 1.3, we find the input domain of max to bethe set of all pairs of integers where each element in the pair is in the range –32,768 till 32,767.Example 1.5 Using Requirement 2 from Example 1.3, it is not possible to find the input domainfor the sort program. Let us therefore assume that the requirement was modified to be thefollowing:ModifiedRequirement 2:It is required to write a program that inputs a sequence of integers and outputs theintegers in this sequence sorted in either ascending or descending order. The order ofthe output sequence is determined by an input request character that should be “A”when an ascending sequence is desired, and “D” otherwise. While providing input to theprogram, the request character is entered first followed by the sequence of integers tobe sorted; the sequence is terminated with a period.6

Preeti PatelBased on the above modified requirement, the input domain for sort is a set of pairs. Thefirst element of the pair is a character. The second element of the pair is a sequence of zero ormore integers ending with a period. For example, following are three elements in the inputdomain of sort: A -3 15 12 55. D 23 78. A . The first element contains a sequence of four integers to be sorted in ascending order,the second element has a sequence to be sorted in descending order, and the third element hasan empty sequence to be sorted in ascending order. We are now ready to give the definition ofprogram correctness.CorrectnessA program is considered correct if it behaves as expected on each element of its input domain.1.3.2 Specifying program behaviorThere are several ways to define and specify program behavior. The simplest way is tospecify the behavior in a natural language such as English. However, this is more likely subjectto multiple interpretations than a more formally specified behavior. Here, we explain how thenotion of program “state” can be used to define program behavior and how the “state transitiondiagram,” or simply “state diagram,” can be used to specify program behavior.A collection of the current values of program variables and the location of control isconsidered as a state vector for that program.The “state” of a program is the set of current values of all its variables and an indicationof which statement in the program is to be executed next. One way to encode the state is bycollecting the current values of program variables into a vector known as the “state vector.” Anindication of where the control of execution is at any instant of time can be given by using anidentifier associated with the next program statement. In the case of programs in assemblylanguage, the location of control can be specified more precisely by giving the value of theprogram counter.Each variable in the program corresponds to one element of this vector. Obviously, for alarge program, such as the Unix operating system, the state vector might have thousands ofelements. Execution of program statements causes the program to move from one state to thenext. A sequence of program states is termed as program behavior.Example 1.6 Consider a program that inputs two integers into variables X and Y, comparesthese values, sets the value of Ζ to the larger of the two, displays the value of Ζ on the screen,and exits. Program P1.1 shows the program skeleton. The state vector for this program consistsof four elements. The first element is the statement identifier where the execution control iscurrently at. The next three elements are, respectively, the values of the three variables X,Y, and Z.Program P1.11 integer X, Y, Z;2 input (X, Y);3 if (X Y)4{Z Y;}5 else6{Z X;}7 endif8 output (Z);9 endThe letter u as an element of the state vector stands for an “undefined” value. Thenotation si sjis an abbreviation for “The program moves from state si to sj.” The movement7

Preeti Patelfrom si to sj is caused by the execution of the statement whose identifier is listed as the firstelement of state si. A possible sequence of states that the max program may go through is givenbelow.Upon the start of its execution, a program is in an “initial state.” A (correct) programterminates in its “final state.” All other program states are termed as “intermediate states.”In Example 1.6, the initial state is [2 u u u], the final state is [9 3 15 15], and there are fourintermediate states as indicated.Program behavior can be modeled as a sequence of states. With every program one canassociate one or more states that need to be observed to decide whether or not the programbehaves according to its requirements. In some applications it is only the final state that is ofinterest to the tester. In other applications a sequence of states might be of interest. Morecomplex patterns might also be needed.A sequence of states is representative of program behavior.Example 1.7 For the max program (P1.1), the final state is sufficient to decide if the programhas successfully determined the maximum of two integers. If the numbers input to max are 3and 15, then the correct final state is [9 3 15 15]. In fact, it is only the last element of the statevector, 15, which may be of interest to the tester.Example 1.8 Consider a menu-driven application named myapp. Figure 1.2 shows the menubar for this application. It allows a user to position and click the mouse on any one of a list ofmenu items displayed in the menu bar on the screen. This results in the “pulling down” of themenu and a list of options is displayed on the screen. One of the items on the menu bar islabeled File. When File is pulled down, it displays Open as one of several options. Whenthe Open option is selected, by moving the cursor over it, it should be highlighted. When themouse is released, indicating that the selection is complete, a window displaying names of filesin the current directory should be displayed.Figure 1.2 Menu bar displaying four menu items when application myapp is started.Figure 1.3 depicts the sequence of states that myapp is expected to enter when the user actionsdescribed above are performed. When started, the application enters the initial state wherein itdisplays the menu bar and waits for the user to select a menu item. This state diagram depictsthe expected behavior of myapp in terms of a state sequence. As shown in Figure1.3, myapp moves from state s0 to state s3 after the sequence of actions t0, t1, t2, and t3 has beenapplied. To test myapp, the tester could apply the sequence of actions depicted in this statediagram and observe if the application enters the expected states.Figure 1.3 A state sequence for myapp showing how the application is expected to behavewhen the user selects the open option under the File menu item.As you might observe from Figure 1.3, a state sequence diagram can be used to specifythe behavioral requirements of an application. This same specification can then be used duringtesting to ensure if the application conforms to the requirements.8

Preeti Patel1.3.3 Valid and invalid inputsIn the examples above, the input domains are derived from the requirements. However,due to the incompleteness of requirements, one might have to think a bit harder to determinethe input domain. To illustrate why, consider the modified requirement in Example 1.5. Therequirement mentions that the request characters can be “A” or “D”, but it fails to answer thequestion “What if the user types a different character?” When using sort it is certainly possiblefor the user to type a character other than “A” or “D”. Any character other than “A” or “D” isconsidered as invalid input to sort. The requirement for sort does not specify what action itshould take when an invalid input is encountered.A program ought to be tested based on representatives from the set of valid as well asinvalid inputs. The latter set is used to determine the robustness of a program.Identifying the set of invalid inputs and testing, the program against these inputs is animportant part of the testing activity. Even when the requirements fail to specify the programbehavior on invalid inputs, the programmer does treat these in one way or another. Testing aprogram against invalid inputs might reveal errors in the program.Example 1.9 Suppose that we are testing the sort program. We execute it against the followinginput: Ε 7 19 . . The requirements in Example 1.5 are insufficient to determine the expectedbehavior of sort on the above input. Now suppose that upon execution on the above input,the sort program enters into an infinite loop and neither asks the user for any input norresponds to anything typed by the user. This observed behavior points to a possible errorin sort.The argument above can be extended to apply to the sequence of integers to be sorted.The requirements for the sort program do not specify how the program should behave if,instead of typing an integer, a user types in a character, such as “?”. Of course, one would say, theprogram should inform the user that the input is invalid. But this expected behaviorfrom sort needs to be tested. This suggests that the input domain for sort should be modified.Example 1.10 Considering that sort may receive valid and invalid inputs, the input domainderived in Example 1.5 needs modification. The modified input domain consists of pairs ofvalues. The first value in the pair is any ASCII character that can be typed by a user as a requestcharacter. The second element of the pair is a sequence of integers, interspersed with invalidcharacters, terminated by a period. Thus, for example, the following are sample elements fromthe modified input domain: A 7 19. D 7 9F 19. In the example above, we assumed that invalid characters are possible inputs tothe sort program. This, however, may not be the case in all situations. For example, it might bepossible to guarantee that the inputs to sort will always be correct as determined from the9

Preeti Patelmodified requirements in Example 1.5. In such a situation, the input domain need not beaugmented to account for invalid inputs if the guarantee is to be believed by the tester.In cases where the input to a program is not guaranteed to be correct, it is convenient topartition the input domain into two subdomains. One subdomain consists of inputs that arevalid and the other consists of inputs that are invalid. A tester can then test the program onselected inputs from each subdomain. Correctness Vs Reliability1.4.1 CorrectnessThough correctness of a program is desirable, it is almost never the objective of testing.To establish correctness via testing would imply testing a program on all elements in the inputdomain. In most cases that are encountered in practice, this is impossible to accomplish. Thus,correctness is established via mathematical proofs of programs. A proof

software quality is a multidimensional quantity and is measurable. So, let us look at what defines the quality of software. 1.2.1 Quality attributes There exist several measures of software quality. These can be divided into static and dynamic quality attributes. Static quality attri