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