Качество начинается до первой строки кода
Как находить риски в требованиях и превращать вопросы к продукту в проверяемые сценарии.
Сначала договоритесь о результате
Представьте задачу: «Пользователь может сохранить материал». Требование кажется ясным, пока не появляются вопросы: нужен ли вход, можно ли сохранить материал дважды, что случится после удаления публикации и сохранится ли выбор на другом устройстве? Список вопросов — уже полезный результат работы QA.
Запишите пользователя, его цель, начальное состояние, действие и наблюдаемый результат. Для сохранения материала результат можно сформулировать так: после повторного входа тот же материал виден в личной коллекции только этому пользователю.
Найдите границы и состояния
Постройте простую модель: гость, авторизованный пользователь, истёкшая сессия. Для каждого состояния проверьте видимость действия, ответ сервера и сохранность данных. Отдельно рассмотрите повторный запрос, недоступную сеть и удалённый материал.
Не пытайтесь покрыть всё одинаково. Оцените вероятность ошибки и её влияние. Утечка чужого избранного важнее неудачного текста уведомления, хотя оба наблюдения нужны команде.
Превратите вопросы в примеры
Обсудите с разработчиком и продуктом конкретные примеры до реализации. Например: два одинаковых запроса дают одну запись; попытка изменить чужую коллекцию отклоняется; после восстановления сети пользователь видит подтверждённое состояние.
Критерий готовности должен описывать поведение продукта. «Кнопка работает» ничего не говорит о серверной проверке прав, повторных запросах и хранении данных.
Проверьте свою модель
Сопоставьте каждый важный риск хотя бы с одним сценарием и ожидаемым результатом. Укажите источник ожидания: требование, решение команды или документированный контракт. Неподтверждённые предположения оставьте вопросами.
Этот демонстрационный материал подготовлен редакцией QA Orbit как пример практической статьи. Используйте подход на своём проекте с учётом его рисков.