Все, що потрібно перевірити перед відправкою - згруповано за категоріями та пріоритетами за ступенем ризику

Більшість запусків SaaS зазнають невдачі з однієї з двох причин.

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

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

Цей чек-лист охоплює шість категорій, на які припадає переважна більшість помилок запуску, які ми спостерігаємо в TestMatick. Функціональні проблеми, які порушують основні потоки користувачів. Уразливості безпеки, які викривають дані користувачів. Проблеми з продуктивністю, які руйнуються під реальним трафіком. Прогалини сумісності, які роблять продукт непридатним для використання на половині пристроїв ваших користувачів. Збої в доступі, які блокують цілі сегменти користувачів. І димовий тест, який покаже вам, чи дійсно ваше виробниче середовище працює так, як передбачалося під час постановки.

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

1. Функціональне тестування

Почніть з цього. Функціональне тестування перевіряє, чи робить ваш продукт те, що він має робити. Ніяких ярликів.

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

Основні потоки користувачів

• Реєстрація користувачів та вхід в систему працюють безперервно
• Процес скидання пароля успішно завершено
• Підтвердження електронної пошти надсилається і посилання працюють
• OAuth / SSO логін працює, якщо це можливо (Google, GitHub і т.д.)
• Користувач може виконати основну дію, для якої існує ваш продукт
• Користувач може редагувати та оновлювати свій профіль або налаштування
• Користувач може видалити свій обліковий запис і всі пов’язані з ним дані

Підписка та виставлення рахунків

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

Цілісність даних

• Дані зберігаються коректно і зберігаються після оновлення сторінки
• Одночасне редагування кількома користувачами не призводить до пошкодження даних
• Експорт даних працює і створює точні, повні файли
• Імпорт даних обробляє пошкоджені файли без збоїв
• Пошук повертає точні результати за всіма релевантними полями
• Фільтри та сортування працюють коректно та стабільно
• Пагінація працює в масштабі - протестуйте з великими наборами даних

Сповіщення та електронні листи

• Транзакційні листи надсилаються коректно (привітання, скидання, інвойс тощо)
• Шаблони коректно відображаються в основних поштовиках
• Сповіщення в додатку з’являються та відхиляються коректно
• Налаштування сповіщень зберігаються та застосовуються коректно
• Посилання для відписки працюють і негайно оновіть налаштування

2. Тестування безпеки

Збої в безпеці - це найдорожчі помилки, які ви можете відправити. Це те, що не підлягає обговоренню.

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

Аутентифікація та авторизація

• Неавторизовані користувачі не можуть отримати доступ до захищених маршрутів
• Користувачі не можуть отримати доступ до даних інших користувачів, маніпулюючи ідентифікаторами в URL-адресах або викликах API
• Термін дії токенів сесії закінчується коректно і не може бути використаний повторно після виходу з системи
• Кількість невдалих спроб входу обмежена
• Вимоги до паролів застосовуються як на клієнті, так і на сервері
• Багатофакторна автентифікація працює коректно, якщо її впроваджено

Захист даних

• Конфіденційні дані (паролі, токени, PII) ніколи не реєструються
• Відповіді API не виводять дані за межі того, що повинен бачити користувач, який їх запитує
• Завантаження файлів перевіряється на тип і розмір - без довільного виконання файлів
• SQL-ін’єкція неможлива в жодному з полів вводу користувача
• XSS уразливості відсутні при рендерингу користувацького контенту
• Захист CSRF для запитів, що змінюють стан держави

Інфраструктура

• HTTPS застосовується повсюдно - жодних попереджень про змішаний вміст
• Заголовки безпеки налаштовані правильно (CSP, HSTS, X-Frame-Options)
• Повідомлення про помилки не показують трасування стека або внутрішні деталі системи
• Скануються та усуваються вразливості залежностей
• Змінні оточення та секрети не піддаються впливу в клієнтському коді

3. Тестування продуктивності

Ваш продукт повинен працювати під навантаженням. Не лише тоді, коли його тестуєте ви та ваша команда.

Проблеми з продуктивністю мають певну закономірність: під час розробки та тестування все працює добре, а в день запуску з’являється реальний трафік, і щось руйнується. Запити до бази даних, які були швидкими при 100 записах, стають повільними при 100 000. Кінцеві точки API, які працювали з 10 одночасними користувачами, падають при 500. Пункти нижче призначені для того, щоб виявити ці проблеми до того, як це зроблять ваші користувачі. Зверніть особливу увагу на навантажувальне тестування - більшість команд пропускають його, тому що його складніше налаштувати, і більшість інцидентів у день запуску пов’язані саме з ним.

Контрольні показники часу відгуку

• Час завантаження сторінки менше 3 секунд при стандартному підключенні
• Час відгуку API менше 500 мс для стандартних операцій
• Запити до бази даних оптимізовано - немає проблем з N+1 запитами
• Операції пошуку та фільтрації повертають результати протягом 2 секунд
• Завантаження файлів завершується протягом прийнятного часу для максимально допустимого розміру файлу

