Як почати роботу над новим проєктом, якщо ти — тестувальник-автоматизатор: покрокова інструкція

На вході в проєкт існує декілька неочевидних нюансів. Про підходи до знайомства з продуктом та старт роботи QA багато корисного розповів у цій статті мій колега, QA Lead Олександр Фіалка. У дечому наші думки перетинаються, але я все одно рекомендую почитати його матеріал — там багато корисних порад для мануальних тестувальників. А цей текст більше зацікавить автоматизаторів.

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

Почнемо з порад Junior QA

Знайомство з проєктом

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

• Бізнес-домен. Якщо техліду розуміння домену та бізнесу клієнта допомагає якісно написати стратегію тестування, то автоматизатору важливо розібратися у цих питаннях з інших причин. Коли ви писатимете нові тести або будете вигадувати способи тестування конкретної функціональності, вам треба достеменно розуміти суть застосунку. Спитайте себе: як часто певну функцію будуть використовувати? Регулярно впродовж дня або раз на місяць? Так ви дізнаєтесь про реальне значення швидкості для обробки цієї функціональності. Якщо користувач звертається до неї рідко, то навряд чи її повільна реакція викличе в нього роздратування.
• Стек розробки. Автоматизатор повинен вміти читати код. Розпитайте техліда, на чому розробляється ваш продукт і чи можна дослідити його «виворіт». Якщо заборони немає — обов’язково робіть це. Почали вивчати продукт, і раптом щось не зрозуміло? Зверніться за роз’ясненням до розробників. Подібна комунікація в команді — це хороший м’який старт для початківця. Досвідчені колеги допоможуть розібратися, як, скажімо, працює валідація або як трігнути помилку, яку не вдається провести через API. І таких корисних розмов буде безліч.
• Стек автоматизації. Це мастхев. Можливо, ще до початку роботи над щоденними тасками вам знадобиться вивчити щось нове.

Участь у створенні стратегії

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

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

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

Початок автоматизації

• Налаштувати оточення. З більш-менш готовою стратегією ви чітко розумієте, які інструменти будете використовувати.
• Опанувати інструментарій. Раптом є щось незнайоме, і ви досі не вивчили цього — зробіть це.
• Отримати скоуп завдань. Якщо є тестовий план, там все зазначено. Якщо ж є лише тест-стратегія, уточніть у тестліда, який з абстрактних інженерів у цьому документі саме ви. Будьте відвертим в обговоренні задач. Не розумієте чогось або не вмієте — так і скажіть про це. Хороший техлід не лаятиме вас за правду, а допоможе дістатися потрібного професійного рівня.

Онгоінг-завдання

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

• «ї#!&$ти кодяру». Я «зам’ютив» у тексті дієслово, але суть ви зрозуміли. Після входження до проєкту ви маєте робити саме це. Пишіть, пишіть і знову пишіть код, щоб покривати мікросервіси, бекенд, фронтенд та усе інше.
• Підсвічувати проблеми. Якщо помітили щось таке, виносьте на обговорення. Збої в організаційних процесах? Не працює фреймворк або його незручно використовувати? Тести на вашому стеку виходять нестабільними? Всі проблеми варто обговорювати з командою і техлідом, аби змінити ситуацію на краще.

Переходимо до порад техлідам автоматизації

Знайомство з проєктом

Не має значення, заходите ви на нульовий або діючий проєкт. У будь-якому випадку ваше перше завдання — якомога більше дізнатися про розробку. Особливо, якщо вона така ж незрозуміла на перший погляд, як ось ця річ із мультсеріалу «Рік та Морті»:

