Download pdf - Typical QA Tasks and Testing Methods

8/10/2019 Typical QA Tasks and Testing Methods

1/14

Table of Contents

1. Introduction.....................................................................................................................................21.1 Purpose...................................................................................................................................21.2 Area of Appliance....................................................................................................................21.3. Responsibilities........................................................................................................................2

2. SDP Phases and Testing activities..................................................................................................22.1 Testing during the Analysis and Planning phases....................................................................32.2 Testing during the Design phase..............................................................................................32.3 Testing during the Ipleentation phase................................................................................!2.! Testing during the Testing phase............................................................................................."

2." Testing during the Deployent phase......................................................................................#$A activities................................................................................................................................ #2.# during the Transition and Support phases...............................................................................#

3. %ethods and Test docuents.........................................................................................................#3.1 Test Plan..................................................................................................................................#3.2 Test Types............................................................................................................................... &

3.2.1 'nit Testing.......................................................................................................................&3.2.2 (oponent Testing...........................................................................................................&3.2.3 Integration Testing............................................................................................................&3.2.! Regression Testing...........................................................................................................&3.2." 'ser Interface Testing.......................................................................................................)3.2.# *oad and Perforance Testing.........................................................................................)

3.2.& Solution Docuentation revie+........................................................................................)3.2.) Autoated Testing............................................................................................................)

3.3 Test (ases...............................................................................................................................)3.3.1 (reate Test scenarios.......................................................................................................)3.3.2 Identify Test cases............................................................................................................,3.3.3 Identify Data -alues to Test..............................................................................................,

