Як тестувальнику розпочати роботу на проекті з нуля

Десь рік тому я вирішила змінити фриланс на класичну аутсорс-компанію: мій внутрішній мізантроп загнувся остаточно й захотілося до людей. Один з оферів був з проекту, який щойно почали розробляти, і, звісно, я вхопилася за нагоду долучитися до проекту від початку. Я пройшла кілька кіл пекла співбесід і страшно пишалася собою, що «взлетіло». Але першого ж робочого дня від словосполучення «страшно пишаюся» залишилося тільки «страшно».

Що насправді відбувається, коли ти приходиш у новий проект і в нову команду? Тебе оточує невідомість. А маючи справу з невідомим, наш мозок починає бити на сполох. Загалом, нам, українцям, до невідомого не звикати, маємо з цим справу після кожних виборів :) Тому й з новими проектами точно впораємося. Але, сподіваюся, ця стаття допоможе тестувальникам стартувати проекти з погляду забезпечення якості впевненіше.

Спочатку з’ясуймо, що таке оця невідомість, яка нас оточує в перші дні життя проекту. Невідомість — це те, чого ми не знаємо, або те, чого не можемо передбачити. Вона аж ніяк не довільна (нехай буде що буде), вона просто складна (тобто складається з частин). Наприклад, багато хто чув про хмарне середовище, і часто ми говоримо, що десь там у клауді щось відбувається або зберігається. Але хмари нема, а є просто чийсь чужий комп’ютер. Це означає, що все складне ми можемо розбити на менші частини, які перетворять невідомість — на «відомість», а страх перед нею — на дію (на таски).

З чого складається процес тестування

Насправді, усі складники тест-процесу вже давно досліджено, згруповано та зорганізовано у фундаментальний тест-процес. Для фанатів теорії можна заглянути в ISTQB syllabus і почитати більше. На початку становлення проекту ми знаходимося десь у цій хмарці:

Ми розпочинаємо процес з планування і встановлення певних маркерів (метрик) для того, щоб переконатися, що дотримуємося плану й не кричати потім: «Штірліц, всьо пропало!» На цьому етапі ще не має самого застосунку, який розроблятимемо під час реалізації нашого проекту, тому часто здається, що в нас нема ніякої інформації, та й тестувати там нема що. Але чи це й справді так?

Що ми вже можемо знати на день 0 (і ні, то не про zero day vulnerability)? Я розділила всю вхідну інформацію, яку ти маєш на початку проекту, на кілька категорій:

• Домен.
• Бюджет.
• Замовник / ключові особи (стейкхолдери).
• Документація.
• Команда.
• Залежності.

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

Домен

Домен, по суті, то є тип бізнесу, з яким ми працюємо. Наприклад, healthcare, automotive, ecommerce, fintech. Залежно від типу бізнесу, можна визначати додаткові обмеження й ризики, які з ним пов’язані, сертифікації тощо.

Наприклад, у галузі охорони здоров’я є чіткі стандарти, яких треба дотримуватися (як-от HIPAA). У такому разі ми можемо прогнозувати наші тестові активності так, щоб вони покривали всі вимоги цього стандарту.

Один з моїх проектів був тісно пов’язаний з різноманітними платежами. Очевидно, є чіткі вимоги щодо безпеки, коли йдеться про гроші (наприклад, довелося ознайомитися з протоколом 3D Secure) й чимало інших нюансів, які треба брати до уваги під час тестування (ось простенький приклад: тестуючи платежі в японських єнах, треба пам’ятати, що в них нема монет, тому платежі можна проводити тільки в цілих числах, а особливо це важливо під час підрахування комісії).

Або, наприклад, ви розроблятимете ПЗ з використанням третьосторонніх систем. Їх обмеження та SLA теж уже відомі наперед. Тому навіть не думайте використати iTunes для розробки ядерних ракет, це чітко заборонено їхньою ліцензією. Також і безплатний ігровий движок від Amazon — Lumberyard — не можна використовувати для створення safety-critical software (так, ці теж знають, що зі здоров’ям бавитися погано). Проте Amazon має один виняток з цього правила, і це — зомбіапокаліпсис :)

