Product discovery з позиції тестувальника. Як провести з користю для майбутньої роботи

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

Мене звати Юрій Бабай, я співпрацюю з ЕРАМ у ролі менеджера з контролю якості розробки. Розповім у цій статті, що врахувати QA-фахівцю, який бере участь у фазі product discovery.

Як проходить Project discovery

Отже, фаза Project discovery — це низка воркшопів між замовником і командою сервісної чи аутсорсингової компанії. На них присутні ключові люди з обох боків, замовник може бути як новий, так і той, з ким співпрацюєте давно. Якщо говорити про потенційних виконавців, то серед них мають бути проєктний чи delivery менеджер, архітектор рішень, бізнес-аналітик (або навіть декілька), тест-менеджер та інші консультанти в залежності від запиту — системний інженер, фахівець з кібербезпеки, UX-дизайнер тощо. Всі ці експерти мають на меті якомога краще зрозуміти, що потрібно клієнту, і запропонувати найоптимальніші варіанти.

Триває фаза Project discovery в середньому 3-4 тижні, але все залежить від клієнта і рівня складності запиту. Тому часові межі можуть складати як 2, так і 6 тижнів. Це час продуктивної роботи для команди і підготовки пропозиції для замовника. Звісно, бувають і невдалі кейси, коли клієнт обирає для співпраці іншу компанію, але очікувана конкуренція для бізнесу. Загалом же знайти підхід до замовника, з яким ви вже співпрацювали, завжди простіше.

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

Я брав участь у Product discovery двох типів:

Коли у замовника присутні процеси і є продукт, який може бути вже в продакшні. У цьому випадку, скоріше за все, від команди очікують певних змін у продукті або процесі, тому спочатку необхідно детально розібратись і зрозуміти, що є зараз, на чому базується розробка продукту, чого хоче замовник і як можна це інтегрувати в наявний процес, покращити його. До речі, тут необхідно дуже обережно використовувати слово «зміни». Краще говорити про «покращення», «вдосконалення». Замовники сприймають їх набагато привітніше.
Коли у замовника ще немає продукту, який має вирішувати ті чи інші задачі. Тут на етапі discovery необхідно зрозуміти клієнта та процес, який йому потрібен, запропонувати архітектуру і продемонструвати прототип продукту, своєрідний макет майбутнього результату. У випадку рішення на вашу користь, далі підписується документ «Terms Statement of Work (SOW)», який окреслює терміни, бюджети та інші формальні моменти.

У кожному з випадків під час Product discovery необхідно якомога краще зрозуміти запит замовника і запропонувати найоптимальніше рішення.

Роль QA

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

Так, один з клієнтів ЕРАМ, до якого я був залучений на Product discovery, мав продукт, який був в лайві вже декілька років, мав власну команду і процес тестування, проте замовник не був задоволений. На продакшні знову і знову виходили баги, на деяких моделях девайсів застосунок працював не найкращим чином. Самостійно виправити ситуацію клієнту не вдавалося, тому я мав проаналізувати наявний процес, зрозуміти його в деталях і далі, спираючись на найкращі практики EPAM EngX (Engineering Excellence), надати рекомендації для покращення ситуації. Внутрішні ресурси на той момент у клієнта були лімітовані, але він хотів зменшити навантаження на функціональне тестування і покращити якість продукту. Тож на додачу до консалтингу це завдання виконували експерти ЕРАМ.

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

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

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

Коли склад майбутньої команди обговорений і є розуміння необхідних навиків і професійного рівня цих спеціалістів, час братись за обговорення quality gates — основних чек-поінтів, за допомогою яких буде відбуватись перевірка продукту. Серед них можуть бути unit testing, integration testing, security testing, performance testing і таке інше. До речі, до останніх видів тестування у замовника можуть бути особливі вимоги. Я неодноразово стикався з тим, що перевірку безпеки і навантаження клієнт проводить на своєму боці або за допомогою інших виконавців — і це має сенс, адже може покращити якість тестування і проявити неочевидні дефекти. А іноді клієнт вимагає тестування, для якого потрібні додаткові інструменти. Вони можуть бути платні і про це теж варто говорити під час фази Product discovery: одразу закладати ці витрати у бюджет або працювати з очікуваннями замовника і пропонувати альтернативи.

Автоматизація: бути чи не бути

Коли остаточно зрозуміло, що і в які часові межі будемо тестувати, варто подумати про доречність автоматизації та її особливості. А вони справді можуть бути. Наприклад, загальна практика — писати автотести тією ж мовою, що й застосунок. Проте в моїй практиці були випадки, коли замовник просив codeless-автоматизацію і це потребувало пошуку win-win рішення. Саме Product discovery — найкращий час для тест-менеджера запропонувати різні варіанти і детально обговорити їх, щоб всі сторони були задоволені.

Неочевидні моменти

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

Окремий момент — розуміння тривалості проєкту. Якщо він короткотерміновий, то пропонувати надто складну та тривалу тест-стратегію немає сенсу. Варто замислитись над іншими способами провести тестування якісно, але досить швидко. Вдалим варіантом може бути краудтестування. В EPAM, наприклад, ми використовуємо для цього власну платформу test IO. Дуже часто такий підхід є вигідним для замовника: адже економить час на тестування і кошти на найм додаткових фахівців. Обговорювати такі нетипові рішення також варто під час фази Product discovery.

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

А які спостереження під час стадії Product discovery робили ви? Що дозволило провести її ефективніше? Пишіть в коментарях. Буду радий конструктивній дискусії.