Предугадывание ошибки тестирование пример

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

Суть техники в том, что чтобы найти все способы, которые могут сломать тестируемый продукт.

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

— Историю работы приложения в прошлом.

— Наиболее вероятные типы дефектов, допускаемых при разработке.

— Типы дефектов, которые были обнаружены в схожих приложениях.

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

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

Например, в программе я вижу: «для подтверждения заказа введите свой номер телефона в формате +7(…)… ….» И я, как тестировщик, начинаю думать: «А если не вводить телефон?», «А если ввести в формате не +7, а просто 8? «, и так далее. Это и есть предугадывание ошибки.

Давайте посмотрим на конкретных примерах, как можно использовать этот метод.

Уже знакомая нам игра с молокозаводом

Возьмем объекты, которые нам необходимо построить. Например, каким образом можно сломать курятник на этапе покупки?

1. Можно попробовать поставить его на другой объект

2. Или за границу доступного поля

3. За границей поля тоже не получается.. А давайте попробуем поставить на воду? Вдруг разработчики не учли этот момент?

Тоже никак, все работает как надо… Ладно поставим пока курятник на место. Теперь попробуем проверить, все ли нормально с его работой.

4. В курятник можно покупать и сажать кур. А что если попробовать вместо кур поместить коров?

5. Или попробовать кур поместить на территорию вне курятника

6. Или попробовать зайти в магазин, пока покупаем кур

«Ладно, видимо не в этот раз» — говорим мы себе и закрываем игру…

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

А теперь посмотрим на примере сайта

Возьмем один из элементов сайта — форму регистрации. Посмотрим на нее внимательно и подумаем, как мы можем ее «сломать».

Мне на ум приходят вот какие варианты:

1. Указать e-mail c несуществующим доменом на конце.
2. Указать e-mail без знака «@».
3. Заполнить поле «Пароль» без использования обязательных символов. Например, если программа требует, чтобы в пароле были заглавные и строчные буквы, то пробуем ввести пароль без использования заглавных букв.
4. В поле «Пароль еще раз» ввести символы отличные от символов в поле «Пароль».
5. Снять галочку «Я принимаю условия Пользовательского соглашения».
6. Ввести неверные символы с картинки.
7. Оставить одно поле незаполненным.

________________________________

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

________________________________

В предугадывании ошибок нет четкой и логической схемы, которая позволила бы нам составить тест-кейсы. Т.е. нельзя сказать, что сделав сначала Шаг №1, затем Шаг №2 и т.д. мы на выходе получим готовые проверки с максимально полным покрытием.
Наоборот, эта техника основывается на опыте тестировщика и на его умении думать креативно и деструктивно.

• Суть методики
• Особенности
• Что требуется, чтобы эффективно (пред)угадывать ошибки
• Примеры
• Преимущества и недостатки методики

Что это

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

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

Особенности

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

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

Частыми ошибками в приложениях (следовательно, наиболее вероятными ошибками в тестируемом приложении) являются, например:

• Ввод некорректных (невалидных) параметров и символов
• Например, ввод пробела в “цифровые” поля, где это недопустимо
• Ошибка-исключение null pointer exception
• Деление на ноль
• Превышение максимального количества передаваемых файлов
• И подобные «типичные пользовательские» ошибки

Итак, цель предугадывания — найти ошибки, которые трудно “выловить” другими методиками черного ящика. Готовятся тест-кейсы, направленные на области наиболее вероятных ошибок; по возможности покрываются все проблемные места; но без избыточности.

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

Что нужно, чтобы хорошо угадывать ошибки

• Интуиция тестировщика
• И его знание продукта
• Опыт прошлых проектов
• Чек-лист
• Риск-репорты 
• Знание типичных проблем с интерфейсом
• Идеальное знание общих принципов тестирования
• Результаты предыдущих тестов
• Характерные ошибки, случавшиеся ранее

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

Пример 1 

В приложении есть функция ввода номера телефона клиента, и он должен быть стандартной длины, то есть 10 цифр. Методика предугадывания ошибок в данном случае может проверить, например:

• Что случится, если ввести не цифру, а букву или пробел
• Если ввести только 8 цифр
• Если оставить поле пустым
• Если ввести не 10, а 12 цифр

Если такие невалидные значения введены, и функция ведёт себя как ожидается — то есть показывает ошибку, она расценивается как не имеющая багов; в противном случае заводится баг, и функция передается разработчикам, чтобы те устранили баг.

Пример 2

Счет на банковской карте настроен так, что принимает только суммы от 5000 до 7000 рублей (так нужно клиенту). Действуя по методике предугадывания ошибок, подбираем значения ввода, пытаясь добиться наибольшего покрытия:

Значение	Результат
6000	ОК
5500	ОК
4000	Ошибка
7200	Ошибка
7400	Ошибка
8000	Ошибка
Пустое	Ошибка
100$	Ошибка
…	…
… и так далее

Преимущества и недостатки методики

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

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

Недостатки

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

***

• Эквивалентное разделение
• Анализ граничных значений
• Переход состояний
• Попарное тестирование
• Предугадывание ошибок

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

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

Что такое тест-дизайн?

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

Зачем нужен тест-дизайн?

Основная цель тест-дизайна — структурировать процедуры тестирования, чтобы было легче отслеживать покрытие требований тест-кейсами. Благодаря тест-дизайну мы:

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

Популярные техники тест-дизайна

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

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

• эквивалентное разделение
• анализ граничных значений
• переход состояний
• попарное тестирование
• предугадывание ошибок

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

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

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

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

Эквивалентное разделение — хорошее решение для случаев, когда вы имеете дело с большим объемом входящих данных или множеством одинаковых вариантов ввода. В противном случае, возможно, имеет смысл более тщательно охватить продукт тестами.

Пример эквивалентного разделения

Допустим, есть интернет-магазин, который предлагает разные тарифы на доставку в зависимости от стоимости корзины. Например:

1. Стоимость доставки для заказов на сумму менее $100 составляет $15.
2. Стоимость доставки для заказов на сумму более $100 составляет $5.
3. При заказе от $300 долларов доставка бесплатна.

У нас есть следующие ценовые категории для работы:

1. от $1 до $100.
2. от $100 до $300.
3. $300 и выше.

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

От $1 до $100:

•  допустимые значения: любая цена в диапазоне от 1 до 99,99
•  недопустимые значения: любая цена ниже 1 или выше 99,99

От $100 до $300:

•  допустимые значения: любая цена в диапазоне от 100 до 299,99
•  недопустимые значения: любая цена ниже 100 или выше 299,99

$300 и выше:

• допустимые значения: любая цена выше 299,99;
• недопустимые значения: любая цена ниже 300.

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

Анализ граничных значений

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

При анализе граничных значений мы тоже группируем данные по эквивалентным классам, но проверяем не значения из определенного класса, а граничные значения — те, которые находятся на «границах» классов. 

Эта логика применяется для интеграционного тестирования. Мы проверяем отдельные элементы во время юнит-тестирования, а на следующем уровне ошибки, скорее всего, появятся на «стыках» юнитов.

Пример анализа граничных значений

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

От $1 до $100:

• допустимые граничные значения: 1,00, 1,01, 99,99
• недопустимые граничные значения: 0,99, 100,00, 100,01

От $100 до $300:

• допустимые граничные значения: 100,00, 100,01, 299,99;
• недопустимые граничные значения: 99,99, 300,00;

$300 и выше:

• допустимые граничные значения: 300,00, 300,01;
• недопустимые граничные значения: 299,99.

Переход состояний

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

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

Пример диаграммы перехода состояний

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

Допустим, мы тестируем систему, которая предлагает ограниченное количество попыток ввести правильный пароль. Если пользователь не введет правильный пароль, система блокирует доступ (временно или постоянно). Логическая схема будет выглядеть так:

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

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

		Пароль верный	Пароль неверный
Состояние 1	Клик на «Войти»	Состояние 5	Состояние 2
Состояние 2	1-я попытка	Состояние 5	Состояние 3
Состояние 3	2-я попытка	Состояние 5	Состояние 4
Состояние 4	3-я попытка	Состояние 5	Состояние 6
Состояние 5	Вход в систему
Состояние 6	Блокировка

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

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

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

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

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

Допустим, есть сеть пекарен, продающих яблочные пироги и чизкейки онлайн. Каждый товар доступен в трех размерах – маленьком, среднем и большом. Пекарня предлагает доставку, как немедленную, так и к определенному времени, а также возможность самовывоза. Пекарня работает в трех городах – Нью-Йорке, Лос-Анджелесе и Чикаго. Также пользователь может заказать до трех товаров одновременно.