Також хорошим прикладом є славно- чи то сумнозвісний GDPR. Є безліч доповідей на цю тему, але в усякому разі, якщо ти хороший тестувальник/тестувальниця, то точно знаєш 4 основні кроки впровадження GDPR у своєму проекті:

Бюджет

То не про печивко й смузі :) Так, так, я знаю, що фінансові деталі проекту — це зазвичай таємниця за сімома замками. Проте майже напевне ми знаємо, чи проект дотримується моделі time and material або fixed price. Для T&M ми можемо мати більшу гнучкість (докупити потрібні ліцензії та передбачити додаткові витрати на інфраструктуру), на fixed price — майже точно відомий скоуп робіт (а це полегшить планування тестових завдань) і ризики. Також треба з’ясувати, чи передбачено бюджет на наймання нових тестувальників. Але точно не варто спершу запитувати, чи є бюджет на тимбілдинги :)

Замовник/стейкхолдери

Тут варто розуміти, що замовники бувають двох типів: IT and non-IT. Основний бізнес ІТ-замовника — це розробка і продаж ПЗ (наприклад, розробка відеоігор чи мобільних застосунків). Для non-IT-замовників будь-яке програмне забезпечення потрібне: а) для додаткового заробітку (наприклад, інтернет-магазин) або б) для оптимізації витрат (наприклад, автоматизація нарахування зарплат). Варто також зрозуміти, ким будуть ваші контактні особи. Їх також поділяють на два типи: технічні й нетехнічні. Ця інформація нам знадобиться, щоб коректно керувати очікуваннями замовника: спланувати звітування, адже не всім потрібні технічні деталі й красиві, проте малоінформативні для них графіки; домовитися щодо прийнятних стандартів якості (наприклад, кількість відомих дефектів, допустимих у релізі та їхня severity) і щодо метрик.

Трапився в мене випадок, коли я «за замовчуванням» прикрутила Allure-звітування до автотестів і, як виявилося потім, у ці красиві графіки й звіти ніхто не заглядав, окрім мене. Замовника, насправді, не дуже цікавила кількість пройдених тестів, але, наприклад, метрика bug leakage була б для них кориснішою.

Документація

Здавалося б, не написано ще жодного рядка коду, а ми вже очікуємо якусь документацію. Але всякий тестувальник, навіть той, який після курсів, чув про вимоги, на підставі яких саме й створюють ПЗ. Можливо, вони ще не надто докладні, але на цьому етапі вже може бути низка високорівневих вимог (якийсь узагальнений беклоґ), можливо, буде узгоджено архітектурні підходи (наприклад, microservices vs monolith), а якщо тобі дуже пощастить, то, можливо, навіть дадуть якісь прототипи (wireframes). Також можна попросити почитати контракт (або його частину), особливо якщо там передбачено, наприклад, якісь умови постгарантійного обслуговування. Загалом, будь-які задокументовані домовленості можуть допомогти нам у плануванні тестових активностей.

Команда

Two possibilities exist: either we are alone on this project or we are not. Both are equally terrifying.

Є два варіанти — або ти будеш сам(а) в проекті в ролі тестувальника, або ні. Обидва варіанти лякають ) Перший — тому що нема з ким розділити весь невимовний сум і біль, які трапляються з усіма; другий — тому що нам тих людей ще потрібно буде найняти (а вибрати собі колегу, то майже як заміж вийти) або вони вже залучені до проекту, наприклад з боку замовника (тоді вам ще треба всі фази від Forming до Performing з ними пройти). Окрім того, чи будуть ще тестувальники на проекті чи ні, ми все одно знатимемо склад команди — девелопери, ліди, ПМ/скрам-мастер, продактовнер, бізнес-аналітик тощо. З ними всіма доведеться працювати, і що раніше ми визначимо цих людей, то легше нам буде скласти собі план комунікації з ними. Не менш важливим є формат співпраці із замовником: це може бути аутстаф-модель, може бути distributed-команда між замовником і вендором, розробка під ключ з colocated-командою, а може ти контрактор або консультант, що ненадовго залучений у проект з певною метою. Все це так чи інакше впливає на те, як ти будеш менеджити тестовий процес (наприклад, може знадобитися трохи більше метрик).

