A/B-тести очима QA
A/B-тест — експеримент, у якому аудиторію випадково ділять на групи: control (поточний досвід) і одну чи кілька variant (зміна). Далі порівнюють цільову метрику (конверсію, retention) і за допомогою статистики вирішують, чи різниця не випадкова. Він відповідає на питання «чи справді зміна допомагає», а не «чи нам подобається».
Що важливо знати QA:
- Стабільність призначення (stickiness). Користувач має завжди потрапляти в ту саму групу: після перезавантаження, входу з іншого пристрою (якщо є ідентифікатор), нової сесії. Якщо людина бачить то A, то B, її дані спотворюють результат, а досвід виглядає як баг;
- Перевіряти всі варіанти. Кожен variant — це окрема версія продукту. Функціональність, верстка, аналітика, локалізація й доступність потребують тестів у кожному. Часта помилка — протестувати лише «нове»;
- Примусове призначення. Для тестування потрібен спосіб потрапити у варіант (query-параметр, cookie, внутрішній інструмент), а не чекати на випадковість. Такий механізм не повинен бути доступним у продакшені всім;
- Аналітика експерименту. Подія експозиції (користувач побачив варіант) має відправлятися один раз і з назвою групи. Інакше метрики будуть порівнювати не тих;
- Не «підглядати» за результатом. Якщо зупинити тест, щойно варіант вирвався вперед, висока ймовірність помилково «виграти» через випадкові коливання. Тривалість і потрібний розмір вибірки визначають заздалегідь, і QA не підштовхує до дострокового висновку;
- Перетин експериментів. Два тести на одному екрані можуть впливати один на одного. Їх розводять (взаємовиключні групи, layers) або враховують у аналізі;
- Якість варіантів. Варіант, що ламає частину браузерів чи уповільнює сторінку, програє не через ідею, а через дефект. QA захищає чистоту експерименту.
Про «розмір вибірки» достатньо концептуально: що менша очікувана різниця і що вища потрібна впевненість, то більше користувачів і часу потрібно; кілька днів на малому трафіку зазвичай нічого не доводять.