Лекція №1. Основи тестування ПЗ

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

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

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

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

Знімок екрана (Screen capture) – можливо один з найефективніших варіантів поділитися тим, що відбувається на екрані монітора. Технічним користувачам, таким як тестувальники, це дозволяє краще комунікувати між учасниками проєкту.

Глосарій термінів та визначень для роботи курсантів в баг-трекері Mantis.

Не помиляється тільки той, хто нічого не робить. А наші курсанти роблять дуже багато в процесі вивчення нової професійної галузі. Виконуючи завдання на курсі, слухачі вчаться і на чужих, і на своїх помилках. У цій статті ми зібрали найпоширеніші помилки курсантів в описі баг-репортів. Сподіваємося, ця стаття допоможе краще розібратися з тим, як робити не варто і як формулювати зрозумілий та повний опис суті бага.

Перед тестувальником стоїть нелегке завдання – донести знайдену помилку до розробника і бути зрозумілим. Що допоможе краще зрозуміти проблему, ніж її наочний приклад? Саме вкладення є одним з основних атрибутів баг-репорту. Тому до баг-репорту просто необхідно прикріпити всю інформацію, яку вдалося зібрати.

В ході роботи з баг-репортами часто доводиться звертати увагу на необхідність чітко і коротко формулювати «Summary» дефекту. У самій назві повинна міститися достатня кількість інформації, щоб зрозуміти, про який баг йде мова, прочитавши тільки заголовок. Такий опис дозволяє швидко зрозуміти і відтворити описаний баг.

В нашій постійній рубриці «QA поради новачкам» ми розглянемо випадки використання артиклів, прийменників і правильного порядку слів в звітах про помилку.