У часи, коли я почала працювати над одним проектом як контрактор, було насправді непросто налаштувати тестовий процес, оскільки працювала віддалено і на стороні клієнта нікого, відповідального за QA, не було. Мабуть, багато хто вважав мене ботом спочатку :) Усі інтеграції, які команда встигала завершити до кінця тижня, йшли в щотижневий реліз без повноцінного тестування. Довелося працювати з кожним окремим девелопером, щоб налагодити процес тестування, проробити необхідні чеклисти й встановити потрібні quality gates.

Залежності

У вас може бути залежність від кофеїну, наприклад, тоді треба додати в план постачання кави ) А якщо серйозніше, то варто розуміти залежності ще від початку, бо будь-яка залежність — потенційний ризик. Приклади залежностей: 3rd party-залежності (наприклад, інтеграція з MS Outlook), залежність від інших команд, залежність від наявної інфраструктури.

В одному з проектів наш продукт мав інтеграцію з іншим продуктом, який розробляли на стороні замовника. Залежність була велика, оскільки на початку не передбачалося використання «нашого» продукту без «їхньої» платформи. Long story short, наші автотести теж мали залежність від цієї платформи (і не треба зараз про моки, стаби й фейки :)), і саме тому все працювало не максимально оптимально, на мою думку. Ну і далі справдився один з ризиків — «їхній» продукт пішов у закат і нам довелося швидко «стати незалежними».

Загалом цих даних нам повинно вистачити, щоб узятися за планування. Ось тут я б не очікувала, що наш план буде незмінний, єдиний та суверенний ))) Змінюватиметься контекст, з’являтимуться нові домовленості й дедалі більше інформації — і план змінюватиметься. Але сам план повинен нам допомогти «перезуватися на льоту» трохи рідше.
Тепер наше «невідоме» вже не таке й невідоме. Проаналізувавши ці інпути, ми повинні відповісти на такі запитання:

1. Навіщо ми тестуватимемо?
2. Що в нас уже є, щоб розпочати тестування?
3. Коли ми маємо почати тестування?
4. Які процеси нам треба налаштувати або описати?
5. Що і як ми тестуватимемо?
6. Що ми робитимемо далі? / Як ми вдосконалюватимемося?

У результаті ми повинні отримати такі задокументовані аутпути в таких категоріях:

• Мета тестування.
• Методологія.
• План комунікації.
• Моніторинг і контроль.
• Документація і звітування.
• Укрування ризиками.
• Інструменти.
• Середовища.
• Процес поліпшення.

Мета тестування

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

Одним з нетривіальних прикладів тестової мети може бути додержання дедлайнів. Тестувальникам доведеться не просто знайти дефекти, а й забезпечити своєчасний реліз певних фіч. 2019 року з’явився оновлений протокол 3ds, який я згадувала вище, — 3ds 2.0. Усі зацікавлені сторони, відповідно, мали чітко встановлені дедлайни для впровадження потрібних змін. Тому тестувальникам довелося (а на деяких ринках ще доведеться) не тільки посприяти випуску якісних оновлень, а й зробити це вчасно.

Визначаючи, що ми тестуватимемо, багато з нас каже: «Усе!» Справді, треба все, але що ми з того всього справді тестуватимемо? Ми завжди обмежені в часі, саме тому пріоритезація — наше все. Чи є зміст продовжувати активну розробку й тестування нових фіч, коли ми виявили проблеми з перформансом? Чи варто наймати дорогого контрактора для тестування безпеки, якщо в нас навіть ще не написано авторизації? Відповіді на ці запитання залежать від пріоритетів проекту в певний момент часу.

