Поки готую наступний пост з серії про автоматизацію. захотілося поділитися цікавим, на мій погляд, матеріалом з книги Agile Testing: A Practical Guide for Testers and Agile Teams.
Так ось, видів тестування дуже і дуже багато: навантажувальний, ad hoc, sanity, black box, white box і так далі. І довгий час я не зустрічав хорошої і зрозумілої, на мою думку, системи, яка б містила нормальну угруповання всіх цих видів, а так само давала пояснення, коли і навіщо які потрібно їх використовувати. І буквально днями прочитав про Agile Testing Quadrants (ATQ), про які і хочу розповісти.
Власне сама система виглядає ось так:
Як видно, класична діаграма 2 * 2. Отже, по одній з осей тести діляться на бізнес-орієнтовані і технологічно-орієнтовані, по іншій осі - на тести для підтримки команди і для "критики продукту". Відразу хочу відзначити, що нумерація нічого не говорить про те, коли потрібно проводити ці тести.
Пройдемо по кожному з секторів.
Сектор Q1 являє собою таку відому практику, як TDD. Все просто: спочатку тести, потім код. І ці тести в першу чергу відповідальність команди розробки. Всі ці тести обов'язково повинні запускатися через CI, для постійної перевірки якості коду. Все це розписано в багатьох джерелах, для тих, хто ще не практикував TDD, хочу порадити ось це посилання.
Сектор Q2 містить в собі більш високорівневі тести, які вже мають відношення до бізнесу. Успішне проходження цих тестів є обов'язковим, щоб говорити про завершеності будь-якого функціоналу. Тому що ми можемо говорити, що той чи інший функціонал зроблений, коли він вирішує одну з поставлених бізнес-користувачами завдань. На цьому рівні в основному тестується зовнішня оболонка програми: інтерфейс, API, веб-сервіси і так далі. З іншого боку, цей сектор включає в себе тестування прототипів, мокап, дизайну і так далі. Часто для позначення тестів, що входять використовують термін приймальне тестування. хоча це не зовсім вірно, так як тести з секторів Q3 і Q4 так само варто віднести до приймального тестування.
Тести з сектора Q3 увазі обов'язкову участь експертів в доменній області, експертів по usability, користувачів і так далі. Так вже часто буває, що реалізований функціонал насправді не вирішує проблеми замовника, або ж щось зрозуміли неправильно командою розробкою. Знову ж таки, могли виникнути нові аспекти роботи з доменними об'єктами або з'ясувалося, що спроектований інтерфейс не зручний користувачам. Якраз тут і вступають в справу тести, призначені для "критики" продукту. Відразу обмовлюся, що слово "критика" тут має позитивний відтінок. Само собою, що дане тестування може бути тільки ручним, тому що ні один скрипт не може виявити позначених проблем, хоча ми, звичайно, можемо використовувати допоміжні засоби, наприклад, для завантаження даних.
І, нарешті, останній сектор Q4. який говорить про тих тестах, які не перевіряють рішення задач бізнесу, а говорять про те, наскільки ж добре написано наш додаток, використовуючи такі терміни як безпеку, продуктивність, стійкість, масштабованість і так далі. Дані тести допоможуть, як перевірити дотримання нефункціональних вимог, якщо вони є, так і зрозуміти, наскільки успішно спроектовано додаток вже на ранніх етапах. Ці тести сильно допомагають уникнути проблем в майбутньому. Зрозуміло, що для проведення подібних перевірок, потрібно використовувати спеціальні інструменти, яких представлено на даний момент дуже багато.
Таким чином, Agile Testing Quadrants є таким собі чек-листом, який показує, що ми йдемо в правильному напрямку, що наші процеси в достатній мірі автоматизовані і можемо займатися ручними дослідними тестами. І найголовніше, Agile Testing Quadrants покажуть, наскільки успішний наш продукт, з точки зору бізнесу.