Сообщений в теме: 8

[Owl]

Добрый день!
А чем отличается документ "Тест-дизайн" от документа "Тест-план", (если отличается)?

[Rost]

Добрый день!
А чем отличается документ "Тест-дизайн" от документа "Тест-план", (если отличается)?

Добрый день!
"Тест План" (Test Plan) - должен содержать в себе информацию для руководителей проектов (структура команды тестировщиков, виды тестирования, риски, что тестируется, что находится вне тестирования, подходы используемые при тестировании, автоматизация и т.д.)
"Тест-дизайн" (Test Design/Test Specification/Software Test Plan/System Test Plan) - содержит тестовые случи (test cases), а так же может содержать и случаи использования (use cases) если необходимо.

На самом деле непростой вопрос ввиду различных стандартов, методик и процедур с их собственными названиями одного и того же.
Мой Вам совет выберите какой-то один стандарт и пользуйтеь. Например IEEE - http://www.opengroup...95399/download/

[Imbecile]

Если следовать RUP (Rational Unified Process), то имеем следующее определение:
Artifact Test Plan
The definition of the goals and objectives of testing within the scope of the iteration (or project), the items being targeted, the approach to be taken, the resources required and the deliverables to be produced. © RUP

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

В тоже самое время, отдельного артифакта Тест Дизайн в RUP нету. Есть только набор, называемый Test Software Design.

Test Software Design
The following are test artifacts that relate to (or are part of) the design and implementation model artifacts. © RUP

Следующий набор Артифактов тестирования относятся (являются частью) к артифактам моделей дизайна и реализации.

В него входят следующие артифакты:
Artifact Test Automation Architecture
A composition of various test automation elements and their specifications that embody the fundamental characteristics of the test automation software system. The Test Automation Architecture provides a comprehensive architectural overview of the test automation system, using a number of different architectural views to depict different aspects of the system. © RUP

Артифакт Архитектура Автоматизации Тестирования
Композиция различных елементов автоматизации тестирования и их спецификации, которая представляет основные характеристики программной системы автоматизирующей тестирование. Архитектура Автоматизации Тестирования предлагает всесторонний обзор системы автоматизации тестирования и описыает аспекты системы с различных архитектурных точек зрения.

Artifact Test Interface Specification
A specification for the provision of a set of behaviors (operations) by a classifier (specifically, a Class, Subsystem or Component) for the purposes of test access (testability). Each test Interface should provide an unique and well-defined group of services. © RUP

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

Artifact Test Class
A stereotype of Class in the design model. © RUP

Artifact Test Component
A stereotype of component in the implementation model. © RUP

P.S. Это не ответ на вопрос, а справка.
P.P.S. Прошу прощения за перевод (точнее за ошибки внём). Поправте, если что-то не так.

[barancev]

http://forums.softwa...indpost&p=11943

[Owl]

Если следовать RUP (Rational Unified Process), то имеем следующее определение:
Artifact Test Plan
The definition of the goals and objectives of testing within the scope of the iteration (or project), the items being targeted, the approach to be taken, the resources required and the deliverables to be produced. © RUP

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

В тоже самое время, отдельного артифакта Тест Дизайн в RUP нету. Есть только набор, называемый Test Software Design.

Test Software Design
The following are test artifacts that relate to (or are part of) the design and implementation model artifacts. © RUP

Следующий набор Артифактов тестирования относятся (являются частью) к артифактам моделей дизайна и реализации.

В него входят следующие артифакты:
Artifact Test Automation Architecture
A composition of various test automation elements and their specifications that embody the fundamental characteristics of the test automation software system. The Test Automation Architecture provides a comprehensive architectural overview of the test automation system, using a number of different architectural views to depict different aspects of the system. © RUP

Артифакт Архитектура Автоматизации Тестирования
Композиция различных елементов автоматизации тестирования и их спецификации, которая представляет основные характеристики программной системы автоматизирующей тестирование. Архитектура Автоматизации Тестирования предлагает всесторонний обзор системы автоматизации тестирования и описыает аспекты системы с различных архитектурных точек зрения.

