Home

Автор: Марк Толфтс (Mark Tolfts)

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2015-June.pdf#page=9

Перевод: Ольга Алифанова

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

Начнем с ряда определений, которые я вынес из курса Rapid Software Testing Джеймса Баха и Майкла Болтона:

Миссия тестирования – результаты, которых от вас хотят заказчики. Покройте продукт тестами так, чтобы оценить риски, основанные на требованиях.

Тест-стратегия – набор идей, направляющих тест-дизайн и выполнение. Она описывает, как вы будете покрывать продукт, чтобы оценить его качество.

Для начала боритесь с собой и не хватайтесь за свою любимую тест-стратегию, начиная заполнять ее на основании допущений или методологии. Я обычно начинаю со следующих фундаментальных вопросов:

1. Кто мои заказчики.
2. Что мне нужно протестировать?
3. Почему мои заказчики подключили меня к тестированию?
4. Чего ожидают мои заказчики?

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

Кто мои заказчики?

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

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

Что мне нужно протестировать?

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

Почему мои заказчики подключили меня к тестированию?

Вооружившись лучшим пониманием того, мнение каких людей имеет значение, и продукта, который я собираюсь тестировать, я стараюсь понять, какая информация наиболее значима для моих заказчиков. Под заказчиками я сейчас имею в виду заказчиков тестирования, которые поддерживают информацией мою тест-миссию. Есть ли среди них важные заказчики с различными взглядами? Важно выяснить это заранее, так как различные цели, возможно, потребуют различных стратегий. Я часто использую список возможных информационных целей из набора слайдов «Системы тестирования черного ящика» (BBST), как эвристический чек-лист, помогающий поддержать разговор с заказчиками. Зачастую первый ответ на мой вопрос звучит примерно так – «ну, протестируй там и скажи, готов ли продукт к релизу». Список BBST помогает добиться ясности, так как прогоняет моих заказчиков через различные информационные цели и информирует, как они могут повлиять на мою тест-стратегию. Я также указываю, что первичные информационные цели тест-миссии могут измениться со временем, чтобы поддержать новые горизонты. Схожим образом, при наличии чересчур большого количества информационных целей образуется неплохая возможность добиться ясности и разрешить все вопросы заранее.

Чего ожидают мои заказчики?

Помимо моих первичных информационных целей, что еще ожидается от меня??? Надо ли мннне следовать определённой методологии? Создать особые конечные продукты тестирования? Завершить тестирование к определённому моменту? Думая о факторах проекта, которые могут ограничить мой подход или помочь мне тестировать и в итоге донести информацию до нужных лиц, я использую проектные элементы эвристической модели тест-стратегии Джеймса Баха. Это еще одна возможность заранее прояснить ситуацию, обсудить компромиссы, и пересмотреть мою тест-миссию вместе с моими заказчиками. Используя аналогию с парашютистом – чего от меня ожидают лейтенант или капитан миссии? Должен ли я отчитываться о ней ежедневно и детально? Должен ли я следовать определенному протоколу?

Заключение

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

«Оценить коммерческий предпринимательский готовый к поставке продукт, Finsys, как подходящее решение для группы Финансов для выполнения общих бухгалтерских задач. Учитывая достаточную автономность финансовой группы, оценка концентрируется на удобстве использования и обладании заявленными свойствами управления ценностями, обязанностями, капиталом, доходом и расходами в соответствии с различным количеством существующих бизнес-процессов. Так как многие из этих процессов не документированы, от тестирования требуется задокументировать существующие процессы, держа в уме, что следующий проект будет нацелен на объединение их в единый процесс, внедренный во всех финансовых группах».

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

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