Возвращаясь к книге Ли Копланда, вспомним еще раз о таблицах принятия решений. Этому материалу традиционно уделяется мало внимания, хотя использование этой методики позволяет значительно упростить написание тест-кейсов и сэкономить время.
Методика состоит в следующем. Создается таблица, названиями столбцов будут комплексы бизнес-правил, а названиями строк - исходные условия, при которых эти бизнес-правила должны выполняться. Далее располагаются строки, содержащие действия. Каждое правило определяет комбинацию условий, которым соответствуют бинарные значения, 0 или 1, в зависимости от того, выполняется условие или нет. Условия могут быть более сложными, содержать математические выражения.
Действия не зависят от порядка, в котором они записаны, и зависят только от определенных условий, а не от любых предшествующих условий и состояний системы.
Тестировщикам в таком случае нужно проверить, что все комбинации условий системы учтены, что нет пропущенных условий, при которых система не будет знать, какое действие ей выполнить. Выглядеть это будет, как будто система зависла и к ее интерфейсу не будет доступа. Мы не сможем выполнить никакое действие.
Каждое сочетание бизнес-правил запускает определенное действие. Действия могут быть не уникальными для отдельных правил, т.е. для нескольких правил может выполняться одно и то же действие.
Почему же их тогда не объединить в один набор?
Дело в том, что условия для выполнения этих действий могут быть различны для разных наборов бизнес-правил.
Действие может запускать один или несколько модулей программы последовательно, в зависимости от бизнес-логики приложения.
Если в качестве условий указаны диапазоны значений, то в каждом диапазоне выбирается одно из значений, в соответствии с техникой классы эквивалентности. Каждый столбец соответствует одному тест-кейсу. Условия в столбце будут предусловиями, а действия будут ожидаемыми результатами, которые выполнит система при выполнении предусловий.
В случае, если не все условия являются важными, таблица может быть упрощена. Это также упростит код программы, но тестировщикам нельзя использовать оптимизированную таблицу, т.к. в этом случае возможны ошибки, допущенные во время оптимизации, либо условия, которые на данном этапе разработки программы являются неважными и могут не учитываться, в будущем станут значимыми, но исправить уже будет ничего нельзя. Поэтому тестировщики, для приложений со сложной бизнес-логикой, используют первоначальные неоптимизированные таблицы.
Подпишитесь, если для Вас важно разобраться в многочисленном теоретическом материале по тестированию и приобрести необходимый опыт и практические знания.