WhIte Paper on Webbased test

management solutIon
Abstract
|ake the task of the QA engIneers and Leads easy
by gIvIng an easy Interface to manage and organIze
actIvItIes lIke FequIrements coverage, Test case
management, Test executIon reportIng, 0efect
management, and may be Test automatIon as well.
Cemunu Pryadarshana
Assocate Enyneer - QA
8002928
VIrtusa CorporatIon
Dctober 2013
Approach
ntroducIng a webbased test management solutIon
whIch gIves a centralIzed control over the entIre testIng
Projects.
T ConsultIng Technology mplementatIon 0W/8 8P| ApplIcatIon DutsourcIng Software TestIng Partner Product ServIces

:)
Theres a way to do
it better-nd it." -
Thomas Edison
V | R T U 8 A
P R 0 P 0 8 AL
L
V | R T U 8 A
w h | T E P A P E R
QA Portal
Contents
1 Abstract 3
2 ProbIem Statement 4
3 Proposed SoIutIon 5
4 AppIIcatIon of SoIutIon 8
5 ConcIusIon

9
V | R T U 8 A
P R 0 P 0 8 AL
L
V | R T U 8 A
w h | T E P A P E R
QA Portal
1 Abstract
Software QualIty assurance has now become one of the most Important task In the current
S/W development LIfe cycle. t Is not only testIng but also the traceabIlIty of the qualIty
assurance Is really Important.
Today's world, busIness requIrements change rapIdly such that software development should
be able to adapt to the sItuatIon accordIngly. AbIlIty to IdentIfy and delIver the Change
Fequests In tIme by assurIng the qualIty has become so Important. |aIntaInIng TCs wrItten
In an excel sheet wIll be quIte useful when It comes as a reference but Is Cleary out dated
way when It comes to maIntaIn them collaboratIvely. The same set of TCs wIll be used
from the TC wrItIng, FevIew and ExecutIon stages and wIll be modIfIed In all three stages.
CollaboratIvely update the same document set and mergIng the same In all three stages Is
a waste of tIme If only one user have access at one tIme. t wIll be more productIve and
accurate If the updatIng can happen sImultaneously. n the end, the sIngle locatIon whIch
capture all the 8A relate stuffs, clarIfIcatIon maIls and all the busIness related requIrements
wIll be TC documents (0SFS may not contaIn all) should be the TC documents; and how
quIckly the changes can made to the TC document set Is really Important. When It comes to
a project wIth a large scope and requIrement changes rapIdly and defects whIch are based
on outdated requIrements Is a waste of tIme from the QA and the 0evelopment teams. ThIs
shows that maIntaIn two or three set of documents Is clearly not the suItable way of doIng
It. FequIrement clarIfIed by a partIcular user can update the TC doc; but It Is better If the
team member can update the maIls or other related thIngs In to test case as a reference. The
current methodology Is clearly out dated and It's clearly need to change the way It has beIng.
t Is clear how Important to have a solId set of test case document In hand to overcast/
predIct the team sIze needed etc. The more accurate the TCs, more accurate the predIctIons
and the outcome wIll be a QualIty Product whIch can be delIver In tIme. To accelerate the
busIness outcomes, It's really Important to change/ Improve the way of doIng It whenever
It Is possIble, rather stIckIng In to a one way. ThIs whIte paper wIll address some of the key
areas In QA phase, whIch need to be ImprovIng In the productIvIty wIse and a solutIon: sIngle
web based applIcatIon that wIll be used throughout the S/W development lIfecycle.

