Разница между тест-кейсом и чек-листом

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

Сила чек-листа в том, что он простой. Там нет глубокой детализации, это просто памятка. К тому же, он довольно наглядный с точки зрения отчетности. Минус в том, что другому человеку может быть сложно вникнуть в суть проверок без деталей и шагов. Чек-листы стали популярнее с приходом гибких моделей разработки, когда писать детальные кейсы может не быть времени и смысла, т.к. всё меняется слишком быстро, к тому же команда может быть небольшой и расписывать кейсы просто не для кого.

Доп. материал:

● Чек-листы: полная лекция

● Составление чек-листов

● Примеры: раз

Баг-репорт (Defect/bug report)

Отчет о дефекте (defect report): Документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. (IEEE 829)

«Смысл написания отчета о проблеме (отчета об ошибке) состоит в том, чтобы исправить ошибки» - Джем Канер. Если тестировщик неправильно сообщает об ошибке, то программист, скорее всего, отклонит эту ошибку, заявив, что она невоспроизводима. Или потратит кучу лишнего времени на то, чтобы сделать вашу работу за вас. Едва ли такой тестировщик будет выгоден бизнесу, приятен коллегам и долго задержится на своем месте.

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

Основные поля баг-репорта:

● Уникальный идентификатор (ID);

● Описание (Summary): краткое, емкое и понятное описание ошибки;

● Окружение (Environment): ссылка на билд/коммит/версия ПО и всего окружения;

● Шаги воспроизведения (Steps to reproduce): полный перечень шагов для воспроизведения;

● Ожидаемый результат (Expected result): какой результат должен был быть без ошибки;

● Фактический результат (Actual result): какой результат получился на самом деле;

● Вложения (Attachments): логи, скриншоты, видео - всё что необходимо для понимания ошибки.

Дополнительные:

● Предварительные условия (Prerequisites);

● Тестовые данные (Test Data);

● Серьезность дефекта (Defect Severity);

● Комментарии (Remarks);

● Проект (Project);

● Продукт (Product);

● Версия релиза (Release Version);

● Модуль (Module);

● Обнаружено в версии (Detected Build Version);

● Вероятность возникновения дефекта (Defect Probability);

● Приоритет дефекта (Defect Priority);

● Автор отчета (Reported By);

● Назначено на (Assigned To);

● Статус (Status);

● Fixed Build Version.

В случаях использования TMS поля будут настроены лидом/менеджером и в зависимости от размеров проекта могут быть пункты вроде milestone, epic, feature и т.п.

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

Несколько ключевых моментов, которые следует учитывать при написании отчета об ошибке:

● В одном отчете один баг;

● Воспроизведите его 2-3 раза;

● Убедитесь, что используете актуальную версию ПО и окружения;

● Проверьте по поиску багтрекинговой системы наличие отчета о таком же дефекте;

● Локализуйте ошибку, чтобы выяснить ее первопричину;

● Напишите подробные шаги и полное окружение для воспроизведения ошибки;

● Напишите хорошее summary дефекта по формуле “Что? Где? При каких условиях?”;

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

● Проиллюстрируйте проблему с помощью правильных скриншотов, видео и логов;

● Перед отправкой перепроверьте ваш отчет об ошибке. А потом еще раз;

Источники:

● How To Write Good Bug Report

Требования (Requirements)

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

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

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

Требования начинают свою жизнь на стороне заказчика. Их сбор (gathering) и выявление (elicitation) осуществляются с помощью следующих основных техник:

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

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

● Анкетирование. Этот вариант выявления требований вызывает много споров, т.к. при неверной реализации может привести к нулевому результату при объемных затратах. В то же время при правильной организации анкетирование позволяет автоматически собрать и обработать огромное количество ответов от огромного количества респондентов. Ключевым фактором успеха является правильное составление анкеты, правильный выбор аудитории и правильное преподнесение анкеты.

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

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

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

● Анализ документов. Хорошо работает тогда, когда эксперты в предметной области (временно) недоступны, а также в предметных областях, имеющих общепринятую устоявшуюся регламентирующую документацию. Также к этой технике относится и просто изучение документов, регламентирующих бизнес-процессы в предметной области заказчика или в конкретной организации, что позволяет приобрести необходимые для лучшего понимания сути проекта знания.

