Search
  • Marinka Shevchenko

Рекомендації від судді 5ти тестатонів Олексія Бурдіна


Олексій став вже "почесним" суддею тестатону Test UA Startups. Він старожил, який брав участь у 4 з 5 проведених. Тому кому, як не йому розказувати на що звертають увагу судді тестатону, за що знімаються бали та як отримати найкращі результати за всього 5 годин тестування.


Скоро новий тестатон Test UA Startups #6! 

І для мене велика честь ще раз бути запрошеним суддею.


Як суддя, перевіряючи результати тестування, найбільшу увагу приділяю найкритичнішим багам. Адже команда за один такий баг отримує у 8 разів більше, ніж за якусь дрібничку. З іншого боку, 8 зареєстрованих дрібничок дають стільки ж, скільки Blocker, тому ними теж не варто нехтувати. Тому тут вже питання до стратегії самої команди чому краще приділяти час: пошукам одиничних criticals або ж на заведення великої кількості minors. 


Але мало просто знайти баг. Його треба добре локалізувати, гарно і зрозуміло описати, та правильно визначити severity(важливість). З цих трьох оцінок і складається повний бал за баг-репорт. 


В оцінку опису входить "загальний екстер’єр" баг репорту та наявність скріншоту чи відео за необхідністю. Але крім хорошого bug description, ще потрібно правильно визначити і severity дефекту. Інакше, цей баг вже не отримає максимального балу. Тому годі сподіватися, що поставивши скрізь Severity = Critical ви наближаєте себе до перемоги. Якщо Critical насправді виявляється Minor'ом, то команда не отримає навіть максимальний бал за Minor. 


Те ж саме стосується локалізації багу. Гарно описаний та правильно зважений баг, що має 7 кроків відтворення замість оптимальних 3-х теж є кандидатом на зниження загальної оцінки. 


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

Тому не потрібно витрачати час суддів на заведення таких дефектів, адже всі duplicates все одно оцінюються нулями.


Також чомусь більшіть команд, з мого досвіду, зосереджуються лише на тестуванні і забувають, що Test Summary Report - це теж важливо та корисно. Передусім, для стартапів - вони ж прийшли дізнатися, в яких областях продукту у них найбільше дефектів. І найголовніше, Test Summary Report - це окрема номінація!


І як завжди скажу, що XSS та SQL ін’єкції - це прикольно. Тому можете вже зараз приготувати парочку шаблонів, щоб швиденько оцінити, чи подумали програмісти та архітектори про безпеку своєї системи.


Сподіваюсь, цього разу побачити багато критичних та ще більше minor / trivial / improvement, але щоб всі вони були цікаві й непересічні :-)


Наснаги та натхнення!


автор

Олексій Бурдін

0 views

2015 - 2018  © All Rights Reserved

  • Black Facebook Icon
  • Black LinkedIn Icon