Мысли об основах тест дизайна

< Предыдущее сообщение по теме обучения: Мысли об основах тестирования
> Следующее сообщение по теме обучения: Техники анализа классов эквивалентности и граничных значений

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




Определение тест дизайна

Итак, что такое тест дизайн?

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

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

Давайте приведем пример: что такое гипотеза, что такое тест, проверяющий гипотезу, что такое разработка тестов.

Предположим, мы видим черный ящик и не знаем, что внутри:

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

• В ящике пусто
• В ящике лежит мяч
• В ящике лежит кот

Чтобы проверить каждое предположение, мы можем провести несколько экспериментов (тестов):

• Поднять и взвесить
• Послушать
• Потрясти
• Открыть

Каждый тест либо подтверждает, либо опровергает наше предположение.

Также можно сказать, что есть тесты разной степени эффективности для разных предположений. Например, для того, чтобы подтвердить, что кот в ящике, тест «Послушать» может нам ничем не помочь. Зато тест «Открыть ящик» наверняка будет эффективнее.

Можно провести аналогию с тестированием программного продукта. Гипотезы, которые мы можем проверять в этом случае:

• Программа работает неправильно
• Программа работает правильно
• Программа удобна
• Программа работает быстро

И возможные тесты по проверке будут такими:

• Проверить работу одной функции
• Проверить работу другой функции программы
• Проверить работу интерфейса
• Измерить время отклика программы на действия пользователей

Цели тест дизайна

Можно выделить главные цели тест дизайна: 

1. Придумать тесты, которые обнаружат наиболее серьезные ошибки продукта. Да, мы можем придумывать тесты, которые находят несерьезные ошибки, но тогда тестирование будет неэффективным. 
2. Минимизировать количество тестов, необходимых для нахождения большинства серьезных ошибок. Мы может придумать столько тестов, сколько не в состоянии будем выполнить. Поэтому перед разработчиками тестов всегда стоит задача – сохранить эффективность тестов (то есть их способность обнаруживать серьезные ошибки) без увеличения их числа.

Задачи тест дизайна

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

Например, в эту категорию входит:

• Написание тест кейсов
• Оценка и анализ рисков (то есть проблем, которые могут быть при использовании продукта)
• Создание списка приемочных проверок для нового функционала
• Анализ требований

Навыки тест дизайнера 

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

Если говорить о навыках, необходимых тест дизайнеру, можно выделить:

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

Важный вопрос, который мог у вас возникнуть: необходимо ли тестеру знать, что такое тест дизайн, и уметь разрабатывать тесты?

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

Техники тест дизайна 

Давайте подробнее рассмотрим техники тест дизайна.

Что это такое? Это способ создания тестов.

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

Техники могут содержать рекомендации не только по тест дизайну (разработке тестов), но и по выполнению тестов.

Давайте перечислим несколько основных техник тест дизайна:

• Разбиение на классы эквивалентности (это метод сокращения числа тестов путем выбора одного теста из эквивалентного набора)
• Анализ граничных значений (это метод проверки переменных программы на их границах)
• Функциональное тестирование (это проверка всех функций продукта, одна за одной)
• Тестирование на основе сценариев использования (это проверка продукта по наиболее частым и важным сценариям использования – use cases)
• Тестирование на основе рисков (это проверка важных проблем, которые могут возникнуть)
• Unit-тестирование
• Регрессионное тестирование
• Тестирование безопасности

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

Например, есть довольно забавные техники:

