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