Масштабований процес контролю якості та тестування для MVP

Чесно кажучи, під час створення MVP контроль якості не завжди є у вашому списку справ. Швидше за все, ви поспішаєте встигнути до дедлайну, провести тестування відповідності продукту ринку і, можливо, навіть зібрати кошти — і все це одночасно. При обмеженому бюджеті є спокуса відкласти контроль якості на потім. Однак реальність така, що якщо ваш MVP буде містити помилки, не працюватиме або буде незручним у використанні, у вас може не бути другої можливості виправити ситуацію. Клієнти вимагають зручності у використанні, а стартапи оцінюються за їхнім першим запуском. Пожертвувати якістю контролю можна порівняти з пожертвою гальмами в гоночному автомобілі: ви можете бути швидкими, але далеко не заїдете. Хороша новина? Немає необхідності мати відділ контролю якості або дорогі платформи автоматизації. Все, що вам потрібно, — це легка стратегія, яка відповідає вашому поточному етапу та розширює ваш продукт. Цей посібник допоможе вам дізнатися все, що потрібно знати для налагодження цього процесу, включаючи методи та інструменти тестування і розумні стратегії, що масштабуються.

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

Реальний вплив: що насправді дає контроль якості

• Швидша ітерація: коли помилки виявляються на ранній стадії, ваші розробники витрачають менше часу на усунення проблем.
• Вища якість відгуків: QA гарантує, що користувачі можуть пройти всі етапи та надати конструктивні відгуки
• Мінімальна переробка: виправлення помилки після запуску коштує в 4-5 разів дорожче, ніж до запуску
• Покращене сприйняття інвесторів: це останнє, чого хочуть люди, які презентують баггий додаток венчурним капіталістам
• Кращий моральний дух у команді: розробники люблять створювати щось нове, а не виправляти помилки, які не були виявлені два спринти тому

Виклики MVP без контролю якості

Щоб проаналізувати, що відбувається, коли ви взагалі не проводите контроль якості, спочатку давайте подивимося, що відбувається, коли користувач стикається з порушеним потоком:

• Відтік користувачів: нестабільні потоки відштовхують користувачів ще до того, як ви отримаєте відгук
• Зміни боргу на технічний борг: проблеми накопичуються, і наступний етап розвитку стає більш складним
• Стрес у команді: розробники команди постійно перебувають на реакційному рівні, а не на рівні планування
• Повільне зростання: продуктам з помилками важко завоювати ринок або залучити гроші

Досить просто. Кожна функція може мати десятки тестів, які будуть виконуватися повним відділом контролю якості. У випадку MVP вам просто потрібно визначити пріоритети того, що є важливим. Нижче наведено скорочений процес тестування програмного забезпечення, який ви можете розпочати негайно:

1. Перевірка вимог

Перш ніж розробляти що-небудь, ви хочете знати, що воно має:

• Видалити
• Тестоване
• Відповідність цінності для користувача

Ви не знаєте, що означає успіх функції, як ви визначите, коли вона працює?

2. Створення плану тестування

Не потрібно бути генієм, на даному етапі достатньо таблиці Google. Список:

• Функції, які ми хотіли б протестувати
• Етапи тестування
• Очікувані результати

Ви навіть можете залучити до цього свою команду. Потоки користувачів також можуть надати розробникам, дизайнерам і навіть менеджерам проектів тестові випадки.

3. Виконання тесту

Це етап, на якому ви виконуєте продукт. Бажано, щоб це робила людина, яка не писала код (оскільки вона більш схильна бачити, що відсутнє або не працює). Тест:

