Home

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

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

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

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

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

Ошибка скользкого склона встречается и в тестировании. Представьте себе неравнодушного тестировщика, который нашел небольшой баг интерфейса в вашем приложении. Он заводит баг, но не дает ему упасть в бэклог – он настаивает, что баг надо исправить СЕЙЧАС. Логика у него примерно такая: «Если не заставить разработчиков исправить баг прямо сейчас, они будут и дальше игнорировать баги, в том числе более крупные. Затем мы погрязнем в техническом долге, из которого никогда не выберемся, а приложение будет кишеть багами. Наши пользователи оставят нас, и мы вылетим из бизнеса».

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

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

Надеюсь, вам понравилась эта серия статей!

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