Home

Доклад Алексея Федорова (инженер по тестированию, ТРАНС-ИТ, Россия, Санкт-Петербург) на конференции Analyst Days – 4.

Если ввести "тестирование требований" в поисковую строку, то вернётся всего один(!!!) релевантный результат. Остальные, так или иначе, связаны с "требованиями к требованиям", которые разные(!) в разных источниках. Мой опыт и опыт коллег, тестировщиков и аналитиков, говорит, что это редкая активность, а у кого она не "пустая формальность" вообще единицы.

Заинтересовавшись этой проблемой год назад, я стал собирать советы по тестированию требований и отлаживать их на своих проектах и проектах коллег из других компаний. Удалось собрать пока немного, но уже есть результаты, которыми я хочу с вами поделиться. Среди них в чём польза, в чём fun, в чём трудности тестирования требований.

Запись доклада Даши Гармаш на онлайн-конференции Chief ConfeT&QA, весна 2012.

Работающее программное обеспечение важнее, чем полная документация (с) Agile Manifesto

В своем докладе я расскажу, как выжить тест-менеджеру в agile-проектах с «плавающими» требованиями, и, самое главное, организовать общение с заказчиком посредством формулирования требований в Jira.

Будут рассмотрены следующие вопросы:

• как жить без аналитика?
• требования: их нет, но они нужны
• проектируем workflow требований для команды разработчики/тестировщики
• общение с заказчиком через постановку требований
• рука на пульсе: кратко об отчетах

Do it в Jira!

Представляем доклад Сергея Мартыненко, который он делал на Летнем аналитическом фестивале 2010.

Этот доклад часто используется как учебный материал для тестировщиков.

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

Мы предлагаем вам ознакомиться с выступлением Сергея Мартыненко на Летнем Аналитическом Фестивале - 2010, где он рассказывал о том, как тестировать требования параллельно с разработкой тестов на их основе:

1) Тесты важнейшая и неотемлемая часть требований
2) Правильные вопросы для выявления требований
3) Преимущества обратного подхода при разработке проектной документации
4) Преимущество стековой модели разработки ПО перед моделью очереди
5) Разумное сочетание ролей в малых командах по разработке ПО

Автор: Наталья Руколь

Внимание! В этой статье будет много буковок и советов о том, как вы можете повысить эффективность своей работы и проекта в целом в условиях нехватки требований. Если вы привыкли жаловаться на нехватку требований и не хотите ничего менять, статья к прочтению не рекомендуется.

Роль требований в процессе разработки

Требования похожи на единорогов. Такие же прекрасные мифические создания, несущие людям счастье  В ~99% проектов, с которыми я сталкивалась, требования:

• Были неполным
• Были некорректным
• Отсутствовали

Выбирайте любые пункты из трёх, а иногда и все вместе.

При этом моя религия утверждает, что хорошие, полные, детально проработанные требования – залог успеха не только тестирования, но и проекта в целом. Что же делать, если мы входим в статистическое большинство, и удовлетворительных требований у нас нет?

Как всегда, у нас есть выбор. Вариант #1 – подождать: а вдруг появятся? Чтобы ожидание не было скучным, можно разбавлять его регулярными жалобами на нехватку требований и байками из серии «а вот в нормальных компаниях…».

И есть вариант #2 – построить процесс таким образом, что у вас появятся требования. Именно об этом варианте мы и поговорим в статье.

Представляем слайдкаст выступления Юлии Нечаевой "Тестирование требований: Зачем - понятно, а вот Как?" на Летнем Аналитическом Фестивале - 2010:

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

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

Автор: К. Хенинджер

Heninger К. L. Specifying Software Requirements for Complex Systems: New Techniques and Their Application, IEEE Transactions on Software Engineering, vol. SE-5, № 1, January 1980, 2-13.

Эта статья посвящена новым методам, позволяющим сделать описания требований точными, краткими, однозначными и легко проверяемыми на полноту и непротиворечивость. Методы хорошо подходят для сложных программных систем реального времени; они были разработаны для документирования существующего полетного программного обеспечения самолета А-7 ВМС США. В статье приводится обзор информации, входящей в состав описания требований, и обсуждаются цели, поставленные при разработке методов. Описание каждого метода иллюстрируется примерами из документа, содержащего требования к программному обеспечению самолета А-7. Цель этой статьи состоит в том, чтобы представить указанный документ как модель дисциплинированного подхода к описанию требований, а сам документ может служить полностью проработанным примером применения этого подхода.

Автор: К. Хенинджер

Heninger К. L. Specifying Software Requirements for Complex Systems: New Techniques and Their Application, IEEE Transactions on Software Engineering, vol. SE-5, № 1, January 1980, 2-13.

Продолжение: Принципы документирования требований, методы описания интерфейсов с аппаратурой, шаблоны для описания значений, описание входных элементов данных.

Автор: К. Хенинджер

Heninger К. L. Specifying Software Requirements for Complex Systems: New Techniques and Their Application, IEEE Transactions on Software Engineering, vol. SE-5, № 1, January 1980, 2-13.

Продолжение: Описание выходных элементов данных в терминах воздействия на внешние устройства; Пример описания выходного элемента данных; Методы описания функций программного обеспечения; Организация описания в соответствии с функциями; Выходные значения как функции условий и событий; Согласованная нотация для описания условий; Режимы и их использование для организации и упрощения описания требований.

Автор: К. Хенинджер

Heninger К. L. Specifying Software Requirements for Complex Systems: New Techniques and Their Application, IEEE Transactions on Software Engineering, vol. SE-5, № 1, January 1980, 2-13.

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