Содержание
Зачем платить за непродуктивную работу? За работу, которая не приносит каких-либо результатов? Есть ли в таком случае смысл оплачивать труд тестировщика (QA инженера)? Чем вообще он занимается? Возможно ли распределить его функции между другими участниками команды?
Вопросы такого рода неизменно возникают у заказчиков программного продукта. Не забывайте — каждая часть проделанной работы должна быть одобрена потребителем, так как именно он ее оплачивает. Мы хотим подробно разобрать функции QA инженера на проекте и очень надеемся, что эта статья ответит на все вопросы, озвученные во вступлении.
Анализ и постановка задачи
Зачастую у заказчика не оказывается времени на детальное описание условий задачи и на дотошную проверку технического задания. Именно поэтому в виде задачи мы периодически получаем какую-то отрывочную идею, выраженную в виде картинки, схемы или набора фраз. В результате формулировка чужой мысли может завершиться произвольно. Более того — она может обрасти лишними деталями, не вписывающимися в изначальную концепцию проекта.
Исправить сложившуюся ситуацию может только опытный разработчик. Однако такие специалисты — на вес золота. И чаще всего они уже заняты на более ответственных участках проекта. В результате задача переадресовывается QA инженеру. Это позволяет избежать большинства трудностей. Во-первых, экономится время заказчика (он не отвлекается на мелкие уточняющие вопросы). Во-вторых, экономится время разработчиков, которым и своих задач хватает по самые уши.
Подготовка и проверка обновлений
Второй момент. Иногда разработчик смотрит на условия задачи и методы ее реализации лишь с одной стороны. Соответственно ему нужен свежий и независимый взгляд на проблему. QA инженер не ищет способы реализации проекта и не погружается с головой в технические детали. Это позволяет ему смотреть на задачу как бы со стороны.
QA специалист ищет недостатки в уже подготовленных обновлениях. Таким образом, два зайца убиваются одним выстрелом. Во-первых, снова экономится время заказчика. Во-вторых, повышается качество подготовки обновлений.
Если проект выходит из категории стартапа, что существенно увеличивает его сложность, рекомендуется регрессионное тестирование. Оно отнимает массу времени. Готов ли заказчик потратить его на проверку обновлений? Вряд ли. В то же время, сокращение времени на проверку чревато пропуском критических багов на продакшн. Вывод очевиден — такую задачу разумнее переложить на мускулистые плечи QA инженера.
Служба поддержки
Максимально полное представление о положение дел на проекте имеет именно QA специалист. Он многократно проводит проверку всего функционала и владеет всей необходимой информацией.
QA инженер знает, кто из разработчиков отвечает за каждый участок проекта, и поэтому может оперативно переадресовать запрос заказчика в нужном направлении.
И еще. Обнаружив баг, QA инженер не отдает его на растерзание разработчикам, а устанавливает причины дефекта. Таким образом, программисты не тратят время на поиск информации о проблеме, а заказчик не отвлекается на постоянные уточнения технических деталей.
Безусловно, служба поддержки может справиться с этим еще лучше. Но только в том случае, если она существует.
Ответственность за внедрение нового функционала
Заказчик неожиданно принимает решение о добавлении нового функционала. QA инженер сразу же начинает подробно расписывать полученное техническое задание. Казалось бы, все просто. Но возникает одна проблема. Внедрение нового функционала зачастую влечет изменения и на других участках проекта. Выявление этих участков и постановка задач перед разработчиками ложится на QA инженера. Кроме того, представляя интересы пользователя, он может самостоятельно инициировать внедрение нового функционала. Контактируя с заказчиком и принимая задачи, QA инженер почти неизбежно генерирует идеи по оптимизации проекта.
Организация труда
Поехали дальше. QA специалист должен обращать внимание не только на функционал, но и повышать уровень разработки. Некорректное обновление или задержка во времени также влияют на стоимость продукта. Предложения по изменению организации труда зачастую ускоряют разработку и положительно сказываются на ее качестве.
В то же время нельзя забывать, что программистам свойственен синтетический подход к решению проблемы. Иными словами, при возникновении трудностей, они предпочитают попросту обойти препятствие. Кто исправит эту ситуацию? Конечно же, QA инженер!
Наконец, отметим, что процесс оптимизации проекта должен носить перманентный характер. В случае внедрения всех обновлений скопом он может просто остановиться. В этой связи, QA инженер обязан непрерывно отслеживать негативные тенденции, обсуждать их и предлагать способы устранения недостатков.
Случаи из практики
От скучной теории — к живой практике. Мы подготовили два простых примера, иллюстрирующих работу отдела QA наилучшим образом.
№1. Нами был подготовлен и успешно принят проект по приему заказов на доставку продукции. При этом клиент наотрез отказался пользоваться услугами QA. Спустя некоторое время после запуска проекта, выяснилось, что клиенты могут оплачивать заказы недействительными банковскими карточками! Чтобы такой баг прошел мимо QA инженеров невозможно представить даже в бреду.
№2. Отдел QA не участвовал в запуске одного из наших проектов. Однако спустя два месяца власть переменилась. В смысле, было принято решение подключить QA инженеров к процессу разработки. В результате наши специалисты нашли множество багов разной степени важности. Самый яркий пример: введенный пароль можно было подтверждать любым набором символов — он принимался в любом случае. Безопасность отдыхает.
Вывод
Очень часто QA специалист выполняет огромный объем работы, скрытой от посторонних глаз. Ее довольно трудно оценить и измерить навскидку. Однако такая работа, хоть и не престижна, но необходима для выпуска действительно качественной продукции.