Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

В прошлый раз мы с Фридой рассматривали визуализации времени, потраченного на различные задачи тестирования, включая работу над тест-покрытием продукта (Т-время), изучение багов и оформление баг-репортов (В-время), и работу по подготовке системы к тестированию и уборке за собой (S-время).

"То есть, - размышляла Фрида, - я могу отслеживать Т-время, В-время и S-время. Но меня немного беспокоит необходимость постоянно смотреть на часы вместо того, чтобы сосредотачиваться на тестировании. Это как самомикроменеджмент".

"Да, об этом стоит задуматься", - ответил я. "Мы уж точно не хотим превратиться в обсессивно-компульсивных, приклеенных к часам людей. Секрет вот в чем: в какой-то степени мы искажаем подсчет сессионного времени".

"Ну супер, - сказала Фрида, - я думала, что мы обсуждаем налаживание доверия".

"Все так. Но мы также обсуждаем, как отчитаться о том, что мы делаем, так, чтобы все могли понять, что происходит. И хоть нам и важна корректность, точность нас не настолько волнует. В сессионном тест-менеджменте мы стараемся отчитаться о своих усилиях, в то же самое время сделав это достаточно простым для понимания. Поэтому мы не глядим на часы все время. Разумной оценки того, сколько времени мы потратили на Т, В и S, вполне достаточно. Точность до ближайших пяти или десяти процентов сойдет. Мы не лжем, но мы упрощаем, сглаживаем детали, чтобы читатели не были подавлены цифрами, не помешались на них и не были ими обмануты. Помни, цель всего этого – не скрупулезные подсчеты. Это нужно, чтобы побудить нас задавать вопросы. В частности, устраивает ли нас то, как мы тратим время?"

"Вот пример", - продолжил я. "Как-то раз после утреннего стендапа я начал работать над чартером, покрывающим некоторую область продукта. Все шло гладко первые минут двадцать, а затем разработчик попросил помочь воспроизвести проблему, о которой сообщил кто-то другой. На это ушло 15 минут".

"Затем я вернулся к работе над чартером. В процессе были быстрые небольшие прерывания – телефонный звонок, сообщение – но в целом я быстро с ними управился и работал полтора часа. Я наткнулся на ряд багов и на проблемы с инструментом, записав это в S-время".

"Настало время обеда. Вернувшись, я продолжал работать над той же областью. Я работал над ней 25 минут, а затем отвлекся на разговор с менеджером разработки. Это заняло 20 минут. Я снова сел тестировать (45 минут), а потом пошел в столовую на день рождения Паолы, ел торт и болтал минут пятнадцать".

"Я вернулся, тестировал 40 минут, после чего другой тестировщик попросил меня посмотреть на созданный им план покрытия. Это заняло десять минут. Я вернулся к чартеру, поработал над ним 25 минут и закруглился".

"Теперь, если мы просуммируем это все, получится около пяти часов чистого времени, из которых час был потрачен на прерывания, а 245 минут – на тестирование. Если мы рассматриваем сессию как 90 минут – это почти три рабочих сессии".

"Поэтому, создавая отчет, я, возможно, сделаю два сессионных отчета – один для утренней работы, и один для послеобеденной. Я укажу, что работал в течение трех сессий. Я сделаю правдоподобное предположение о Т-времени, В-времени и S-времени для каждой сессии. Повторюсь, точности до 5-10% будет достаточно. При помощи TBS-чисел мы стараемся примерно определить, насколько часто прерывалось покрытие продукта. Если нас не устраивает примерное предположение, мы углубимся в детали".

"Но не расстроятся ли менеджеры, если мы сообщим неточные числа?" – спросила Фрида.

"Поверь мне", - сказал я со смехом, - "они не настолько пристально всматриваются. Они никогда так не делают. Они просто не могут стремиться так пристально всматриваться, это невозможно. У них нет времени на ежедневный подробный разбор каждой минуты работы каждого сотрудника. В этом нет смысла. К тому же наблюдение за каждым шагом будет подрывать социальную природу работы. Люди должны оставаться в какой-то степени безнадзорными, чтобы чувствовать, что им доверяют брать на себя ответственность за свой труд – и действительно ее брать".

"К тому же", - отметил я, - "если бы менеджеры действительно пристально вглядывались в процесс, они пришли бы в ужас от того, сколько времени тратится впустую на поддержку и пополнение тест-кейсов, и как мало времени уходит на реальное тестирование и совместную работу".

"Хе-хе", - сказала Фрида, "это правда".

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

"Но это же очень сильно варьирует?" – спросила Фрида. "В смысле, некоторые команды многое делают во время митингов. Вроде дизайн-митингов, груминга, митингов по планированию проекта… Надо ли это отслеживать?"

