QA-outsourcing. Особенности и тонкости

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Сложно не сталкиваться с аутсорсингом занимаясь разработкой ПО. Либо часть кода написана в теплых странах, либо дизайн был получен издалека, либо поддержка продукта лежит на плечах партнеров. Фактически, каждый этап производства может быть вынесен за пределы компании и передан в заботливые руки аутсорсинг-провайдеров. Не является исключением и обеспечение качества программного продукта (QA-outsourcing). Вот о том, как сделать этот процесс проще и понятнее и пойдет речь в этой статье. Мнение автора основано на собственном опыте работы как в составе аутсорс-команд, так и в составе компании — заказчика услуг внешнего тестирования.

Как и в других случаях, мысль о работе со сторонней QA-командой имеет под собой вполне определенную почву. Для небольших команд этой почвой может быть отсутствие выделенных тестировщиков. Особенно это ощутимо для небольших shareware продуктов, где команда состоит из самого же автора идеи. Наличие же своей тестовой лаборатории, тоже не всегда дает 100% уверенность. Задачи множатся, дедлайны давят, а рук не хватает. И, наконец, даже в самой спокойной обстановке и при полном достатке ресурсов остается место стороннему аудиту. Это может быть как проверка продукта на широком парке платформ и конфигураций, или использование новых методик и подходов. Взгляд со стороны может открыть абсолютно свежий пласт проблем.

Итак, в первую очередь, необходимо поставить перед собой ясную и понятную цель привлечения сторонних специалистов. Если будет угодно — SMART-цель. Тем самым, заранее прибрав некоторую часть проблем при общении, а также застраховав себя от ложных ожиданий. Поскольку аутсорс-команда не в силах найти всех проблем и обеспечить Абсолютное Качество.

QA-команда, особенно сторонняя, в большинстве случаев не решит проблемы. Проблемы могут быть выявлены, локализированы и зафиксированы. Решать проблемы продукта, а тем более процесса разработки необходимо самой команде разработки. И об этом не стоит забывать.

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

Следующим этапом будем считать подготовку интерфейса взаимодействия с аутсорсерами. Это может быть подготовка формата отчета, предоставление доступа к багтрекеру, либо просто подготовка отдельного почтового ящика для писем. Все зависит от проекта, команды и процесса разработки. Расчетливые QA команды имеют наготове свои системы ведения проектов, багтрекеры и т.д. Что очень поможет, если ранее подобные системы в проекте не использовалось. Но при более формализованной разработке и состоявшемся процессе добавление новых систем ни к чему. Стало быть, формируем канал общения.

Далее можно приступить к поиску конкретных исполнителей. Их можно найти на биржах фрилансеров, где количество желающих предоставить QA-услуги всегда больше количества проектов. Можно глянуть в сторону крупных сообществ объединяющих в себе тысячи специалистов. Еще одним вариантом является компании, ориентирующиеся именно на QA-аутсорсинге. Они, конечно же, бывают разных размеров и предлагают разных наборы услуг.

Отдельно стоит остановиться на географии. Фактическое расположение аутсорсеров может заметно повлиять на результаты работы с ними. Язык, особенности менталитета, разница во времени могут, как упростить, так и усложнить работу. Работаете на западном рынке — отдайте предпочтение местным жителям, они скорее могут, заметят специфические недоработки, из-за океана таковыми не кажущиеся. Да и лишний пруфинг (proofing) текста носителем языка не вредил ещё ни одному продукту. C другой стороны, команде из вашего города всегда можно назначить встречу и оперативно решить ряд вопросов и, таким образом, например, справится с отсутствием документации по проекту.

Справившись со всем вышеперечисленным, можно задуматься и о финальной части. Получение результатов и оплата. Этим пунктам стоит уделить серьезное внимание и не откладывать их в долгий ящик. Дедлайн, объемы работ, сумма и методы оплаты должны быть оговорены и согласованы заранее. Учтите риски, оговорите формы отчетности, подберите подходящие обеим сторонам платежные механизмы. Тем самым будет готова почва для плодотворной работы, а может и для долговременного сотрудничества. Обе стороны смогут получить желаемое и попрощаются, пожав друг другу руки. Пусть и виртуально.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU