METHODS & TOOLS · Good testers are still necessary to identify and write test cases for what needs to be tested. A test automator, on the other hand, takes these test cases and writes

METHODS & TOOLSGlobal knowledge source for software development professionals ISSN 1023-4918Spring 2000 (Volume 8 - number 1)

Post-Y2K Life in Software Development

We have passed the New Year and the February 29 date and no big bug has been signaled. Have weachieved this situation because we have been too alarming about the state of your software portfoliosor have we done a good job correcting all bad programs? Surely both answers are correct.

Now that the Y2K problem is mostly behind us, the question is what are we going to do? The currentmarketing noise is about "B2B e-commerce infrastructure", with new companies like Ariba orBroadvision gaining major contracts and old players like Oracle or SAP shifting their emphasis towardsthis area. It is sure that Internet is the next big thing and that most of the new projects will be involvedwith the redeployment of enterprise software on the Web platform, including the new "handheld"phenomena represented by the Palm Pilot or the WAP protocol for Internet access through mobilephones.

This means a strong demand for HTML, XML, Java or ColdFusion developers, but I do not think thatthis is the end of the need for traditional software development skills. If the software interfaces withcustomers will be changed in many organizations, the core internal processing software will continue towork on the same technologies. Mainframes, ERP and databases will still be at the heart of informationsystems. The challenge will be to integrate the new customer relationship management software with thetraditional software components like invoicing or accounting. This is where infrastructure software andmiddleware standards like Corba will play a big role.

So if you have the chance to be trained in a new technology, do not hesitate, but do not panic if youhave traditional skills, their value has not disappeared after the Y2K passage.

Inside

Practical Experience in Automated Testing........................................................................................ page 2

Understanding Use Case Modeling.................................................................................................... page 10

GUI Testing Checklist............................................................................................................................page 17

Facts, News & Comments .....................................................................................................................page 27

Testing

Methods & Tools * Spring 2000 * Page 2

Automated Software Testing - APerspective

Note from the author: My perspective on mostthings is that the 'glass is half full' rather than halfempty. This attitude carries over to the advice Isuggest on automated software testing as well. Ishould point out, however, there is an increasingawareness from others experienced in this field,as well as from my own experience, that manyefforts in test automation do not live up toexpectations. A lot of effort goes intodeveloping and maintaining test automation, andeven once it's built you may or may not recoupyour investment. It's very important to perform agood cost/benefit analysis on whatever manualtesting you plan to automate. The successes I'veseen have mostly been on focused areas of theapplication where it made sense to automate,rather than complete automation efforts. Also,skilled people were involved in these efforts andthey were allowed the time to do it right.

Test automation can add a lot of complexity andcost to a test team's effort, but it can alsoprovide some valuable assistance if its done bythe right people, with the right environment anddone where it makes sense to do so. I hope bysharing some pointers that I feel are importantthat you'll find some value that translates intosaved time, money and less frustration in yourefforts to implement test automation back on thejob.

Key Points

I’ve listed the ‘key points’ up front instead ofwaiting until the end. The rest of the article willadd detail to some of these key points.

• First, it's important to define the purpose oftaking on a test automation effort. There areseveral categories of testing tools each withits own purpose. Identifying what you wantto automate and where in the testing lifecycle will be the first step in developing atest automation strategy. Just wishing thateverything should be tested faster is not apractical strategy. You need to be specific.

• Developing a test automation strategy isvery important in mapping out what's to beautomated, how it's going to be done, howthe scripts will be maintained and what theexpected costs and benefits will be. Just likeevery testing effort should have a testingstrategy, or test plan, so should there be a'plan' built for test automation.

• Many of the testing 'tools' provided byvendors are very sophisticated and useexisting or proprietary coding 'languages'.The effort of automating an existing manualtesting effort is no different than aprogrammer using a coding language towrite programs to automate any othermanual process. Treat the entire process ofautomating testing as you would any othersoftware development effort. This includesdefining what should be automated, (therequirements phase), designing testautomation, writing the scripts, testing thescripts, etc. The scripts need to bemaintained over the life of the product justas any program would require maintenance.Other components of softwaredevelopment, such as configurationmanagement also apply

Practical Experience in Automated Testing

Kerry Zallar, [email protected]://www.testingstuff.com

Testing


• The effort of test automation is aninvestment. More time and resources areneeded up front in order to obtain thebenefits later on. Sure, some scripts can becreated which will provide immediatepayoff, but these opportunities are usuallysmall in number relative to the effort ofautomating most test cases. What thisimplies is that there usually is not a positivepayoff for automating the current release ofthe application. The benefit comes fromrunning these automated tests everysubsequent release. Therefore, ensuring thatthe scripts can be easily maintainedbecomes very important.

• Since test automation really is anothersoftware development effort, it's importantthat those performing the work have thecorrect skill sets. A good tester does notnecessarily make a good test automator. Infact, the job requirements are quite different.Good testers are still necessary to identifyand write test cases for what needs to betested. A test automator, on the other hand,takes these test cases and writes code toautomate the process of executing thosetests. From what I've seen, the best testautomation efforts have been lead bydevelopers who have put their energies intotest automation. That's not to say that testerscan't learn to be test automators and besuccessful, it's just that those two roles aredifferent and the skill sets are different.

Points

Here are some other important points toconsider:

When strategizing for test automation, plan toachieve small successes and grow. It's better toincur a small investment and see what the effortreally takes before going gung ho and trying toautomate the whole regression suite. This alsogives those doing the work the opportunity totry things, make mistakes and design even betterapproaches.

Many software development efforts areunderestimated, sometimes grosslyunderestimated. This applies to test automationas well, especially if the effort is not lookedupon as software development. Test automationis not something that can be done on the sideand care should be taken when estimating theamount of effort involved. Again, by startingsmall and growing, estimating the work can begauged.

When people think of testing tools, many firstthink of the 'capture/playback' variety where theapplication is tested at the end during systemtest. There are several types of testing toolswhich can be applied at various points of codeintegration. Test automation can be applied ateach of the levels of testing including unit testing,one or more layers of integration testing, andsystem testing (another form of integration). Thesooner tests can be executed after the code iswritten, before too much code integration hasoccurred, the more likely bugs will not becarried forward. When strategizing for testautomation, consider automating these tests asearly as possible as well as later in the testing lifecycle.

Related to this last point is the idea that testersand software developers need to work as ateam to make effective test automation work. Idon't believe testing independence is lost whentesters and developers work together, but therecan be some excellent advantages that I'll laterpoint out.

Testing tools, as sophisticated as they havebecome, are still dependent upon consistency inthe test environment. This should be quiteobvious, but having a dedicated testenvironment is absolutely necessary. If testersdon't have control of their test environment andtest data, the required setup for tests may notmeet the requirements of those tests. Whenmanual testing is done testers may sometimes'work around' test setup issues. Automated testscripts are less flexible and require specific setupscenarios, thereby needing more control.

Testing


Test automation is not the only answer todelivering quality software. In fact, testautomation in many cases is a last gasp effort inan attempt to find problems after they've beenmade instead of eliminating the problems as theyare being created. Test automation is not asubstitute for walkthroughs, inspections, goodproject management, coding standards, goodconfiguration management, etc. Most of theseefforts produce higher pay back for theinvestment than does test automation. Testingwill always need to be done and test automationcan assist, but it should not be looked upon asthe primary activity in producing better software.

The truth is that developers can produce codefaster and faster with more complexity than everbefore. Advancements in code generation toolsand code reuse are making it difficult for testersto keep up with software development. Testautomation, especially if applied only at the endof the testing cycle, will not be able to keep upwith these advances. We must pull out all stops

along the development life cycle to build in goodquality software and test as early and often aspossible with the assistance of test automation.

Benefits

