Уперше береш участь у проєкті як QA Lead і хочеш, щоб усе пройшло ідеально? Тоді цей матеріал саме для тебе. 

Олександр Фіалка, QA Lead у NIX, поділився дієвими порадами з власного досвіду про те, із чого краще стартувати в новій команді, як сформулювати стратегію та уникнути базових помилок. 

Замість вступу

Стандартизованого визначення тест-ліда немає. Але можна зробити висновок, що це досить впевнена в собі людина.

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

1. Визнач очікування від роботи

Поговори з керівником, щоб визначити цілі, повноваження та дедлайни. 

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

2. Познайомся з командою

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

3. Оціни ресурси

Я виділяю такі категорії:

• Залізо. Подумай про конфігурацію комп’ютерів і ноутбуків, кількість моніторів, планшетів або смартфонів та іншу техніку, яка знадобиться для тестування продукту. Якщо працюватимете над сайтом-візиткою, то запозиченого у бабусі ноутбука напевно вистачить. Але якщо робити тестування навантаження, знадобиться серйозніша техніка.
• Інструменти. Крім hardware, для тестування потрібне й software. При виборі цих інструментів пам’ятай про доступний бюджет. Якщо грошей достатньо, купуй просунуте ПЗ. В іншому випадку пошукай безкоштовні аналоги й оціни, наскільки вони відповідають конкретним завданням.
• Оточення. Спробуй розрахувати, скільки та які енвайроменти тобі потрібні. В ідеалі треба мати хоча б одне оточення винятково для тестування. Це взагалі хороша практика: один енвайромент для девелоперів, один — для аналітиків, один — для тестувальників.
• Люди. Оціни кваліфікацію співробітників. Людям не має бути тісно на проєкті. Якщо у тебе тільки круті сеньйори, навряд чи вони довго звірятимуть літери у застосунку. Їм потрібні завдання відповідного рівня, а таких банально на всіх не вистачить. Якщо ж у тебе лише джуни, вони можуть не подужати тестування складної та заплутаної логіки. Команда має бути збалансованою по скілам.

4. Досліди об’єкт тестування

Вивчи продукт, його архітектуру, наявні модулі та всю пов’язану з ним інформацію. Дізнайся, які види інтеграцій використовуються, чи є сторонні застосунки та які cпособи взаємодії з ними передбачені проєктом. 

5. Визнач ймовірні ризики та способи тестування

Розібравшись із продуктом, спробуй передбачити потенційні проблеми на проєкті:

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

6. Сформулюй стратегію тестування

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

• Тест-план. Більше підходить для проєктів із фіксованим скоупом, коли чітко зрозумілі стадії, підсумкові результати і терміни.
• Тестова стратегія. Цей варіант краще пристосований до Agile-проєктів, де все швидко змінюється і немає орієнтирів за термінами та підсумками розробки.

7. Попрацюй з вимогами до продукту і документацією

Ця частина роботи найбільш об’ємна. Спершу зосередьтесь на вимогах. В ідеальному світі тест-лід на вході до проєкту отримує велику теку документації, яка включає:

• бізнес-вимоги;
• вимоги користувача;
• функціональні вимоги;
• вимоги до зовнішніх інтерфейсів;
• вимоги до даних;
• бізнес-правила;
• атрибути якості;
• обмеження;
• ідеї розв’язання.

Ми завжди сподіваємося, що доведеться мати справу з детально написаною специфікацією або деталізованими User Stories. Та ліпше одразу налаштувати себе на можливе виокремлення вимог з уривків листів, розмов та мітингів із замовником. У найгіршому випадку він взагалі обмежиться фразою на зразок: «Зробіть мені, як там». До цього теж варто бути готовим.

8. Без менеджменту не обійтися

Твоє завдання — забезпечити прозорість роботи як усіх QA, так і проєктної команди загалом. Якщо кожен розуміє хто і чим займається, до тест-ліда буде мінімум питань. Для забезпечення прозорості на проєкті раджу запровадити кілька параметрів:

• метрики, які ви збиратимете;
• які звіти збиратимете, як та з ким;
• кому і наскільки часто надсилаєте звіти;
• за яких умов необхідно використовувати матриці покриття коду, тестів, вимог тощо.

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

9. Продумай процес доставки коду

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

• Чек-лист деплою. Пропишіть покроково, як ви доставлятимете продукт на різні оточення.
• Критерії готовності. Визначте, в якому вигляді результати тестування можна передавати на наступні рівні.
• Пре- і пост-перевірки. Оберіть відповідальних за той чи інший етап.

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

10. Розвивай команду

Ділися знаннями з колегами. Продумай програму менторства всередині команди — навчайтеся разом, обмінюйтеся досвідом. 

І памʼятай, що функції QA Lead виходять далеко за межі звичайного тестування.