Нотатки мого суддівства DEV Challenge в номінації тестування

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привіт друзі! Я — Олексій Остапов, Head of Test Automation Practice в Infopulse, автор блогу QA Mania та один з ведучих подкасту Питання Якості на DOU.
І цього року я — головний суддя DEV Challenge в номінації тестування 🥳

Ми з колегами підготували для учасників цікаві завдання і вже активно займаємось перевіркою результатів. Паралельно робимо нотатки, які потім зберуться у фінальний звіт. Частиною цих нотаток я хочу і можу поділитись вже. Нотаток багато, тож навіть не намагатимусь зібрати все в один допис.

🧐 Загальний аналіз

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

1. Правила однозначно кажуть, що не можна ніде вказувати своє ім’я чи іншим способом намагатись себе ідентифікувати, щоб оцінки суддів були неупереджені. Нажаль, ми дискваліфікували тих учасників, що вказали своє ім’я в імені файлу, в якому здавали роботу, в супроводжувальному коментарі чи в полі Reporter в написаних баг репортах.
2. Інше правило вимагало всі роботи завантажувати у вигляді файлу на портал challenge’у. Але деякі учасники не зробили цього (оце біль, робити роботу, і забути її відправити) чи дали посилання на хмарні сховища. Тож вони отримали заслужені 0 балів
3. Ще були учасники, що виконали завдання одночасно декількох категорій складності, але вибірково (всього було 3 легкі та 3 складні) — здані були 2 легкі та 2 складні. Таке завзяття мені подобається, але додаткових балів за це ми надати не можемо

Також пропоную розглянути перше завдання online раунду з тестування

Це завдання було спільним для всіх учасників.

Протестувати калькулятор площі. Примітивний, на перший погляд, застосунок: вказуєш 2 числа в м, отримуєш добуток в найближчій цілій одиниці площі.

Для того, щоб зробити тестування цікавішим та інтерактивнішим, до цього застосунку я додав з десяток багів і написав ТГ бота, який має допомогти прорватись через блокери до робочої версії.

Застосунок я планую і надалі залишити активним, тож як маєте час і бажання — досліджуйте і тестуйте!

Трохи аналітики:
✅ переважна більшість учасників впоралась з інструкціями і змогла отримати фінальну, робочу версію програми, яку можна протестувати. Більшість учасників вміє користуватись Dev Tools 💪
✅ всі знають про концепцію smoke test — якщо застосунок не виконує свою основну функцію (має блокери) — то нема потреби витрачати час на його тестування. Деякі учасники забули про це правило і надали тестовий звіт, в якому тестували всі 3 версії застосунку, хоча в цьому нема жодного сенсу. Не робіть так!
✅ сама програма — класична задача на класи еквівалентності та граничні значення. Подібні до цієї я на співбесідах іноді прошу потестувати. Я був дуже здивований, що в тестовому звіті учасники правильно визначили всі класи еквівалентності, але майже ніхто не перевірив границі! Ну як так?
✅ Тут же варто згадати про тест дизайн взагалі — він же існує не просто так, а для того, щоб тестувати ефективно і оптимально. Якщо спитати, скільки тестів треба, щоб перевірити 5 класів еквівалентності, майже кожен тестер відповість: «5 тестів, по одному на кожен клас, 4 тести на границі між класами + деяка кількість негативних класів (наприклад, ввести букви замість числа)».

Я додав метрику до калькулятору площі, щоб подивитись на кількість тестів, яку виконували учасники, щоб протестувати основну фічу:
➡️ Середня кількість: 430 перевірок
➡️ Медіана: 98 перевірок
➡️ Рекордсмен з тестування: 4208 перевірок

✅ Root cause analysis — важлива штука. Приблизно половина тестових звітів, містила по 2-3 різні баги, у яких, насправді, одна причина. Тобто баг насправді лише один, треба лише ретельно проаналізувати побачену поведінку
✅ Кожен третій учасник, по моїм даним, обрав категорію Hard, і мав окрім калькулятору протестувати ще й бот. Класичний state transition. І більшість учасників впорались із завданням. Але один з найочевидніших багів, який бачили всі учасники, ніхто не зарепортив (серед тих робіт, що я перевіряв) — коли бот питає категорію, дає 2 кнопки на вибір: Light та Hard. Бачите баг?😁

Також я додав в бот 3 великодки, які знайшло лише 10% всіх учасників:
➡️ спробувати написати боту кирилицею (він спілкується тільки англійською). Чомусь при тестування input поля на формі, всі перебирають цифри, букви, спец символи. А коли треба тестувати бота, який по суті, приймає той самий інпут, всі одразу такі чемні
➡️ спробувати змінити категорію, після того, як обрали категорію
➡️ спробувати запропонувати свою категорію. Так, бот показує 2 кнопки, але ж поле вводу нікуди не зникає
Великодок я планував більше, але за браком часу не встиг зробити. Залишу ідеї на наступний рік!

Висновки прості — освіжайте в пам’яті теорію тестування — вона допоможе робити роботу швидше і якісніше. І тестову теорію можна застосувати з кожним застосунком, яким є навіть боти!