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

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

"Весь основной функционал должен работать"

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

Решение: обычно поможет анализ изменений вместе с разработчиками. Я использую методы "белого ящика" и построение тестов на основе результатов совместно с существующими тест-кейсами. Можно применить принцип Парето, согласно которому 20% приложения используется в 80% случаев.

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

"Возьмите легаси код и напишите новый"

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

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

"Работает только локально"

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

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

"Подготовьте новую команду через месяц"

Проблема: хотя у вас нет опытных тестировщиков, руководство требует, чтобы вы быстро собрали команду тестировщиков для нового проекта, и они хотят, чтобы все были знакомы с продуктов (без обучения).

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

"Тестовая окружение должно быть идеально"

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

Решение: я нашел смысл в том, чтобы тщательно сопоставить оба окружения и проанализировать риски, связанные с каждым различием. Я представил своим командам концепцию "правила Сегеди", придуманного мной: если между двумя окружения существует N различий, то среди результатов тестирования будет 2n проблем. Это означает, что вы должны выделить огромное количество времени для отладки, даже если большинство отличий является ложной тревогой.

"Нет необходимости в инструменте управления тестированием"

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

В отчете 2017-2018 ISTQB тестовые метрики и тестовые усилия оказались важны только для 23,5% опрошенных компаний, но 62,5% из них использует какой-то инструмент управления тестами. В моем опыте не требовались отчеты по тестированию кроме данных о блокирующих багах. И я должен был сделать их вручную, так как мы не использовали какой-либо профессиональный инструмент управления тестированием.

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

"У меня не было времени прочитать отчет о тестировании"

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

Решение: предположим, заинтересованные стороны не читают ваши отчеты, тогда готовьтесь ко встречам с заметками, где выделены наиболее важные вопросы и показатели

"Эти требования слишком сложные"

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

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

"Просто автоматизируй все тесты"

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

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