Таблицы решений, попарное и баг-репорт

Когда условий много, а ещё надо грамотно сообщить о найденном дефекте.

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

Таблицы решений

Когда результат зависит от нескольких условий, легко что-то упустить. Таблица решений раскладывает все комбинации по полочкам. Пример: скидка зависит от «новый клиент?» и «сумма > 1000?».

def discount(is_new, big_order):
    if is_new and big_order:
        return 15
    if is_new and not big_order:
        return 10
    if not is_new and big_order:
        return 5
    return 0


# Проверяем КАЖДУЮ строку таблицы решений
assert discount(True,  True)  == 15
assert discount(True,  False) == 10
assert discount(False, True)  == 5
assert discount(False, False) == 0
print("Все 4 комбинации таблицы решений покрыты")

Вывод:

Все 4 комбинации таблицы решений покрыты

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

Если параметров много (ОС × браузер × язык × тариф), число комбинаций взрывается: 4 параметра по 3 значения — это 81 комбинация. Попарное тестирование (pairwise) опирается на наблюдение: большинство багов вызывается взаимодействием двух факторов, а не пяти сразу. Достаточно покрыть все пары значений — и 81 комбинация сжимается до ~9–10 тестов почти без потери покрытия.

Хороший баг-репорт

Нашли дефект — нужно его внятно описать, иначе разработчик не воспроизведёт. Хороший баг-репорт содержит:

Главное правило баг-репорта: «фактический ≠ ожидаемый» должно быть очевидно с первого взгляда, а шаги — воспроизводимы любым человеком.

Итог

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