3.! Test Reports...........................................................................................................................113.!.1 (ategories of soft+are errors..........................................................................................113.!.2 Reporting and Describing an Issue.................................................................................113.!.3 Test Reports...................................................................................................................12

!. /clusion points............................................................................................................................ 1!". *in0s and References...................................................................................................................1!

(hange (oents..................................................................................................................................


2/14

1. Introduction

1.1 Purpose

The purpose of this Procedure is to outline the $A Tea activity and responsibilities in $copany. Theprocedure outlines phases and procedures of uality assurance and uality control activities to coverhigh uality during all phases in the Soft+are Developent Process in accordance +ith the rules of the$uality %anageent Syste. The $A Tea activities include all uality assurance 4$A5 and all ualitycontrol 4$(5 activities.The procedure defines test types and techniues test docuentation test cycle and activities. Also aredescribed specific techniues rules nors and directions for testing process. As very iportant part ofthe $%S the cycle of testing docuentation is described and the basic rules are indicated forcopilation contents and aintain of testing docuentation.

In this docuent is used the ter testing as a suary of uality assurance and uality control activitiesduring all phases in the SDP.

1.2 Area of Appliance

The procedure should be observed and applied by the follo+ing copany actors6

$uality %anager 7 ensures the effective uality assurance 4process focused activities5 of allprocesses during the pro8ect lifecycle9

$A Tea 7 ensures the high uality control 4product oriented activities5 during the pro8ect lifecycle9

%iddle %anageent

1.3. Responsibilities

The $uality %anager onitors the appliance of this procedure +ithin the $A Tea during all phases inthe Soft+are Developent Process.The $uality %anager controls the appliance of this procedure a0ing revie+s and approving testdocuentation.The effective control should be perfored during internal audits also.The %iddle %anageent ust include the uality control activities in the pro8ect tas0s and ust estiatethe $A Tea specific tas0s in the schedule.The $A Tea ust follo+ the rules in this procedure prepare the relevant docuents according the

phases in the Soft+are Developent Process and e/ecute o+n activities and tas0s +ith highresponsibility and diligence.

.2SDP Phases and Testing activities

The uality assurance and uality control activities continue during all phases of Soft+are DevelopentProcess independent of its definition li0e selfdependence.


3/14

2.1 Testing during the Analsis and Planning phasesThe $A and $( activities during the Analysis and Planning phases are to perfor Reuireents revie+.The $A tea should evaluate the reuireents docuent 4and the functional definition based on it5 inters of at least si/ issues6

Are these the right requirements?Is this the solution that should be built:

Are they complete?Does Syste Release 4Delivery5 need ore functions: (an soe of thelisted reuireents be dropped:

Are they compatible? Reuireents can be logically incopatible 4i.e. contradictory5 orpsychologically incopatible.

Are they achievable?Do they assue that the hard+are +or0s ore uic0ly than it does: Dothey reuire too uch eory too any I;< devices and too fine a resolution of input or outputdevices.

Are they reasonable?

Are they testable? =o+ easy +ill it to tell +hether the design docuents atch thereuireents:

>hen $A Tea a0e a reuireents revie+ should evaluate the docuent in advance in ters of theuestions above.

2.2 Testing during the Design phase

During the Design phase the $A and $( activities should be focused in syste and design revie+ tas0s.

Three coon types of revie+ tas0s are +al0throughs inspections and technical revie+s. In revie+eetings is represent prototype 4or oc0up5 to evaluate the functionality and user interface of thesyste. Testing activity is consists in perforing follo+ing issues6

!earn about the product

Revie" specifications# proposal# design docu$ents

As% for design testabilit


4/14

The pro8ect Tea should prepare a design of the solution +ith a/iu testability 7 the solutionshould have a set of coponents +ith capsulated functionality and clear defined inputs and e/pectedoutputs.

Perfor$ Test Plan

?or Test Plan are described test techniues that should be perfored during Testing phase. Define test structure and strateg

Define test types +hich +ill be e/ecuted and test succession. During the Ipleentation phaseshould be generated +riting off notes for test cases

Acceptance Criteria

In the Test Plan should be defined acceptance criteria 7 the set of criteria 4tests5 for thesuccessful acceptance of the solution fro the $A Tea 4during Testing phase5 and fro the (lient4during Deployent phase5.

Anal&e stabilit of ac'uisitions

Perfor initial stability test to avoid bad acuisition. Anal&e custo$er data

Identify errors that the $A Tea issed. Asses the severity of the issed errors issed or that+ere deferred. Develop an epirical basis for evaluating deferred errors. @ustify the e/pense ofnecessary further testing. Revie" the (I for consistenc

The $A Tea should unsure the confority +ith 'ser Interface standards. specially iportant isto verify that 'I contain all client reuireents and include no e/trasteps. )egotiate earl testing environ$ent

*utputs+Test Plan

2.3 Testing during the I$ple$entation phase

In soe pro8ects the testing process starts and continues during Ipleentation phase for another starts after (ode copleteB event. Independent of that testing should start in a possible early phase ofSoft+are Developent process. Although testing is defined in SDP li0e selfdependent it is perforedduring Ipleentation phase. In this phase should be perfored follo+ing actions focused on theuality control of the solution6

Test cases design and generation

The first perforance should be to analyCe the use cases in +hich basis the $A Tea cangenerate test cases. Define all actions actors events race and boundary conditions.

In this phase the $A Tea can prepare the first revision of test plan defining and including the

obvious things 4for e/aple boundaries5. Code revie"s

?or $A Tea (ode revie+ tas0s have ostly a training disposition but they should a part of the.The $A Tea should insure the confority of the ipleented functionality +ith pro8ect rules andinternal standards (nit testing

'sually the 'nit testing is perfored fro developers but in soe cases the $A Tea ayassist in this activity. Co$ponent testing

After unit testing the $A Tea becoes to perfor coponent testing to ensure that +hole thesolution coponents +ill +or0 properly. ?or all coponents the $A Tea should build appropriatetesting environent and test ho+ coponents react on environent events. To validate that thecoponent reacts properly for all possible interactions need to develop testing scenarios. achscenario contains seuence of actions against the coponent and estiation of the results.

*utputs+Test (ases;Scenario


5/14

2., Testing during the Testing phase

Integration testing

Integration testing is conducting to inspect ho+ the coponents +or0 together. The coponentgroups can consist of t+o or ore coponents as +ell as all +hole syste. At this case the $ATea should assure that group of coponents interact +ell and +hole coponent cluster +or0sproperly. *i0e in the previous phase the $A Tea tests coponents cluster in testing environentidentical +ith the production environent. -unctional and Sste$ testing

These testing tas0s are called ost popular Independent -erification and -alidation. The functionaland syste testing +ill be perfored +ith all specifications design docuents and all clarificationsfro the %eeting %inutes docuents. During these tas0s the $A Tea should run e/aples testsas follo+ing6

Requirements verification7 copare the progras behavior against the specifications9 Usability;

Boundary conditions 7 chec0 the progra response to all boundary and e/ceptional inputvalues9

State transitions7 inspect does the progra s+itch correctly fro state to state9 Mainstream usage tests7 to use the progra the +ay the $A Tea e/pects client to use it. Load and Performance test for perforance test identify tas0s and easure ho+ long it

ta0es to do each. *oad test study the behavior +hen it is +or0ing at its liits6 volue stressstorage9

Error recovery7 verify for all listed in docuentation error essages. rror handling code isaong the least tested so these should be aong $A Tea ost fruitful tests.

Security7 inspect security for e/aple6 =o+ easy +ould it be for an unauthoriCed user togain access:

Compatibility 7 in dependence of technical reuireents should chec0 that progra +or0s

copatible +ith another or chec0 for conversion bet+een t+o versions of one progra. Configuration7 ensure that progra +or0s +ith range of systes configuration 4coputers5

and +ith listed environents in the reuireents docuents.The syste testing should be ta0en over the testing environent. The testing environent is that+hich is referenced in the reuireents. Regression testing

The $A Tea should assure that the coponents +or0 properly after any changes in thesolution. This tas0 includes needs to e/ecute the tests +ith ne+ versions of coponents again. Inthis case the $A Tea should ree/ecute the testing scenarios +hen ne+ coponent version isreleased. A regression test suite should be the iniu possible set of tests that covers an area ofthe progra. It should cover as any aspects 4subfunctions boundary conditions etc.5 of the area e

+ith correct input values for the coponents. Perfor$ance testing

The ob8ective of perforance testing is perforance enhanceent. Should be deterining +hichodules are e/ecuted ost often or use the largest part of the coputer resources 7 inspect tieand storage. Deliverable Sign *ffAfter e/ecuting of planned set of tests verification of fi/ing probles believing in deliverable uality4functionality and copleteness5 the Tea *eader and $A Tea prepare the foral docuent +ithall 0no+n issues and send it to the T%. After revie+ the T% or authoriCed person 4in +ritten for5gives the sign off for the Deliverable 4in free forat5.

*utputs+

Test ReportDeliverable Sign off9


6/14

2. Testing during the Deplo$ent phase

During Deployent phase the $A tea should perfor follo+ing activities6

Deplo$ent testing

Deployent testing contains verification of the configuration and installation procedures. (ser Docu$entation verification

The 'ser Docuentation includes 'ser %anual Installation (onfiguration %anual andAdinistration %anual. During the deployent the $A Tea tas0 is to verify these docuents forconsistency and confority +ith (lients Reuireents and Internal Standards. Technical Docu$entation verification

The $A Tea should revie+ the Technical Docuentation for copleteness and confority +ith(lient Reuireents and Internal Standards

Acceptance Testing

The acceptance test should be short. It should test ainstrea functions +ith ainstrea data.The test +ill be perfored fro the $A Tea as a final test before delivering the pro8ect to the client.In addition the client +ill e/ecute acceptance test after successful deployent of the solution. Thistest should be e/ecuted on production environent. >ith acceptance testing the (lient a0esvalidation for the product delivery.

*utputs+?inal Test ReportDeliverable pac0age9

2./ 0A activities during the Transition and Support phases

During the Transition Phase the $A Tea participates in the follo+ing activities6 ?illingin Tea $uestionnaire9

(lient Satisfaction Analysis9

Post %orte Revie+ and Analysis.

In the Support Phase the (lient can report Eon (onforing productB issues. The $A Tea shouldreproduce analyCe and evaluate issues;bugs;defects described in the Eon (onfority report. Afterfi/ing defects fro Developers the $A Tea e/ecutes tests to verify the fi/es and to confir Eon(onfority Report closing.

*utputs+Post %orte Analysis Report

.3 ethods and Test docu$ents

3.1 Test Plan

The Test Plan outlines the activities of the $A Tea involved in a specific Pro8ect phase. The plandefines the e/act $A tas0s that should be perfored by the $A Tea given to and distributedthroughout the $A Tea. The source of this e/act planning is the =i*evel uality +hich outlines TestStrategy for the developent cycles defined and brief definitions of the goals in each pro8ect phase.The $A tea should define and coplete the follo+ing activities before preparing the Test Plan6

AnalyCe Pro8ect investigate all reuireents9 Define the necessity for Test Types independence fro Pro8ect specialties9

Perfor rear0s for necessary supported nvironent 7 test and build environents9

%a0e notes for test rounds.


7/14

In the initial version of the Test Plan the $A tea can describe the follo+ing6 Prepare a structure for the test plan. Dont list boundary conditions yet but a0e a place for

the9

Describe Test Types9

Define acceptance criteria9

Describe Test ites9

*ist the ain features coands enu options i.e. start preparing the function list9

Describe reporting and bug fi/ing schea9

Describe Test deliverables9

Describe Pro8ect nvironent prereuisites9

Include actors responsibilities.

In soe cases the Test Plan can be revised during the Deployent phase but the initial revision of TestPlan should be perfored during the Design phase. In this docuent all referenced docuents and

deliverables 4input and output docuents5 should be indicated.The Test Plan is part of the Design docuents and it should be approved by the $uality %anager.

3.2 Test Tpes

This section describes the Test Types applied in $copany depending on the specifics of the Pro8ects.

.3.2.1 (nitCo$ponent Testing

In unit testing the developers fill in input data observe output data but do not 0no+ or pretend not to0no+ ho+ the progra +or0s. The $A tea loo0s for uncoon input data and conditions that ight

lead to uncoon outputs. Input data are interestingB representatives of a class of possible inputs ifthey are the ones ost li0ely to a0e visible an error in the progra. The unit;coponent testing is thefirst cycle of the testing process +riting code and debugging is an iterative cycle of prograing.

.3.2.2 Co$ponent Integration Testing

$A Tea perfors coponent integration testing after unit testing. In this test the progra is e/ainedas a set of coponents and the focus should be on the interfaces and relationships. It does not inspect aparticular coponent for proper functionality and proper +or0ing. ?or each interface and relationship ofthe coponents the $A tea e/ecutes a specific test scenario to chec0 ho+ the interfaces bet+eencoponents react to typical and uncoon inputs or environent events.

.3.2.3 Sste$ Testing

The syste testing is a ore thorough release test. It provides an opportunity to revie+ the solutionfunctionality in details before the solution deployent. The $A tea ust carefully copare theprogra the pro8ect docuentation and the clients reuireents. The Syste testing can be perforediediately after the coponent integration testing to inspect ho+ the tested coponents +or0 togetherin one syste. The $A tea should ensure proper functionality including navigation data entryprocessing and retrieval for all related parts of the syste

.3.2., Regression Testing

The regression testing is used in t+o different +ays. (oon for both is the idea of reusing old tests6 Iagine finding an error fi/ing it and then repeating the test that ade the issue visible in the first

place. 'nder these circustances the regression testing is done to a0e sure that the fi/edcode +or0s properly9


8/14

Iagine a0ing the sae fi/ and testing it but then e/ecuting a standard series of tests to a0esure that the change did not disturb anything else.

Foth types of the regression tests are e/ecuted +henever errors are fi/ed.

.3.2. (ser Interface Testing

The 'ser Interface Testing is a specific testing routine. >hen testing the 'I the $A tea should easurethe follo+ing ites6

?unctionality 7 does the 'I fit the clients reuireents9

'I reaction tie 7 is the 'I reaction tie in adissible bounds9

Availability 7 does the 'I +or0 adeuately in any possible cases9

'sability 7 the 'I should have intuitive navigation and no e/tra steps9

*oo0 G feel 7 does the 'I atch pro8ect Design standards 4(lients and Internal59

.3.2./ !oad and Perfor$ance TestingThe Perforance tests identify tas0s and easure ho+ long it ta0es to do each.


9/14

.3.3.1 Create Test scenarios

The $A Tea should revie+ the usecase description in details identify each cobination of ain andalternate flo+s 4the test scenarios5 and create a scenario atri/. The table belo+ sho+s an e/aple of apartial scenario atri/.

Scenario Eae Starting ?lo+ AlternateScenario 1 7 Successful registration Fasic ?lo+Scenario 2 7 'nidentified user Fasic ?lo+ A1Scenario 3 7 'ser uits Fasic ?lo+ A2Scenario ! 7 (ourse catalog syste unavailable Fasic ?lo+ A!Scenario " 7 Registration closed Fasic ?lo+ A"Scenario # 7 (annot enroll Fasic ?lo+ A3

.3.3.2 Identif Test cases

The $A tea can identify test cases by analyCing the test scenarios. ?or soe scenarios a fe+ casescan e/ist9 for others 7 only one. The ne/t step in fleshing out the test cases is to read the usecasedescription and find the conditions or data eleents reuired to e/ecute the various scenarios.The $A tea creates a Test case atri/. =ere is an e/aple6

TestcaseID

Scenario;(ondition 'ser ID Pass+ord (oursesselected

Prereuisitesfulfilled

(ourse


10/14

Doing error guessing.

The table belo+ describes an e/aple listing euivalence classes6

Input or Output Event Valid Equivalence lasses Invalid Equivalence lassesnter a nuber Eubers bet+een 1 and ,,

L,,An e/pression that yields an invalidnuber such as "" +hich yields .Eegative nuber.*etters and other nonnuericcharacters.

nter the first letter of a nae ?irst character is a capital character.?irst character is a lo+er case letter.

?irst character is not a letter

Dra+ a line ?ro 1 dot+idth to ! inches long Eo line*onger than ! inchesEot a line 4a curve5

The $A tea does not need to add all possible values to find data errors during testing. The first tas0 isto analyCe data types and to define their boundaries. If the $A tea uses boundary values this fact canspread any error cases. The follo+ing e/aples present analysis of data entry +ith valid and invalideuivalence classes boundary and special cases6

?ield -alid uivalence (lasses Invalid uivalence(lasses

Foundary G Special (ases Eotes

ProbleReport M

,,,,,, 1. N

2. L ,,,,,,3. Duplicate any otherreport M

!. Any nondigits

1.

2. ,,,,,,3. nter a record after,,,,,,

!. 1

Default autoatically entered butyou can edit nuber

(an you enter a saller nuberthan the default: If so +hathappens to the default ne/t tie:

Progra 'p to 3# printable chars.NReturnL NTabL leadingNSpaceL not


11/14

>hen reading fro or +riting to a dis0 file chec0 the first and last characters in the file. 4(an you read past

the files end:5

The state transitions can be uch ore cople/ than enutoenu. ?or testing interactions bet+eenpaths the $A tea should select paths through the progra as follo+s6

Test all paths that the actors are particularly li0ely to follo+9

If the $A tea has any reason to suspect that choices at one enu level or data entry screenay affect the presentation of choices else+here the $A tea can test the effects of thosechoices or entries9

Along +ith conducting the ost urgent types of tests as described above the $A tea can try afe+ rando paths through the solution. The $A tea selects different paths in each test cyclerandoly.

The $A tea cans try to guess all possible errors to inspect handling for correct error essages and

their presence. The $A tea should include the e/pected outputs after errors appear in the test cases.

3., Test Reports

.3.,.1 Categories of soft"are errors

In this section soe rules and recoendation for the $A tea are described. 6oundar7related errors

The siplest boundaries are nueric but largest and sallest aounts of eory that a progracan cope +ith boundaries too. In this eans that coon boundary conditions can be used. Calculation errors

Reeber that siple arithetic is difficult and errorprone in soe languages. Initial and later states

Fear in ind that a function ight not fail only the first tie the $A tea uses it. Control flo" errors

A control flo+ error occurs +hen the progra does the +rong thing ne/t. 8rrors in handling or interpreting data

A set of data ight be passed bac0 and forth any ties. In the process it ight be corrupted orisinterpreted. Race conditions

The classic race is bet+een t+o events. If A coes first the progra +or0s. If F happens before Athe progra fails because it e/pected A to al+ays occur before F. !oad conditionsThe progra ay isbehave +hen overloaded. 9ard"are

Progras send bad data to devices ignore error codes coing bac0 and try to use devices that arebusy or arent there.

Source and version control


12/14

.3.,.2 Reporting and Describing an Issue

This section presents instructions to the $A tea for issues;errors reporting to cover6 (orrect test docuents9

Jood counication and synchroniCation bet+een the $A and Developers Teas9

ffective trac0ing of tas0s9

hen describing and reporting issues the $A tea should follo+ the follo+ing instructions6

Fefore reporting any issue be sure of its e/istence 7 if it is necessary chec0 several ties. Dontdescribe suspicions for error appearance9

very issue or error description should be described in a possibly plain e/act andcoprehensible style9

%a0e the error description reproducible. This is ost iportant because if the Developers cant

reproduce it it is the sae as if it does not e/ist. If an error is not reproducible +rite that in yourreport by all eans9 Describe stepbystep the continuity at +hich errors arise9

Describe in detail dont be stingy in description but dont be +asteful either9

'se visual tools if it is necessary 7 this a0es description easier for adoption.

The follo+ing ites are obligatory for the issue;error description6

Area screen page or coponent in +hich error appears9

Issue category 7 for e/aple6 error;bug iproveent enhanceent change etc.9

rror priority 7 for e/aple6 ASAP high ediu lo+9

Issue state 7 for e/aple6 identified in progress finished verified closed etc.9

Solution build nuber version or release9

Reported by person 7 nae and pro8ect role9

Assigned to person 7 nae and pro8ect role9

The follo+ing ites are optional and recoendable for the $A tea6 Attachents 7 doc files iages etc.9

Issue;error severity 7 for e/aple6 critical a8or noral inor etc.9

Suggested fi/9


13/14

.3.,.3 Test Reports

In this section soe rules and recoendations to the $A tea ho+ to copose Test Reports aredescribed.During the Ipleentation phase the $A Tea describes Issues;Fugs in $copany internal IssueTrac0ing Syste 4ITS5 and prepares Issues Reports based on the inforation in the ITS. During theTesting phase the $A tea ay +rite any reports for different cases or test types. During theDeployent phase the $A tea should describe Suary Reports +hich ay be Fuild or ReleaseReports.The Issue reports substance is described in the previous chapter 4Reporting and Describing an Issue5.The Suary Reports should contain the follo+ing ites6

Pro8ect nae9

-ersion nuber9

Date of build;release9

Reported by person 7 nae and pro8ect role9

Suary 4nae title59 Test type9

Description tables figures9

Test Results9

(oents.Ites for +hich there is no data or +hich are not a sub8ect of the perfored test ay not be filled in.?or specific pro8ects during the Testing phase the $A tea can use and fill in Test (ycle (opleteReports +hich can be used for detailed analyses. The follo+ing is a siple e/aple of the contents ofthese reports6

Progra6 AF(D

-ersion6 1.'nresolvedProbles Feforethis -ersion

Ee+ Probles Resolved Reaining Probles

?atal ) 1 , ,Serious !) 12 1# !!%inor ) 1" 1! )1Total 13# 3& 3, 13!Resolution for this -ersion6?i/ed6 22Deferred6 #Irreproducible6 "


14/14

., 8=clusion points

The clients reuireents for testing ethodology standards and procedures are +ith high priority. Ifboth sides agree to a specific testing ethodology different fro the one described in this procedure the$A Tea ust a0e changes in the appliance of the testing ethodology or perfor other testingethodology in confority +ith the clients reuireents.

.!!in%s and References

IS< ,162 Standard$uality %anualSoft+are Developent ProcessEon (onforing Product

Docuents and Records %anageent$%S IproveentResource %anageent

This procedure is affected fro the internal procedure Soft+are Developent Process

!"esting omputer #o$t%are& 2nd Editionby Cem "aner# $ac% &al%# 'ung (! )guyen# *iley $o+n , Sons# $une ---.! 'ational Edge e()inehttp6;;+++1#.ib.co;developer+or0s;rational;rationaledge;/!A*#I+IEEE #tandard ,2-(--, $or #o$t%are "est /ocumentation
http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Kaner%2C%20Cem/002-0260123-5176077http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Falk%2C%20Jack/002-0260123-5176077http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Nguyen%2C%20Hung%20Q./002-0260123-5176077http://www-106.ibm.com/developerworks/rational/rationaledge/http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Kaner%2C%20Cem/002-0260123-5176077http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Falk%2C%20Jack/002-0260123-5176077http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Nguyen%2C%20Hung%20Q./002-0260123-5176077http://www-106.ibm.com/developerworks/rational/rationaledge/