Что менеджер проектов должен знать о тестировании

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

Если задать среднестатистическому РМ’у простой вопрос: «Зачем на этом проекте тестирование?», то чаще всего ответом будет «Ты же тест-менеджер, ты и должна ответить на этот вопрос».

Но ведь, приходя в парикмахерскую, вы не говорите мастеру «вы сами знаете, что мне нужно»? И в продуктовом магазине вы не просите продавца накидать вам в корзину то, что вам нужно? Вы можете советоваться, вы можете узнавать «а как можно?», спрашивать варианты, но решение всегда за вами. В чём отличие тестирования? Может, в том, что слишком мало менеджеров проектов понимают, зачем оно им?

В этой статье я постараюсь выступить в роли продавца, который показывает клиенту: «а что вообще бывает?» Многие вещи будут описаны, возможно, слишком подробно, слишком просто… Не серчайте, мне просто очень хочется быть понятой.

Зачем вообще формулировать какие-то ожидания от тестирования?

Камон! Тестирование — это всякие там нажимания на кнопки, хорошо, если автоматизированные. И так понятно, какие цели! Нужно находить баги, и чем больше, тем лучше. Какие ещё могут быть цели у тестирования?

Упс… Если исходить из этого подхода, то во всех компаниях с тестированием всё в порядке. Баги находятся, фиксятся, проверяются… И что, тестирование всегда полезно? Всегда раскрывает весь свой потенциал?

Что-то мне подсказывает, что нет. Тогда в чём отличия между теми редкими случаями, когда «с тестированием всё отлично», и преобладающим большинством?

Попробую привести ещё одну иллюстрацию. Вы никогда в жизни не ходили на массаж. Вы заходите в салон (а что, все ходят, почему бы и вам не сходить?) и заказываете получасовой сеанс. У вас есть фиксированный бюджет и есть требования: «помассируйте меня». Невнятного вида дама невнятно возится с вашими вполне внятными плечами, кайфа никакого, вы выходите из салона и думаете «эх, массаж — фигня полная». Но ведь ваше требование «помассируйте меня» было выполнено! Может быть, дело в некорректности требования? У вас болела спина, и вы хотели, чтобы боль прошла? Или не хватало растяжки? Или хотелось релакса? Чем точнее требования, тем больше у исполнителя шансов их удовлетворить. Но если вы не можете сформулировать, что хотите, то и исполнитель не сможет сделать то, что нужно, и вы не сможете объективно оценить результат.

Какими могут быть ожидания от тестирования?

Тестирование нужно для того, чтобы повышать качество продукта. Ну это же очевидно!

Упс… Простой пример из практики. Команда тестирования своевременно находит дефекты, команда разработки не располагает временем их исправить, продукт неизменным выходит на рынок, клиенты говорят «отстой»… Что, тестирование было плохим?

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

В общем, примеров можно привести много. Но вывод почти всегда один: тестирование на качество никак не влияет. Также, как ваша стрижка не влияет на вашу успешность. «Эй, парикмахер, постригите меня так, чтобы я сдал экзамен!». Никакой логики, правда? В тестировании — то же самое. Тестирование предоставляет информацию в определённый бюджет, в определённом формате, с определённой скоростью… Но тестирование никак не влияет на качество, даже если очень хочет.

Что же тогда может предоставить тестирование?

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

Давайте сначала рассмотрим эти пункты, а потом перейдём к самим формулам.

1. Тестовое покрытие

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

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

Покрытие можно и нужно измерять: traceability matrix, code coverage, процент пропущенных дефектов и масса других метрик вам в помощь.

2. Предоставляемая информация

Годами живёт мем о тестировщике, с паникой в глазах говорящем «ничего не работает!». А если попросить объяснить подробнее, он отвечает: «ну, совсем ничего!». Возможно, он обеспечил хорошее тестовое покрытие, но, увы, адекватную информацию не предоставил. Какая же информация может быть нужна проекту от тестирования?

  • Качественно описанные баги в баг-трекере
  • Статистическая информация о продукте для прогнозирования релизов и принятия решений по процессам
  • Метрики качества для принятия решений о релизах
  • Оценка самого тестирования: какое покрытие, что проверено, насколько достаточно тестирование и т.д.

Если группа тестирования не предоставляет внятной информации о продукте и проекте (а это её основная функция!), то принимать решения очень сложно.

3. Скорость тестирования

ОК, покрытие хорошее, информация чёткая… Только поздно. Или долго. Или долго, и поэтому поздно.

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

Мало кто берётся анализировать проекты по ТОС, и мало кто замечает, что тестирование иногда удлиняет релизы в несколько раз. Вот замените тестирование на своевременное, и получите релиз в два раза быстрее.

Обычно это незаметно, и кажется, что баги — источник всех бед… А ведь иногда найти их раньше = сократить затраты на весь цикл разработки!