To many people, the benefits of automation arepretty obvious. Tests can be run faster, they'reconsistent, and tests can be run over and overagain with less overhead. As more automatedtests are added to the test suite more tests canbe run each time thereafter. Manual testingnever goes away, but these efforts can now befocused on more rigorous tests.

There are some common 'perceived' benefitsthat I like to call 'bogus' benefits. Since testautomation is an investment it is rare that thetesting effort will take less time or resources inthe current release. Sometimes there's theperception that automation is easier than testingmanually. It actually makes the effort morecomplex since there's now another added

http://www.componentsource.com/home/firsttime.asp?MTC=BN21

Testing


software development effort. Automated testingdoes not replace good test planning, writing oftest cases or much of the manual testing effort.

Costs

Costs of test automation include personnel tosupport test automation for the long term. Asmentioned, there should be a dedicated testenvironment as well as the costs for thepurchase, development and maintenance oftools. All of the efforts to support softwaredevelopment, such as planning, designing,configuration management, etc. apply to testautomation as well.

Common View

Now that some of the basic points have beennoted, I'd like to talk about the paradigm oftesting automation. When people think of testautomation, the 'capture/playback' paradigm iscommonly perceived. The developers create theapplication software and turn it over to thetesting group. The testers then busily usecapture/playback functionality of the testing toolto quickly create test scripts. Capture/playbackis used because it's easier than 'coding' scripts.These scripts are then used to test theapplication software.

There are some inherent problems with thisparadigm. First, test automation is only appliedat the final stage of testing when it is mostexpensive to go back and correct the problem.The testers don't get a chance to create scriptsuntil the product is finished and turned over. Atthis point there is a tremendous pull onresources to just test the software and forgo thetest automation effort. Just usingcapture/playback may be temporarily effective,but using capture/playback to create an entiresuite will make the scripts hard to maintain asapplication modifications are made.

Test and Automate Early

From observations and experience, a differentparadigm appears to be more effective. Just as

you would want to test early and test often ifyou were testing manually, the same applies totest automation. The first level of testing is theunit testing performed by the developer. Frommy experience unit testing can be done well ornot done well depending on the habits andpersonality of the developer. Inherently,developers like to develop, not write test cases.Here's where an opportunity for developers andtesters to work together can begin to pay off.Testers can help document unit tests anddevelopers can write utilities to begin toautomate their unit tests. Assisting indocumenting test cases will give a bettermeasurement of unit tests executed. Muchsuccess of test automation comes fromhomegrown utilities. This is because theyintegrate so well with the application and there issupport from the developer to maintain theutilities so that they work with the application.More effective and efficient unit testing, throughthe use of some automation, provides asignificant bang for the buck in trying to findbugs in the testing life cycle. Static analyzers canalso be used to identify which modules have themost code complexity and may require moretesting.

Work With Developers

The same approach should be applied at eachsubsequent level of testing. Apply testautomation where it makes sense to do so.Whether homegrown utilities are used orpurchased testing tools, it's important that thedevelopment team work with the testing team toidentify areas where test automation makessense and to support the long-term use of testscripts.

Where GUI applications are involved thedevelopment team may decide to use customcontrols to add functionality and make theirapplications easier to use. It's important todetermine if the testing tools used can recognizeand work with these custom controls. If thetesting tools can't work with these controls, thentest automation may not be possible for that partof the application. Similarly, if months and

Testing


months of effort went into building test scriptsand the development team decides to use newcustom controls which don't work with existingtest scripts, this change may completelyinvalidate all the effort that went into testautomation. In either case, by identifying upfront in the application design phase howapplication changes affect test automation,informed decisions can be made which affectapplication functionality, product quality andtime to market. If test automation concernsaren't addressed early and test scripts cannot berun, there is a much higher risk of reducedproduct quality and increased time to market.

Working with developers also promotes buildingin 'testability' into the application code. Byproviding hooks into the application testing cansometimes be made more specific to any area ofcode. Also, some tests can be performed whichotherwise could not be performed if these hookswere not built.

Besides test drivers and capture/playback tools,code coverage tools can help identify wherethere are holes in testing the code. Rememberthat code coverage may tell you if paths arebeing tested, but complete code coverage doesnot indicate that the application has beenexhaustively tested. For example, it will not tellyou what has been 'left out' of the application.

Capture/Playback

Here's just a note on capture/replay. Peopleshould not expect to install the testing tool, turnon the capture function and begin recording teststhat will be used forever and ever. Capturingkeystrokes and validating data captured withinthe script will make the script hard to maintain.Higher level scripts should be designed to bemodular which has options to run several testsscripts. The lower level test scripts that actuallyperform tests also should be relatively small andmodular so they can be shared and easilymaintained. Data for input should not be hardcoded into the script, but rather read from a fileor spreadsheet and loop through the module foras many times as you wish to test with variations

of data. The expected results should also residein a file or spreadsheet and read in at the time ofverification. This method considerably shortensthe test script making it easier to maintain andpossibly reuse by other test scripts. Bitmapcomparisons should be used very sparingly. Theproblem with bitmap comparison is that if evenone pixel changes in the application for thebitmap being compared, the image will compareas a mismatch even if you recognize it as adesirable change and not a bug. Again, the issueis maintainability of the test suite.

Capture/playback functionality can be useful insome ways. Even when creating small modularscripts it may be easier to first capture the testthen go back and shorten and modify it foreasier maintenance. If you wish to create scriptsthat will obviously provide immediate pay back,but you don't care if it's maintainable, then usingcapture/playback can be a very quick way tocreate the automated test. These scripts typicallyare thrown away and rebuilt later for long termuse. The capture/playback functionality is alsogood to use during the design phase of aproduct if there's a prototype developed. Duringusability testing, which is an application designtechnique, users sit at the computer using amock up of the actual application where they'reable to use the interface, but the realfunctionality has not yet been built. By runningthe capture/playback tool in capture mode whilethe users are 'playing' with the application,recorded keystrokes and mouse movements cantrack where the users move on the system.Reading these captured scripts help thedesigners understand the level of difficulty innavigating through the application.

Players

Test automation is not just the responsibility ofthe testers. As noted, getting developersinvolved is important as well as getting theunderstanding and support of management.Since test automation is an investment, it'simportant that they understand the up front costsand expected benefits so that test automationstays around long enough to show the benefits.

Testing


There is the tendency to 'give up' when resultsare not shown right away.

If the project is just beginning with testautomation then having someone who canchampion the test automation effort is important.This 'champion' should have skills in projectmanagement, software testing and softwaredevelopment (preferably a coding background).This 'champion' is responsible for being theproject manager of the test automation effort.This person needs to interact well with both thetesters and the application developers. Since thisperson may also be actively involved withwriting scripts as well, good development skillsare also desirable. This person should not beinvolved with the designing of test cases ormanual testing other than to review other teammember's work. Typically there is not enoughtime to both design test cases and design testautomation. Nor is there time to build testscripts and run manual tests by the same person.Where the testing effort is large the distinctionbetween these two roles apply to teams ofautomators and testers as well. Too many timestest automators are borrowed to performedmanual testing never to realize the benefits oftest automation in the current or future releasesof the application.

This is not to say that the role of testers isreduced. Test planning still needs to be done bya test lead, test cases still need to be designedand manual testing will still be performed. Theadded role for these testers is that they mostlikely will begin to run the automated test scripts.As they run these scripts and begin to workmore closely with the test automation 'champion'or test automators, they too can begin to createscripts as the automated test suite matures.

Experience has shown that most bugs are notfound by running automated tests. Most bugsare found in the process of creating the scripts,or the first time the code is tested. What testautomation mostly buys you is the opportunity tonot spend valuable man-hours re-testing codethat has been tested before, but which has to betested in any case because the risk is too high

not to test it. The other benefit comes from theopportunity to spend these man-hours rigorouslytesting new code for the first time and identifyingnew bugs. Just as testing in general is not aguarantee, but a form of insurance, testautomation is a method to have even moreinsurance.