• Партизанское тестирование – попытка найти ошибки в некоторой области программы, причем тесты выполняются быстрые и вредоносные.
• Есть еду своей собаки – когда продукт используется внутри самой компании, в повседневной работе.
• Тестирование глупой обезьяны – беспорядочное автоматическое тестирование, когда с клавиатуры вводятся случайные числа и мышь кликает по случайным местам экрана.
• Тестирование мыльной оперы – (http://www.logigear.com/logi_media_dir/Documents/Soap_Opera_Testing.pdf) – когда проверяются слегка усложненные и расширенные сценарии реального использования. Главное в одном сценарии проверить как можно больше всего, как в мыльной опере, в которой в одной серии может произойти столько событий, сколько умещается во всей жизни.

Классификация техник

А как можно классифицировать техники?

Считается, что каждая техника может заключать в себе рекомендации по семи вопросам: 
1.       Что тестируется?
2.       Насколько тщательно?
3.       Кем тестируется?
4.       Какие проблемы ищутся?
5.       Как тестируется?
6.       Как оценивается результат тестов?
7.       Есть ли определенная цель тестирования?

Но каждая техника обычно дает ответы не на все вопросы, а на 2-3. Остальные нюансы оставляет на наше усмотрение, то есть на усмотрение тех, кто будет ее использовать.

В зависимости от того, по каким вопросам дает рекомендации техника, все техники делят на разные категории: 

• Ориентированные на тестовое покрытие (отвечают на второй вопрос). Например, функциональное тестирование, разбиение на классы эквивалентности.
• Ориентированные на людей, которые выполняют тестирование (третий вопрос). Например, пользовательское тестирование, бета тестирование.
• Ориентированные на цель (седьмой вопрос). Например, верификация билда, приемочное тестирование пользователями, сертификация.
• И другие.

Давайте для примера рассмотрим несколько техник, которые дают нам ответы на некоторые вопросы, но оставляют нам свободу выбора по остальным.

• Функциональное тестирование. Техника говорит нам, что нужно тестировать функции (фичи) продукта, одну за одной, по очереди. Причем она рекомендует тестировать все функции. Насчет остального (кто выполняет тестирование, какие проблемы ищутся, как мы тестируем, как определяем результат тестов) – мы решаем сами. 
• Бета тестирование. Техника говорит нам, что тестирование лучше проводить в выделенной группе пользователей. Остальные вопросы – на наше усмотрение. 
• Unit-тестирование. Техника говорит нам, что тестируется каждая функция кода, тестирование обычно проводится программистом, тесты выполняются автоматически. Остальное (какие проблемы ищут unit-тесты, насколько они покрывают код) – мы вольны решать сами.

Техники черного и белого ящика

Наверняка, вы слышали про тестирование черного и белого ящика. Иногда техники тестирования делят по этому признаку. Давайте коротко обсудим, чем отличаются эти техники.

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

Однозначно сказать, какие техники (белого или черного ящика) лучше – нельзя. ИМХО, самый хороший вариант – комбинировать эти техники, от этого тестирование может стать намного эффективнее.

Исследовательское тестирование

Мне бы также хотелось рассказать вам о двух подходах к тестированию:

• Исследовательском (эксплоративном) тестировании
• Тестировании по тест кейсам

Их очень часто противопоставляют друг другу в литературе по тестированию.

Давайте начнем с исследовательского тестирования:

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

Обычно тестировщик, занимающийся ET (exploratory testing, исследовательское тестирование), не имеет четкого сценария тестирования. У него есть цель, но все, что нужно для достижения этой цели – он определяет сам. Такое тестирование обычно слабо структурировано, предоставляет тестеру много свободы. Оно не очень удобно для оценки тестового покрытия, то есть определения того, что мы уже протестировали.

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

Тестирование по тест кейсам

Теперь давайте рассмотрим второй подход, который очень популярен во всем мире – тестирование по тест кейсам (Scripted testing):

Это подход к тестированию, который предполагает формальное описание тестов в форме чеклистов или тест кейсов.

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

Что такое тест кейс?

Раз уж мы заговорили о тест кейсах, давайте обсудим, что это такое.

Типичный тест кейс состоит из следующих частей: 

• Цель. То есть, смысл тест кейса, что мы в нем проверяем.
• Предварительные шаги (опционально). Содержит список шагов, которые нужно выполнить до начала теста.
• Шаги. Это описанный по шагам алгоритм выполнения теста. 
• Ожидаемый результат (или результаты). Раздел, который содержит описание поведения продукта, которое мы должны наблюдать после выполнение шагов теста. По ожидаемому результату мы обычно определяем, прошел продукт тест или не прошел.

Также мы упомянули чеклисты. Что это?

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

Плюсы и минусы эксплоративного тестирования и тестирования по сценариям

Давайте рассмотрим плюсы и минусы исследовательского тестирования и тестирования по сценариям.

Исследовательское тестирование: 

• Хорошо развивает навыки, дает тестеру больше свободы
• Не требует времени для написания тестовых сценариев, все время уделяется тестированию
• Поощряет изучение тестером продукта

Но:

• Неопытным тестерам в первое время бывает трудно из-за того, что они предоставлены сами себе, у них нет хотя бы примеров тестов, которые нужно выполнять
• Без тест кейсов сложнее оценить тестовое покрытие
• Изучение продукта отнимает время от непосредственного тестирования

Тестирование по сценариям: 

• Требует меньше навыков от тестера, который выполняет тесты
• Дает возможность легче оценить тестовое покрытие
• Стабильность и неизменяемость тест кейсов дает возможность проследить качество продукта с течением времени
• Обеспечивает более структурированный подход к тестированию
• Как правило, выполнение тестов не требует дополнительных исследований и общения с разработчиками, аналитиками, работы со спецификациями, что дает выигрыш по времени

Но:

• Тестирование по тест кейсам ограничивает свободу тестера
• Формирует привычки в тестировании, потому что тестер привыкает делать такие проверки, как описаны в тест кейсах 
• Тест кейсы потихоньку теряют свою эффективность и перестают находить баги
• Постоянное выполнение одних и тех же тестов со временем утомляет
• Требует много времени на поддержку тест кейсов: обновление, удаление, исправление
• Тестер медленно развивает свое знание продукта и его контекста по сравнению с исследовательским тестированием

У обоих подходов есть плюсы и минусы. Отсюда можно сделать вывод:

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

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

Что почитать по тест дизайну?

 

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

Но что-то новое в раздел литературы по тест дизайну я бы добавил:

• Practitioner’s Guide to Software Test Design (Lee Copeland) – очень полезная книга по тест дизайну. Она понятным языком описывает основные техники тест дизайна, собранные из разных источников. Рекомендую, написано интересно! 
• http://www.testingeducation.org/BBST/testdesign/ - сайт одного из курсов по обучению тестированию. Здесь есть видео, слайды лекций, статьи по тест дизайну. Рекомендую тем, кого не смущает английский язык.

Спасибо за внимание! Надеюсь, было интересно. Буду рад выслушать ваше мнение в комментах.