Про важливість репортів

#testing

Читаю зараз книжку “Software Testing Strategies” та натрапив на важливу інформацію про репорти. Хочу поділитися нею з вами.

Одна з ключових навичок (про яку часто забувають) - це вміння доносити до менеджмента результати тестування (test summary report).

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

Які рішення треба прийняти менеджеру?

- Чи можна вже релізитись?
- Якщо зараз не можна, то коли можна буде релізитись?
- Шо треба пофіксити, щоб вийти в продакшн в стані “good enough”?
- Чи готова ця фіча для демо? Чи можемо ми викатити конкретну фічу?

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

Що включає в себе хороший репорт:

- Репорт представляє менеджменту варіанти. “Можна зробити це, можна - інше. А можна - взагалі щось третє”. Коли ви даєте тільки один варіант - ви позбавляєте людину вибору. З двома варіантами - менеджмент має дилему. З трьома - керівник відчуває, що має контроль.
- Репорт включає в себе невеличкий список найкритичніших багів та чому саме вони є критичними.
- Репорт розповідає що саме ви НЕ протестували. Менеджмент зможе прийняти рішення, базуючись на тому, які баги вже є - чи потрібно далі тестувати ту чи іншу фічу додатково. Бо якщо ми не будемо фіксити наявні баги - нащо поглиблюватись далі та витрачати час.

Дайте менеджменту інформацію. Дозвольте їм бути частиною рішення.
Потім той менеджер не зможе критикувати вашу роботу - бо ж сам приймав в цьому участь.