Home

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

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

Мы с моей клиенткой Фридой обсуждали, как управлять тестированием, не завися от формализованных, скриптованных, процедурных тест-кейсов. Часть любого подхода к отчетности о работе – это коммуникация между менеджером или тест-лидом и исполнителем. В сессионном тест-менеджменте часть этой коммуникации – это разговор, который мы называем дебрифингом, и об этом мы говорили в прошлый раз.

Один из важных элементов дебрифинга – это отчетность о потраченном на работу времени, и поэтому один из самых важных вопросов – это "На что вы потратили время в ходе этой сессии?"

"Эммм… ну, на тестирование, предположительно, разве нет?" – спросила Фрида.

"Ну, - ответил я, - есть тестирование, и есть прочая работа, выполняемая в ходе сессии. И практически неминуемо существуют какие-либо прерывания".

"Конечно, - согласилась Фрида. – Меня прерывают ежедневно, постоянно: сообщения в мессенджерах, звонки, просьбы о помощи от других тестировщиков, заявления разработчиков, что на их машине все работает…"

"Прерывания, конечно, всем знакомы, - сказал я. – Давайте поговорим о них. Для начала подумаем, что бы вы делали в ходе тест-сессии без прерываний. Или если бы мы не вспомнили о них сейчас. Что бы вы делали?"

"Тестировала бы. Выполняла бы тесты. Искала бы баги", - ответила Фрида.

"Ну да. Можно раскрыть вопрос детальнее?"

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

"Каждый кусочек тестирования, - повторил я. – Хорошо, представим, что у вас есть 90-минутная тестовая сессия, в ходе которой вас не будут прерывать. Заприте дверь офиса…"

"…которой у меня нет", - сказала Фрида.

"Естественно. Вы из мира опенспейсов. Но представим, что вы повесили знак "Не беспокоить! Тестирование в процессе!". Переключите звонки на голосовую почту, выключите Слак, Скайп и iMessage, и что у вас там еще. В ходе этой сессии, предположим, вы можете выполнить набор двухминутных тестов, и каждый из них поможет вам узнать что-то о продукте".

"Но тестирование так не работает! Это звучит, как… как тест-кейсы!" – сказала Фрида.

"Я знаю, - ухмыльнулся я. – Вы правы, я согласен. Но давайте пока что придержим это возражение и проработаем этот момент. Представьте, что эта 90-минутная сессия смоделирована как таблица 9 на 5 с 45 мини-импульсами тестирования. Менеджер того типа, который вы изображаете, думает, что произойдет следующее".

Фрида хихикнула. "Издание "Фантазия менеджера". Да уж, все так".

"Конечно, - сказал я. – Но почему?"

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

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

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

"Хорошее ли это занятие?"

"Ну… да, - ответила Фрида. – Очевидно, что исследование багов – большая часть моей работы".

"Верно. И она занимает время. Сколько именно?"

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

"То есть довольно много времени", - сказал я.

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

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

Фрида нахмурилась. "Или, говоря иными словами, исследование багов снижает тестовое покрытие".

"Да. И когда это происходит, важно, чтобы менеджер об этом знал. Как менеджер, я не хочу обманываться в тестовом покрытии – то есть в том, сколько продукта мы исследовали согласно определенной модели".

"Вы начинаете сессию с чартером, нацеленным на покрытие чего-то, о чем мы хотим знать. Одно дело, если в ходе 90-минутной сессии тестировщик тратит 80 минут на покрытие определенной области продукта тестированием, и только десять – на исследование багов. Совершенно другое дело – если тестировщик тратит 80 минут на исследование багов, и только десять – на тесты, дающие новое покрытие. Если вы тратите на чартер только десять процентов времени, а остальное – на исследование найденных багов, я надеюсь, что вы не сообщите в отчете, что выполнили чартер".

"Погодите-ка… а что, если это меня тревожит? – спросила Фрида. – Не буду ли я плохо выглядеть, не достигнув цели сессии?"

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

Фрида выглядела взволнованной. "Не каждый менеджер, с которым я работала, понял бы это. Они бы просто сказали "Закончи тест-кейсы", и этим дело бы и кончилось".

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

"То есть в этой ситуации мне понадобится еще несколько сессий для получения покрытия, которое мы надеялись получить в ходе первой", - сказала Фрида.

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

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

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

"Или читала о продукте? Или разговаривала о нем с кем-то?" – спросила Фрида.

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

"Или даже так".

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

"Угу. Подобная визуализация производит впечатление, не так ли? Проблема в том, что немногие тестировщики помогают менеджеру это понять. Как вы сказали, если вы стремитесь к покрытию, на которое надеялся менеджер в "Фантастическом издании", такая схема поможет показать, что вам понадобится примерно четыре сессии, а не одна. К тому же найденные в ходе этой единственной сессии баги – по определению самые поверхностные, самые очевидные. Спрятанные, редкие, неочевидные, плавающие, внезапно возникающие баги сидят глубже".

У Фриды все еще оставались вопросы, и их мы разберем в следующий раз.

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