A Proposed Defect Tracking Model for Classifying the Inserted Defect Reports to Enhance Software Quality Control.

2013·0.97 MB·English

by  Sultan, Torky

A Proposed Defect Tracking Model for Classifying the Inserted Defect Reports to Enhance Software Quality Control 103
acta inform med. 2013 jun; 21(2): 103-108 doi: 10.5455/aim.2013.21.103-108
Received: 05 february 2013 • Accepted: 04 April 2013
conflict of interest: none declared
© AVICENA 2013
A Proposed Defect Tracking Model for Classifying the
Inserted Defect Reports to Enhance Software Quality
Control
torky sultan1, ayman e.khedr1, mostafa sayed2
information systems department, faculty of computers and information, Helwan university cairo, egypt1
information systems department council state cairo, egypt2
corresponding author: prof. torky sultan. faculty of computers and information. Helwan university of cairo, egypt. e-mail: torky @yahoo.
com, aymankhedr @gmail.com
original paper tracking models and systems to enhance their in detecting such bugs. This paper shows a
aBSTRaCT capabilities to be more specifically track- new proposed defect tracking model for the
Defect tracking systems play an important role ing, and were adopted with new technology. purpose of classifying the inserted defects
in the software development organizations as Furthermore, there are different studies in reports in a step by step method for more
they can store historical information about classifying bugs in a step by step method to enhancement of the software quality.
defects. There are many research in defect have clear perception and applicable method Key words: bugs, defects, bug tracking systems.
1. introduction
systems and its relation with soft- development process such as: quality
In many software development ware quality from different perspec- control, quality improvement, and
organizations, bug tracking systems tives (section 2). The Paper starts quality assurance. The Institute of
play an important role as they allow with a theoretical overview of dif- Electrical and Electronics Engineers
different types of users communi- ferent aspects of defects tracking (IEEE),  defined software quality as
cating with each other (i.e. devel- models and their components. Be- “the degree to which a system, com-
opers; testers and customers ) to as- sides, it illustrates the shortcomings ponent or process meets specified
sure that they have the same percep- of these models (section 3). The ex- requirements and customer (user)
tion about problems or requesting isting attempts to improve the defects needs (expectations) “(13). Moreover,
new features (1-10). In addition, bug tracking systems are highlighted in Quality Control was defined as “A
tracking systems can keep track of our synthesizing framework (section process in which the product is exam-
more historical information stored of 4). The paper ends with a conceptual ined and evaluated against the orig-
the bugs; and also software require- model for defect tracking system (sec- inal requirements expressed by the
ments requests to learn from the pre- tion 5), followed by section summary customer. The detected problems are
vious bugs through the maintenance of (section 6). then corrected” (16).
or the development process of the There are many software tools that
2. defect tracking systems
software systems (11-19). Earlier at- play an important role in tracking
and tHeir relations witH
tempts were made for understanding defects of software and which are
tHe software Quality
the way of filtering and classifying called “Defects Tracking Systems”.
inputting data for bugs with a struc- This section aims at providing a de- Jalbert defined them as “Allow users
tured way for easy use in tracking de- tailed discussion of the background to report, describe, track, classify and
fects later (5); (10); (19); (20) and (21- overviews about defects tracking sys- comment on bugs reports and fea-
30). However, most bug tracking sys- tems. It deals with the importance of ture requests” (14).
tems are far from perfect (17). the defects tracking systems and their Defects Tracking Systems can be
This paper provides new proposed relations with the Software Quality separated systems that can integrate,
defects tracking model concentrating Control; also it explores the different and contribute in software develop-
on the factors for the insertion of de- views of the defects tracking models ment process. Lethbridge, Singer
fects reports through tracking tools. and systems. and Forward indicated that devel-
In addition, it provides an overview Software Quality have a different opers view the defects tracking sys-
of the literature on defects tracking aspects that influence the software tems as important repositories of
aCTa inFOrM MeD. 2013 Jun; 21(2): 103-108 / Original paper
104 A Proposed Defect Tracking Model for Classifying the Inserted Defect Reports to Enhance Software Quality Control
historical information (20). Further- positions, the proposed stage and who should check it as the defect may
more, software defects data is an im- the active stage (22). There were no not exists only in a new project pro-
portant source to the organizations remarks about how to examine and cess, but also may exists at the main-
for the software process improve- register the bugs. tenance process.
ment decisions and that “ignoring Edwards et al. (2006), proposed the
4. syntHesis model for tHe
defected data, can lead to serious Full Product Life Cycle Defect (FPLC)
classification of tHe
consequences for an organizational Model, which was an extension of
Bugs
business” [10]. In addition “they may IBM/Rational Model with changes to
be part of an integrated suite of con- include the test and project manage- The last section discussed the
figuration management tools, where ment interfaces. The model discussed different overviews of the defects
the status of the defect may act as a in details, the five statuses of the de- tracking systems. Their workflow
trigger or key for other events within fects tracking model which are: Sub- models, the status and paths of the
the system” (1). mitted, Open, Postponed, Resolved defects through the process of discov-
There is no doubt that software and Closed. Although the model ering the defect. Also, it mentioned
quality which is used in detecting de- mentioned perfectly the duplication the literature reviews of different re-
fects, is one of the important factors problem of defects; it still has some search at the same point that dealing
for evaluating the software process remarkable scope for more enhance- with defects. The proposed model
development. Weinberg (1983) docu- ments. concerned with the following two
mented that an error costing a com- The research dealt with the status points: First the different classifica-
pany 1.6 billion dollars, and was the “reject” as not a closed status. It tions of the bugs; and second is the
result of changing a single character coped with it as a circulating process tracking history of the defect that
in a line of code (30). Also, Curhan where it should be a “Closed” status. was discovered. This section covers
mentioned that “some types of de- Also another remarkable note about discussing the proposed model and
fects have a much higher costs to fix the postponed defect, Edwards et al. how it makes classification of the
due to the customer impact and the (2006), reported that “Placing any de- bugs. We divided the classification
time needed to fix them, or the wide fect in a Postponed status is a tacit and track of the bugs into the fol-
distribution of the software in which admission that it should be repaired, lowing Phases: (Submission – Exam-
they are embedded “ (5). but at a later time.” (6) which means ination – Registration – Tracking)
that it has the priority to be repaired which interact with each other and
3. tHe different aspects
not to be a closed. will be discussed in more details in
of tHe defects tracking
One of the famous defects tracking the next paragraphs.
models and tHeir
tools used by quality control engi-
sHortcomings neers is Bugzilla defects tracking 4.1. the submission phase:
Defects Tracking Systems can be separated systems that can integrate, and contribute in software development process.
Lethbridge, Singer and Forward indiThcateed thSaot dftevweloapreers vTierwa cthke idnefgec tsT toraocklisn g asyrsete mss yass timepmort.a nTht reepo switooriersk o ffl ow of the model The first phase of our defects
historical information [20]. Furthseirmmorpe,l yso bftwuairelt d befaecstse dda toa nis adne ifmepcorttsan tt rsaoucrkcei nto gth e osrhgaoniwzateiodn st fhora tth ei ts ocftlwaasrse ified the new bugs tracking model will help us in under-
process improvement decisions and that “ignoring defected data, can lead to serious consequences for an organizational
business” [10]. In addition "they mmayo bde epalrst .o fF anig inutergera te1d sbuietel oofw co nrfieguprarteiosne mnatnsa geam enit ntotools, wthheree thef ostlaltuosw of itnheg two categories: standing the filtration process of the
defect may act as a trigger or key for other events within the system" [1].
simple defect tracking model. Ed- the first one comes from a user with bugs in the submission phase. The
There is no doubt that software quality which is used in detecting defects, is one of the important factors for evaluating the
software process development. Wweinabredrgs ( 1a98n3d) d oScutmeienntkede t h(a2t a0n 0er6ro)r csoismtinpg lay c odmipsa-ny 1a.6 cbiollinonfi dromllaras,t ainodn w arsi tgheh t, and the second role of this model in tracking bugs,
result of changing a single character in a line of code [30]. Also, Curhan mentioned that "some types of defects have a much
higher costs to fix due to the cusctoumsesr eimdp actth aend tdhee tfiemce tnse edterda tco kfixin thgem ,m oro thde ewli,d e dcisotrmibuetiosn forf othme s oaftwnayre uins er but it will not starts after discovering an incorrect
which they are embedded " [5]. as they divided it into the following be confirmed till it has enough votes. action or value to the system. De-
two stages: ((repair/ resolution)- Also, it concentrated on quality con- scribing and stating the problem is a
3. The Different Aspects of the Defects Tracking Models and their Shortcomings
(verification)) and the following trol engineer roles in checking the significant component for retrieving
The Software Tracking Tools aret hsimrepley bcuhilta bnasgede osn odeff escttsa ttraucksi:n g( dmoisdcelos. vFeigruyre 1– beloawp preprroespenrtisa at seim spolel udetfieoctn which being sat- a suitable solution. Stimson (1998)
tracking model. Edwards and Steinke (2006) simply discussed the defects tracking model, as they divided it into the
following two stages: ((repair /rersoelsutoiolnv)-e(vde r–ifi ccaltioons)e) dan)d (t6he) .following three changes of stiastfiuse: (ddi,s cvoveerryi fi– eredso, lvceldo –s ed or didn’t con- mentioned that “A problem well-
closed) [6].
form with the solution (15). stated is half-solved” (27), this push us
Although the IBM Rational Clear to define of who discovered the bug,
Quest Ticket mentioned the work- and when it is discovered.
MiFcigruroe 1s: oThfte t woT steagaesm of t he SDeyfesctt Termackisng Muodseel [d6] a flow that defect process has taken, There are two different groups of
four-stage defects tracking model for and which “Starts when the defect users who can discover the presence
Microsoft Team Systems used a four-stage defects tracking model for Capability Maturity Model Integration (CMMI); the
model expanded and evolved theC "oappena"b stialgiet yin toM thae tfoullroiwtiyng Mtwoo sdtageels : I"pnrotpeogserda" -andi s"a cdtivise"c ostavgee.r Aedlth oaunghd th ee nds when the de- bugs. The first Group is: “The Normal
model enhanced the three- stage defects tracking model, it still works as a framework describing the status and phases of
tion (CMMI); the model expanded fect is resolved, hopefully repaired, User” who deals with the system after
bugs that should followed. The three statuses (deferred – rejected – duplicate) duplicated through two positions, the proposed
stage and the active stage [22]. Thaenre dw eerev nool rvemedark ts habeo u“t ohopwe tno ”ex asmtainge ean idn retgois ttehr tehe bufgos.r the most immediate release of the released to him. The second Group
Edwards et al. (2006), proposed the Full Product Life Cycle Defect (FPLC) Model, which was an extension of IBM/Rational
following two stages: “proposed” and software application” (15). It still has is: “The Authorized User” who par-
Model with changes to include the test and project management interfaces. The model discussed in details, the five statuses
of the defects tracking model whi“cah cartei:v Seu”bm isttteadg, Oep.e nA, Plotshtpoonuedg, hRe stohlveed amnd oCdloseeld . Asltohomugeh thseh moordtecl ommentiionnegds as the “rejected” ticipates at any phase of the develop-
perfectly the duplication problem of defects; it still has some remarkable scope for more enhancements.
The research dealt with the statuse "nrehjecat"n acs enodt a ctlhoseed sttahturs.e Iet c- opsedt awgiteh it ads ea fceirccutlsa tings tparotcuesss wchoerue iltd sh obuled bae ta any state. It may ment process.
“Closed” status. Also another remtraarkcabklei nnogte ambouot dthee lp,o stipto nesdt idlelf ecwt, Eodrwkarsd s aets a l.a (2 00b6)e, r eapoftrteedr thiant "vPelasctinigg aantyi on, the approved Section (3), discussed a number
defect in a Postponed status is a tacit admission that it should be repaired, but at a later time." [6] which means that it has the
priority to be repaired not to be a fclroasemd. ework describing the status and state or after the task opened and in of different defects tracking models;
One of the famous defects tracking tools used by quality control engineers is Bugzilla defects tracking system. The work flow
phases of bugs that should followed. all the cases, it should be closed. Also where there were a number of these
of the model showed that it classified the new bugs into the following two categories: the first one comes from a user with a
confirmation right, and the secoThnd ceo mthesr feroem s taanyt uusseer sb u(dt iet fweirllr neodt b–e rceonjfeircmteedd ti ll itt hheas aepnopugrho vvoeteds. sAtlasot,u its should be one of models which coped with “the sub-
concentrated on quality control engineer roles in checking the appropriate solution which being satisfied, verified, closed or
didn’t conform with the solution [–15 ]d. uplicate) duplicated through two the roles of quality control engineer; mission phase” as the first step of clas-
Although the IBM Rational Clear Quest Ticket mentioned the workflow that defect process has taken, and which "Starts
when the defect is discovered and ends when the defect is resolved, hopefully repaired, for the most immediate release of the
software application" [15]. It still has some shortcomings as the "rejected" status could be at any state. It may be after
Figuinrvee 1st:i gTahtei otnw,o t hseta agpepsr oofv ethde s Dtaetfee Ocotrr Tarifagtecrik nitnhage lMta opsdkae olp p[6ee]nred / aandC Tina a liln thFeO crasMes, Mit eshDou. l2d 0be1 3cl oJsuedn. A; l2so1 (th2e) :a p1p0ro3v-e1d0 s8tatus
should be one of the roles of quality control engineer; who should check it as the defect may not exists only in a new project
process, but also may exists at the maintenance process.
2
A Proposed Defect Tracking Model for Classifying the Inserted Defect Reports to Enhance Software Quality Control 105
sifying defect reports. The adapted sponsibility was to detect, store and schemes of previously works.
one with our model was “Bugzilla check the appeared faults in the da- Although there are large number
tickets workflow”. Bugzilla Workflow tabase. Also the important role of of research on classification of de-
Model, classified the detectors of the triage team mentioned by Black fects schemes, they faced a number of
bugs into two categories: (1999), who assured that the triage problems including ambiguous, and
• Anyone who has enough votes. team can review, evaluate the defects confusion of error causes (23).
• A user with confirmation rights. and assigning them to the develop- One of the first works for classi-
According to the classification of ment team (3). For more information fying defects, was made by Endres in
users in Bugzilla Workflow Model, in details about triage team see (21). 1973 of IBM. He classified the defects
we will classify the users into three Bug examination phase is the last into six general categories including:
categories: phase of deciding whether either the Machine Error, User Error, and Doc-
• Authorized user with confirma- bug was registered before with a suit- umentation Error. Also, he classified
tion rights. able solution, or it will be a new one. each defect by ‘type’. But this type of
• Trusted User. The last statement lead us into the fol- classification scheme was very com-
• Normal User. lowing three states after check the da- plex (7).
The first Category: (Authorized tabase recorded history such as:- According to Basili, and Perri-
User) who is discovering the bugs in- • Bug not found and not registered cone’s categories, the error classified
side the location of the development before. as one of the following Categories:
process. He may be one of the soft- • Bug found and resolved before. Requirements incorrect, Functional
ware development process partici- • Bug found with the same condi- Specification misinterpreted, a design
pants. The second category: (Trusted tion and need to be in (reopened error which spans several modules,
User), who can be defined as the user state). an implementation error in a single
who has the ability, and good experi- The first point will be discussed module, misunderstanding of the ex-
ence for dealing with the product or in more details, in the next section ternal environment, error in the use
system; also has a recorded history of as it will be the default path even if of compiler, clerical error, and error
detecting bugs. The third category: it achieved the two conditions: “not due to previous wrong correction of
(Normal User) who has the ability found” and “not registered before”. an error (2).
but little experience for dealing with The second and the third points are Another work was made by Sul-
the product or system, and has short the core elements in the examination livan and Chillarege (1992) to ana-
recorded history of detecting bugs. phase as there is no need to move to lyze the different error classifications.
That is, the Normal User has the the next phase of registering with They made their work based on de-
ability to inform the presence of a an already existing bug. The second fects reported at customer sites in
bug but hasn’t the priority element point is that such a bug already exist two large IBM database management
without a confirmation of an “Autho- and has a suitable solution for it; so products, DB2 and IMS. They com-
rized User”. there is no need to fill the database pared the errors type; defects type
with duplication of data, but what and error triggers classifications (28).
4.2. the examination phase: will happen if the bug is re-iterated Fredericks and Basili (1998) made
The examination phase begins with the same condition of the test analysis to find defects and how or-
after the end of the submission phase. case scenario?. ganizations dealt with it. They fo-
In this phase, the user decides that The last question leads to the third cused on achieving three goals that
there is a real presence for a defect. point that the bug has recorded ac- can be defined as significance fac-
This phase has its own priority as tions before closed. This point was tors of building a new defect tracking
Hooimeijer and Weimer (2007) doc- achieved by following different test models. These goals are: Detecting
umented that “Bug report triage and case scenarios, and confirmation that the Nature of Defects; Detecting the
evaluation are the significant part there was a bug with the same con- Location of Defects, and when the
of modern software engineering for ditions registered before. Therefore, a Defects are Inserted.
many large projects” (11). It is the first “reopen state” can be released by an In the early 1990’s, IBM developed
phase of preventing the distortion of authorized user in the examination two new Technologies using defects
registering un-wanted data or dupli- phase in order to prevent duplication data. The First Technology: “Defect
cation of bugs by checking the data- defect reports. Prevention”, which involves develop-
base for registered bugs before. ment teams contributing to a knowl-
According to the work and efforts 4.3. the registration phase: edge database containing: common
made by Mays, Jones, Holloway and The registration phase follows the defects, how they can be prevented,
Studinski, at IBM 1990 for defects examination phase. It is important and how to easily detect them. The
prevention. They analyzed the faults for retrieving useful information Second Technology: “Orthogonal
that appeared using casual analysis. in the future because there are dif- Defect Classification”, which involves
In addition, detecting the way of pre- ferent factors for classifying defects using statistical methods to predict
vents defects from appearing again. reports which were registered in this the phase in which a defect origi-
They showed the role and impor- phase. The next paragraphs, will dis- nated, rather than relying on the sub-
tance of the action team whose re- cuss different classification of defects jective evaluation of an engineer (8).
aCTa inFOrM MeD. 2013 Jun; 21(2): 103-108 / Original paper
106 A Proposed Defect Tracking Model for Classifying the Inserted Defect Reports to Enhance Software Quality Control
The Defect Tracking Bug Type Meaning
Model had evolved at Errors visually appear in the
1 Interface Errors
the end of the nineties; user interface.
the Defects Classification Calculation Errors appear in such areas
2 that had some calculations
Scheme shown in Figure Errors
done before.
(2) was used.
Errors appear in loading data
According to the work 3 Loading Errors that take much more normal
made by Mays et al., at time in response
IBM 1990 on defects pre- Errors appear in the general
4 Security Errors imbalance in privileges and
vention; they concen-
rules for each user.
trated on how to prevent
Errors appear based on the
defects from appearing
various variations between
again. They classified the Documentation different systems and
errors that appeared into FigureF 2ig: uHreew 2le:t t H-Peawcklaerttd- PDaecfekcatr dC aDteegfoercitz aCtiaotne gSocrhiezmatei o[2n6 S]cheme [26] 5 Errors. documentations or between
the documentation’s versions
four categories as summa- termined by, in which stage the bug
According to the work made by Mays et al., at IBM 1990 on defects prevention; they concentrated on how to preitvseelnf.t defects
rized in table 1. appeared or discovered; and in which
from appearing again. They classified the errors that appeared into four categories as summarized in table1. Enhancement errors appear
AccorAdicncgo rtod inRgu st o(2 R00u2s) , (2a0 0de2f)e, cat dcleafsescifty inpgl ascceh eimn at hwea ss ydsetevmelo pite da papneda ruesded. Fbryy IBM cEanlhlaendc em“Oenrt thogwohnean lt heDree ifse ac tn eed to
6
Clacslsaifsisciaftyiionng”. Its cdhefeimnead asw a"As dmeevaesluorepmeden t a cnodnc Wepet i mfoer r s(o2f0tw10a)r ed e dfienveeldo pfamuelnt tl o tchaatl - uses thEer rdoresf.ect streamen ahsa nac es toauskr cine p erformance
of iannfodr musaetido nb oyn I BthMe pcraoldleudct “ Oanrdt h tohge o dneavle loipzmateinotn parso: c“eThss e" [t2a6s]k. Hofe ddeivteidremd iint iinntgo itfw o classes of defect aotrt rriebspuotnesse:. the
FirDst eCfleacsts aCssloacsisaitfiecda wtiiothn ”th. eI dt efdeecfit ndiesdco vaesr y aan pdr coognrtaamine odr t hceo delee mfreangtsm: (eanctt icvoitny,t atriinggs er, and impact). The STehecsoen bdu gCs ltahasts appear
associated with the defect removal and contained the elements: (target, defect type, qualifier, sourcBeu, sainnedss a Lgoegi)c. when a rule or business logic
“A measurement concept for soft- a defect, and if so, locating exactly 7
Errors . is Inconsistent with another
ware development that u ses thCea tdegeo-ry where that defecWt hraets iitd mees”an (s9 ). As we one.
fect stream as a source 1o f Oinvfeorsrimghat - attempt to enThhae nced ethveelo qpeur alitydi dc on-notT able 2: The Proposed Defects Classification Scheme
tion on the product and the devel- trol in the softcwomaprlee,t ewlye hacvoen stiode rr ecosgo-me
details of the problem.
opment process “(26). He divided it nize different phases of the software 4.4. the tracking phase:
into two classes of defect attributes: development such as: Analysis, De- This phase is concerned with the
the First Class associated w2 itEhd tuhcaet idone - sign, Testing aTnhde Madienvteelonpaenr ce. dAidt then ott raceability of the defects that were
understand the process because
fect discovery and contained the ele- research conteoxf tla, cwk eof wtrailinl icngo ninc tehnatt raraetae. registered in the system before. There
3 Communications Failure Information was communicated
ments: (activity, trigger, and impact). only on the phases: (Maintenance were a number of scenarios expected
incorrectly and thus not
The Second Class associated with the and Testing).u nFduerrstthooedr mproopreer,l y.a nother from the proposed model to achieve.
defect removal and contained the ele- element of describing the location of One of these scenarios is the tradi-
4 Transcription Error A typographical error or other
ments: (target, defect type, qualifier, bugs is to descmriisbtaek ew whheirceh twhaes bmuagde w bay st het ional scenario which is searching a
developer.
source, and age). discovered through the system. Also new defect which is then classified

