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

[Alexey]

Кто должен сформулировать такие требования (не случаи использования и не тестовые сценарии) которые можно протестировать:

1) Менеджер проекта?
2) Тест-менеджер сам должен уточнять имеющиеся описаные на высоком уровне требования (легкость в эксплуатации, отображение всплывающих подсказок - полного их списка еще нет список ) с программистами ?
3) Совместно на совещаниях (кто должен там присутсвовать?)


Как граммотно действовать в такой ситуации не очень точных требований, распределение ролей очень интересует...

[Case]

Алексей, уточните, пожалуйста:

Сколько людей в вашей команде разработки/ в отделе?
Работают ли ваши разработчики по ХР?
Как построен процес проектирования и документации?
Есть ли выделенный отдел постановки?

[Yarilo]

Привет!

По поводу требований - use cases выражают требования к поведению системы.
Требования составляет аналитик (роль). Роль аналитика может выполнять человек, привлеченный к этой задаче (как программист, так и тестировщик, может быть и менеджер проектов).

По поводу кто должен формулировать требования - никто не ДОЛЖЕН, это происходит для какой-то нужды проектной команды или заказчика ПО. Обычно с заказчиком обсуждаются бизнес-требования (т.н. features, функции системы, ее характерные особенности). Также с заказчиком обсуждаются use cases. Требования к ПО (Software Requirements) получаются в результате детализации бизнес-требований и use cases.

Вы, Алексей, видимо задавали вопрос именно о Software Requirements. Их в проекте строго оформленных может и не быть, особенно, если сроки разработки быстрые/проектная команда маленькая (просто разработчики между собой договариваются, а заказчику сразу предоставляются версии программы, прототипы, раскадровки и т.п.). В этом случае отсутствия спецификаций Software Requirements тестировщик сам исследует поведение системы, выясняя и уточняя поведение системы непосредственно у разработчиков. Можно попросить написать спецификакии на особо критические области программы - запрос адресовать к менеджеру проектов, чтобы он поручил разработчикам (или сам написал).

(Это из моего опыта)
Надеюсь, поможет... :)

[Green]

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

(Это в том случае, если вопрос сформулирован корректно. ;) ).

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

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

[Green]

Если же речь идет о Software Requirements, то рекомендую прочитать книгу "Быстрое тестирование", авторы Роберт Калбертсон и др.

В ней подробно описывается методология разработки требований к приложению (JAR) с акцентом на дальнейшее тестирование системы.

[Case]

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

ПРикольно - а я думал, что требования к системе один из основных документов с которыми работают люди, когда пытаются понять, насколько то что сделано, соответсвует пожеланиям заказчика.

Если нет требований - то по большому счёту будет сделано что-то, а не система.

[Yarilo]

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

ПРикольно - а я думал, что требования к системе один из основных документов с которыми работают люди, когда пытаются понять, насколько то что сделано, соответсвует пожеланиям заказчика.

Если нет требований - то по большому счёту будет сделано что-то, а не система.

Я имела в виду, что требования, разумеется, есть, но они могут быть не документированы, цель составления требований - достигнуть одинакового понимания вИдения системы заказчиком и проектной командой, для мелких проектов никаких формальных спецификаций может не быть - работа будет вестись по подписанным в контракте бизнес требованиям (а они, как правило, не детализированы до нужд тестирования).

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

[Yarilo]

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

[Alexey]

Спасибо за ответы, с требованиями проблема решена - с помощью совещания. (JAR сеанс=)

[Undi]

Я имела в виду, что требования, разумеется, есть, но они могут быть не документированы, цель составления требований - достигнуть одинакового понимания вИдения системы заказчиком и проектной командой, для мелких проектов никаких формальных спецификаций может не быть - работа будет вестись по подписанным в контракте бизнес требованиям (а они, как правило, не детализированы до нужд тестирования).

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

Не соглашусь.
Первая ситуация:
Контракт подписывался с генеральным директором, переговоры "что и как" велись с ИТ-директором. ИТ-директор увольняется. Берут другого, который читает контракт, понимая его абсолютно по-своему. Что дальше?

