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

И да, сегодня мы поговорим именно об обычных ручных (функциональных) тестировщиках, без уклона в автоматизацию, нагрузку и другие технические виды тестирования!

Сейчас профессия ручного тестировщика – это одна из самых востребованных процессий ИТ и один из самых простых способов попасть в ИТ.

Почему?

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

Потому что профессия ручного тестировщика на начальном этапе не требует специфических знаний и умений. Основное «знание» для тестировщика – это умение «разрушать» и аналитическое мышление. А главное – иметь нестандартный склад ума, находить нетривиальные решения поставленных задач. Некий монстр, умеющий крушить и ломать:)

Hard skills всегда можно научить, а вот soft skills к сожалению научить очень сложно, потому что это характер человека, его отношение к чему-либо и т.д. Обычно я косо смотрю на руководителей, которые набирают себе специалистов по ручному тестирования по hard skills. Зачем Вы это делаете??? (ответы можете оставить в комментариях) Ну да ладно, продолжим:)

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

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

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

И в этом цикле статей поговорим об этом.

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

Выглядит это так:

• Зачем нам нужны техники тест-дизайна?
• Чтобы правильно определить проверки для тестирования.
• А используете ли Вы их в работе?
• В явном виде нет, мы сами определяем то, что нужно проверить.

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

Ответ прост.

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

Если говорить простыми словами, то техники тест-дизайна – это совокупность правил, позволяющих правильно определить список проверок для тестирования. И самое важное, это использовать эти правила всегда и везде :) уметь на интуитивном уровне применять данные правила. Именно умение «проводить аналитику в голове» отличает хорошего тестировщика!

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

• Анализ требований и рисков тестирования
• Определение проверок для тестирования
• Формализация проверок в виде тестовых сценариев
• Приоритезация проверок
• Определение подходов к тестированию

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

Итак, начнем.

А начнем мы с самого простого, а именно о 2-х основных техниках тест-дизайна, про которые все слышали, и я уверен, применяли, но скорее всего на интуитивном уровне в своей работе.
Это классы эквивалентности и граничные значения.

Что же такой классы эквивалентности?

Класс эквивалентности (Equivalence class) – это набор входных (или выходных) данных ПО, которые обрабатываются программой по одному алгоритму или приводят к одному результаты.

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

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

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

Рассмотрим пример:

Система скорринга рассчитывает процентную ставку по кредиту для клиента исходя из его возраста, который вводится в форму:

• От 18 до 25 лет – 18%
• От 25 до 45 лет – 16 %
• Свыше 45 лет – 20%

Мы определяем 2 основных класса – это позитивные и негативные сценарии.

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

Далее мы делим класс позитивных сценариев 3 класса вводимых значений 18-24, 25-44 и 45 +

В классе негативных сценариев мы формируем значения, исходя из необходимости проверки отказов программы, поэтому мы имеем 0, 1-17, отрицательные значения, ввод символов и т.д.

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

Итого мы имеем.

• Позитивные проверки: Ввод значений: 19, 30, 48 (значения могут быть любыми из данного диапазона класса)
• Негативные проверки: 0, 3, -1, А и т.д.

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

Еще одна особенность классов эквивалентности – это их применение. Я выделяю 3 уровня применения техник тест-дизайна для подготовки к тестированию.

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

Визуально это выглядит так:


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

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

Граничные значения дополняют эквивалентные классы, тем самым полностью покрывая проверки элемента ПО.

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

Вроде все просто!

Вернемся к нашему примеру ранее.

Система скорринга рассчитывает процентную ставку по кредиту для клиента исходя из его возраста, который вводиться в форму:

• От 18 до 25 лет – 18%
• От 25 до 45 лет – 16 %
• Свыше 45 лет – 20%

Что же здесь будет границей?

Если вы подумали о длине поля на страничке Хабры, или об отпуске в теплых странах, хочу вас расстроить, это не так :)

Что определить граничные значения нужно нечто иное. А именно, определить, какие значения являются начальным и конечным для нашего класса. И самое важное!!! Годы исследований в области тестирования показали, что бОльшая часть дефектов находится тестировщиками именно на стыке значений, которые меняют условия работы программы.

Поэтому, помимо граничного значения мы используем для тестирования дополнительно 2 значения, значение перед границей и значение после границы.

