Home

 Автор: Кристин Джеквони (Kristin Jackvony)

Оригинал статьи
Перевод: Ольга Алифанова

В этой части моего цикла статей про логические ошибки я разберу ошибку ложной дихотомии. Эта ошибка возникает, когда два противоположных варианта предлагаются, как единственно возможные; альтернатив не существует. Это отрицательно влияет на прогресс, так как ограничивает мышление людей; они чувствуют, что должны выбрать или одно, или другое. В тяжелых случаях это приводит к тому, что люди опасаются высказывать свое мнение, чтобы их не приписали к «неправильной» стороне в споре. А недалекие люди будут неспособны объективно оценить обе стороны проблемы.

В современном обществе множество примеров ошибки ложной дихотомии – возьмем ту, которую совершили пару десятилетий назад. В 1990-х существовал феномен, известный, как «Войны мамочек». Это дискуссия о том, должны ли матери оставаться днем с ребенком, или же идти на работу и отдать детей в детский сад. Обе стороны конфликта были крайне поляризованы – мамы-домохозяйки цитировали исследования, демонстрирующие, что дети процветают, находясь дома с матерью, намекая, что работающие матери не стремятся к лучшему для своих детей. Работающие мамы, в свою очередь, цитировали исследования, демонстрирующие, что неработающие матери не реализуются профессионально, намекая, что желание оставаться дома вредит движению за равенство женщин.

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

В области тестирования есть две очевидных ложных дихотомии. Первая – это дебаты «Ручное VS автоматизация». Я уже писала об этом, изложу тут кратко, почему этот спор просто смешон:

• «Ручное» и «автоматизированное» - очень условные обозначения. Автоматизация возможна как часть ручного теста (например, скрипт для создания пользователей), а ручное тестирование – как часть автоматизированного теста (визуальная проверка после прогона скрипта).
• Что-то лучше тестировать скриптами – например, проведение нагрузочного теста, - а что-то ручным способом – например, поездка на машине с мобильным телефоном для проверки, что сервисы локации GPS верно работают.

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

Вторая ложная дихотомия в тестировании – это дебаты, нужны ли нам вообще тестировщики. Некоторые команды разработки убеждены, что все их тестирование могут проводить разработчики, а тестировщики не нужны; другие команды убеждены, что тестированием должны заниматься тестировщики, и тестировать свой код – не задача для разработки. Я уверена, что оба варианта ошибочны и потенциально вредят делу. Когда разработчики пытаются полностью взять на себя тестирование, они могут упустить важные баги, вызванные взаимодействием двух разных областей ПО. А если они вообще не тестируют, то могут создать забагованное приложение, замедляющее прогресс команды, пока тестировщики логируют все больше и больше багов.

Тестирование ПО наиболее эффективно, когда вся команда сконцентрирована на качестве. Как это выглядит? В разных командах ситуация может различаться, но вот ряд примеров:

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

Страдает ли ваша компания от ошибки ложной дихотомии? Если это так, поработайте совместно с оппонентами над новыми изобретательными решениями.

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