У каждого сегмента рынка своя специфика бизнеса и разный подход к разработке. Поэтому, заказывая тестировщиков в агентстве, нужно не просто смотреть на сумму в коммерческом предложении, но и трезво оценивать, что и кого вам предлагают.
Тестирование в стартапах
Главная цель стартапа — как можно быстрее выйти на MVP: выпустить минимально жизнеспособный продукт, показать его и перейти к следующему раунду инвестиций. Все процессы должны работать на высоких скоростях и не терять в качестве, поэтому основатели чаще всего работают по Agile и Scrum — гибким методологиям. Это позволяет быстро работать, оперативно вносить изменения и на любом этапе сделать пивот — изменить итоговый продукт частично или полностью.
Каких тестировщиков брать: можете поступиться рангом специалиста и взять junior-тестировщика, если он умеет закрывать базовые рабочие задачи и умеет работать в скоростном режиме. Рабочий процесс в стартапе по Agile — это процесс, где задачи формируют и делают на спринтах. Тестировщики проверяют как отдельно выполненные задачи, так и итоговый продукт в целом. В отличие от каскадных методологий, Agile — про скорость и быстрые результаты.
Например, у нас в Qualitica тестирование в стартапе выглядит так:
-
мы подбираем тестировщиков, которые умеют работать с гибкими методологиями
-
тестировщики начинают участвовать в планировании вашего спринта
-
они же проверяют каждую задачу и функционал в рамках этого спринта
-
проверенные задачи уходят дальше по жизненному циклу
Помните: спринт должен закладывать время на регрессионное тестирование — повторную проверку ранее протестированных задач. Это нужно, чтобы проверить, как проверенные функции будут работать с новыми, разработанными в рамках проекта.
Например, тестировщик проверил работу функции «свайп» в Tinder и пропустил ее дальше. Если в продукт добавляют возможность поставить лайк или написать пользователю, «свайп» может сломаться и не работать. Поэтому тестировщики на стартапе постоянно проверяют задачи и их взаимодействие друг с другом.
Продукт, который вы разработали на спринте, нельзя выпускать без регрессионного тестирования. Идеальный процесс выглядит так:
-
Проведение регрессионного тестирования
-
Утверждение релиза
-
Выпуск релиза в бой
-
Проведение smoke-тестирования (минимальной проверки на явные ошибки)
-
Планирование следующего спринта
После этого, когда стартап наконец выйдет на MVP, можно автоматизировать часть функций тестировщика, а часть оставить на ручном управлении. Но на первых порах важно быстро интегрировать человека и, по возможности, оставить его на постоянной основе. Изменений в стартапах так много, что новому тестировщику будет сложно быстро въехать в процесс даже с грамотной тестовой документацией.
Тестирование в digital-агентствах
В digital-агентствах тоже стремятся работать по Scrum и выпускать MVP, но очень немногие реально умеют работать с гибкими методологиями. По опыту знаю — в итоге все скатываются в классические водопадные методологии, и главным становится соответствие конечного результата условиям ТЗ.
Каких тестировщиков брать: специалистов уровня middle, которые хороши в написании тест-кейсов и проводят финальное тестирование продукта перед его сдачей на высшем уровне.
Тестирование проектов digital-агентств — это упор на тестовую документацию. Без хороших тест-кейсов не провести качественное тестирование итогового продукта. То же самое относится к интеграторам — они, как и digital-агентства, сдают заказчику готовый продукт.
Важно, чтобы готовый продукт отвечал всем заявленным требованиям и функциям. Даже если вы измените эти требования по ходу разработки, это нужно документировать.
Идеальный процесс выглядит так:
-
Тестирование продукта (мы делаем по ПМИ — Программе и методике испытаний, ГОСТ 19.301–79)
-
Создание тестировщиками bug-report (отчета об ошибках)
-
Отправка bug-report разработчикам на устранение дефектов
-
Повторное тестирование исправленного релиза по дефектам, которые обнаружили в прошлый раз
-
Финальное тестирование продукта по ПМИ
По опыту Qualitica, классическая структура работы в компании, которая придерживается методологии Waterfall.
Тестирование в e-commerce
Интернет-магазинам, в первую очередь, нужна полноценная техподдержка. Они постоянно добавляют новые фишки, виджеты, функции и акции — случается, что при добавлении чего-то одного слетает все разом. Если магазин успешен, то рано или поздно станет большим и функциональным. И что-то начнет отваливаться.
Каких тестировщиков брать: специалистов уровня junior или middle, которые имеют опыт работы с аналитиками на стороне заказчика. Это важно: чтобы постоянно отслеживать дефекты, они должны работать сообща.
Тестировщик в e-commerce постоянно проверяет работоспособность интернет-магазина и фиксирует неполадки. Аналитик нужен, чтобы отслеживать финансовые показатели, замечать проблемы в пользовательском поведении и сообщать, если что-то не так.
Например, вы заметили, что пользователи стали реже покупать ваш товар через мобильную версию, хотя до этого показатели были отличными. Скорее всего, там что-то случилось: возможно, пользователь не может добавить товар в корзину или у него не получается оплатить покупку. Надо идти и смотреть.
Это — правильный подход. Работа тестировщика здесь — постоянно тестировать одно и то же.
Тестирование проектов банков, страховых и государства
Это крупный и сложный сегмент рынка. В отличие от интернет-магазинов, которые вносят на сайт или в приложения минимальные изменения, банки и страховые меняются радикально. Если уж делают что-то, то это почти всегда новый, глобальный функционал, который должен взаимодействовать со старым и интегрироваться с другими системами.
Каких тестировщиков брать: middle или senior, которые имеют опыт в интеграционном тестировании и будут заняты только на вашем проекте. Их нельзя отвлекать на другие задачи, а сами они должны быть максимально завязаны на вашей команде и внутренних процессах. Зачастую такие тестировщики даже ходят на те же вечеринки, что и сотрудники крупного заказчика.
На банки часто жалуются — если в их системе что-то слетает или неверно работает, цена ошибки слишком высока. Клиенты могут потерять деньги или невовремя их провести, а это критично. Поэтому главная цель тестирования банковских и страховых продуктов — их стабильная работа и грамотное взаимодействие со сторонними системами.
Ищите тестировщика на полное погружение в проект. Иначе он не поймет, как работают эти системы — огромные, сложные, с кучей интеграций и запросов. Это механизм, где постоянно что-то отваливается, поэтому тестировщик должен быть почти что inhouse-сотрудником.
Кроме того, тестировщик должен уметь проводить нагрузочное тестирование. Это важно, особенно для государственных продуктов, когда разовый наплыв пользователей «роняет» всю систему. Например, так было на государственном сервисе перед началом учебного года, когда родители не могли записать своих детей в школу, и в пандемию, когда сервис «падал» из-за огромного количества запросов на пропуска.
Как правильно выбрать и оценить подрядчика
Повторюсь: у каждого сегмента рынка — своя специфика, свой подход и свои задачи. Но есть общие шаги, придерживаясь которых, вы сможете отобрать для себя лучшее предложение по тестированию:
Разберитесь, что именно вы хотите получить от тестирования, еще до поиска подрядчика
Это может быть базовая проверка, упор на полную документацию для последующего тестирования или специалист на поддержку «под ключ».
Отберите компании по клиентам и кейсам
В крупную компанию, где все завязано на долгом процессе разработки, не стоит брать тестировщиков, которые привыкли работать на стартапах с его спринтами и маленькими релизами. И наоборот.
Оцените, какое взаимодействие предлагают тестировщики
От этого зависит, правильно ли они поняли цель вашего обращения. Например, они могут просто тестировать конечный продукт или внедриться в вашу команду и тестировать все, что выдают разработчики.
Одни предложат вам разовое тестирование на 20 часов, а другие скажут: «Ребята, мы не знаем ваш проект, но очень хотим узнать. Давайте поступим так — мы возьмем вашу документацию или напишем ее сами, пройдемся по всем сценариям и поймем, как должен работать ваш продукт. После этого мы сделаем отчет об ошибках, отправим вам на доработку и снова проведем тестирование. Даем вам Васю и Петю — они поработают с вами, а потом смогут внедрится в вашу команду, полностью погрузиться в проект и напрямую с вами планировать работу».
Первый подрядчик предложил вам 20 часов, второй — 200 часов. Да, первый обойдется дешевле, но во втором случае тестировщики будут «ваши» и смогут не просто протестировать продукт, но и повысить его качество. А первые просто сделают беглое тестирование — это поможет на первом этапе, но дальше-то что?
Не везде нужны «сеньоры», не везде важна идеальная графика, не везде плохи «джуны». Грамотно выбирайте агентство тестирования, а в КП оценивайте формат взаимодействия и скиллы подрядчика, а не только стоимость. Правильное агентство подберет правильную стратегию работы и тех людей, которые умеют с этим работать.
Полный текст статьи читайте на CMS Magazine
