Услуга · Тестирование и QA

Функциональное тестирование

Задача - убедиться, что продукт ведёт себя правильно не только на показательном пути, но и во всех остальных. Дефект, найденный до выпуска, обходится в разы дешевле того, о котором сообщил клиент.

Сценарии
описаны и переиспользуются
Перед выпуском
полный прогон
Дефекты
с шагами воспроизведения
Риски
перечислены письменно

Состав работ

Главная ценность не в отдельно найденных ошибках, а в накопленном наборе сценариев, который прогоняется из версии в версию.

Обсудить объём

Анализ требований

Вычитываем постановку и находим противоречия до написания кода. Ошибки, пойманные здесь, самые дешёвые.

Набор сценариев

Описанные проверки с ожидаемым результатом, пригодные для повторного использования.

Проверка функций

Основные пути, граничные значения, реакция на заведомо некорректные данные.

Проверка после правок

Убеждаемся, что новое не сломало работавшее. Здесь обнаруживается большинство вернувшихся дефектов.

Описание дефектов

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

Заключение

Что проверено, что осталось за рамками и какие риски вы принимаете, выпуская версию.

Порядок действий

Первый цикл занимает больше времени, потому что набор сценариев пишется с нуля. Последующие прогоны идут значительно быстрее.

01

Погружение

Разбираемся в продукте и выясняем, что критично для бизнеса, а что второстепенно.

02

План

Определяем объём и границы проверки. Проверить всё бесконечное множество вариантов невозможно.

03

Прогон

Проходим сценарии, фиксируем найденное, перепроверяем после исправлений.

04

Заключение

Готовность к выпуску с перечислением непокрытых участков и оставшихся рисков.

Дефект без шагов воспроизведения разработчик закроет как невоспроизводимый. Сообщение вида «не работает оформление заказа» возвращается обратно и путешествует между людьми неделями. Точные шаги, данные и окружение сокращают срок исправления в разы.

Вопросы и ответы

Проверяют, но проходят тот путь, который задумывали, и не замечают собственных допущений. Отдельный человек проверяет как раз то, о чём автор не подумал: некорректный ввод, потерю связи, повторное нажатие кнопки.

Примерно четверть-треть от времени разработки. Если меньше, покрываются только основные пути, и часть дефектов доедет до пользователей. Иногда это осознанный и вполне разумный выбор.

Да, и обращаются с этим часто: система живёт, а качество вызывает вопросы. Начинаем с изучения и составляем набор сценариев по фактическому поведению, поскольку документации, как правило, нет.

Проверим ваш продукт

Опишите систему и то, что вызывает сомнения. Составим план проверки и оценим объём работ.