9
V | R T U 8 A
P R 0 P 0 8 AL
L
V | R T U 8 A
w h | T E P A P E R
QA Portal
2 ProbIem Statement
t's a common dIffIculty when It comes to mergIng the collaboratIve tasks In to a sIngle
document (Say: TestScrIpts.xls) whIch Is collaboratIvely modIfIed by number of team
members, daIly throughout the S/W development lIfe cycle. t Is a managerIal requIrement
to keep tack on each and every member and the progress of the task assIgned to. So It's clear
how Important to commIt the work In to Key Stone end of day, such that another member
may contInue the same task In the absence of the orIgInator. 8ut, practIcally the leads may
assIgn a task based on the experIence, and a team member may complete the assIgned task
In tIme (At the End of 0ay: may be ahead of the task, may be behInd), but stIll have to waIt
after hours to commIt the task Into the reposItory: Key Stone. ThIs looks lIke a sImple task,
but wIth correct counts and references (ScenarIo numberIng, Test case count wIth the Status
In Feference table, PrIorIty and SeverIty counts) and more Importantly wIthout affectIng to
the work done by other users, Is a very rIsky task (ProbabIlIty of affectIng to other members
work when mergIng the local copy Is hIgh). f any dIscrepancIes found, then agaIn the team
member(s) have to go through the versIons and fInd out who case what and then correct It;
whIch Is tIme consumIng and an InapproprIate approach. 8ut when It come to the task, It's
all completed; but stIll It's not merged at the tIme of completIon, (the same member can
be utIlIse to another task where another team member Is strugglIng on) and at the same
tIme stayIng late Is affected to the productIvIty of the tester. There Is a better way of doIng
thIs, and wIll be addressed on the Proposed SolutIon sectIon. The resource person should
spend/utIlIse the tIme meanIngfully doIng somethIng whIch add more value to the product;
otherwIse It wIll ended up beIng exhausted workIng experIence only.
Currently, a lead has to create and maIntaIn a log/ trackIng sheet, wIth records related to
tasks agaInst the user who own the partIcular module and the completIon percentage and etc.
t Is really Important to have thIs to verIfy where we are currently and what thIngs need to be
prIorItIzed and what are not. The maIn Idea behInd thIs Is proposed solutIon Is to make the
work more effIcIent and productIve. The proposed solutIon for thIs wIll be addressed In the
next sectIon.

9
V | R T U 8 A
P R 0 P 0 8 AL
L
V | R T U 8 A
w h | T E P A P E R
QA Portal
3 Proposed SoIutIon
ntegrate the entIre QualIty Assurance cycle Into a separate Internal applIcatIon (or Integrate
In to chorus as a module and Interconnect It wIth defect tracker).
Proposed applIcatIon wIll be used In followIng stages.
1. Test case wrItIng stage
2. Test case revIew stage
i. Peer revIew
ii. Lead revIew
3. Test case executIon stage(s)
i. Test case modIfIcatIon (Change requests: f any)
4. SettIng the Task AllocatIon In all J stages.
WrItten test case wIll be Fouted through several team members (Peers, Leads) , In module
wIse, and each and every test case wIll be revIewed and modIfIed accordIngly and Fated
(FatIng: CIve 5 Star ratIng dependIng on the QualIty of the test case, by Peers and Leads,
consIderIng 1.ClarIty, 2.Arrangement, J.Coverage, 4.ApproprIateness, 5.Easy of Understand.
ThIs wIll be used as reference for the fInal ratIng of the tester or Fave, PEP etc.)
The wrItten test cases can be exported In to excel as module wIse at any poInt of tIme.
(ExtractIng the Images In to Excel may be defIcIt. Need to do a FeasIbIlIty Study on that.).
FollowIng are the Us suggested, for the proposed solutIon: a web based applIcatIon that can
be accessIble wIthIn the 7Irtusa Intranet.
Figure 1: UI for the Test Scenario Editor

9
V | R T U 8 A
P R 0 P 0 8 AL
L
V | R T U 8 A
w h | T E P A P E R
QA Portal
Figure 2: UI for the Test Case Editor
Figure 3: UI for the Test Case Execution

9
V | R T U 8 A
P R 0 P 0 8 AL
L
V | R T U 8 A
w h | T E P A P E R
QA Portal
Figure 4: UI for the Task Tracker
Figure 5: UI for the Task Progress