• Бізнес-домен. Що робить застосунок, в якій сфері застосовується та в чому суть бізнесу замовника. Чому це так важливо? Уявіть собі якусь нову програму, яка потрібна для взаємодії користувача з деякими гаджетами. Припустимо, ви обмежитися лише цією інформацією, і згодом навчились реєструвати девайси, вибудовувати QA-процеси та запускати тести. Але пізніше дізнаєтесь, що передбачуваних пристроїв — не один і навіть не десять, а мільйони! Відповідно, всі ваші інвестігейти та інструменти мають бути зовсім іншими. І тепер у вас просто немає можливості працювати з такими масивами даних. Тому моя порада: з самого початку дізнавайтеся всі деталі про бізнес-домен та цілі продукту.
• Стек розробки. Ви повинні хоча б приблизно розуміти, якою мовою та за допомогою яких технологій створюється застосунок. Іноді розробники готові підтримувати ваші тести, але не хочуть вивчати новий стек. Для них взаємодія з командою автоматизаторів у цьому питанні має бути швидкою та безболісною. Визнаю, подібна ситуація не є настільки поширеною, як хотілося б. Тим паче не варто втрачати таку можливість. Знаючи стек розробки, ви зможете обрати відповідний стек і для автоматизації. Це відчутно спрощує взаємодію з девелоперами та підвищує ефективність роботи.
• Стек автоматизації. Цей пункт більше стосується діючих проєктів, де підтримуються автотести. Тут вам варто знати, чим користувались ваші попередники.
• Навички QA-команди. Дізнайтеся, з ким ви працюєте і що вміють ваші люди. Їхні скіли важливі не лише для втілення поточних рішень але й із перспективою на майбутнє. Ваші колеги можуть знати певні мови програмування, вміти проводити поки що непотрібні на цьому проєкті види тестування або мати досвід у спорідненій доменній зоні. Згодом їхній досвід може знадобитися і вам.
• Робочі процеси. Які тікети використовуються у Jira? Де вони розміщуються та як рухаються по дошці? Коли можна брати функціональність у тестування, а коли закінчувати розробку, запускати code freeze та регресії? Можливо, пізніше ви скоригуєте ці процеси, але на старті ознайомтесь із тим, що є.
• Доступні ресурси. Я маю на увазі залізо та софт. Які програми можна обирати? Чи маєте ви можливість купувати платні бібліотеки або використовувати лише загальнодоступні версії? Чи можлива реєстрація поштових скриньок у потрібній вам кількості? Який загалом виділено бюджет на необхідні ресурси? Відповіді на ці питання допоможуть у плануванні подальшої роботи.

Підготовка драфту стратегії тестування

Детально вивчивши проєкт, переходьте до написання чернетки стратегії тестування. Навіть від досвідчених автоматизаторів інколи можна почути, що без тестової стратегії чи тест-плану можна прожити. Причому люди посилаються на реальні проєкти, де всі обходилися без такої документації. Мовляв, вона потрібна лише для чогось великого і потужного, як Зірка смерті із «Зоряних війн».

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

• Чим тестова стратегія відрізняється від тест-плану?

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

• Чи складно сформувати стратегію?

Звернусь до особистого досвіду. Першу тестову стратегію я написав певною мірою випадково. Мене запросили до одного суміжного проєкту, де в команді не вистачало досвідчених людей. Коли клієнт попросив команду підготувати тест-стратегію, колеги звернулися до мене. Я раніше цього не робив, але загальном розумів процеси на проєкті і… був готовий трохи погуглити. Почитав, що таке тестова стратегія, що в ній має бути, і взявся писати. Шаблони з інтернету допомогли мені правильно сформулювати структуру. І буквально через день ми вже мали робочий документ. 

• Навіщо потрібна стратегія?

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

При розробці автомейшен-стратегії дайте відповіді на такі питання:

• Хто? Йдеться не про конкретну людину з ім’ям та прізвищем, а про абстрактного інженера на проєкті. Ви повинні сформулювати чіткі критерії щодо цього фахівця. Які види тестування він може виконувати? Які скіли йому потрібні? Який у тестувальника буде Definition of DoneНабір критеріїв, які дозволяють зрозуміти, чи було зроблено те, що було метою.? Скільки вам взагалі потрібно автоматизаторів на проєкті того чи іншого рівня? Так ви зможете зібрати оптимальну команду.
• Що? Тут стане в нагоді згадане вище розуміння доменної області. Що ви збираєтесь перевіряти? Які види тестування потрібні для цього? Чи проводитимуться перфоманс тести?
• Як? Це питання стосується методів досягнення мети. Як буде організовано роботу в команді QA? Як проходитиме взаємодія з проєктною командою? Як писатимуться функціональні тести? Чи залучатимуть автоматизаторів до написання юніт-тестів тощо.

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

