Preventing Defects in Agile Software Development - Essay Example

of affiliation: Defects in agile software development are nothing but deviations from the expected values. It is logical to think that defects are encountered in the test execution phase and is also worth noting that it should not be limited to this phase alone (Muinch, 2012). In agile software the expression "An ounce of prevention is worth a pound of cure." Translates to a general knowledge that the longer a defect is overlooked in a process, the more costly it is to fix. Additionally, agile software defects are costly and time consuming. The expense involved in finding and rectifying defects presents one of the costly agile software development undertakings. Such is the case that if the defects are transferred all the way to the final acceptance testing phase of the project life cycle, the greater risk of time consumption and costing increases. Consequently, small effort advanced towards quality assurance will help reduce expenses to a greater degree with regard to detecting and rectifying the defects. To better understand the effectiveness of the processes of agile software; it is important to gather facts on defects identified in the previous projects and also examine how the same defects can be eliminated following process improvements and application of newer methodologies. This paper presents comprehensive view on the defect prevention techniques and practices that can be followed in agile software development. In handling this topic the paper will look into related work and further discusses the need for defect deterrence. Additionally, the work will address handle issues of improvement workflow along with the illustration of various stages, the root cause analysis and determination of precautionary action. INTRODUCTION Agile software defect simply refers to “Imperfections in agile software development process that would cause agile software to fail to meet the desired expectations”. During the long and complex process of agile software development, lot of defects frequently occurs. One misleading notion is that defects crop into the process at the start of the cycle and is eliminated all through the remaining development phases. The truth is that defects form part of the development process from the very beginning to the end, a factor that makes its prevention an essential part in the agile software process quality improvement. Defect prevention (DP) refers to quality improvement process whose aim is to discover regular causes of defects and prevent their reoccurrence through alteration of the relevant process (es). Defect prevention also enhances the agile software product quality while reducing the overall costs, resources and schedule. Following this, equilibrium between the cost, schedule and quality is maintained. Defect prevention serves the purposes of identifying defects in the initial stages of the life cycle and stops them from reoccurring or resurfacing again. Agile software quality improvement will always start with identification, classification and analysis of the defect patterns. The studied patterns are then removed by establishing their root causes, for which deterrent mechanisms are identified to help stop their reoccurrence in future project, hence improving quality (Winkler, 2013). RELATED WORK The previous studies in defect prevention were geared towards defect prediction, a factor that limited it to deciding the testing resources in terms of team size that will help complete the project within the expected time. These required lots of efforts in the debugging phase were defects were being eliminated. One study conducted by Fang Chenbin introduced the Tracing System (BTS) tool to help in defect tracing. This tool gained popularity due to its low cost and the ability to enhance accuracy while tracking the established defects. Another work accomplished by Stefan Wagner summarized the studies on defect classification approaches previously proposed by other two companies’ i.e HP and IBM. The IBM model is referred to as Orthogonal Defect Classification (ODC) while the HP model finds its basis on three dimensions- defects origin, Modes and Types. Naresh Agarwal and Pankaj Jalote emphasized on how defect analysis identified in the initial iterations can offer feedback to help in the later iteration defect prevention, resulting to quality and productivity enhancement. Another study by Ajit Ashok Shenv finds its basis on a philosophy that “capturing defects in the earlier stage of the life cycle” serves as a way to prevent defects in the subsequent stages in the product life cycle and thus focused on establishing preventive measures for defects types viewed as functional. Suma V focused on providing information that addressing the various practices and methods that support defect detection and prevention as three particular case studies all these methodologies depicted short comings as they lacked some dimension regarding defect prevention and thus required further attention. This work supports combine application of the methodologies mentioned above i.e. iteration defect reduction, ODC, capturing defects during the early stages and establishing defect prevention with regard to better classified defect types. Moreover, this work this work has tried to come up with defect prevention cycle to help establish a continuous improvement of defect prevention and quality process. NEED FOR DEFECT PREVENTION As mentioned before Defect prevention forms an important part in any agile software development project. Majority of agile software organizations have their project team focused on defect detection which is mostly addressed through a rework. Following this, defect prevention has almost become a neglected component. It is prudent to come up with measures that will ensure prevention of defect introduction in the product all the way from the initial stage of the project. Such is the case that while the costs linked to such measures may be negligible, the long-term benefits (accruing from the overall cost saving) are notably higher when compared to the expenses of fixing the defects in the advanced stage. Up to this point it is clear that analysis of defect during the initial phases lessens the cost, time and resources required. Here, the knowledge gathered on defect injecting processes and methods helps much in the overall defect prevention. Such is the case that once this knowledge is acted upon, the quality is enhanced and at the same time productivity boosted (Singh, 2011). PROCESS IMPROVEMENT WORK FLOW Figure 1 Process Improvement Workflow WORK FLOW STAGES Defect Identification Defects are commonly spotted following preplanned activities that are deliberately designed to expose their existence. Generally, defects will be spotted in the different phases of agile software life cycle following activities that include GUI review, Code Inspection, Design review, function and unit testing (Ahmed, 2012). Best practices: Accurately identifying defects and relying on peers Best practices I defect identification requires that once something is thought of as a defect a research that tries to imitate is performed. Here, a brainstorming will be beneficial for the following reasons; first it will help to avoid raising incorrect defect bearing in mind that time allocated in a test execution case includes the time apportioned for execution of the test, that for logging defects, and that taken while doing other maintenance activities. Such is the case that when an alarm is raised concerning an incorrect defect, the development team will have to spend some time researching on it, only to later find out that it is not right. This is a loss as the team spends more time on a wrong thing at the expense of other important activities. Secondly, when incorrect defects are raised consistently, the team gets a wrong reflection concerning the knowledge they posses on the application (Huizinga, & Kolawa, 2007). Another way to prevent this is to keep checking the documentation to get the basic idea and further deliberate with team members to establish an understanding or agreement on the thing perceived as not working correctly. Having identified it as a defect, the next step is ensuring it is being g raised for the first time i.e. it is not duplication. Duplicate issues frequently result to wastage of time and also reflect poorly on coordination of the concerned team. Every time anew defect is identified it is important that a recheck is made on the defect log to find out if such a defect has been logged earlier. If it has not been logged, the step which is logging is implemented. Logging simply means creating a defect report. Defects identification is followed closely by classification, a process that employs the first level of Orthogonal Defect Classification. Defect Classification Orthogonal Defect Classification or ODC is one of the common techniques used in defects identification. This technique involves grouping of defects according to their respective types as opposed to considering them independently. ODC defect classification occurs in two different points in time. The first point is when the defect was first detected (or opener Section) and secondly when the defect was fixed (Closer section). ODC technique classifies each defect into a mutually exclusive (orthogonal) attributes with some being technical and others managerial. The attributers established here provide all the information required to enable shift through the large volume of data and thus arrive at patterns that drive the root-cause analysis activities (Kim, 2012). A good implementation of this methodology with an addition of a proper action planning and tracking will greatly help achieve greater defect reduction and subsequent cross learning. Among the things considered in defect classification is their severity and priority. It is important to note here that a small difference exists between these two aspects of defect analysis. Severity refers to the importance of the feature while priority has much to do with time and thus how fast such a defect should be fixed. A good example is a case where a program lacks a logout button. In such a case having a logout button may be considered low severity. This is so because in the event that one is unable to log out, it practically carries no implication on his/her ability to doing other things on the site. Taking an example of Gmail.com is one is unable to logout; the same thing cannot prevent such a person from sending an e-mail, checking an email or creating a group. Fundamentally, the log out function is considered to be of low severity, meaning it is not very crucial with regard to the site functionality. It is also true that having it fixed is not a priority. When taking the position of functional testers we b get more concerned on whether one is or is not able to utilize the site. Taking such a view, lack of, logout button carries no difficulty with using the site. Based on functional view the severity is very low, however the security perspective it is very high and it thus requires immediate fixing. In this case it is also important to mention that the priority also becomes high. As said before severity and priority present a slight difference with “Severity being nothing but how important is the function to the site” while Priority being nothing but, how soon should you fix this bug?” When the priority is high, developers are required to work on the defect right away. These aspects essentially serve as indicator to help developers establish how quickly they should address a defect. When considering small and medium projects, classification of defects to the level of ODC can significantly help save on time and effort. This may not apply for the critical and large projects which typically require an extensive defect classification in to better analyze and understand the defects (Krishna, 2012). First level of Orthogonal Defect Classification includes classification of the defects based on a range of defect types that include design, requirement, logical (logical defects identified while testing the code using unit/ functional testing) and documentation. Defects are classified basing on these types followed by a move to analyze the defects identified. Defect Analysis Defect analysis refers to the process of using the identified defects as data for an ongoing quality enhancement. Here, the analysis generally serves to categorize defects into groups and identify probable causes to help direct efforts placed on process improvement. Root cause Analysis commonly referred as RCA has for a long time played a central role in the general analysis of defects in agile software. RCA goal is to identify the defects root cause and initiate action that will eliminate the defects source. To accomplish this, defects are analyzed qualitatively one by one. The only limitation to this analysis is the range of human investigative capabilities. This analysis gives feedback to the developers that are used in the consequent improvement of the agile software organization both in terms of quality and productivity (Jalote, 2002). Defect Prevention Defect prevention is the other activity in agile software project that is of utmost importance. Defect prevention serves the purpose of identifying the causes of defects and preventing their reoccurrence. This activity involves analysis of defects that were identified previously, rolling out particular actions that will prevent the future reoccurrence of such defects. Defect preventions occur in one or more stages of the agile software lifecycle and seek to improve the quality of agile software process. Figure 2: Defect Prevention in Agile software Lifecycle Process Improvement I this stage the proposed preventive measures are implemented through rewriting of the existing quality manuals and tweaking of the SDLC process. Following this, developers come out with an improved SDLC processes and documents. Future project set are created based on the revised processes and thus all the preventive measures are followed meticulously. DEFECT ANALYSIS Defect Pareto Chart A Pareto chart is used to study the frequencies of occurrences of the many problems identified and thus determine the most frequent existing problem. The problem cause or categories are indicated on the bar graph’s X-axis while the y-axis shows the cumulative percentages. Such is the case that before root cause analysis is performed, A Pareto chart must first be prepared to show the defect type with the highest frequency of occurrence of defects. This follows the logging and documentation of defects and another closely related review and analysis that done using root cause analysis technique. The figure below shows an example of a Pareto chart with different defect types. Figure 3: Defect Pareto chart Root Cause Analysis Root cause analysis refers to the process of identifying the activity which results to the identified defects and designing ways to eliminate or reduce the effects through remedial actions. Root cause analysis of defects is typically founded on two key principles: the first principle is on reducing defects to enhance quality. Here, the analysis should culminate in the implementation of changes within processes that serve to prevent defects during the formation phase itself and guarantee their early detection in the event of a reoccurrence (Defect Prevention and Detection in Software for Automated Test Equipment, 2006). The second principle is based on utilizing local and third party experience that requires persons with detailed information on the problem to be present to analyze the processes prevalence in the concerned organization. This is accomplished alongside the third part experts. This principle holds the view that healthy debates carries the possibility of ensuring all possibilities are discussed, analyzed and the most appropriate action taken through a consensus. Using these guiding principles, analysis of defects is performed to determine their origin and the identified causes used in the later root cause analysis. Among the tools used in facilitating root cause analysis is the cause-and-effect diagram or fishbone diagram, a graphical technique commonly drawn to help in sorting and linking factors contributing to particular situation. The following diagram below shows an example of the cause-and –effect diagram. Figure 4: Cause Effect Diagram for a software Defect Preventive Action Preventive actions usually begin with brainstorming procedure which comes right after root cause analysis. This starts with identification of all possible causes as shown in the cause-and –effect diagram. The concerned team can then debate on the suggestions listed separating those identified as main reasons for the causes. Now that the causes are known possible preventive measures are brought forwards and implemented (Lucia, 2008). CONCLUSION Adoption of defect preventive measures not only works to better the project quality but also serves as a valuable investment. Such is the case that prevention practices improves the agile software developers ability to learn from errors identified and more importantly avoid mistakes done by other people. The benefits accruing from adopting defect prevention plans is great, mentioning just a few , it includes reducing development cost and time, increasing customer satisfaction, reducing rework effort, and thus decreasing cost and lastly improving the quality of the product. To better understand the defect there is need to classify them by implementing ODC to the subsequent phase. Later analysis of the ODC classified information works to establish better defect preventive techniques that would further enhance the process when using agile software. References Ahmed, A. (2012). Software project management: a process-driven approach.. Boca Raton: CRC Press. Defect Prevention and Detection in Software for Automated Test Equipment. (2006). Washington, D.C.: United States. National Nuclear Security Administration ;. Huizinga, D., & Kolawa, A. (2007). Automated defect prevention best practices in software management. Hoboken, N.J.: Wiley-Interscience :. Jalote, P. (2002). Software project management in practice. Boston: Addison-Wesley. Kim, T. (2012). Computer applications for web, human computer interaction, signal and image processing, and pattern recognition International Conference, SIP, WSE, and ICHCI 2012, held in conjuction with GST 2012, Jeju Island, Korea, November 28-December 2, 2012, proceed. Berlin: Springer. Krishna, P. (2012). Global trends in information systems and software applications 4th International Conference, ObCom 2011, Vellore, TN, India, December 9-11, 2011. Proceedings.. Berlin: Springer. Lucia, A. (2008). Emerging methods, technologies, and process management in software engineering. Hoboken, N.J.: Wiley-Interscience. Muinch, J. (2012). Software process definition and management. Berlin: Springer. Singh, Y. (2011). Software Testing. Cambridge: Cambridge University Press. Winkler, D. (2013). Software quality increasing value in software and systems development ; 5th International Conference, SWQD 2013, Vienna, Austria, January 15-17, 2013. Proceedings. Berlin: Springer. Read More