четверг, 26 апреля 2012 г.

"Везет" мне на IE в последнее время..

Буквально за пару последних дней дважды наткнулся на сообщения типа "Ваш броузер не поддерживается. Используйте IE..". Причем в приложениях довольно нужных: одно - важный интранет-портал (сделан на asp), другое - банковская веб-ориентированная система (написанная на jsp).
Если в случае ASP-шного портала запуск IE действительно помог, то банкиры удивили не на шутку.. Дословно "Ошибка: работа возможна только в IE5 и выше".
Хорошо, думаю, будет вам IE. Windows 7, думаю, IE 9. Хватит? Запускаю. Вижу "Ошибка: работа возможна только в IE5 и выше" Не смешно. На этот раз я выступал в роли не тестировщика, а обычного пользователя. Мне нужен был этот софт!)
Вот так вот. В обоих случаях, наверняка, разработка стоила кучу денег. Живо представляю себе пункт в требованиях к программно-аппаратному "Допускается работа только в IE5 и выше")) Толстые дяди с умным видом месяц согласовывали, потом подписывали, потом денежки перечисляли, потом в конверте часть назад приносили... А на дворе 21 век, а сайт работает только в IE5 , и не никак выше )))
p.s. вот найду на досуге ie5 иль эмулятор и затестирую изделие до... )

Офтопы на software-testing

Хорошо, когда твой профессиональный блог транслируется на такой посещаемый и авторитетный ресурс как, например, software-testing. Ты пишешь, делишься мыслями, рецептами - люди практически сразу это видят и могут дать отзыв о твоей записи, дельный совет и т.д.

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

В общем к чему это я..  Хорошо бы иметь механизм автора влиять на то , будет ли данная конкретная статья опубликована или нет. Сейчас я имею в виду конкретно трансляцию  на software-testing ... Думаю, можно сравнительно легко решить такую задачу. Например, автор добавляет некий код <!--DONTTRANSLATE--> в тело материала, если не хочет данной статьей флудить в ленте, а разрабочики сайта , немного "допиливают" свой транслятор, небольшим парсингом поступающего материала... Если знать точно, как именно происходит трансляция на S-T , то было бы легче "предлагать" и "советовать" и даже "приложить патч", но пока идея лишь в такой форме..

Если кто знает о "велосипеде" , который уже изобретен - буду рад совету )

воскресенье, 8 апреля 2012 г.

Взаимное влияние автотестов

Наиболее распространенной практикой при проектировании системы автотестов является минимизация взаимного влияния тестов между собой.
Для unit-теста "быть автономным" - аксиома. Для комплексных автотестов этот подход не всегда полностью применим. Но в этой статье речь пойдет не об этом.
Я хочу рассказать о способе, который может помочь в принудительном выявлении скрытых до поры до времени проблем в тестах, связанных с их явными и неявными зависимостями друг от друга.

Итак, имеем некоторый набор 4-х фазных тестов, которые время от времени проваливаются из-за недостаточной их изоляции друг от друга.
Это "время от времени" непредсказуемо и всегда не к стати.
Что можно сделать, чтобы выявить скрытые зависимости , от которых хотелось бы избавиться, не затеивая глобальной ревизии и перепроектирования системы автотестов?

Если у вас, как и большинства, тесты запускаются всегда в одном и том же порядке, то можно применить "метод перемешивания" автотестов. Сделав их порядок запуска каждый раз разным.
Чтобы это реализовать, скорее всего, потребуется реализация "перемешивателя" (mixer) списка тестов.
Отмечу, что не всегда можно просто взять и перемешать тесты.

Вот три основных типовых случая:

1. Ваши тесты ДОЛЖНЫ быть автономными согласно принятым у вас принципам автоматизации
Тут вы законно можете ожидать одинаковых результатов в независимости от порядка запуска

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

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

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

Еще важно понимать, что данный метод не выявит сразу ВСЕХ проблемных зависимостей. Но постепенно от запуска к запуску позволит минимизировать их количество.
Так картина будет даже нагляднее..