Я предлагаю читателю составить мне компанию и посмотреть, чем в течение дня занимается тест-аналитик (в мои обязанности входит работа не только тестировщиком, но и тест-аналитиком). Итак, добро пожаловать в мир аналитики!
Как выглядит мой обычный день в роли тест-аналитика
Утром мне на почту приходит письмо от заказчика с данными для получения дистрибутива продукта и формальными требованиями к нему. Плохие новости – технического задания как такового у нас нет. Хорошие новости – представитель заказчика оказался открытым к общению молодым человеком.
- исследовать продукт;
- составить логическую карту продукта;
- разбить программный продукт на составные части;
- расставить приоритеты тестирования.
Исследование программного продукта
Итак, заварив чашечку ароматного кофе, приступаю к исследованию продукта. Изучаю всю имеющуюся в моем распоряжении документацию, стараясь понять, каким хочет видеть продукт заказчик. Именно на этом этапе мною активнее всего привлекается к обсуждению представитель заказчика: в условиях отсутствия четкого ТЗ только он может рассказать, что именно должен делать продукт.
Прежде всего, мне необходимо понять цель создания этого продукта. Какими способами она должна достигаться? Какие основные и вспомогательные возможности предоставляет продукт пользователям? Только после этого я выполняю установку дистрибутива и стараюсь оценить, понял ли заказчика разработчик.
Логическая карта
Сформировав предварительное представление о продукте, составляю логическую карту (интеллект-карту).
Подобный подход позволяет достигнуть одновременно нескольких целей.
Во-первых, цельный взгляд на весь проект дает возможность отследить логические связи внутри продукта и выявить так называемые «бутылочные горлышки».
Во-вторых, при детализации карты достигается разделение функций до наименьших, атомарных составляющих (собственно, выполняется декомпозиция продукта), представленное в графическом виде.
На карте отображаются функциональные модули продукта, которые потом разделяются на мельчайшие части (вплоть до отдельных форм, полей, чек-боксов и т. д.). По возможности карта должна целиком помещаться в поле зрения. В центре располагается центральный блок (система). От центрального блока по часовой стрелке рисуются ветви (начиная с правой стороны). От ветвей первого уровня идет деление на более глубокие уровни. Рекомендуется использовать от 5 до 7 ветвей на уровне.
Все они отличаются удобством использования, набором параметров и ценой (есть и бесплатные варианты). Самым простым инструментом служит лист ватмана и фломастер, но карту в электронном виде все-таки удобнее корректировать и дополнять. Более подробно тема интеллект-карт раскрыта здесь. Замечу, что во время процесса построения карты крайне желательно получать обратную связь от заказчика.
Декомпозиция
Процесс построения карты неразрывно связан с выполнением декомпозиции продукта. Как уже указывалось выше, по мере исследования продукта и построения его карты выполняется разделение функционала до наименьших частей. Чаще всего, при декомпозиции я пользуюсь следующими правилами:
Исходная система располагается на нулевом уровне. После ее расчленения получаются подсистемы первого уровня. Расчленение этих подсистем или некоторых из них приводит к появлению подсистем второго уровня и т. д.
2. Система расчленяется только по одному, постоянному для всех уровней признаку.
В тестировании программного обеспечения указанного деления добиться крайне сложно, поэтому данное правило можно несколько видоизменить: все объекты одного уровня, являющиеся подсистемами одной и той же системы, должны разделяться по одному признаку. Другими словами, они должны отвечать на один и тот же вопрос относительно своего родителя. Например, для интернет-магазина это могут быть каталоги товаров, товары, информационные блоки самого товара (характеристики, отзывы, фото и т. д.).
3. Вычленяемые подсистемы должны взаимно исключать друг друга, а в сумме – полностью характеризовать систему.
Напрашивается аналогия с пазлом: если сложить подсистемы вместе, должна получиться сама система. Целостность и качество этой системы можно гарантировать только с учетом взаимодействия подсистем. При возникновении сложностей с однозначной адресацией некоторых подсистем к той или иной группе допускается создание для них отдельной группы (подсистемы) «Другие».
Глубина декомпозиции
Глубина декомпозиции (количество уровней) определяется удобством восприятия получаемой иерархической структуры конкретным специалистом. Для специалиста, хорошо знающего систему, декомпозиция может быть неглубокой и менее детализированной. Если же результат декомпозиции предназначен для специалиста, ранее не работавшего с системой, то декомпозировать следует более детально и глубоко.
Как можно видеть на иллюстрации выше, для некоторых модулей достаточно деления до второго уровня (так называемая «Пакетная установка»), а для других – до четвертого (так называемая «Расширенная установка»). Случается, что для некоторых модулей хватает и одного уровня. В нашем примере мы согласуем с заказчиком выделение нескольких функциональных блоков, имеющих наибольшую важность для продукта; все они разделены до элементарных частей. «Второстепенные» блоки мы рассматриваем на уровне крупных модулей. Таким образом оказывается затронутым и вопрос приоритезации продукта.
Приоритезация
Глядя на полученный (пусть и небольшой) проект, я понимаю, что даже при всем своем желании протестировать абсолютно все в указанные сроки мы физически не успеем. Что делать в такой ситуации? Я могу предложить заказчику несколько вариантов: например, мы можем увеличить сроки на тестирование или расширить команду. Но даже такие меры не могут гарантировать, что нами будет проверен абсолютно весь функционал.
В качестве альтернативного варианта мы можем выбрать наиболее приоритетные направления и уделить им самое пристальное внимание; при этом остальной функционал будет покрыт лишь смоук-тестами. Выслушав мои доводы, заказчик соглашается на приоритезацию.
В общем случае выполнять приоритезацию можно по следующим критериям:
1. Требования клиента.
Требования клиента очень важны и связаны с продвижением продукта и торговой деятельностью.
2. Степень риска.
Функционал, отказ которого принесет наибольшие потери, необходимо тестировать в первую очередь и наиболее тщательно.
3. Сложность системы.
В первую очередь следует протестировать наиболее сложные свойства. Это поможет избежать перерасходов бюджета и времени.
4. Временные ограничения.
Очень важно протестировать все необходимые свойства до выхода релиза. Можно повременить со свойствами, запланированными на следующий релиз. Полезные сведения о приоритезации тестирования можно почерпнуть в докладе Натальи Руколь.
Итак, мой рабочий день практически закончен. Осталось всю полученную и обработанную информацию передать тест-дизайнеру для разработки стратегии и написания тестов.
Заключение
Подводя итоги, можно сказать, что тест-аналитик – это своеобразное связующее звено между заказчиком и остальной командой тестирования. Он первым знакомится с новым материалом, систематизирует и раскладывает по полочкам всю ту информацию, которая обрушивается на простого смертного тестировщика при получении им в тестирование продукта.
В компании с полным циклом, где весь процесс разработки от идеи до передачи готового продукта в руки счастливого пользователя не выходит за рамки одной команды, работа тест-аналитика начинается еще до того, как разработчиками будут написаны первые строки кода. Уже на стадии формирования требования к продукту он выясняет цели тестирования, опираясь на основное предназначение разрабатываемого ПО, закладываемую в него логику, целевую аудиторию и возможные особые пожелания заказчика.