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

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

Элементы тест-фрейминга

Основная идея в том, что в любой связанной с тестированием ситуации:

• У вас есть тест-миссия, поиск информации. Ваша миссия может со временем меняться.
• У вас есть информация о требованиях – частично она явная, частично – неявная, и с шансами будет меняться со временем.
• У вас есть риски, лежащие в основе миссии. Знание о рисках и их приоритеты будут меняться.
• У вас есть идеи о том, что в продукте генерирует ценность, а что ей угрожает. В ходе тестирования эти идеи будут совершенствоваться.
• У вас есть контекст, в котором вы работаете, и со временем он будет меняться.
• Вы будете применять оракулы – принципы или механизмы, помогающие распознать проблему. Вы улучшите некоторые оракулы и найдете другие по ходу работы.
• У вас есть модели продукта, которые вы намерены покрыть. Эти модели будут улучшены и расширены в ходе проекта.
• У вас есть тест-техники, которые вы можете применять. У вас также есть выбор, какими техниками пользоваться и как именно. Вы будете разрабатывать техники по ходу работы.
• У вас есть установленные процедуры, которым вы следуете. Вы можете время от времени следовать им более или менее тщательно.
• Вы настраиваете продукт, работаете с ним и наблюдаете за ним (используя вышеупомянутые тест-техники), и вы оцениваете продукт (сравнивая его с вышеупомянутыми оракулами по отношению к ценности продукта и угрозам этой ценности).
• У вас есть навыки и эвристики, которые вы можете применять. Эти навыки и эвристики будут развиваться в ходе этого проекта и всей вашей карьеры как тестировщика.
• Существуют моменты, связанные с балансом стоимости/ценности ваших действий, и с ними нужно разобраться.
• У вас есть тесты, которые нужно провести. Их обычно меньше, чем тестов, которые вы хотели бы провести. В любом случае вы выбираете свои тесты из бесконечного множества возможных тестов.
• У вас есть время на выполнение ваших тестов. Доступное вам время, как правило, жестко ограничено – по сравнению с временем, необходимым на тесты, которые вам хотелось бы провести. Отведенное на тесты время асимптотически приближается к нулю по отношению к времени, необходимому для выполнения всех возможных тестов.

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

Цель тест-фрейминга

Цель тест-фрейминга – в способности предоставить ясные, логичные, убедительные ответы на вопросы вроде таких:

• Почему вы прогоняете (прогнали, будете прогонять) этот тест (а не какой-то другой тест)?
• Почему вы прогоняете этот тест сейчас (прогоняли тогда, будете прогонять позже)?
• Почему вы тестируете (тестировали, будете тестировать) это требование, а не то требование?
• Как вы тестируете (тестировали, будете тестировать) это требование?
• Как конфигурация, которой вы пользовались в своих тестах, связана с реальной конфигурацией продукта?
• Как связаны результат вашего теста и ваш тест-дизайн?
• Была ли миссия связана с риском? Как связан с риском этот тест?
• Чем отличается этот тест от других, которые вы могли бы выбрать?
• Достаточно ли вы квалифицированы (были квалифицированы, можете ли стать квалифицированным) для проведения этого теста?
• Почему вы думаете, что это (была, будет) проблема?

Форма тест-фрейминга

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

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

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

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

Пример 1:

Миссия: найти проблемы, которые могут угрожать ценности продукта – например, ошибки поведения или потери данных.

Тезис: тут есть поле ввода.

Тезис: после того, как пользователь нажимает Enter, поле ввода отправляет данные в буфер.

Тезис: неограниченный ввод может переполнить буфер.

Тезис: переполненный буфер затирает данные или программный код.

Тезис: затертые данные могут привести к потере данных.

Тезис: затертый программный код может привести к возникновению видимых ошибок поведения.

Соединение тезисов: ЕСЛИ это поле ввода не ограничено, И ЕСЛИ вследствие этого оно переполнит буфер, ТО существует риск потери данных ИЛИ ошибок поведения программы.

Тезис: чем больше набор данных, отправленных в это поле ввода, тем выше шанс затирания кода или данных.

Связь: СЛЕДОВАТЕЛЬНО, чем больше набор данных, тем выше шанс спровоцировать видимую проблему.

Связь: ЕСЛИ я вставлю в это поле экстремально длинную строку, я с большей долей вероятности смогу наблюдать за проблемой.

Вывод: СЛЕДОВАТЕЛЬНО, в качестве теста, я попробую вставить экстремально длинную строку в это поле И следить за признаками проблем вроде мусора в записях, в которых до этого, по моим наблюдениям, было чисто, или утечек памяти, или падений, или другого странного поведения.

Пример 2:

Миссия: оценить наш продукт и его взаимодействие со связанным с ним продуктом.

Тезис: наш продукт, MobileMoolah, позволяет пользователям записывать финансовые транзакции в момент продажи и загружать наборы этих транзакций в совместимые продукты.

Тезис: PC ChequeBook – второй по размерам среди десктопных финансовых продуктов, а CompuCash – лидер рынка.

Тезис: PC ChequeBook разрешает локализованные форматы даты (мм/дд/гггг, дд/мм/гггг, ггггмм-дд, и так далее).

Тезис: MobileMoolah тоже разрешает локализованные форматы даты.

Связь: если мы настроим форматы данных одинаково в обоих продуктах, то разумно ожидать импорта данных из MobileMoolah в PC ChequeBook, не приводящего к необходимости изменять дату вручную.

Тезис: цель любого программного продукта – сберечь время и повысить удобство пользователя.

Тезис: один из оракулов, которые могут указать на проблему в продукте – это несоответствие его явным или неявным задачам.

Тезис: другой оракул, который укажет на проблему в продукте – это его несоответствие разумным пользовательским ожиданиям.

