Title Page Software Bugs Management (Iso/Iec/Ieee 29119 Standard) System
TITLE PAGESOFTWARE BUGS MANAGEMENT(ISO/IEC/IEEE 29119 STANDARD) SYSTEMByCHIN JUN KANGA REPORTSUBMITTED TOUniversiti Tunku Abdul Rahmanin partial fulfillment of the requirementsfor the degree ofBACHELOR OF COMPUTER SCIENCE (HONS)Faculty of Information and Communication Technology(Kampar Campus)JAN 2020
UNIVERSITI TUNKU ABDUL RAHMANREPORT STATUS DECLARATION FORMTitle:SOFTWARE BUGS MANAGEMENT(ISO/IEC/IEEE 29119 STANDARD) SYSTEMAcademic Session: JAN 2020ICHIN JUN KANG(CAPITAL LETTER)declare that I allow this Final Year Project Report to be kept inUniversiti Tunku Abdul Rahman Library subject to the regulations as follows:1.2.The dissertation is a property of the Library.The Library is allowed to make copies of this dissertation for academic purposes.Verified by,(Author’s signature)(Supervisor’s signature)Address:No. 32, Jalan Besar,35500 Bidor,PerakDate: 24 April 2020Tan Teik BoonSupervisor’s nameDate: 24 April 2020
TITLE PAGESOFTWARE BUGS MANAGEMENT(ISO/IEC/IEEE 29119 STANDARD) SYSTEMByCHIN JUN KANGA REPORTSUBMITTED TOUniversiti Tunku Abdul Rahmanin partial fulfillment of the requirementsfor the degree ofBACHELOR OF COMPUTER SCIENCE (HONS)Faculty of Information and Communication Technology(Kampar Campus)JAN 2020BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTARi
DECLARATION OF ORIGINALITYDECLARATION OF ORIGINALITYI declare that this report entitled “SOFTWARE BUGS MANAGEMENT(ISO/IEC/IEEE 29119 STANDARD) SYSTEM” is my own work except as cited in thereferences. The report has not been accepted for any degree and is not being submittedconcurrently in candidature for any degree or other awards.Signature:Name:CHIN JUN KANGDate:24/04/2020BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTARii
ACKNOWLEDGEMENTSACKNOWLEDGEMENTSI would like to express my sincere thanks and appreciation to my supervisors, Ts. Tan TeikBoon who has given me this bright opportunity to engage in a Software Bug Managementproject. It is my first step to establish a career in the software development field. A millionthanks to you.Furthermore, I would like to thank Ts. Yeck Yin Ping who introduce Mr Tan to me so thatI can have a chance to work with Mr Tan. Finally, I must say thanks to my parents and myfamily for their love, support and continuous encouragement throughout the course.BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTARiii
ABSTRACTABSTRACTBug management is a crucial process in the software development process. Low-quality bugmanagement could result in low-quality deliverable, resources wasted and profit lost.However, bug management is not an easy process, software developers often have a hardtime managing software bugs. This is because a development team involves not onlytechnical software developer but also non-technical business unit. It can be hard tocommunicate between the development team as the members have a different level oftechnical knowledge. To solve this problem, this project proposes a bug management systemas a solution. Although there are many existing bug management systems, most of them donot provide a standardized bug management process. The proposed system provides astandardized bug management process following the ISO/IEC/IEEE 29119 SoftwareTesting Standard. The proposed system also aims to improve the understanding of thesoftware bugs and improve the communication between the development team. With thehelp of the proposed system, the software developer can focus on the software developingand software development team including business unit can communicate more effectively.BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTARiv
TABLE OF CONTENTSTABLE OF CONTENTSTITLE PAGEiTITLE PAGEiDECLARATION OF ORIGINALITYiiACKNOWLEDGEMENTSiiiABSTRACTivTABLE OF CONTENTSvLIST OF FIGURESviiiLIST OF TABLESxiLIST OF ABBREVIATIONSxiiCHAPTER 1: INTRODUCTION11.1. Problem Statement11.2. Background and Motivation21.3. Project Scope31.4. Project Objectives31.5. Impact, Significance and Contribution4CHAPTER 2: LITERATURE REVIEW2.1. Bugs552.1.1 Bug Report52.1.2 Bug life cycle62.2. ISO/IEC/IEEE 29119 Software Testing Standard72.2.1 ISO/IEC/IEEE 29119-1:2013 – Concepts & Definitions72.2.2 ISO/IEC/IEEE 29119-2:2013 – Test Processes72.2.3 ISO/IEC/IEEE 29119-3:2013 – Test Documentation102.2.4 ISO/IEC/IEEE 29119-4:2015 – Test Techniques112.2.5 ISO/IEC/IEEE 29119-5:2016 – Keyword Driven Testing132.3. Review of Existing Works142.3.1 Airbrake142.3.2 Backlog162.3.3 Zoho BugTracker192.3.4 Comparison of Key Features21BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTARv
TABLE OF CONTENTSCHAPTER 3: PROPOSED METHOD233.1. Design Specifications233.1.1 Methodologies233.1.2 General Work Procedures233.1.4 Technologies and Tools Involved.253.1.5 System Performance Definition263.1.6 Verification Plan263.2. System Design283.2.1 System Flowchart283.2.2 Use Case Diagram293.2.3 Use Cases Description303.2.4 Activity Diagrams37CHAPTER 4: ISO/IEC/IEEE 29119 STANDARD SPECIFICATION4.1. General44444.1.1 Metrics444.1.2 Classification444.2. Form Design Specification454.2.1 Test Case454.2.2 Bug / Test Incident46CHAPTER 5: IMPLEMENTATION AND TESTING495.1. Database Set up495.2. Authentication525.3. React Native Components535.3.1 Community built libraries and components535.3.2 Self-built components545.4. User Interface Design585.4.1 Mobile Platform585.4.2 Web Platform695.5. Use Case Testing765.6. Implementation Issues and Challenges78CHAPTER 6: CONCLUSION6.1. Project ReviewBCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTAR8080vi
TABLE OF CONTENTS6.2. Novelties and Contribution806.3. Future Work81BIBLIOGRAPHY82POSTER84PLAGIARISIM CHECK RESULT85CHECKLIST FOR FYP2 THESIS SUBMISSION87BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTARvii
LSIT OF FIGURESLIST OF FIGURESFigure 2.1.1: The defect life cycle (Graham et al. 2008)6Figure 2.2.1: Test Management Process (International Organization forStandardization 2013)8Figure 2.2.2: Test Planning Process (International Organization for Standardization2013)8Figure 2.2.3: Test Monitoring and Control Process (International Organization forStandardization 2013)9Figure 2.2.4: Dynamic Test Process (International Organization for Standardization2013)9Figure 2.2.5: Test Design Techniques (International Organization for Standardization2013)12Figure 2.3.1: Logo of Airbrake14Figure 2.3.2: Real-time errors capture and tracing features (‘Airbrake’ n.d.)14Figure 2.3.3: Real-time deployment monitoring and quality analysis features(‘Airbrake’ n.d.)15Figure 2.3.4 Logo of Backlog16Figure 2.3.5: Project management features (‘Backlog’ n.d.)17Figure 2.3.6: Bugs tracking and team collaboration features (‘Backlog’ n.d.)17Figure 2.3.7: Task management and version control features (‘Backlog’ n.d.)17Figure 2.3.8: Logo of Zoho BugTracker19Figure 2.3.9: Bug management and Custom form field features (‘Zoho BugTracker’2010)19Figure 2.3.10: Forum and working timesheet features (‘Zoho BugTracker’ 2010)20Figure 3.1.1: The flow of the development process23Figure 3.2.1: System Flowchart28Figure 3.2.2: Use Case Diagram29Figure 3.2.3: Activity diagram of the Login use case37Figure 3.2.4: Activity diagram of the Sign up use case38Figure 3.2.5: Activity diagram of the View feed list use case39Figure 3.2.6: Activity diagram of the View dashboard use case39Figure 3.2.7: Activity diagram of the View team use case40Figure 3.2.8: Activity diagram of the Create team use case40BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTARviii
LSIT OF FIGURESFigure 3.2.9: Activity diagram of the Add project use case41Figure 3.2.10: Activity diagram of the Add test case use case42Figure 5.1.1: Database structure of profiles49Figure 5.1.2: Database structure of teams49Figure 5.1.3: Database structure of projects50Figure 5.1.4: Database structure for feeds50Figure 5.1.5: Database structure of requirements51Figure 5.1.6: Database structure for test cases51Figure 5.1.7: Database structure for bugs52Figure 5.3.1: Screenshot of PasswordField.js54Figure 5.3.2: Screenshot of ProgressBar.js55Figure 5.3.3: Screenshot of Alert.js56Figure 5.3.4: Screenshot of style for Alert.js57Figure 5.4.1: The splash screen58Figure 5.4.2: The Login screen59Figure 5.4.3: The Signup screen59Figure 5.4.4: System alert when fields are invalid59Figure 5.4.5: The Feeds screen60Figure 5.4.6: Add function in the Feeds screen60Figure 5.4.7: Search function in the Feeds screen60Figure 5.4.8: The Drawer Navigation61Figure 5.4.9: The Bottom Bar Navigation61Figure 5.4.10: The Profile screen62Figure 5.4.11: The Team screen62Figure 5.4.12: Edit user list function in the Team screen62Figure 5.4.13: The Dashboard Screen - 163Figure 5.4.14: The Dashboard Screen - 263Figure 5.4.15: The Add Project Screen64Figure 5.4.16: The Requirement Screen64Figure 5.4.17: The Add Test Case Screen - 164Figure 5.4.18: The Test Case Screen - 264Figure 5.4.19: The Add Project Screen65Figure 5.4.20: The Requirement Screen65Figure 5.4.21: The Project List Screen66BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTARix
LSIT OF FIGURESFigure 5.4.22: The Project Home Screen66Figure 5.4.23: The Project Requirement Screen67Figure 5.4.24: The Project Test Case Screen67Figure 5.4.25: The Project Bug Screen67Figure 5.4.26: The Requirement Screen68Figure 5.4.27: The Test Case Screen68Figure 5.4.28: The Bug Screen68Figure 5.4.29: Screenshot of Login Page69Figure 5.4.30: Screenshot of Signup Page69Figure 5.4.31: The Home Page70Figure 5.4.32: The Profile Page70Figure 5.4.33: Screenshot of Project Home Page71Figure 5.4.34: The Team Page71Figure 5.4.35: The Dashboard Page72Figure 5.4.36: The Add Project Page72Figure 5.4.37: The Add Requirement Page73Figure 5.4.38: The Add Test Case Page73Figure 5.4.39: The Add Bug Page - 174Figure 5.4.40: The Add Bug Page - 274Figure 5.4.41: The Requirement Page75Figure 5.4.42: The Test Case Page75Figure 5.4.43: The Bug Page76BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTARx
LIST OF TABLESLIST OF TABLESTable 2.3.1: Key features comparison table21Table 3.1.1: Laptop specifications25Table 3.1.2: Mobile device specifications25Table 3.2.1: Use case description of the Login use case30Table 3.2.2: Use case description of the Sign up use case31Table 3.2.3: Use case description of the View feed use case31Table 3.2.4: Use case description of the View dashboard use case32Table 3.2.5: Use case description of the View team use case32Table 3.2.6: Use case description of the Create team use case33Table 3.2.7: Use case description of the Add project use case34Table 3.2.8: Use case description of the Add requirement use case34Table 3.2.9: Use case description of the Add test case use case35Table 3.2.10: Use case description of the Add bugs use case35Table 3.2.11: Use case description of the View project detail use case36Table 3.2.12: Activity diagram of the Add requirement use case41Table 3.2.13: Activity diagram of the Add bug use case42Table 3.2.14: Activity diagram of the View project detail use case43Table 4.1.1: ISO/IEC/IEEE 29119 standard general metrics44Table 4.1.2: Classification used in ISO/IEC/IEEE 29119 standards44Table 4.2.1: Form Fields Description for Test Case46Table 4.2.2: Form Template for Test Case46Table 4.2.3: Form Fields Description for bug47Table 4.2.4: Form Template for Bugs48Table 5.3.1: Libraries and components used and the repositories53BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTARxi
LIST OF ABBREVIATIONSLIST OF ABBREVIATIONSNISTNational Institute of Standards and TechnologyU.S.United StatesISOInternational Organization for StandardizationIECInternational Electrotechnical CommissionIEEEInstitute of Electrical and Electronics EngineersIPInternet ProtocolOSOperating SystemUMLUnified Modeling LanguageUIUser Interfaceetc.et ceteraAnon.Anonymousn.d.No datepp.pagesBCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTARxii
CHAPTER 1: INTRODUCTIONCHAPTER 1: INTRODUCTION1.1. Problem StatementPoor bugs management could post problems in every software development lifecycle.First is the misunderstanding of bugs, not all bugs are caused by coding errors,misunderstanding can be caused by miscommunication within the development team,unclear requirements, misunderstanding of requirements and poor documentation ofbugs. Sometimes issues are reported technically (as bugs), but a development teamconsisting of non-technical members such as customer, stakeholders, organization, etc.It could be hard for non-technical members to involve in the software developmentprocess this can cause the requirement and issue to become unclear.Moreover, fixing bugs can become not effective and time-consuming if thedevelopers do not have a standardized testing process. As mentioned by (Ahonen etal. 2004) one of the challenges in testing defects is that it is hard to ensure that allmembers in the development team follow good practices. During a conference, (KajkoMattsson & Bjornsson 2007) have also reported that organizations do not documenttesting processes properly. These testing-related problems can delay the time a bug isdetected during the software development process and result in late in solving the bugs.Last but not least, it will be an ineffective use of intellectual if a bug is notdocumented well (Ahonen et al. 2004). A development team may consist of expertsfrom different domain/fields, an issue found by a developer may from a different field,he/she may use a long time to solve the problem. In a larger development team, therewill be different members to do the testing which may not have coding skill to resolvethe issue. The member who found the bug has to determine the skills needed to solvethe problem and passes the bug to the members who have the required skill or informsevery member in the team to find out who has the ability to solve the problem. If thebug is documented well, other developers who are expert in the domain can view thedocumentation and resolve the problem effectively.BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTAR1
CHAPTER 1: INTRODUCTION1.2. Background and MotivationSoftware bugs are always a challenge in the software development process. Softwarebugs are errors occur in software including coding error, unexpected softwarebehaviour, misunderstood user requirement etc. These software bugs can prolong theproject development process and delay the delivery of the final product. These problemsarise because bugs are not well-documented and most of the time it is very difficult todocument bugs (Singh 2013) thus developers often use Bug Management System toease the bugs documentation process.A bug management system is a tool for developers to report bugs, sort and filterbugs, assign bugs to individuals and tracking the bugs to resolution. A bug managementsystem provides a standard for developers to document and distribute bugs sodevelopers can focus on developing and not documenting. A bug management systemeases the process of bug managing so the developers can focus on developing thesoftware and thus reduce development duration and increase product quality.Bug management is the process of documenting, keep tracking and eventuallyfixing the software bugs during the software development process. Bug managementinvolves different techniques to manage software bugs such as bug report, bug life cyclemonitoring, etc.In this project, the ISO/IEC/IEEE 29119 Software Testing Standard is used toprovide a set of standardized formats for software testing and bug managementprocesses. Bug documentation with standardized format help the development team tounderstand the documentation easier and hence result in solving the bugs better. Asoftware testing standard ensures the developers in the software development team todeliver quality products.BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTAR2
CHAPTER 1: INTRODUCTION1.3. Project ScopeThe scope of the project including the following three: To develop a system with bug management functionalities. To develop the bug management system in both the web and mobileplatforms. To develop a centralized database to maintain the bugs for the bugmanagement system.1.4. Project ObjectivesThe main objective of this project is to build a system that is able to assist developers,stakeholders, and customers in understanding the program development process. Theproposed system follows the ISO/IEC/IEEE 29119 Software Testing Standard toprovide better bugs management to the members involved in the software developmentprocess. The objective can be broken down into sub-objectives: To offer bug tracking and management functionalities to the users suchas bug report, keep track of bug’s status, assign bugs to users, etc. To keep track the progress of bug management. To standardize the bug tracking and management process by usingsoftware testing standard.BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTAR3
CHAPTER 1: INTRODUCTION1.5. Impact, Significance and ContributionAccording to the report from the National Institute of Standards and Technology (NIST)(Strate & Laplante 2013), the U.S. economy loses 60 billion a year because of softwaredefects and fixing these defects earlier could save 22 billion a year for the U.S.economy. The statistic shows how crucial bug management is in the softwaredevelopment process. It is the development team’s job to test, keep track and resolvethe bugs but it is not easy to duel with bugs. If the development team cannot resolvebugs effectively, the system will become buggy which highly decreases the usability ofthe system and even cause the system cannot meet the user requirement and result infailure. This project aims to create a tool for the development teams to helps them inproducing quality products.Although there are many existing bug management systems, most of thesystems are not standardized. This can cause solving bugs becomes ineffective andtime-consuming. This project provides a standard based on the ISO/IEC/IEEE 29119Software Testing Standard so the developers can be more consistent at work and solvethe bugs effectively. Another limitation for the existing works is that most systems onlyconcern about the developer aspect and disregard for the business aspect of thedevelopment team. This project considers the business aspect of the development teamand provides easy to understand non-technical information for the progress of thedevelopments.BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTAR4
CHAPTER 2: LITERATURE REVIEWCHAPTER 2: LITERATURE REVIEW2.1. BugsA bug is a failure, flaw, error or abnormal behaviour in software that causes the softwareto behave differently from what is expected. A bug can be a logical error, incorrectimplementation of code, design error, syntax error or unfulfillment of user requirements.2.1.1 Bug ReportBug reports are the primary method users and testers of a system to communicate anissue to the developers. When a bug is detected, a bug report should be generated andsend to the developers for resolving. The content of a bug report is important as it helpsdevelopers to understand the issue, find and fix the bugs. After comparing severalsources by (Bug n.d., Defect Management Process in Software Testing (Bug ReportTemplate) n.d., Davies & Roper 2014, What is Defect or bugs or faults in softwaretesting? 2012), the following parameters are found to be important to be included in abug report to assist the developers in resolving an issue. Bug ID – A unique identifier for each bug Bug Description – Detailed description of the bug including expectedbehaviour and observed behaviour. Build Information – The system and the release version of the system inwhich the bug was detected. Environment – Description of the environment the bug was foundincluding operating system, browser system and more. Steps to Reproduce – The detailed steps for the developers to reproducethe same issue in different machines. Date Raised – Date when the bug is reported. Reported by – Name or ID of the tester who detected and reported thebug. Status – The current status of the bug, could be New, Assigned, Open,etc. Assigned to / Fixed by – Name or ID of the developer who assigned tosolve the issue or fixed the bug. Date Closed – Date when the issue is closed.BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTAR5
CHAPTER 2: LITERATURE REVIEW Severity – Level of the impact of the bug on the system. Priority – Level of urgency in resolving the bug.2.1.2 Bug life cycleIn software development, the bug life cycle describes the statuses a bug goes throughduring its lifetime. It differs between organizations and projects, some may prefer asimpler life cycle like presented by (Graham et al. 2008, D’Ambros et al. 2007) whileothers may adopt a more extensive life cycle.Figure 2.1.1: The defect life cycle (Graham et al. 2008) Reported – When a bug is first detected and reported, it is in theReported state. Opened – After the bug is reviewed, it is in the Opened state. Assigned – After the bug is approved by the development team leadtester, the bug is assigned to the developers. Fixed – Once the developers have repaired the bug, it is in the Fixedstate and will go through a confirmation test. Reopened – If the bug is checked not fixed after the confirmation test, itis reopened and repeat until it passes the confirmation test. Closed – The final state of the bug, after it is fixed and passes theconfirmation test it is closed to indicate that the bug is repaired and donot exist in the program anymore.BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTAR6
CHAPTER 2: LITERATURE REVIEW Rejected – The developers can reject the bug by a few reasons, the issueis not reproducible, duplicated issue, it is not a bug, etc. Deferred – Deferred state means the bug is expected to be fixed in thenext releases for the reason that the bug has a low severity and lowpriority.2.2. ISO/IEC/IEEE 29119 Software Testing StandardISO/IEC/IEEE 29119 is a software testing standard developed by ISO Software TestingGroup of the ISO/IEC JTC1/SC7 Software and Systems Engineering committeestarting from 2007. The ISO/IEC/IEEE 29119 consists of a series of 5 internationalstandards for systems and software engineering testing. Each release of theISO/IEC/IEEE 29119 focus on an aspect of software testing such as concepts anddefinitions, test processes, test documentation, test techniques and keyword-driventesting.2.2.1 ISO/IEC/IEEE 29119-1:2013 – Concepts & DefinitionsPart 1 of the ISO/IEC/IEEE 29119 standard release in 2013 and covers the conceptsand definitions of software testing. It provides practical examples of the application ofeach concept and introduces vocabulary used throughout the ISO/IEC/IEEE 29119series to help the reader in understanding the concepts presented in the ISO/IEC/IEEE29119 series.2.2.2 ISO/IEC/IEEE 29119-2:2013 – Test ProcessesPart 2 describes more details about test processes with a generic software testing modelthat can be used in any software development. The series presents a multi-layer processmodel for governing, managing and implementing software testing. The diagramsprovided by (International Organization for Standardization 2013) below describe themodel in detail.BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTAR7
CHAPTER 2: LITERATURE REVIEWFigure 2.2.1: Test Management Process (International Organization forStandardization 2013)Figure 2.2.2: Test Planning Process (International Organization for Standardization2013)BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTAR8
CHAPTER 2: LITERATURE REVIEWFigure 2.2.3: Test Monitoring and Control Process (International Organization forStandardization 2013)Figure 2.2.4: Dynamic Test Process (International Organization for Standardization2013)BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTAR9
CHAPTER 2: LITERATURE REVIEW2.2.3 ISO/IEC/IEEE 29119-3:2013 – Test DocumentationPart 3 introduces the software test documentation with standard templates. Alltemplates follow the three test process levels defined in ISO/IEC/IEEE 29119-2 andcan be customized for any organization and software development process. The testdocumentation standard presented is built on top of the IEEE 829 Test Documentationstandard.The documents defined in this part are as follows (International Organizationfor Standardization 2013):BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTAR10
CHAPTER 2: LITERATURE REVIEW2.2.4 ISO/IEC/IEEE 29119-4:2015 – Test TechniquesPart 4 of the standard covers software test design techniques based on the BS-7925-2Component Testing standard. It defines different types of testing and testing techniquesthat can be applied as well as provides detailed examples of the implementation of eachtechnique.Following are the testing type discussed in the standard(InternationalOrganization for Standardization 2013):The diagram below shows the test design techniques that are discussed in thestandard (International Organization for Standardization 2013):BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTAR11
CHAPTER 2: LITERATURE REVIEWFigure 2.2.5: Test Design Techniques (International Organization for Standardization2013)BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTAR12
CHAPTER 2: LITERATURE REVIEW2.2.5 ISO/IEC/IEEE 29119-5:2016 – Keyword Driven TestingPart 5 of the standard introduce Keyword-Driven Testing, an approach of softwaretesting that using predefined keywords in describing test cases. The standard covers theintroduction in Keyword-Driven Testing, application of Keyword-Driven Testing,frameworks, data interchange, roles and tasks in Keyword-Driven Testing and somebasic Keywords. The standard also discussed on benefits and issues of Keyword-DrivenTesting.BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTAR13
CHAPTER 2: LITERATURE REVIEW2.3. Review of Existing WorksThere are many similar systems exist in the market, 3 of them are selected for review.2.3.1 AirbrakeFigure 2.3.1: Logo of AirbrakeAirbrake is a cloud-based monitoring tool for software development teams to manageand monitor deployed projects. Airbrake is an API that automatically captures uncaughterrors in deployed and ongoing projects and reports to development teams directly.Currently, there are many well-known companies using Airbrake including Twitch,TED, Zenefits, SalesForce, SoundCloud, Adobe and more.Key Features: Capture real-time errors automatically from deployed projects Real-time issues tracking and monitoring Errors code tracing Real-time deploy monitoring Deployment quality analysis and insight User experience monitoring Security features to protect users data.Figure 2.3.2: Real-time errors capture and tracing features (‘Airbrake’ n.d.)BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTAR14
CHAPTER 2: LITERATURE REVIEWFigure 2.3.3: Real-time deployment monitoring and quality analysis features(‘Airbrake’ n.d.)Strength: Errors are captured automatically in real-time as they arise on clientsides. Provides real-time deployment quality monitoring and analysis. Notification for new issues. Support for a vast amount of programming languages. Support for numbers of third-party integrations. Easy to install and integrate it into software projects. Highly secured data protection. API is available for developers. Accessible anywhere anytime as a web-based service. Mobile-friendly web design.Weakness: Complex user interface. Lack of team communication functionality. Lack of support for different platforms. Users are unable to attach additional files on an error. Lack of test case management features. Lack of requirement management features. Lack of traceability of bugs.BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTAR15
CHAPTER 2: LITERATURE REVIEW2.3.2 BacklogFigure 2.3.4 Logo of BacklogBacklog is an all-in-one software development assisting tool that includes functionssuch as project management, bug tracking, task management, version control and more.In Backlog, developers can communicate effectively throughout the softwaredevelopment process. Currently, companies that using Backlog include Omron,SoftBank Robotics, Adobe, TransferWise and Vanilla Air.Key Features: Push notifications for new issues. Bugs tracking and managing. Extensive task managing. Version control support with integration with Git. Centralize repository for each project. Project scheduling with Gantt charts. Access control for IP addresses and roles. Team collaboration using comments and attachments. Project wiki page. Customizable forms. Jira and Redmine importer.BCS (Hons) Computer ScienceFaculty of Information and Communication Technology (Kampar Campus), UTAR16
CHAPTER 2: LITERATURE REVIEWFigure 2.3.5: Project management features (‘Backlog’ n.d.)Figure 2.3.6: Bugs tracking and team collaboration features (
Bug management is a crucial process in the software development process. Low-quality bug management could result in low-quality deliverable, resources wasted and profit lost. However, bug management is not an easy process, software developers often have a hard . ISO/IEC/IEEE 29119 Software Testing Standard 7 2.2.1 ISO/IEC/IEEE 29119-1:2013 .
Conenose bugs are an exception to the family rule and are blood-feeding parasites that feed on a wide variety of domestic and wild animals, and occasionally humans. Conenose bugs are also known as kissing bugs, Triatomine bugs, Mexican bed bugs, and the Wallapai tigers. The name “kissing bug” refers to a South American species thatFile Size: 2MBPage Count: 10
Beautiful Bugs Let's get buggy at camp. Looking around outside! There are fuzzy bugs, flying bugs, lots-of-legs bugs, all sorts of bugs! Some bugs are even pets! Speak with a bug specialist, make a bug box, make a model of a bug home and take a bug hike! Camp is open Monday - Friday, 7:30 a.m. - 6 p.m. Register by May 1 and pay only 135 per .
best way to manage bed bugs. Adult bed bugs can hide in any spaces as thin as a piece of paper. Young bed bugs are even smaller. When conducting an inspection, move slowly and avoid disturbing hiding bugs, so they don’t scatter. Keep in mind that in a low infestation, t
In the U.S., kissing bugs live in many southern states. There are 11 different kinds of kissing bugs in the U.S. Most of the reports of the different kissing bugs have come from Arizona, California, New Mexico, and Texas. Kissing bugs have been found and documented in the U.S. as early as the mid-1800s. They are not a new species of bug in the U.S.
Module 7- Dealing with Bed Bugs in Child Care Settings Integrated Pest Management for Child Care Settings 1 . Bed Bugs in Child Care Settings Bed bugs are often introduced to schools and child care centers from
Decodable Text for Phonics Intervention Instructional Focus Digraph /hw/ wh Cluck! Quack! Wham! Whack! Bugs whiz and buzz. “Hmmm,” clucks Hen. “Which bug shall I pick for a snack?” Hen is not quick, and the bugs whiz off. When Hen naps, the bugs come back. Bugs whiz and buzz. “Hmmm,” quacks Duck. “Which bug shall I pick for a .
both good (beneficial) and bad (damaging) bugs that you might find in your garden. This guide will offer tips on how to control bad bugs and ideas for how to attract good bugs. Good and bad bugs can be different sizes, shapes, and colors. This book has pictures of the damage caused by bad bug
Brownie Bugs Badge – STEM Goal: Explore the world of bugs and learn more about these little creatures that do so much. Notes: Though many people call all insects and spiders “bugs,” a bug is actually an insect that has a mouth shaped like a straw that it uses to suck nectar from plants or blood from other insects or animals (like us).
