QA Engineer

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

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

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

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

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

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

4.5. Требования

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

Например:

— Площадь квадрата вычислять по формуле S=a2, где S — площадь, а — длина стороны.

— При открытии Door_127 запускается NPC типа Guard_5, находящийся в Room_34 и запускается скрипт NPC Atack_360.

— Данные хранить в SQL таблице Users с полями: ID (int, unique, not null), login (varchar, unique, not null), password (varchar, not null).

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

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

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

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

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

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

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

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

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

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

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

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