Как тестировать ПО, если у вас нет своих тестировщиков

Когда люди рассуждают о тестировании ПО, они чаще всего предполагают наличие в каждой компании своей команды 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+ проектами за плечами. Свяжитесь с нами, мы знаем таких.

Об авторе

Редакция сайта

Поиск
Облако меток
8 марта (1)api (5)Game of testers (1)ISTQB FL (1)kpi (1)kpi в тестировании (1)postman (1)Quality lab. Meetup (2)regress тестирование (1)rest api (2)scrum (1)scrumban (1)smoke тестирование (1)soap api (1)sqa days (1)TDD (2)UX-экспертиза (1)won't fix (1)А/Б тестирование (1)День дарения книг (1)День защитника Отечества (1)День рождения ЛК (1)День смеха (1)Мероприятия (2)Опрос (1)ПОИНТ (3)Приёмочное тестирование (1)РИТ (1)Эльбрус (1)Юмор (2)автоматизация тестирования (7)аудит (2)аудит тестирования (2)аутсорс (5)баги (4)банковские приложения (1)бесплатный вебинар (1)вакансии (5)варианты использования (1)веб-приложения (1)веб-тестирование (2)верстка (1)галеры_qualitylab (1)граничные значения (1)дедлайн (2)диаграмма Исикавы (1)дополнительные материалы (3)ежемесячный отчет (14)интернет-магазин (1)исследовательское тестирование (2)коммуникации (4)конфликты (2)кроссбраузерное тестирование (1)курсы для тестировщиков (2)лаборатория качества (21)лайф-хаки (4)локализация (1)медицинское ПО (1)международные проекты (1)метрики (3)модель ситуационного лидерства (1)мотивация (3)новый год (2)обеспечение качества (13)обучение (8)оптимизация тестирования (13)оффлайн тренинги (1)поздравление (1)поздравления (6)пользовательские истории (1)пример (2)проблемы (3)проектные риски (1)проекты (4)процесс тестирования (25)развитие команды (6)разработчики (1)распределенная команда (3)решения (4)ритейл-приложения (1)сертификация ISTQB FL (1)собеседование (1)специализация (2)с чего начать (2)тест-анализ (2)тестирование (49)тестирование безопасности (3)тестирование для бизнеса (2)тестирование мобильных приложений (2)тестирование серого ящика (1)тестирование требований (1)тестирование черного ящика (1)тестировщики (10)тестовая документация (1)тестовое покрытие (1)тесты (1)техники тест-дизайна (1)требования (1)удобство использования (2)управление проектами (4)управление рисками (1)успехи (6)целевая аудитория (3)юзабилити (3)
Получите совет