Cause/Effect, Cause-Effect (CE)

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

● Логическое состояние для каждого эффекта;

● Логическое состояние (истина или ложь) по любой причине;

Граф причинно-следственных связей (Cause-Effect Graph) использует такую ​​модель логических взаимосвязей между причинами и следствиями для компонента. Каждая причина выражается как условие, которое может быть истинным, ложным на входе или комбинацией входных данных компонента. Каждый эффект выражается в виде логического выражения, представляющего результаты или комбинацию результатов для произошедшего компонента (?Every effect is expressed as a Boolean expression representing results, or a combination of results, for the component having occurred). Модель обычно представлена ​​как логический граф, связывающий производные логические выражения ввода и вывода с использованием логических операторов:

● И (AND);

● ИЛИ (OR);

● Истина, если не все входные данные верны («не оба») (NAND);

● Истина, когда ни один из входов не является истиной ("ни один") (NOR);

● НЕ (NOT).

Cause-Effect Graph также известен как диаграмма Исикавы, поскольку он был изобретен Каору Исикава, или как диаграмма рыбьей кости из-за того, как он выглядит.

Граф причинно-следственных связей похож на Decision Table и также использует идею объединения условий. И иногда они описываются как один метод. Но если между условиями существует много логических зависимостей, может быть проще их визуализировать на cause-effect graph.

Syntax testing

Синтаксическое тестирование используется для проверки формата и правильности входных данных в случаях символьных текстовых полей, проверки соответствия формату файла, схеме базы данных, протоколу и т.д., при этом данные могут быть формально описаны в технических или установленных и определенных обозначениях, таких как BNF (Форма Бэкуса - Наура).

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

● Валидные: Проверка нормального состояния с использованием покрывающего набора путей синтаксического графа для минимально необходимых требований (?Testing the normal condition using the covering set of paths of the syntax graph, for the minimum necessary requirements). Иными словами находим возможные варианты значений, допускаемые отдельными элементами определения BNF, а затем разрабатываем кейсы, чтобы просто охватить эти варианты;

● Невалидные: Проверка мусорных условий (garbage condition)* с использованием недопустимого набора входных данных.

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

Check List Based Testing

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

Risk-Based Testing

Тест-дизайн на основе риска можно рассмотреть как часть вида/подхода к тестированию.

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

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

Приоритет любого риска зависит от вероятности возникновения и его воздействия на продукт, то есть от того, насколько серьезным является воздействие: Priority = Probability * Severity.

● Управление рисками (Risk Management) должно начинаться на ранней стадии жизненного цикла, чтобы с рисками можно было справиться на ранней стадии. Категории рисков:

○ Project Risks: бюджет, ресурсы, график, проблемы, связанные с клиентами и т. д.

○ Technical Risks: Технический риск включает риски на этапах проектирования, внедрения, тестирования и разработки. Большинство технических рисков возникает либо на этапе требований, либо во время кодирования, поскольку неясность требований может привести к серьезным рискам во время разработки. Во-вторых, на этапе разработки, если разработчики недостаточно хорошо знакомы с Продуктом, это также может привести к серьезным рискам.

○ Business Risks: Бизнес-риски включают проблемы с бюджетом и созданием проекта, который не соответствует требованиям заказчика, потерю клиента.

● Оценка рисков (Risk Assessment): риск оценивается на основе того, насколько серьезным является воздействие.

● Контроль рисков (Risk Control): Риском можно управлять с помощью трех стратегий:

○ Предотвращение риска (Risk Avoidance): избежание риска - это избежание риска проекта с согласия клиента. Например. Чтобы избежать риска задержки реализации проекта из-за нехватки ресурсов, ресурсы можно оставить на скамейке запасных для замены, если какой-либо ресурс уйдет в отпуск. Объем работ можно сократить, чтобы избежать рисковУ

○ Снижение риска (Risk Reduction): снижение риска включает в себя планирование управления рисками и минимизации их последствий. Например. Чтобы снизить риск, для реализации Проекта следует использовать инкрементальный подход;

