OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

UNIT-V SOFTWARE QUALITY AND USABILITY

CONTENTS Designing Interface Objects Software Quality Assurance System Usability Measuring User Satisfaction

PREFACE This unit deals with designing interface objects , Software uality assurance, Ty!es of tests and a test !lan ,usability testing and user satisfaction tests" INTRODUCTION Once the analysis is com!lete #and sometimes concurrently$, we can start designing the user interfaces for the objects and determining how these objects are to be !resented" The main goal of a user interface #UI$ is to dis!lay and obtain needed information in an accessible, efficient manner" The design of the software%s interface, more than anything else, affects how a user interacts and therefore e&!eriences an a!!lication" It is im!ortant for a design to !ro'ide users the information they need and clearly tell them how to successfully com!lete a tas(" A well)designed U* has 'isual a!!eal that moti'ates users to use your a!!lication" In addition, it should use the limited screen s!ace efficiently" To de'elo! and deli'er robust systems, we need a high le'el of confidence that

DEPARTMENT OF M.C.A

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

,ach com!onent will beha'e correctly" -ollecti'e beha'ior is correct" .o incorrect collecti'e beha'ior will be !roduced" DESIGNING VIEW LAYER CLASSES: Designing Interface Objects

The 'iew layer objects are res!onsible for two major as!ects of the a!!lications/ +" Inputresponding to user interaction. The user interface must be designed to translate an action by the user, such as clic(ing on a button or selecting from a menu, into an a!!ro!riate res!onse" 0" Outputdisplaying or printing business objects. This layer must !aint the best !icture !ossible of the business objects for the user" The !rocess of designing 'iew layer classes is di'ided into four major acti'ities/ 1. The macro level UI design processidentifying view layer objects. The main objecti'e of the macro !rocess is to identify classes that interact with human actors by analy1ing the use cases de'elo!ed in the analysis !hase"

2. Micro level UI design activities

DEPARTMENT OF M.C.A

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

!esigning the view layer objects by applying design a"ioms and corollaries. In designing 'iew layer objects, decide how to use and e&tend the com!onents so they best su!!ort a!!lication)s!ecific functions and !ro'ide the most usable interface" #rototyping the view layer interface. After defining a design model, !re!are a !rototy!e of some of the basic as!ects of the design" 2rototy!ing is !articularly useful early in the design !rocess" $. Testing usability and user satisfaction. 34e must test the a!!lication to ma(e sure it meets the audience re uirements" To ensure user satisfaction, we must measure user satisfaction and its usability along the way as the UI design ta(es form" 4. Refi i ! " # i$e%"$i ! $&e #e'i! . SOFTWARE QUALITY ASSURANCE( I.T5ODU-TIO. To de'elo! and deli'er robust systems, we need a high le'el of confidence that ,ach com!onent will beha'e correctly" -ollecti'e beha'ior is correct" .o incorrect collecti'e beha'ior will be !roduced"

