Как обычно строят процесс тестирования непросветлённые тест-менеджеры?
Они стараются протестировать всё. Они тщетно пытаются протестировать всё. В результате в баг-трекере есть ошибка о том, что программа крашится при нажатии на самую редкоиспользуемую кнопочку 286 раз. Ошибка про странный серый пиксель в нижнем правом углу программы тоже заведена. Команда трудилась в поте лица по ночам и выходным.
Релиз.
Не работает основной функционал.
Почему такое возможно?
1. Заведение всех подряд ошибок мешает разработке. Разработчики тратят своё время на исправление минорных ошибок и вносят новые, зачастую более серьёзные.
2. Потраченное на мелочи время не дало возможности проверить более серьёзные пользовательские сценарии и найти более критичные дефекты.
3. Обратная связь по статусу сборки предоставлялась разработчикам с запозданием: вместо критичных дефектов непрерывно сыпались миноры.
4. Проектный паттерн «дохлая рыба» сыграл своё дело: все участники команды прекрасно понимали, что протестировать всё нельзя, и это не могло не сказаться на качестве работы. А реалистичных целей им никто не поставил…
Что просветлённые тест-менеджеры делают по-другому?
Что они поменяют в первую очередь?
Приоритеты!
Эта простая идея помогает сэкономить на крупных проектах значительно больше, чем 25.000$!
1. Всегда документируйте приоритет функционала, и согласовывайте его с сейлзами и аналитиками. Не надо кучу времени тратить на фичи, которые никто не использует.
2. Всегда приоритезируйте тесты. Приоритет теста определяется как важностью фичи, так и вероятностью возникновения ошибки (которая определяется эмпирически, по результатам общения с разработчиками, исходя из изменений в функционале и т.д.)
3. Акцент на слове «документируйте»!.. Если послезавтра релиз, и все в запарке, то об устных договорённостях никто не вспомнит, и начнётся скоростное нажимание на кнопочки. Вам правда нужно найти ещё 10 миноров? Или Вам важнее проверить работоспособность основного функционала?
4. Никогда не давайте сотрудникам объёмные задачи, которые могут не уложиться в сроки. Режьте их на кусочки, приоритезируйте и определяйте последовательсность. В противном случае Вы рискуете опять же столкнуться с хаосом и паттерном «дохлая рыба», переложив ответственность на сотрудников.
5. Создайте набор приёмочных тестов. Что должно работать при релизе, что ОБЯЗАТЕЛЬНО должно работать, а что — только желательно? Таким образом Вы всегда сможете оценить трудозатраты на тестирование релизной сборки — а не время на бесцельное прокликивание интерфейса.
6. Имея приоритезированные проверки, Вы всегда можете рассчитывать на продуктивный диалог с руководством о расширении штата сотрудников. Вместо слов «Нам не хватает сотрудников» Вы сможете сказать «Нам не хватает Х человекочасов для проверки тестов с приоритетом У». Руководство очень редко слышит такие внятные высказывания, поэтому Ваши шансы вырастут в разы ;-)
Результат работы не определяется затраченным на неё временем. Более того, трудозатраты и результат вообще никак не связаны, особенно в тестировании.
Работайте над результатом, а не над повышением объёма работ. И приоритезация тестов — самый первый и самый главный шаг в этом направлении.
Они стараются протестировать всё. Они тщетно пытаются протестировать всё. В результате в баг-трекере есть ошибка о том, что программа крашится при нажатии на самую редкоиспользуемую кнопочку 286 раз. Ошибка про странный серый пиксель в нижнем правом углу программы тоже заведена. Команда трудилась в поте лица по ночам и выходным.
Релиз.
Не работает основной функционал.
Почему такое возможно?
1. Заведение всех подряд ошибок мешает разработке. Разработчики тратят своё время на исправление минорных ошибок и вносят новые, зачастую более серьёзные.
2. Потраченное на мелочи время не дало возможности проверить более серьёзные пользовательские сценарии и найти более критичные дефекты.
3. Обратная связь по статусу сборки предоставлялась разработчикам с запозданием: вместо критичных дефектов непрерывно сыпались миноры.
4. Проектный паттерн «дохлая рыба» сыграл своё дело: все участники команды прекрасно понимали, что протестировать всё нельзя, и это не могло не сказаться на качестве работы. А реалистичных целей им никто не поставил…
Что просветлённые тест-менеджеры делают по-другому?
Что они поменяют в первую очередь?
Приоритеты!
В самом начале XX столетия Чарльз Шваб, президент компании «Bethlehem Steel», встретился с консультантом в области общественных отношений и управления Ивом Ли, так как хотел улучшить продуктивность своей компании. «Мы знаем, что нам следовало бы сделать, — объяснил Шваб, — но если вы можете показать нам лучший способ достижения этого, то я вас с удовольствием выслушаю и заплачу любую сумму в пределах разумного».
Ли сказал, что может помочь и что это займет всего 20 минут. Он протянул Швабу чистый лист бумаги и сказал: «Напишите шесть самых важных дел, которые вы должны сделать завтра». Шваб сделал, как ему было сказано.
«Теперь пронумеруйте их в соответствии с их важностью для вас и для компании». Когда Шваб закончил, Ли продолжил: «А теперь положите эту бумагу в карман, и первое, что вы должны сделать завтра утром, это вытащить этот лист бумаги и посмотреть на пункт номер 1. Не смотрите на другие пункты — только на первый, и начинайте работать согласно ему и до тех пор, пока он не будет полностью выполнен. Затем приступайте таким же образом к пункту 2, потом к пункту 3 и т. д., пока ваш рабочий день не подойдет к концу. Не беспокойтесь, если успеете справиться только с одним или двумя пунктами. Зато вы будете работать над самыми важными. Без них вы все равно не выполнили бы остальные. А не имея четко составленной системы, вы, вероятно, потратили бы в десять раз больше времени на их завершение — и, возможно, выполняли бы их не в порядке важности.
Делайте так каждый рабочий день, — сказал Ли. — После того как вы убедитесь в ценности этой системы, посоветуйте и вашим служащим попробовать делать то же самое. Испытывайте этот метод столько времени, сколько захотите, а потом пришлите мне чек на такую сумму, которую, по вашему мнению, заслуживает эта идея».
Через несколько недель Шваб прислал Ли чек на 25.000 долларов вместе с письмом, где говорилось, что это самый полезный урок, который он когда-либо получал. И очень скоро после этого компания «Bethlehem Steel» стала самым крупным независимым производителем стали своего времени.
Эта простая идея помогает сэкономить на крупных проектах значительно больше, чем 25.000$!
1. Всегда документируйте приоритет функционала, и согласовывайте его с сейлзами и аналитиками. Не надо кучу времени тратить на фичи, которые никто не использует.
2. Всегда приоритезируйте тесты. Приоритет теста определяется как важностью фичи, так и вероятностью возникновения ошибки (которая определяется эмпирически, по результатам общения с разработчиками, исходя из изменений в функционале и т.д.)
3. Акцент на слове «документируйте»!.. Если послезавтра релиз, и все в запарке, то об устных договорённостях никто не вспомнит, и начнётся скоростное нажимание на кнопочки. Вам правда нужно найти ещё 10 миноров? Или Вам важнее проверить работоспособность основного функционала?
4. Никогда не давайте сотрудникам объёмные задачи, которые могут не уложиться в сроки. Режьте их на кусочки, приоритезируйте и определяйте последовательсность. В противном случае Вы рискуете опять же столкнуться с хаосом и паттерном «дохлая рыба», переложив ответственность на сотрудников.
5. Создайте набор приёмочных тестов. Что должно работать при релизе, что ОБЯЗАТЕЛЬНО должно работать, а что — только желательно? Таким образом Вы всегда сможете оценить трудозатраты на тестирование релизной сборки — а не время на бесцельное прокликивание интерфейса.
6. Имея приоритезированные проверки, Вы всегда можете рассчитывать на продуктивный диалог с руководством о расширении штата сотрудников. Вместо слов «Нам не хватает сотрудников» Вы сможете сказать «Нам не хватает Х человекочасов для проверки тестов с приоритетом У». Руководство очень редко слышит такие внятные высказывания, поэтому Ваши шансы вырастут в разы ;-)
Результат работы не определяется затраченным на неё временем. Более того, трудозатраты и результат вообще никак не связаны, особенно в тестировании.
Работайте над результатом, а не над повышением объёма работ. И приоритезация тестов — самый первый и самый главный шаг в этом направлении.