Some Nuts and Bolts

When learning to use testing tools it's commonto make mistakes. One way to mitigate thesemistakes is to create scripts that will provideimmediate pay back. That is, create scriptswhich won't take too much time to create yetwill obviously save manual testing effort. Thesescripts will be immediately useful and it's all rightif they're not intended to be part of thepermanent test suite. Those creating the scriptswill learn more about the tool's functionality andlearn to design even better scripts. Not much islost if these scripts are thrown away since somevalue has already been gained from them. Asexperience is gained with the testing tool, a long-term approach to test automation design canstart to be developed.

Again, start off small when designing scripts.Identify the functional areas within theapplication being tested. Design at a higher levelhow each of these functional areas would beautomated, then create a specific automated testdesign for one of the functional areas. That is,what approach will be used to create scriptsusing test cases as the basis for automating thatfunction? If there are opportunities to usecommon scripting techniques with other testingmodules, then identify these commonapproaches as potential standards would beuseful in creating maintainable scripts.

Use a similar approach to design and createscripts for some of the other functional areas ofthe application. As more experience is gainedfrom automation then designing and buildingscripts to test the integration of these functionalareas would be the next step in building a largerand more useful testing suite.

Testing


Since the purpose of automating testing is to findbugs, validations should be made as tests areperformed. At each validation point there is apossibility of error. Should the script find anerror, logic should be built into it so that it cannot only report the error it found but also routeback to an appropriate point within theautomated testing suite so that the automatedtesting can continue on. This is necessary ifautomated tests are to be run overnightsuccessfully. This part of test automation is the'error recovery process'. This is a significanteffort since it has to be designed in for everyvalidation point. It's best to design and createreusable error recovery modules that can becalled from many validation points in manyscripts. Related to this are the reports that getgenerated from running the tests. Most toolsallow you to customize the reports to fit yourreporting needs.

It's also important to write documentedcomments in the test scripts to help those whowould maintain the test scripts. Write the scriptswith the belief that someone else will bemaintaining them.

In the automation test design or documentedwithin the test scripts also identify any manualintervention which is necessary to set up the testenvironment or test data in order to run thescripts. Perhaps databases need to be loaded ordata has to be reset.

Test Data

I know of three ways to have the test datapopulated so that the test environment is setupcorrectly to run automated tests. If completecontrol of the test environment is available totesters, then reloading preset databases can be arelatively quick way to load lots of data. Onedanger in having several preset databases is if afuture release requires a reconstruction of datastructures and the effort to convert the currentdata structures to the desired state is a largeeffort.

Another method of setting up the data is tocreate tests scripts which run and populate thedatabase with the necessary data to be used inautomated tests. This may take a little longer topopulate, but there's less dependency on datastructures. This method also allows moreflexibility should other data change in thedatabase.

Even though I mention 'databases' specifically,the concepts apply to other types of datastorage as well.

Other people with test automation experiencehave used 'randomly' generated datasuccessfully to work with their test scripts.Personally, I have no experience using randomlygenerated data, but this is another option worthlooking into if you're looking for other ways towork with data.

Potential Risks

Some common risks to the test automationeffort include management and team memberssupport fading after not seeing immediateresults, especially when resources are needed totest the current release. Demanding scheduleswill put pressure on the test team, projectmanagement and funding management to dowhat it takes to get the latest release out. Thereality is that the next release usually has thesame constraints and you'll wish you had theautomated testing in place.

If contractors are used to help build orchampion the test automation effort because oftheir experience, there is the risk that much ofthe experience and skills will 'walk away' whenthe contractor leaves. If a contractor is used,ensure there is a plan to back fill this positionsince the loss of a resource most likely will affectthe maintenance effort and new development oftest scripts. It's also just as important that thereis a comprehensive transfer of knowledge tothose who will be creating and maintaining thescripts.

Testing


Since the most significant pay back for runningautomated tests come from future releases,consider how long the application being testedwill remain in its current state. If a rewrite of theapplication is planned in the near future or if theinterface is going to be overhauled, then itprobably makes sense to only use testautomation for immediate pay back. Again,here's where working with application designersand developers can make a difference,especially if internal changes are planned whichmay not appear to affect the testing team, but inreality can affect a large number of test scripts.

Summary

As mentioned earlier, most of the conceptsidentified here came from experiences and asalso noted there are not a lot of facts to back upthese ideas. The intent here wasn't to prove anyparticular technique worked, but, rather just toshare methods that appear to be moresuccessful. If nothing else, this information canbe used to look at test automation from a littledifferent perspective and assist in planning.

If you have experiences that are different thanthese that you've found successful, or if you'veexperienced hardships using some of theserecommendations, I'd be grateful to hear fromyou. Many people, including myself, areinterested in finding out what really works increating higher quality software more quickly.

Method


Introduction

Following the "method wars" of the 1970s and1980s, the Unified Modeling Language (UML)emerged from the unification that occurred in the1990s within the information systems andtechnology industry. Unification was lead byRational Software Corporation and ThreeAmigos, Grady Booch, James Rumbaugh, andIvar Jacobson. The UML gained significantindustry support from various organizations viathe UML Partners Consortium and wassubmitted to and adopted by the ObjectManagement Group (OMG) as a standard(November 17, 1997).

The UML is an evolutionary general-purpose,broadly applicable, tool-supported, andindustry-standardized modeling language forspecifying, visualizing, constructing, anddocumenting the artifacts of a system-intensiveprocess. The language is broadly applicable todifferent types of systems (software and non-software), domains (business versus software),and methods and processes. The UML enablesand promotes (but does not require normandate) a use-case-driven, architecture-centric, iterative, and incremental process that isobject oriented and component based. TheUML enables the capturing, communicating, andleveraging of knowledge: models captureknowledge (semantics), architectural viewsorganize knowledge in accordance withguidelines expressing idioms of usage, anddiagrams depict knowledge (syntax) forcommunication.

System development may be characterized asproblem solving, including understanding orconceptualize and representing a problem,solving the problem by manipulating the

representation of the problem to derive arepresentation of the desired solution, andimplementing or realizing and constructing thesolution. This process is very natural and oftenoccurs subtly and sometimes unconsciously inproblem solving.

Models are complete abstractions of systems.Models are used to capture knowledge(semantics) about problems and solutions.Architectural views are abstractions of models.Architectural views are used to organizeknowledge in accordance with guidelinesexpressing idioms of usage. Diagrams aregraphical projections of sets of model elements.Diagrams are used to depict knowledge (syntax)about problems and solutions.

Within the fundamental UML notation, conceptsare depicted as symbols and relationshipsamong concepts are depicted as paths (lines)connecting symbols.

Use case modeling from the user model view(also known as the use case or scenario view),which encompasses a problem and solution asunderstood by those individuals whose problemthe solution addresses, involves use casediagrams to depict the functionality of a system.

Use Case Diagrams

To successfully apply use case diagrams, wemust first understand the types of elements usedin use case diagrams.

Actors

Actor classes are used to model and representroles for “users” of a system, including human

Understanding Use Case Modeling

Sinan Si Alhir, [email protected]://home.earthlink.net/~salhir

Method


users and other systems. Actors are denoted asstick person icons.

They have the following characteristics:

• Actors are external to a system.

• Actors interact with the system. Actors mayuse the functionality provide by the system,including application functionality andmaintenance functionality. Actors mayprovide functionality to the system. Actorsmay receive information provided by thesystem. Actors may provide information tothe system.

• Actor classes have actors instances orobjects that represent specific actors.

Figure 1 shows a project management systemwith a project manager actor and a projectdatabase actor. The project manager is a userwho is responsible for ensuring the success ofproject and uses the system to manage projects.The project database is a system that isresponsible for housing project managementdata.

Figure 1

Use Cases

