Як не розгубитися на новому проєкті, коли ти джуніор-тестувальник: 5 головних порад

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

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

1Дізнайтесь про проєкт і ваші задачі

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

• конкретні цілі та завдання на проєкті;
• ваші повноваження у команді;
• обов’язкові задачі;
• терміни на knowledge transfer, навчання, адаптацію в команді та початок роботи.

Співставте цілі на проєкті зі своїм планом професійного розвитку (за його наявності). В ідеалі ваші кар’єрні та проєктні цілі мають поєднуватись. Якщо є невідповідності, поговоріть про це зі своїм лідом.

Можливо, варто скорегувати ваш особистий план. Завжди краще зробити це на старті.

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

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

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

Врешті у вас має скластися цілісне розуміння того, що ви тестуватимете, як це будете робити та з ким.

2Підготуйтесь до роботи

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

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

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

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

3Познайомтесь із колегами та налаштуйте комунікацію

• Ролі QA. Намагайтеся визначити, хто з тестувальників за що відповідає. Уточнюйте детально, скажімо, до кого звертатись за інтеграцією із Salesforce, хто розповість про логіку застосунку в цілому, кому ставити питання щодо дизайну тощо.
• Принципи існування проєкту. Дізнайтеся про нюанси проєктної команди в цілому. Наприклад, чи є бізнес-аналітики або хто з програмістів відповідає за той чи інший модуль, що тестується.
• Взаємодія. Обов’язково познайомтесь із кожним спеціалістом, який дотичний до «вашого» модулю, обміняйтесь контактами, розпитайте, чим конкретно вони займаються на проєкті.

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

• Формат тікетів і статуси, які використовує QA-команда та проєктна команда.
• Життєвий цикл тікетів та їх воркфлоу — тобто в якій послідовності пересувати тікети по дошці, в які стовпці це робити тощо.
• Формат баг-репортів — які поля є під час створення звіту, чи потрібно заповнювати фікс-версію та в яких випадках, чи потрібні лейби тощо.
• Пошук існуючих багів за проєктом у Jira та наявні фільтри.
• Незакриті баги. Ця інформація дозволить краще зрозуміти проєкт, уникати дублів та бачити найбільш проблемні частини, на які треба звертати особливу увагу.

З’ясували це все? Тепер спробуйте самостійно завести баг у Jira та відпрацювати його стандартний воркфлоу.

4Вивчіть документацію

Наступний крок — ознайомитись із базою знань по проєкту (Confluence чи подібна до неї), почитати робочі Google Docs та всю інформацію з інших сховищ, дізнатися про специфічні проєктні знання, мануали та програми навчання. Якщо часу на читання замало, спробуйте зрозуміти хоча б структуру цих знань. Так ви знатимете, де шукати потрібну вам інформацію у майбутньому.

Окремо познайомтеся із тестовими артефактами та їх форматом. Не зайвим буде попрактикуватися у написанні власних — за аналогією з наявними. А ще дізнайтесь про існування перехресного рев’ю ваших кейсів — про його принципи, порядок і ролі.

5Перепитайте у досвідчених колег, що незрозуміло

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

Інколи щось виглядає цілком зрозумілим, але трохи дивним — і про теж запитайте.

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

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

• Чому треба заводити саме такий баг?
• Чому його треба переміщати в Jira у вказаний статус?
• Чому цей мітинг у графіку є, а ви в ньому не берете участі?
• Чи можна скоротити кількість мітингів, аби ви могли більше часу приділити своїм задачам?

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

Зі своїм безпосереднім керівником можете поділитися враженнями від проєкту, що подобається, а що ні. Обговоріть те, що вам здалося незрозумілим або дивним, спробуйте дізнатися причини цього. Саме час запланувати перші таски й дедлайни. Не зайвим тут буде порадитись, як вам діяти в разі виникнення якоїсь проблеми. І врешті — ви готові до роботи!

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

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

Моя головна порада всім джунам: завжди думайте, що ви робите, як та навіщо. Намагайтесь покращувати кожен свій крок від проєкту до проєкту. Так ви швидше станете професіоналом у своїй справі.