Юзергайд зі створення якісного баг-репорту під час тестування
У цій статті ми хочемо поділитися з вами кількома порадами щодо складання звіту про помилки під час проведення тестування. Сподіваємося, ви знайдете відповідь на головне питання – що дійсно хочуть бачити розробники у ваших звітах.
Що таке звіт про помилки?
Звіт про помилки – це основний спосіб інформування розробників про проблеми, з якими зіткнулися користувачі в процесі роботи. Також він полегшує комунікацію між відділами: керівник проекту завжди буде в курсі якості розробки продукту, а технічні фахівці беруть в роботу усунення виявлених неполадок.
На жаль, лаконічність фрази “Х’юстон, у нас проблеми” підійде тільки для Центру управління польотами в Техасі. Тому давайте детально розглянемо основні характеристики якісного звіту, який допоможе зібрати воєдино всю цінну інформацію для поліпшення якості продукту:
- Чіткість. Ваш звіт повинен бути максимально конкретним, сконцентрованим на певній помилці, і досить докладним, детально описуючи поведінку помилки.
- Лаконічність. Вказуйте лише найголовніше і уникайте зайвого “шуму”.
- Унікальність. Завжди перевіряйте, чи не описувалася ця помилка раніше. Якщо так, то подумайте, якою інформацією можна розширити вже існуючий звіт.
Роль структури в звітах
Ще одне правило при складанні звіту про помилки – пам’ятати, що ви тестувальник ПЗ, а не Лев Толстой. І навіть якщо ви вважаєте, що процес полювання за багами схожий з описом баталій у романі “Війна і Мир”, то розробники точно воліли, щоб ваш звіт починався з “Епілог”.
Правила звітного етикету
Приказка «ви – те, що ви пишете» однаково застосовується як для письменників, так і для тестувальників програмного забезпечення. При написанні баг-репорту важлива не тільки стислість викладу, а й загальний тон вашого тексту. Повідомлення, які здаються грубими, що звинувачують або занадто прискіпливі, створюють негативне враження.
Давайте зупинимося на цьому моменті докладніше і познайомимося з основними принципами написання ввічливого звіту:
- Будьте обережні з тоном, в якому пишете звіт, тому що кожен розробник, чию роботу ви критикуєте, побачить ваш звіт.
- Не редагуйте вже існуючі звіти про помилки без дозволу власників. Кожен раз при внесенні правок залишайте свої ініціали і поточну дату.
- Не використовуйте баг-трекінгові системи для моніторингу продуктивності інших тестувальників і розробників.
- Налагодіть особисту комунікацію з розробниками, які будуть читати ваші звіти, щоб вам було простіше шліфувати текст звіту і робити його зручним для використання при виправленні помилок.
Ми з вами знаємо, що за усіма успішно запущеними проектами стоять десятки відправлених звітів про помилки, що виникають в найважливіший момент. Саме тому важливо, щоб баг-репорти були чітким, лаконічним, продуманим і, звичайно ж, ввічливим.
