лк_4_Жизненный_цикл_тестирования (2)

1.

Жизненный цикл тестирования

2.

Следуя общей логике итеративности, превалирующей во
всех современных моделях разработки ПО, жизненный
цикл тестирования также выражается замкнутой
последовательностью действий

3.

Важно понимать, что длина такой итерации (и, соответственно,
степень подробности каждой стадии) может варьироваться в
широчайшем диапазоне — от единиц часов до десятков месяцев.
Как правило, если речь идёт о длительном промежутке времени,
он разбивается на множество относительно коротких итераций, но
сам при этом «тяготеет» к той или иной стадии в каждый момент
времени (например, в начале проекта больше планирования, в
конце — больше отчётности).
Также ещё раз стоит подчеркнуть, что приведённая схема — не
догма, но общая суть и ключевые принципы остаются
неизменными. Их и рассмотрим.

4.

5.

Стадия 1 (общее планирование и анализ требований) объективно
необходима, как минимум, для того, чтобы иметь ответ на такие
вопросы, как: что нам предстоит тестировать; как много будет
работы; какие есть сложности; всё ли необходимое у нас есть и т.п.
Как правило, получить ответы на эти вопросы невозможно без
анализа требований, т.к. именно требования являются первичным
источником ответов.

6.

Стадия 2 (уточнение критериев приёмки) позволяет сформулировать
или уточнить метрики и признаки возможности или необходимости
начала тестирования, приостановки и возобновления тестирования,
завершения или прекращения тестирования.

7.

Стадия 3 (уточнение стратегии тестирования) представляет
собой ещё одно обращение к планированию, но уже на
локальном уровне: рассматриваются и уточняются те части
стратегии тестирования, которые актуальны для текущей
итерации.

8.

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

9.

Стадия 5 (выполнение тест-кейсов) и стадия 6 (фиксация
найденных дефектов) тесно связаны между собой и
фактически выполняются параллельно: дефекты
фиксируются сразу по факту их обнаружения в процессе
выполнения тест-кейсов. Однако зачастую после выполнения
всех тест-кейсов и написания всех отчётов о найденных
дефектах проводится явно выделенная стадия уточнения, на
которой все отчёты о дефектах рассматриваются повторно с
целью формирования единого понимания проблемы и
уточнения таких характеристик дефекта, как важность и
срочность.

10.

Стадия 7 (анализ результатов тестирования) и стадия
8 (отчётность) также тесно связаны между собой и
выполняются практически параллельно. Формулируемые
на стадии анализа результатов выводы напрямую зависят
от плана тестирования, критериев приёмки и уточнённой
стратегии, полученных на стадиях 1, 2 и 3. Полученные
выводы оформляются на стадии 8 и служат основой для
стадий 1, 2 и 3 следующей итерации тестирования. Таким
образом, цикл замыкается.

11.

Требования

12.

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

13.

Важность требований

14.

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

15.

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

16.

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

17.

Продуктная документация (product documentation, development
documentation) используется проектной командой во время разработки и
поддержки продукта. Она включает:
План проекта (project management) и в том числе тестовый план
(test).
Требования к программному продукту (product requirements
document)и функциональные спецификации (functional specifications
document, FSD; software requirements specification, SRS).
Архитектуру и дизайн (architecture and design).
Тест-кейсы и наборы тест-кейсов (test cases, test suites).
Технические спецификации (technical specifications), такие как
схемы баз данных, описания алгоритмов, интерфейсов и т.д.

18.

Проектная документация (project documentation)
включает в себя как продуктную документацию, так и
некоторые дополнительные виды документации и
используется не только на стадии разработки, но и на
более ранних и поздних стадиях (например, на стадии
внедрения и эксплуатации).

19.

Пользовательскую и сопроводительную
документацию (user and accompanying documentation), такую
как встроенная помощь, руководство по установке и
использованию, лицензионные соглашения и т.д.

20.

Маркетинговую документацию (market requirements
document, MRD),которую представители разработчика или
заказчика используют как на начальных этапах (для
уточнения сути и концепции проекта), так и на финальных
этапах развития проекта (для продвижения продукта на
рынке).

21.

Источники и пути выявления требований:

22.

Интервью, опросы, анкетирование.
Мозговой штурм, семинар.
Наблюдение за производственной деятельностью,
«фотографирование» рабочего дня.
Анализ нормативной документации.
Анализ моделей деятельности.
Анализ конкурентных продуктов.
Анализ статистики использования предыдущих версий системы.
Совещание.
Use case.

23.

Анкетирование

24.

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

25.

Самым известным примером анкетирования может быть
“Бриф на разработку сайта” — анкета содержащая
список основных требований и информацию о будущем
сайте.

26.

Преимущества:
1.Высокая скорость получения результатов.
2.Сравнительно небольшие материальные затраты.
Недостатки:
1.Данный метод не подходит для выявления неявных
требований.
2.При составлении опросника физически невозможно
учесть все необходимые вопросы.

27.

Интервью

28.

