Як побудувати ефективну роботу QA в продуктовій компанії

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Привіт! Я Оля, QA Engineer у продуктовій компанії Newage. У цю сферу прийшла 5 років тому, починала з позиції Junior Manual QA. На попередньому місці роботи, в аутсорс-компанії, що була інтегратором CRM, я доросла до Tech Lead. Там було чимало різних проєктів, багато команд, і в кожної — свій підхід до роботи. Були спроби створити єдину QA Team, але всі тестувальники працювали над різними проєктами в різних командах, тому було важко впровадити єдиний механізм.

Саме в той період мені стало дуже цікаво — як можна покращити взаємодію QA та розробників, якою має бути команда QA та чи треба її виокремлювати? Питання зависло в повітрі через постійне навантаження та потреби навчання новачків, на експерименти часу не лишалося.

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

QA у продуктовій компанії

На моєму проєкті тестувальники не відокремлені, вони одразу потрапляють в команди розробників і працюють з ними. Перше, що мене вразило: всі колеги (QA, розробники, ВА, РМ) допомагали розібратися з функціоналом продукту, відповідали на всі запитання, обговорювали ідеї та підтримували будь-яку ініціативу. Я замислилась — чому ж така різниця?

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

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

Необхідні скіли для професійного QA

Тестувальник — це багатофункційний спеціаліст. І чим глибше QA розуміє продукт, тим він крутіший.

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

• розбиратися в технічній частині продукту, і не лише за своєю спеціалізацією. Я зараз працюю з бекендом, тому мої мастхев — знання баз даних і всіх принципів тестування, вміння користуватися JIRA, Jenkins, TestRail, Grafana, Swagger, Postman, Dev Tools, ELK, Bitbucket, DataGrip. Але список не вичерпний — з кожним днем з’являється щось нове;
• чітко уявляти структуру компанії та зони відповідальності, орієнтуватися, які задачі виконують інші команди, що створюють продукт. У мене часто виникають запитання про «чужий» функціонал, і я знаю, кому їх адресувати. В ідеалі в продуктовій компанії всі QA мають розуміти, хто що робить і коли до кого звертатися;
• брати участь у загальній комунікації, не боятися запитувати й уточнювати, навіть якщо це прямо не стосується технічної частини продукту. Як і в багатьох компаніях, у нас відбуваються грумінги, коли ВА приходить до команди та розповідає про нову задачу. Всі беруть участь в обговоренні, і ми обов’язково перевіряємо, чи однаково зрозуміли таск.

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

Взаємодія QA та бізнесу

Робота тестувальника будується за дедуктивним методом: від загального уявлення про продукт до детального. Зараз я багато дізнаюся саме про бізнес-складову продукту, тому менше контактую з розробниками, натомість більше з ВА. Це дозволяє детально зрозуміти, як продукт повинен функціонувати.

Я дізнаюся, навіщо бізнесу саме ця задача. Часто QA просто отримують таск, роблять свою частину, перевіряють, чи працює — і все. Та важливо мати всебічне уявлення, і це допомагає правильно перевіряти задачі. Я впевнена, що QA має бути в курсі новин продукту, напряму його розвитку та свіжих ідей, тому участь у загальних мітингах — it’s a must. Крім бізнес-аналітиків, QA може звертатися з питаннями і до проджект-менеджерів.

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

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

Коли QA, ВА та розробники працюють як одна команда, робота йде набагато ефективніше, ніж коли кожен сам за себе.

Взаємодія між QA і розробниками

В нашій компанії QA та розробники перебувають у командах, які займаються певними сервісами. Тестувальник не один: я — Manual QA, а мій колега — QA Automation engineer. Зрозуміло, ми всі об’єднані регулярними скрам-зустрічами — раз на 2 тижні маємо рев’ю, плануємо спринт на наступні два тижні, підбиваємо підсумки. І, звичайно, daily meetings — хто що зробив учора та має зробити сьогодні, з якими проблемами стикнувся. Тому тестувальники знають, над якими задачами працюють розробники загалом і в конкретний момент, і навпаки.

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

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

Багато залежить від взаємодії з командою. Часто спостерігаю невірний підхід в інших компаніях — «ну, заведуть баг, то й зробимо». Якщо орієнтуватися на бізнес-результат, то відразу інше ставлення до взаємодії та виправлення багів — «йой, оце ми наробили, треба поправити».

Які можуть бути помилки у взаємодії тестувальника з розробниками? По-перше, не можна поспішати. Треба працювати спокійно та уважно. Для прикладу, слідкувати за середовищем, на якому тестуєш, щоб не виникло ситуації, коли створюєш тестові дані на проді (таку інформацію не має бачити користувач). Або щоб дані не були видалені. Уважно дивитися, що саме робиш і куди надсилаєш запит, не відволікатися.

По-друге, не треба боятися перепитувати. Подумав, що все просто, зрозумів задачу по-своєму, а потім виявилося, неправильно протестував й отримав баги.

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

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

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

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

Отже, у взаємодії з розробниками QA повинен:

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

Взаємодія між QA і Support

Коли клієнт пише, що в продукті щось не працює, сапорт першим обробляє цю інформацію. Якщо там справді щось не так, завдання виправити адресують відповідній команді. Тут є поширена проблема в ІТ — ми зробили новий функціонал і передали клієнту, але не сповістили про це сапорт. І він передає помилкові запити чи взагалі не до кінця розуміє, що відбувається. Сапорт має чітко уявляти, як продукт працює.

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

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

Зараз наша компанія експериментує у формах взаємодії QA і сапорта. Разом з ВА ми детально розповідаємо сапортам про продукт: аналітик — у загальних рисах, я говорю більше про прикладну частину, показую демо функціонала. Подивимося, чи ефективною буде така схема взаємодії.

Отже, QA варто:

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

Управління розробкою за допомогою QA

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

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

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

Якщо коротко:

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

То як же побудувати ефективну роботу QA в компанії

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

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

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

Також ми працюємо над створенням загальної бази use cases. Якщо така база прописана, QA набагато легше виконувати свою роботу. І так само з test cases — поки що їх фіксує лише частина колег, але плануємо створити документацію, яка допомагатиме ефективніше і швидше працювати.

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

• менеджмент компанії повинен добре знати продукт і зону відповідальності всіх спеціалістів;
• для нових QA, як і для всіх інших фахівців, має існувати зрозумілий онбординг;
• треба створити загальну базу знань про продукт (тестову документацію — use cases і test cases, а також технічну документацію);
• завжди треба йти від головного — того, над чим ви працюєте. Тому кожна команда має враховувати задачі продукту.

Корисні ресурси для тестувальників

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

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

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

Сайти:

qalight.ua (розділ «База знань», де є корисна теорія),
medium.com/tag/qa (stories, thinking, and expertise from writers),
ibm.com (Tutorials),
guru99 (Tutorials),
gurock.com (TestRail User Guide),
Postman Learning Center.