На стадии замысла
Множитель 1. Достаточно исправить формулировку в постановке задачи.
Пять направлений, и у каждого свой вопрос: делает ли положенное, вынесет ли наплыв, разберётся ли человек и нет ли брешей.
Вручную повторяем действия клиента: оформление заказа, оплата, возврат, правка своих данных. Отдельным блоком идут пограничные ситуации, на которых чаще всего и рушится.
Имитируем наплыв посетителей и ловим точку, где система перестаёт справляться. Выяснить свой предел заранее обходится дешевле, чем обнаружить его в день распродажи.
Ключевые пути проверяются самостоятельно перед каждым выпуском. Уходят и однообразная ручная работа, и опасение что-либо выкладывать.
Наблюдаем за настоящими людьми на настоящих телефонах: в каком месте они застревают, что не удаётся отыскать и по какой причине заказ остаётся неоформленным.
Выявляем бреши до релиза: внедрение в запросы к базе, промахи в разграничении прав, избыточные сведения в ответах сервера и записях журналов, уязвимости механизма входа.
Цена одного и того же дефекта определяется тем, на каком этапе его нашли. Это главный аргумент за регулярные проверки вместо единственного прогона накануне приёмки.
Множитель 1. Достаточно исправить формулировку в постановке задачи.
Множитель 3. Разработчик меняет строки, пока они не попали в сборку.
Множитель 10. Работа уходит обратно исполнителю, и цикл повторяется целиком.
Множитель 30. Требуется внеплановый выпуск с экстренной заплаткой.
Множитель 100. К стоимости работ добавляются упущенная выручка и подмоченная репутация.
Вложение в автоматизацию окупается не сразу, а после десятков прогонов. Поэтому машине передают устоявшиеся пути, которые проходятся при каждом релизе. Автоматизировать то, что перекраивается еженедельно, - значит спустить бюджет на сопровождение самих тестов.
Результатом становится не жалоба на общее качество, а воспроизводимые замечания с расставленными приоритетами, по которым разработчик приступает к делу немедленно.
Изучаем пути пользователей, их состав и то, что критично для бизнеса. Уделять всем участкам равное внимание бессмысленно.
Фиксируем перечень проверок, список устройств и браузеров. Документ утверждается с вами и задаёт как трудоёмкость, так и стоимость.
К каждому замечанию прилагаются последовательность действий, изображение экрана и оценка серьёзности. Иначе документ теряет смысл.
Получив исправление, смотрим не только на него, но и на соседние участки: не сломалось ли что-то попутно.
Разумеется, проверяют, но убеждаются, что созданное ведёт себя согласно замыслу. У проверяющего задача обратная: выяснить, что произойдёт при отступлении от замысла. Роли принципиально разные и в одной голове сочетаются скверно - глаз перестаёт замечать очевидное.
Да, с этим обращаются регулярно накануне приёмки у подрядчика. Утаивать замечания нам ни к чему, поэтому заключение выходит непредвзятым. Проводить такую проверку логичнее до подписания документов, а не задним числом.
Отталкиваемся от вашей статистики, а не от универсального списка. Как правило, достаточно пары-тройки диагоналей телефонов и трёх браузеров - на них приходится подавляющее большинство визитов. Сплошная проверка дорога и не оправдывает затрат.
Три показателя: какое число одновременных посетителей выдерживается без напряжения, с какого момента начинается замедление и какой именно узел становится ограничителем - вычислительная мощность, накопители, база или сам программный код. Имея их, уже можно выбирать между наращиванием ресурсов и переработкой.
Напишите, что подлежит проверке и к какой дате. Составим программу работ и рассчитаем стоимость по числу проверяемых путей.
Заявка принята
Она уже у менеджера. Ответ придёт в течение рабочего дня, а срочные обращения дежурный инженер берёт в работу сразу.
Такого города в списке нет. Проверьте написание.