Built-in Quality: щось нове чи добре систематизоване старе?

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

Усім привіт. Мене звуть Ігор Кошелєв, я Director of QA Office компанії MEV.

У цій статті хочу поговорити про якість і про те, хто має її забезпечувати. Можливо, відповідь на це питання здається очевидною. Мовляв, той, у кого в назві професії значиться Quality, той і відповідає за якість. Але якщо розглянути детальніше вакансії QA-інженерів, то можна помітити, що часто йдеться не стільки про забезпечення якості, скільки про тестування. Чи може тестування забезпечити відповідність продукту очікуванням стейкхолдерів (а це є важливою складовою тлумачення якості)? На жаль, ні. Тож у цій статті я хочу поговорити про те:

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

Тестування vs забезпечення якості

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

• під час тестування ми знаходимо помилки та дефекти. По суті, тестування працює лише з однією складовою якості (відсутність помилок) та передбачає аналіз того, що вже було зроблено;
• під час забезпечення якості ми виконуємо подвійну роль: як виявляємо помилки, так і гарантуємо відповідність продукту потребам стейкхолдерів. І щоб ця відповідність була можлива, ми маємо ще ДО початку активної фази розробки розуміти очікування. Отже, забезпечення якості починається ще на етапі збору вимог, триває протягом усього Software Development Life Cycle і допомагає як правильно доставляти фічу, так і бути впевненим, що ця фіча безпомилкова. Про це поговоримо далі.

Проведемо просту аналогію: якщо говорити, наприклад, про дорожній рух, то в цьому випадку якістю можемо вважати дотримання певної швидкості його учасниками. І якщо водій порушує цю якість та перевищує швидкість, то поліцейський має його зупинити та виписати штраф. Але хто в цьому випадку несе відповідальність за забезпечення швидкості? Поліцейський лише «відловлює» порушників (тобто баги). Тоді як відповідальність за комплексне забезпечення якості лежить на всіх учасниках дорожнього руху, чи не так?

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

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

Якщо щось пішло не так під час збору та аналізу вимог або під час перевірки в дизайні, то виправлення буде відносно простим. Проте, якщо це «не так» помітять уже користувачі, то ціна усунення дефектів (та й їхній вплив на продукт) значно зросте. Адже такі помилки можуть призводити до втрати аудиторії та грошей бізнесу, зменшення задоволеності користувачів, збільшення часу реагування на баг.

Отже, що ми маємо:

• забезпечення якості лише тестувальником малоймовірне, адже воно потребує комплексного підходу. До того ж, тестувальник здійснює перевірку постфактум, що є лише частиною процесу забезпечення якості. Згадаємо приклад з водієм, що перевищив швидкість, і поліцейським. Наш тестувальник — це той самий поліцейський, який відловлює порушників, тобто контролює якість (або ж констатує факт її дотримання чи недотримання), але не забезпечує її. Для цього потрібні інші механізми, і про них ми поговоримо далі;
• додаємо сюди ще умову: на проєкті з тих чи інших причин не передбачено розширення команди QA. Тому виправлення помилок стає не тільки дорожчим, але й тривалішим. Відповідно, тривалішими стають і lead-time фічі. А якщо продукт ще й розширюватиметься, то тим паче.

Щоб побороти ці очевидні недоліки, подивимося на підхід Built-in Quality.

Вбудовуємо якість

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

Як вбудовувати якість у розробку програмного забезпечення?

1. Етап Requirements. Щоб говорити про забезпечення та вбудовування якості, на цьому етапі потрібні будуть прозорі Acceptance Criteries — детальні вимоги до самого продукту та майбутніх acceptance testing. Ці вимоги і є тими очікуваннями, якими продукт має задовольняти. Хоча Acceptance Criteries можуть створюватися розробником, тестувальником чи бізнес-аналітиком, але саме власник продукту несе відповідальність за них.

Наприклад, ми маємо спроєктувати економічний автомобіль для горе-водія, якого раніше штрафували за перевищення швидкості. Одна з вимог до машини (Acceptance Criteria): при русі з постійною швидкістю 100 км/год протягом однієї години автомобіль повинен споживати не більше 5 літрів пального.

