Мені не потрібна твоя баг репорт! Давай до побачення!
нещодавно прочитав пару статей про "правильне" опис дефекту і вирішив в черговий раз поторсати тему управління дефектами на проекті. Я вже писав на тему того, які типи дефектів існують і як з ними бути в адекватної команді.
- Тестувальник знаходить дефект під час ручного тестування або використання продукту.
- Він повторює свої дії вручну з метою його відтворити (можливо кілька разів).
- Коли дефект потрапляє до розробника, той намагається його відтворити на своєму оточенні.
- Якщо не вдалося, то сценарій повторюється ще кілька разів на різних середовищах (еталонному, тестувальника, живому).
- Тепер розробник намагається знайти помилку і повторює ще кілька разів (можливо з включеним debug режимом).
- Проблема знайдена і виправлена, після чого розробник запускає сценарій ще раз для перевірки.
- Тестувальник також запускає сценарій для перевірки пару раз для впевненості.
- Будемо вірити, що проблема виправлена і все добре ... 🙂
В результаті, один і той же сценарій запускається не менше 7 разів. А в переважній більшості випадків набагато більше ... І все це робиться руками! А тепер додайте сюди проблеми розряду "це не повторюється на моїй машині" і "у мене немає часу дивитися на нові баги".
Воно і зрозуміло - зусилля з боку розробника на ручний прогін сценаріїв дуже великі, а розробники лінуються робити щось руками. Отримуючи інформацію про дефект, розробник заздалегідь розуміє, скільки зусиль йому потрібно буде зробити і ставиться до цього негативно.
Тут причаїлася і ще одна проблема - інтерпретація інформації. Тестувальник пише сценарій для відтворення, вкладаючи в нього наявну у нього інформацію. Потім розробник її намагається "декодувати" при читанні сценарію. І цей процес далеко не безпомилковий. Через це так часто і виникають проблеми взаєморозуміння.
Ну і остання проблема - ми всі знаємо, що дефект може проявитися знову. Тому сценарій повинен бути доданий до регрессионному тестування. А це означає, що його будуть запускати кожен раз при тестуванні продукту, що вимагає ще більше часу.
Так може варто відразу вкладатися в автоматизацію для дефектів? Адже питань про обсяг ручної роботи тут не варто. Мало цього, це буде ручна робота не тільки тестувальників, а і розробників. Важливо відзначити, що на короткому інтервалі можна навіть не дбати про підтримувані сценарію - адже завжди можна буде запустити ту ж версію коду і на ній прогнати сценарій. А це дуже сильно полегшує автоматизацію. Можливо, якщо у вас і так вже є автоматизація, то сценарій буде всього лише використанням вже реалізованих кроків зі специфічними даними і новими перевірками.
Якщо тестувальники замість написання чергової "історії дефекту" надаватимуть автоматизований скрипт, то багатьох перерахованих вище проблем можна буде уникнути. До того ж, можна буде відразу ж додати написаний сценарій в наявний тестовий набір або як раз і покласти початок автоматизації тестування. Задумайтеся про це на дозвіллі! 🙂
Не хочеш пропускати нічого цікавого? Підпишись на стрічку RSS або стеж за нами в Twitter !
Так може варто відразу вкладатися в автоматизацію для дефектів?