Методологія

Мені не хотілось би зараз описувати весь страх і ненависть еджайлу, бо це краще піти на конференцію до ПМів, але з великою ймовірністю доведеться працювати саме з якимось гнучким підходом. З цього випливають і наші активності — чи буде передбачено рефайнмент (як ми працюватимемо з вимогами, який у нас Definition of Ready), як плануватимемо (чи естимейти враховують час на тестування), розширити Definition of Done так, щоб усі наші заплановані тестові цілі були враховані (наприклад, покриття юніт-тестами на рівні не меншому ніж 90% (звучить закадровий сміх)). Якщо тобі «світить» скрам, то треба пам’ятати про mini waterfall trap, щоб усі тестові активності не проводити останнього дня перед демо.

В одному з проектів мені допомогла проста роздруківка всіх 16 пунктів Definition of Done, яку я прикріпила до нашої дошки. Тоді ми практикували парну розробку (а було, що й тестувальник долучався до них — виходила потрійна розробка) і бодай хтось один з пари завжди пам’ятав ураховувати час на тестові активності.

Окрім цього, ми можемо застосувати один або декілька таких підходів:

• Експертне тестування (наприклад, тестувальники, які спеціалізуються на різних видах нефункційого тестування).
• Тестування на підставі вимог (урахування acceptance criteria).
• Тестування на підставі ризиків (якщо ця фіча працюватиме некоректно або взагалі не працюватиме, як «боляче» буде нашим користувачам? Або, наприклад, фіча, від якої залежать більшість інших фіч).

План комунікації

Качечка на цьому фото символізує процес duck debugging. Качка — уявний помічник, розмовляючи з яким можна розв’язати певну проблему. Тому, розмовляючи навіть з уявним другом, можна дістати користь :) А що вже казати, якщо в тебе є цілий план комунікації. У реальному житті якийсь чітко документований чи бодай хоч якось описаний план комунікації я не бачила. Але зазвичай цей план у нас є — у голові.

Що важливо розуміти про комунікацію, то це те, що вона може відбуватися як синхронно (говорю з людиною в режимі реального часу й отримую миттєвий фідбек), так й асинхронно (пошта, спілкування в слеку). А важливо це тому, що треба планувати в який спосіб, і коли ти комунікуватимеш з... усіма в проекті. Деякі ключові особи можуть бути доступні лише в певний проміжок часу, але потребуватимуть коротких статусних звітів щодня. До одного розробника можна просто звернутися, вигукнувши його ім’я через всю кімнату, а інший — цього не любить, бо втрачає фокус.

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

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

Моніторинг і контроль

Спланувати щось — це добре, але як з’ясувати, що все за планом? Як побачити відхилення від нього якомога раніше? Для цього нам треба впровадити процес моніторингу (просто спостереження) і контролю (спостерігаємо й реагуємо). Вдалий моніторинг і контроль дає змогу виявити проблему на ранній стадії, і це означає, що ви матимете більше часу, щоб нервувати щодо цього :)

Що ми моніторимо? Моніторитимемо ризики (про них далі) та якісь наші домовленості із замовником (наприклад, щось прописане в контракті).

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

Як ми це робитимемо? Ну, звісно ж, за допомогою метрик.

Один з моїх проектів мав визначений критерій — 90% покриття юніт-тестами для кожної нової фічі. Цей показник ми завжди моніторили, оскільки 90% — це дуже амбітна цифра, та в разі, якщо ми не могли її досягнути, потрібне було обґрунтування під час рев’ю. Однак я не вважаю, що варто «гнатися» лише за кількісним показником. Покриття тестами повинно бути не лише об’ємне, а й, передусім, якісне. Немає значення, скільки у вас юніт-тестів, якщо їх написано, наприклад, без урахування старих добрих технік тест-дизайну. Зрештою, одна з переваг вимірювання будь-якого покриття — це визначення частин коду, не покритих (або недостатньо покритих) тестами, саме там і є ризик виникнення дефектів.

