Новое в IBM Rational

Размещено в: Технологии и подходы/ Technologies and Frameworks по материалам osp.ru - Software

Обновление линейки IBM Rational затронуло инструменты, расширяющие экспертизу заказчиков в разработке собственных продуктов. IBM Rational Systems Architect 11.3.1 предлагает интеграцию с средством управления проектами и портфелями Rational Focal Point, подключение к инструментам измерения производительности IBM Rational Insight, поддержку Open Group Architecture Framework 9, расширенные возможности подготовки отчетов, анализа и принятия решений. В системе управления требованиями IBM Rational DOORS Web Access 1.3 реализован ввод и редактирование требований посредством веб-интерфейса. В инструментарии проектирования и разработки на основе моделей IBM Rational Rhapsody 7.5.1 расширено взаимодействие между командой разработчиков и группой контроля качества, документация проектирования систем, возможности AUTOSAR (Automotive Open Systems Architecture).

В решение SOA-разработки IBM Rational Software Architect for WebSphere Software 7.5.4 добавлен модуль предоставления коммуникационных услуг. IBM Enterprise Verification Management Solution предлагает среду тестирования и моделирования разработки микросхем, в том числе однокристальных систем.

Разработка корпоративных порталов на основе IBM WebSphere Portal

Серия вебинаров «Аналитика для тестировщиков» от Юлии Нечаевой

Размещено в: Семинары и конференции/ Seminars and Conferences, Тестирование ПО/ Software Testing по материалам It4business.ru

Разработка программного продукта начинается с выявления и составления требований. Вторым, не менее важным этапом, является анализ и тестирование требований. И именно мы, тестировщики, лучше всех сможем справиться с этим.

Можно научиться методикам и инструментам работы с требованиями. Но для того, чтобы делать что-то эффективно, нужно в первую очередь понимать цель. И только затем – знать методики. Тестировщик должен уметь работать с требованиями, и он должен делать это также осознанно, как процедуру утренней чистки зубов. А то и более ;-)

 

Бытует мнение, что основная задача тестирования – проверка соответствия разработанного приложения требованиям и поиск ошибок. Но как же часто встречается ситуация, когда сами требования содержат ошибки. Ошибки не функциональные, а логические, ошибки бизнес-логики, недомолвки, двусмысленности.

Когда Филиппа Крухтена спросили, что такое качество продукта, он ответил: «Качество — это соответствие ожиданиям Заказчика/Пользователя».

А что, если ожидания пользователя были поняты неверно изначально? Тогда продукт, даже если он вопреки статистике (теории вероятности) не содержит ни одной функциональной ошибки, не сможет удовлетворить ни заказчика, ни конечного пользователя.

Составление требований – удел (хотите, называйте это обязанностью или компетенцией) аналитиков.  А вот за создание качественного программного продукта ответственна вся команда. Именно поэтому все участники процесса разработки должны быть причастны к созданию продукта с самого начала и дополнять друг друга.

В процессе разработки тестировщик дополняет и проверяет работу разработчика. А где же тестировщик может дополнять и проверять аналитика? В тестировании до разработки. В тестировании требований.

Требования – это основной документ, фундамент всей работы по тестированию продукта. Именно поэтому очень важно тестировать этот фундамент. Ведь если он далек от правды, то вся дальнейшая активность по сверке реализации с требованиями теряет смысл.

Аналитики не всегда имеют достаточно времени на детальную проработку требований, не всегда имеют достаточно знаний о нюансах проектирования и реализации приложения. Особенно, если аналитики – люди от заказчика.

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

Что же, если у вас в команде свои аналитики? Соглашусь с высказываением, что каждый должен заниматься своим делом. Действительно, тестировщик никогда не сравнится со «специально обученным» аналитиком. Ну и не нужно равняться. Нужно делать то, что по силам, и то, что работает на улучшение качества программных продуктов. Предотвращение дефектов – это уже не контроль качества (Quality Control), а элементы его обеспечения (Quality Assurance).

Сложно ли научиться дополнять и проверять работу аналитика? Не думаю. Ведь аналитический склад ума и так присущ нам, тестировщикам, иначе бы мы навсегда остались на уровне «маускликеров». Мы анализируем поведение приложения в различных ситуациях, придумываем эти самые ситуации, основываясь на бизнес-приоритетах и сценариях поведения пользователей. Мы выясняем все недовыясненные моменты и доказываем разработчикам, что заказчику нужно другое, отличное от реализованного.

Оговорюсь, что всему этому конечно же нельзя научиться за 2 часа. Моя цель – показать вам, где мы можем дополнять работу аналитика, и показать вам, что чем более осознанно мы это делаем, тем больше пользы это приносит продукту, команде и нашему профессионализму.

Серию семинаров: «Аналитика для тестировщиков» открывают два первых семинара:

«Работа с требованиями: анализ, тестирование» (10 декабря, 13:00-15:00)

• Когда и зачем привлекать тестировщиков к анализу и тестированию требований.
• Критерии качественного требования.
• Свойства требований.
• Функциональные и нефункциональные требования.
• Явные и неявные требования
• Методики тестирования требований.
• Полномочия и компетенции тестировщиков при работе с требованиями.

«Работа с требованиями: управление изменениями» (24 декабря, 13:00-15:00)

• Требования будут изменяться. Всегда!
• Влияние изменений в требованиях на тестирование.
• Изменения объема.
• Изменения сути.
• Изменения конфигурации.
• Конфликты и гибкость требований и тестов.
• Трассировка изменений требований.
• Повторное использование.

Условия участия в семинарах

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