Use case classes are used to model andrepresent units of functionality or servicesprovided by a system (or parts of a system:subsystems or classes) to users. Use cases aredenoted as ellipses or ovals. They may beenclosed by a system boundary or rectanglelabeled with the name of the containing system.

They have the following characteristics:

• Use cases are interactions or dialogsbetween a system and actors, including themessages exchanged and the actionsperformed by the system. Use cases mayinclude variants of these sequences,including alternative and exceptionsequences.

• Use cases are initiated by actors and mayinvolve the participation of numerous otheractors. Use cases should provide value to atleast one of the participating actors.

• Use cases may have extension points thatdefine specific points within an interaction atwhich other use cases may be inserted.

• Use case classes have use case instances orobjects called scenarios that representspecific interactions. Scenarios represent asinge sequence of messages and actions.

Figure 1 shows a project management systemwhich provides the functionality to manageprojects in which the project manager andproject database participate.

Relationships

Association relationships between actor classesand use case classes are used to indicate thatthe actor classes participate and communicateswith the system containing the use case classes.Association relationships are denoted as solidlines or paths. Arrowheads may be used toindicate who initiates communication in theinteraction. If an arrowhead points to a usecase, the actor at the other end of theassociation initiates the interaction with thesystem. If the arrowhead points to an actor, thesystem initiates the interaction with the actor atthe other end of the association.

Figure 1 shows a project management systemthat provides functionality to manage projects. Aproject manager initiates this functionality andthe system initiates the communication with theproject database in providing this functionality.

Method


Includes relationships from base use caseclasses to inclusion use case classes are used toindicate that the base use case classes willcontain the inclusion use case classes; that is, thebase use case will contain the inclusion use case.A base use case defines the location at whichthe inclusion use case is included. Includesrelationships are denoted as dashed lines orpaths with an open arrowhead pointing at theinclusion use case and are labeled with the<<include>> keyword (stereotype). Theinsertion of the inclusion use case involves theexecution of the base use case up to theinclusion point, inserting and executing theinclusion use case, and then continuing with theexecution of the base use case.

Figure 2 shows that a project manager may addprojects and remove projects using the projectmanagement system. When removing projects,the functionality of finding a project is includedinto removing a project.

Extends relationships from extension use caseclasses to base use case classes are used toindicate that the base use case classes may beaugmented by the extension use case classes;that is, the inclusion use case will augment the

base use case if an extension condition issatisfied. A base use case defines the extensionpoint. An extension use case defines theextension condition that must be satisfied inorder to insert the extension use case into thebase use case.

The insertion of the extension use case involvesthe execution of the base use case up to theextension point, testing the extension conditionand inserting and executing the extension usecase if the condition is satisfied, and thencontinuing with the execution of the base usecase. Extends relationships are denoted asdashed lines or paths with an open arrow-headpointing at the extension use case and arelabeled with the extension condition in squarebrackets, the <<extend>> keyword(stereotype), and the extension point name inparentheses. Extension points are identified in acompartment labeled “Extension Points” in thebase use case.

Figure 3 shows that a project manager mayupdate projects using the project managementsystem. When updating projects, a projectmanager may manage tasks if the projectmanager selects the task option, and a project

Figure 2

Method


manger may manage resource if the projectmanager selects the resource option.

Generalization relationships from specializationuse case classes to generalized use cases classesare used to indicate the specialization use caseclasses are consistent with the generalized usecase classes and may add additionalinformation. A specialization use case may beused in place of a generalized use case and mayuse any portions of the interaction of thegeneralized use case. Generalizationrelationships are denoted as solid lines or paths

with a hollow arrowhead pointing at thegeneralized use case.

Figure 4 shows that a project manager maypublish a project schedule by sending e-mail toproject team members using an e-mail system orby generating a web-site on a web-site host. Ineither case, there will be common functionalityused from the generalized use case, for example:inputting project name, extracting the relevantproject information from the project database,etc.

Figure 3

Figure 4

Method


Generalization relationships from specializationactor classes to generalized actor classes areused to indicate the specialization actor classesare consistent with the generalized actor classesand may add additional information.

A specialization actor may be used in place of ageneralized actor and receives thecharacteristics of the generalized actor.Generalization relationships between actors aredenoted similarly to generalization relationshipsbetween use cases.

Figure 4 shows that there are two types projectmangers, full-time and part-time, and that thereare two types of project database, relationaldatabase management systems (R-DBMS) andobject oriented database management systems(OO-DBMS). Any type of project managermay publish a project schedule using any type ofproject database.

Use Case Modeling

To successfully apply use case diagrams in usecase modeling, we ought to be aware of variousguidelines, and lessons learned from applyingthis technique.

Actors

When modeling actors, we ought to be aware ofthe following guidelines:

• Actors should be named using nounphrases.

• Actors should be described, indicating whatinterests an actor has in interacting with thesystem. For example, the project manager isresponsible for ensuring the success ofprojects, and the project database isresponsible for housing project managementdata.

• Actors define the scope of a system andidentify those elements that reside at the

Lift your SW Development Process to new Heights!

Enterprise Architecture Configuration Management & DW, DB, Application Modeling Innovative & Affordable

Traditional development methods don’t cut | Too many SW projects are late & showit anymore. Quick response to CHANGE is | quality problems due to lack of structurea must. Modeling eliminates all these short- | in development processes. Large & mid-comings. It quickly shows where you are, | sized projects need configuration mgmtwhere you need to be & how to get there. It | to stay on the projected course.is the blueprint of IT systems & applications | Issue/Problem Version Release

Tracking Control Management

Visible Visible Business | Analyst ® Advantage™ Templates | R A Z O R ®

Benefits : * Quick Access to ‘What Is’ | Benefits: * Increased product quality * Fast adaptation to CHANGE | * Better control * Supports collaboration | * Supports collaboration * Enables integration through XML | * Audit trail through life cycle

For more information contact: Resellers are welcome! [email protected] www.visible.com/mt Excellent business opportunities.or [email protected]

http://www.visible.com/mt/

Method


periphery of the system and those elementson which the system depends. For example,these use case diagrams indicate that theproject management system depends on aproject database to provide functionality toa project manager, both residing on theperiphery of the system.

Furthermore, other guidelines may be applied inaddition to those above.

Use Cases

When modeling use cases, we ought to beaware of the following guidelines:

• Use cases should be named using verb-nounphrases.

• Use cases should be described, indicatinghow they are started and end, anyconditions that must be satisfied before theuse case starts (pre-conditions), anyconditions that must be satisfied when theuse case ends (post-conditions), thesequence of exchanged messages andperformed actions, the data exchanged, andany non-functional characteristics (reliability,performance, supportability, etc.constraints). This description may becaptured using text and other UMLdiagrams.

• Use cases define the scope of a system anddefine the functionality provided by thesystem and those elements on which thesystem depends in order to provide thefunctionality. For example, these use casediagrams indicate that the projectmanagement system will providefunctionality to manage projects to a projectmanager, and this functionality isimplemented using the project database.

• Use cases should facilitate actors in reachingtheir goals. Use cases are systemfunctionality or responsibilities(requirements) that actors use in order toreach or satisfy their goals. Use cases arenot simply actor goals. For example, aproject manager is responsible for ensuring

the success of projects, and a projectdatabase is responsible for housing projectmanagement data. The project managementsystem provides functionality to manageprojects to a project manager such that theproject manger can ensure the success ofprojects.

• Use cases should facilitate the architectureof a system. Use cases may be organizedand partitioned using includes, extends, andgeneralization relationships to identify,extract, and manage common, optional, andsimilar functionality. The organization of aset of use cases is not simply thearchitecture of the system. However, thearchitecture of a system is based upon thevarious technology, infrastructure, etc.considerations relevant to satisfying the usecases. For example, the projectmanagement system must interface with ane-mail system and a web-site host, thusappropriate subsystem elements must existwithin our architecture to facilitate theseinterfaces.

