QA Engineer - Михаил Семынин

требований со стороны QA инженеров маловероятно.

— User Requirements — изложение ожиданий конечных пользователей. Чаще всего оформляются в виде пользовательских историй или сценариев. Этот уровень тоже обычно не тестируют QA инженеры, хотя такое случается. Используя эти требования, QA инженер может представить абстракции того, как будут выглядеть его проверки.

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

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

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

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

Требования могут быть качественными или нет.

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

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

— Измеримость — должен существовать способ проверить, выполнено требование или нет.

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

— Атомарность — требование должно быть настолько неделимым, насколько это возможно.

— Релевантность — требование должно быть важным для бизнес — целей проекта.

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

— Непротиворечивость — требования не могут противоречить друг другу, они должны быть согласованы.

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

— Проверяемость — должна быть возможность протестировать требование, чтобы определить, что система его выполняет.

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

— Проранжированность — требования должны быть отсортированы в соответствии с важностью целей.

Далее рассмотрим примеры критериев качества требований. Учтите, что каждый пример описывает конкретный критерий, но для простоты может намеренно нарушать другие.

Пример конкретности требования

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

Пример измеримости требования

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

Пример достижимости требования

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

Пример атомарности требования

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

Пример релевантности требования

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

Пример полноты требования

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

Пример непротиворечивости требования

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

Пример модифицируемости требования

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

Пример проверяемости требования

В хорошем примере существует однозначный способ проверить во время тестирования, выполнено ли требование. В то же время, «приятный» пользовательский интерфейс является очень субъективным понятием.

Пример отслеживаемости требования

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

Пример проранжированности требования

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