Заказ	Размер	Город	Количество	Доставка	Время
Яблочный пирог	Маленький	Нью-Йорк	1	Адресная	Немедленно
Чизкейк	Средний	Лос-Анджелес	2	Самовывоз	К указанному времени
	Большой	Чикаго	3

Если вы захотите протестировать все возможные варианты инпута, у вас  будет 2x3x3x3x2x2=216 комбинаций. Но проверять каждую нет смысла. Вместо этого вы можете выстроить переменные таким образом, чтобы охватить максимум сценариев.

Для этого вам нужно сгруппировать переменные или использовать какой-нибудь инструмент, который сделает это за вас. Например, воспользовавшись Pairwise Tool, мы получили 17 сценариев, способных охватить все 216 комбинаций. Вы можете увидеть список комбинаций ниже.

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

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

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

Как правило, тестировщики начинают с тестирования на распространенные ошибки:

• ввод пробелов в текстовые поля
• нажатие кнопки Submit без ввода данных
• ввод неверных параметров (адрес электронной почты вместо номера телефона и т.д.)
• загрузка файлов, превышающих максимально допустимый размер
• … и так далее.

Чем больше опыта у тестировщика, тем больше сценариев предугадывания ошибок он сможет быстро придумать.

Итоги

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

При создании IT-продукта большую роль играет обеспечение качества – Quality Assurance (QA). Для того, чтобы устранить ошибки и «баги», QA-инженеры в числе прочих инструментов применяют техники тест-дизайна.

Тест-дизайн – это разработка, создание тестов. Каждый тест направлен на проверку конкретного предположения. Например: «Что будет, если пользователь по ошибке кликнет здесь не левой, а правой кнопкой мыши».

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

Типы тестирования 

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

Динамическое тестирование требует проверять ПО в действии. Этот вид, в свою очередь, также делится на две обширные группы: 

• Техники белого ящика (они же структурное тестирование) применяют в том случае, если специалист хорошо знает архитектуру продукта, его код, «начинку» – то есть может ориентироваться в самой программе. 

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

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

Этапы тестирования

1. Подготовка. На этом этапе QA-инженер читает проектную документацию, выясняет требования к продукту, прорабатывает план, продумывает стратегию, расставляет задачи по приоритетности и анализирует возможные риски. 

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

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

3. Анализ результатов и составление отчетов.  

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

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

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

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

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

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

У нас есть четыре возрастных группы: младше 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.       Правильный логин и правильный пароль.
2.       Правильный логин, неправильный пароль.
3.       Неправильный логин, правильный пароль.
4.       Неправильный логин, неправильный пароль. 

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

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

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

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

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

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

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

Pairwise testing: пример 

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

№	Браузер	Операционная система	Язык
1	Opera	Windows	RU
2	Google Chrome	Linux	RU
3	Opera	Linux	EN
4	Google Chrome	Windows	EN

При составлении матрицы принятия решений для двух браузеров, двух ОС и двух языков было бы нужно 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. Малое покрытие тестами. 

Итоги

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

Привет, Хабр! Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться). При этом, чтобы статья не казалась слишком громоздкой, информация будет представлена без излишней детализации, как необходимая и достаточная для прохождения собеседования (согласно моему опыту), рассчитанное на стажеров/джунов (как вариант, эта информация может быть для общего понимания полезна ИТ-рекрутерам, которые проводят первичное собеседование и попутно задают некоторые около-технические вопросы).

---

ОСНОВНЫЕ ТЕРМИНЫ

Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:

1. планированием работ (Test Management)

2. проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.

3. выполнением тестирования (Test Execution)

4. анализом результатов (Test Analysis)

Основные цели тестирования

• техническая: предоставление актуальной информации о состоянии продукта на данный момент.

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

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

Следует уметь различать, что:

• Error — это ошибка пользователя, то есть он пытается использовать программу иным способом (например, вводит буквы в поля, где требуется вводить цифры). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).

• Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.

• Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).

Жизненный цикл бага

Атрибуты дефекта

• Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.

Градация Серьезности дефекта

• Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.

НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА

