Разделы портала

Онлайн-тренинги

.
Логические ошибки для тестировщиков, часть 8: циклические рассуждения
02.11.2023 00:00

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

На этот раз мы продолжим изучать логические ошибки на примере Циклических Рассуждений. Циклические рассуждения можно объяснить так:

  • X верно, потому что верно Y.
  • Y верно, потому что верно X.

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

Вот пример: ваш сосед настаивает, что вести машину на скорости 55 миль в час – это опасно. Когда вы просите ее доказать, что это опасно, она говорит, что это запрещено законом. Рассмотрим два утверждения:

  • Вести машину на скорости выше 55 миль в час запрещено, потому что это опасно.
  • Опасно вести машину на скорости выше 55 миль в час, потому что это запрещено.

Циклические рассуждения в действии!

В тестировании циклические рассуждения тоже встречаются. Рассмотрим два утверждения:

  • Все наши автоматизированные тесты проходят, потому что наша фича правильно работает.
  • Мы знаем, что наша фича правильно работает, потому что все наши автоматизированные тесты прошли успешно.

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

Я получила этот урок несколько лет назад, когда только начинала писать JavaScript-тесты. Я очень гордилась тестами и тем, что они срабатывают, пока разработчик не попросил меня создать условие, когда проверяемое значение было неверным. Я была страшно удивлена – мой тест все равно сработал!

Я не знала, как работают промис в JS. Когда я думала, что проверяла наличие значения на странице, то на самом деле проверяла присутствие промис значения на странице. Мне пришлось добавить логику async/await, чтобы увидеть падение теста там, где он должен был упасть.

Чтобы избежать циклической логики, непременно оспаривайте свои допущения. Спросите себя – откуда я действительно знаю, что это работает? Тестируйте свои автотесты: каждый должен падать при наличии условия, которое должно вызвать падение. И не доверяйте метрикам слепо. Заройтесь в данные и проверьте, что метрики измеряют именно то, что, по мнению команды, они должны измерять.

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

Обсудить в форуме