Вітаю, ви — тест-лід: як зайти на новий проєкт і не упустити нічого важливого (зручний чек-лист)

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

У цій статті я хочу зосередитись на етапах знайомства з проєктом з позиції QA Test Lead. Це може бути проєкт, що тільки стартує, або вже діючий. Тоді вас можуть долучити до команди як ще одного QA або на заміну іншому.

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

Вітаю, ви — тест-лід

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

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

Тому подальший сценарій розіб’ємо на декілька кроків.

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

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

• Цілі. Дізнайтеся, що вам потрібно досягти як тест-ліду в межах цього проєкту, та які конкретні завдання ставить ваш безпосередній керівник.
• Повноваження. Можливо, ви й самі ухвалюєте всі рішення і самі ж нестимете за них відповідальність. Або ж вам треба узгоджувати як стратегічні, так і найменші дії у проєкті. Розпитайте про все це.
• Терміни. Бажано заздалегідь окреслити дедлайни на входження у проєкт та на knowledge transfer. Дізнайтеся, наскільки тривалим буде проєкт та ваша роль у ньому.

Метою цієї розмови має стати виключення непорозумінь у майбутньому. Інакше існує ризик, що через певний час керівник скаже щось на кшталт: «Я думав, ти це зробиш», а ви відповісте із серії: «Мені здалося, що цим хтось інший займається…».

Наступна бесіда має бути із клієнтом. Як і в першому випадку, варто розділити розмову на кілька етапів:

• Очікування. З’ясуйте вимоги, які замовник висуватиме вам, команді тестування і, можливо, всій проєктній команді. Він може сказати: «Мені байдуже, як ви це зробите, але я хочу вчасно отримати хороший продукт». Або ж клієнт може захотіти відстежувати кожен ваш крок.
• Відповідальні особи. Від замовника необхідно одержати перелік людей з його боку, до яких ви зможете звертатися з питаннями та пропозиціями. Крім самого клієнта, це може бути проєктний менеджер або тест-лід на стороні його команди розробки.

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

Якщо проєкт не новий, то важливо перейняти досвід від минулого тест-ліда:

• Загальна інформація. Це може бути, що завгодно: від архітектури, домену, складу команди — аж до розкладу стендапів.
• Домовленості. Вам потрібно знати, про що домовлялися між собою тест-лід, керівник, замовник та команда. Так ви зможете підхопити ці рішення та слідувати їм якщо не так само, то як мінімум краще.

Познайомтесь із командою

Не можу відмовити собі у задоволенні порівняти команду супергероїв дитинства із QA-командою.

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

Ваше завдання як тест-ліда — створити команду однодумців зі спільною метою. І тут лише QA-командою справа не обмежується.

Дізнайтесь якомога більше про всіх, із ким працюватимете: менеджери, програмісти, девопси, аналітики тощо. Обов’язково визначайте відповідальних за кожним напрямком, до кого і з якими питаннями зможете звертатись, із ким частіше будете спілкуватись. Не забудьте запропонувати колегам посильну допомогу і від себе.

Оцініть ресурси

Після знайомства з людьми потрібно оцінити наявні та необхідні ресурси на проєкті.

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

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

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

Це знайомство з продуктом. Тут я би виділив три вектори:

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

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

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

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

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

Обмежусь простим перерахуванням:

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

Окремо скажу про регресію. Це дуже необхідний вид тестування, з яким зазвичай виникає багато проблем. Регресійне тестування виконується наприкінці, тому на нього часто не вистачає часу та ресурсів. Тому продумайте аргументи на користь цього тестування і запропонуйте їх керівнику проєкту. Обсяг та цілі роботи мають бути виправданими.

Після видів тестування визначіться з браузерами. Зазвичай достатньо останніх версій Edge та Chrome. Але вам може не пощастити з продуктом для користувачів, які працюють на Windows XP. У такому разі треба проводити тести в IE 8 або більш екзотичних варіантах.

Також подумайте про операційні системи, навіть якщо маєте справу із вебзастосунком. Підготуйте все необхідне для тестів на різних ОС. Те саме стосується й мобільних операційних систем. Дізнайтеся, чи буде ваш застосунок працювати ще й на них. Тут головним орієнтиром має бути цільова аудиторія.

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

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

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

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

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

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

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

Коли у вас є більш-менш формалізовані вимоги, оцініть їх. Можливо, оцінку доведеться давати поетапно й кожну ітерацію оцінювати невеликі частини роботи. А можливо, попросять відразу оцінити весь скоуп робіт із тестування. У будь-якому разі для цього варто розуміти:

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

Наступний документ — Jira або будь-яка подібна система трекінгу та менеджменту. У Jira визначте типи сутностей, порядок їх переміщення по дошці, зміну статусів та життєвий цикл тікета. Заздалегідь обговоріть із колегами, як діяти з тестуванням Stories: заводити звичайний дефект, інстраспринт, сабтаск абощо.

Можливо, керівник проєкту і замовник вам довіряють, тому ви самі можете переміщувати таски по дошці в Jira. Ймовірним є сценарій, коли QA-команда переносить задачі у проміжний статус, а після демо їх закривають відповідальні особи.

У роботі з документацію зверніть увагу на:

• Вигляд та формат. Це можуть бути різні артефакти: чек-листи, докладні тест-кейси в тест-рейлі, користувальницькі сценарії в Google Docs або короткі коментарі до тасків у Jira.
• Місце зберігання. Визначте, де ви писатимете та розміщуватимете документацію. Не забудьте про доступи до цих сховищ.
• Техніки тест-дизайну. Визначте, які з них будуть використовуватись для написання тестів. Який би підхід до ведення документації ви не обрали, він має бути формалізованим, чітким і зрозумілим для всіх учасників процесу.

Останній важливий пункт на цьому етапі — критерії потрапляння функціоналу чи Stories у тестування. QA має розуміти, за яких умов братися за тестування та коли його закінчити.

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

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

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

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

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

Менеджери з аналітиками часом віддають перевагу паяльникам, щоб вивужувати з команди терміни, оцінки та іншу інформацію. Особисто я — за мирне врегулювання питань, тому пропоную при організації мітингів дізнаватися наступне:

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

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

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

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

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

Постійно розвивайте свою команду

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

Розповідайте про перебіг роботи

Спланувавши роботу над продуктом і загалом у команді, повертайтеся до комунікацій. Принципи прості:

• розповідайте всім стейкхолдерам про все, що зробили вище;
• за необхідності аргументуйте свої рішення;
• тих, хто не зацікавлений у зайвих обговореннях, — зацікавте та розкажіть про свої напрацювання.

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

Ви ж пам’ятаєте, що це все було лише входом у проєкт? От тепер можете почати працювати! На позиції тест-ліда вистачає щоденних рутинних завдань:

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

Усе це необов’язково робити самостійно. Кожен проєкт втілюється силами команди. Деякі задачі можна виконувати спільно з розробниками, менеджерами чи бізнес-аналітиками. А щось — дійсно лише самотужки. Зважайте й на те, що все задумане в проєкті може змінюватися. Тому намагайтесь бути гнучкими, а не сліпо слідувати певним патернам.