Question 7 you are writing an explanation for your test team on the lifecycle of

Question

Question 7

you are writing an explanation for your test team on the lifecycle of a bug in the system: explain each status code and when it might be applied?

Question 8

Select bug tracking software for a small development environment (8 developers and 2 testers). Explain why the software is best to meet the needs of the environment and give an estimated cost. ?

Question 9

What metrics from the bug-tracking software would you use to measure your progress in fixing bugs? Why?

Question 10

List the fields that you would use to document the bug in the tracking system

Explanation / Answer

Question 7:

Bug status and its description:

1) New: When new bug is found by the QA team.

2) Deferred: If the bug is not associated to current build or it cannot be fixed in the current release or bug is not so important that it needs to be fixed.

3) Assigned: ‘Assigned to’ field is set when a bug is assigned to a developer to be fixed.

4) Resolved/Fixed: When developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team.

5) Could not reproduce: If the bug is not reproducible by the developer using the steps given in bug report by QA then developer can mark the bug as ‘CNR’.

6) Need more information: If the bug reproduction steps provided by QA to reproduce the bug is unclear to the developer, then the developer can mark it as “Need more information’.

7) Reopen: If QA is not satisfied with the fix and if bug is still reproducible even after fix then QA can mark it as ‘Reopen’ so that developer can take appropriate action to fix it again.

8) Closed: If bug is verified by the QA team and if the fix is correct and problem is solved. Then QA team marks it as closed.

9) Rejected/Invalid: Sometimes developer or team lead can mark the bug as Rejected or invalid if the system is working according to specifications and bug is just due to some misinterpretation.

Question 8:

Software called Aiveo can be used .

Aiveo provides simple solution to the problems you. As small software development company it is usually found that most issue trackers are either too expensive, too complicated or lacked the features we found important. The best part about Aiveo, is that it is completely free with no limitations for up to 5 users.

Some highlighting features in are:

·         Milestones

·         Custom workflows

·         Task board

·         Time tracking

·         Git integration (commit commands)

Question 9:

Metrics that can be used for bug tracking include the followings:

·         Total number of bugs.

·         Total number of bugs that has not been fixed.

·         Total number of bugs that have been fixed.

·         number of new bugs identified per week.

·         The number of successful bug fixes per week.

·         Number of unsuccessful bug fixes per week.

Question 10:

Good bug reports contain the following fields:

DESCRIPTIVE TITLE

The bug details must be clear and descriptive, so that anypne get an idea of what it is about the bug at a glance.

CONCISE DESCRIPTION

A short description of the bug and the possible reasons of why it may happen.

EXPECTED RESULTS

Description of the actual expected result and the current result output due to the bug.

DETAILS ABOUT THE PROJECT AND VERSION

It’s not unusual for testers to work on multiple projects at the same time, and sometimes they’ll share a database, so ensuring that your bug is listed in the correct project, and section within that project, is vital. You also need to get the software version right. Sometimes a bug will be fixed when a different defect is addressed, or simply by some change in the newest version of the software. If the version is wrong, developers may be embarking on a wild goose chase.

PLATFORM DETAILS

Any background information you can provide about your environment will help developers track that bug down. What device were you using? What operating system was it running? What model was it? What browser did you use? Every detail you can give about the platform will help.

DEFECT TYPE AND SEVERITY

These fields go hand-in-hand. A functional bug will generally be treated more seriously than a suggestion. Developers also need to know how severe the bug is. No product ships with zero defects, so having bugs categorized correctly in terms of type and severity really helps the decision-making process with regards to what gets fixed and what doesn’t. So it is always better to mention the Priority and Severity of the Bugs.

STEPS TO REPRODUCE

A step-by-step account of exactly how you did to find any defect.

This may include screenshots/audio/video for some steps, and description for each step.

TAGS & LINKS

Include bug ID or a link within your defect report to something that you feel is strongly related or similar, but not similar enough to be a duplicate.

ASSIGNEE

The name of the developer to whome the bug is assigned to be fixed.

Hope your question has been resloved. Please do not forget to give a positive like to the answer. Thank you.

Related Questions

Navigate

• Browse (All)
• Browse Q
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.