A bug is an error in a product\u2019s code which\nstops the working of a developed software therefore making it vital to detect a\nbug before the final product is made available for customers. Software\ndevelopment teams always associate bug tracking with testing and most\ntechniques of software creation have special steps of test conduction such as the\nTraditional waterfall methodology. There exist methodologies with flexible\ntesting and tracking approaches like the agile methods that encourage constant\ntracking during project realization. The bugs are usually tracked with the aid\nof a special software thereby making developing easier. Bug tracking systems\nare the applications that aid in detecting bugs, reporting on them, and\ncreating lists of bugs for fixing. This paper therefore discusses the Pivotal\ntracker software in terms of its bug tracking process for my proposed project,\nto facilitate the knowing the voting status of all people process using android\ndevices.<\/p>\n\n\n\n
Software description <\/strong><\/p>\n\n\n\n Pivotal\nTracker was developed in laboratories in 2006 to ease and facilitate\ndevelopment processes and team collaboration because it monitors progress\nthroughout the project making teams that use agile methodologies in software\ndevelopment benefit as they are to list down actionable items, prioritize\ntasks, assign given activities, and set their deadlines. It is therefore an opinionated\nand cloud-based project management tool that backs bug tracking as a project\nmanagement process as it will bring on board all team members despite the\ndistribution, into the same virtual room. The tracker will work by\nautomatically calculating the estimated time required to finish the voting, and\ncalculate their voting status by locating them everywhere they are globally.<\/p>\n\n\n\n The users<\/strong><\/p>\n\n\n\n This\ntherefore allows managers, more so those responsible for voting processes to\nhave better delivery estimates of the voting status depending on real time\ncircumstances and the workforce. This solution will give a guided iteration\nplanning tool that will enable the users to prioritize on project tasks as well\nas break them down into manageable chunks. Pivotal android mobile tracker will\nallow the team members to know exactly what happens at given times during\nvoting processes thereby making creation and responding to tasks easy. This\ntracker will aid in the management of our project\u2019s mobile phone app thus\nfacilitating its realization, and efficiency in voting.<\/p>\n\n\n\n Bugs vs feature request<\/strong><\/p>\n\n\n\n The\ntracker will organize all stories into story types that include bug, feature,\nchore and release and all of then use the same obligatory workflow of icebox,\nbacklog, current and done. It will give great visibility to the status of one\u2019s\nbugs and the overall project via personal work spaces and strong charts and\nreports. For my project, each developer will be able to see all stories that\nare assigned to them in a single space and this will help ensure nothing\nescapes through cracks. This type of detailed reporting will allow Kevin Hill\nas the project manager to constantly supervise the progress and speed of the\nproject thus identify issues as they occur.<\/p>\n\n\n\n System monitoring <\/strong><\/p>\n\n\n\n With\nthis tracker, the customer, project manager (Kevin Hill) or the product owner\n(Charles Lee Ray) will be adding new feature stories as the commencement of the\nprocess. This will be done in cooperation with other team members for instance\nstory mapping, specifications, workshops as well as an iteration planning\nmeeting. At this step mock-ups and assets are allowed for inclusion in the\nstory and stories are in an unscheduled state; icebox, unestimated and have\npoints approximate in place of an action button. They will then be prioritized\nby the customer\/ PM\/ PO in a backlog leaving them in an unstarted state as they\nremain unestimated. The customer\/PM\/PO will then prioritize stories in Backlog;\nthe stories will then be in the unstarted state, and will remain unestimated.\nThey will be estimated by the team while discussing each story so as to attain\na mutual understanding followed by the addition of extra data followed by\ncollective estimation. <\/p>\n\n\n\n At\nthis point the stories have a start button and they are started; the developers\n(Jason Vorhees and Freddy Kreuger) will then click on the start button on the\nfollowing unstarted estimated story in the present iteration. If the story\nturns out to be a feature that has yet to be estimated, the developer will be\nimpelled to allocate a point value before continuing making the story to be in\na started state with a finish button. Unless it has been preassigned, the individual\nwho clicked on start becomes the story owner. The developers will collaborate\nwith other team members to carry out testing and coding in turn building\nfeature increment represented by the story. Upon passing the coding and testing\nactivities, the developers will click on finish thus displaying the Deliver\nbutton. This mobile app will also have the ability to send and receive texts,\nand to locate anyone everywhere. <\/p>\n\n\n\n Follow up with the requester<\/strong><\/p>\n\n\n\n After\nbuilding the CI-newly built committed code passed, it will then be deployed to\ntesting and the stories marked as delivered by a team member making the Green\naccept and red Reject buttons visible. The Customer\/PM\/PO together with\ntesters, designers and other team members will verify if all set criteria have\nbeen adhered to and either accepts or rejects the story thus completing the\nfeedback loop. Accepted stories at this point will turn green and move to the\ntop of the current iteration then move to the Done panel at the end of the\niteration.<\/p>\n\n\n\n Bugs\non the other hand possess a similar work flow as feature stories and can be\ntagged with labels that relate them to a specific release, feature area of a\ngiven epic. In my case the product owner Charles Lee Ray will prioritize them as\na story in the backlog and label it as \u201cneeds design\u201d for placing the teams\ndesign in line to be reviewed for the results that came up; Afterwards the designer will then add mock ups\nand remove the label. Kevin Hill will then meet with the designer, Jackson\nNicholson and the programmer for a discovery workshop three days prior to the\nIPM to talk over the story while using an example in order to come up with the desired behaviors, establishing rules for the\nstory then jotting any oexceptional queries. <\/p>\n\n\n\n Assign unique code <\/strong><\/p>\n\n\n\n The\nwhole team will meet with the IPM and go over the rules with Kevin Hill. The\nteam will go in depth on the topic of dependency for the server side of story along\nwith the different options for implementation. Afterwards they\u2019ll be able to\nprovide an estimate to the story on three three points; lastly Kevin Hill will\nadd a blocker to it. Blocking will be accepted and should automatically resolve\nthe issue, next time the story itself. Jason Vorhees and Freddy Kreuger will\nstart it up, while assigning themselves as the story\u2019s owner. The code will\nthen be tested. Next , they will go over what was , then and only then discuss\nthem with Jackson and Hill in case new questions may\/may not come about. <\/p>\n\n\n\n Once\nthe code passes, samples will be automated throughout the test environment and Jackson will verify and\nclick on the Deliver button. Jackson will then have to validate how the search\u2019s turned out and felt while accepting it\nafter which more explanatory testing is done to determine issues outside the story\u2019s\nscope followed by adding of more stories. Jackson and Hill will then accept the\nstory. An issue reported as a bug will be a missing feature or any behavior plus\nwith this story being changed from a bug then towards to a the main event or it\nwill be labeled with a tag that states \u201c its not a bug\u201d ; then the status will\nbe changed to to being accepted. Some bugs may linger long enough to be fixed\nby different stories and a good option here will be to comment on anything that\nwas tried on it as \u201cnon-reproducible\u201d then change the state to \u201cAccepted\u201d. <\/p>\n\n\n\n Conclusion <\/strong><\/p>\n\n\n\n The necessary steps and\nprocesses required for the implementation of this project have been explained\nin details. Bug tracking is the final stage of projects realization but in some\ninstances testing and bug detection may cause trouble considering it is hectic\nto fix a problem when the final product is almost ready. It is therefore\nexpected that this project will run smoothly and that the expected objectives\nwill be achieved. This will enable the project team to eventually identify,\nfix, and log the bugs when undertaking various tasks. <\/p>\n","protected":false},"excerpt":{"rendered":" A bug is an error in a product\u2019s code which stops the working of a developed software therefore making it vital to detect a bug before the final product is made available for customers. Software development teams always associate bug tracking with testing and most techniques of software creation have special steps of test conduction […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1068","post","type-post","status-publish","format-standard","hentry","category-research-paper-writing"],"_links":{"self":[{"href":"https:\/\/papersspot.com\/blog\/wp-json\/wp\/v2\/posts\/1068","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/papersspot.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/papersspot.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/papersspot.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/papersspot.com\/blog\/wp-json\/wp\/v2\/comments?post=1068"}],"version-history":[{"count":1,"href":"https:\/\/papersspot.com\/blog\/wp-json\/wp\/v2\/posts\/1068\/revisions"}],"predecessor-version":[{"id":1069,"href":"https:\/\/papersspot.com\/blog\/wp-json\/wp\/v2\/posts\/1068\/revisions\/1069"}],"wp:attachment":[{"href":"https:\/\/papersspot.com\/blog\/wp-json\/wp\/v2\/media?parent=1068"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/papersspot.com\/blog\/wp-json\/wp\/v2\/categories?post=1068"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/papersspot.com\/blog\/wp-json\/wp\/v2\/tags?post=1068"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}