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

Методы черного ящика:

1. Эквивалентное разбиение
2. Анализ граничных значений
3. Тестирование с помощью таблицы альтернатив
4. Тестирование с помощью таблицы переходов
5. Тестирование с помощью сценариев использования
6. Попарное тестирование
7. Причина и следствие

Эквивалентное разбиение

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

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

У нас есть четыре возрастных группы: младше 15 лет, от 15 до 25 лет, старше 25 и младше 60 лет и люди старше 60. При этом, в поле для ввода возраста помещается всего два символа, поэтому указать возраст более 99 лет технически невозможно.

QA-специалисту не нужно писать 99 тестов для каждого возраста, хватит пяти: по одному для каждой возрастной группы (скажем, 10, 18, 35 и 75 лет) и один для случая, если возраст человека превышает 99 лет. Да, последний тест на практике невыполним (поскольку в поле возраста невозможно ввести более двух знаков), и все же не следует забывать об этой проверке. 

Граничные значения

Техника граничных значений основана на предположении, что большинство ошибок может возникнуть на границах эквивалентных классов. Она тесно связана с  вышеописанной техникой эквивалентного разбиения, из-за чего часто используется с ней в паре. Тогда для примера из предыдущего пункта границами будут являться значения 0, 15, 25, 60 и 99. Граничными значениями будут 0, 1, 14, 15, 16, 24, 25, 26, 59, 60, 61, 98, 99, 100.   

Часто сложности возникают, если возрастные категории указаны «внахлест», например, 0-12, 12-25 лет и т.д. 

Скорее всего, у вас возникнет такой вопрос: если мы применяем граничные значения, то зачем нам тесты со значениями из середины диапазона, согласно технике эквивалентных классов? Ведь, казалось бы, значения 1, 14, 16, 24, 26, 59, 61, 98 уже это проверяют, значит в дополнительной проверке нет нужды.

Ответ:

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

В то же время техника граничных значений утверждает, что по статистике, на границах перехода между классами часто встречаются ошибки (во всяком случае чаще, чем в середине класса). Также программисты, которые тоже люди, иногда забывают обозначить в коде разницу между > и >= и наоборот. Именно поэтому границы классов нужно тестировать отдельно (или дополнительно) и количество тестов на одну границу = 3: сама граница, +1 шаг от нее вверх, -1 шаг от нее вниз.

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

Именно из за этой гипотетической разницы мы выполняем дополнительный тест (или несколько). Ведь если поведение на границах и в середине может отличаться, то правильность поведения на границах не гарантирует правильность поведения в середине диапазона.

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

Таблица принятия решений

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

Какие возможны сценарии:
1.       Правильный логин и правильный пароль.
2.       Правильный логин, неправильный пароль.
3.       Неправильный логин, правильный пароль.
4.       Неправильный логин, неправильный пароль. 

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

Однако, может быть так, что система выдает разные сообщения в зависимости от того, на каком этапе была допущена ошибка, скажем: invalid login, invalid password. Соответственно, групп потребуется больше, а таблица станет обширнее. 

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

Пример таблицы принятия решений 

Попарное тестирование

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

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

Для Parwise достаточно, чтобы каждое значение всех параметров хотя бы единожды сочеталось с другими значениями остальных параметров. Таким образом, матрицу можно значительно сократить. Например:

При составлении матрицы принятия решений для двух браузеров, двух ОС и двух языков было бы нужно 8 сценариев. При попарном тестировании достаточно четырех. 

Все это можно просчитать и вручную, но не обязательно – гораздо удобнее автоматизировать процесс. Для этого существует программа попарного независимого комбинированного тестирования – Pairwise Independent Combinatorial Testing (PICT). Для проведения тестирования специалист создает текстовый файл с перечислением и их возможных значений, а затем запускает PICT через cmd – командную строку. Скомбинированные тесты отображаются в виде таблицы в самой консоли. Так же результаты по желанию можно выгрузить в файл Excel. 

Пример содержимого файла для программы PICT:

Браузер: Chrome, Opera
ОС: Windows, Linux
Язык: RU, ENG

Пример попарного тестирования

Причина и следствие

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

Примерный алгоритм использования техники:  

1. Выделяем причины и следствия в спецификациях.  
2. Связываем причины и следствия.  
3. Учитываем «невозможные» сочетания причин и следствий.  
4. Составляем «таблицу решений», где в каждом столбце указана комбинация входов и выходов, т.е. каждый столбец – это готовый тестовый сценарий.  
5. Расставляем приоритеты.

Эта техника помогает: 

• Определить минимальное количество тестов для нахождения максимума ошибок. 

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

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

Например, QA-специалист тестирует приложение типа “записная книжка”. После ввода всех данных нового контакта и нажатия кнопки Создать (причина) приложение должно автоматически создать карточку с номером телефона, фотографией и ФИО человека (следствие). Тесты покажут, можно ли оставлять одно или несколько полей пустыми, распознает ли система кириллицу, латиницу или оба алфавита, а также другие параметры.

Предугадывание ошибок

Используя свои знания о системе, QA-специалист может «предугадать», при каких входных условиях есть риск ошибок. Для этого важно иметь опыт, хорошо знать продукт и уметь выстроить коммуникации с коллегами. 

Например, в спецификации указано, что поле должно принимать код из четырех цифр. В числе возможных тестов:

• Что произойдет, если не ввести код?
• Что произойдет, если не ввести спецсимволы?
• Что произойдет, если ввести не цифры, а другие символы?
• Что произойдет, если ввести не четыре цифры, а другое количество?

Преимущества:

1. Эта проверка эффективна в качестве дополнения к другим техникам.
2. Выявляет тестовые случаи, которые “никогда не должны случиться”. 

Недостатки:
1. Техника в значительной степени основана на интуиции.
2. Необходим опыт в тестировании подобных систем.
3. Малое покрытие тестами. 

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

Покрытие условий

Покрытие операторов

Если сравнить два этих метода, придем к следующему заключению:

100% покрытие условий = 100% покрытие операторов
НО
100% покрытие операторов != 100% покрытие условий

Итоги

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

Источники: https://www.simbirsoft.com/blog/tekhniki-test-dizayna-i-ikh-prednaznachenie/, ISTQB-силлабус, https://testerpractice.blogspot.com/2015/12/vs.html

Дополнительные материалы:

статья о тест-дизайне, техниках тест-дизайна: класс эквивалентности, граничные значения, попарное тестирование

статья о понятиях техники тест дизайна

статья о попарном тестировании: суть техники, инструменты и примеры