оцінювання ДЗ

Кроки для відтворення (англ. Steps to Reproduce, або STR) тісно пов’язані з отриманим фактичним результатом.

Тест-кейс (Test Case) – це сукупність кроків, конкретних умов і параметрів, необхідних для перевірки реалізації тестуємої функції або її частини

Будь-який тест-кейс повинен містити мінімально необхідну (і в той же час достатню) кількість інформації. Існує «золота середина» по відношенню до обсягу інформації в тест-кейсах. Якщо тест-кейс містить багато зайвої (другорядної) інформації – це уповільнює процес читання, розуміння і проходження самого тест-кейса. І навпаки, якщо інформації дуже мало – це призводить до непорозумінь, що саме необхідно зробити для того, щоб пройти тест-кейс.

Опис багів англійською мовою багато в чому нагадує їх опис українською. У той же час існують значні відмінності, зумовлені відмінностями в граматиці мов. Далі в статті будуть розглянуті поради і правила для всіх основних атрибутів баг-репорта.

У нашій постійній рубриці «QA поради новачкам» дуже важлива тема: правила опису результатів у баг-репорті.

Розглянемо правила оформлення теми тест-кейсів, приклади правильних та неправильних формулювань, поширені помилки.

Без сумніву, хороший баг-репорт – це документ високої якості. Написання якісного баг-репорта – це важливе завдання, адже саме баг-репорт буде основною точкою комунікації між тестувальником, розробником і менеджером проєкту. Добре написаний баг-репорт не тільки створить хороші взаємини між вами і розробниками, але і збереже ресурси компанії на роботу з ним.

Баг-репорт – це технічний документ, що описує ситуацію або послідовність дій, що призвела до некоректної роботи об’єкта тестування, з вказанням причин і очікуваного результату. Перерахуємо і детальніше розглянемо основні атрибути баг-репорта.

Правила оформления дефектов в баг-трекере в каждой компании свои. Но в любом случае хороший баг-репорт обладает определенными характеристиками. И для того, чтобы оформить баг-репорт грамотно, необходимо учесть несколько важных нюансов.

Як правильно описувати оточення при оформленні звіту про дефект в різних системах обліку дефектів (Jira, Mantis, Pivotal, Trello, Bugzilla).