Вопрос в блоге про анализаторы кода для руби. В ответах есть полезные ссылки

Ruby/Python developers rely on tests pretty heavily. In fact, some claim, that tests are the only right way to deal with bugs in your program. This way a tool for automatic error detection might even be considered harmful – just because it can be used as an excuse for not writing tests. So, what kind of job is left for a static analysis tool? Well, detect design flaws, a.k.a. “code smells”. In other words – automatically find subjects for refactoring (a change that does not affect program functionality). This way static analysis tool fits naturally into Red/Green/Refactor cycle. Another possible area where static analysis based error detection can prove useful is security vulnerabilities – it is pretty hard to spot all corner cases up-front (or through exploratory testing), just because security is a complex domain and requires good amount of knowledge and expertise.

Когда менеджеры говорят "Тестирование занимает слишком много времени", они подразумевают "Исправление дефектов займет слишком много времени".

А что бы Джерри Вайнберг написал, если бы его окружили менеджеры, которые отвечают за выпуск ПО, со своими извечными вопросами:

- Зачем нужно тестировать, если это только задерживает выпуск?
- Почему нельзя просто писать софт без ошибок?
- Там уже всё протестировано?
- Почему бы вам просто не взять и протестировать всё, что можно?
- Почему это ваше тестирование такое сложное?
- Почему вы тестируете так долго?

Это же не конкретные вопросы. Это вопросы о вечном, о мироздании, о сути создания ПО.

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

И получилась книга.

Неспешная, "размышленческая" книга.

О многом думается после ее прочтения.

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

Одной из наиболее серьезных проблем при автоматизации функционального тестирования на уровне GUI является высокая чувствительность тестов к изменениям GUI. По-хорошему, подобная ситуация не должна возникать, так как автоматизация подобного рода ставится тогда, когда пользовательский интерфейс более-менее стабилен. Но это идеальная ситуация. В реальности, продукт меняется по всем направлениям и в том числе это касается пользовательского интерфейса. Так или иначе какие-то мелкие изменения имеют место (поле переименовали, переместили, поменяли некоторые идентификаторы) и это уже влияет на работоспособность тестов. Частично, можно реализовать гибкий механизм поиска объектов, на который подобные изменения не повлияют, но в большинстве случаев корректировок самих реализаций тестов не избежать. Соответственно, надо как-то минимизировать трудозатраты на корректировку. Наиболее эффективным решением данной проблемы можно назвать вынесение оконных деклараций во внешний ресурс и использование "псевдонимов". Подобное реализовано в WinRunner ( GUI Map ), QTP, RFT ( в котором есть возможность маппинга и все оконные объекты можно классифицировать как mappable и non-mappable ), TestComplete ( NameMapping и Alias, появившийся в поздних версиях ). Суть подобных решений в том, чтобы некоторому оконному объекту с заданными атрибутами поставить в соответствие некоторое имя, которое и будет использовано для обращения к данному оконному объекту.

Во многих средствах подобный механизм реализован, но существует много различных решений, которые фактически представляют собой некоторую библиотеку с прикрученным тестовым движком. В этом случае приходится пользоваться возможностями языка, на котором эти тесты пишутся. В качестве примера рассмотрим язык Ruby и конкретно его порт под Selenium RC. Почему взят именно Ruby? Во-первых, на Ruby есть еще несколько решений аналогичных Selenium RC и возможности языка, там применимы в той же мере. Во-вторых, Ruby - один из примеров языков интерпретируемого типа, у которого есть возможность динамического формирования и компоновки объектов. Подобные механизмы имеются и во многих других скриптовых языках ( в частности JavaScript ), поэтому Ruby был выбран в качестве демонстрации самой во

У нас есть вспомогательные решения, позволяющие следить за работоспособностью наших тестов, написанных с использованием движка Cucumber. Эти задачи могут быть использованы как локально, так и на сборочном сервере. Например, при каждой операции check-in срабатывает строка rake compile.