9
V | R T U 8 A
P R 0 P 0 8 AL
L
V | R T U 8 A
w h | T E P A P E R
QA Portal
4 AppIIcatIon of SoIutIon
The proposed solutIon wIll be a web based applIcatIon whIch supports for mport and Export
Excel functIonalIty whIch Is quIte useful and It wIll be a common template. ThIngs wIll be
easIer to modIfy vIa Excel and wIll be able to mport back and wIll be stored In a 0atabase
and each and every modIfIcatIon wIll be recorded and the transparency of the work Is hIgh.
The proposed solutIon wIll be used throughout the S/W development lIfecycle and wIll be
used as a TC wrIngIng; ExecutIng and a modIfIcatIon tool and as a TrackIng tool as well. Peer
and Lead revIews are Incorporated and easIly vIsIble the areas whIch needs to be revIewed
and who has done the work In a hIgh qualIty. The revIewIng stage can be used as a ratIng
stage and the PrIorIty and SeverIty can be set here and the mappIng of the ScenarIo 0s can
be set here wIth the web based U easIly land changIng the TC numbers or ScenarIo 0s wIll
not be sImple and less tIme consumIng and accurate task. Test ExecutIon results wIll also set
when new release number beIng set In chorus; and test executIon results correspond to the
buIld number wIll be stored In buIld wIse.
Throughout all three stages, task allocatIon can be set by the lead to partIcular team
members. ThIs wIll be used as a Task Tracker and automated emaIls wIll be sent upon a
task beIng allocated and TD and CC fIelds and the |essage wIll be customIsable. The task
allocatIon can be modIfIed at any gIven poInt of tIme because change In the allocatIon Is very
common dependIng on the managerIal decIsIons and absence of team members or etc. SInce
each and every team member are updatIng the task In real tIme; a real tIme task progress Is
avaIlable and a lead can decIde how the allocatIon should change, based on the current task
progress.
t wIll be quIte useful If the proposed applIcatIon Is Integrated In to Chorus, sInce then the
project trackIng wIll become easIer and vIsIble for Project / QA managers as well as for the
development team, coz then It wIll become a one sIngle applIcatIon.
AudItors wIll also be able to use thIs, sInce It wIll provIde each and every detaIl from the
beggIng of the IdentIfIcatIon of the Test ScenarIos to the Test Case executIon.

9
V | R T U 8 A
P R 0 P 0 8 AL
L
V | R T U 8 A
w h | T E P A P E R
QA Portal
5 ConcIusIon
The Idea behInd thIs whIte paper Is to change / modIfy the way currently the QA process
whIch Is beIng taken place In 7Irtusa. ThIs whIte paper wIll maInly address In J areas where
the process can be more accurately Implement by IntroducIng a web based applIcatIon that
wIll replace the current manual QA process. FollowIngs are the benefIts In there stages.
1. TC wrItIng Stage
. Accurate test case count avaIlable, from the begInnIng (Feal tIme status)
. dea of the amount of scope beIng covered
. WIll alter the effort put on changIng In the PrIorIty or severIty levels
7. Project change requests can be absorbed In to TCs easIly wIthout affectIng to
the Drder, etc.
7. 0etaIled TrackIng of the owner of modules also avaIlable wIth the tIme spent
2. TC FevIew Stage
. dea of the QualIty of the wrItten TCs
. Areas to be covered or need more Improvements.
. ncorporatIon of revIewed TCs Is an easy task.
7. FatIng the wrItten TCs wIll add more value to the owner of the module and
wIll also provIde a feedback on the areas need to be Improved.
J. TC ExecutIon Stage
. 0efect 0s can be lInked wIthIn the applIcatIon wIll provIde more InformatIon
whether It Is addressed In the current release or not.
. WIll avoId duplIcatIon of effort sInce real tIme TC executIon result avaIlable.
. TradabIlIty of the owners for dIfferent releases Is avaIlable In the Task
Tracker and cause of the problem and the buIld can be easIly IdentIfIed.
7. Easy task allocatIon and Intergrade emaIl notIfIcatIon wIll Improve the
TractabIlIty vIa Task Tracker.
The proposed webbased test management solutIon wIll gIve a centralIzed control over the
entIre testIng Project. t can make the task of the QA engIneers and Leads easy by gIvIng
an easy Interface to manage and organIze actIvItIes lIke FequIrements coverage, Test case
management, Test executIon reportIng, 0efect management, and may be Test automatIon as
well.
"There's a way to do It betterfInd It. Thomas EdIson

9