6 ступеней в менеджменте тестирования

Сам танцую, сам пою: организация тестирования в зависимости от масштаба

Небольшой проект требует одного подхода к организации тестирования, крупный – совсем другого. Чем больше проект, тем значительнее ресурсы для тестирования, а, значит, тем сложнее управление им. 

Получается своего рода подъем по лестнице менеджмента. На ней можно условно выделить 6 основных ступеней-уровней организации тестирования. Рассмотрим их по порядку.

Ступень 1. Тестировщик = разработчик

Когда проект совсем небольшой, то обычно разработчик сам и тестирует свое ПО. Действительно, в таких случаях компании смотрят очень скептически на необходимость нанять тестировщика на полную ставку. Поэтому разработчик выступает в роли «Сам танцую, сам пою, сам билеты продаю», хотя хотел бы только петь.

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

Более того, из-за запарки или по другим причинам разработчик может упустить из виду какую-либо важную проверку, и тогда релизная версия ПО уйдет к заказчику с критическими дефектами.

Ступень 2. Тестировщик = старший разработчик (менеджер проекта)

Если проект побольше, он требует команду разработчиков из 2-3 человек. Но в таких масштабах обычно найм отдельной единицы тестировщика все еще рассматривается как экономически нецелесообразный. Функции тестирования может взять на себя самый опытный из разработчиков (проверка качества кода) или менеджер проекта, если таковой выделен в проектной структуре.

Теперь уже есть кому «продавать билеты» (раздавать тикеты в Канбан) и «аккомпанировать» разработчикам. Однако, подойти к построению тестирования по всем принципам этой дисциплины получается далеко не всегда (аккомпанировать тоже надо уметь). Кроме того, организация тикетов и другие задачи могут отвлекать от проверок качества ПО. В результате процент выявленных дефектов вырастает, но риски критических багов в релизе все еще высокие.

Ступень 3. Тестировщик как полнофункциональная штатная единица

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

Такая организация работы значительно уменьшает количество багов, проявившихся у клиента. Эффективность каждого участника проекта может быть повышена за счет специализации на своей функции. Пожалуй, идеальный состав для «ансамбля одной песни».

Сложности могут возникнуть, если придется менять «репертуар». Тестировщик-профи, конечно, сможет подхватить любое изменение, но не сразу. Появляются «разрывы» между разработкой и тестированием – приходится тратить время на подготовку тест-кейсов после того, как программисты существенно изменили код.

Ступень 4. Команда тестировщиков с методологией

На проектах более серьезных масштабов тестировщиков может быть несколько. Кроме того, у них выделяется в отдельную функцию методология проведения проверок. Теперь эта команда заранее имеет «ноты», тем самым уменьшая время на подстройку под исполнение разработчиков, это уже не просто Testing, это уже Quality Control.

Ансамбль проекта играет намного более слаженно. Взаимодействие между разработчиками и тестировщиками прочное. Менеджер проекта только успевает раздавать тикеты на задачи.

Можно ли еще лучше организовать тестирование? Да, можно.

Ступень 5. Quality Assurance

Тестировщики участвуют во всех процессах проекта для улучшения качества. Они заранее обсуждают с разработчиками, как будет происходить «концерт», а с менеджерами – какие тикеты стоит выдавать в первую очередь. 

Если организовать Quality Assurance правильно, «Ансамбль» начнет выдавать высококачественный продукт, и от клиентов не будет отбоя. Непроизводительные потери ресурсов при тестировании снижаются, рентабельность проекта повышается.

А можно еще лучше? Да.

Ступень 6. QA-партнер

Тестировщики выходят за рамки обычной функции. Это уже отдельная QA-компания со специализированными сотрудниками (тест-дизайн, тест-аналитика, тест-автоматизация, тест-поддержка и т.п.). Они не только аккомпанируют, они взаимодействуют с клиентами – какую «аранжировку» проекта лучше сделать и какие модели разработки и тестирования стоит использовать. В такой концепции тестирование – не просто сервис, а партнер.

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

Резюме

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