Overview Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby. The premise of AOP is that some concerns in an application will cut across the natural object boundaries of the problem domain. Rather than scatter duplicated code in each object to handle the cross-cutting concern, AOP modularizes the specification of which execution points are affected (called join points) and the actions that should be invoked at those points.

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby. The premise of AOP is that some concerns in an application will cut across the natural object boundaries of the problem domain. Rather than scatter duplicated code in each object to handle the cross-cutting concern, AOP modularizes the specification of which execution points are affected (called join points) and the actions that should be invoked at those points.

REVEXPRESS is a test automation framework that enables non-technical users to develop and execute automated tests. It accelerates and optimises test automation through an easy to use interface and greatly reduces the maintenance overhead. It enables organisations to build robust test automation suites using a consistent and proven approach that is more effective than keyword and excel based frameworks.

REVEXPRESS is a standalone application that uses HP QuickTest Professional as the underlying engine and integrates with HP Quality Center. This approach enables us to leverage off the powerful functionality that the HP tools provide as a baseline. Using REVEXPRESS we then build on this functionality to provide a framework and simple approach to develop test automation scripts that is quick and easy.

очень простой пример организации AJAX-запросов

Отличная статья от Баха про pairwise testing

про проекты портирования программных продуктов и роли аналитика итестировшика в таких проектах

тренинги, которые стоит послушать и/или приобрести

Некоторые полезные опции для настройки Firefox.
Плюс метод запуска селениума с кастомным профилем Firefox

Таких отличий всего два: 1. Различие в том, как Proc / Lambda назначает аргументы. Lambda генерирует ArgumentError. Proc отбрасывает лишние, недостающие инициализирует в nil
2. Различие в том, что происходит, когда Proc / Lambda вызовы возвращают внутри вызываемого метода.
Return из lambda не прерывает метод, из которого вызван этот блок. Return из Proc приводит к автоматическому return из метода, в котором Proc вызвали

управление джемами (gems) в Ruby: возможность установки разных наборов джемом, управления версиями и прочие вкусности.

разбор полетов для разных компьютерных столов

обзор неких ключевых вещей:
на что обращать внимание, как описывать ошибку + ссылки на видео Асхата, Дж.Баха и др. гуру

Объясняются особенности блоков и lambda-функций в Руби. приводятся сравнения с Джава и питоном. Много примеров кода и вариантов использования. Плюс стоит почитать полезные комментарии после статьи

Programming Ruby The Pragmatic Programmer's Guide.
rdtool comments formating

писок книнг, рекомендуемых к прочтению. На многие есть ссылки на электронные версии.

Полезная статья из 4-ъ частей с обзором платных и бесплатных плагинов для Excel

Презентация Джеймса Баха на тему, почему вредны тест-кейсы. Основная мысль: если мы хотим глубоко протестировать простую программу или отедельный модуль сложной программы, то надо работать через тест-кейсы. Если же мы хотим найти критичные баги к сложном продукте, то надо тестировать по-другому. Используя методы свободного поиска, сосредотачиваясь на активностях и уелях, а не на тест-кейсах.
Плюс 2 хороших слайда о том, что подразуемавется под тест-кейсом (с десяток совершенно разных вещей)

отличная статья.
Описан мысленный эксперимент по подсчету, чем занимаются тестировщики в течение 2-х дней. Наглядно показано, что количество найденных багов и выполненных тест-кейсов зависит от того, в каком состоянии передан продукт на тестирование.Показано, почему плоха метрика ранжирования тестировщиков по найденным дефектам, и почему метрика по выполненным тест-кейсам еще хуже.
Перевод оригинальной статьи

Отличная статья про рендеринг. Как ускорить отрисовку страницы? На что уходит время при рендеринге? Как он вообще осуществляется.
Влияние css на отрисовку и советы по улучшению
Инструменты для отслеживания, что происходит при рендеринге
Куча полезных ссылок на статьи по оптимизации веб