• Use cases provide flexibility and powerthroughout the life-cycle process. Theyprovide the freedom to work with a usecase as a whole or any subset of a use casevia scenarios. The use of includes, extends,and generalization relationships to identify,extract, and manage common, optional, andsimilar functionality provides furtherflexibility in working with use cases.Furthermore, use cases may be used tomodel interactions between actors andsystems, subsystems, and classes at variouslevels of abstraction. This flexibly and poweris propagated to every application of usecases. For example, if time, resources, orfunding are not sufficient to implement awhole use case, various scenarios may beselected for implementation based uponthese factors.

• Use cases may be used as the basis forplanning. Time and resource estimates maybe associated with use cases. If estimatesfor a use case cannot be derived, estimates

Method


for each scenario of a use case may bederived and used to potentially estimate theoverall time and resource estimates for theuse case as a whole. This helps ensure thatplanning is done with the objective ofsatisfying the requirements.

• Use cases may be used as the basis foranalysis, design, and implementation. Thesequence of exchanged messages andperformed actions within the description of ause case are analyzed and the system isdesign and implemented to specificallyrealize use case interactions. This helpsensure that every element of a system iscreated and used because it contributes tosatisfying the requirements.

• Use cases may be used as the basis fortesting. The sequence of exchangedmessages and performed actions within thedescription of a use case may be used astest scripts for validating the functionality ofa system. This helps ensure that the systemis tested and validated against therequirements.

• Use cases may be used as the basis fordocumentation since use cases capture howusers will use the system.

Furthermore, other guidelines may be applied inaddition to those above.

Conclusion

As the Unified Modeling Language (UML) is anevolutionary general-purpose, broadlyapplicable, tool-supported, and industry-standardized modeling language for specifying,visualizing, constructing, and documenting theartifacts of a system-intensive process, byunderstanding the types of elements used in usecase diagrams and being aware of variousguidelines (lessons learned) from applying thistechnique, we have a sound foundation forsuccessfully applying the technique.Furthermore, it is experience, experimentation,and application of the standard and its varioustechniques that will enable us to realize itsbenefits.

GUI Testing


Section 1 - Windows Compliance Standards

1.1. Application1.2. For Each Window in theApplication1.3. Text Boxes1.4. Option (Radio buttons)1.5. Check Boxes1.6. Command Buttons1.7. Drop Down List Boxes1.8. Combo Boxes1.9. List Boxes

Section 2 - Tester's Screen ValidationChecklist

2.1. Aesthetic Conditions2.2. Validation Conditions2.3. Navigation Conditions2.4. Usability Conditions2.5. Data Integrity Conditions2.6. Modes (Editable Read-only)Conditions2.7. General Conditions2.8. Specific Field Tests2.8.1. Date Field Checks2.8.2. Numeric Fields2.8.3. Alpha Field Checks

Section 3 - Validation Testing - StandardActions

3.1. On every Screen3.2. Shortcut keys / Hot Keys3.3. Control Shortcut Keys

1. WINDOWS COMPLIANCE TESTING

For Each Application

Start the application by double clicking on itsicon. The loading message should show the

application name, version number, and a biggerpictorial representation of the icon.

No login is necessary.

The main window of the application should havethe same caption as the caption of the icon inProgram Manager.

Closing the application should result in an "Areyou Sure" message box.

Attempt to start application twice. This shouldnot be allowed - you should be returned to mainWindow.

Try to start the application twice as it is loading.

On each window, if the application is busy, thenthe hour glass should be displayed. If there is nohour glass (e.g. alpha access enquiries) thensome enquiry in progress message should bedisplayed.

All screens should have a Help button, F1should work doing the same.

For Each Window in the Application

If the window has a minimize button, click it.

The window should return to an icon on thebottom of the screen.

This icon should correspond to the original iconunder Program Manager.

Double click the icon to return the window to itsoriginal size.

GUI Testing Checklist

Barry Dorgan, Bazman @bigfoot.comhttp://members.tripod.com/bazman/index.html

GUI Testing


The window caption for every applicationshould have the name of the application and thewindow name - especially the error messages.These should be checked for spelling, Englishand clarity, especially on the top of the screen.Check if the title of the window does makesense.

If the screen has a control menu, then use allungreyed options. (see below)

Check all text on window for spelling/tense andgrammar

Use TAB to move focus around the window.Use SHIFT+TAB to move focus backwards.

Tab order should be left to right, and up todown within a group box on the screen. Allcontrols should get focus - indicated by dottedbox, or cursor. Tabbing to an entry field withtext in it should highlight the entire text in thefield.

The text in the micro help line should change.Check for spelling, clarity and non-updateableetc.

If a field is disabled (greyed) then it should notget focus. It should not be possible to select itwith either the mouse or by using TAB. Try thisfor every greyed control.

Never updateable fields should be displayedwith black text on a grey background with ablack label.

All text should be left-justified, followed by acolon tight to it.

In a field that may or may not be updateable, thelabel text and contents changes from black togrey depending on the current status.

List boxes are always white background withblack text whether they are disabled or not. Allothers are grey.

In general, do not use goto screens, use gosub,i.e. if a button causes another screen to bedisplayed, the screen should not hide the firstscreen.

When returning, return to the first screen cleanlyi.e. no other screens/applications should appear.

In general, double-clicking is not essential. Ingeneral, everything can be done using both themouse and the keyboard.

All tab buttons should have a distinct letter.

Text Boxes

Program Filename:

Move the mouse cursor over all enterable textboxes. The cursor should change from arrow toinsert bar. If it doesn't then the text in the boxshould be grey or non-updateable.

Enter text into the box

Try to overflow the text by typing to manycharacters - should be stopped Check the fieldwidth with capitals W.

Enter invalid characters - Letters in amountfields, try strange characters like + , - * etc. inAll fields.

SHIFT and arrow should select characters.Selection should also be possible with mouse.Double click should select all text in box.

GUI Testing


Option (Radio Buttons)

The left and right arrows should move 'ON'selection. So should up and down. Select withthe mouse by clicking.

Check Boxes

Clicking with the mouse on the box, or on thetext should SET/UNSET the box. SPACEshould do the same.

Command Buttons

If the command button leads to another screen,and if the user can enter or change details on theother screen, then the text on the button shouldbe followed by three dots.

All buttons except for OK and Cancel shouldhave a letter access to them. This is indicated bya letter underlined in the button text. The buttonshould be activated by pressing ALT+letter.Make sure that there is no duplication.

Click each button once with the mouse - Thisshould activate

Tab to each button - Press SPACE - Thisshould activate

Tab to each button - Press RETURN - Thisshould activate

The above are VERY IMPORTANT, andshould be done for EVERY command button.

Tab to another type of control (not a commandbutton). One button on the screen should be

default (indicated by a thick black border).Pressing the return key: in ANY CASE nocommand button control should activate it.

If there is a Cancel button on the screen, thenpressing <Esc> should activate it.

If pressing the command button results inuncorrectable data e.g. closing an action step,there should be a message phrased positivelywith Yes/No answers where Yes results in thecompletion of the action.

Drop Down List Boxes

Pressing the arrow should give list of options.This list may be scrollable. You should not beable to type text in the box.

Pressing a letter should bring you to the first itemin the list with that start with that letter. Pressing‘Ctrl - F4’ should open/drop down the list box.

Spacing should be compatible with the existingwindows spacing (word etc.). Items should bein alphabetical order with the exception ofblank/none which is at the top or the bottom ofthe list box.

Drop down with the item selected should bedisplay the list with the selected item on the top.

Make sure that only one space appears, youshouldn't have a blank line at the bottom.

Combo Boxes

Should allow text to be entered. Clicking thearrow should allow user to choose from list

GUI Testing


List Boxes

Should allow a single selection to be chosen, byclicking with the mouse, or using the up anddown arrow keys.