Інвестігейт інструментів

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

Адже нам, автоматизаторам, завжди корисно вивчити та випробувати на практиці щось незнайоме.

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

• Вивчити поточні тулзи. Це справедливо тільки для діючих проєктів. Насамперед варто дізнатися, з чим зараз працюють автоматизатори. Так з одного боку, ви оціните наявні інструменти та зрозумієте, чи підходять вони для вирішення ваших завдань. З іншого — зможете аргументовано запропонувати щось інше.
• Спробувати нові. Підберіть інструменти, які видаються підходящими для ваших задач та цілей. Якщо йдеться про наявний проєкт, обов’язково варто порівняти результати нових інструментів із тими, які вже використовує команда.
• Затестити і запропонувати команді. Поділіться результатами випробувань нових інструментів. Розкажіть про це QA-команді, менеджеру, замовнику. Не забувайте про аргументи на користь того чи іншу інструменту.
• Допоможіть іншим QА опанувати нові інструменти. Якщо запропоновані вами тулзи виявились наскільки ефективними, що їх затвердили у проєкті, навчіть решту команди користуватися ними.
• Відслідковуйте результати. Якщо виникають проблеми під час користування обраними інструментами, не гайте часу і сміливо змінюйте рішення.

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

Комунікація

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

Комунікація на проєкті відбувається у трьох напрямках:

• Зі своїми командами. Навіть якщо у вас поки одна команда, організувати комунікацію слід так, щоб вам вчасно надходили необхідні звіти для розуміння ситуації на проєкті. Краще побудувати комунікацію не техліда з командами, а команд — із техлідом. Тоді робочі процеси будуть стабільними.
• З іншими командами. У великих проєктах це можуть бути вендори з інших країн. І з їхніми командами ви також будете перетинатись. Головне не згаяти часу й одразу познайомитись із колегами. Інакше в якийсь момент перестанете розуміти, що взагалі роблять партнери. Це може позначитись і на ставленні клієнта до вас. Тому завжди намагайтеся бути на зв’язку зі сторонніми командами. Ідеально, якщо вам вдалося потоваришувати. Зрештою, ви працюєте над одним продуктом, тож у вас мають бути спільні теми для робочих і неформальних розмов.
• З менеджментом. У будь-якій проєктній ієрархії є хтось і над вами: лід, Рroduct Owner чи замовник. Спілкування з цією людиною має бути не менш злагодженим, ніж із командами. Основа такої комунікації — ті самі звіти команд. Ви як техлід збираєте всю інформацію, обробляєте її та трансформуєте у зрозумілий менеджменту формат. В результаті керівник має розуміти, що ви робите і наскільки добре ви це робите. Від цього фактору залежить багато чого — від ставлення до вашої команди та продовження роботи до готовності розширити проєкт та впроваджувати нові рішення (які ви теж можете запропонувати).

Отже, маємо чітке розуміння стратегії тестування. Саме час розповісти все команді.

• Заплануйте мітинг із колегами

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

• Починайте впроваджувати тести

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

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

Онгоінг-завдання

• Слідкуйте за трендами

Наведу кілька опорних питань, які допоможуть вам розуміти ситуацію на проєкті:

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

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

• Виконуйте стратегію

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

• Оновлюйте документ

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

• Збирайте фідбеки

Зворотний зв’язок дуже цінний. Він допомагає коригувати процеси зі стратегією тестування та зрештою покращувати продукт.

• Навчайте команду

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

• Вирощуйте менторів

Жоден техлід не може постійно займатися виключно навчанням нових людей. Згодом доведеться шукати ресурс для стратегічних завдань. Тому паралельно з попереднім пунктом техлід має навчити того, хто потім навчатиме інших. Спершу вам може здатися, що тільки ви знаєте, як правильно вчити людей працювати з конкретним проєктом. Ви ж його мало не самі будували! Та будемо відверті: якість навчання та ефективність роботи команди аж ніяк не просідає, якщо в ній будуть інші ментори, такі ж, як ви, кваліфіковані фахівці. Тут варто навчитися делегувати обов’язки і дати можливість іншим членам команди професійно зростати.

Репорти

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

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

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

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