Artifact Test Interface Specification
A specification for the provision of a set of behaviors (operations) by a classifier (specifically, a Class, Subsystem or Component) for the purposes of test access (testability). Each test Interface should provide an unique and well-defined group of services. © RUP

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

Artifact Test Class
A stereotype of Class in the design model. © RUP

Artifact Test Component
A stereotype of component in the implementation model. © RUP

P.S. Это не ответ на вопрос, а справка.
P.P.S. Прошу прощения за перевод (точнее за ошибки внём). Поправте, если что-то не так.

Спасибо - любая информация в этом плане очень ценна.

[Owl]

http://forums.softwa...indpost&p=11943

Спасибо большое. А то 3 года занимаюсь тестированием и соот-но написанием планов, но стандарт как таковой не использовали, т.к. все равно Тест-план больше для внутреннего использования команды был.

А тут вдруг "не хотите ли стать тест-дизайнером?" - я и испугалась...

Единственное хочу уточнить, а разве такие моменты как отвод времени типа "тестировать будем подсистемы в перечисленном порядке, на каждую отводим не более одного месяца на разработку тестов и затем по 2 дня в месяц для выполнения тестов в регрессионном режиме и анализа результатов"" , а также просчитывание рисков есть задача тест-дизайнера, а не Рroject Manager'а?

[Imbecile]

Единственное хочу уточнить, а разве такие моменты как отвод времени  типа "тестировать будем подсистемы в перечисленном порядке, на каждую отводим не более одного месяца на разработку тестов и затем по 2 дня в месяц для выполнения тестов в регрессионном режиме и анализа результатов"" , а также просчитывание рисков есть задача тест-дизайнера, а не Рroject Manager'а?

Опять же, следуя RUP, это задача Тест-Менеджера.

P.S. Кинте в приват своё мыло, я разобью html-guide по RUP и вышлю. Там много чего интересного. Весит 17 МБ в архиве. Скажите на какого размера файлы разбить. Не обязательно следовать методологии RUP, но получить представление об этом стоит.

[barancev]

Единственное хочу уточнить, а разве такие моменты как отвод времени  типа "тестировать будем подсистемы в перечисленном порядке, на каждую отводим не более одного месяца на разработку тестов и затем по 2 дня в месяц для выполнения тестов в регрессионном режиме и анализа результатов"" , а также просчитывание рисков есть задача тест-дизайнера, а не Рroject Manager'а?

Планирование -- это задача, которую PM реально не может решить волюнтаристски, не привлекая в качестве экспертов будущих исполнителей. PM спросит Вас (ибо Вы же лучше разбираетесь в тестировании) -- "как Вы думаете, в каком порядке имеет смысл тестировать эти подсистемы и сколько времени понадобится на каждую?", потом поторгуется с Вами, с разработчиками, с вышестоящим начальством, и тогда будет план, который реально выполнить. А вот слежение за исполнением -- это да, тут PM типа самый главный. И поэтому он старается облегчить себе это дело. Если временные рамки просто спущены сверху -- выход за них не вызывает никакого дискомфорта. А вот нарушать данные Вами же обещания сделать это за такое-то время Вам будет неприятно, согласитесь. Поэтому Вы очень постараетесь уложиться в план

[Nadya Kochetova]

тест план может быть написан на салфетке и продукт будет успешным. тест -план может быть расписан в 6 документах, включая мастер тест план, план для каждой фазы тестирования и релиз может провалиться.

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

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

В плохой практике план написали раз и забыли. в хорошей практике - получили информацию-пересмотрели планы, пересмотрели эстимацию.

тест кейсы расписываются в тест планах низкого уровня.

и еще: не держите планы и тест кейсы в секрете! люди должны их видеть обсуждать и использовать.