● Моделирование процессов и взаимодействий. Может применяться как к «бизнес-процессам и взаимодействиям» (например: «договор на закупку формируется отделом закупок, визируется бухгалтерией и юридическим отделом…»), так и к «техническим процессам и взаимодействиям» (например: «платежное поручение генерируется модулем “Бухгалтерия”, шифруется модулем “Безопасность” и передаётся на сохранение в модуль “Хранилище”»). Данная техника требует высокой квалификации специалиста по бизнес-анализу, т.к. сопряжена с обработкой большого объема сложной (и часто плохо структурированной) информации.

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

Уровни и типы требований

● Бизнес-требования (business requirements) выражают цель, ради которой разрабатывается продукт (зачем вообще он нужен, какая от него ожидается польза, как заказчик с его помощью будет получать прибыль). Результатом выявления требований на этом уровне является общее видение (vision and scope) — документ, который, как правило, представлен простым текстом и таблицами. Здесь нет детализации поведения системы и иных технических характеристик, но вполне могут быть определены приоритеты решаемых бизнес-задач, риски и т.п. Несколько простых, изолированных от контекста и друг от друга примеров бизнес-требований:

○ Нужен инструмент, в реальном времени отображающий наиболее выгодный курс покупки и продажи валюты;

○ Необходимо в два-три раза повысить количество заявок, обрабатываемых одним оператором за смену;

○ Нужно автоматизировать процесс выписки товарно-транспортных накладных на основе договоров.

● Пользовательские требования (user requirements) описывают задачи, которые пользователь может выполнять с помощью разрабатываемой системы (реакцию системы на действия пользователя, сценарии работы пользователя). Поскольку здесь уже появляется описание поведения системы, требования этого уровня могут быть использованы для оценки объема работ, стоимости проекта, времени разработки и т.д. Пользовательские требования оформляются в виде вариантов использования (use cases), пользовательских историй (user stories), пользовательских сценариев (user scenarios). Несколько простых, изолированных от контекста и друг от друга примеров пользовательских требований:

○ При первом входе пользователя в систему должно отображаться лицензионное соглашение;

○ Администратор должен иметь возможность просматривать список всех пользователей, работающих в данный момент в системе;

○ При первом сохранении новой статьи система должна выдавать запрос на сохранение в виде черновика или публикацию.

● Бизнес-правила (business rules) описывают особенности принятых в предметной области (и/или непосредственно у заказчика) процессов, ограничений и иных правил. Эти правила могут относиться к бизнес-процессам, правилам работы сотрудников, нюансам работы ПО и т.д. Несколько простых, изолированных от контекста и друг от друга примеров бизнес-правил:

○ Никакой документ, просмотренный посетителями сайта хотя бы один раз, не может быть отредактирован или удален;

○ Публикация статьи возможна только после утверждения главным редактором;

○ Подключение к системе извне офиса запрещено в нерабочее время.

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

○ Максимальное время готовности системы к выполнению новой команды после отмены предыдущей не может превышать одну секунду;

○ Внесенные в текст статьи изменения не должны быть утеряны при нарушении соединения между клиентом и сервером;

○ Приложение должно поддерживать добавление произвольного количества неиероглифических языков интерфейса.

● Функциональные требования (functional requirements) описывают поведение системы, т.е. ее действия (вычисления, преобразования, проверки, обработку и т.д.). В контексте проектирования функциональные требования в основном влияют на дизайн системы. Стоит помнить, что к поведению системы относится не только то, что система должна делать, но и то, что она не должна делать (например: «приложение не должно выгружать из оперативной памяти фоновые документы в течение 30 минут с момента выполнения с ними последней операции»). Несколько простых, изолированных от контекста и друг от друга примеров функциональных требований:

○ В процессе инсталляции приложение должно проверять остаток свободного места на целевом носителе;

○ Система должна автоматически выполнять резервное копирование данных ежедневно в указанный момент времени;

○ Электронный адрес пользователя, вводимый при регистрации, должен быть проверен на соответствие требованиям RFC822.

● Нефункциональные требования (non-functional requirements) описывают свойства системы (удобство использования, безопасность, надежность, расширяемость и т.д.), которыми она должна обладать при реализации своего поведения. Здесь приводится более техническое и детальное описание атрибутов качества. В контексте проектирования нефункциональные требования в основном влияют на архитектуру системы. Несколько простых, изолированных от контекста и друг от друга примеров нефункциональных требований:

○ При одновременной непрерывной работе с системой 1000 пользователей, минимальное время между возникновением сбоев должно быть более или равно 100 часов;