Вторая ситуация:
Вы успешно сдаете проект, проходит полгода. Вдруг :) оказывается, что какая-то деталь, очень важная с точки зрения заказчика, не реализована. Заказчик приходит к вам. Грозится подать на вас в суд, если вы не допишите бесплатно нужную "деталь". Вы понимаете, что это противоречит всей архитектуре системы. Что дальше?

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

[Yarilo]

Не соглашусь.
Первая ситуация:
Контракт подписывался с генеральным директором, переговоры "что и как" велись с ИТ-директором. ИТ-директор увольняется. Берут другого, который читает контракт, понимая его абсолютно по-своему. Что дальше?

Вторая ситуация:
Вы успешно сдаете проект, проходит полгода. Вдруг :) оказывается, что какая-то деталь, очень важная с точки зрения заказчика, не реализована. Заказчик приходит к вам. Грозится подать на вас в суд, если вы не допишите бесплатно нужную "деталь". Вы понимаете, что это противоречит всей архитектуре системы. Что дальше?

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

Undi, вы, видимо, не согласны с тем, что стоит внедрять описанный мной подход в работе над проектом. Но я это и НЕ ПРЕДЛАГАЮ!

Я описала реальную ситуацию, когда Software Requirements МОГУТ БЫТЬ НЕ ОПИСАННЫМИ (а они действительно МОГУТ быть недокументированы), и как в этом случае строится работа команды, включая тестировщика; я отнюдь не призываю к внедрению такого подхода в IT компанию.

По поводу неожиданностей:
У нас так принято:
Заказчик участвует в официальном бета тестировании продукта, обнаруженные в результате дефекты и недоработки будут исправлены. И никаких пол года вдруг B) К тому же, все фичи заявляются в контракте. Архитектурно значимые варианты использования тоже выявляются в стадии presale, так что неожиданных кардинальных деталей не может возникнуть.

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

Но связь с заказчиком не обрывается и не ограничивается одним разом.

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

А вот если не расшаривает, и модель водопадная,то всяко может быть, тут я согласна с Undi :) - но это тоже решаемо - смотря как в компании процессы налажены :P

[Undi]

Я описала реальную ситуацию, когда Software Requirements МОГУТ БЫТЬ НЕ ОПИСАННЫМИ (а они действительно МОГУТ быть недокументированы), и как в этом случае строится работа команды, включая тестировщика; я отнюдь не призываю к внедрению такого подхода в IT компанию.

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

По поводу неожиданностей:
У нас так принято:
Заказчик участвует в официальном бета тестировании продукта, обнаруженные в результате дефекты и недоработки будут исправлены. И никаких пол года вдруг  B) 

т.е. вы не сопровождаете свои продукты?

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

Не всегда всё так очевидно, как хотелось бы:)

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

Естественно, но здесь уже нужно оговаривать масштабы проекта.

[Green]

А вот если не расшаривает, и модель водопадная,то всяко может быть

To Yarilo

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

Ни кто не спорит, что могут быть проекты, где отсутствует вся документация. ;)

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

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

Как у Маяковского - "Любую бумажку... Но эта!" :P

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

В конечном итоге, это все выливается в вопрос эффективности.

[Jackie]

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

В конечном итоге, это все выливается в вопрос эффективности.

Полностью согласен.

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

[Vit]

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

Вот кстати возникает вопрос в достаточно эффективной и формальной оценке качества тестирования? Что принять за критерий? Покрытие требований тестами? Или покрытие строк кода? Или число ошибок найденных после нас клиентом?

[Green]

Что принять за критерий? Покрытие требований тестами? Или покрытие строк кода? Или число ошибок найденных после нас клиентом?

Вообще то, это комплексная оценка.

В основу могут быть положены следующие показатели:
- общее количество требований к системе / количество требований покрытых тестами;
- количество прошедших / не прошедших тестов;
- количество открытых / назначенных / исправленных / закрытых багов.