Это шестой вебинар из цикла бесплатных вебинаров по автоматизации тестирования.
Видеозапись (продолжительность 1 час 16 мин.):
Темы и детали видеозаписи под катом
Это шестой вебинар из цикла бесплатных вебинаров по автоматизации тестирования.
Видеозапись (продолжительность 1 час 16 мин.):
Темы и детали видеозаписи под катом
Не рекламы ради, я не имею никакого отношения к данной игре.
Если вас заинтересовала кооперативная игра Warframe, но вам не удалось получить, заветный, ключик на ЗБТ — эта тема для Вас.
MMOBomb.com вместе с Digital Extremes устроили раздачу ключей на закрытый бета-тест Warframe.
Как получить ключ:
Читать полностью »
В практике юнит-тестирования часто возникает желание сделать несколько Assertion'ов в одном тест-методе. В теории же, такой подход критикуется с двух основных позиций. Во-первых, семантически, один тест должен проверять только один кейс, не разрастаться. Во-вторых, при падении одного из Assertion’ов в цепочке, выполнение теста прервется и мы увидим сообщение об ошибке лишь от него, а до всех остальных дело не дойдет, что не даст наиболее полной картины произошедшего. Первый аргумент безусловно резонен и при написании тестов его всегда следует держать в голове, но фанатичное следование этому принципу зачастую не представляется разумным (пример далее). Устранению же второй проблемы посвящен этот пост. Будет представлен небольшой класс, позволяющий просто и лаконично обеспечить исполнение нескольких Assertion’ов без прерывания выполнения метода и с выводом сообщения об ошибке каждого из них.
Читать полностью »
Привет!
Год назад разработали под свои задачи сервис который позволял нам хранить файлы (со всеми примочками файловых хранилищ) и прямо из хранилища создавать для файлов виджеты, делать удобные линки на файлы, которые мы добавляли на корпоративные сайты, статистику для отслеживания жизни виджетов и еще незначительный функционал, который нам был нужен.
Весной, в Калифорнии, пообщавшись с множеством предпринимателей решили (видимо воздух у них там такой) сделать публичный сервис, который бы давал возможность человеку управлять своими файлами непосредственно из своего хранилища. Проблему вы знаете — контента много, что с ним делать не всегда ясно. В Долине в одной компании нам сказали, что они уже не контролируют на каких сайтах и что они публиковали.Читать полностью »
Маленькое предварительное замечание: Подробное объяснение потребовало бы объёмов средней книжки. Тут всё дано схематично, кратко и без подробностей. Текст, конечно, хулиганский, но прежде чем наезжать на автора, стоит учесть, что за ним стоит двадцать лет опыта и много-много литературы как классической, так и специалистам ИТ не ведомой.
Есть слово, приносящее индустрии каждый год огромные убытки. И слово это — bug.
Баги — это некие виртуальные вредоносные жучки, прячущиеся внутри программ. Они обладают собственной волей. Они проникают в самые важные участки. Они портят результаты, прерывают выполнение работы и делают другие гадости.
Конечно, это бред, если смотреть правде в глаза. Но, если вывести ментальную модель из того, что делают и говорят программисты, как раз получаются виртуальные живые существа, которых ищут, ловят, выявляют и уничтожают.
Массовая глобальная нескончаемая игра, которой увлечённо предаются практически все работники отрасли, включая тестеров, менеджмент, организаторов процессов и высоколобых теоретиков.
Почему так происходит? Потому что в индустрии совершенно превратно понимают, что такое исходный код и для чего он нужен.
Если опросить специалистов, мы получим сотню разных мнений. Но в сухом остатке, если отбросить всю шелуху, код выступает плодом творческих усилий и выражением гениальности автора. В стандартной ситуации и при любом фактическом уровне профессионализма программист воспринимает себя почти святым гением, создающим почти идеальный продукт.
Если сделать программиста не идеальным, получается одна интересная штука: код перестаёт быть готовым результатом. Он даже перестаёт быть результатом. И становится отражением текущего понимания программистом условий поставленной задачи и способов её решения.
Код именно отражает, а не описывает. Последнее возможно, но требует перестройки всего процесса, от форматов записи до мозгов.
Мозги критичны. Нужны люди особой культуры, не боящиеся выглядеть дураками, каких в ИТ практически не встречается.
Писать и говорить то, что думаешь, — это всегда отсутствие такта, презрение к окружающим и хамство. Если кто-то ставит в своём коде комментарий «Stupid idea. Does not work, if N < 0. Correct ASAP.», он рискует прослыть минимум странным. А вот если это попадёт в участок ответственности гениального программиста, тут уже мелкой истерикой не ограничится. Даже, если «stupid» будет подразумеваться только по контексту. Или напишите в комментарии что-нибудь типа «I do not know why this works, but otherwise the function generates an exception.» Потом покажите это начальнику и попросите повышения.
И, конечно, гораздо выгоднее говорить «Мы исправляем баги в коммуникационном модуле», а не «Читая документацию мы прошляпили несколько критических моментов и неделю будем всё с нуля переделывать.»
Ладно, оставим. Большинство такого не выдерживает. Страшно. И ронять чувство собственного достоинства тоже страшно. И лицо потерять… И начальство тоже… Короче, фиг с ним, перейдём к плюшкам.
Очень не хватало возможности ввести пользователей в контекст перед голосованием. Спасибо! И так
Работая со старым унаследованным кодом, порой встречаются достаточно проблемные участки, которые есть желание переписатьисправитьпеределать, но нет такой возможности. Этот код может быть с ошибками, которые не исправляются годами и с ними приходится мириться. Что делать с таким кодом?
Читать полностью »
Sikuli — это API позволяющая писать на Jython сценарии автоматизации опираясь на визуальную составляющую любой программы/сайта и т.д. Особенно приятна для автоматизации Flash.
О Sikuli написано мало статей и большинство из них обзорные. Ещё меньше русскоязычного хелпа, и ещё меньше примеров кода. И отсутствие последнего пожалуй самое трагичное для тестировщика ПО который столкнулся в работе с необходимостью автоматизировать какой либо флэш. Как раз это и подтолкнуло меня написать более ёмкую статью по Sikuli и описать несколько подробнее некоторые особенности использования.
Современные подходы к разработке программного обеспечения делают большой упор на контроль качества. Теперь недостаточно, как раньше, просто писать код, нужно убедиться в том, что этот код правильно написан.
Уже сложно найти проект, в котором отсутствуют юнит-тесты. Их использование многим кажется избыточным, ведь это трата времени, которое с тем же успехом можно потратить на написание другого кода и “не, ну я точно знаю, что там все правильно”. Но, как мы убеждаемся, в долгосрочной перспективе тесты экономят больше времени, чем отнимают. Облегчается сопровождение кода, рефакторинг становится безопасным, отслеживается правильность любых изменений. Причем, чем выше покрытие — тем сильнее чувствуется полезность тестов.
Соответственно, важным моментом является анализ этого самого покрытия, причем желательно построчно, чтобы видеть, какие участки кода не тестируются и иметь возможность быстро исправлять ситуацию.
Вопрос калибровки цветного принтера часто ставится довольно жёстко, так как качество печати в цвете может довольно сильно зависеть от того, насколько хорошо откалиброван принтер. Калибровка большинства цветных принтеров заключается в выполнении двух автоматических операций по настройке цветов:
Читать полностью »
Только что, в группе Steam for Linux появилось объявление о событии, которого все так долго ждали: клиент Steam для Linux теперь в стадии открытого бета-тестирования. Все, кому до сих пор не пришел инвайт теперь могут совершенно свободно и без хаков запускать клиент.
Читать полностью »