○ Ни при каких условиях общий объем используемой приложением памяти не может превышать 2 ГБ;

○ Размер шрифта для любой надписи на экране должен поддерживать настройку в диапазоне от 5 до 15 пунктов.

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

● Ограничения (limitations, constraints) представляют собой факторы, ограничивающие выбор способов и средств (в том числе инструментов) реализации продукта. Несколько простых, изолированных от контекста и друг от друга примеров ограничений:

○ Все элементы интерфейса должны отображаться без прокрутки при разрешениях экрана от 800x600 до 1920x1080;

○ Не допускается использование Flash при реализации клиентской части приложения;

○ Приложение должно сохранять способность реализовывать функции с уровнем важности «критический» при отсутствии у клиента поддержки JavaScript.

● Требования к интерфейсам (external interfaces requirements) описывают особенности взаимодействия разрабатываемой системы с другими системами и операционной средой. Несколько простых, изолированных от контекста и друг от друга примеров требований к интерфейсам:

○ Обмен данными между клиентской и серверной частями приложения при осуществлении фоновых AJAX-запросов должен быть реализован в формате JSON;

○ Протоколирование событий должно вестись в журнале событий операционной системы;

○ Соединение с почтовым сервером должно выполняться согласно RFC3207 («SMTP over TLS»).

● Требования к данным (data requirements) описывают структуры данных (и сами данные), являющиеся неотъемлемой частью разрабатываемой системы. Часто сюда относят описание базы данных и особенностей её использования. Несколько простых, изолированных от контекста и друг от друга примеров требований к данным:

○ Все данные системы, за исключением пользовательских документов, должны храниться в БД под управлением СУБД MySQL, пользовательские документы должны храниться в БД под управлением СУБД MongoDB;

○ Информация о кассовых транзакциях за текущий месяц должна храниться в операционной таблице, а по завершении месяца переноситься в архивную;

○ Для ускорения операций поиска по тексту статей и обзоров должны быть предусмотрены полнотекстовые индексы на соответствующих полях таблиц.

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

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

○ Отсутствуют нефункциональные составляющие требования или ссылки на соответствующие нефункциональные требования (например: «пароли должны храниться в зашифрованном виде» — каков алгоритм шифрования?);

○ Указана лишь часть некоторого перечисления (например: «экспорт осуществляется в форматы PDF, PNG и т.д.» — что мы должны понимать под «и т.д.»?);

○ Приведённые ссылки неоднозначны (например: «см. выше» вместо «см. раздел 123.45.b»).

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

○ В одном требовании, фактически, содержится несколько независимых (например: «кнопка “Restart” не должна отображаться при остановленном сервисе, окно “Log” должно вмещать не менее 20-ти записей о последних действиях пользователя» — здесь зачем-то в одном предложении описаны совершенно разные элементы интерфейса в совершенно разных контекстах);

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

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

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

○ Противоречия внутри одного требования (например: «после успешного входа в систему пользователя, не имеющего права входить в систему…» — тогда как он успешно вошёл в систему, если не имел такого права?);

○ Противоречия между двумя и более требованиями, между таблицей и текстом, рисунком и текстом, требованием и прототипом и т.д. (например: «712.a Кнопка “Close” всегда должна быть красной» и «36452.x Кнопка “Close” всегда должна быть синей» — так всё же красной или синей?);

○ Использование неверной терминологии или использование разных терминов для обозначения одного и того же объекта или явления (например: «в случае, если разрешение окна составляет менее 800x600…» — разрешение есть у экрана, у окна есть размер).

● Недвусмысленность (unambiguousness, clearness). Требование должно быть описано без использования жаргона, неочевидных аббревиатур и расплывчатых формулировок, должно допускать только однозначное объективное понимание и быть атомарным в плане невозможности различной трактовки сочетания отдельных фраз. Типичные проблемы с недвусмысленностью:

○ Использование терминов или фраз, допускающих субъективное толкование (например: «приложение должно поддерживать передачу больших объемов данных» — насколько «больших»?) Вот лишь небольшой перечень слов и выражений, которые можно считать верными признаками двусмысленности: адекватно (adequate), быть способным (be able to), легко (easy), обеспечивать (provide for), как минимум (as a minimum), быть способным (be capable of), эффективно (effectively), своевременно (timely), применимо (as applicable), если возможно (if possible), будет определено позже (to be determined, TBD), по мере необходимости (as appropriate), если это целесообразно (if practical), но не ограничиваясь (but not limited to), быть способно (capability of), иметь возможность (capability to), нормально (normal), минимизировать (minimize), максимизировать (maximize), оптимизировать (optimize), быстро (rapid), удобно (user-friendly), просто (simple), часто (often), обычно (usual), большой (large), гибкий (flexible), устойчивый (robust), по последнему слову техники (state-of-the-art), улучшенный (improved), результативно (efficient). Вот утрированный пример требования, звучащего очень красиво, но совершенно нереализуемого и непонятного: «В случае необходимости оптимизации передачи больших файлов система должна эффективно использовать минимум оперативной памяти, если это возможно»;

