Должен ли менеджер IT проекта тестировать его самостоятельно или можно передать тестировщикам?

4 главных функции менеджмента: планирование, организация, мотивация и контроль. Переводя эти функции в плоскость IT, можно сказать, что тестирование продукта — это часть задач по контролю, которые должен выполнять управленец. На деле, часто менеджеры IT проектов просто передают проверку продукта тестировщику, считая, что задача по контролю выполнена.

Но тут возникает резонный вопрос, знает ли действительно тестировщик, как должен работать продукт? Он присутствовал на встрече с заказчиком? Слышал содержание диалога и реальные пожелания клиента? Нет, он основывается только на том функциональном задании, которое было составлено менеджером и утверждено заказчиком. Он проверяет только те сценарии, которые описаны в проектной документации.

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

К сожалению, многие менеджеры пытаются управлять разработкой безконтекстно. Контроль ограничивается фразой «Ты сделал?» и ответом «Да, сделал!» от исполнителя. А что сделал, как сделал, работает ли это? Менеджера в таком случае устраивает сам факт выполнения в срок.

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

Более того, IT разработка — это командная игра. Если один из сотрудников свои задачи выполнил неправильно, это ставит под угрозу работу всей команды. Отхождение от цели может быть настолько сильным, что действия остальных сотрудников могут быть обесценены, а это много потерянного времени, которое в IT стоит очень дорого (в прямом смысле слова). Это не говоря о потерянной репутации и потенциальных штрафных санкций перед заказчиком, которые может понести компания из-за задержки сроков сдачи проекта.

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

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

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

Как уже было сказано выше, менеджеру необязательно делать монотонное механическое тестирование по 100-200 операций. Ему нужно проверять правильность работы основных сценариев. Причем такая проверка должна быть глубокой, и проводиться периодически (не только при сдаче продукта).

Я рекомендую при работе со сложными проектами и сложным функционалом прописать все основные сценарии использования. А также, как именно они будут тестироваться. Думать о том, как функционал проверить, достигнут результат или нет, нужно еще на этапе проектной документации. Это называется сценарием тестирования.

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

При работе с тестировщиками нужно придерживаться тех же принципов, что и при работе с другими специалистами.

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

Должен ли менеджер проекта самостоятельно тестировать продукт? Да, обязательно. Работа тестировщика заключается в поиске багов при разных условиях использования, в том числе нестандартных (нагрузочное тестирование или проверка максимальных/некорректных значений в формах). Но основной функционал, особенно тот, который зафиксирован в проектной документации, руководитель должен проверять самостоятельно.

Источник — Курс «Как стать классным менеджером проектов и не ох..еть»

Ссылка на курс для жителей России