Pressing a letter should take you to the first itemin the list starting with that letter.

If there is a 'View' or 'Open' button beside thelist box then double clicking on a line in the listbox, should act in the same way as selecting anditem in the list box, then clicking the commandbutton.

Force the scroll bar to appear, make sure all thedata can be seen in the box.

2. Screen Validation Checklist

Aesthetic Conditions:

1. Is the general screen background thecorrect colour?

2. Are the field prompts the correct color?

3. Are the field backgrounds the correctcolor?

4. In read-only mode, are the field promptsthe correct color?

5. In read-only mode, are the fieldbackgrounds the correct color?

6. Are all the screen prompts specified in thecorrect screen font?

7. Is the text in all fields specified in thecorrect screen font?

8. Are all the field prompts aligned perfectlyon the screen?

9. Are all the field edit boxes aligned perfectlyon the screen?

10. Are all groupboxes aligned correctly on thescreen?

11. Should the screen be resizable?

12. Should the screen be minimisable?

13. Are all the field prompts spelt correctly?

14. Are all character or alpha-numeric fields leftjustified? This is the default unless otherwisespecified.

15. Are all numeric fields right justified? This isthe default unless otherwise specified.

16. Is all the microhelp text spelt correctly onthis screen?

17. Is all the error message text spelt correctlyon this screen?

18. Is all user input captured in UPPER case orlower case consistently?

19. Where the database requires a value (otherthan null) then this should be defaulted intofields. The user must either enter analternative valid value or leave the defaultvalue intact.

20. Assure that all windows have a consistentlook and feel.

21. Assure that all dialog boxes have aconsistent look and feel.

Validation Conditions:

1. Does a failure of validation on every fieldcause a sensible user error message?

2. Is the user required to fix entries whichhave failed validation tests?

3. Have any fields got multiple validation rulesand if so are all rules being applied?

4. If the user enters an invalid value and clickson the OK button (i.e. does not TAB offthe field) is the invalid entry identified andhighlighted correctly with an error message?

5. Is validation consistently applied at screenlevel unless specifically required at fieldlevel?

GUI Testing


6. For all numeric fields check whethernegative numbers can and should be able tobe entered.

7. For all numeric fields check the minimumand maximum values and also some mid-range values allowable?

8. For all character/alphanumeric fields checkthe field to ensure that there is a characterlimit specified and that this limit is exactlycorrect for the specified database size?

9. Do all mandatory fields require user input?

10. If any of the database columns don’t allownull values then the corresponding screenfields must be mandatory. (If any fieldwhich initially was mandatory has becomeoptional then check whether null values areallowed in this field.)

Navigation Conditions:

1. Can the screen be accessed correctly fromthe menu?

2. Can the screen be accessed correctly fromthe toolbar?

3. Can the screen be accessed correctly bydouble clicking on a list control on theprevious screen?

4. Can all screens accessible via buttons onthis screen be accessed correctly?

5. Can all screens accessible by doubleclicking on a list control be accessedcorrectly?

6. Is the screen modal, is the user preventedfrom accessing other functions when thisscreen is active and is this correct?

7. Can a number of instances of this screen beopened at the same time and is this correct?

Usability Conditions:

1. Are all the dropdowns on this screen sortedcorrectly? Alphabetic sorting is the defaultunless otherwise specified.

2. Is all date entry required in the correctformat?

3. Have all pushbuttons on the screen beengiven appropriate shortcut keys?

4. Do the shortcut keys work correctly?

5. Have the menu options which apply to yourscreen got fast keys associated and shouldthey have?

6. Does the TAB order specified on thescreen go in sequence from top left tobottom right? This is the default unlessotherwise specified.

7. Are all read-only fields avoided in the TABsequence?

8. Are all disabled fields avoided in the TABsequence?

9. Can the cursor be placed in the microhelptext box by clicking on the text box with themouse?

10. Can the cursor be placed in read-only fieldsby clicking in the field with the mouse?

11. Is the cursor positioned in the first inputfield or control when the screen is opened?

12. Is there a default button specified on thescreen?

13. Does the default button work correctly?

14. When an error message occurs does thefocus return to the field in error when theuser cancels it?

15. When the user Alt+Tab’s to anotherapplication does this have any impact onthe screen upon return to the application?

16. Do all the fields edit boxes indicate thenumber of characters they will hold by theirlength? e.g. a 30 character field should be alot longer

Data Integrity Conditions:

1. Is the data saved when the window isclosed by double clicking on the close box?

2. Check the maximum field lengths to ensurethat there are no truncated characters?

3. Where the database requires a value (otherthan null) then this should be defaulted into

GUI Testing


fields. The user must either enter analternative valid value or leave the defaultvalue intact.

4. Check maximum and minimum field valuesfor numeric fields?

5. If numeric fields accept negative values canthese be stored correctly on the databaseand does it make sense for the field toaccept negative numbers?

6. If a set of radio buttons represent a fixedset of values such as A, B and C then whathappens if a blank value is retrieved fromthe database? (In some situations rows canbe created on the database by otherfunctions which are not screen based andthus the required initial values can beincorrect.)

7. If a particular set of data is saved to thedatabase check that each value gets savedfully to the database. Beware of truncation(of strings) and rounding of numeric values.

Modes (Editable Read-only) Conditions:

1. Are the screen and field colors adjustedcorrectly for read-only mode?

2. Should a read-only mode be provided forthis screen?

3. Are all fields and controls disabled in read-only mode?

4. Can the screen be accessed from theprevious screen/menu/toolbar in read-onlymode?

5. Can all screens available from this screenbe accessed in read-only mode?

6. Check that no validation is performed inread-only mode.

General Conditions:

1. Assure the existence of the "Help" menu.

2. Assure that the proper commands andoptions are in each menu.

3. Assure that all buttons on all tool bars havea corresponding key commands.

4. Assure that each menu command has analternative (hot-key) key sequence whichwill invoke it where appropriate.

5. In drop down list boxes, ensure that thenames are not abbreviations / cut short

6. In drop down list boxes, assure that the listand each entry in the list can be accessedvia appropriate key / hot key combinations.

7. Ensure that duplicate hot keys do not existon each screen

8. Ensure the proper usage of the escape key(which is to undo any changes that havebeen made) and generates a cautionmessage “Changes will be lost - Continueyes/no”

9. Assure that the cancel button functions thesame as the escape key.

10. Assure that the Cancel button operates as aClose button when changes have beenmade that cannot be undone.

11. Assure that only command buttons whichare used by a particular window, or in aparticular dialog box, are present. - I.e.make sure they don’t work on the screenbehind the current screen.

12. When a command button is usedsometimes and not at other times, assurethat it is grayed out when it should not beused.

13. Assure that OK and Cancel buttons aregrouped separately from other commandbuttons.

14. Assure that command button names are notabbreviations.

15. Assure that all field labels/names are nottechnical labels, but rather are namesmeaningful to system users.

16. Assure that command buttons are all ofsimilar size and shape, and same font andfont size.

GUI Testing


17. Assure that each command button can beaccessed via a hot key combination.

18. Assure that command buttons in the samewindow/dialog box do not have duplicatehot keys.

19. Assure that each window/dialog box has aclearly marked default value (commandbutton, or other object) which is invokedwhen the Enter key is pressed - and NOTthe Cancel or Close button

20. Assure that focus is set to an object/buttonwhich makes sense according to thefunction of the window/dialog box.

21. Assure that all option buttons (and radiobuttons) names are not abbreviations.

22. Assure that option button names are nottechnical labels, but rather are namesmeaningful to system users.

23. If hot keys are used to access optionbuttons, assure that duplicate hot keys donot exist in the same window/dialog box.

24. Assure that option box names are notabbreviations.

25. Assure that option boxes, option buttons,and command buttons are logically groupedtogether in clearly demarcated areas“Group Box”.

