Проверяем продукт до того, как его увидят ваши клиенты. Мы отвечаем перед заказчиком, а не перед подрядчиком, — поэтому находим то, что разработчик показывать не заинтересован.
Независимая проверка нужна там, где цена ошибки в рабочей среде выше стоимости тестирования. Достаточно одного признака:
Вы принимаете работу подрядчика и не знаете, что именно проверять
В команде нет своих QA-инженеров или они заняты другими проектами
Продукт сделан своими силами и нужен независимый взгляд
Ошибки регулярно доходят до пользователей и стоят денег
Перед релизом нет уверенности, что не всплывут сюрпризы
Нужны специфические проверки: нагрузка, безопасность, интеграции
«Приёмочное тестирование — независимый взгляд: мы отвечаем перед заказчиком, а не перед подрядчиком.»
Набор видов тестирования подбираем под продукт и риски. В каждой карточке — что проверяем и что вы из этого узнаёте.
Проверяем соответствие продукта техническому заданию и заявленным требованиям, сценарий за сценарием.
Что вы получаете
Документальное подтверждение, что заявлено и что работает на самом деле — с чем идти к подрядчику.
Проверяем корректность и стабильность обмена данными с внешними системами и между модулями. Инструменты: Postman, Charles.
Что вы получаете
Уверенность, что данные не теряются на стыках систем — там, где ломается чаще всего.
Оцениваем не только внешний вид, но и логичность и удобство интерфейса для конечного пользователя.
Что вы получаете
Список мест, где пользователь спотыкается, — до того как это увидят в отзывах.
Ищем уязвимости и технические лазейки в защите конфиденциальных данных. Инструменты: OWASP ZAP, Burp Suite, Nessus.
Что вы получаете
Уязвимости устраняются до того, как о них узнают посторонние.
Моделируем пиковый наплыв пользователей и проверяем, справится ли инфраструктура. Инструменты: K6, JMeter, Yandex Tank.
Что вы получаете
Понятный потолок нагрузки и что именно ляжет первым при его превышении.
Сверяем ожидания реальных пользователей с тем, что сдаёт разработчик: сценарии и интервью.
Что вы получаете
Обратная связь от людей, которые будут этим пользоваться, а не от команды разработки.
Подключаемся разово на приёмку, усиливаем вашу команду или перестраиваем процесс качества целиком.
Разовая независимая проверка перед приёмкой работ у подрядчика.
Условия
Когда тестирование нужно постоянно, а своих инженеров нет.
Условия
Когда тестирование в команде есть, но ошибки всё равно доходят до рабочей среды.
Условия
Шесть этапов от разбора требований до повторной проверки. Вы видите промежуточные результаты, а не только финальный отчёт.
ТЗ, сценарии и зоны риска
Виды проверок, объём и инструменты
Чек-листы, тест-данные и окружение
Прогон проверок и фиксация дефектов
Дефекты по критичности и их последствия
Проверка исправлений со скидкой 50%
Отчёт пишется так, чтобы с ним можно было идти к подрядчику и принимать решения, а не подшить в папку.
Посмотреть пример отчёта — по нему видно, в каком виде вы получите результат.
Заступник
Разработали приложение для защиты детей в опасных ситуациях с трансляцией геопозиции и вызовом помощи
Просмотреть проект
PreventAge
Модернизировали образовательный веб‑сервис и админ‑панель, усилили стабильность и производительность
Просмотреть проект
Фармакопейка
Мобильное приложение для сети аптек: поиск и заказ лекарств, консультации и карта ближайших точек
Просмотреть проект
Образовательный центр ЧТПЗ
Мобильное приложение для студентов, преподавателей и родителей программы «Будущее Белой металлургии»
Просмотреть проект
Feelo
Кроссплатформенное приложение для отслеживания эмоций и поддержки ментального состояния
Просмотреть проект
РОСТерм
Мобильный каталог инженерной сантехники: монтажник собирает заявку прямо на объекте
Просмотреть проект
Академия Спортсменов
Мобильное приложение и админ-панель: спортсмен сдаёт разряд по видео и получает награду почтой
Просмотреть проект
СпортАктиV
Мобильное приложение и админпанель для Министерства спорта Рязанской области
Просмотреть проектПотому что подрядчик проверяет свою работу и отвечает за сроки. Мы отвечаем перед вами и заинтересованы найти проблемы, а не показать, что всё в порядке. Это не значит, что подрядчик недобросовестен, — просто у внутреннего тестирования и внешней приёмки разные задачи.
Повторная проверка идёт по уже готовым чек-листам и тест-данным: подготовительная часть работы сделана в первый раз, платить за неё второй раз не за что. Проверяем исправление найденных дефектов и то, что правки ничего не сломали рядом.
Зависит от того, где у вас цена ошибки выше. Для продукта с платежами и персональными данными в приоритете безопасность и интеграции; для сервиса с пиковой посещаемостью — нагрузочное. Набор согласуем на этапе плана и объясним, почему именно такой.
Да, на любой стадии. Чем раньше, тем дешевле обходится исправление, но и приёмка почти готового продукта имеет смысл: вы хотя бы будете знать, что принимаете.
Стоимость зависит от объёма функциональности, набора видов тестирования и наличия документации: тестировать продукт без ТЗ дороже, потому что требования приходится восстанавливать. Оценку даём после разбора требований, с фиксированным объёмом и сроком.
Отчёт составлен так, чтобы его можно было передать подрядчику как перечень к исправлению: каждый дефект с шагами воспроизведения, критичностью и последствиями. После исправлений проводим повторную проверку.
Расскажите, что за продукт и на какой он стадии. Предложим набор проверок и назовём объём работ.