Или другой аспект скорости тестирования: время, требуемое для проверки сборки. К примеру, готовимся к релизу. Получаем RC (релиз кандидат). Тестированию нужна неделя, чтобы убедиться в его работоспособности, РМ соглашается, выделяет неделю, на пятый день находится критичный баг… 10 минут на фикс, и снова 5 дней, и снова на пятый находится критичный баг… Сталкивались? Звучит знакомо?

4. Бюджет

Пожалуй, это самый простой пункт из всех. Естественно, он относителен. 1000 рублей — это много или мало? Для батона хлеба, пожалуй, много, для поездки на Бали, пожалуй, мало. Поэтому бюджет — это те деньги, которые вы готовы платить, но не за «тестирование», а за конкретные и понятные результаты этого самого тестирования.

Ну, и что дальше?

А дальше вот что. Чтобы принести проекту максимум пользы, вы должны точно знать, что ему сейчас нужно. Чтобы знать, что нужно, вам необходимо анализировать его показатели, что именно за пределами нормы: сроки, качество или бюджет. И уже после этого создавать вашу уникальную формулу с требованиями к тестированию. При этом будем честны: «сократить сроки» или «увеличить покрытие» — это всё те же «помассируйте меня».

Нужны точные показатели. Зачем? Чтобы оценивать изменения. Чтобы следить, правда ли они влияют на показатели всего проекта в целом (будем честны, покрытие само по себе вам не нужно!). Чтобы контролировать процесс.

Заметьте, я нигде не говорила «юнит-тесты», «автоматизация», «тест-дизайн» и т.д. Все действия вносятся в процесс только по результатам определённых целей! Нужно повысить скорость тестирования сборки? Внедряем автоматизацию. Нужно повысить скорость нахождения дефектов? Модульные тесты. Качество отчётности? Модерацию дефектов. В тестировании сотни подходов, инструментов, решений, которые можно комбинировать исходя из ваших целей. Но сами по себе инструменты вторичны.

Поэтому, как тестировщик/тест-менеджер/тест-аутсорсер будет достигать ваши цели — это его головная боль. Но никто лучше внимательного к своему проекту РМ’а не скажет, что этому проекту нужно.

Об авторе

Занимается тестированием с 2004 года. За это время была тестировщиком операционных систем и систем документооборота, тест-менеджером интернациональных команд и выпускающим специалистом на государственных разработках. С 2009 года развивает направление заказного тестирования в «Лаборатории Качества» и выступает в роли консультанта по построению процессов тестирования. Её курсы по тестированию и тест-менеджменту прошли более 3000 специалистов.

Поиск
Облако меток
8 марта (1)api (5)ISTQB FL (1)IT (1)kpi (1)kpi в тестировании (1)postman (1)Quality lab. Meetup (2)regress тестирование (1)rest api (2)scrum (1)scrumban (1)smoke тестирование (1)soap api (1)sqa days (1)TDD (2)UX-экспертиза (1)won't fix (1)А/Б тестирование (1)День дарения книг (1)День защитника Отечества (1)День рождения ЛК (1)День смеха (1)Мероприятия (2)ПОИНТ (3)Приёмочное тестирование (1)РИТ (1)Эльбрус (1)Юмор (2)автоматизация тестирования (7)аудит (2)аудит тестирования (2)аутсорс (5)баги (4)банковские приложения (1)бесплатный вебинар (1)вакансии (5)варианты использования (1)веб-приложения (1)веб-тестирование (2)верстка (1)галеры_qualitylab (1)граничные значения (1)дедлайн (2)диаграмма Исикавы (1)дополнительные материалы (3)ежемесячный отчет (14)интернет-магазин (1)исследовательское тестирование (2)коммуникации (4)конфликты (2)кроссбраузерное тестирование (1)курсы для тестировщиков (2)лаборатория качества (22)лайф-хаки (4)локализация (1)медицинское ПО (1)международные проекты (1)метрики (3)модель ситуационного лидерства (1)мотивация (3)новый год (3)обеспечение качества (13)обучение (8)онлайн-конференция (1)оптимизация тестирования (12)оффлайн тренинги (1)поздравление (2)поздравления (6)пользовательские истории (1)пример (2)проблемы (3)проектные риски (1)проекты (4)процесс тестирования (24)развитие команды (6)разработчики (1)распределенная команда (3)решения (4)ритейл-приложения (1)сертификация ISTQB FL (1)собеседование (1)специализация (2)с чего начать (2)тест-анализ (2)тестирование (49)тестирование безопасности (3)тестирование для бизнеса (2)тестирование мобильных приложений (2)тестирование серого ящика (1)тестирование требований (1)тестирование черного ящика (1)тестировщики (10)тестовая документация (1)тестовое покрытие (1)тесты (1)техники тест-дизайна (1)требования (1)удаленная работа (1)удобство использования (2)управление проектами (3)управление рисками (1)успехи (6)целевая аудитория (3)юзабилити (3)
Получите совет