1. Эквивалентное Разделение (Equivalence Partitioning) — это техника, при которой функционал (часто диапазон возможных вводимых значений) разделяется на группы эквивалентных по своему влиянию на систему значений. ПРИМЕР: есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.

2. Анализ Граничных Значений (Boundary Value Analysis) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных. Если брать выше ПРИМЕР: в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

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

4. Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.

5. Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).

6. Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

7. Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.

8. Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить общее количество тест-кейсов. Используется для тестирования, например, фильтров, сортировок. Этот интересный метод заслуживает отдельного внимания и более подробно рассматривается в статье по ссылке (в конце которой упоминаются инструменты для автоматизации применения PT).

9. Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.

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

ВИДЫ ТЕСТИРОВАНИЯ

Классификация по целям

• Функциональное тестирование (functional testing) рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом, т.е. проверяется корректность работы функциональности приложения.

Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.

Классификация по позитивности сценария

• Позитивное — тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.

• Негативное — тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции.

Классификация по знанию системы

• Тестирование белого ящика (White Box) — метод тестирования ПО, который предполагает полный доступ к коду проекта, т.е. внутренняя структура/устройство/реализация системы известны тестировщику.

• Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).

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

Классификация по исполнителям тестирования

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

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

Классификация по уровню тестирования

• Модульное (компонентное) тестирование (Unit Testing) проводится самими разработчиками, т.к. предполагает полный доступ к коду, для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде, проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).

• Интеграционное тестирование (Integration Testing) направлено на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое, т.е. проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

Подходы к интеграционному тестированию

• Системное тестирование (System Testing) — это проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования и т.д., и оцениваются характеристики качества системы — ее устойчивость, надежность, безопасность и производительность.

• Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема.

Классификация по исполнению кода

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

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

Классификация по хронологии выполнения

• Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок, т.е. проверяется исправление багов.

• Регрессионное тестирование (regression testing) — это тестирование после внесения изменений в код приложения (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям, т.е. проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвали новых багов.

• Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.

ДОКУМЕНТАЦИЯ

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

Основные атрибуты требований:

• Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.

• Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.

• Недвусмысленность — требование должно содержать однозначные формулировки.

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

• Приоритетность — у каждого требования должен быть приоритет (количественная оценка степени значимости требования).

Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:

• Что нужно тестировать?

• Как будет проводиться тестирование?

• Когда будет проводиться тестирование?

• Критерии начала тестирования.

• Критерии окончания тестирования.

Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.

Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.

Чек-лист (check list) — это документ, описывающий что должно быть протестировано. На сколько детальным будет чек-лист зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта. Чаще всего, в ЧЛ содержатся только действия, без ожидаемого результата. ЧЛ менее формализован, чем тестовый сценарий.

Тестовый сценарий (Test Case) — это документ, в котором содержатся условия, шаги и другие параметры для проверки реализации тестируемой функции или её части.

Атрибуты тест кейса:

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

• Шаги (Steps) — cписок действий, переводящих систему из одного состояния в другое, для получения результата.

• Ожидаемый результат (Expected result), на основании которого можно делать вывод о удовлетворении поставленным требованиям.

• иногда используются Постусловия (PostConditions), как некоторое напоминание для перевода системы в первоначальное состояние, как до проведения теста (initial state)

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

Отчёт о дефекте (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе функциональности.

---

Огромное спасибо @alexlobach и @Gennadii_M за статьи! Большая часть информации взята именно оттуда.

UPD: статья пополняется. Спасибо @yakoeka

Спасибо большое всем за фидбэк, благодаря которому материал обновляется и дополняется

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

• Что такое техника угадывания ошибок?
• Как применять технику угадывания ошибок?
• Когда использовать технику угадывания ошибок?
• Подводные камни техники угадывания ошибок

Что такое техника угадывания ошибок?

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

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

Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туторилов, задач по автоматизации и книг по QA.

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

Как применять технику угадывания ошибок?

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

Как приложение работало в прошлом?

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

Какие ошибки допустимы?

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

Какие сбои происходили в других приложениях?

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

Давайте разберемся в этом на простом примере:

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

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

99, 100, 101, 500000, 99999, 100000, 100001.

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

Когда использовать технику угадывания ошибок?

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

Техника угадывания ошибок будет эффективна, если

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

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

Подводные камни техники угадывания ошибок

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

Перевод статьи Faisal Khan «Error Guessing».