Тезис: импортируя данные из MobileMoolah в PC Chequebook, с обоими форматами даты, установленными как дд/мм/гггг, мы наблюдаем, что импортированные транзакции содержат формат мм/дд/гггг.

Связь: если после передачи данных между PC ChequeBook и MobileMoolah поля месяца и дня переключаются для любой или для всех транзакций, продукт не соответствует разумным пользовательским ожиданиям, и не соответствует своей неявной задаче.

СЛЕДОВАТЕЛЬНО, у нас есть причина подозревать баг.

Тезис: на основании только этого теста нельзя без дальнейших разбирательств определить, где находится баг – в PC ChequeBook, или в MobileMoolah.

Тезис: новое обновление MobileMoolah должно выйти через четыре дня.

Связь: ЕСЛИ наша миссия в том, чтобы найти максимум багов до релиза, мы должны быстро воспроизвести этот баг и немедленно сообщить о нем (вместе с шагами воспроизведения) без дальнейшего исследования.

Связь: ЕСЛИ на данный момент это самая серьезная проблема из найденных, И ЕСЛИ мы убеждены, что наша миссия включает выяснение, связана ли эта проблема только с PC ChequeBook, или же это общий случай – мы должны воспроизвести ее с другой программой (возможно, с лидером рынка), прежде чем двигаться дальше.

Тезис: нам доступна тестовая система CompuCash, и мы можем немедленно прогнать на ней такой же тест и получить результат через две минуты.

Связь: ЕСЛИ проблема воспроизводится с CompuCash, ТО мы сможем сделать вывод, что наблюдаем за общей проблемой с MobileMoolah.

Вывод: ТАК КАК мы можем получить больше полезной и специфичной информации очень быстро, то так и стоит поступить.

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

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

Тесты вне фрейминга

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

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

Структуры тест-фрейминга

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

Миссия тестирования. Тестирование – необязательно простая задача поиска багов. У тестирования множество возможных миссий, включая информирование решений о выходе или не выходе в релиз, конкурсная оценка, поиск безопасных сценариев и обходных путей проблем. "Различные цели требуют различных инструментов и стратегий тестирования, и приведут к различным тестам, различной тест-документации, различным результатам". См. страницу 19 у Кема Кейнера, “Challenges in the Evolution of Software Testing Practices in Mission-Critical Environments.” Software Test & Evaluation Summit/Workshop (National Defense Industrial Association), Reston VA, September 2009. 

Информация о требованиях. В любом проекте всегда доступно больше информации, чем кажется на первый взгляд. Фокус в том, чтобы уметь быстро и сознательно находить и использовать эти источники информации. Используйте справку, подтекст и обмен мнениями как эвристические источники знания. Все они полезны, все они неполны, и все могут противоречить, усиливать, или уточнять друг друга. См. статью Майкла Болтона “Rock, Paper, Scissors”, Better Software, Vol. 8, No. 11, December 2006. 

Требования как справка, подтекст и обмен мнениями также обсуждаются в книге Кейнера, Баха и Петтикорда Lessons Learned in Software Testing: A Context-Driven Approach. Wiley, 2001.

Риски. История риска затрагивает четыре стороны – жертва (какой-то человек) страдает от ущерба, потери или досады из-за уязвимости в программе, которая спровоцирована какой-либо угрозой. Для быстрого знакомства с идеями рисков см. статью Джеймса Баха “Heuristic Risk-Based Testing” in Software Testing and Quality Engineering, 11/99. Также см. 

Майкл Болтон, “Test Design with Risk in Mind”. Better Software, Vol. 9, No. 7, July 2007.

Для более подробного списка см. Кейнер, Фалк, Нгуен, Testing Computer Software, Second Edition, Wiley 1999. Обсуждение рисков в целом: Николас Нассим Талеб, "Черный лебедь".

Ценность. Ценность продукта всегда субъективна и многогранна. Некоторые способы оценки ценности продукта: раздел "Критерии качества" эвристической модели тест-стратегии. См. также книгу Дональда Гауза и Джеральда Вайнберга, Exploring Requirements: Quality Before Design, Dorset House, 1989.

Контекст. См. модель тест-контекста и раздел "Окружение проекта" в эвристической модели тест-стратегии.

Оракулы. См. статью "Оракулы". Также см. статью Майкла Болтона “Testing Without A Map”, Better Software Vol. 7, No. 1, January 2005. И, наконец, см. работу Кема Кейнера и Дуга Хоффмана “Introduction: The strategy problem and the oracle problem”, Black Box Software Testing, Center for Testing Education and Research, Florida Institute of Technology. 

Покрытие. Первый шаг на пути оценки или улучшения качества тест-покрытия – определить, для кого это покрытие разработано и почему. Карта иллюстрирует взаимоотношение между двумя сущностями. В тестировании карта может выглядеть, как дорожная карта, но также и как список, график, таблица или набор историй. Мы можем использовать все это для размышления о тест-покрытии. Однако отличное тестирование не ограничивается исключительно покрытием "карты" – оно также связано с исследованием территории, а это процесс, путем которого выявляется то, что не покрыто картой. См. Майкл Болтон, “Got You Covered”, Better Software, Vol. 10, No. 8, October 2008; “Cover or Discover”, Better Software, Vol. 10, No. 9, November 2008; и “A Map By Any Other Name”, Better Software, Vol. 10, No. 10, December 2008. 

Тест-техники. См. раздел "Тест-техники" эвристической модели тест-стратегии. Также см. книгу Ли Копланда, A Practitioner’s Guide to Software Test Design, Artech House Publishers, 2003.

Навыки. См. “Exploratory Testing Skills and Dynamics”. 

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