Home

Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи
Перевод: Ольга Алифанова

В офисе прекрасный солнечный день, вы пришли туда раньше всех, потому что вы долбаный трудяга; вы схватили огромную чашку крепкого кофе и большой стакан воды, чтобы избежать обезвоживания, сели на свое место и смотрите на старого доброго CI-товарища. Но что же вы видите?! Падение, красную метку, проблему, какой ужас… Но вы знаете, что делать – перезапустить, пересобрать билд, перераскаяться во всех ваших тест-грехах, и спустя 30-90 минут… вуаля, зеленый прогон! (если не помогло, повторяйте все вышеперечисленное, пока не добьетесь успеха; все, кроме кофе, а то схватите передозировку). Знакомо звучит? Да, именно этим заняты ваши коллеги, «исправляющие нестабильные тесты».

Сколько раз вас нужно ударить в одно и то же место, чтобы вы поняли, что это больно?

Честно говоря, иногда эти повторные прогоны напоминают мне мультик о Томе и Джерри, в котором Том снова и снова наступает на лопату, грабли и другие садовые инструменты.

Обращаюсь к вам, о перепрогонщики: если вы идете мимо яблони, и вам на голову падает яблоко, будете ли вы трясти дерево, чтобы добиться еще одного яблока и убедиться, что это и правда больно?

Если срабатывает пожарная сигнализация, остановитесь ли вы поглядеть, не прекратится ли это само по себе, или же срочно эвакуируетесь?

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

Итак, где же кроется настоящая проблема?

Простая математика прогона тестов

«Мы сделали тесты стабильнее, добавив повторные попытки и повторные прогоны» — вот что частенько можно слышать от разработчиков и QA-автоматизаторов.

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

(количество упавших прогонов / общее количество прогонов) * 100

Последняя часть нужна для превращения числа в проценты.

Пример: допустим, ваш тест падает в 10 случаях из 100. Применим формулу: процент отказов = (10/100) = 0,01*100 = 10% (это, на самом деле, очевидно).

Теперь вы добавили в ваш нестабильный тест «повторный прогон», чтобы «стабилизировать» его, и он будет запущен еще дважды. Формула станет выглядеть так:

Процент отказов = 100 прогонов + (10 * 3 для повторных прогонов) или (10/130)*100 = 7,69%.

По сути, вы просто увеличиваете общее количество прогонов, чтобы уменьшить долю в общем количестве, растворяя количество отказов в большом ведре прогонов. Это мошенничество, а не решение!

Ложная тревога и порядок действий

Именно в этом и суть нестабильных тестов – это ложная тревога, сломанная сигнализация, набат, не работающий как следует.

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

Итак, у вас только один разумный вариант – исправить чертов тест. Не можете исправить? Удалите его, баба с возу – кобыле легче.

Для меня тут вообще нет дилеммы, потому что логика тут вот какая:

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

Видите повторяющуюся часть? Исследовать – «любой упавший тест – повод для исследования» (Маарет Пюхяярве), и именно это вам нужно сделать – приложить свой труд, чтобы сделать с этой информацией что-то значимое, а не обманывать себя и коллег.

Тупые оправдашки перепрогона тестов

Наиболее распространенные объяснения для перепрогона тестов:

• Я прогоняю тест повторно, чтобы посмотреть, упадет ли он снова.
  Он уже один раз упал, этого недостаточно? А почему ты останавливаешься, если тест пройдет успешно? Это больше не проблема? Я лучше потрачу время на изучение тонкостей этого теста, раз он падает, а потом срабатывает без видимых причин.

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

• Я перепрогоняю тесты, потому что все так делают.
  Ой, я тебя умоляю! У тебя гордость есть?!

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

• И т. д.

Повторный прогон тестов – ложная, неэффективная, аморальная QA-практика

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

Если мы, как QA/тест-специалисты, должны повышать качество продукта, добросовестно предоставлять заинтересованным лицам или внутренним клиентам подробную информацию о рисках и статусе продукта, то как, то, что вы им лжете, соответствует этим задачам?

Стоит ли приносить в жертву качество, бизнес-успех и свое ценное время, чтобы защищать какую-то выдуманную, поддельную репутацию нас как инженеров-автоматизаторов?

Итак, скажите мне – какое наитупейшее оправдание повторных прогонов слышали вы?

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