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