we have to describe the surrounding and will be on the first status which
Category What it means
Table 1: Defects Classification Scheme [8]
environment of the system as an ele- is “Initial Phase”.
The developer did not
With the last different views of the defects classification schemes, it appeared that there were a number of factors that
1 oversight completely consider some ment in classifying the location of the At this stage, the development en-
describe the defects, and these factors are so important. We will concentrate on the following two Factors "Bug Location"
details of the problem. bugs such the version of the system, gineer who is responsible for fixing
and "Bug Type" that are seen on the degree of importance from quality control perspective.
The developer did not the kind of operating system that the such defect starts to work under the

21- EdTuhcaet iFonirst Eulnedmersetnant d itsh e" Bpruocge sLs obeccaatuisoen ":-s ystem works under. status: “under development” with a
of lack of training in that area.
The Second Element is “Bug new date recorded of the beginning
The locations of the bugs are determined by, in which stage the bug appeared or discovered; and in which place in the system
it ap3peaCroemdm. u Fnircya- anIidnn fcoWorrmreeacittmiloyn ea rwn da( s2th c0uo1sm 0nmo)tu dniecfaitnede d faTuyltp leo”c:a-lization as: "The task of determiningo iff tah ep rdogervaemlo porm ceondet pfrraogcmeesns.t After the
containsti oan sd feafielucrte, anudnd iefrs stooo,d lporocpaetrilny.g exactly whereTh thea t ‘dBeufegc t Treyspidee’s "v [a9r]i.e As sf rwoem a tteomnpet tod eevnehlaonpcme tehne tq puarloitcye scso notrfo tl hine defect is
the software, we have to recognize different pshyassteesm of ttohe asnofottwhaerre dbeevcealoupsme etnht es udchif -as:fi Annisahlyesdis,, iDtse ssitgantu, sT ecshtianngg aensd t o “devel-
A typographical error or other
MaintenTaranncsecr.i pAtiotn the research context, we willf ecroenncet nttroatoe lso nlwy hoinc hth ew pehraes esu: s(eMda inttoe naoncpem aenndt Tceostminpg)le. tFeudr”th ewrmitohr er, espect to
4 mistake which was made by the
another Eerrloerment of ddeevsecloripberi.ng the location of bucgrse iast eto sduecshcr isbyes wtehmerse, thhea vbeu gt hweaisr doiswconv erreedc tohrrdouinghg tdhea tsey sotef mfi.n Aislshoi nwge this pro-
limitations and shortcomings [18]. cess. With small calculations of dates
Table 1: Defects Classification Scheme [8]
However, we have to put a dynamic between “Under Development” and
With the last different views of the framework for defining the bug type “Development Completed”, we can
defects classification schemes, it ap- according to the various tools used measure how much time it took the
peared that there were a number of to build the systems; with respect to development team to fix this defect.
factors that describe the defects, and the major general bug type. Table (2) Hooimeijer et al., documented that
5
these factors are so important. We shows the major proposed defects Bugs fixing is a time-consuming pro-
will concentrate on the following types that may appear in any system cess, with half of all the fixed defects
two Factors “Bug Location” and “Bug and based on Sullivan et al., 1992 in Mozilla requiring over 29 days
Type” that are seen on the degree of work who classified the Software De- from start to finish date (11).
importance from quality control per- fects Type as: function defect, data After the status “Development
spective. structure/algorithm defect, assign- Completed” is finished, a Regression
The First Element is “Bug Loca- ment/checking defect, interface de- Test Phase is going to achieve. When
tion”:- fect, timing/synchronization defect, finishing all test cases and scenarios
The locations of the bugs are de- and build/package/merge defect [28]. for the defects, the quality control en-
Original paper / aCTa inFOrM MeD. 2013 Jun; 21(2): 103-108
A Proposed Defect Tracking Model for Classifying the Inserted Defect Reports to Enhance Software Quality Control 107
gineers release the status “Test Com- sumes over 70% of the
plete” then the status “Closed” for total life cycle cost of the
finishing the scenario. software development
The last scenario showed different projects (4). Also, the pro-
status which defect moves through posed model which tends
it, concerning the time element that to evaluate the tracking
recoded before and recording every system, gives real histor-
change on defect status, as mentioned ical information about
by Tammana and Faught (1998) “A de- bugs recorded. The model
fect tracking system that lets the user developed was based on