Щоб Acceptance Criteries були прозорі та однозначні, зазвичай використовують так звану зустріч трьох амігосів — представника бізнесу (Product Оwner), розробника та тестувальника (але за потреби можна залучити й більше людей). Для опису фіч використовується Gherkin-мова, спільна та зрозуміла для всіх учасників зустрічі, яка сприяє взаєморозумінню щодо функціональних вимог до продукту.

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

• Feature: описує функціональну можливість або функцію, яку необхідно реалізувати.
• Scenario: описує конкретний сценарій або тестовий випадок.
• Given: вказує початковий стан системи або попередні умови для сценарію.
• When: вказує подію або дію, яка спричиняє зміну стану системи.
• Then: вказує очікуваний результат після виконання попередньої дії.

Ці сценарії BDD, написані мовою Gherkin, можуть стати основою для написання автоматизованих тестів.

Ось простий приклад Gherkin сценарію для нашого автомобіля:

Ця зустріч «трьох амігосів» є частиною refinement та проводиться перед sprint-плануванням. Вона дає змогу зрозуміти поведінкові вимоги до майбутнього програмного забезпечення, які будуть використані для acceptance testing.

2. Етап Development. Ми пам’ятаємо, що задача забезпечення якості як в тому, щоб правильно доставляти фічу, так і в тому, щоб доставляти правильну фічу. І завдання етапу Development більше про першу складову. Тут потрібен підхід Test Driven Development (TDD), відповідно до якого ми спочатку пишемо тест, потім — код, який проходить цей тест, а потім виконуємо рефакторинг, щоб зробити код максимально чистим. Зрештою створюємо мінімальну кількість коду та забезпечуємо високоякісні, довговічні системи, які стабільно та легко можуть адаптуватися або змінюватися. Цей підхід поширюється і на виправлення багів: просто їх виправити недостатньо, на них також потрібно написати тести. Адже в іншому випадку не буде гарантії, що баг знову не з’явиться в майбутньому. Це банально, але виконається не зажди.

У випадку нашого автомобіля зараз ми, наприклад, будемо перевіряти, чи місткість бака відповідає очікуванням. Спочатку ми розробляємо сенсор, який сигналізуватиме нам про те, що в бак залито рівно 60 літрів пального, цей об’єм заповнив бак на 100 % і разом з тим не відбулось переливу. Це і є наш тест. Далі, заливаючи пальне в бак, ми добиваємось того, щоб пройти цей тест, тобто заповнити бак повністю потрібним об’ємом без переливів.

3. Етап Acceptance testing. Настав час перевірити, чи відповідає продукт критеріям, які ми створили на першому етапі за допомогою Behavior Driven Development (BDD). А також: чи готовий він до використання та чи поводиться так, як очікується.

Коли автомобіль перейшов на етап Acceptance testing, ми маємо випробувати паливну ефективність за реальних умов.

Кроки потрібного тесту:

• встановити постійну швидкість двигуна автомобіля 60 км/год;
• керувати машиною одну годину;
• очікуваний результат: автомобіль повинен споживати не більше 5 літрів пального;

4. Етап Demonstration та застосування деяких практик з Lean UX, зокрема постійного та ітераційного поліпшення користувацького досвіду. На цьому етапі ми показуємо, що правильно доставляємо правильну фічу. Як саме це відбувається? Ми швидко створюємо мінімально життєздатний продукт, тобто MVP-версію, який містить основні функції та дозволяє перевірити їх на малій кількості користувачів (тест-автомобіль, який не має ні кондиціонера, ні парктроніка, але витрачає рівно 5 літрів на 100 км). Потім команда працює над покращенням продукту на основі зворотного зв’язку від клієнтів.

А кому Built-in Quality не підійде?

Хоча Built-in Quality — важлива частина головоломки під назвою «Якість», у ній є свої нюанси.

1. Built-in Quality — це великою мірою про готовність команди отримувати зворотний зв’язок. Скажу більше, якість загалом — це про зворотний зв’язок. Адже ледь не найнадійніший спосіб зрозуміти, що якість та відповідність потребам стейкхолдерів зберігається на потрібному рівні — отримувати фідбеки від цих самих стейкхолдерів та користувачів. Відтак команда, яка хоче «вбудувати якість», має бути готова отримувати зворотний зв’язок чи навіть проактивно його шукати, а також коригувати свої дії відповідно до нього. Наприклад, на основі підходу Think Test-First та зміщеної вліво моделі, у якій запускати тестування можна одразу, коли з’являється достатній для цього об’єм коду. Запустили тестування — отримали зворотній зв’язок — внесли корективи.

2. Через важливість зворотного зв’язку та можливу мінливість вимог (очікувань), інтеграція Built-in Quality на проєкти з waterfall-методологією виглядає малоймовірно. У такій ситуації регулярний фідбек просто непередбачений, а тому можливі дефекти та проблеми знаходяться лише тільки під кінець процесу розробки.

3. Тоді як на проєктах з Agile (а саме scrum) за допомогою ітераційних sprints ми можемо постійно перевіряти, чи наш продукт все ще відповідає очікуванням стейкхолдерів і коригувати scope робіт, якщо, наприклад, ці очікування змінилися. До того ж, в Agile-трикутнику якість стає фіксованою шляхом домовленостей в команді щодо definition of ready та definition of done (тобто переліку вимог, які повинні бути виконані перед тим, як команда почне працювати над якоюсь задачею, та перелік вимог, які дозволяють визначити, що задача завершена). Наприклад, до definition of ready належить створення сценаріїв для acceptance testing, а до definition of done — перевірка коду на відповідність стандартам якості (code review).

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

4. Звичайно, що різні проєкти та галузі мають унікальні вимоги та обмеження. І практики Built-in Quality потребують адаптації до конкретних умов. Наприклад, проєкт може бути досить невеликим і взагалі не мати функціоналу для впровадження BDD. Тож, хоч і вчитися на найкращих практиках корисно, сліпе їх застосування без урахування конкретних характеристик проєкту може призвести до неоптимальних результатів.

5. Часовий ресурс. Усі ми стикаємося зі стислими термінами та обмеженими ресурсами. Хоча Built-in Quality має важливе значення, цей підхід повинен бути збалансований з іншими обмеженнями проєкту, такими як час, бюджет і обсяг.

Наприклад, під час реалізації Built-in Quality та TDD-підходу команда може зіштовхнутися з оберненою пірамідою тестування, в основі якої мала кількість unit-тестів, трохи більше інтеграційних та end-to-end (E2E) і нескінченно велика кількість мануальних тестів, яка збільшується разом зі зростанням програмного забезпечення. У такій ситуації QA-команді все більше не вистачатиме часу на проведення регресії або smoke-тестування.

Розв’язувати цю проблему має допомогти Test Automation Pyramid. Але для того, щоб автоматизація тестування окупила себе, теж потрібен неабиякий час.

Якщо ми маємо справу з короткотривалими, MPV-проєктами або проєктами з обмеженим бюджетом, важливо фокусуватися на головному:

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

6. Built-in Quality вимагає співпраці та спілкування між різними учасниками команди. Без чітких каналів зв’язку, прозорої та системної комунікації та культури, у якій якість — це найвищий пріоритет, ми багато чого не досягнемо.

Отже, що в результаті

Як бачимо, всі (або більшість) елементи Built-in Quality вам добре відомі та, скоріш за все, використовуються на практиці. Але об’єднані разом підходом Built-in Quality вони відкривають нове бачення забезпечення якості.

Звичайно, що цей підхід — це кропітка та об’ємна гра в довгу. І ми маємо розглядати його як цінний інструмент, але не як універсальний засіб розв’язання всіх проблем, оскільки Built-in Quality має достатньо як плюсів, так і мінусів. Рішення щодо його застосування слід ухвалювати винятково через призму унікальних потреб і параметрів вашого проєкту. Проте я вірю, що окремі елементи Built-in Quality, а головне — філософію цього підходу слід тримати в голові.