Home

Автор: Рикард Эдгрен (Rikard Edgren)
Оригинал
Перевод: Ольга Алифанова

Мы начинаем публиковать перевод книги Рикарда Эдгрена "Записная книжка тест-дизайнера". В первой главе книги он говорит о теоретической основе тест-дизайна, его научной базе и особенностях пространства тестирования.

Эта книга описывает способы извлечения пользы из множества источников информации, необходимых для энергичного системного тестирования.

Я начал разбираться в этом вопросе глубже, когда в сто пятый раз ощутил, что существующие техники тест-дизайна не отражают мой подход после десятилетней работы с одним и тем же набором продуктов. Это вылилось в расширенную генерализацию идей, о которых я узнал благодаря коллегам (я учился у всех своих коллег, но особенно у Хенрика Эмилссона и Мартина Янссона. Библиография отражает наиболее важные моменты. Хочется также поблагодарить рецензентов, которые потратили свое время на то, чтобы сделать ценные замечания: это Роберт Бергквист, Лиза Криспин и Мэтью Хоссер).

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

Я хочу сделать упор на результатах тестирования, на широкой выборке, делающей возможными озарения (концепция "озарения" набирает популярность в тестировании, впервые, насколько я знаю, об этом написал Джонатан-Бах в статье Session-Based Test Management – журнал "Software Testing and Quality Engineering", 11/00, см. также Rikard Edgren, Testing is an Island, A Software Testing Dystopia, EuroSTAR conference 2008) и нацеленной на полноценное освещение важных областей (об освещении областей см. Rikard Edgren, Is your testing saturated?). Возможно, книга лучше всего подойдет ручным тестировщикам, которые концентрируются на важных проблемах – людям, которые хотят выяснить важную информацию, а не удовлетворяются соответствием или несоответствием требованиям.

Книга рассказывает про методы тест-дизайна, которые долгое время применяются как мной, так и многими другими тестировщиками (о работе тестировщика написано много статей, но Фиона Чарльз затронула основные моменты в статье Modeling Scenarios using Data).

Суть

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

Тестировщики могут следовать идеям социальной науки Grounded Theory: мы должны пользоваться множеством источников информации о субъекте (требования, спецификации, прототипы, код, баги, каталоги ошибок, информация службы поддержки, рассказы заказчика, ожидания пользователей, технологии, инструменты, модели, системы, цели качества, атрибуты качества, тест-техники, тест-идеи, разговоры с людьми, риски, возможности); мы должны уметь группировать и подходить к задачам креативно, и создавать теорию, состоящую из ряда идей, отражающих то, что важно протестировать, совместно с результатами.

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

Это может показаться сложным, однако люди наделены феноменальными способностями.

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

Grounded Theory

С моей точки зрения, за научную теоретическую базу тест-дизайна можно взять Grounded Theory, которая используется в социальных науках как качественный тщательный анализ феномена (см. Juliet Corbin and Anselm Strauss, Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory, Second Edition, SAGE Publications, Inc., Thousand Oaks 1998).

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

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

Мне кажется, это хороший аналог тестирования, особенно потому, что он настаивает на креативном подходе исследователя.

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

Я не пробовал применять GT к тестированию – она послужила источником вдохновения для описания моего тест-дизайна.

Теория тест-дизайна

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

Пример соответствующей высокоуровневой тест-стратегии:

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

Мы также хотим, чтобы вы помогали ускорить работу разработчиков; создавали для них легкие мишени.

Низкоуровневые тест-стратегии (да, их множество) естественным образом придут к вам в процессе вашего изучения продукта, но вам, возможно, стоит проверить явные требования и провести чартерное или свободное исследовательское тестирование.

Тест-анализ – необыкновенно слабо проработанная область в литературе по тестированию. Думаю, это связано с тем, что традиционное/церемониальное тестирование в нем не нуждается – то, что должно быть протестировано, уже "полностью" описано в требованиях. Еще это связано с тем, что "большая часть опубликованных руководств по тест-техникам основывается на юнит- и компонентных техниках" (см. Neil Thompson & Mike Smith, The Keystone to Support a Generic Test Process: Separating the “What” from the “How”). Это печально, так как куда более важные тест-решения принимаются, когда вы выбираете, какие тест-элементы учитывать и до какой степени; когда вы пытаетесь найти хорошие способы исследования какой-то области, и дизайн-методы для выявления важной информации о ПО с точки зрения пользователя. В то же самое время в этих процессах заключена самая суть исследовательского тестирования (основы исследовательского тестирования описаны в курсах Кема Кейнера и Джеймса Баха Black Box Software Testing, Exploratory Testing), и я тоже больше заинтересован в тестировании, а не в проверках (см. цикл статей Майкла Болтона, начиная с Testing vs. Checking).

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

Мне неинтересно создавать тест-кейсы – я считаю, что лучше создавать тест-идеи, как минимум на уровень выше тест-кейсов. Детали выполнения конкретных тестов часто отдаются на откуп тестировщику. Ожидаемый результат необязателен – зачастую мы не знаем, что планируем найти, и отчитываемся обо всем, что стоит упоминания.

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

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

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

Важные моменты

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

Тест-дизайн должен порождать тест-идеи, которые при их воплощении (с озарениями в процессе или без них) покроют большую часть того, что важно (требования будут неплохим стартом). Это очень сложно – в ПО значимо множество вещей, и поэтому "Тестирование – это невероятно креативная и интеллектуально сложная задача" (страница 19 в Glenford Myers, The Art of Software Testing, Second Edition, John Wiley & Sons, Inc., Hoboken 2004 (впервые опубликована в 1979)).

Я убежден, что в отдельных ситуациях вы или знаете, что важно, или нет. Поэтому базовая стратегия – это учиться, учиться, и еще раз учиться, и тогда вы будете знать, что же тут важно, чаще, чем не знать.

Ваш навык понимания того, что важно, будет развиваться со временем, а движим он любопытством и сотрудничеством. Если вы долго работаете над продуктом, используйте это как преимущество, изучая различные способы, которыми этот продукт приносит пользу – это долгое и веселое образовательное приключение. В пути вам помогает доменное знание, благодаря контактам с конечными пользователями концепции обретают плоть и кровь, воображение позволяет конструировать жизнеспособные сценарии и новые взаимодействия, критическое мышление помогает заметить пробелы, изучение технологий – понять, что можно сделать с их помощью (и что должно быть сделано). Все это – составные части мышления тестировщика (хорошее описание мышления тестировщика – в статье Майкла Болтона Why Do Some Testers Find The Critical Problems?).

Тест-пространство можно рассматривать, как бесконечность, в которой находится коробка требований и "картошка" продукта (см. статью Рикарда Эдгрена In search of the potato…):

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

Чтобы распознавать важность, нужно принимать оценочные решения. В традиционном тестировании используется чересчур много количественных подходов, пришедших из естественных наук (я предпочитаю подход Кема Кейнера, который описан в статье Тестирование как социальная наука, Toronto Association of Systems and Software Quality, October, 2006.). Компьютеры плохо разбираются в том, что важно – в этом хороши люди.

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