Доброй ночи!
Коллеги, а расскажите какие у вас были самые курьёзные фейлы тестов?
Например, тест не фейлился, хотя фича совсем не работает.
Либо тест фейлится, хотя руками все проходится без проблем. Что-то что больше всего запомнилось)
Самый-самый epic fail, на расследование которого потратили много времени)
Мы тестировали очень крупное «коробочное» десктопное приложение, с необъятным количеством строк кода на C++ под Windows.
В один прекрасный день, после трех сотого авто-теста, на сохранении пользовательского профиля, приложение просто крэшелось, иногда оставляя за собой дамп-файл крэша, а иногда и нет.
Интересно, что воспроизводилась ошибка только при прогоне авто-тестов, а руками ни один из самых крутых мануальщиков воспроизвести не мог.
Программисты, читая дамп файлы, не могли ничего понять:
крэш возникал при попытке чтения из ячейки памяти… которая не принадлежала приложению… из кода… который не могли найти в самом приложении.
В итоге, все дружно заявили: «Это все ваша автоматизация виновата», но баг решили держать открытым.
Заставили ещё гонять тесты на специальной, Debug версии… но как мы не старались, в Debug-билде ошибки не было.
Так продлилось ещё некоторое время, пока на стадии бета-тестирования, один из пользователей не сообщил о такой же проблеме при сохранении пользователя.
Тогда, программисты взяли тот же бил от пользователя… и написав API тест, который в цикле 500 раз сохранял пользователя, все таки воспроизвели проблему.
Собрали Debug версию того же билда. Прогнали тот-же тест… и…
не воспроизвели.
А причиной проблемы было ПО, защищающее приложение от копирования – Armadillo.
После сборки, приложение патчилось этим ПО.
Ошибка возникала в Armadillo, и он (оно) заодно и крэшал наше приложение.
Хорошо, что ошибку удалось исправить в момент беты.
Отозвать диски с релизом и простой полок в магазине обошёлся бы дорого.
С того времени, крэшам и непонятным ошибкам, которые иногда находила автоматизация, начали чуть-чуть больше прислушиваться.
Про “самый-самый” говорить трудно - и много всякого бывало, и “самый-самый” часто “контекстное” понятие. Обычно “самый-самый” в неделю, итерацию, спринт, а не в период всей творческой тестерской жизни 
А зелёное когда надо красное (нет проверки) и красное, когда надо зелёное (программеры что-то резко поменяли) - это вообще в порядке вещей.
Мне припоминаются случаи проблем, когда их быть не должно.
К примеру, приложение: визард на .NET, в собственной остнастке в MMC 3.0. На некоторых шагах визарда есть поля ввода с автодополнением. Поля ввода самые обычные, но там навёрнуто много кода между UI и API. Когда помещаешь текст при помощи UI Automation, приложение крэшится. UI Automation активирует другое событие, но это не проблема. Автодополнение - не проблема. В итоге, программеры не смогли разобраться (если скопировать форму в новый проект - всё работает), решили через вывод окна в фокус и сендкейс в эти два текстбокса.
Подобный же случай - часто падает визард одного сетапа (только одного) на шаге Installing. Тест просто нежно проверяет наличие контрола на форме и спит дальше - это медленный шаг. Скорее всего, форма периодически уходит в бэкграунд и тест попадает в неурочный час. Руками никто визард не трогает в момент установки, посему это и не баг.
Но времени занимает регулярно - то шаг становится медленнее, когда продукт меняют, то настоящие баги мешают. Время от времени приходится этот тест трогать - должна же быть и user-side проверка сетапа.
А вот припоминается успех, много лет назад. Дльлька C++ в приложении, которое копирует большие объёмы файлов с сохраниением иерархий, пермиссиями, между разнообразными серверами (эта история была на Windows-Windows копировании), с кастомизациями пермиссий, файловых иерархий и т.д. Сотрудник жаловался, что копирует медленно - интуитивно казалось, что медленно. Решили проверить на объёмах. Я накорябал утилитку для генерации файлов на Win32 (самый обычный цикл на C++ с созданием иерархий) и нагенерили что-то за сорок миллионов фалов. И нашли! ТАКИЕ объёмы копировались медленнее, чем через Windows Explorer (а должно быть побыстрее). Оказалось, что про программер написал цикл обхода (не помню, что там делалось, пермиссии, атрибуты или логгинг), прикол был в том, что точно такой же цикл обхода УЖЕ был написан год назад. Цикл в цикле работал помедленнее и на сорока миллионах файлов разница с Проводником уже была заметна. 
Вот так через акцептанс тест, наполовину ручной, сделали код ревью :)
А у меня было так… (то что вспомнила из последнего…)
Я несколько месяцев назад покрывала тестами так называемую “коробку удачи” - коробку с случайными предметами. Принцип такой: покупаешь коробочку, а в ней может быть обычный предмет, а может выпасть что-то эксклюзивное. Тест заключался в том, чтоб проверить, что если я выиграла предмет и потом его сносила - то я смогу его починить.
Steps:
1. Дала денег на одну “коробочку удачи”- купила.
*- > Если попался не ломающийся предмет - даю денег на новую 1 коробочку и снова покупаю…
Если попался подходящего типа предмет - прекращаю покупку.*
2. Изнашивала предмет (чтоб он грубо говоря сломался)
3. Чинила предмет
4. Проверяла целостность предмета после починки.
Тест успешно написала, засабмитила и забыла про него.
Прошло больше месяца и тест начал периодически падать на ремонте.
Я начала подозревать что-то неладное, но причину понять не могла. Тест падал примерно 1 раз из 15-20 прогонов.
Каково было моё удивление, когда я увидела, что забыла дать себе денег на сам ремонт.
То есть предмет не чинился, потому что на это не хватало денег. А тесты так редко падали и стабильно работали поскольку с коробки удачи часто подарком было бабло)). Этих “подарочных” денег мне и хватало на ремонт так долго.
Это да. Защита часто приводит к таким ситуациям.
У меня крупной проблемы с дампами не было как у @dzhariy, но помню я занимался разработкой автотестов в большой организации и там были постоянные проблемы с выяснениями правильных ожидаемых данных.
Суть проблемы была в том, что тест был написан и прогонялся по 3-4 раза в день, но падал тест один раз на 2-3 прогона. Система состояла из большого количества подсистем и команд, которые успешно играли в “пинг понг” с моей проблемой. Проверки удалять нельзя было, а для того чтобы выяснить кто виноват и почему один и тот же тест с одинаковыми данными то проходит то падает, ушло где-то неделю.
А еще мне из интересного, припоминается один немецкий проект по автоматизации, который я делал. Тут нюанс был больше в людях чем в автотестах. В общем, моя команда написала автотесты, передали автотесты на приемку заказчикам, а там как началось жесткое ревью, которого в жизни не видел:
Такое code review с особой немецкой педантичностью было у меня один раз в жизни После этого, как то начал очень сильно к этому присматриваться. Так как после такого code review пришлось пройтись по всему коду и исправить все замечания.
А на чём тесты были?
Если ты за немецкий проект говоришь, то на webdriver + grails + groovy
Ага, за него
Не знаю, почему такие фейлы можно назвать смешными, но, когда у тебя всё работало, а потом, вдруг, перестало, да так, что сыпятся ошибки, решения которых в интернете тебе не помогают ничем, в сам момент этих фейлов я бы их не назвал курьёзными. Хотя, по прошествии времени, мнение меняется в лучшую сторону 
.
Мой пример:
Есть web-приложение для банковских расчётов, всё - на Java (back-end) и на JavaScript (front-end). Автоматизация - часть проекта, на WebDriver. Никакие библиотеки руками устанавливать нельзя (Американский БАНК!), есть собственное, многократно проверенное на безопасность, хранилище, куда “смотрит” Maven. Так вот, работала автоматизация UI, работала, а потом “хоп!” и перестала. Я по ошибкам бегаю, гуглю решения, не подходят варианты решения, никакого улучшения.
Я проверил код, стал проверять компоненты и заметил, что у одной из либ вэбдрайвера версия немного отличается “вниз”. Я лезу в pom.xml , смотрю - всё норм, версия указана верно, думаю - глюк проекта, сидел, искал решения. Не нашёл. Девелоперы вокруг прикалывались, что “уличная магия”. Я одного из них привлёк, когда надоело впустую ковыряться самому, и вот что обнаружилось: какая-то нехорошая(ие) голова(ы) американского(их) админа(ов) додумалась(ись) изменить кое-что в хранилище…
Итого, у меня была ссылка на “нормальную” версию, а в самом хранилище товарищ (читай - “редиска”) взял и применил… релокацию. А я тогда вообще не знал, что он есть, этот механизм релокации в Maven. Я, значится, обращался в одно место, а мой запрос перенаправлялся в другое, на более “старую” версию, которая и начинала в проект “подсасываться”, из-за чего проблемы и были.
Вот он, “корень зла”:
http://maven.apache.org/guides/mini/guide-relocation.html
История скорее банальная, но отголосок её в презентацию попал 
Сборки промежуточных релизов iOS приложения проходили обязательную проверку скриптом по методу “обезьяньего тестирования”, т.е. случайного тыка. После очередной большой переделки и коммитов, приложение стало на “обезьяньем тесте” валиться. По stacktrace разработчики ничего не могли сказать, а ошибка повторялась раз за разом, но далеко не сразу. Чтобы показать им наглядно, что собственно произошло, на дисплей Макинтоша на котором в iOS Simulator гонялся тест, была аккуратно наведена веб-камера, подключена к соседнему ПК, на который поставлена программа для видеозаписи, и всё это оставлено на ночь.
По приходе утром, запись была просмотрена, и действия “обезьяны” перед падением приложения были продемонстрированы разработчику буквально в покадровом режиме. Причиной оказалось быстрое переключение рядом стоящих пунктов меню, — что для случайного теста, в общем, редкое попадание (представьте себе, какова вероятность сделать два рядом стоящих клика в два рядом стоящих пункта меню, которое занимает далеко не самую большую область экрана).
Вот тогда я и увидел вытаращенные глаза разработчика, и услышал “знаменитую фразу” “Да ни один живой пользователь никогда в жизни…!!!11111”, которую вспоминал потом в выступлении на ATDays.
Некоторые, слыша о видеозаписи “обезьяньего теста”, смеются, но это работает.
Вторая история про “слава роботам”.
Новая сборка сложного веб-приложения портального типа, состоящего из разных серверных подсистем, тестирующаяся вручную, перестала впускать пользователей. Чтобы выяснить, когда логин заработает снова, на коленке был написан логин-автотест. При очередном запуске тест сработал, пользователь залогинился.
Ура, починили!
Попробовал залогиниться вручную, — логин не работает, зависает.
Запустил еще раз автотест, — логинится.
Попробовал еще раз вручную, — зависает.
Блин, да в чём же дело, почему Webdriver заходит, а я нет?
Проверки на настройки прокси и пр. результата не дали. Загадка оставалась. Тогда я начал смотреть проблему в Network monitor Chrome Developer tools. Оказалось, что при попытке входа вручную не проходит запрос к серверному сервису авторизации, так как браузер не доверяет его SSL сертификату. Но для Webdriver такая проблема почему-то вообще не стояла, — он не обращал внимание на то, что у сервиса самоподписанный сертификат, и спокойно им пользовался. После ручного импорта сертификата в Trusted root проблема была снята, и ручной вход заработал, но поиски причины проблемы всё же заняли довольно много времени.
Почти всё понятно, но, простите, мой мозг не в силах составить картинку при чтении текста
Поясните, плиз. Уж больно разгадка интересна
Примерно 6 лет назад я тестировал антивирусный link-cheker (проверка сайта на вирусы перед его загрузкой в браузер). Для этого я написал вспомогательного робота, который рандомно ходил по сайтам и оставил его на ночь. Каково же было мое удивление, когда утром я обнаружил в логе - больше половины сайтов, по которым ходил робот, была порно-ресурсами. Пришлось объяснять коллегам и админам, что я совсем не собирался составлять базу порно-контента. Зато это была отличная проверка на вирусы.
А ссылки робот откуда взял?
Так тестировали наверное какой-то порно-сайт а там ссылок обычно много
Гы, если только в качестве отправной точки.
Так и есть, но в качестве отправной точки я взял вполне приличный сайт (то ли udaff, то ли fishki). В общем, энтропия интернета на тот момент вполне ясно показывала преобладание порносайтов. Сейчас, наверное, робот упёрся бы в социальные сети.
У меня все было очень, просто. Я только начал работать и попросил разработчиков исправить favicon на какой то из страниц приложения (практически на всех было, а на этой почему то нет). На следующий день, пришел на работу, открыл браузер, авторизовался и меня пробросило на пустую страницу в защищенной части файлов - ах да не совсем пустую, в углу гордо висела favicon - как картинка. Разработчики не глумились, но там был какой то трудноуловимый баг самого Apache
нас похожим образом строили на ревью. мы сначала плевались “не могут по сути ничего сказать, вот и цепляются к форматированию и именам переменных”. А потом привыкли приводить код к этим требованиям, и да, тогда и начали возникать замечания по более глубоким вещам, потому что шелуха убрана и код всей команды смотрится однообразно.
Мне кажется, это как помыть руки, прийдя с улицы - автоматическое обязательное действие.
testomat.io управление авто тестами