Этот метод известен многим в качестве своего рода беседа “по душам” с
заинтересованным лицом, тет-а-тет.
Необходимо задавать открытые вопросы для получения информации и
закрытые для того, чтобы подтвердить или опровергнуть конкретные
варианты требований.
Данный способ применяется, в основном, для получения информации по
какой-либо конкретной теме и/или для уточнения требований.
Многим этот способ может показаться достаточно легким, но это не так.
Провести хорошее интервью достаточно сложно. Вы должны гибко
реагировать на реакцию интервьюируемого и, в случае необходимости,
изменять порядок заготовленных вопросов или их формулировку. Не
забудьте включить диктофон во время интервью или вести заметки.

29.

Из плюсов:
1.Возможность задавать вопросы в произвольной
последовательности.
2.Возможность использовать вспомогательный материал.
3.Анализ невербальной реакции опрашиваемого человека,
позволит сделать дополнительный вывод о достоверности
его ответов.
Из минусов:
1.Интервью отнимает достаточно много времени и сил.
2.Дополнительной сложностью является получение
одинаковых ответов от интервьюируемых.

30.

Анализ нормативной документации

31.

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

32.

Плюс:
Быстрое получение информации.
Минус:
Данный способ не применим при наличии в компании
только базовых документов (или при их полном
отсутствии) или, если в компании заказчика не
поддерживается актуальность документации.

33.

Мозговой штурм

34.

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

35.

Плюсы:
Позволяет генерировать множество (в том числе и
нестандартных) вариантов решений, а также позволяет
участникам развивать идеи друг друга.
Минусы:
Участники мозгового штурма должны быть мотивированы
на идеи.
Трудно применим в распределенных командах.

36.

Совещание

37.

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

38.

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

39.

Use case

40.

Use cases или варианты использования позволяют собрать
и сформировать функциональные требования от лица
участников. Диаграммы вариантов использования
определяют границы решения и показывают связи с
внешними системами и участниками.
Метод позволяет детализировать требования с точки
зрения пользователей, а также помогает уточнить и
систематизировать функционал, который требуется
реализовать.

41.

Плюсы:
Позволяет проработать все варианты развития
сценария (основной и альтернативные
сценарии).
Минусы:
Метод не применим для сбора
нефункциональных требований.

42.

Анализ требований

43.

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

44.

Пример. В требованиях было записано: «В поле «Имя
пользователя» могут быть введены буквы и цифры».
Разработчик начал выяснять у аналитика, какие именно буквы
(кириллица, латиница или арабские) и какие цифры (целые,
дробные, римские) имеются в виду. После уточнения требований
разработчик реализовал функционал согласно комментариям
аналитика. Задача перешла в тестирование. Тестировщик не
понимал, по каким критериям проверять данное поле, и тоже
начал расспрашивать аналитика.

45.

Последствия:
Затраченное время нескольких членов команды.
Несовпадение итогового и изначально планируемого
функционалов.
Как тестировать:
Если у Вас после прочтения требований остались вопросы
– необходима доработка.
Если разработчики часто уточняют детали в чатах – это
плохой знак.
Дальнейшее («более глубокое») исследование требует
гораздо больших временных затрат.

46.

2. Актуальность
Необходимость поддержания актуальности требований
кажется очевидной. Однако, на некоторых проектах
требования не обновляются месяцами, а то и годами. Это
может быть связано с тем, что в штате нет аналитика, а у
исполняющего его обязанности сотрудника просто не хватает
времени. Случается и другое: требования обновляют только
при наличии действительно значимых изменений, при этом
различные «мелочи», в виде изменения кнопок или текстов,
игнорируются.

47.

Пример. Было решено изменить положение кнопок на странице
авторизации. Аналитик не стал править документацию, а написал
разработчику личное сообщение с просьбой поправить расположение
кнопок. Разработчик внес правки и закрыл задачу. Во время очередного
регрессионного тестирования тестировщик решил, что это дефект, и
завел на него баг. Другой разработчик вернул кнопки на прежние
позиции согласно документации.

48.

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

49.

3. Логика
Как следует из названия, работа системы должна быть
логичной. Пользователь не может изменить настройки
своего профиля или написать письмо до того, как
пройдет авторизацию в системе. Звучит, опять же,
элементарно, но в проектах со множеством клиентов или
со сложной логикой подобные ошибки часто
допускаются.

50.

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

51.

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

52.

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

53.

Последствия:
При потере связи система ведет себя некорректно
(отсутствие ошибок, зависание).
Сообщения об ошибках не очевидны.
В худшем случае возможны репутационные или
финансовые потери.
Как тестировать:
Нарисовать блок-схему отдельного модуля системы, в
рамках которой обозначить все возможные условия и
действия пользователя.
Убедиться, что в требованиях есть описание каждого
возможного случая.

54.

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

55.

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

56.

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

57.

Тестирование документации

58.

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

59.

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

60.

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

61.