Навантажувальне тестування

• Додаток обробляє очікуваний трафік у день запуску без погіршення якості
• Налаштовано пул підключень до бази даних для одночасних користувачів
• Фонові завдання не блокують основні потоки програми під час навантаження
• CDN налаштовано для статичних активів
• Для дорогих операцій передбачено кешування
• Автоматичне масштабування налаштоване, якщо використовується хмарна інфраструктура

4. Сумісність з браузерами та пристроями

Ваші користувачі не всі використовують один і той самий браузер на одному пристрої. Перевірте, де вони насправді знаходяться.

Найпоширеніша помилка сумісності - тестування лише на пристроях, якими користується команда розробників. Якщо ваша команда працює на комп’ютерах MacBook з браузером Chrome, ви побачите помилки Chrome і пропустите все інше. Safari на iOS особливо важливий для американських SaaS-продуктів - це браузер за замовчуванням для значної частини вашої користувацької бази, і він має специфічні відмінності в рендерингу та поведінці JavaScript, яких немає в Chrome. Тестуйте на реальних пристроях, де це можливо, а не тільки в інструментах розробника браузера в адаптивному режимі.

Покриття браузера

• Chrome (останні дві версії)
• Safari (останні дві версії - критичні для користувачів iOS)
• Firefox (остання версія)
• Edge (остання версія)
• Chrome на Android (остання версія)
• Safari на iOS (останні дві версії)

Адаптивний дизайн

• Макет функціональний і читабельний при ширині 320px (найменший поширений мобільний телефон)
• Макет функціонує при 768px (планшет)
• Макет функціонує при 1024px, 1280px та 1440px (робочий стіл)
• Сенсорні цілі достатньо великі на мобільних (мінімум 44px)
• Форми можна використовувати на мобільній клавіатурі - поля не закриваються клавіатурою
• Горизонтальна прокрутка відсутня на екранах будь-якого розміру

5. Доступність (WCAG 2.1)

Доступність не є необов’язковою. Це законодавча вимога в багатьох юрисдикціях і сигнал якості для корпоративних покупців.

У США Закон про захист американців з інвалідністю застосовується до веб-додатків у все більшій кількості судових справ. Процеси корпоративних закупівель все частіше включають аудит доступності як частину оцінки постачальників. Окрім юридичних та комерційних міркувань, приблизно 15% населення світу мають певну форму інвалідності, яка впливає на їхню взаємодію з програмним забезпеченням. Наведені нижче пункти охоплюють стандарт WCAG 2.1 AA - найпоширеніший рівень, необхідний для бізнес-додатків у США. Автоматизовані інструменти, такі як Axe або Lighthouse, виявляють близько 30% проблем доступності. Решта вимагає ручного тестування.

Основні перевірки доступності

• Всі зображення мають змістовний альтернативний текст
• Контрастність кольорів відповідає мінімуму WCAG AA (4,5:1 для звичайного тексту)
• Всі інтерактивні елементи мають клавіатурну навігацію
• Порядок фокусування логічний і видимий
• Поля форми мають асоційовані мітки
• Повідомлення про помилки пов’язані з полем, яке їх спричинило
• Назви сторінок унікальні та описові
• Заголовки використовуються в логічній ієрархії (H1 > H2 > H3)
• Вміст не повинен блимати більше 3 разів на секунду (небезпека замикання)
• Тестування зчитувачів екрану проходить для основних потоків користувачів

6. Передпусковий димовий тест

Запустіть його у виробничому середовищі - не в тестовому - за день до запуску. Якщо щось не вдасться, не відправляйте.

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

Випробування виробничого диму

• Новий користувач може зареєструватися та пройти повний курс навчання
• Існуючий користувач може увійти в систему та отримати доступ до своїх даних
• Платіжний процесинг працює з реальною тестовою транзакцією
• Основна функція продукту працює як очікувалося
• Доставка електронної пошти працює з виробничої поштової інфраструктури
• Відстеження помилок активне та отримує події
• Аналітика стріляє правильно
• Чат підтримки або контактна форма працює
• Всі зовнішні інтеграції підключені та реагують
• SSL-сертифікат дійсний і не закінчується протягом 30 днів

І ще одне.

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

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

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

Це не проблема людей. Це проблема процесу. І вона має просте рішення.

Правильний QA-партнер допоможе вам побудувати процес тестування, який масштабується разом з вашим продуктом - такий, що надасть вам впевненості в перший день запуску і продовжить надавати її в міру зростання продукту. Це те, що ми робимо в TestMatick, і це те, що покликаний оцінити повний аудит якості.

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

Хочете отримати повний аудит якості перед запуском?

TestMatick допомагає SaaS-компаніям впевнено виходити на ринок з 2009 року. Ми перевіримо цей контрольний список - і все, чого в ньому немає - перед вашим наступним запуском. Доступний безкоштовний пілотний проект, без укладання контракту.

-> Отримайте повний аудит якості - testmatick.com