Квадранти гнучкого тестування

Незалежно від того, чи ви читали лінійку книжок Agile Testing від Лізи Кріспін та Джанет Грегорі, у процесі опанування напряму QA ви могли стикнутися з концепцією квадрантів гнучкого тестування. Ця концепція має вигляд умовної схеми, де різні типи тестування розташовані в різних площинах в залежності від того, на що вони спрямовані. Я звертаю увагу на цю теоретичну абстракцію на фоні сотень інших саме тому, що її легко і корисно використовувати на практиці.

Оригінальна схема тестових квадрантів, представлена ще в далекому 2008-му році, виглядає наступним чином:

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

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

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

Одразу маю зазначати, що кажучи “тестування” я не маю на увазі процес, яким займаються виключно QA. Це не так і особливо помітно це буде на першому квадранті. Взагалі Ліза Кріспін у своїх книжках акцентує увагу на тому, що з приходом agile тестувальники втратили монополію на тестування, але всі тільки виграли таким чином, тому що позбулися інертних уявлень, що обмежували можливості.

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

Спрямованість на критику продукту означає, передусім, що вже є, що критикувати, себто майже завершений функціональний інкремент, який вже можна розглядати “серйозно”. Це може бути і прискіпливий погляд кінцевого користувача, і аналіз можливостей продукту.

Тепер, коли ми розібралися з розподіленням, пройдемо по кожному квадранту.

Q1. Технологічно-орієнтовані тести, спрямовані на підтримку команди.

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

Q2. Бізнес-орієнтовані тести, спрямовані на підтримку команди.

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

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

Ви можете запитати, а що функціональні тест-кейси роблять у квадранті допомоги команді, хіба їх місце не у критиці продукту квадрантом правіше? І тут ви попалися, любителі відкласти написання документації “на потім”. Бо хорошою практикою, по-перше, вважається проектування кістяка документації із найбільш ранніх етапів розробки (привіт, shift left), а, по-друге, ці функціональні тести дуже легко конвертуються у опис тікету, вимоги чи acceptance criteria функціоналу, в які розробник може дивитись, аби розуміти, коли функціонал можна віддавати далі.

Загалом це найбільш дискусійний квадрант — тут присутні жваві обговорення типу “а що мав на увазі клієнт?”, “тут не конкретизовано, але думаю, що отак буде найкраще; чи може спитати?”, “ось на цьому відомому аналогу зроблено отак, що думаєте?” та інші. QA активно залучений у цю фазу як посередник задля допомоги команді розробки. Сюди також можна віднести E2E-рівень автоматизації тестування, якщо він поставлений на якісь регулярні рейки.

Q3. Бізнес-орієнтовані тести, спрямовані на критику продукту.

Це царина QA-інженера, особливо у відносно невеличких компаніях, де альфа- та бета-тестування відсутні або не є обов’язковими етапами. Тут відбувається виконання попередньо спроектованих тестів на вже готовому продукті, який команда розробки, якби не ви, вважала достойним передачі клієнту. Після або паралельно із QA функціонал може передаватися альфа- (обраним ізсередини компанії/команди) чи бета-тестувальникам (обраним ззовні компанії/команди), а також інші типи User Acceptance Testing (UAT).

Так само тут присутній exploratory testing, і про нього хотілося б трохи обмовитись. Повноцінний exploratory testing — це окрема практика, яка регламентується в тест плані із прописуванням скоупу тестування, дозволених часових рамок, рівня заглиблення тощо. Ця практика дуже корисна, оскільки чим складніший проєкт, тим експоненціально вищі шанси проґавити емерджентні (тобто такі, що виникають у взаємодії елементів) нюанси його роботи. Але крім того, зі зростанням власної експертизи ви будете помічати, як певні “спалахи” exploratory testing поступово вплітаються в вашу рутину регулярного виконання написаних тестів. Досвід, інтуїція, знання аналогів будуть підказувати вам звернути увагу на щось ще, приділити дві хвилини, аби протестувати щось непередбачене і дивне. Моя загальна рекомендація — дослухатися до цих “спалахів”, а найбільш суттєві і важливі знахідки конвертувати в регулярну документацію, щоби наступного разу це був не випадковий exploratory testing, а типове виконання тест-кейсів.

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

Q4. Технологічно-орієнтовані тести, спрямовані на критику продукту.

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

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

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

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

Наостанок хотів би поділитися хорошим джерелом. Ліза Кріспін та Джанет Грегорі, за 16 років після публікації своєї першої книги, досі досліджують проблеми тестування і діляться знахідками у своєму блозі. Їх інсайти нетривіальні, тому що вони беруть їх із реальних прикладів власної практики.

Бажаю вам двох найважливіших якостей тестувальника, уважності і удачі!