Из пункта выше вытекает структурированность документации. Все
документы должны находится в полном порядке, по разделам. Также, текст
должен быть с четкой структурой, чтобы можно было в любой момент
вспомнить, где остановился или понять, в каком абзаце содержится именно та
информация, которая нам необходима.
Инструкции должны присутствовать везде. Даже при выполнении абсолютно
одинаковых манипуляций с программой необходимо пошаговое описание
действий во всех случаях. Это может быть как прямое повторение инструкций,
так и ссылка на уже существующие.
Термины и их значение. В любой документации может использоваться масса
терминов, аббревиатур и сокращений. Каждый из них должен иметь свое
значение и расшифровку.
Доступность пользователю. Документация должна быть максимально
понятной для любой целевой аудитории.
Если документация создана и для иностранных пользователей,то
необходимо привлечение специалистов данного лингвистического сектора,
вплоть до носителей языка.

62.

Основные принципы тестирования требований

63.

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

64.

Существует еще много требований к составлению и
тестированию документации. Сегодня мы рассмотрели
основные положения. Но главное правило, которое поможет
нам – это умение ставить себя на место пользователя,
попавшего в определенную проблемную ситуацию.

65.

Свойства качественных требований

66.

В процессе тестирования требований проверяется их
соответствие определённому набору свойств:
Атомарность, единичность (atomicity). Требование является атомарным,
если его нельзя разбить на отдельные требования без потери
завершённости и оно описывает одну и только одну ситуацию.
Непротиворечивость, последовательность (consistency).
Требование не должно содержать внутренних противоречий и
противоречий другим требованиям и документам.

67.

Недвусмысленность (unambiguousness, clearness). Требование должно
быть описано без использования жаргона, неочевидных аббревиатур и
расплывчатых формулировок, а также должно допускать только
однозначное объективное понимание и быть атомарным в плане
невозможности различной трактовки сочетания отдельных фраз.
Обязательность, нужность (obligatoriness) актуальность (up-to-date).
Если требование не является обязательным к реализации, то оно должно
быть просто исключено из набора требований. Если требование нужное,
но «не очень важное», для указания этого факта используется указание
приоритета (см. «проранжированность по...»). Также должны быть
исключены (или переработаны) требования, утратившие актуальность.

68.

Прослеживаемость (traceability). Прослеживаемость бывает вертикальной (vertical
traceability) и горизонтальной (horizontal traceability). Вертикальная
прослеживаемость позволяет соотносить между собой требования на различных
уровнях требований, горизонтальная - соотносить требование с тест-планом, тесткейсами, архитектурными решениями и т.д. Для обеспечения прослеживаемости
часто используются специальные инструменты по управлению требованиями
(requirements management tool) и/или матрицы прослеживаемости (traceability
matrix).
Модифицируемость (modifiability) - это свойство характеризует внесения
изменений в отдельные требования и в набор требований. Можно говорить о
наличии модифицируемости в том случае, если, при доработке требований,
искомую информацию легко найти, а её изменение не приводит к нарушению иных
описанных в этом перечне свойств.

69.

Проранжированность по важности, стабильности, срочности (ranked
for importance, stability, priority). Важность характеризует зависимость
успеха проекта от успеха реализации требования. Стабильность
характеризует вероятность того, что в ближайшем будущем в требование
не будет внесено никаких изменений. Срочность определяет
распределение по времени усилий проектной команды по реализации того
или иного требования.

70.

Корректность (correctness) ипроверяемость(verifiability).
Фактически, эти свойства вытекают из соблюдения всех
вышеперечисленных (или ,можно сказать, они не выполняются,
если нарушено хотя бы одно из вышеперечисленных). В
дополнение, можно отметить, что проверяемость
подразумевает возможность создания объективного тест-кейса
(тест-кейсов), однозначно показывающего, что требование
реализовано верно и поведение приложения в точности
соответствует требованию.

71.

Техники тестирования требований

72.

Тестирование документации и требований относится к
разряду нефункционального тестирования (non-functional
testing). Основные техники такого тестирования в контексте
требований таковы:
Взаимный просмотр (peer review) или «рецензирование»
является одной из наиболее активно используемых техник
тестирования требований и может быть представлен в одной
из трёх следующих форм (по мере нарастания его сложности
и цены):

73.

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

74.

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

75.

Технический просмотр (technical review) выполняется
группой специалистов. В идеальной ситуации - каждый
специалист должен представлять свою область знаний.
Тестируемый продукт не может считаться достаточно
качественным, пока хотя бы у одного просматривающего
остаются замечания.

76.

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

77.

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

78.

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

79.

Вопросы. Следующей очевидной техникой тестирования и
повышения качества требований является использование (повторное)
техник выявления требований, а также (как отдельный вид
деятельности) — постановка вопросов. Если хоть что-то в
требованиях вызывает у вас непонимание или подозрение, то
задавайте вопросы. Можно спросить представителей заказчика или
же обратиться к справочной информации. По многим вопросам
можно обратиться к более опытным коллегам при условии, что у них
имеется соответствующая информация, ранее полученная от
заказчика. Главное, чтобы Ваш вопрос был сформулирован таким
образом, чтобы полученный ответ позволил улучшить требования.