"Конечно", - сказал я, - "если хочется. Ключевой момент тут в том, что если все полностью довольны ситуацией, не надо пытаться измерять что-то специфическое. Но если кто-то недоволен, или у кого-то есть ощущение, что в проекте могут быть причины для недовольства – этому надо уделить внимание. К примеру, кто-то говорит, что тестирование занимает чересчур много времени…"

"Это я слышала не раз", - сказала Фрида.

"Ага. Чересчур много по сравнению с чем? Какая часть или части конкретно занимают слишком много времени? Собери данные. После сбора данных задай вопросы по ним. Проанализируй их. Может, тестировщики тратят много времени на исследование багов? Чем это взывано? Они пишут чересчур детализированные баг-репорты? Они исследуют баги дольше нужного? Это вызвано тем, что баги сложны в воспроизводстве и неочевидны? Или дело в том, что в продукте столько багов, что они занимают все время тестирования, не оставляя никакого шанса на тест-покрытие?"

"Каждая из этих причин влечет за собой различные действия менеджмента, и различные изменения поведения. Возможно, проблема вообще не в том, что тестирование занимает много времени, а в том, что на разработчиков чересчур давят. Они пишут код так быстро, что толком не вникают, что конкретно они строят, и у них нет времени проверять свою работу. Или, возможно, проблема в том, что тестировщики тратят кучу времени на создание баг-репортов, и вероятным решением может стать работа тестировщиков бок о бок с разработчиками. Тогда вместо ненужной бумажной работы они просто покажут ряд багов разработчикам напрямую".

"Суть основанного на действиях тест-менеджмента – это избежать превращения тестирования в производство артефактов, а тестировщиков –в машины по производству тест-кейсов".

"Что же делать, если кому-то нужны артефакты?" – спросила Фрида. – "Это основная причина, по которой менеджерам нужны тест-кейсы – чтобы они точно знали, что работа выполнена".

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

"Ну…" – ответила она, - "есть еще дебрифинг, о котором мы уже говорили. Но им же нужны доказательства. Ну, знаешь, что-то оформленное письменно".

"Как насчет заметок тестировщика".

"Хм" – Фрида запнулась. "Большинство тестировщиков не очень-то хорошо ведут заметки".

"Согласен", - сказал я. "Я тоже это видел, и это может стать серьезной проблемой. Люди, хорошо выполняющие исследовательскую работу – журналисты, лаборанты, детективы – нуждаются в хороших заметках. В том числе тестировщики. Я говорю тестировщикам, что совершенно нормально не вести хороших заметок… ну, если они хотят забывать о множестве важных вещей".

"Почему тестировщики плохо ведут заметки?" – спросила Фрида.

"Я полагаю, что мы наблюдаем петлю обратной связи", - ответил я. "Люди плохо выполняют исследовательскую деятельность, следуя формальным сценарным тест-кейсам – и заметок это тоже касается. А почему должно быть иначе? Они делают то, что шаги кейса им диктуют, и миссия превращается из "тестирования продукта" в "следование скрипту". Это делает тестирование механическим, скучным, отвлекает от задачи поиска проблем. Зачем вообще морочиться с заметками в этом случае? А затем, так как у людей отсутствует практика ведения заметок, их навык ухудшается. И когда у них появляется шанс поработать менее формализованным способом, они плохо ведут заметки. Они забывают важные детали того, что собирались сделать, и даже если вспомнят – у них может не быть доказательств".

"Один из способов научить людей вести хорошие заметки – это освободить их от создания и прогона тест-кейсов. Но в ответ они должны создавать доказательства того, о чем они думали и что они делали. Они могут показать мне эти материалы в дополнение к дебрифингу, и мы пройдемся по ним вместе. Аккуратные заметки, которые делаются каждые несколько минут, обычно приносят пользу. Я хочу видеть, какие тест-идеи их посещали, какие риски они рассматривали в ходе работы. Если они использовали специфические тестовые данные и исследовали специфические поведения, они могут показать мне списки, таблицы или ментальные карты. Если они писали код, чтобы помочь тестированию, они могут показать мне код и его результат. Их заметки не должны быть громоздкой канцелярщиной – я хочу видеть то, что поможет мне следовать за их мыслительным процессом и развивать доверие к ним".

"Некоторых менеджеров очень волнует эта самая целостность", - сказала Фрида.

"Логично", - ответил я. "Если бы я управлял проектом, где целостность очень важна – например, в контексте медицинских приборов или ПО – я все равно не стал бы заставлять людей следовать тест-кейсам. Если что-то нужно проверить, автоматизируйте это. Для высокой целостности мне понадобятся формальные отчеты о сессиях в качестве результатов работы, и я буду постоянно давать тестировщикам обратную связь. В сессионном тест-менеджменте, к примеру, есть концепция сессионного листа, сочетающего тест-заметки, данные о сессии, и отсылки к созданным в ходе сессии артефактам – результатам тестирования, сниппетам кода, или даже скриншотам/видео, если они могут пригодиться".

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

Больше о заметках и сессионных листах см.

Обсудить в форуме