Что входит в направление

Пять видов проверок. Каждый отвечает на свой вопрос: работает ли, выдержит ли, понятно ли и безопасно ли.

Обсудить продукт

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

Проверяем сценарии так, как их проходит пользователь: оформить заказ, оплатить, вернуть, изменить данные. Отдельно смотрим граничные случаи, где чаще всего ломается.

Нагрузочное тестирование

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

Автоматизация тестирования

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

Тестирование UI/UX

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

Тестирование безопасности

Поиск уязвимостей до релиза: инъекции, ошибки прав доступа, утечки данных в ответах и логах, слабые места аутентификации.

Цена ошибки по этапам

Одна и та же ошибка стоит по-разному в зависимости от того, когда её нашли. Это главный аргумент за тестирование как процесс, а не как разовую услугу перед сдачей.

При проектировании

Стоимость ×1. Достаточно изменить пункт в требованиях до начала работ.

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

Стоимость ×3. Разработчик правит код до того, как он попал в сборку.

При тестировании

Стоимость ×10. Задача возвращается разработчику, цикл повторяется заново.

После релиза

Стоимость ×30. Нужен срочный выпуск исправления вне обычного графика.

Нашёл клиент

Стоимость ×100. К стоимости исправления добавляются потери и репутация.

Автотесты окупаются не на первом прогоне, а на двадцатом. Поэтому автоматизировать имеет смысл стабильные сценарии, которые проверяются перед каждым релизом. Автоматизировать то, что меняется каждую неделю, - способ потратить бюджет на поддержку самих тестов.

Как мы тестируем

Результат работы - не список «всё плохо», а воспроизводимые дефекты с приоритетами, по которым разработчик может сразу работать.

01

Разбор продукта

Изучаем сценарии, аудиторию и то, что критично для бизнеса. Тестировать всё одинаково тщательно нет смысла.

02

План и чек-листы

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

03

Прогон и отчёт

Каждый дефект - с шагами воспроизведения, скриншотом и приоритетом. Без этого отчёт бесполезен для разработки.

04

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

После исправлений проверяем не только сам дефект, но и то, что рядом ничего не сломалось.

Частые вопросы

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

Да, это частый запрос перед приёмкой работ у подрядчика. Мы не заинтересованы скрывать дефекты, поэтому отчёт получается независимым. Такую проверку лучше заказывать до подписания акта, а не после.

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

Три цифры: сколько одновременных пользователей система держит комфортно, где начинается замедление и что именно упирается - процессор, диск, база или код. С этим можно осознанно решать, наращивать ресурсы или оптимизировать.

Проверим продукт до пользователей

Расскажите, что нужно протестировать и в какие сроки. Составим план проверок и назовём стоимость по объёму сценариев.