• Послідовні процеси (наприклад, реєстрація, адаптація, основна дія)
• Крайні випадки (наприклад, що станеться, якщо я залишу обов'язкове поле порожнім?)
• Кілька гаджетів або браузерів (принаймні Chrome і Safari)

4. Відстеження помилок

Вам не потрібні складні системи. Використовуйте:

• Trello — легкий (також візуальний), чудово підходить, якщо ваша команда вже ним користується
• Проблеми GitHub - краще, якщо у вас вже є команда
• Jira — застосовується, коли ви працюєте в спринтах

Кожна помилка повинна містити кроки для її відтворення, знімки екрана та пріоритет.

5. Регресійне тестування

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

Просто переконайтеся, що все працює. Ручне тестування проти автоматичного тестування

Що є найбільш доречним для MVP? Це питання виникає дуже часто. І воно є цілком обґрунтованим. Ручне тестування легко ініціювати. Не потрібно ніяких інсталяцій, ніякого програмування — лише ваш продукт, ваш контрольний список і людина, яка ним керує. З іншого боку, автоматизоване тестування економить час у довгостроковій перспективі, але виявляється більш трудомістким з точки зору впровадження. То що ж підходить саме вам?

На початку використовуйте ручне тестування з метою забезпечення якості

Ручне тестування — це ваша біблія. Чому?

• Швидко запускається
• Ви можете швидко редагувати тестові випадки у міру зміни функцій
• Візуальні тести або тести інтерфейсу користувача

Ви можете використовувати Руководство по контролю качества ручного тестирования будет особенно полезно при живых демонстрациях, тестировании перед запуском и интервью с пользователями.

Коли автоматизація має сенс

Як стартап, ви маєте стабільний MVP і у вас є:

• Доставка щотижня або щодня
• Підтримуйте послідовний потік користувачів
• Розширення вашої команди розробників або бази користувачів

Ось декілька доступних і недорогих інструментів для автоматизованого тестування, які можуть бути цікавими:

Селен

Оригінальна платформа для автоматизації браузерів з відкритим кодом. Багатозадачність у різних мовах і браузерах. Застосування: команди, яким потрібна гнучкість і сумісність з різними браузерами.

Cypress

Сучасний, простий у використанні інструмент, що працює в браузері. Базується на JavaScript, простий у написанні, читанні та обслуговуванні. Найкраще підходить для: команд, які створюють SPA на основі фреймворків, таких як React або Vue.

Драматург

Відкритий код, написаний Microsoft і заснований на Chromium, Firefox та WebKit. Без проблем тестує сучасні веб-додатки. Найкраще: Більш складні вимоги до веб-тестування, такі як емуляція мобільних пристроїв.

Поштар

Автоматичні перевірки API можна виконувати не тільки за допомогою колекційного запускача та моніторів у Postman, але й не тільки під час ручного тестування API. Найкраще підходить для: команд, що працюють з API, або важких додатків.

TestRail

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

Як вибрати відповідний стек тестування

Не обов'язково мати все це. Насправді, на початку краще надіслати мені менше, а я отримаю більше. Запитайте:

• Який наш стек? (JavaScript? Python? Щось інше?)
• Що нам потрібно протестувати? (Веб-інтерфейс? API? Логіку бекенду?)
• Яка частота випуску наших продуктів?
• Хто пише тести?

Вибирайте інструменти, які не чинять негативного впливу на вашу команду.

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

1. Включіть QA до вашого CI/CD

Використовуйте GitHub Actions, GitLab CI або CircleCI для виконання простих тестів при кожному пуші. Навіть якщо це лише кілька перевірок працездатності, це допомагає виробити хороші звички.

2. Напишіть тестові випадки, які можна використовувати повторно

Кожного разу, коли ви тестуєте один потік, ви повинні зробити його повторюваним тестовим випадком. Збережіть його в документі Notion або TestRail. Таким чином, вам не доведеться починати з нуля кожного спринту.

3. Визначте пріоритети автоматизації

• Реєстрація
• Основні дії на панелі інструментів
• Увійдіть
• Платежі

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

4. Переглядайте QA кожного спринту

Після завершення кожного спринту запитайте:

• Що зламалося?
• Що ми пропустили?
• Що краще: автоматизація чи документація?

QA — це не просто тестування, це навчання та вдосконалення способу, яким ваша команда створює програмне забезпечення.

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