Требования для тестирования
#1
Отправлено 19 августа 2004 - 11:57
1) Менеджер проекта?
2) Тест-менеджер сам должен уточнять имеющиеся описаные на высоком уровне требования (легкость в эксплуатации, отображение всплывающих подсказок - полного их списка еще нет список ) с программистами ?
3) Совместно на совещаниях (кто должен там присутсвовать?)
Как граммотно действовать в такой ситуации не очень точных требований, распределение ролей очень интересует...
#2
Отправлено 19 августа 2004 - 12:27
Сколько людей в вашей команде разработки/ в отделе?
Работают ли ваши разработчики по ХР?
Как построен процес проектирования и документации?
Есть ли выделенный отдел постановки?
Редактор портала www.it4business.ru
#3
Отправлено 20 августа 2004 - 06:58
По поводу требований - use cases выражают требования к поведению системы.
Требования составляет аналитик (роль). Роль аналитика может выполнять человек, привлеченный к этой задаче (как программист, так и тестировщик, может быть и менеджер проектов).
По поводу кто должен формулировать требования - никто не ДОЛЖЕН, это происходит для какой-то нужды проектной команды или заказчика ПО. Обычно с заказчиком обсуждаются бизнес-требования (т.н. features, функции системы, ее характерные особенности). Также с заказчиком обсуждаются use cases. Требования к ПО (Software Requirements) получаются в результате детализации бизнес-требований и use cases.
Вы, Алексей, видимо задавали вопрос именно о Software Requirements. Их в проекте строго оформленных может и не быть, особенно, если сроки разработки быстрые/проектная команда маленькая (просто разработчики между собой договариваются, а заказчику сразу предоставляются версии программы, прототипы, раскадровки и т.п.). В этом случае отсутствия спецификаций Software Requirements тестировщик сам исследует поведение системы, выясняя и уточняя поведение системы непосредственно у разработчиков. Можно попросить написать спецификакии на особо критические области программы - запрос адресовать к менеджеру проектов, чтобы он поручил разработчикам (или сам написал).
(Это из моего опыта)
Надеюсь, поможет... :)
#4
Отправлено 20 августа 2004 - 09:17
(Это в том случае, если вопрос сформулирован корректно. ;) ).
Как правило, данный вопрос, регламентируемый внутренними документами компании, определяет уровень качества тестировочных работ и правила по которым это уровень может быть оценен. Другими словами, если вы заявляете, что гарантируете высокий уровень тестирования, то необходимо продемонстрировать, как вы получаете этот уровень и как вы его оцениваете: набор действий, перечень получаемых результатов и критерии оценки этих результатов.
Ответственность за создание такого документа, на мой взгляд, должна лежать на сотруднике, который отвечает за поддержание процессов в комании.
#5
Отправлено 20 августа 2004 - 09:21
В ней подробно описывается методология разработки требований к приложению (JAR) с акцентом на дальнейшее тестирование системы.
#6
Отправлено 20 августа 2004 - 18:35
ПРикольно - а я думал, что требования к системе один из основных документов с которыми работают люди, когда пытаются понять, насколько то что сделано, соответсвует пожеланиям заказчика.По поводу кто должен формулировать требования - никто не ДОЛЖЕН, это происходит для какой-то нужды проектной команды или заказчика ПО.
Если нет требований - то по большому счёту будет сделано что-то, а не система.
Редактор портала www.it4business.ru
#7
Отправлено 23 августа 2004 - 09:12
Я имела в виду, что требования, разумеется, есть, но они могут быть не документированы, цель составления требований - достигнуть одинакового понимания вИдения системы заказчиком и проектной командой, для мелких проектов никаких формальных спецификаций может не быть - работа будет вестись по подписанным в контракте бизнес требованиям (а они, как правило, не детализированы до нужд тестирования).ПРикольно - а я думал, что требования к системе один из основных документов с которыми работают люди, когда пытаются понять, насколько то что сделано, соответсвует пожеланиям заказчика.По поводу кто должен формулировать требования - никто не ДОЛЖЕН, это происходит для какой-то нужды проектной команды или заказчика ПО.
Если нет требований - то по большому счёту будет сделано что-то, а не система.
Сделано будет то, что нужно заказчику, т.к. в любом случае ведутся переговоры о том, что и как надо сделать.
#8
Отправлено 23 августа 2004 - 09:13
#9
Отправлено 23 августа 2004 - 16:30
#10
Отправлено 25 августа 2004 - 08:05
Не соглашусь.Я имела в виду, что требования, разумеется, есть, но они могут быть не документированы, цель составления требований - достигнуть одинакового понимания вИдения системы заказчиком и проектной командой, для мелких проектов никаких формальных спецификаций может не быть - работа будет вестись по подписанным в контракте бизнес требованиям (а они, как правило, не детализированы до нужд тестирования).
Сделано будет то, что нужно заказчику, т.к. в любом случае ведутся переговоры о том, что и как надо сделать.
Первая ситуация:
Контракт подписывался с генеральным директором, переговоры "что и как" велись с ИТ-директором. ИТ-директор увольняется. Берут другого, который читает контракт, понимая его абсолютно по-своему. Что дальше?
Вторая ситуация:
Вы успешно сдаете проект, проходит полгода. Вдруг :) оказывается, что какая-то деталь, очень важная с точки зрения заказчика, не реализована. Заказчик приходит к вам. Грозится подать на вас в суд, если вы не допишите бесплатно нужную "деталь". Вы понимаете, что это противоречит всей архитектуре системы. Что дальше?
ИМХО требования всегда нужны и если их нет, то тестировщику лучше написать их самому или требовать у лидера проекта. Иначе возможны проблемы именно у тестировщика :)
#11
Отправлено 25 августа 2004 - 09:39
Undi, вы, видимо, не согласны с тем, что стоит внедрять описанный мной подход в работе над проектом. Но я это и НЕ ПРЕДЛАГАЮ!Не соглашусь.
Первая ситуация:
Контракт подписывался с генеральным директором, переговоры "что и как" велись с ИТ-директором. ИТ-директор увольняется. Берут другого, который читает контракт, понимая его абсолютно по-своему. Что дальше?
Вторая ситуация:
Вы успешно сдаете проект, проходит полгода. Вдруг :) оказывается, что какая-то деталь, очень важная с точки зрения заказчика, не реализована. Заказчик приходит к вам. Грозится подать на вас в суд, если вы не допишите бесплатно нужную "деталь". Вы понимаете, что это противоречит всей архитектуре системы. Что дальше?
ИМХО требования всегда нужны и если их нет, то тестировщику лучше написать их самому или требовать у лидера проекта. Иначе возможны проблемы именно у тестировщика :)
Я описала реальную ситуацию, когда Software Requirements МОГУТ БЫТЬ НЕ ОПИСАННЫМИ (а они действительно МОГУТ быть недокументированы), и как в этом случае строится работа команды, включая тестировщика; я отнюдь не призываю к внедрению такого подхода в IT компанию.
По поводу неожиданностей:
У нас так принято:
Заказчик участвует в официальном бета тестировании продукта, обнаруженные в результате дефекты и недоработки будут исправлены. И никаких пол года вдруг B) К тому же, все фичи заявляются в контракте. Архитектурно значимые варианты использования тоже выявляются в стадии presale, так что неожиданных кардинальных деталей не может возникнуть.
Про увольнение сотрудников, владеющих информацией:
А аналитик может уволиться и сразу после устных переговоров с заказчиком, когда ничего не еще документировано.
Но связь с заказчиком не обрывается и не ограничивается одним разом.
Обычно разговоры "что и как" происходят постепенно, а не всё в один раз, при этом вопросы и предложения о работе системы задаются в письменной форме и ответы тоже (или в устной, но тогда передаются команде разработчиков, иначе все равно всего в деталях не запомнить), тогда аналитик владеет приватно (если он расшаривает переписку) только концепцией построения системы и способами ее осуществления, а не собственно информацией о системе.
А вот если не расшаривает, и модель водопадная,то всяко может быть, тут я согласна с Undi :) - но это тоже решаемо - смотря как в компании процессы налажены :P
#12
Отправлено 25 августа 2004 - 09:59
Да, бывают ситуации, когда требований и документации мало или нет вообще. Но я считаю, что в таких случаях нужно либо писать документацию, либо требовать ее. Иначе могут случиться любые неприятности :).Я описала реальную ситуацию, когда Software Requirements МОГУТ БЫТЬ НЕ ОПИСАННЫМИ (а они действительно МОГУТ быть недокументированы), и как в этом случае строится работа команды, включая тестировщика; я отнюдь не призываю к внедрению такого подхода в IT компанию.
т.е. вы не сопровождаете свои продукты?По поводу неожиданностей:
У нас так принято:
Заказчик участвует в официальном бета тестировании продукта, обнаруженные в результате дефекты и недоработки будут исправлены. И никаких пол года вдруг B)
Не всегда всё так очевидно, как хотелось бы:)К тому же, все фичи заявляются в контракте. Архитектурно значимые варианты использования тоже выявляются в стадии presale, так что неожиданных кардинальных деталей не может возникнуть.
Естественно, но здесь уже нужно оговаривать масштабы проекта.Про увольнение сотрудников, владеющих информацией:
А аналитик может уволиться и сразу после устных переговоров с заказчиком, когда ничего не еще документировано.
Но связь с заказчиком не обрывается и не ограничивается одним разом.
#13
Отправлено 25 августа 2004 - 10:05
To YariloА вот если не расшаривает, и модель водопадная,то всяко может быть
Возможно я и ошибаюсь, но судя по описанной ситуации, Ваша организация находиться только в начале пути имплементации процессов.
Ни кто не спорит, что могут быть проекты, где отсутствует вся документация. ;)
Но речь идет о том, что это уже даже не вчерашний день, а позавчерашний. Фирмы, которые не занимаются усовершенствованием процессов, потерпят фиаско и давольно быстро. Через год - два конкуренты с более эффективной организационной системой вытеснят такие фирмы из их ниш. И снижение себестоимости продукции не поможет.
Документация, это всего лишь один из элементов процесса. Часть бумажек можно безболезненно игнорировать до определенного момента.
Как у Маяковского - "Любую бумажку... Но эта!" :P
Но часть документации является ключом к созданию приложения. Именно она определяет насколько качественно продумана и подготовлена работа. Документ с перечнем требований относиться к этой категории. Не зря во всех стандартах по разработке программного обеспечения деятельность по составлению, учету и поддержанию требований в актуальном состоянии вынесен в качестве отдельного процесса.
В конечном итоге, это все выливается в вопрос эффективности.
#14
Отправлено 26 октября 2004 - 09:30
Полностью согласен.Но часть документации является ключом к созданию приложения. Именно она определяет насколько качественно продумана и подготовлена работа. Документ с перечнем требований относиться к этой категории. Не зря во всех стандартах по разработке программного обеспечения деятельность по составлению, учету и поддержанию требований в актуальном состоянии вынесен в качестве отдельного процесса.
В конечном итоге, это все выливается в вопрос эффективности.
Тест-планы и тест кейсы должны разрабатываться именно исходя из требований, в противном случае говорить об эффективном тестировании не приходится. ;)
#15
Отправлено 11 ноября 2004 - 15:14
Вот кстати возникает вопрос в достаточно эффективной и формальной оценке качества тестирования? Что принять за критерий? Покрытие требований тестами? Или покрытие строк кода? Или число ошибок найденных после нас клиентом?Как правило, данный вопрос, регламентируемый внутренними документами компании, определяет уровень качества тестировочных работ и правила по которым это уровень может быть оценен. Другими словами, если вы заявляете, что гарантируете высокий уровень тестирования, то необходимо продемонстрировать, как вы получаете этот уровень и как вы его оцениваете: набор действий, перечень получаемых результатов и критерии оценки этих результатов.
#16
Отправлено 11 ноября 2004 - 15:27
Вообще то, это комплексная оценка.Что принять за критерий? Покрытие требований тестами? Или покрытие строк кода? Или число ошибок найденных после нас клиентом?
В основу могут быть положены следующие показатели:
- общее количество требований к системе / количество требований покрытых тестами;
- количество прошедших / не прошедших тестов;
- количество открытых / назначенных / исправленных / закрытых багов.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных