Роль тест дизайнера

33 тестера

суббота, 20 июля 2013 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

14 комментариев:

На мой взгляд, автор блога спутал понятие «техника тест-дизайна» и «вид-метод тестирования» (в отношении, например, перечисленных после анализа граничных значений). Также (насколько поняла из других разных источников — книги, блоги, видео) — описанный тут вид тестирования — скорее Ad hoc (а не исследовательское). Есть исследовательское тестирование с написанием тест-кейсов.

Спасибо, что подняли очень интересный вопрос!

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

Что касается видов и методов тестирования с одной стороны и техник тест дизайна с другой — мне кажется эти понятия очень похожи и грань между ними найти сложно.

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

Например, возьмем метод функционального тестирования. Для того, чтобы его использовать, нам нужно придумать тесты. Как мы их будем придумывать? Используя соответствующую технику тест дизайна. Эта техника заключается в создании тестов для каждой функции. И она также дает нам совет по выполнению тестов: тестируйте каждую функцию по очереди.

Если говорить о Ad hoc и исследовательском тестировании, то я думаю, что Ad hoc — это более интуитивное и беспорядочное тестирование, когда тестировщик просто идет и проверяет, что ему хочется. У него нет определенной цели, структуры тестов в голове, какой-то системы. Как мне кажется, исследовательское тестирование более структурированное. Обычно тестировщик знает, что ему нужно проверить, у него в голове есть цель и какая-то система проведения тестов. Хоть тесты в этом случае не обязательно должны быть оформлены в виде тест кейсов.

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

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

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

Исследовательское тестирование отличаетса от кейсового только одним — длиной степа. В кейсовом — изучаешь требования пол дня, потом проводишь тест дизайн день, пишешь кейсы, получаешь функционал, тестишь, анализируешь, всё это занимает 2-3 дня, первый фидбек дня через полтора. В исследовательском — изучаешь 15 минут требования, час намечаешь приблизительный план тестирования и вперёд — степ 5-10 минут — требование, тест, выполнение, анализ. А потом уже после цикла — оформление документации. Первый фидбек — через час-два.

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

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

Кто такие тест-дизайнеры и зачем они нужны

Что такое «качественный программный продукт»? Это продукт, который выполняет поставленные перед ним задачи и удовлетворяет ожидания пользователей. Для достижения этого результата любая программа сначала проходит тестирование и только потом попадает в руки конечного потребителя. Так как сроки тестирования (как и любого процесса) имеют тенденцию стремиться к бесконечности, нам необходимо грамотное выстраивание процесса. И тут уже никак не обойтись без тест-дизайна.

Тест-дизайнер — что это за зверь и с чем его едят?

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

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

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

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

Ли Копланд (Lee Copeland) выделяет следующие техники, используемые в тест-дизайне:

1. Тестирование Классами Эквивалентности (Equivalence Class Testing).
Тестовые данные разбиваются на определенные классы допустимых значений. В рамках каждого класса выполнение теста с любым значением тестовых данных приводит к эквивалентному результату. После определения классов необходимо выполнить хотя бы один тест в каждом классе.

• при возрасте от 0 до 16 лет – не нанимать;
• при возрасте от 16 до 18 лет – можно нанять только на part time;
• при возрасте от 18 до 55 лет – можно нанять на full time;
• при возрасте от 55 до 99 лет – не нанимать.

• класс эквивалентности NO: 0-16;
• класс эквивалентности PART: 17-18;
• класс эквивалентности FULL: 19-55;
• класс эквивалентности NO: 56-99.

• 10 – не нанимать;
• 17 – нанимать на неполный день;
• 40 – нанимать на полный день;
• 80 – не нанимать.

2. Тестирование Граничных Значений (Boundary Value Testing).
Эта техника основана на том факте, что одним из самых слабых мест любого программного продукта является область граничных значений. Для начала выбираются диапазоны значений – как правило, это классы эквивалентности. Затем определяются границы диапазонов. На каждую из границ создается 3 тест-кейса: первый проверяет значение границы, второй – значение ниже границы, третий – значение выше границы.

Нужно помнить, что «выше» и «ниже» – понятия относительные. Например, если мы говорим о границе 6$, то значение «ниже» будет 5$, а значение «выше» – 7$. Если речь идет о границе 6.00$, то значение «ниже» будет 5.99$, а значение «выше» – 6.01$. Не исключено, что значение «ниже» или «выше» границы может быть другим классом эквивалентности, уже охваченным нами. В этом случае нет смысла создавать дубликаты тест-кейсов.

• при возрасте от 0 до 16 лет – не нанимать;
• при возрасте от 16 до 18 лет – можно нанять только на part time;
• при возрасте от 18 до 55 лет – можно нанять на full time;
• при возрасте от 55 до 99 лет – не нанимать.

Представим, что соответствующий код выглядит так:

If (applicantAge >= 0 && applicantAge = 16 && applicantAge = 18 && applicantAge = 55 && applicantAge

• при возрасте от 0 до 15 лет – не нанимать;
• при возрасте от 16 до 17 лет – можно нанять только на part time;
• при возрасте от 18 до 54 лет – можно нанять на full time;
• при возрасте от 55 до 99 лет – не нанимать.

В итоге корректный код должен выглядеть следующим образом:

If (applicantAge >= 0 && applicantAge = 16 && applicantAge = 18 && applicantAge = 55 && applicantAge

Таким образом, набор значений, для которых будут составлены тесты, будет выглядеть так: <-1, 0, 1>, <15, 16, 17>, <17, 18, 19>, <54, 55, 56>, <98, 99, 100>.

3. Таблица Принятия Решений (Decision Table Testing).
Таблицы решений – это удобный инструмент для фиксирования требований и описания функциональности приложения. Таблицами очень удобно описывать бизнес-логику приложения, и они могут служить отличной основой для создания тест-кейсов.

По клику на картинку откроется полная версия.

По клику на картинку откроется полная версия.

• Если водитель был примерным студентом и при этом еще и женат, то ему предоставляется скидка $60.
• В случае, когда водитель женат, но студентом он был так себе, то ему предоставляется скидка $50.
• Если же он не женат, но был хорошим студентом, то ему предоставляется скидка $40.
• В случае, когда человек не женат и не был хорошим студентом, ему предоставляется скидка $30.

По клику на картинку откроется полная версия.

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

4. Тестирование Состояний и Переходов (State-Transition Testing).

• Состояние (state, представленное в виде круга на диаграмме) – это состояние приложения, в котором оно ожидает одно или более событий. Состояние помнит входные данные, полученные до этого, и показывает, как приложение будет реагировать на полученные события. События могут вызывать смену состояния и/или инициировать действия.
• Переход (transition, представлено в виде стрелки на диаграмме) – это преобразование одного состояния в другое, происходящее по событию.
• Событие (event, представленное ярлыком над стрелкой) – это что-то, что заставляет приложение поменять свое состояние. События могут поступать извне приложения, через интерфейс самого приложения. Само приложение также может генерировать события (например, событие «истек таймер»). Когда происходит событие, приложение может поменять (или не поменять) состояние и выполнить (или не выполнить) действие. События могут иметь параметры (например, событие «Оплата» может иметь параметры «Наличные деньги», «Чек», «Приходная карта» или «Кредитная карта»).
• Действие (action, представлено после «/» в ярлыке над переходом) инициируется сменой состояния («напечатать билет», «показать на экране» и др.). Обычно действия создают что-то, что является выходными/возвращаемыми данными системы. Действия возникают при переходах, сами по себе состояния пассивны.
• Точка входа обозначается черным кружком.
• Точка выхода показывается на диаграмме в виде мишени.

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

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

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

5. Метод Парного Тестирования (Pairwise testing).
Метод парного тестирования основан на следующей идее: подавляющее большинство багов выявляется тестом, проверяющим либо один параметр, либо сочетание двух. Ошибки, причиной которых явились комбинации трех и более параметров, как правило, значительно менее критичны.

Допустим, что мы имеем систему, которая зависит от нескольких входных параметров. Да, мы можем проверить все возможные варианты сочетания этих параметров. Но даже для случая, когда каждый из 10 параметров имеет всего два значения (Вкл/Выкл), мы получаем 2 10 = 1024 комбинаций! Используя метод парного тестирования, мы не тестируем все возможные сочетания входных параметров, а составляем тестовые наборы так, чтобы каждое значение параметра хотя бы один раз сочеталось с каждым значением остальных тестируемых параметров. Таким образом, метод существенно сокращает количество тестов, а значит, и время тестирования.

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

6. Доменный анализ (Domain Analysis Testing).
Это техника основана на разбиении диапазона возможных значений переменной (или переменных) на поддиапазоны (или домены), с последующим выбором одного или нескольких значений из каждого домена для тестирования. Во многом доменное тестирование пересекается с известными нам техниками разбиения на классы эквивалентности и анализа граничных значений. Но доменное тестирование не ограничивается перечисленными техниками. Оно включает в себя как анализ зависимостей между переменными, так и поиск тех значений переменных, которые несут в себе большой риск (не только на границах).

7. Сценарий использования (Use Case Testing).
Use Case описывает сценарий взаимодействия двух и более участников (как правило – пользователя и системы). Пользователем может выступать как человек, так и другая система. Для тестировщиков Use Case являются отличной базой для формирования тестовых сценариев (тест-кейсов), так как они описывают, в каком контексте должно производиться каждое действие пользователя. Use Case, по умолчанию, являются тестируемыми требованиями, так как в них всегда указана цель, которой нужно достигнуть, и шаги, которые надо для этого воспроизвести.

Что тут думать, трясти надо!

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

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

Действительно: какой смысл, допустим, от полного тестового покрытия формы авторизации, если при этом не будет корректно работать механизм оплаты за товар в интернет-магазине? Ведь за то время, пока тестировщик 100 тестами проверит 100 значений, тест-дизайнер придумает, как за 10 тестов проверить 1000 значений! Таким образом, усилия, затраченные на тест-дизайн, с лихвой окупятся качеством выполнения тестирования.