В итоге мы имеем:

Границы наших классов: 17, 18, 19, 24, 25, 26, 44, 45, 46 и max.

Также, у нас есть негативный класс, это от 0 до 18. Поэтому тут мы тоже должны использовать для тестирования граничные значения: -1, 0, 1, 17,18

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

-1, 0, 1, 17, 18, 19, 24, 25, 26, 44, 45, 46, max.

Значение max обычно уточняется у Заказчика или аналитика. Если не могут предоставить, то следует бросить его и не проверять необходимо подобрать значение, соответствующее здравому смыслу (вряд ли кто-то придет за кредитов в возрасте 100 лет).

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

Если ранее у нас были 3 значения для 3-х классов, 19, 30 и 48, то после определения граничных значений, мы можем исключить из списка значения 30 и 48 и заменить их предграничными значениями, такими как 26 (вместо 30) и 46 (вместо 48).

Граничные значения определяются не только для числовых значений, но и для буквенных (например, границы алфавита и кодировки), даты и времени, смысловых значений. Граница числовых значений зависит от формата ввода, если у вас целые числа, например, 2, то граничные значения будут 1 и 3. Если дробные значения, то границы для числа 2 уже будут 1,9 (1,99) или 2,1 (2,01) и т.д.

Техники тест-дизайна 1-го уровня достаточно просты и понятны. Я думаю, вы скажете, да это легко, но зачем досконально проверять каждый элемент. И будете правы!..

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

Что ж, слишком легко??? Сейчас начнем разбирать более сложные техники, готовьтесь.

Техники тест-дизайна 2-го уровня отвечают за вариативность и комбинаторику данных при проверке ПО.

Основной техникой тест-дизайна parwise testing (попарное тестирование). Суть техники заключается в минимизации вариативности комбинаций проверок, достаточных для обеспечения высокого качества ПО.

Простыми словами, в данной технике применяется правило Парето, 80 % качества можно достичь всего 20% проверок комбинаций данных.

Данная техника была выведена путем более 15-тилетнего исследования IEEE в области анализа причин возникновения дефектов в системе. Результаты исследования показали, что 98% всех дефектов возникают при конфликте ПАР входных данных или ОДНОГО входного параметра.

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

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

Пусть выпадение значения 2 – это дефект, тогда вероятность появления дефекта при кидании кубика равна 1/6=0,167.

Если мы бросаем 2 кубика, то вероятность выпадения 2-х двоек (2 дефекта) становиться ниже и равна 0,167*0,167 = 0,028, для 3-х уже 0,005 и т.д.

Получается, что вероятность возникновения дефекта при комбинации 3-х и более параметров настолько мала, что ее можно отбросить.

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

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


Если мы внимательно посмотрим, то увидим с Вами пять полей заполнения данных:

• ФИО
• Дата рождения
• Мобильный телефон
• Серия номер паспорта
• Электронная почта,
• а также 2 чек-бокса.

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

Очень ВАЖНО, при использовании техники попарного тестирования, мы не говорим о результате тестирования. Нам важно проверить вариативность данных при заполнении заявки.

Итак,

Поле ФИО может принимать значения (классы):

• ФИО на русском
• Невалидное значение
• Пустое значение

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

Идем дальше, дата рождения, также как и мобильный телефон, серия и номер паспорта можем иметь тоже 3 состояния:

• Валидное значение
• Невалидное значение
• Пустое значение

Т.к. электронная почта необязательно, то данное поле имеет 2 значения:

• Валидное значение
• Невалидное значение

Чек-боксы обычно имеют всего 2 состояния – Y или N.

Чтобы проверить все комбинации данной формы нам бы понадобилось сделать свыше 1000 тестов, но используя попарное тестирование нам достаточно всего 9 тестов!
Магия, не думаю:)

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

Мы берем ФИО и серия номер паспорта. Наша задача – перебрать все значения данной пары между собой:


После перебора одной пары, мы создаем другую пару и начинаем перебирать значения (например номер мобильного телефона)


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



Таким образом мы получаем 9 тестов с конкретными классами эквивалентности, которые мы можем вводить для проверки работы вариативности данных для формы. Классы мы можем заполнять конкретными значениями, которым мы получаем с вами используя 1 уровень техник тест-дизайна.

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

Надеюсь было полезно!