○ Использование неочевидных или двусмысленных аббревиатур без расшифровки (например: «доступ к ФС осуществляется посредством системы прозрачного шифрования» и «ФС предоставляет возможность фиксировать сообщения в их текущем состоянии с хранением истории всех изменений» — ФС здесь обозначает файловую систему? Точно? А не какой-нибудь «Фиксатор Сообщений»?);

○ Формулировка требований из соображений, что нечто должно быть всем очевидно (например: «Система конвертирует входной файл из формата PDF в выходной файл формата PNG» — и при этом автор считает совершенно очевидным, что имена файлов система получает из командной строки, а многостраничный PDF конвертируется в несколько PNG-файлов, к именам которых добавляется «page-1», «page-2» и т.д.). Эта проблема перекликается с нарушением корректности.

● Выполнимость (feasibility). Требование должно быть технологически выполнимым и реализуемым в рамках бюджета и сроков разработки проекта. Типичные проблемы с выполнимостью:

○ Так называемое «озолочение» (gold plating) — требования, которые крайне долго и/или дорого реализуются и при этом практически бесполезны для конечных пользователей (например: «настройка параметров для подключения к базе данных должна поддерживать распознавание символов из жестов, полученных с устройств трёхмерного ввода»).

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

○ В принципе нереализуемые требования (например: «система поиска должна заранее предусматривать все возможные варианты поисковых запросов и кэшировать их результаты»).

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

○ Требование было добавлено «на всякий случай», хотя реальной потребности в нём не было и нет;

○ Требованию выставлены неверные значения приоритета по критериям важности и/или срочности;

○ Требование устарело, но не было переработано или удалено.

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

○ Требования не пронумерованы, не структурированы, не имеют оглавления, не имеют работающих перекрестных ссылок;

○ При разработке требований не были использованы инструменты и техники управления требованиями;

○ Набор требований неполный, носит обрывочный характер с явными «пробелами».

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

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

○ Требования изначально противоречивы (см. «непротиворечивость»). В такой ситуации внесение изменений (не связанных с устранением противоречивости) только усугубляет ситуацию, увеличивая противоречивость и снижая прослеживаемость;

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

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

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

○ Проблемы с проранжированностью по стабильности повышают риск выполнения бессмысленной работы по совершенствованию, реализации и тестированию требований, которые в самое ближайшее время могут претерпеть кардинальные изменения (вплоть до полной утраты актуальности);

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

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

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

○ наличие неаргументированных требований к дизайну и архитектуре;

○ плохое оформление текста и сопутствующей графической информации, грамматические, пунктуационные и иные ошибки в тексте;

○ неверный уровень детализации (например, слишком глубокая детализация требования на уровне бизнес-требований или недостаточная детализация на уровне требований к продукту);

○ требования к пользователю, а не к приложению (например: «пользователь должен быть в состоянии отправить сообщение» — увы, мы не можем влиять на состояние пользователя).

Источники требований:

● Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения);

● Нормативное обеспечение организации (регламенты, положения, уставы, приказы);

● Текущая организация деятельности объекта автоматизации;

● Модели деятельности (диаграммы бизнес-процессов);

● Представления и ожидания потребителей и пользователей системы;

● Журналы использования существующих программно-аппаратных систем;

● Конкурирующие программные продукты.

Виды документов требований:

● Спецификация требований к программному обеспечению (SRS - Software Requirement Specification): представляет собой документ, подготовленный группой системных аналитиков (system analysts), который используется для описания программного обеспечения, которое будет разработано, основной бизнес-цели и функциональности определенного продукта, а также того, как он выполняет свои основные функции. В организациях, которые используют SRS, они обычно очень похожи на то, что описывается в PRD и FSD. SRS - это основа любого проекта, поскольку он состоит из структуры, которой будет следовать каждый член команды. SRS также является основой контракта с заинтересованными сторонами (пользователями / клиентами), который включает в себя все подробности о функциональности будущего продукта и о том, как он должен работать. SRS широко используется разработчиками программного обеспечения в процессе разработки продукта или программы. SRS включает как функциональные, так и нефункциональные требования, а также варианты использования. В идеальном документе SRS учитывается не только то, как программное обеспечение будет взаимодействовать с другим программным обеспечением или когда оно встроено в оборудование, но также потенциальных пользователей и способы их взаимодействия с программным обеспечением. Он также содержит ссылки на таблицы и диаграммы, чтобы получить четкое представление обо всех деталях, связанных с продуктом. Документ SRS помогает членам команды из разных отделов оставаться в единстве и обеспечивать выполнение всех требований. Этот документ также позволяет минимизировать затраты и время на разработку программного обеспечения.;

● Спецификация бизнес-требований (BRS - Business Requirement Specification): BRS - это спецификация бизнес-требований, цель которой - показать, как удовлетворить бизнес-требования на более широком уровне. Документ BRS является одним из наиболее широко распространенных документов со спецификациями. Это очень важно, и BRS обычно создается в самом начале жизненного цикла продукта и описывает основные цели продукта или потребности, которые клиент хочет достичь с помощью определенного программного обеспечения или продукта. Он обычно создается бизнес-аналитиком (business analyst) на основе спецификаций других заинтересованных сторон и после тщательного анализа компании-клиента. Обычно окончательная версия документа проверяется клиентом, чтобы убедиться, что ожидания всех заинтересованных сторон бизнеса верны. BRS включает в себя все требования, запрошенные клиентом. Как правило, он состоит из цели продукта, пользователей, общего объема работ, всех перечисленных функций и возможностей, требований к удобству использования и производительности. В этот тип документа не включены варианты использования, а также диаграммы и таблицы. BRS используется в основном высшим и средним менеджментом, инвесторами в продукты, бизнес-аналитиками;

● Спецификация функциональных требований (FRS - Functional Requirement Specification): документ, в котором описаны все функции, которые должно выполнять программное обеспечение или продукт. Фактически, это пошаговая последовательность всех операций, необходимых для разработки продукта от начала до конца. FRS объясняет подробности того, как определенные программные компоненты будут вести себя во время взаимодействия с пользователем. Этот документ создан квалифицированными разработчиками и инженерами и считается результатом тесного сотрудничества между тестировщиками и разработчиками. Основное отличие от документа SRS заключается в том, что FRS не включает варианты использования. Он также может содержать диаграммы и таблицы, но это не обязательно. Этот документ является наиболее подробным, поскольку в нем подробно объясняется, как программное обеспечение должно функционировать (включая бизнес-аспекты, соответствие требованиям, требования безопасности), поскольку оно также должно удовлетворять всем требованиям, упомянутым в документах SRS и BRS. FRS помогает разработчикам понять, какой продукт они должны создать, а тестировщики программного обеспечения лучше разбираются в различных тестовых примерах и сценариях, в которых ожидается тестирование продукта;

● Документ бизнес-требований (BRD - Business Requirements Document, Business Needs Specification, Business Requirements): BRD фокусируются на определении бизнес задач проекта. BRD определяет одну или несколько бизнес задач стоящих перед пользователями, которые могут быть решены с помощью продукта компании. После этого предлагается решение – обычно это новый продукт или усовершенствование существующего продукта в нужной части. Он также может включать какой-то предварительный бизнес анализ – прогноз прибылей, анализ рынка и конкурентов, а также стратегию продаж и продвижения. Чаще всего он пишется Менеджером по продукту, Менеджером по маркетингу продукта или Бизнес аналитиком. В маленьких компаниях это может быть даже директор или владелец фирмы;

● Документ требований рынка (MRD - Market Requirements Document): MRD фокусируется на определении требований рынка к предлагаемому новому продукту. Если BRD определяет круг проблем и предлагает вариант их решения – то MRD более подробно описывает детали предлагаемого решения. Он может включать несколько или все нижеприведенные аспекты:

○ Функциональные возможности, необходимые для решения бизнес задач;

○ Анализ рынка и конкурентов;

○ Функциональные и нефункциональные требования;

○ Приоритезацию требований и функциональных возможностей;

○ Варианты использования;

Чаще всего он пишется Менеджером по продукту, Менеджером по маркетингу продукта или Бизнес аналитиком совместно с Системным аналитиком. Некоторые организации объединяют MRD и P