• Как и зачем расчитывать ROI для автоматизации
• WebDriver теперь и на VBScript, так что QTP теперь можно скрестить c WebDriver
• Меряем покрытие в Selenium IDE
• Несложный пример реализации Page Object Pattern + WebDriver + Spring
• Как создать первый тест на C# и Specflow (реализация Cucumber для .NET)
• Очередные новости по Selenium №74
• Электронная книга по Web Load Testing
• Совет по WatiN: Как отследить ошибку выполнения JavaScript в строке состояния Internet Explorer
• Паралельный запуск авто тестов на RobotFramework 
• SQA Days10: Доклад Андрей Терехин - Автоматизация тестирования модели разграничения прав доступа
• И еще одни Selenium новости  №75

По моему глубокому убеждению, «ROI для автоматизации» придумали консультанты с дикого запада, которым нечего было считать, и они решили придумать считать Test Automation Return On Investment.

Перед внедрением автоматизации ROI просчитать сложно, потому что существует огромное количество неизвестных факторов и коэффициентов. И в разных статьях и книгах эти факторы и формулы подсчета различаются.

Ну, а после внедрения автоматизации – ROI посчитать очень просто, потому что он бинарный: либо классный либо хреновый.

Введение

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

SOA тестирование – это сочетание проверок сервисов, проверки процессов, TDM и автоматизации UI. Сюда входит также создание таких методов, как непрерывное интеграционное тестирование и виртуализация сервисов.  Команды тестеров должны проверить системы у поставщика услуг и со стороны клиента для обеспечения безошибочного исполнения систем. Тесты также должны быть сгруппированы правильно в регрессионный набор. Ключевым моментом регрессионного набора является обработка данных на основании workflow.

Начиная наше путешествие с проверки в реальных условиях

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

Давайте кратко посмотрим на некоторые из общих проблем, с которыми мы столкнулись в процессе внедрения SOA за последнее время:

SOA приносит некоторые проблемы для команды тестирования тем, что они должны изучить новые технологии, процессы и новые инструменты, которые используются. Многие команды тестирования часто проверяют, смогут ли они продолжать использовать классические инструменты и процессы в новой среде SOA. Но как только они начинают SOA тестирование, понимают, что не смогут продолжать. Давайте посмотрим на некоторые из причин, и вопросы, которые приводят к реализации:

Современные требования к инструменту

• SOA имеет уникальную архитектурную экологию. Могут ли классические инструменты тестировать не-UI компоненты? Могут ли эти инструменты справиться с подпиской на brokers? Могут ли они интерпретировать сообщения, которые идут через ESB?
  
  
• SOA имеет свой собственный набор уникальных протоколов. Может ли существующие инструменты автоматизации обрабатывать такие протоколы, как SOAP, WS-Security и подобные протоколы?
  
  
• Могут ли классические инструменты изолировать ошибку посредством вызовов компонент по Web?