Документація і звітування

Документація — це не тільки конфлуенс і тест-кейси (писати їх чи ні — тема холіварна). Сюди ж належать тестова стратегія, тест-план (такий, на 50 вордівських сторінок, уже ніхто не пише, сподіваюся, але такий, у якому коротко викладено всі пункти, описано в цій статті — матиме цілком пристойний і читабельний вигляд), трейсебіліті-матриця й інші метрики, чеклисти, майндмапи, звіти (наприклад, про прогони автоматизованих тестів), а можливо, ви навіть практикуватимете підхід test cases as a code.

Для звітів важливо розуміти їхню цільову аудиторію. Звіт про прогон автотестів повинен бути, передусім, зрозумілий для розробників, бо саме вони повинні переконатися, що їхні зміни не зламали нічого. Тому неправильно адресувати такі звіти бізнес-людям, хай який красивий вони мали б вигляд (звіти, не люди :)

Керування ризиками

Загалом підхід у роботі з ризиками досить відомий, й інформації на цю тему чимало в Інтернеті. Спочатку потрібно скласти карту ризиків, оцінити ймовірність виникнення кожного ризику й оцінити важливість (тобто серйозність наслідків у разі, якщо ризик наступить). Помноживши ймовірність на важливість, отримаємо пріоритет ризику і далі працюватимемо тільки з найпріоритетнішими (пам’ятаємо, час негумовий, працювати з усім логом ризиків неможливо). Для кожного ризику визначимо стратегію — уникатимемо цього ризику, передаватимемо третій стороні, прийматимемо як є чи спробуємо зменшити наслідки (avoid, transfer, accept, mitigate).

Нижче подано простий приклад реєстру ризиків і стратегій роботи з ними:

Інструменти

Нам, тестувальникам, пощастило трохи більше, ніж менеджерам: у них лише один інструмент — Excel. У нас же є широкий вибір інструментів для будь-яких активностей, пов’язаних з тестуванням. Чим керуватися під час вибору інструментів?

Призначення. Будь-який інструмент лише допомагає нам розв’язувати проблеми або обліковувати завдання. Відповідно, якщо завдання — документувати тест-кейси, їхні статуси, зберігати історію змін тощо — ліпше вибрати спецінструмент, ніж старий добрий Excel. Проте, якщо у вас лише короткий чеклист, який рідко змінюватиметься, як-от в одному з моїх останніх проектів, то Excel упорається з нею на ура. І, звісно, твій улюблений інструмент не завжди такий, що найбільше підходить для розв’язання тої чи іншої проблеми.

Експертиза. Різні люди мають різний досвід, і це означає, що інструментарій треба підбирати з урахуванням експертизи членів команди, які безпосередньо працюватимуть з інструментом. Якщо в проект прийшов молодший тестувальник без досвіду в API-тестуванні, то ліпше взяти простий інструмент Postman, ніж намагатися відразу навчити його працювати з cUrl. А ще не варто давати дітям молоток у руки, бо вони всюди бачитимуть цвях :)

Часто, коли йдеться про вибір інструментів для автоматизованого тестування, кожен стек технологій має свій «золотий стандарт», наприклад, Selenide (Java) для тестування на рівні UI. Проте й стандарти з часом змінюються, оскільки з’являються дедалі крутіші інструменти. Щоб дізнатися про них першими, долучайтеся до локальних спільнот — наприклад, QA Club Lviv (або Telegram-канал), відвідуйте конференції або переглядайте відео зі свіжими доповідями онлайн.

