Замена специалистов по тестированию на QA-инженеров в отделе тестирования

Тестирование программного обеспечения – проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. В более широком смысле тестирование – это одна из техник контроля качества, включающая в себя активности по планированию работ, проектированию тестов, выполнению тестирования и анализу полученных результатов [1].

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

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

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

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

В большинстве компаний бизнес-процесс разработки программного продукта выглядит так:

• 1)    менеджер проекта придумывает идею и составляет к ней требования;

• 2)    тестировщики, аналитики проводят анализ этих требований;

• 3)    разработчики начинают разработку функциональности, а тест-дизайнер начинает составлять план по тестированию;

• 4)    когда функциональность разработана, тестировщики проводят ее тестирование, используя план тест-дизайнера, и составляют документацию;

• 5)    после окончания тестирования, если не были обнаружены проблемы, функциональность отправляется в релизную сборку;

• 6)    далее проводится регрессионное тестирование релизной сборки, чтобы убедиться, что новая функциональность не сломала старые и приложение продолжает работать; в это же время специалист по автоматизированному тестированию пишет автотесты на данный функционал;

• 7)    если регрессионное тестирование не выявило проблем, релиз появляется в публичном доступе.

После всех этих действий процесс повторяется снова.

В этом бизнес-процессе используется достаточно большое количество ресурсов: менеджер проекта, аналитик, разработчики, тест-дизайнер, тестировщик, специалист по автоматизации тестирования.

Количество участников можно сократить путем замены тестировщиков на полноценных QA-инженеров, которые не просто проводят тестирование, а именно обеспечивают качество продукта.

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

QA-инженер будет совмещать в себе сразу несколько специализаций: аналитик, тест-менеджер, тест-дизайнер, специалист по тестированию, специалист по

ВЕСТНИК РОСНОУ. Серия «Сложные системы…»

автоматизированному тестированию в рамках одного или нескольких модулей, а не всего проекта.

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

Таким образом, бизнес-процесс разработки ПО будет выглядеть так:

• 1)    менеджер проекта придумывает идею и составляет к ней требования;

• 2)    QA-инженер совместно с менеджером проекта проводит тестирование требований, параллельно составляя план по тестированию;

• 3)    разработчики начинают разработку функциональности, а QA-инженер дорабатывает план по тестированию или занимается другими делами, например написанием (поддержкой) автотестов для других функциональностей или составлением (актуализацией) документации;

• 4)    когда функциональность разработана, QA-инженер проводит ее тестирование, используя собственный тест-план, и составляет документацию;

• 5)    после окончания тестирования, если не были обнаружены проблемы, функциональность отправляется в релизную сборку;

• 6)    далее проводится регрессионное тестирование релизной сборки, чтобы убедиться, что новая функциональность не сломала старые и приложение продолжает работать;

• 7)    составляются автотесты на данный функционал;

• 8)    если регрессионное тестирование не выявило проблем, релиз появляется в публичном доступе.

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

Также одним из преимуществ можно выделить возможность применения этой модели компаниями любых размеров: от стартапа до гиганта отрасли, поскольку сама модель очень простая, гибкая и в ней может быть задействовано мало сотрудников, в том числе один даже для среднего проекта, где понадобилось бы 3–4 тестировщика.

Основным недостатком является высококвалифицированный и разносторонний персонал, которого крайне трудно найти и непросто и долго подготовить, и не менее важна стоимость этого персонала. Еще есть высокая вероятность, что специалист может «перегореть» из-за очень высокой скорости работы, ответственности и разносторонности компетенций данного специалиста. (Однако подобная проблема решается путем смены проекта, оптимальным вариантом может быть смена один раз в 6–12 месяцев.)

В связи с этим данная концепция не подойдет для команд, которые любят «выращивать» специалистов, принимая на работу сотрудников после курсов по тестированию. Чтобы работать без потери эффективности, нужно нанимать сотрудников со стажем от 1,5–2 лет при условии, чтобы за это время они развивались в разных направлениях и овладевали техниками тест-дизайна.

Заключение

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

Рис. 1. Классическая модель отдела тестирования

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

Рис. 2. Модель с использованием QA-инженеров вместо специалистов по тестированию

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

ВЕСТНИК РОСНОУ. Серия «Сложные системы…»

Как видно из этой модели, несмотря на высокую рыночную стоимость QA-инженера, данный подход выгоднее для компаний, поскольку для обеспечения высокого качества продукта на проект можно нанять 1–2 инженеров, а не 4–6.

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