Підходи до співпраці BA та QA

13.10.2022 332

Software Development Hub працює за принципом "найкращі результати розробки програмного забезпечення досягаються високопродуктивними командами".

Вступ

Перш за все, для досягнення найкращого результату розробленого програмного забезпечення життєво важливу роль відіграють специфікація та вимоги, надані бізнес-аналітиком (Business Analyst, BA).

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

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

Обов'язки ролей у життєвому циклі розробки програмного забезпечення

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

Якщо коротко описати всі фази, то на фазі "Аналіз" від клієнта отримується вся необхідна і доступна інформація для того, щоб розробити продукт відповідно до потреб і очікувань замовника, а також проводиться аналіз отриманої інформації. Результатом етапу аналізу є специфікація вимог до програмного забезпечення (Software Requirements Specification, SRS).

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

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

На етапі тестування розроблене програмне забезпечення ретельно тестується. Будь-які виявлені дефекти передаються розробникам для усунення, щоб забезпечити відповідність програмного забезпечення стандарту відповідності замовника.

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

Існують ключові обов'язки BA та QA під час SDLC, які на практиці приводять до найкращих результатів.

BA	QA
Аналіз
Підготовка та планування діяльності з бізнес-аналізу Виявлення бізнес-потреб і визначення обсягу та підходів до проекту Сприяння у виявленні та аналізі вимог	Аналіз здійсненності вимог Визначення вимог до навколишнього середовища. Підготовка плану тестування вищого рівня Визначення типу тестування, яке буде проводитися в рамках проекту
Дизайн
Визначення варіантів дизайну Рекомендації проектного рішення	Перегляд дизайну Перевірка потоку вимог Перевірка UI/UX Підготовка плану низькорівневого тестування
Розробка
Підтримка команди розробників	Створення списку тестових кейсів Підготовка тестового середовища
Проведення тестування
Перевірка готовності Сприяння навчанню користувачів Визначення пріоритетності знайдених дефектів/багів	Тестування Написання тестових кейсів Пошук помилок і тестування Виправлення помилок Регресійне тестування Підготовка баг-звітів Підготовка статусів тестування
Розгортання
Перевірка готовності	Димове (smoke) тестування
Обслуговування
Оцінка системи	Тестування виправлень помилок та оновлень функцій

Але, на жаль, на практиці, через брак ресурсів не всі обов'язки виконуються.

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

Основні підходи до співпраці BA та QA

Робота в ізоляції

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

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

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

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

Колаборація

Інший підхід, заснований на співпраці, пропонує залучення QA на ранніх стадіях, тобто з процесу виявлення вимог.

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

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

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

Об'єднання ролей BA та QA

Деякі компанії та команди розробників вирішили об'єднати обов'язки BA та QA в одну роль, поставивши одну і ту ж людину на обидва кінці процесу, щоб поліпшити співпрацю між ролями розробки. Ця об'єднана роль є критично важливою ланкою між бізнес-потребами клієнта та досвідом команди.

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

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

Замість висновку

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

BA QA