Добавить юзера c обычной подпиской
Стань тестировщиком сегодня
Level 6 Bug-tracking systems
Welcome to the ice planet Hot! After passing its tough challenges you will learn to work as a team with other IT professions. And the bug-tracking system will help you.
Every tester that works in a company consisting of more than 2 people works with a bug-tracking system. Let's see what kind of system it is in terms of JIRA example.
As far as I know, the bug-tracking system term usually refers to the application program designed for the following purposes:
- to help software developers (programmers, testers, etc) consider and control the errors and problems found in the programs,
- to do customer support,
- and to monitor the troubleshooting process and performance or non-performance of any IT processes.
Why are we using Jira as an example? Because it is better?
- One can't say for sure.
- Maybe because the author used it when making this course level?
- Who knows... He also used Redmine much in due time.
Let's put it this way, Jira is a more common bug tracking system than all the rest, but it is not an absolute leader. Jira actively develops, new modules are added constantly, since this is a commercial project, in contrast to the slowly developed open-source projects. It's important to understand one thing - all bug-tracking systems are similar, and by being able to work in one of them, it will take you a few hours to get familiar with any other.
What is in JIRA?
By and large, any tracking system is a means of electronic document flow. Since all IT folks stand for green trees and against papers that always get lost, every necessary document is formalized as a task. Tasks may include almost anything: write a program, test it, configure the server for it, and even replace a damaged hard drive in a working laptop. The types of tasks that you will encounter at work:
Projects structure
-
Allows you to assign, prioritize, track, create reports, process and monitor "bugs"
-
Extended platform that can be configured for specific business processes
-
Increases productivity by reducing the time loss associated with tracking the progress of problem solving and coordination
-
Improves performance quality due to the fact that the execution progress of all tasks is recorded in detail until the full completion of the tasks
How Jira is used
Jira is used to formalize the relationships in the IT team. The tester must consider the bug-tracking system primarily as his own defense. All bugs, testing tasks should be documented in the system with a registered status and result. Let's look into some practical examples:
1. You are called by the boss for reporting:
BOSS: What have you been doing the whole past week?
Silly QA: Eeeh... Mmmm... Tolny asked me to check the new design of the disk shop
BOSS:
- What specific task were tested?
- What was the amount of work?
- How many bugs have been located?
- How many of them were fixed?
Silly QA: (begins to look silly) Wait, I shall look into my papers, there were mentioned about 12 errors.
Smart QA: According to my QA task 8 critical errors, 3 major and 2 minor errors were found. 8 bugs are already fixed. The list of completed tests is in Jira testing task.
By keeping electronic records and opening tasks and bugs in the bug tracking system you can always get the report of your work. And most importantly, you can monitor progress and see the testing status.
2. The users complain about the bug that the product manager defined as a "feature":
BOSS: Why the bug wasn't found?
Silly QA: I found this bug, honestly, but the programmer said that this is a feature and it doesn't need to be recorded.
Developer: I was doing everything according to the specification, it doesn't include anything about that.
Product manager: This is an obvious bug, but I didn't know anything about it, the testing team didn't inform me about it.
BOSS: We'll have to dismiss such an irresponsible tester!
Smart QA: I recorded the bug. Here is the task - SAS-3412. Product manager closed it as a "not a bug". I did my job, this is his responsibility.
Even if you think it is unlikely that your bug will be fixed, by documenting it you protect yourself in case it turns out that it's actually a bug during program operation.
Why JIRA?
Example of the project structure
The project structure in bug-tracking systems can be commonly represented with this table:
Let's look into how this structure works on the example of the manufacturing plant of rebel fighters, which produces the fighters to destroy the Death Star:
-
Bug reports / Let you track the progress of error fixing.
-
HelpDesk (Customer support / Service maintenance). From here you will know about the omitted bugs. Let's not make it happen!
-
Project management / These are manager features - let you record completed tasks, time spent, code quality, etc.
-
Task execution progress management / Creation of the specific workflow.
-
Requirements management / Creating tasks for programmers for software development.
-
Workflows / Workflow visualization via diagrams, tables and filters of current tasks.
Working with defects
(Defect tracking in the JIRA system)
The diagram below shows the basic life cycle of a bug recorded in the bug-tracking system. Once you create a new bug report, it automatically receives the "new" status. The bug report should be assigned to a programmer or a test manager (if there is one). Then the bug has three options: 1. "Rejected" by the spell - "it's not a bug, it's a feature", 2. "Opened" - if it was accepted, or 3. "Deferred" - for now. These three states are of the same rank, so the bug can pass from one of them to another. Later, if the bug is fixed, it will get the "Fixed" status. If the fix doesn't pass the test, the bug is reopened and assigned to the same programmer. This is repeated until the bug passes the test, then it is "Closed".
P.S. The closed bug can also be reopened if it appears again, for example, in another program version or in a related project.
It was noted in the description above that it is the basic scheme. Since the bug-tracking system is flexible, and the workflow is customized by your company at its discretion. For example, one can add the status - "In the boss office", and the boss will check every bug before it is fixed. A feature of my company was the bug status "In QA progress". It means that the issue is assigned to a tester, it is used to ensure that two workers do not work on the same issue. Next, let's consider a specific example of defect lifecycle in Jira.
By the way, you must be questioning what the Issue is? Issue - the electronic document instance in the bug-tracking system.
A tester creates a new bug
The bug gets the "Opened" status and awaits a programmer to be assigned
Well done! The bug is assigned and being fixed. Waiting for fix
Studied the bug (reproduced according to your scenario)
Анализ бага
Setting the testing environment
Direct error correction in code
The bug is marked as fixed. Go ahead, tester!
Here one checks if the bug is fixed. And now the bug has 2 options
Fix is accepted and confirmed
Not fixed, or not completely fixed. Everything is repeated, the bug is assigned again
The bug is closed, well done!
Controversial case. Discussion whether to accept such a fix or not?
Bug report example in Jira
How cold is here, at this level ...
Brrrrr .....
See quickie the sample issue of a bug report to keep warm, they say that a good test documentation warms soul of a tester.
You have already met a bug report in its pure form, and now carefully examine how it is transferred to Jira. Remember the order and the principle of its filling, because in the end of the level you will have to deal with testing and the creation of bug reports in practice. Remember everything well here, do not forget to jump to keep warm.
Working with defects - role tracking
Home page example
The diagram below shows circulation of the issue across testing roles during the first part of its lifecycle (before the bug is assigned to a developer). This part is very important since in addition to describing the bug, it is necessary to assign it a priority, severity, put down the sprint, labels, etc., as well as solve points at issue with a product manager regarding each of these points. You will learn more about the roles in testing on the eighth level. Note that this is an ideal scheme which looks so only for large companies, where all these employees are present. In other cases, all of these activities are the same, but these roles are performed by one and the same person. That is, you should be able to set the priority and importance, assign the right programmer for fixing, as well as argue with a product manager regarding the controversial issues and be able to prove your point of view.
What does Jira start from? Jira, as any other web-system, starts with a home page. This page is customizable, that is, you can add the modules that you are interested in. The standard set includes: project news, tasks, favorite task filters.
Assigned to me задачи закрепленные за вами
Agail board
I start my morning with Agail board and coffee. This table includes a list of all the active tasks in the company. Each column corresponds to a specific task status: what is still developed, what failed testing, what awaits testing, what was tested and what passes the tests successfully (Pass QA).
You may ask, what is Agail board? Hmmmm! A visual display of bugs and tasks for the current sprint with status division (and with a variety of additional indicators) in our case - it is.
1
2
3
4
5
So that you can easier understand the picture:
-
In Dev - the tasks under development
-
Fail QA - something that failed testing
-
Ready for QA - something that awaits testing, job source for a tester
-
QA in progress - something that undergoes testing at the moment
-
Done - something that is completed/tested/bugs fixed
Favorite filters - наиболее часто используемые фильтры jira задач
DEV task
DEV task - this is the development task, the primary document that a tester starts working with when testing new features. The development task is created for everyone in the company, but first of all, for a programmer. This document contains all the key information about the problem + references to more detailed documents, such as the specification if the feature is large, if not, everything is described in the issue.
This document arrives to a tester from the Ready for QA column, when the development is completed and it's time for testing. Let's look through the main points of the DEV task:
Project name
Current task status panel
Button for task creation
Unique task number
The main description
Information regarding the task
Application for the screenshots and necessary files
Related issues or tickets in Jira
Activities: commentaries, activity history, questions
Edit button
Task name
Subtasks
Dates of creation, update and closure of the task
Let's look at the current task status panel in more detail
-
Type - Task type.
-
Priority - Priority.
-
Affects versions - The version in which the bug was found.
-
Labels - The logo indicating that it belongs to some feature, structure, release, etc.
-
Epic link - Similar to label, but it forms a rigid structure and automatically generates tasks relationship and a filter.
-
Status - Current bug status. Pass QA/Fail QA/Resolved/Closed/In progress/Open/Reopen...
-
Resolution - Verdict regarding the bug. It relates to status, but includes additional information. E.g., if the bug is closed, the Resolution indicates why it was closed: fixed / not a bug / duplicate / can't reproduce...
-
Fix version - The version that contains the bug fix. The bug is checked in this or later version.
And how can we now understand the difference between an epic link and a label, as well as a Status and a Resolution??
Alternative systems
The author fully recognizes that there are so many kinds of bug-tracking systems, as well as other automated document management systems, as there is fish in the sea, or users in the Internet. They are all similar and will become an easy to use helpful means for the one who can test and knows how to record a bug properly. Let's look at some similar systems in order to broaden the mind and be ready for anything.
The second most popular system after Jira is Redmine. Its main difference is that it is open-source based. Therefore, in order to manage it, one needs to have certain skills working with Linux. But this absolutely shouldn't concern the testers. We only work with the interface. You will find a more detailed comparison of the systems in this article.
Articles to read on the topic
1. Comparison of popular bug-tracking systems
2. Video-review of some popular tracking systems
Bug
Finally, we got to the bug description. Don't worry - it is very similar to the bug report standard that we have already learned on the previous level. But creating a bug report in Jira is mere pleasure. The whole structure is ready, one just needs to select the necessary value. Moreover, usually a unified diagram of bug description is designed, which is added as a template when creating a bug.
The standard bug description must contain: testing environment (server name), device/software exposed to the bug (browser name), preliminaries - preconditions, test scenario, Actual and Expected outcome.
Bug description
The current task status panel is similar for all task types. The only difference is the type - bug
Description - alternative description (it is not necessary in case everything is already entered into QA info)
Bug screenshot
Activity, commentaries, history, questions
Questinos and summary
Educational video
Educational video will be the cherry on our Jira cake. After reviewing it, start to practice!
For further in-depth study here is a link to the Jira University. There you will find a full training course on this bug-tracking system from the manufacturer.
Practice
Create a training bug - any from your homework. Assign it to the project administrator.
Enter the Jira portal.
You need to be granted access to a Jira project in order to enter. Let me know if you didn't receive the letter with an access.
Home task
Dear future tester, before you move on, I'll recommend you some articles for further reading on the topic of this level:
How the sprints are planned at the Yandex department
Для перехода на уровень 7, необходимо набрать минимум 13,8 баллов (60%) за задания уровня 6.
Level 7
