IT-блоги • Как тестировать ПО, если у вас нет своих тестировщиков

Когда люди рассуждают о тестировании ПО, они чаще всего предполагают наличие в каждой компании своей команды QA-инженеров. Именно этот коллектив призван обеспечить качество продукта и освободить разработчиков от необходимости его тестировать.

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

Когда нет QA—команды

Некоторые компании просто не видят смысла в найме QA-инженеров. Другие могут верить (ошибочно), что в мире DevOps собственная команда тестировщиков – это архаизм. Встречаются, конечно, и стартапы, которые слишком малы, чтобы позволить себе найм QA-специалиста в штат.

Хорошая новость: отсутствие штатной QA-команды не означает, что вашему проекту придется расстаться с качественным ПО. При правильном подходе вы можете восполнить этот пробел.

Давайте рассмотрим варианты.

Вариант №1: тестирование продукта силами QA-фрилансеров

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

В остальном не нам вам объяснять минусы фриланса. Назовем его непрактичным и далеким от принципов непрерывной разработки и интеграции CI/CD. Работая с фриланс-одиночками, вы будете испытывать следующие недостатки: 

• низкий уровень навыков тестирования;
• недостаток самоорганизации и низкая эффективность труда (прокрастинация);
• проблемы коммуникации и постановки задач QA-фрилансеру;
• отсутствие гарантий качества выполненной работы;
• риск потери ценной информации и утечки данных;
• нарушение сроков сдачи работы;
• риск «исчезновения» фрилансера в процессе работы или по ее завершении.

Вывод: QA – это не то, что стоит проаодить на разовой или индивидуальной основе.

Вариант №2: тестирование силами собственных разработчиков

Это может звучать пугающе, но на самом деле не всё так страшно. Даже если у вас есть QA-команда, ваши разработчики должны учиться тесно сотрудничать с тестировщиками; в конце концов, это то, чем являются DevOps и QAOps.

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

Стратегии и практики, подобные следующим, могут помочь в этом разработчикам и IT-инженерам, даже если у них нет предыдущего опыта в QA:

• Создание автотестов. Разработчики уже знают, как программировать, – это то, чем они занимаются весь день. Поэтому изучение фреймворка автоматизированного тестирования и написание тестов не должно стать большой проблемой. Если у вас в штате есть такие разработчики, они могут взять на себя автоматизацию тестирования. Даже если у вас есть штат QA-инженеров, разработчики всегда могут помочь в написании автоматизированных тестов.
• IT-инженеры могут помочь с shift-right тестированием. Shift-right – это проведение тестирования, когда продукт уже находится в производстве. В некотором смысле это то, что разработчики уже делают, когда мониторят приложения. Чтобы повысить эффективность shift-right тестирования, попросите своих программистов не ограничиваться отслеживанием проблемы. Они должны использовать идеи/инсайты мониторинга производства для улучшения общего качества программного обеспечения.
• Непрерывная обратная связь. Без штатной QA-команды трудно доносить до разработчиков информацию о проблемах с качеством ПО. Также IT-инженерам трудно самостоятельно узнать, как клиенты хотят, чтобы приложение работало. Вот почему важно установить непрерывный цикл обратной связи непосредственно между разработчиками ПО и его пользователями, чтобы каждая сторона могла обсуждать друг с другом вопросы качества ПО.
• Коллективная ответственность за качество ПО. С идеологической точки зрения каждый разработчик должен отвечать за качество программного обеспечения. Это должно происходить, даже если у вас есть команда тестировщиков на full-time. Но в отсутствие QA-специалиста на проекте нет никого, чья основная работа – тестирование ПО. В результате IT-специалисты не могут «перевести стрелки» и обязаны нести полную ответственность за качество ПО.
• Развивайте QA-скиллы. Вы окончательно решили обойтись без QA-специалистов, но не готовы рисковать качеством своего продукта? Тогда готовьтесь прокачивать своих разработчиков инструментами для обеспечения эффективности QA. В арсенал стоит включить как минимум: автоматизацию тестирования (что устранит необходимость тратить время на ручное тестирование), продвинутые навыки отладки продукта (которые ускорят процесс интерпретации результатов тестов) и параллельное тестирование (которое увеличивает поток единовременно проводимых тестов).

Вариант №3: заказать услугу аутсорсингового тестирования

Или, другими словами, попросить провайдера QA-услуг подобрать под ваш продукт и бюджет готовую QA-команду, заключив договор с гарантиями качества и сроков исполнения.

Обо всех плюсах и минусах аутсорс-тестирования можно прочитать тут.

Если обобщить

Минусы:

• дорого: для тех, кто привык сравнивать только по ставкам;
• небезопасно: для тех, кто не привык подписывать NDA;
• не для всех: особенно если вы маленький, но очень гордый стартап без инвестиций и прибыли;
• зависимость от наработок подрядчика: если вы не проговорили передачу вам документации.

Плюсы:

• устраняются все недостатки QA-фрилансеров: низкая квалификация, потеря коммуникации, срыв сроков, отсутствие гарантий, плохая дисциплина;
• нивелируется большая часть недостатков тестирования силами своих программистов: падение скорости разработки, попытки скрыть баги для выполнения KPI, высокий процент пропущенных багов, недовольство коллектива, псевдоэкономия;
• снижается управленческая нагрузка: в аутсорс-команде, как правило, есть свой АМ и точно есть ТМ;
• QA-экспертиза: помимо специалистов, вы получаете многолетний опыт подрядчика в построении QA-процессов с нуля;
• непредвзятость и независимость: аутсорс-специалисты имеют свежий взгляд на продукт, а еще не станут умалчивать о проблемах на проекте;
• вариативность: при небольшом объеме работ можно подключать аутсорс-специалиста на несколько часов в неделю;
• перекладывается ответственность: за качество продукта отвечаете не вы и команда разработки, а подрядчик;
• оптимизация бюджета проекта: минус зарплатные налоги, оргтехника/рабочее ПО, больничные/декреты/отпуска, затраты на подбор/обучение/увольнение и прочее.

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

В нашем примере штатный тестировщик с окладом 70 тысяч рублей в месяц обходится компании на 14 877 рублей дороже, чем более дорогостоящий специалист-аутсорсер, имеющий почти вдвое больший оклад. Если взять в расчет отдел из 9 человек, которые отработали год, выгода составит 1 606 716 рублей. А это уже деньги.

Какой вариант выбрать?

Вопрос риторический, ведь однозначного ответа нет.

В идеальном мире у каждой компании была бы большая и динамичная команда QA-инженеров. Они бы проводили свои дни, совершенствуя качество каждого выпуска кода, идущего по конвейеру CI/CD.

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

Кого-то устраивает, что ПО пишет и тестирует один человек — тогда вы видели наши рекомендации. Искренне надеемся, что у вас получится сделать этот процесс эффективнее. А кому-то прямо сейчас нужна помощь экспертов в тестировании со 150+ проектами за плечами. Свяжитесь с нами, мы знаем таких.