Очікування - Вимоги - Реальність

Нещодавно я знову побачив відому діаграму Венна, яку часто використовують адепти школи контекстного тестування (цього разу на презентації на QA Fest 2017. Ilari Henrik Aegerter. What is Context-Driven Testing?).

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

Області 4 + 7 + 5 + 2 - Записані вимоги 

Області 1 + 4 + 7 + 6 - Очікування клієнтів 

Області 6 + 7 + 5 + 3 - Фактичний продукт 

Тільки збільшення областей 6 та 7 додає вартості проекту та задовільняє потреби бізнесу.

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

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

Очікування клієнтів

Області 4 та 7 - це обмежений об’єм бажаного функціоналу, що був правильно описаний. Тобто те, що вдалося сформулювати клієнтами, чи аналітиками що слухали клієнтів. Ця частина в інших джерелах ще називається "явні вимоги" (explicit requirements).

Явні вимоги - це весь корпус документації, від речення з чатику чи пошти, до законодавства, що регулює галузь у країні цільового ринку. Від Маніфесту Гнучкої Розробки ПЗ що у далекому 2001 році постановив, що "Співпраця із замовником важливіша за обговорення умов контракту", шириться розуміння, що не можливо задокументувати кожен аспект майбутнього використання системи, натомість слід постійно "розмовляти з бізнесом". Таким чином, зараз у 2018 році команда розробників розпочинає роботу, слухаючи Продакт Овнера ("власника продукту" - представника бізнесу); і продовжує слухати його всю дорогу, на всіх етапах життєвого циклу розробки. Таким чином, кожен звук від бізнес-хлопців, який ми можемо зрозуміти, може розглядатися як явна вимога.

Області 1 та 6 - неявні вимоги. Їх можна назвати "невисловлені сподівання"; те, що запитувач вважає настільки очевидним, що про це не варто згадувати. Незважаючи на те, що ці сподівання не вимовляють вголос, неявні вимоги можуть бути навіть більш важливими для клієнтів, оскільки вони можуть бути основою майбутнього бізнес-процесу.

Область 6 відповідає "загальному розумінню", чи "tacit knowledge" - "тихе знання", спільне розуміння проблеми та шляхів її вирішення між між учасниками процесу. Ця область зростає тим більше, чим інтенсивніше відбувається спілкування між бізнесом та командою розробки.

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

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

Письмові вимоги

Чому не повністю реалізована вся задокументована функціональність?

Області 4 та 2 - вимоги написані, але не були зрозумілі розробниками (і були пропущені тестувальниками та аналітиками).

Крім того, області 2 та 5 також не зрозумілі і замовникам. Як таке може бути?
Це може статися, якщо, наприклад, частина документа була скопійована з іншого проекту. Чи документ вимог має кілька авторів, які не до кінця узгодили між собою всі деталі.
Крім того, коли команда зрозуміє та впровадить пункти з області 5, до області 2 потрапляє те, що є поза сферою відповідальності ("out of scope"), і на тепер просто тихо (і може підсвідомо) ігнорується розробниками.

Написане завжди має межі, тому тут немає ніяких нескінченних частин.

 

Фактичний продукт

Області 5 та 7 цілеспрямовано впроваджуються розробниками.

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

І нарешті, область 3 виявилася поза контролем і розумінням бізнесу. Наприклад, програмісти могли використати нове API для геолокації, полегшивши життя користувачам; або зробили так, що апп працює без Інтернету, а коли той з'являється - синхронізується. Такі деталі завжди будуть поза увагою бізнесу, адже самі по собі дуже рідко вирішують якісь бізнес-задачі. 
Також вона включає в себе фактори, які не контролюються ні розробниками, ані опсами. Такі, як програмне та апаратне забезпечення третіх сторін, тобто інших постачальників, проблеми з оновленнями та підтримкою. Область 3 також необмежена. Бо хто може знати, коли знайдеться чергова вразливість чи щось вийде з ладу?