Інколи треба вибрати інструмент для розв’язання завдання, з яким ми ще ніколи не стикалися. У такому разі раджу зробити короткий POC і подивитися, як працюють різні інструменти. Одного разу мені довелося підбирати безплатні інструменти для демонстрації дефект-трекінгу для групи тестувальників-початківців. Оскільки Jira, до якої ми так звикли, платна для великих груп користувачів, довелося пошукати в надрах Інтернету. Ми зі студентами спробували попрацювати з кількома трекерами й повернулися до найпершого вибору — старої (і, може, уже не надто доброї) Bugzilla.

Пропонуючи нові інструменти, раджу враховувати ROI. Інструмент платний чи ні? Як швидко всі члени команди зможуть його опанувати? Як добре він розв’язуєте весь набір завдань? Наприклад, інколи нам набагато легше купити ліцензію на TestRail, ніж лаятися на безплатний TestLink.

Середовища (environments)

Інфраструктура є? А якщо знайду?

Якщо в проекті є людина, яка займається DevOps, то вам пощастило. Слід продумати мінімально потрібну кількість середовищ, в яких ви з командою тестуватимете, показуватимете демо, ганятимете автотести тощо. Усе залежно від тестових цілей. На мою думку, мінімальна кількість середовищ — це dev, stage, prod. На майбутнє можна передбачити окреме середовище для тестування навантаження або тестування безпеки (наприклад, сек’юріті-команда в моєму проекті має своє окреме середовище). Проте в одному з моїх проектів уся команда працювала насправді в одному середовищі — dev env. Команда мобільної розробки зважала на бекенд з цього середовища. Тому коли там виконувалися автотести, які додавали або чистили дані, то це спричиняло купу незручностей. Тож непередбачене заздалегідь розгортання середовища для QA коштувало нам усім трохи нервів.

Якщо ж девопс-інженера в проекті нема, то варто задуматися, а чи не впадуть ці завдання на твої плечі? Часто тестувальники, особливо автоматизатори чи SDET, можуть узяти на себе інфраструктурні завдання. Проте таке навантаження повинно бути сплановане й відповідати рівню компетенції.

Процес поліпшення

Якщо ми добре попрацювали і якісно проробили всі пункти, це ще не час видихати й починати планувати відпустку. Наші тестові цілі мають тенденцію змінюватися, залежно від бізнесових потреб і пріоритетів. Та й загалом сама галузь IT постійно змінюється, з’являються нові підходи й інструменти (наприклад, chaos testing). Саме тому треба ще сісти й подумати: «А як ми вдосконалюватимемо наші процеси? І коли це робитимемо?»

Щоб постійно вдосконалюватися, можна використати так званий цикл Демінга: Plan>Do>Check>Act. Інакше кажучи, спочатку плануємо, упроваджуємо план в життя, перевіряємо результати (класичний приклад — ретроспектива) й коректуємо/удосконалюємо наші процеси.

Висновок

Ось так просто невідомість проясніла й усе стало, сподіваюся, набагато зрозуміліше. Заповнивши всі прогалини, поговоривши з усіма ключовими особами й учасниками команди, склавши план, використовуючи вищеподану категоризацію, ми можемо порозставляти в нашому проекті «пастки», що відловлюватимуть різноманітні дефекти. Багато з нас знає їх під назвою quality gates. Це як у грі — щоб перейти на наступний рівень, треба спочатку пройти попередній. Так і тут — щоб релізнути продукт потрібно пройти всі рівні (aka quality gates) один за одним, щоб переконатися в його якості. Ось список того, що може бути як quality gate:

• Definition of ready, requirement analysis.
• Definition of done.
• Peer reviews.
• Static code analysis.
• Version control systems.
• Unit, integration, system testing.
• Pair sessions.
• CI/CD.
• Canary releases.
• Documentation.
• Automatic backup/restore plan.

Усе це допоможе поліпшити якість вашого продукту. Проте, хоч які класні процеси ви з командою вибудували, пам’ятаймо золоте правило — нам потрібен хороший продукт, а не хороший процес.