Пройшов тестатон TestUAStartUps#6.
А перед ним мене попросили дати настанови суддям. Ось, що я їм казав:
Скоро новий тестатон! І для мене велика честь, що мене знову запросили туди у якості судді. Цього разу я спробую хоча б кілька годин побути і учасником теж: пошукаю й позаводжу баги, "сфокусуюся на головному для користувачів", як я сам завжди раджу учасникам.
В якості судді, перевіряючи результати тестування, найбільшу увагу хочеться приділити найсуворішим багам. Адже команда за один такий баг отримує у 8 разів більше, ніж за якусь дрібничку. З іншого боку, 8 зареєстрованих дрібничок дають стільки ж, скільки Blocker, тому ними теж не варто нехтувати.
Але мало просто знайти баг, треба його добре локалізувати, гарно і зрозуміло описати, та правильно визначити важливість. Саме ці три оцінки складають повний бал за баг-репорт.
В оцінку опису входить "загальний екстер’єр" баг-репорту та наявність скріншоту чи відео, коли це необхідно. Але навіть добре описаний баг із неправильно виставленою важливістю вже не отримає максимальний для цієї важливості бал. Тому годі сподіватися, що поставивши скрізь Severity = Critical ви наближаєте себе до перемоги. Якщо Critical виявляється Minor'ом, то команда не отримає навіть максимальний бал за Minor.
Те ж саме стосується локалізації багу. Гарно описаний та правильно зважений баг, що має 7 кроків відтворення замість 3 теж є кандидатом на зниження загальної оцінки.
Інша проблема, що часто трапляється у командних звітах - це дублікати. Найчастіше це один і той самий баг заведений різними членами команди. Це свідчить про погану комунікацію між учасниками. Втрачається дорогоцінний час на реєстрацію дефекту. Але особисто мені не хочеться витрачати час суддів на те, за що ми не додаємо команді балів. Адже всі додаткові копії вже зареєстрованого у звіті дефекту мають не більше нуля.
Також чомусь всі команди зосереджуються на тестуванні, і всі забувають, що Test Summary Report - це теж важливо та корисно. Передусім, для стартапів - вони ж прийшли дізнатися, в яких областях у них найбільше багів. І найголовніше, Test Summary Report - це окрема номінація!
І як завжди скажу, що XSS та SQL ін’єкції - це прикольно. Тому можете вже зараз приготувати парочку шаблонів, щоб швиденько оцінити, чи думали програмісти та архітектори про безпеку своєї системи.
Сподіваюсь, цього разу побачити багато дуже важливих та ще більше недуже важливих багів, але щоб всі вони були цікаві й непересічні :-)
Наснаги та натхнення!
А перед ним мене попросили дати настанови суддям. Ось, що я їм казав:
Скоро новий тестатон! І для мене велика честь, що мене знову запросили туди у якості судді. Цього разу я спробую хоча б кілька годин побути і учасником теж: пошукаю й позаводжу баги, "сфокусуюся на головному для користувачів", як я сам завжди раджу учасникам.
В якості судді, перевіряючи результати тестування, найбільшу увагу хочеться приділити найсуворішим багам. Адже команда за один такий баг отримує у 8 разів більше, ніж за якусь дрібничку. З іншого боку, 8 зареєстрованих дрібничок дають стільки ж, скільки Blocker, тому ними теж не варто нехтувати.
Але мало просто знайти баг, треба його добре локалізувати, гарно і зрозуміло описати, та правильно визначити важливість. Саме ці три оцінки складають повний бал за баг-репорт.
В оцінку опису входить "загальний екстер’єр" баг-репорту та наявність скріншоту чи відео, коли це необхідно. Але навіть добре описаний баг із неправильно виставленою важливістю вже не отримає максимальний для цієї важливості бал. Тому годі сподіватися, що поставивши скрізь Severity = Critical ви наближаєте себе до перемоги. Якщо Critical виявляється Minor'ом, то команда не отримає навіть максимальний бал за Minor.
Те ж саме стосується локалізації багу. Гарно описаний та правильно зважений баг, що має 7 кроків відтворення замість 3 теж є кандидатом на зниження загальної оцінки.
Інша проблема, що часто трапляється у командних звітах - це дублікати. Найчастіше це один і той самий баг заведений різними членами команди. Це свідчить про погану комунікацію між учасниками. Втрачається дорогоцінний час на реєстрацію дефекту. Але особисто мені не хочеться витрачати час суддів на те, за що ми не додаємо команді балів. Адже всі додаткові копії вже зареєстрованого у звіті дефекту мають не більше нуля.
Також чомусь всі команди зосереджуються на тестуванні, і всі забувають, що Test Summary Report - це теж важливо та корисно. Передусім, для стартапів - вони ж прийшли дізнатися, в яких областях у них найбільше багів. І найголовніше, Test Summary Report - це окрема номінація!
І як завжди скажу, що XSS та SQL ін’єкції - це прикольно. Тому можете вже зараз приготувати парочку шаблонів, щоб швиденько оцінити, чи думали програмісти та архітектори про безпеку своєї системи.
Сподіваюсь, цього разу побачити багато дуже важливих та ще більше недуже важливих багів, але щоб всі вони були цікаві й непересічні :-)
Наснаги та натхнення!
Немає коментарів:
Дописати коментар