query the defect database is useful the previous work of (6),
Figure 3: Proposed Defect Tracking Model
not only to generate summary re- (15) and on our general Figure 3: Proposed Defect Tracking Model
ports, but also to track the status and synthesized model for classifying and cussed models concentrated on the
the progress of a project that’s un- tracking defects (section 3 & 4). It is tracking phases of defects without
derway” (29). Therefore, through the quite suitable for a case study. This caring of the classification factors of
6. Summary
power of DBMS (data base manage- model will guide us through our ex- the defects. Furthermore, there were
ment system), we can achieve a good Thpislo Praatpieorn d feoscrr icbleads sitefircmast ioannd offi nddeinfegcs tsf romdi ffsiegrneinfitc adnitr eecatriloienr sr eosfe aprrcehv, etnhteirnebgy d feo-rming a conceptual context and
tracking of defects through this last fotuon daetniohna fnocr et heq uexapliltoyra tcooryn otrbosel rvfaotrio ntahle s tufdeyc tthsa at nisd c ecnlatrsasli fitoc athtiiso rne soefa rbcuh.g sT ihne vfiarsrt- part was a discussion of different
perspectives of what translated a subtle relation between, on the one hand, defect tracking systems and its relation with the
scenario. software development and mainte- ious models, in chronological order.
software quality and, on the other hand, different classifications of defects with phases of their tracking and shortcomings of
The Following Table, Abbreviated nance processes.
these models.
references
the different status of tracking sce- Our model will focus, in details,
The last section described the various models of the defect classifications coupled with the illustration of these models
narios that the defects take through shoorntc othmein gpsh. aIst ews aos fa rpgrueevde nthtaitn tgh ed perfeevcitosu sl1y. disAcuvsrsaemd mGo, dSehlse echoannc eAnt,r aStueldl ivoann t hDeK tr, acking phases of defects without
different phases of the product devel-caarinndg ocfl athsesi fcylainssgif ictahtieomn .f aThctoers ocfo nthcee pd-efects. FDuertfheecrtm Torraec, kthinegre Swyestreem dsif fienre nGt ldoibre-ctions of preventing defects and
opment phases and whose responsi-clatsusaifli cfartiaomn oefw bourgks info vra rciolauss smifoydinelgs, iann cdh ronologaicl aSl ooftrdwera.r e Development – a work

