Как правильно оформлять баги, которые будут понятны всем HOW TO PRESENT THE BUGS SO THAT EVERYONE UNDERSTANDS?

Как часто вы или ваши коллеги сталкивались с проблемой описания найденного дефекта? Например, разработчик вернул дефект с комментарием «не смог воспроизвести». Тестировщик смотрит, воспроизводит и снова переводит баг на разработчика. Затем разработчик и тестировщик начинают выяснять есть баг или нет бага. В итоге оказывается, что дефект действительно есть, но разработчик не смог его воспроизвести по описанному сценарию. How often did you or your colleagues face a problem of describing an identified bug? For example, the developer returned the defect with the comment "could not reproduce". The tester checks reproduces and redirects the bug to the developer. Then both the tester and the developer start figuring out whether there actually was a bug or not. Finally, it turns out that there is a defect but the developer could not reproduce it according to the scenario.

Для того чтобы избежать подобной ситуации, сэкономить время проектной команды и не провоцировать лишние конфликты, необходимо корректно оформлять найденные баги.Разберем основные правила при оформлении дефекта. To avoid situations like this one, save the time of the project team and not cause extra conflicts, the identified bugs have to be properly presented. Let us discuss the main rules of presentation of a defect.

1) Название. 1) Name.

Важно понимать, что описание помогает коллегам воспроизвести баг и найти причину бага, но название должно говорить о том, где и какая проблема. Старайтесь придерживаться следующего формата: «Название проекта. Название модуля. Проблема». К примеру: «Документооборот. Договора. Не работает поиск». Такое правило очень помогает понять сразу где проблема, особенно полезно, когда на проекте более двух разработчиков, сразу становится понятно, кто будет рассматривать данную проблему. It is important to understand that the description helps the colleagues to reproduce the bug and find what is causing it but the name of the bug must specify what and where is the problem. Try following the format: "Project name. Module name. Problem". For example: "Document management. Contracts. The search function is not working". This rule helps a lot to understand where the problem is. If there are more than two developers on the project, it gets clear who is to solve the problem.

2) Серьезность дефекта. 2) Defect severity.

У дефекта также есть градация. Команда в первую очередь будет рассматривать критичные и блокирующие дефекты, а дефекты низкого приоритета будет смотреть в последнюю очередь. Упрощайте своей команде жизнь и оцените серьезность дефекта. Defects are different. The team will first of all evaluate the critical and blocking defects while the low priority defects will be considered last. Simplify the life of your team and evaluate the severity of the defect.

3) Ссылка и тестовое окружение. 3) Link and text.

Прежде чем описывать дефект, необходимо указать где вы его нашли и при каких условиях. Например, если это веб-проект, то обязательно укажите название браузера, его версию и прикрепите ссылку на этот проект. Это очень поможет при воспроизведении ошибки. Опять же на примере веб-проектов, иногда ошибка воспроизводится в каком-то конкретном браузере, когда во всех остальных браузерах ошибка не воспроизводится. Prior to describing the defect, it is essential to specify where you found it and under what conditions. For example, if it is a web project, specify the name and version of the browser and insert the link to the project. This helps tremendously in reproducing the error. Coming back to the example of web projects, sometimes the error is reproduced in one particular browser, while in all other browsers it is not.

4) Права и роль текущего пользователя. 4) Rights and role of the current user.

На большинстве проектов, которые мы тестируем присутствует ролевая модель. Например, есть администратор, владелец или обычный пользователь. У каждого пользователя свои права на проекте, поэтому под одним пользователем функционал может работать, но под другим пользователем та же система может давать ошибки. Если вы укажите пользователя, его роль и права на момент тестирования - это облегчит и ускорит поиск причины ошибки. In the majority of the projects that we test, there is a role model. For example, there is an administrator, a master and a user. Each user has the rights in the project therefore for some users the function may work but for others the same system will display an error. If you specify the user, her role and rights at the moment of testing, this will simplify and facilitate the search for the reason of the bug.

5) Сценарий. 5) Scenario.

Сценарий - это те шаги, которые будет выполнять разработчик для воспроизведения найденной ошибки. От того как описан сценарий, будет зависеть, сможет ли он воспроизвести дефект. Старайтесь максимально подробно описать ошибку, но пишите в описание больше конкретики. Детализируйте сценарий по шагам, старайтесь каждое новое действие вынести в новый шаг. Например: «1. Перейти на страницу с договорами. 2. Нажать на кнопку «Создать». 3. Заполнить обязательные поля. 4. Загрузить договор. 5 Нажать кнопку «Сохранить». Как мы видим сценарий описан подробно, при этом нет никакой «воды». A scenario is the steps that the developer will execute to reproduce the identified error. The test of the scenario determines whether she will be able to reproduce the defect. Describe the bug in as much detail as possible and add more specifics to the description. Specify the scenarios by steps and try to make a new step for every action. For example: «1. Go to the page with the contracts.2. Click "Create". 3. Fill out the mandatory fields. 4. Load the contract. 5. Click "Save". As we can see, the scenario is detailed and there is no excessive information.

6) Ожидаемый результат. 6) Expected outcome.

Это тот результат, который вы ожидали получить в ответ на свои действия. Или тот результат, который должен быть по документации или тест-кейсов. Обязательно напишите в ошибке, что вы ожидали увидеть. При возможности дайте ссылку на документацию. It is the outcome you expect as the result of your actions Or it is the outcome according to the documentation or test cases. Add to the description what outcome did you expect. If possible, provide a link to the documentation.

7) Фактический результат. 7) Actual outcome.

Тот результат, который вы получили, после выполненных действий. Опишите максимально полученный результат. Возможно из этого описания разработчик поймет причину ошибки. Actual outcome is the outcome that you got after the actions you made. Describe the outcome in as much detail as possible. Probably, this description will allow the developer to understand the cause of the bug.

8) Скриншоты и логи. 8) Screenshots and logs.

Если есть возможность и необходимость, приложите скриншоты и системные логи с ошибкой. Это, опять же,экономит время разработчикам при анализе дефекта. If it is possible and necessary, attach screenshots and system logs with the bug. This will save the developers’ time when analyzing the defect.

Придерживаясь такого формата описания дефекта, вам и вашей команде будет легче работать с дефектами, а менеджерам будет проще анализировать дефекты на проекте. Following this format of bugs description, will simplify working with defects for you and your team, while it will be easier for the managers to analyze the project defects.

2017-06-02

Как правильно оформлять баги, которые будут понятны всем HOW TO PRESENT THE BUGS SO THAT EVERYONE UNDERSTANDS?

Напишите намSend us an E-mail

Обратная связьCONTACT US

Ваше письмо отправлено!Your letter has been sent!