26. Assure that the Tab key sequence whichtraverses the screens does so in a logicalway.

27. Assure consistency of mouse actions acrosswindows.

28. Assure that the color red is not used tohighlight active objects (many individualsare red-green color blind).

29. Assure that the user will have control of thedesktop with respect to general color andhighlighting (the application should notdictate the desktop backgroundcharacteristics).

30. Assure that the screen/window does nothave a cluttered appearance.

31. Ctrl + F6 opens next tab within tabbedwindow.

32. Shift + Ctrl + F6 opens previous tab withintabbed window.

33. Tabbing will open next tab within tabbedwindow if on last field of current tab.

34. Tabbing will go onto the 'Continue' button ifon last field of last tab within tabbedwindow.

35. Tabbing will go onto the next editable fieldin the window.

36. Banner style and size and display exactsame as existing windows.

37. If 8 or less options in a list box, display alloptions on open of list box - should be noneed to scroll.

38. Errors on continue will cause user to bereturned to the tab and the focus should beon the field causing the error. (I.e. the tab isopened, highlighting the field with the erroron it).

39. Pressing continue while on the first tab of atabbed window (assuming all fields filledcorrectly) will not open all the tabs.

40. On open of tab focus will be on firsteditable field.

41. All fonts to be the same

42. Alt+F4 will close the tabbed window andreturn you to main screen or previousscreen (as appropriate), generating"changes will be lost" message if necessary.

43. Microhelp text for every enabled field andbutton

44. Ensure all fields are disabled in read-onlymode.

45. Progress messages on load of tabbedscreens.

46. Return operates continue.

47. If retrieve on load of tabbed window failswindow should not open.

GUI Testing


Specific Field Tests

Date Field Checks

Assure that leap years are validated correctlyand do not cause errors/miscalculations.

Assure that month code 00 and 13 are validatedcorrectly and do not causeerrors/miscalculations.

Assure that 00 and 13 are reported as errors.

Assure that day values 00 and 32 are validatedcorrectly and do not causeerrors/miscalculations.

Assure that Feb. 28, 29, 30 are validatedcorrectly and do not cause errors/miscalculations.

Assure that Feb. 30 is reported as an error.

Assure that century change is validated correctlyand does not cause errors/ miscalculations.

Assure that out of cycle dates are validatedcorrectly and do not causeerrors/miscalculations.

Numeric Fields

Assure that lowest and highest values arehandled correctly.

Assure that invalid values are logged andreported.

Assure that valid values are handles by thecorrect procedure.

Assure that numeric fields with a blank inposition 1 are processed or reported as anerror.

Assure that fields with a blank in the last positionare processed or reported as an error an error.

Assure that both + and - values are correctlyprocessed.

Assure that division by zero does not occur.

Include value zero in all calculations.

Include at least one in-range value.

Include maximum and minimum range values.

Include out of range values above the maximumand below the minimum.

Assure that upper and lower values in rangesare handled correctly.

Alpha Field Checks

Use blank and non-blank data.

Include lowest and highest values.

Include invalid characters and symbols.

Include valid characters.

Include data items with first position blank.

Include data items with last position blank.

3. VALIDATION TESTING - STANDARD

ACTIONS

On every Screen

AddViewChangeDelete

Continue

AddViewChangeDelete

Cancel

GUI Testing


Fill each field - Valid data

Fill each field - Invalid data

Different Check Box combinations

Scroll Lists

Help

Fill Lists and Scroll

Tab

Tab Order

Shift Tab

Shortcut keys - Alt + F

CONTROL SHORT KEYS

Recommended CTRL+Letter Shortcuts

Key Function

CTRL+Z Undo

CTRL+X Cut

CTRL+C Copy

CTRL+V Paste

Suggested CTRL+Letter Shortcuts

Key Function

CTRL+N New

CTRL+O Open

CTRL+P Print

CTRL+S Save

CTRL+B Bold*

CTRL+I Italic*

CTRL+U Underline*

* These shortcuts are suggested for textformatting applications, in the context for which

they make sense. Applications may use othermodifiers for these operations.

GUI Testing


Shortcut keys & Hot Keys

Key No Modifier SHIFT CRTL ALT

F1 Help Enter HelpMode

N\A N\A

F2 N\A N\A N\A N\A

F3 N\A N\A N\A N\A

F4 N\A N\A CloseDocumentWindow

CloseApplicationWindow

F5 N\A N\A N\A N\A

F6* Moveclockwise tonext pane ofactive window

Movecounterclockwise to next paneof activewindow

