Defect Report Chapter 1. Introduction Throughout the design and creation process, a developer may make errors that reveal flaws in the software, After the development phase, a tester's responsibility is to thoroughly test an application to discover as many errors as possible, seeking to identify and rectify all possible defects, in order to deliver to the customer a quality product. When the anticipated results do not match the actual results, it is referred as a defect. The term defect (or fault) is used to describe an entry of erroneous information into software documents. A defect is an error in coding or logic that causes a program to malfunction or to produce incorrect/ unexpected results. In general,a software bug refers to the abnormal behavior of the software. A software bug begins when adefect is found and ends when itis closed after taking steps to ensure it cannot be reproduced. This could be due to errors in the information in the requirements, design, and architecture documents. These discrepancies can become defects with different degrees of severity (complexity) during testing, Software defects are a failure to address these discrepancies that are not identified during the document review. The defect management approach focuses on counting and managing defects and includes misread or misunderstood requirements, problems with logic, timing, validity checking, coding etc. a142 [whan sotvareTexing Tools In software development, defects are typically categorized by severity, and the number in each, ‘category is used for planning, More mature development organizations use metrics such a, defect leakage (for counting the numberof defects that pass through development phases before being detected). tn genera a Software Defector Bu is a condition in a software product which dey inthe requirement speciation) or ender reasonable). {expectation (which may not be specified Type of Detects 1 Logical defects: Ifyou get unexpected results due to wrong instructions, considered as a Topical errr. i, Multithreading defects: When execution of multiple parts of a program accomplished a "He same time, may causes different issues, and fils to complete processes. i, Arithmetic defects: You may encounter bugs such as arithmetic Overflow or Underflow ‘while performing arithmetic calculation. Iv, _ Syntax defects: These defects occur due to grammatical mistakes or misspelled words done in coding. ¥. Performance defects: This defect specifies the performance issue of the code for instance 1 the scope of the function or module goes beyond time and space complexity. vi. Interface defects: It occurs due to missing and incorrect information and wrong functions. 2. Defect Life Cycle Defect lifecycle also referred as bug life cyte in software testing is a speci defector bug goes, thou by the tester and ends. The life eycle varies from organization to organization and is governed by the software testing process (Software Testing Life Cycle) the organization or projet follows and / or the defect tracking tool being used, 2.1 Detect Life Cycle Stages uring the lifecycle ofa defect, it can have the following stases: ‘Status | Alternate Status Open [ New ‘Assigned Dupicate Dropped | Rejected Deterred Fed | Completed Resolved ‘Reassioned ‘Closed | Verified paecrRepot win 43 ‘Reopened Iq Ten Figure 41: States of Bug2 444 [lion sormar Teeig Too i, Open/New: When a defect is logged and posted for the first time. This is considered a, the beginning of a defect’s journey and the name is given as new: Defect is identified vag review ora test and reported. Assigned: The tester’s lead approves the bug and sends it to the developer team once it has, ‘been posted by the tester. The defect can be assigned directly to the developer, who owns the faults functionality, in one of two circumstances. Second, it can be assigned to the Development Lead, who can then forward the defect to the developer when it has been Authorized by the Development Lead, That means a defect is allocated to a person who is responsible for analyzing or resolving it. fii. Duplicate: Ifthe bug is repeated twice or if the two bugs describe the same bug concept, then itis considered as duplicate and i's recentMatest bug status changes to duplicate. In that case, defect is marked as invalid because it's a duplicate of another one already reported. iv. Dropped/Rejected: Developers reject bug reports if they do not feel they are genuine and ‘marked as invalid. There may be various reasons like false positives to drop defect. The state of the report is changed to "dropped / rejected”. ¥. Deferred: In deferred state, the bug is expected to be fixed in the next release. There are many reasons for adding this state tothe bug, for example, the priority of the bug may be low, there may be a lack of time forthe release or the bug may not be a major problem. In ‘other words, when the defect is valid it's decided tobe fied in a future release instead of the current release. When the time comes, the defect is assigned again. vi. Fixed/Resolved/Completed: As soon asthe defect has been “fixed,” its status is changed 1 allow its verification to start due to following reasons: ‘Sometimes it needs more information to analyze and fix the defect such as the exact steps to reproduce. ‘The defect cannot be reproduced for reasons such as change of environment or the defect somehow being already fixed. ‘When the defect cannot be fixed, it can be either assigned to another person who will be able to fix or it can be deferred, or dropped. vii, Reassigned: Defect is reassigned if it is verified that the repaired defect isnot fixed at al, or if it is resolved partially. If tis decided to wait and fix the defect in a furure release, it is deferred. Detar tipot when 45 sii, Closed/Verified: Upon completion of fixing the bug the tester tests the software. If the tester determines that the bug is no longer present in the software, the status ofthe bug is ‘changed to “closed”. This state indicates the bug has been fixed, examined, and approved. DEV request closeimare information DEV fixed the (Avert, fixed Figure 42: Defect Handling Process 3. Classification of Defect Software defects are basicaly classified according 10: i. Severity /Impact ii Probability / Visibility Priority / Urgency iv. Related dimension of Quality ¥. Related module / Component Vi. Phase detected vil, Phase injected L.Severity/Impact: Bug report should include this attribute to decide how quickly a bug should be fixed. Defect severity defines the impact of the bug on the application. It dictates the priorities of when the bug should be fixed.> 446 /wbitn —Sotvare Tesong Toot There are typically 4 types of Severity: ‘Minor: Affects minor functionality or data, May have an easy workaround, }. Major: Affects major functionality or data. May have a workaround but is noe ‘obvious or complicated, © Medium: No affect to functionality or data. Usually, just a major inconvenience ang ‘may not impact productivity or efficiency. 4. Critical: Wt afectscitical functionality or data. This may not have a workaround, Example of High Severity and Low Priority defect: ‘This mixture of bug cause a severe disruption inthe system's functionality, While using online ticket booking software, there would be a defect in reservation functionality ifthe user uses an old version of browser for reservation of tickets, This problem is severe but the number of customers with old browsers is very low, So, it is not a high priority to fix the bug. Hi, Defect Probability: It is also known as defect or Bug visibility or bug, indicates the likelihood of a user encountering the defect bug It can be denoted in percentage (%). @. High: Encountered by all or almost all the users ofthe feature. 1b. Mediu: Encountered by about 50% ofthe users ofthe feature. & —_Low: Encountered by very few users ofthe feature, fii, Priority/Urgency: The importance or urgency of resolving a defect is indicated by defect priority, also known as Bug priority. Though the Software Tester may determine the priority initially, it is usually decided by the Project/ Product Manager. Priority can be defined asthe impact of the bug on the customers’ business, Provty provides the order in ‘which a bug should be resolved There are ypically 3 types of Priority a High b. Medium Low Higher priority bugs should be treated first. The main intemtion is how soon the defect should be fixed. Most of the times the priority status is set based on the customer requirement. % > eect Reson wie 4-7 priority can be categorized into the following levels: i. Urgent: Must be fixed immediately / inthe next build. ii, Highs Must be fixed in any of the upcoming builds but should be included in the release, iii, Medium: May be fixed after the release / inthe next release. jv, Low: May or may not be fixed at al. Priority is also denoted as PI for Urgent, P2 for High and so on. Example of High Priority and Low Severity defect: This combination of bug can’t create a major problem on the functionality ofthe system but needs to solve on high priority. Suppose a Logo on any particular website is wrong, so we can say this bug can be of low severity as it not going to affect the functionality of the system and very easy to fix but ccan be of high priority sit totaly gives wrong information of a website. Related dimension of quality: Software quality has many dimensions/atributes including accessibility, compatibility, concurrency, efficiency, functionality, install ability, localizabilty, maintainability, performance, reliability responsiveness and many more. Related module/eomponent: Related module/component indicates the module or component of the software where the defect was detected. This advises you which module ‘or component is risky or buggy. a. Module/Component A b. Module/Component B . — Module/Component C Phase detected: Phase detected indicates the phase in the software development lifecycle where the defect was identified a Unittestng b. Integration esting €. Systemtestng 4. Acceptance esting48 uh ‘Sofware Tesing Tools Vil, Phase injected: Phase injected always comes before phase detected in the software development lifecycle. Only after a thorough root-cause examination of the bug, Phase injected can be determined. This is the phase where the bug was introduced in the software development lifecycle is indicated by phase injected. 8. Requirements development b. High level design Detailed design Coding © Build / deployment v ‘The usages of categorization vary from organization to organization and It depends on the detect aching too that preted bythe organization, 4. Write Defect Report Defect Report ‘The moment a tester finds a bug or defect, it needs to convey to the developers and is conveyed by using bug reports, issue report, problem report, etc In technical speak, a defect reports a document that identifies and desribes a defect found by “tester, The purpose of a defect report is to make the defect as clear as possible in order for “developers to reproduce it easly Defect repor, also known as Bug report. By definition of ISTQB, defect report is a documentation ofthe occurence, nature, and status of adefect. How fo waite detect report? Quality assurance, developers, and support employees all need 10 be able to write easly unde le, detailed, and complete software defect reports, > net hesen wisn 49 satowing steps shouldbe carried out to write defec repr: Define the defect ‘State the platform and version . Log in and examine data (client, patent, program selected) ._Listany nonstandard configuration stings with values d. State the workflow direction through the aplication ii Finding the root cause papining Me roel oe Retest until you have the exact steps inthe correct order to reproduce the defect b. Define the ho, what. where, when, and how you found the defect c. _ Execute database queries 4 Scan error logs Ihe defect is intermittent, mention as its ii, Add supportive documents T scwentos Video ‘Step recording files peewee Error log data ©. Database query results ix. Format all text for readability an easy understanding Stick toa known and familiar format when possible b. _Listusng bulleted or numbered lists €. Keep textual descriptions succinct and direct 4. Facts only; no opinion, no suggestions, no accusations, no blame Detect Report Template ‘There are many different types of defect tracking tools which, in tum, vary with the elements of ‘defect repor. [A defect report may include one or more of the following elements, depending on which tool as used by the company. Generally, a defect report includes the following elements.a 4-10/ wiitn —Sotvare Test Tos brtecrRepotwhiea\ ett 2 Sample 1 ote 7 “RatoBystom goveraied Detect “Tse the entra vento each doect reas) Project Tame othe proect Fee ofthe Autor: | Accepted rom sytem jPoies__[Wanectteprgest ino) ease [Ec ater Release Version | Retease version ofthe producti he formal 123 | [see Mode Speci module ofthe product wher the defect was detected | ee bat ‘erected rom DTpcker (System generated) Tia Version | Bul version the product where the celct was detected ike 12.95 ‘eenied) Summary (Contains clear and concise summary of the defect heat ‘GA closes , System generated ‘Developer is assi (Require [ont wonbe cis ased =] (08) Deec Descbien [Cont of snp, unarbiguus Bu conpehesve dled descpin e re ae - or Enhancement: | » Defect (Detady ‘Detected on Date | Date when the defects logged one) i: deahanooment [Deteced By Detail the tester who repored the defect ike Name and panen Ties ‘Shot one ine deszripion ‘Steps to Replicate | Step by step description of the way to reproduce the defect. Number the (eauired) a Prablem Description’ | A precise problem descripion with screen shots, ifpossbie Factual Resut “The actual ea you recived when you elowed the stops treaared) pected Rests | The epeced rests. arent Envronments | Eg, Wint 7 Orace ONT Attach any addtional information like screenshots and logs. (Requiced) Remarks: Any additional comments on the defect. “Ciher Environmentis): | E.g., Wint0/ Oracle 4.0 NT_ Detect Probably | Probably of the defect. Detect Type * Funetonaly (Deaut) (Required) © Architectural Detect Severty ‘Severity ofthe detect. + Connectivity Detect Porky Prony othe cetect. + Consistency FReponed By The name ofthe person who reported the defect Database regi | Assigned To _The name of the person that is assigned to analyze/ fix the defect. ‘¢ Documentation Status “The stats ofthe defect. ae {Fixed Build Version | But version ofthe prodet where he deft washed (ag. 12.39) * Memory * Perormance + Secutty and Contls ‘These above specified fields can vary depending upon the project or tool that is used in Standards and Conventions tre rqanzaion + Stress 2. automated too! Is used, then the defects logged can be exported in an excel sheet osetia andcanbe considered dlc repo. Wo betes + Cualty Assurance (Defaut) 3. Delecae logged and acedn Defect Management ol ke ALM QC, H ALM Test (Required) + Exceral Customer Deco 14s Ratna Team Caner te * nema Customer + Development ow Deeted + Tesing(Oetat) Required) + Review Wakehrough JAD.2 4412/nlion sotvae Testo Tos | cetecReor wien 413 Taagred To: Taal aslged a vesiate problem 7 Teron WEW STATUS [X TERORUGEEAY |X equa) Pub vay Oca Priority: © High (Defautt) Private intermittently Occurs Peavey cial * Medium ‘SEVERITY PRIORITY Soa er, Critical Critical ver © High (Default) High High (Roques) cite Tu Tes Nem | Toe + tow San + Open Daa | (uspescnPTON Tape (Requires) + Being Reviewed by Development re + Rotunedby Oovtpment 5 Ready or Tsing ne Not Bud L Gureuion) : ' Jomnnes Sample 4: QA Bug Report Templat + betoreda tn Not Release CPENDATE PROBLEW AREA FROBLEW DESCRIPTION Sas Derotans | (Requred whe) Ste = Rated Dea “Roady rosin th Ni us eT EWARONMENT Fed eared wen) CLOSE DATE FROBLENTALE eo Si Roady or Tsing nthe Now Buk? Panred Fx Bagr | (Reged wher) Sas © ead ox Testing iNet Bu ‘Defect Type | X | Who Detected X | How Detected x Sample 3: Bug report Form template Freon [| Quay ase Te SUBMITTED BY [DATE fens | [era Gate ee enmecviy [| tral Cuter i Consisony Coven OL Database integrity Priority |X = See cia 7 SUMMARY FALE ATTACHMENTS) Documenta Tigh |_| Bing Reviewed by Development Taaaion Tec Tredby Develo saiaon Ton ody esigin te Nex Bd DESCRIPTION OOTTORAL = eae owed (A) |X a Cia Famed (OH Tate Gowen aah | [Defra ne ee Sie Teser|— [Riones To a Usability = SCREENSHOT DEMONSTRATING BUGS BEHAVIOR Tate Deacon [Fea by aed i Bune te a]Wn Software Testing Toots Example 1: Prepare a Bug report having an issue in billing system Bagi [010 Originator | Witane | EnallWilame_rega@radtinalisom | Phone’ Submit Date | 1209-2020 Summary __| Svonit batons vale Severity | fecher| eral major normal minor eval] enhancer) Product | Standalone Bing System ‘Component_| Not aoe Version [13 Piattorn | [PCT Macher os | [Windows | Mac | Linux) Browser | Fretox15} URL inva. corcaritwebporal_ nde RAT Example 2: Bug/Defect report prepared in Excel foron line purchase > Dee Ropot won 415 inpatant Ponts fo be Remember QA or Test lead needs to send daily defect report to showcase testing progress therefore drafing effective defect report is very crucial task. jj. Test lead is responsible to communicate report tothe client in a professional manner. (QA Lead handles the Defect Status Report on a daly or weekly basis. jx. After drafting the mail, Status should be sent to Project Manager, Architect. and All leads like, Developmeti ead, Database lead, or any other team is working in the project. 1, While sending the mail team members should be kept in CC. i Subject of the mail should be more specific and clear to receivers, as in the format: Project Name> Testing Status Report ——— EE ero ‘Steps to reproduce ‘tem image or type item name inthe search bar > add new item to eat via “ad to car button > go to car. Taber Vas Forinstance: Voting System Testing Status Report: 23/02/2022 Dromber [0170 Name ‘Unable to open cart window and add new item to the cart. vii, Defects summary snapshots contains, Tables, Diagrams and Pi Charts to summarize your eponer Moca defees by Status or Priority or Severity as per project demands. Submat Date [21021 sin Sagar | Surmary I vi Mal body should be shor with highligh the isuesachieverents in bullet points and should be vil Cnt re otal atoms Naa Provide a snapshot of the report summary. Detaled Defest Stans, can be send as an UAL ‘ores compurchaseingex hin! atachment or uploaded ona shared drive and share the link alongwith of test ase. ‘Sereershet | ww fasconcompurchasaleenshotOT70 Environment | Plato Mac 0510.4 ik. In some situations the Test Execution Repor also needs to sent tothe manager andor Operating System _| Win 10 client. Browser Maula 7202 opie: Bug deta ‘Open the cart window > inaly add one item to cant >eeect ae pec et | Th a shod mie? eS ee ‘Aetvalresut_| The cat srt accessible H fess meal {tf ‘The customer should able to see description of product as t 4 4 +} 1 ~ ‘well as select product and add into cart one he clicks on add — J Deseroten __| carbon Bug tracking | Severity Major ‘Assigned to Developer ~ Ra Sha Piety ih Notes [ notes nay ler SAS donnerth Ds 4-16/ whan Sober Tesing Tools eet Regen ian 4-17 By Status tT ent Defect Summary Ite fewer x 1 zi 7 Summary fovea F 2 1 foes jae) ea af 1 os = a ot I 7 ‘An imperfection or deficiency in a work product where it does not meet its requirements or specications. Defect Summary By Severity [seis lteter __forteat_|najor_|etoor ormat__ Teta Spet Foret 1a = ieee Levers ees] Talo 24 a F ‘Aprogram that contains a large number of bugs is said to be buggy. ‘Reports detaling defects / bugs in sofware are known as defect reports / bug reports. Applications for tacking defects bugs are known as defect racking ool /bug racking tots. “The process of finding the cause of bugs is known as debuoging “The process of intentionally injecting bugs in sofware program, to estimate test coverage by Test Case Execution Summary —_] ‘monitoring the detection of those bugs, is known as bebuoging [oaitot — Yiotron [rottoes [rot tes oe Pane ta te ‘There are numerous defect management tools to lag defect including ALM QC, HP ALM, Test ‘Sorat we | a o Director and IBM's Rational Team Concer, ‘sernt2 a a 0 =a : 4+ A z Based onthe priory set ofthe defect, the order of fing the defect can be made. o n Gast | 5s |» | a