QUALITY ASSURANCE TESTS(

DEPARTMENT OF M.C.A

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

One reason why

uality assurance is needed is because

com!uters are infamous for doing what we tell them to do, not necessarily what we want them to do" !ebugging is the !rocess of finding out where something

went wrong and correcting the code to eliminate the errors or bugs that cause une&!ected results" 7or e&am!le, if an incorrect result was !roduced at the end of

a long series of com!utations, !erha!s we forgot to assign the correct 'alue to a 'ariable, chose the wrong o!erator, or used an incorrect formula" and luc(" Sometimes, the error is ob'ious/ The bug shows its hideous Testing and searching for bugs is a balance of science, art,

head the first time we run the a!!lication" Other bugs are stealthy and might not surface until a method

recei'es a certain 'alue or until we ta(e a closer loo( at the out!ut and find out that the results are off by a factor of a certain fraction or the middle initials in a list of names are wrong" There are no magic tric(s to debugging8 howe'er, by

selecting a!!ro!riate testing strategies and a sound test !lan, we can locate the errors in were system and fi& them using readily a'ailable debugging tools" A software debugging system can !ro'ide tools for finding

DEPARTMENT OF M.C.A

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

errors in !rograms and correcting them"

TYPES OF ERRORS (

%anguage #synta&$ errors result from incorrectly constructed code,

such as an incorrectly ty!ed (eyword or some necessary !unctuation omitted" These are the easiest ty!es of errors to detect8 for the most !art, we need no debugging tools to detect them" The 'ery first time we run wer !rogram the system will re!ort the e&istence of these errors"

&un'time errors occur and are detected as the !rogram is running,

when a statement attem!ts an o!eration that is im!ossible to carry out" 7or e&am!le, if the !rogram tries to access a none&istent object #say, a file$, a run)time error will occur"

%ogic errors occur when code does not !erform the way we intended"
The code might be syntactically 'alid and run without !erforming any in'alid o!erations and yet !roduce incorrect results" Only by testing the code and analy1ing the results can we 'erify that the code !erforms as intended" *ogic errors also can !roduce run)time errors" The elimination of the syntactical bug is the !rocess of debugging, whereas the detection and elimination of the logical bug is the !rocess of testing" As we might ha'e e&!erienced by now, logical errors are the hardest ty!e of error to find"

Quality assurance testing can be di'ided into two major categories/ +" ,rror)based testing

DEPARTMENT OF M.C.A

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

0" Scenario)based testing" (rror'based testing techni ues search a gi'en class%s method for

!articular clues of interests, and then describe how these clues should be tested" 7or e&am!le, say we want to test the !ayroll-om!utation method

of an ,m!loyee class/ anEmployee.computePayroll (hours). To test this method, we must try different 'alues for hours #say,

9;, ;, +;;, and <+;$ to see if the !rogram can handle them #this also is (nown "' testing the boundary conditions). The method should be able to handle any 'alue8 if not, the error

must be recorded and re!orted" Similarly, the techni ue can be used to !erform integration testing by testing the object that !rocesses a message and not the object that sends the message" )cenario'based testing* also called usage'based testing*

concentrates on what the user does, not what the !roduct does" This means ca!turing use cases and the tas(s users !erform, then

!erforming them and their 'ariants as tests" These scenarios also can identify interaction bugs" They often are more com!le& and realistic than error)based tests"

DEPARTMENT OF M.C.A

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

Scenario)based tests tend to e&ercise multi!le subsystems in a

single test, because that is what users do" The tests will not find e'erything, but they will co'er al least the higher 'isibility system interaction bugs"

DEPARTMENT OF M.C.A

>

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

IMPACT OF OBJECT ORIENTATION ON TESTING( The im!act of an object orientation on testing is summari1ed by the following/ Some ty!es of errors could become less !lausible #not worth testing for$" Some ty!es of errors could become more !lausible #worth testing for now$" Some new ty!es of errors might a!!ear" 7or e&am!le, when we in'o(e a method, it may be hard to tell e&actly

which method gets e&ecuted" The method may belong to one of many classes" It can be hard to tell the e&act class of the method" 4hen the code accesses it, it may get an une&!ected 'alue" In a non)object)oriented system, when we loo(ed at & ? com!ute2ayroll#$8

4e ha'e to thin( about the beha'iors of a single function" In an object)oriented en'ironment, we may ha'e to thin( about the

beha'iors of base computePayroll, of derived computePayroll, and so on" 7or a single message, we need to e&!lore #or at least thin( about$ the

union of all distinct beha'iors"

DEPARTMENT OF M.C.A

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

The !roblem can be com!licated if we ha'e multi!le inheritance" Aowe'er, by a!!lying the design a&ioms and corollaries of object)

oriented design, we can limit the differences in beha'ior between base and deri'ed classes" The testing a!!roach is essentially the same in both en'ironments" The !roblem of testing messages in an object orientation is the same

as testing code that ta(es a function as a !arameter and then in'o(es it"

IMPACT OF IN)ERITANCE IN TESTING( Su!!ose we ha'e this situation/ The base class contains methods inherited#$ and redefined#$ and the deri'ed class redefines the redefined#$ method" The deri'ed((redefined has to be tested afresh since it is a new code"

Does deri'ed((inherited#$ ha'e to be retestedB If it uses redefined#$ and the redefined#$ has changed, the deri'ed((inherited#$ may mishandle the new beha'ior" So, it needs new tests e'en though the deri'ed ((inherited#$ itself has not changed" If the base((inherited has been changed, the deri'ed((inherited#$ may

not ha'e to be com!letely tested"

DEPARTMENT OF M.C.A

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

4hether it does de!ends on the base methods8 otherwise, it must be

tested again" The !oint here is that, if we do not follow the OOD guidelines, es!ecially if we don%t test incrementally, we will end u! with objects that are e&tremely hard to debug and maintain" REUSABILITY OF TESTS( If base((redefined#$ and deri'ed((redefined#$ are two different methods with different !rotocols and im!lementations, each needs a different set of test re uirements deri'ed from the use cases, analysis, design, or im!lementation" Dut the methods are li(ely to be similar" Their sets of test

re uirements will o'erla!" The better the OOD, the greater is the o'erla!" 4e need to write new tests only for those deri'ed((redefined

re uirements not satisfied by the base((redefined tests" If we ha'e to a!!ly the base ((redefined tests to objects of the class

3deri'ed,E the test in!uts may be a!!ro!riate for both classes but the e&!ected results might differ in the deri'ed class" The models de'elo!ed for analysis and design should be used for

testing as well"

DEPARTMENT OF M.C.A

+;

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

7or e&am!le, the class diagram describes relationshi!s between

objects8 that is, an object of one class may use or contain an object of another class, which is useful information for testing" 7urthermore, the use)case diagram and the highest le'el class

diagrams can benefit the scenario)based testing" Since a class diagram shows the inheritance structure, which is

im!ortant information for error)based testing, it can be used not only during analysis but also during testing" The internal uality of the software, such as its reusability and

e&tendability, should be assessed as well" Although the reusability and e&tendability are more difficult to test,

ne'ertheless they are e&tremely im!ortant" Software reusability rarely is !racticed effecti'ely"

S!ecifying results is crucial in de'elo!ing test cases" 4e should test cases that are su!!osed to fail" During such tests, it is a good idea to alert the !erson running them that failure is e&!ected" Say, we are testing a 7ile O!en feature" 4e need to s!ecify the result as follows/

DEPARTMENT OF M.C.A

++

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

+" Dro! down the 7ile menu and select O!en" 0" Try o!ening the following ty!es of files/ A file that is there #should wor($" A file that is not there #should get an (rror message$" A file name with international characters #should wor($" A file ty!e that the !rogram does not o!en #should get a message or con'ersion dialog bo&$" TEST PLAN( On !a!er, it may seem that e'erything will fall into !lace with no

!re!aration and a bug)free !roduct will be shi!!ed" Aowe'er, in the real world, it may be a good idea to use a test !lan to

find bugs and remo'e them" A dreaded and fre uently o'erloo(ed acti'ity in software

de'elo!ment is writing the test !lan" A test plan is de'elo!ed to detect and identify !otential !roblems

before deli'ering the software to its users" Users might demand a test !lan as one item deli'ered with the

!rogram" In other cases, no test !lan is re uired, but that does not mean we should not ha'e one"

DEPARTMENT OF M.C.A

+0

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

A test !lan offers a road ma! for testing acti'ities, whether usability,

user satisfaction, or uality assurance tests" It should state the test objecti'es and how to meet them" The test !lan need not be 'ery large8 in fact, de'oting too much time

to the !lan can be counter!roducti'e" The following ste!s are needed to create a test !lan/

+" 0"

Objectives of the test. -reate the objecti'es and describe how to !evelopment of a test case. De'elo! test data, both in!ut and

achie'e them" e&!ected out!ut, based on the domain of the data and the e&!ected beha'iors that must be tested 6" Test analysis. This ste! in'ol'es the e&amination of the test out!ut and the documentation of the test results" If bugs are detected, then this is re!orted and the acti'ity centers on debugging" After debugging, ste!s + through 6 must be re!eated until no bugs can be detected" All !assed tests should be re!eated with the re'ised !rogram, called regression testing* which can disco'er errors introduced during the debugging !rocess" 4hen sufficient testing is belie'ed to ha'e been conducted, this fact

should be re!orted, and testing for this s!ecific !roduct is com!lete" Most software com!anies also use beta testing* a !o!ular, in)

DEPARTMENT OF M.C.A

+6

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

e&!ensi'e, and effecti'e way to test software on a select grou! of the actual users of the system" This is in contrast to alpha testing* where testing is done by in)house

testers, such as !rogrammers, software engineers, and internal users" If we are going to !erform beta testing, ma(e sure to include it in

!lan, since it needs to be communicated to users well in ad'ance of the a'ailability of a!!lication in a beta 'ersion"

GUIDELINES FOR DEVELOPING TEST PLANS

As software gains com!le&ity and interaction among !rograms is

more tightly cou!led, !lanning becomes essential" A good test !lan not only !re'ents o'erloo(ing a feature #or features$,

it also hel!s di'ide the wor( load among other !eo!le, e&!lains Thomas" The following guidelines ha'e been de'elo!ed by Thomas for writing test !lans/

4e may ha'e re uirements that dictate a s!ecific a!!earance or format for test !lan" The test !lan should contain a schedule and a list of re uired resources" After we ha'e determined what ty!es of testing are necessary #such as
DEPARTMENT OF M.C.A

+9

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

blac( bo&, white bo&, to!)down, or bottom)u! testing$, we need to document s!ecifically what we are going to do" A configuration control system !ro'ides a way of trac(ing the changes to the code" A *e++-$&,-!&$-,-$ #e'i! tends to !roduce better code and result in more com!lete testing, so it is a good idea to try to (ee! the !lan u! to date" At the end of each month or as we reach each milestone, ta(e time to com!lete routine -.#"$e'. CONTINUOUS TESTING

Software is tested to determine whether it conforms to the

s!ecifications of re uirements" Software is maintained when errors are found and corrected, and soft)

ware is e&tended when new functionality is added to an already e&isting !rogram" There can be different reasons for testing, such as to test for !otential

!roblems in a !ro!osed design or to com!are two or more designs to determine which is better, gi'en a s!ecific tas( or set of tas(s" A common !ractice among de'elo!ers is to turn o'er a!!lications to a

uality assurance #QA$ grou! for testing only after de'elo!ment is com!leted" Since it is not in'ol'ed in the initial !lan, the testing team usually has
+:

DEPARTMENT OF M.C.A

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

no clear !icture of the system and therefore cannot de'elo! an effecti'e test !lan" 7urthermore, testing the whole system and detecting bugs is more difficult than testing smaller !ieces of the a!!lication as it is being de'elo!ed" The !ractice of waiting until after the de'elo!ment to test an

a!!lication for bugs and !erformance could waste thousands of dollars and hours of time" Testing must ta(e !lace on a continuous basis, and this refining cycle

must continue throughout the de'elo!ment !rocess until we are satisfied with the results" During this iterati'e !rocess, !rototy!es will be transformed

incrementally into the actual a!!lication" The use cases and usage scenarios can become test scenarios and, therefore, will dri'e the test !lans" Aere are the ste!s to successful testing/

Understand and communicate the business case for im!ro'ed testing" Develop an internal infrastructure to su!!ort continuous testing" Look for leaders who will commit to and own the !rocess" Measure and document were findings in a defect recording system" Publici e improvements as they are made and let !eo!le (now what they
are doing better"

DEPARTMENT OF M.C.A

+=

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

SYSTEM USABILITY AND MEASURING USER SATISFACTION(

INTRODUCTION Quality refers to the ability of !roducts to meet the users% needs and e&!ectations" The tas( of satisfying user re uirements is the basic moti'ation for Quality also means stri'ing to do the things right the first time, while Sometimes, this e'en means s!ending more time in the initial !hases uality" always loo(ing to im!ro'e how things are being done" of a !roject<such as analysis and design<ma(ing sure that we are doing the right things" Two main issues in software uality are validation or user satisfaction There are different reasons for testing" 4e can use testing to loo( for 4e can focus on com!aring two or more designs to determine which Usability testing is different from uality assurance testing in that, and verification or uality assurance" !otential !roblems in a !ro!osed design" is better, gi'en a s!ecific tas( or set of tas(s" rather than finding !rogramming defects, we assess how well the interface or the software fits the use cases, which are the reflections of users% needs and

DEPARTMENT OF M.C.A

+>

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

e&!ectations" To ensure user satisfaction, tests" we must measure it throughout with user satisfaction the system de'elo!ment

5efine and iterate the design

FIGURE The !rocess of designing 'iew layer classes"

DEPARTMENT OF M.C.A

+@

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

The !rocess of designing 'iew layer classes consists of the following ste!s #see the abo'e figure$/

+" Macro)le'el UI Design 2rocess<Identifying 'iew layer objects" 0" Micro)le'el UT Design Acti'ities" 6" Testing usability and user satisfaction" 9" 5efining and iterating the design"

Once the design is com!lete, we can wal( users through the ste!s of the scenarios to determine if the design enables the scenarios to occur as !lanned"

USABILITY TESTING The International Organi1ation for Standardi1ation #ISO$ defines -'"/i+i$0 as the effecti'eness, efficiency, and satisfaction with which a s!ecified set of users can achie'e a s!ecified set of tas(s in !articular en'ironments" The ISO definition re uires

Defi i ! $"'1'( 4hat are the tas(sB

DEPARTMENT OF M.C.A

+C

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

Defi i ! -'e%'( 4ho are the usersB A 2e" ' f,% 2e"'-%i ! effe3$i4e e''5 effi3ie 305 " # '"$i'f"3$i, ( Aow do we measure usabilityB Usability testing 2e"'-%e' $&e e"'e ,f -'e "' *e++ "' $&e #e!%ee ,f

3,2f,%$ " # '"$i'f"3$i, -'e%' &"4e *i$& $&e ',f$*"%e. P%,#-3$' *i$& .,,% -'"/i+i$0 3" /e #iffi3-+$ $, +e"% 5 3,2.+i3"$e# $, ,.e%"$e5 " # 2i'-'e# ,% ,$ -'e# "$ "++. Therefore, low !roduct usability leads to high costs for users and a bad re!utation for the de'elo!ers" Usability is one of the most crucial factors in the design and

"

de'elo!ment of a !roduct, es!ecially the user interface" Usability testing should begin in the early stages of !roduct

de'elo!ment8 for e&am!le, it can be used to gather information about how users do their wor( and find out their tas(s, which can com!lement use cases" Usability test cases begin with the identification of use cases that can The main ad'antage is that all design traces directly bac( to the user

s!ecify the target audience, tas(s, and test goals" re uirements"

OOA/ Use)case model

DEPARTMENT OF M.C.A

0;

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

Quality assurance FIGUREtest cases

User Satisfaction test cases

Usability test cases

The use cases identified during analysis can be used in testing the design" Once the design is com!lete, wal( users through the ste!s of the scenarios to determine if the design enables the scenarios to occur as !lanned"

GUIDELINES FOR DEVELOPING USABILITY TESTING ( Many techni ues can be used to gather usability information" In addition to use cases, focus grou!s can be hel!ful for generating Usability tests can be conducted in a one)on)one fashion, as a

initial ideas or trying out new ideas" demonstration, or as a 3wal( through,E in which we ta(e the users through a set of sam!le scenarios and as( about their im!ressions along the way" In a techni ue called the !i ard of " , a testing s!ecialist simulates Although these latter techni ues can be 'aluable, they often re uire a *et us ta(e a loo( at some guidelines for de'elo!ing usability testing/ the interaction of an interface" trained, e&!erienced test coordinator.

The usability testing should include all of a software%s com!onents"

DEPARTMENT OF M.C.A

0+

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

Usability testing need not be 'ery e&!ensi'e or elaborate, such as including trained s!ecialists wor(ing in a sound!roof lab with one) way mirrors and so!histicated recording e ui!ment" ,'en the small in'estment of ta!e recorder, sto!watch, and note!ad in an office or conference room can !roduce e&cellent results" Similarly, all tests need not in'ol'e many subjects" More ty!ically, uic(, iterati'e tests with a small, well)targeted sam!le of = to +; !artici!ants can identify @;<C; !ercent of most design !roblems" -onsider the user%s e&!erience as !art of software usability" 4e can study @;<C; !ercent of most design !roblems with as few as three or four users if we target only a single s(ill le'el of users, such as no'ices or intermediate le'el users" A!!ly usability testing early and often" RECORDING T)E USABILITY TEST( 4hen conducting the usability test, !ro'ide an en'ironment uiet location, free from

com!arable to the target setting8 usually a

distractions is best" Ma(e !artici!ants feel comfortable" It often hel!s to em!hasi1e that we are testing the software, not the

!artici!ants" If the !artici!ants become confused or frustrated, it is no reflection on

them" 4e can alle'iate some of the !ressure by e&!laining the testing

DEPARTMENT OF M.C.A

00

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

!rocess and e ui!ment" Always record the techni ues and search !atterns users em!loy when

attem!ting to wor( through a difficulty and the number and ty!e of hints we ha'e to !ro'ide them" As( subjects to thin( aloud as they wor(, so we can hear what

assum!tions and inferences they are ma(ing" As the !artici!ants wor(, record the time they ta(e to !erform a tas(

as well as any !roblems they encounter" 4e may want to follow u! the session with the user satisfaction test uestionnaire that as(s the

#more on this in the ne&t section$ and a

!artici!ants to e'aluate the !roduct or tas(s they !erformed"

5ecord the test results using a !ortable ta!e recorder or, better" a 'ideo

camera" Since e'en the best obser'er can miss details, re'iewing the data later will !ro'e in'aluable" 5ecorded data also allows more direct com!arison among multi!le

!artici!ants" It usually is ris(y to base conclusions on obser'ing a single subject" 5ecorded data allows the design team to re'iew and e'aluate the results"

DEPARTMENT OF M.C.A

06

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

4hene'er !ossible, in'ol'e all members of the design team in

obser'ing the test and re'iewing the results" This ensures a common reference !oint and better design solutions as

team members a!!ly their own insights to what they obser'e" If direct obser'ation is not !ossible, ma(e the recorded results a'ailable to the entire team" To ensure user satisfaction and therefore high) uality software,

measure user satisfaction along the way as the design ta(es form

USER SATISFACTION TEST ( U'e% '"$i'f"3$i, $e'$i ! is the !rocess of uantifying the usability test with some measurable attributes of the test, such as functionality, cost, or ease of use" Usability can be assessed by defining measurable goals, such as

C: !ercent of users should be able to find how to withdraw money from the ATM machine without error and with no formal training" >; !ercent of all users should e&!erience the new function as 3a clear im!ro'ement o'er the !re'ious one"E C; !ercent of consumers should be able to o!erate the F-5 within 6; minutes"

DEPARTMENT OF M.C.A

09

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

Aere are the !rinci!al objecti'es of the user satisfaction test/

As a communication 'ehicle between designers, as well as between users and designers" To detect and e'aluate changes during the design !rocess" To !ro'ide a !eriodic indication of di'ergence of o!inion about the current design" To enable !in!ointing s!ecific areas of dissatisfaction for remedy" To !ro'ide a clear understanding of just how the com!leted design is to be e'aluated" ,'en if the results are ne'er summari1ed and no one fills out a uestionnaire, the !rocess of creating the test itself will !ro'ide useful information" Additionally, the test is ine&!ensi'e, easy to use, and it is educational to both those who administer it and those who ta(e it"

GUIDELINES FOR DEVELOPING A USER SATISFACTION TEST The format of e'ery user satisfaction test is basically the same, but its Once again, the use cases can !ro'ide us with an e&cellent source of 7urthermore, we must wor( with the users or clients to find out what

content is different for each !roject" information throughout this !rocess" attributes should be included in the test"

DEPARTMENT OF M.C.A

0:

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

As( the users to select a limited number (# to +;$ of attributes by 7or e&am!le, the user might select the following attributes for a

which the final !roduct can be e'aluated" customer trac(ing system/ ease of use, functionality, cost, intuiti'eness of user interface, and reliability" Once these attributes ha'e been identified, they can !lay a crucial role in the e'aluation of the final !roduct" Aow do we rate the customer trac(ing !roject at this timeB ,ase of use/ 'ery easy +; 'ery hard C @ > = : 9 6 0 +

7unctionality/ 'ery functional +; functional C @ > = : 9 6 0 + not

-ost/ ,&!ensi'e

'ery Ine&!ensi'e +; C @ > = : 9 6 0 + 'ery

Intuiti'e UI/ 'ery Intuiti'e

DEPARTMENT OF M.C.A

0=

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

+; hard to 7ollow

>

'ery

5eliability/

'ery 5eliable

+; 5eliable

>

not

-omments/ I ha'e more to say/ I would li(e to see you"

FIGURE A custom form for user satisfaction test

DEPARTMENT OF M.C.A

0>

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

6EY TERMS

V"+i#"$i, Te'$ P+" Ve%ifi3"$i, COTS Q-"+i$0 P"$& $e'$i ! U'"!e /"'e# $e'$i !

+" Scenario based testing also called GGGGGGGGGGGG 0" GGGGGGGGGGis one of the form of 4hite bo& testing"

DEPARTMENT OF M.C.A

0@

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

6" AGGGGGGGGis de'elo!ed to detect and identify !otential !roblems before deli'ering the software to its users" 9" GGGGGGrefers to the ability of !roducts to meet the users needs and e&!ectations" :" GGGGGGGsoftware tools are already written and a few are a'ailable for analy1ing and conducting user satisfaction tests =" The tas( of !redicting corres!ondence is called GGGGGG >" GGGGGGGis the e&ercise of determining correctness"

Test your Understanding

+" The 2rocess of finding out where something went wrong and correcting the code to eliminate the errors is called

a" Testing b" Debugging c" -orrecting d" .one

0" ,rrors are detected as the !rogram is running is called

a" *ogical error b" Synta& error c" 5untime error d" .one

DEPARTMENT OF M.C.A

0C

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

6" The Techni ues search a gi'en class%s method for !articular clues of interests, then describe how the clues should be tested"

a" 4hite bo& b" Dlac( bo& c" ,rror based testing d" .one

9" In which testing we are trying 'arious in!uts and e&amine the resulting out!ut is called

a" 4hite bo& testing b" Dlac( bo& testing c" ,rror based testing d" .one

:" The testing that tests the logic to guarantee the system !ro!er functioning is called

a" Dlac( bo& testing b" 4hite bo& testing c" To! down testing d" Dottom u! testing

=" The !rocess of e&ecuting a !rogram with the intent of finding errors

a" Testing b" Debugging c" ,rror detection d" .one

>" The testing which can disco'er errors introduced during the debugging !rocess"

a" Dlac( bo& testing b" 5egression testing c" Al!ha testing

DEPARTMENT OF M.C.A

6;

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

@" Testing done at the customer site is called

a" Al!ha test b" Deta test c" 5egression test d" .one

C" It measures the ease of use as well as the degree of comfort and satisfaction users ha'e with the software

b" Al!ha testing b" Deta testing c" Usability testing d" .one

+;"The !rocess of uantifying the usability test with some measurable attributes of the test , such as functionality

a" Usability testing b" User satisfaction testing c" Al!ha testing d" Deta testing

DEPARTMENT OF M.C.A

6+

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

PART A-QUESTIONS( +" 4hat is a successful bugs when you are loo(ing for bugsB 0" Describe the different testing strategies" 6" 4hat is blac( bo& testingB 9" 4hen would you use white bo& testingB :" If you do not (now what is inside the bo&, how would you test itB =" 4hat is the im!ortance of de'elo!ing test caseB >" 4hat is white bo& testingB @" 4hat is !ath testingB C" 4hat are the ty!es of error that may occur in a !rogramB +;"4hat is statement testing co'erageB ++"4hat is branch testing co'erageB +0"Describe to! down and bottom u! strategies" 4hich do you !refer and whyB +6"4hat is regression testingB +9"4hat is test !lanB 4hat ste!s are followed in de'elo!ing a test !lanB +:"4hy are debugging tools im!ortantB +="4hat basic acti'ities are !erformed in using debugging toolsB +>"4hat is 'alidationB +@"4hat is 'erificationB
DEPARTMENT OF M.C.A

60

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 5

+C"4hat is ualityB 0;"4hy do we need usability testingB 4hen do we use usability testingB 0+"4hy do we need to a!!ly usability testing early onB 4hy should we a!!ly it oftenB 00"4hat is user satisfaction testB 06"4hat are error based 09"Aow do you de'elo! a custom form for a user satisfaction testB 0:"4hat is the significance of comments in a user satisfaction formB 2A5T D )Questions +" 0" 6" 9" :" =" Aow would you describe whether a !roduct you are buying is bug freeB -reate a user satisfaction test for a ban( system a!!licationB ,&!lain about Usability testingB ,&!lain about test !lanB ,&!lain about testing strategies" ,&!lain about inheritance in testing"

Refe%e 3e B,,17'8(

+" Dooch H",EObject Oriented Analysis And DesignE,Addison) 4esley 2ublishing -om!any,+CC9" 0" 5ambaugh I, Dlaha"M" 2remeriani, 4", ,ddy 7 and *oresen 4", 3Object Oriented Modeling and DesignE, 2AI, +CC>"

DEPARTMENT OF M.C.A

66