bility to check. tracking defects as shown in Figure practice study, Limerick, Ireland,
References
(3), shows that the tracking system 2007: 3.
Status Responsibility [1] Gabriela Avram, Anne Sheehan and Daniel K. Sullivan, Defect Tracking Systems in Global Software Development – a work practice
gisvtuedsy ,r Leiamle rhiciks,t oIrreilacnadl, 2in00f7o, rPm3. ation for 2. Basili VR, Perricone BT. Software
1 Initial Quality Team
[2]m Vaicitnotr aRin. Binasgil i,t ahned Bbaurrgy sT . tPherroricuognhe, Stohftew are ErroErrs raonrds Caonmdp Clexoimty:p Alenx iEtym: pAirinca El Imnvpeisrtii-gation, Communications of the ACM,
2 Under Development Development Team 1984, P.42-52.
development life cycle. Moreover, it cal Investigation, Communications
Development Development team [3] Rex Black, Managing the Testing Process, Wiley, 1999.
3 Complete leader [4]c Boanrcrye nBotreahmte sa ndo Vne cttohr eR . bBuasgil i, eSxoaftmwairne aD-efect Redouf ctthioen ATCopM 10. 1L9i8st4, :2 4020-15,2 p..135–137.
4 Under Test Quality Team [5]t ioLinsa, lAo.c aCtuiorhnan a, nSdof ttwyapree fDaecfteoctr sT froacrk tinhge du3ri.n g NBleawc kP Rro.d uMcta nDaegvienlogp mtheen t Toefs tCinogm pPurtoe-r System, Massachusetts institute of
technology, 2005.
5 Test Complete Quality Team Leader insertion process of defect reports. cess, Wiley, 1999.
[6] Jim Nindel-Edwards and Gerhard Steinke, A Full Life Cycle Defect Process Model That Supports Defect Tracking, Software Product
6 User Acceptance Users and Quality DCuyec lteos, Athned Theisgt hItleyra teioxnpsl,o Croamtomruyn incaattiounrse o f t4he. IIMBAo,e Vhmolu mBe, 6B Iasssiulei 1V, R20.0 6S,o Pft1w-1a4r. e De-
Test Complete team leader [7]o fA ltbheirts Esntudrdesy,, aanl lA insaolylasitse dof cEornrocrse pantud aTlh eir Caufseecst inR eSdyustcetmio Pnr oTgroapm s1, 0P rLocieste,d in2g0s0: 1I: nternational Conference on Reliable
7 Closed Project Manager vaSroifatwbalrees, /1fa97c5t,o Pr3s2 7o-3n3l6y. represent the 135–137.
8 Need more Details Development Team [8] Michael Fredericks and Victor Basili , A State-of-the-Art-Report for Using Defect Tracking and Analysis to Improve Software Quality ,
inDiotiDa lD aidtae &a sA naablyosuist Ctehntee r dfoirs cSuofstswioarne (DoAf CS5)., 19C98u, rPh3a-1n8 .L A. Software Defect Track-
Project Manager
[9]d Zeafcehcatrsy tPr.a Fcrky ianngd Wphesatlseeys W aenimd ecr,l aas Hsiufimcaan- Study ofi nFgau ldt uLroicnagli zaNtieown A Pccruordacuyc,t 2 0D1e0v. elop-
9 Postponed Development Team
Leader [10ti] oRno bmerte Bt.h Gordad yto, S odfetwaal rew Fiatihlu rien A nthaleys ifsu f-or High-Rmeteunrnt Porof ceCsso Immppruotveerm eSnyt sDteecmis,i onMs, aHs-ewlett-Packard Journal, 1996, 47(4).
[11] Pieter Hooimeijer and Westley Weimer, Modeling Bug Report Quality, In Automated Software Engineering, 2007, P 34–43.
Development Team [12tu] IrBeM. ® Rational® ClearQuest® Deployment Kit, Usagsea Mchoudesel tGtsu idienlisnteitsu, Vtee rsoifo n t1e.c1h, Jnaonl.,o 2g0y0, 5, p. 4.
10 Refused
leader [13] IEEE, IEEE Std. 610.12: Standard Glossary of So2ft0w0a5re. Engineering Terminology. The Institute of Electrical and Electronics
11 Reopen Quality team leader 6E. ncgionenercs,l Nuews Yioornk, NY, USA, 1990. 6. Nindel-Edwards J, Steinke G. A Full
[14] Nicholas Jalbert and Westley Weimer, Automated Duplicate Detection for Bug Tracking Systems, IEEE, 2008, P 52-60.
Table 3: Proposed Defect status Scheme [15] JiThří Jiasn ákP,a Ipsseure Tdraecskcinrgib Seydst emtesr, mBrsn o,a snprdin g, 2009L. ife Cycle Defect Process Model
[16fi]n Jodsienpgh sM .f rJuorman , Jsuigrann'isfi Qcuaanlitty eCaornltireorl Hraen-dbook, MThcGarta wSu-Hpipllo, r1t9s8 D8. efect Tracking, Soft-
5. conceptual framework [17s]e aSarscchh,a tJhusetr, eRbahyu fl oPrremmirnajg a nad cTohnomceasp Ztuimaml ermann,w Taorwe aPrdrso tdhue cNte Cxty Gcelense,r aAtionnd o Tf eBsutg I Tterra-cking Systems, IEEE, 2008, P82-85.
design for tHe proposed [18] Andrew J. KO and Brad A. Myers, Development and Evaluation of a Model of Programming Errors, IEEE, 2003, P7-14.
context and foundation for the ex- ations, Communications of the II-
defects tracking model
ploratory observational study that is MA. 2006; 6(1): 1-14.
Based on the previous discussions central to this research. The first part 7. Endres A. An Analysis of Errors and
in sections 1, 2&3 and that derived was a discussion of different perspec- Their Causes in System Programs,
from the development of the research tives of what translated a subtle rela- Proceedings: International Confer-
synthesis model for different ways of tion between, on the one hand, de- ence on Reliable Software, 1975: 327-
defect classifications that were pre- fect tracking systems and its relation 336. 8
sented in the preceding section, the with the software quality and, on the 8. Fredericks M, Basili V. A State-
ultimate conceptual model is given other hand, different classifications of of-the-Art-Report for Using De-
in Figure (3). The present research defects with phases of their tracking fect Tracking and Analysis to Im-
adopts the following model for clas- and shortcomings of these models. prove Software Quality , DoD Da-
sifying bugs which appear through The last section described the var- ta & Analysis Center for Software
different development phases espe- ious models of the defect classifica- (DACS), 1998: 3-18.
cially in the maintenance and testing tions coupled with the illustration 9. Fry ZP, Weimer W. A Human Study
phases. As mentioned by Boehm and of these models shortcomings. It of Fault Localization Accuracy, 2010.
Basili, the maintenance phase con- was argued that the previously dis- 10. Grady RB. Software Failure Analysis
aCTa inFOrM MeD. 2013 Jun; 21(2): 103-108 / Original paper
108 A Proposed Defect Tracking Model for Classifying the Inserted Defect Reports to Enhance Software Quality Control
for High-Return Process Improve- Evaluation of a Model of Program- 24. Ostrand TJ, Weyuker EJ. A Tool for
ment Decisions, Hewlett-Packard ming Errors, IEEE, 2003: 7-14. Mining Defect-Tracking Systems to
Journal, 1996: 47(4). 19. R.B. Lenin, R. B. Govindan and S. Predict Fault-Prone Files, 1st Inter-
11. Hoimeijer P, Weimer W. Modeling Ramaswamy, Predicting Bugs in national Workshop on Mining Soft-
Bug Report Quality, In Automated Distributed Large Scale Software ware Repositories, United kingdom,
Software Engineering. 2007: 34–43. Systems Development, SCS M&S 2004: 85-89.
12. IBM® Rational® ClearQuest® De- Magazine, 2010: 1-5. 25. Pfleeger, and Shari Lawrence. Soft-
ployment Kit, Usage Model Guide- 20. Lethbridge TC, Singer J, Forward A. ware engineering theory and prac-
lines, Version 1.1, Jan., 2005: 4. How Software Engineers Use Docu- tice upper saddel river, NJ prentice
13. IEEE, IEEE Std. 610.12: Standard mentation: The State of the Practice, hall, 1998.
Glossary of Software Engineering IEEE Software. 2003; 20(6): 35-39. 26. Rus J. Combining Process Simula-
Terminology. The Institute of Elec- 21. R.G. Mays, C. L. Jones, G. J. Hollo- tion and Orthogonal Defect Classi-
trical and Electronics Engineers, way and D. P. Studinski, Experienc- fication for Improving Software De-
New York, NY, USA, 1990. es with Defect Prevention, IBM Sys- pendability, Chillarege Press, 2002:
14. Jalbert N, Weimer W. Automated tems Journal. 1990; 29(1): 4-32. 1-2.
Duplicate Detection for Bug Track- 22. Process Guidance documentation 27. Stimson C. The Quality Improve-
ing Systems, IEEE, 2008: 52-60. provided in the documentation for ment Story, 1998.
15. Janák J. Issue Tracking Systems, Br- Microsoft Visual Studio, 2012, http:// 28. Sullivan M, Chillarege R. A compar-
no, Spring, 2009. msdn.microsoft.com/en-us/library/ ison of Software Defects in Database
16. Juran JM. Juran’s Quality Control ee332488.aspx Management Systems and Operat-
Handbook, McGraw-Hill, 1988. 23. Ostrand TS, Weyuker E. Collecting ing Systems, IEEE, 1992: 475-484 .
17. Just S, Premraj R, Zimmermann T. and Categorizing Software Error 29. Tammana P, Faught D. Software De-
Towards the Next Generation of Bug Data in an Industrial Environment, fect Isolation, 1998: 1-10.
Tracking Systems, IEEE, 2008: 82-85. the Journal of Systems and Software. 30. Weinberg GM. Kill That Code, Info
18. KO AJ, Myers BA. Development and 1984; 4: 289-300. systems. 1983: 49.
Original paper / aCTa inFOrM MeD. 2013 Jun; 21(2): 103-108