Home

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

В прошлый раз я объявила новую тему для моих статей в 2023! Ежемесячно я буду исследовать различные логические ошибки и их отношение к тестированию.

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

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

Тренажер приезжает, и 1 января вы начинаете им пользоваться. К пятому января вы обнаруживаете, что до глубины души его ненавидите. В гостях у приятеля вы попробовали поработать на гребном тренажере и выяснили, что он вам страшно нравится! Но вы уже потратили на велотренажер кучу денег, и чувствуете, что у вас нет выбора – надо продолжать пользоваться. К 13 января вы забили на свое обещание, и велотренажер стал крайне дорогой вешалкой для пиджаков и толстовок.

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

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

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

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

Это занимает много времени, но полный набор автотестов наконец-то склеен и собран. Команда устанавливает ежедневный запуск тестов, но вскоре вскрывается другая проблема: отредактированные тесты нестабильны. Команда тратит много времени, пытаясь разобраться, как сделать их стабильнее, но не находит решения. В результате еженедельно назначается тестировщик, ответственный за мониторинг ежедневных прогонов и ручной прогон всех упавших тестов, а один тестировщик продолжает работать над нестабильными тестами.

Задача сберечь время провалена! Полкоманды теперь тратит время на то, чтобы тесты вообще работали. В этот момент кто-то из тестировщиков предлагает все бросить и поискать другой инструмент. Но команда полагает, что так как столько денег, времени и сил уже потрачено именно на этот инструмент, надо продолжать им пользоваться.

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

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