Move to nextdocumentwindow; topwindow movesto bottom ofstack (addingSHIFTreverses action:previouswindow movesto top.

Move toapplication'snext open non-documentwindow(Adding SHIFTreverses orderof movement)

F7 N\A N\A N\A N\A

F8 Toggle extendmode, ifsupported

Toggle Addmode , ifsupported

N\A N\A

F9 N\A N\A N\A N\A

F10 Toggle menuBar activation

N\A N\A N\A

F11,F12 N\A N\A N\A N\A

Facts, News & Comments


- Companies

Cap Gemini & Ernst & Young

Cap Gemini, the French-based software house,has reached an agreement with Ernst & Youngto acquire its consulting and IT services arm.The completion of the transaction is now subjectto the vote of Ernst & Young partners on acountry by country basis.

The new company will have a strong positionboth in Europe and in the USA, eliminating aCap Gemini weakness. It will however beinteresting to see how the cultural differencesbetween a traditional software house and apartnership-based company will influence thefusion of these two organizations.

Linux my Love

Corel and Inprise/Borland announced inFebruary that they have entered into a mergeragreement, with the goal to become a leader inthe Linux market. The combined revenues of thetwo companies in 1999 were of $418 million.

These two companies have in common a longhistory in the shade of Microsoft. The officeproductivity suite of Corel has never been reallycompetitive against Microsoft or Lotus/IBMproducts. The recent life of Inprise has beenagitated also. Its new orientation (and name)toward middleware with the Visigenic's

Visibroker acquisition has not been a bigsuccess. Its main assets are its competencies insoftware development environments withproducts like Delphi or JBuilder. Part of thetechnology is also licensed to bigger players likeOracle.

The bases of this marriage seem as unstable asthe two companies. If the Linux name has a bigmarketing potential in financial market and agood future as a server or home computingoperating system, I could not see a spectaculargrowth as a professional desktop system, that isthe main market for office productivity suite andsoftware development environments. The leastwe can hope is that the merger process will notdamage too much the quality and evolution ofInprise software development products.

Big Fish gets Bigger

In mid-February, Computer AssociatesInternational (CA) announced an agreement toacquire Sterling Software.

Sterling Software was often compared to CA inits strategy of acquiring a lot of companies tocash on licenses. In the recent years, Sterlinghas acquired Knowledgeware (ADW), TISoftware (IEF/Composer), Synon and CayenneSoftware. All these products were remixed in anew line using the "Cool:" prefix. With itsacquisition by CA, the probability of having astrong company working on the evolution ofsoftware engineering tools seems to vanish. If

Everlasting Advertisement Available5000 registered readers receive Methods & Tools via e-mail...

More than 5000 visitors read the online HTML version...More than 500 times downloads each month for the past issues in PDF version...

Advertise in Methods & Tools and you will harvest results forever!(and this space costs only $60!)

Interested? Contact us: [email protected]



we examine the list of companies and productsacquired by CA (IDMS; Ideal/Datacom,Clipper, Ingres, Platinum,...), we can see thatnone has left a mark as an technology innovatorafter its absorption. The problem is thatcustomers working in traditional and mainframeenvironments have now fewer chances to findanother alternative except working with CA...

$9%£ Numbers

Wanted: Happy Workers

"The average job tenure in IT has shrunk toabout 13 months, down from about 18 monthstwo years ago"

Source: "The Joy of Quitting", Fortune,February 7, 2000

Think about your job today. How much timewould you say that you spend working orthinking about work?Too much time ........................................ 50%Just the right amount of time..................... 47%Not enough time........................................ 3%

Think again about your job today. How wellwould you say that you are paid?More than enough ..................................... 7%Just enough ............................................. 33%Not enough............................................. 60%

Overall, do you think that your job has?Exceeded your expectations .................... 16%Met your expectations ............................. 52%Fallen short of your expectations.............. 28%Been completely disappointing................... 4%

Source: "Great Expectations?", Fast Company,November 1999

From the same Fortune's article: "So whatmakes people start looking in the first place?The short answer is bad management 'Peopledon't quit because of money' says Bev Kaye, a

retention expert and co-author of Love 'Em orLose 'Em 'People leave bad bosses."

So if you think that people are the key successfactors in software project, try to keep themhappy.

& In Others' Words

The Blame Game

"Blaming is a self defense mechanism. Peoplereact personally, in a group, or as a corporation,when they are under pressure, make mistakes,are put into uncomfortable situations, or areattacked. They react in two basic ways (withvariations); they fight back (attack) or theywithdraw. People blame others to deflect aproblem, incident, or negative attention awayfrom themselves. We all have been involved inthe blame game – on both the receiving andgiving ends.

Blaming can have varying degrees of impact,and its intensity and the harm it may cause rangewidely. Someone may point the finger at us – orwe may point it at someone else – for a problemwe may or may not have caused. We maybecome the targets of intimidating grilling tacticsintended to have us own up to causing theproblem. An individual or organization may tryto keep employees constantly under its thumbby telling them how unworthy they are; this iscommon in environments that do not toleratemistakes. In perhaps the worst case, asupposedly trusted friend, maybe underpressure, diverts blame toward you and hurtsyou personally or professionally.

Why do we blame? We have been conditionedto do so. Many of us learn at a young age thatowning up to mistakes can have direconsequences – physical punishment, loss ofprivileges, belittlement, and so forth. We learndefense mechanisms like the blame to cope, andlearn from our parents' sometimes less-than-stellar examples that blaming is okay. This



conditioning is reinforced throughout ourlifetimes in all facets of society. In the businessworld, we primarily play the game because it iseasy (with few if any apparent repercussions),we are used to playing it, and we feel we needto protect ourselves and escape responsibilityfor our actions.

[...] The blame game pervades our businessculture at the work group, department andcorporate levels. Its extreme form, scapgoating,instigates reorganizations, layoffs, mergers andfinancial manipulations to mask real problemsand deflect the true cause of failure should thesemeasures not succeed. A number oforganizations never successfully complete theseundertakings despite public assertions andappearances to the contrary.

Why many large-scale changes do not succeedis difficult to say. Is it because corporationsdidn't have the right business motivation, didn'tplan well, or didn't have the know-how,patience or perseverance? Because we don'twant to analyze and reveal our failures to others,and because we use the blame game well todeflect blame away from the root cause offailure, we may never know why these initiativesfail. If we could examine these failures we mightwell see the influence of the blame game in them.

[...] We must remember that people are thefoundation of our organizations. Processesshould support people and make them moreeffective. Technology exists to integrate with ourprocesses, automate them and make our peoplemore productive, not replace them. Asorganizational change agents, we mustremember this and also demonstrate it to ourclients – in our working relationships, ourwillingness to evaluate and use the best of theirpractices, and our willingness to stand up to ourconvictions. It must manifest in our efforts todefine and implement organizational process andtechnology implementation strategies thatconsider the needs of the people affected.

Some specific organizational remedies for theblame game include the following:

1. Stop deflecting problems – don't run awayfrom finding their root causes.

2. Take responsibility and admit mistakes as alearning experience.

3. Change the blaming culture; "civilize out" thenatural instinct to blame.

4. Establish objective performance standardsbased on a common corporate vision andvalues.

5. Build effective, adult-to-adult relationshipsbased on trust and respect.

6. Develop teamwork – we all sink or swimtogether. Do not tolerate blaming on others.

7. Don't overlook personal agendas. Beingable to satisfy them helps people overcomeindividual barriers.

The blame game starts and can be stopped at apersonal level – as individuals we can make abig difference in successfully implementingpositive change at any organizational level.Lessons I've learned include maintaining aservice instead of a self orientation, believingthere is no limit to the good we can do if wedon't care who gets the credit, an maintaining asensitivity toward others. To paraphrase RalphWaldo Emerson, we succeed when we offer thebest in ourselves and strive to leave the world abetter place. When we stop blaming people andstart truly valuing them, and when we are notafraid to take responsibility for our deeds, wesow the first seeds of that success.

Source: Manfred Hein, "The Blame Game",IEEE Software, November/December 1998.

The Rookie Manager

"To get better at anything, you have to try, fail,reflect, regroup, and try again, until yousucceed. Your first successes are likely to besporadic and hard to repeat. Over time, andwith enough practice and experience, you willimprove your performance until you can performskillfully. It doesn't matter if the skill is creating agood object model in UML, writing exception-safe C++ classes, or negotiating a delivery datefor your next release.



[...] Pressman identifies some of the fears arookie project manager has when assuming anew position. One of the biggest was the"Dilbert Factor", which I interpret as the fear ofappearing technically incompetent in front ofyour technical peers as you exchange nitty grittytechnical skills for management skills. This fear isstrongest in those who aren't certain they wantto be managers. To be blunt, if you really wantto be a good manager, you'll accept thatincreasing your management and leadershipskills will mean losing some technical skills. Andyes, at times you'll end up looking just asclueless as Dilbert's pointy-haired boss. It isinevitable.

I've found that a different kind of fear is oftenmistaken for the "Dilbert Factor": the fear of theunknown. Suppose a rookie project manager isgenuinely interested in becoming a manager, butharbors a legitimate fear that she may simply notlike management. In many companies this fear iscompounded by the fact that once your are'promoted' from the technical ranks into aproject management position, there is little hopeof going back to a technical position withoutbeing labeled a failure.

We take a different approach at my company.Instead of a one-time promotion fromdevelopment into project management, we try togrow the project and general management skillsof interested developers through a series of

assignments.

[...] Developers can assume the role of projectlead without formally changing job title or role.This allows them to 'try on'management/leadership roles without the usualassumption that once you become a manageryou're stuck.

[...] At Aurigin, a developer can work on oneproject, be a lead on the next, and go back toworking on a third. This provides the necessarytime to reflect on 'management' experiences.More importantly, we've found that when arookie manager has once again become a'normal' developer she is a more effective teammember on the next projects. Simply put, to bean effective leader, you must also be an effectivefollower!"

Source: Luke Hohmann, "Coaching the RookieManager", IEEE Software, January/February1999

� Coming next in Methods & Tools

• Data Warehouse Design

• How to Sponsor a Successful Project

• Testing Client/Server Applications

Classified Advertisement

Advertising for a new Web development tool? Looking to recruit software developers? Promoting aconference or a book? Organizing software development related training? This space is waiting for youat the price of US $ 20 each line. Reach more than 5'000 web-savvy software developers and projectmanagers worldwide with a classified advertisement in Methods & Tools. Without counting those thatdownload the issue without being registered! To advertise in the classified section, to place a page ador to become the distribution sponsor of the next issue, simply send an e-mail to [email protected]

METHODS & TOOLS published by Martinig & Associates, Rue des Marronniers 25,CH-1800 Vevey, Switzerland Tel. +41 21 922 13 00 Fax +41 21 921 23 53 www.martinig.chEditor: Franco Martinig; e-mail [email protected] content of this publication cannot be reproduced without prior written consent of the publisherISSN 1023-4918 Copyright 2000, Martinig & Associates

Documents

METHODS & TOOLS · Good testers are still necessary to identify and write test cases for what needs to be tested. A test automator, on the other hand, takes these test cases and writes