○ Передача риска (Risk Transfer): эта стратегия включает покупку страховки или любого компонента, разработанного третьей стороной, чтобы избежать возникновения рисков;

Процесс Risk-based Testing:

Риск идентифицируется и анализируется, т. е. рассчитывается влияние (impact) и серьезность (severity) риска, и принимаются меры в соответствии с приоритетом риска. Как только приоритет определен, начинается тестирование, т. е. создаются объем (test scope) и план тестирования, а затем выполняется тесты.

User Journey Test

User Journey test, как следует из названия, охватывает полное путешествие пользователя по системе. Он охватывает сквозные тесты, из-за которых процент покрытия тестами больше по сравнению с другими методами. Этот метод помогает уменьшить количество тестовых примеров, поскольку тестовые примеры являются исчерпывающими и охватывают большую часть функциональности в одном сценарии. Сценарии написаны для самого сложного путешествия. Тесты взаимодействия с пользователем не связаны с пользовательскими историями (user stories).

User Story Testing (Agile)

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

Exhaustive testing

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

Источники:

● Ли Копланд - “A Practitioner's Guide to Software Test Design”, Главы 3-9

● Test Design Techniques overview

● An Evaluation and comparison of practical results of Combination Strategies for Test Case Selection

● Handling constraints in the input space when using combination strategies for software testing

● State Transition testing

● Classification Tree Method

● Black Box Test Techniques. Cause-Effect Graphing

● Syntax Testing

● Popular Software Testing Techniques With Examples

Доп. материал:

● Тестирование областей определения или классы эквивалентности + анализ граничных значений + pairwise

● James Bach, Patrick J. Schroeder - “Pairwise Testing: A Best Practice That Isn’t”

● Paul Ammann & Jeff Offutt - “Input Space Partition Testing”

● Jeff Offutt & Sten F. Andler - “Combination Testing Strategies”

● Комбинаторное тестирование: примеры с PICT

● Pairwise Testing - Обзор веб инструментов для попарного тестирования

● Cem Kaner - ”Introduction to Domain Testing”

● Шаблон Requirement Traceability Matrix

● Cause-Effect Graph example

● Leadership in test: risk-based testing

Dynamic -> Experience based

Error Guessing;

Предположение об ошибках (EG - error guessing): Метод проектирования тестов, когда опыт тестировщика используется для предугадывания того, какие дефекты могут быть в тестируемом компоненте или системе в результате сделанных ошибок, а также для разработки тестов специально для их выявления. (ISTQB)

Предугадывание ошибки (Error Guessing - EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы "предугадать" при каких входных условиях система может выдать ошибку. Например, спецификация говорит: "пользователь должен ввести код". Тест аналитик, будет думать: "Что, если я не введу код?", "Что, если я введу неправильный код? ", и так далее. Это и есть предугадывание ошибки.

Некоторые факторы использующиеся при Error Guessing:

● Уроки, извлеченные из прошлых релизов;

● Исторические знания;

● Интуиция;

● Тикеты с прода;

● Review checklist;

● Пользовательский интерфейс приложения;

● Отчеты о рисках программного обеспечения;

● Тип данных, используемых для тестирования;

● Общие правила тестирования;

● Результаты предыдущих тестов;

● Знание об AUT (тестируемое приложение);

Исследовательское тестирование (Exploratory testing);

См. в видах тестирования

Ad-hoc testing;

См. в видах тестирования

Attack Testing;

Атака (attack): Направленная и нацеленная попытка оценить качество, главным образом надежность, объекта тестирования за счет попыток вызвать определенные отказы. См. также негативное тестирование. (ISTQB)

Тестирование на основе атак (attack-based testing): Методика тестирования на основе опыта, использующая программные атаки с целью провоцирования отказов, в частности - отказов, связанных с защищенностью. (ISTQB)

Источник:

How Error Guessing Testing Benefit in Software Testing