Требования к программе — Рабочий процесс тестировщика

• Что такое требования
• Кто определяет требования
• Функциональные и нефункциональные требования
• Явные и неявные требования
• Какими должны быть требования

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

Что такое требования

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

• Текста
• Изображений — например, в виде макетов страниц
• Блок-схем
• А также в других форматах

Кто определяет требования

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

• Сначала вся команда продумывает идею приложения и определяет, какая функциональность должна в нем быть — самые базовые требования создаются именно на этом этапе
• Дальше программисты разрабатывают приложение и сверяются, все ли требования выполнены
• Дальше приложением занимаются тестировщики — они смотрят, соответствует ли реализованное приложение заданным требованиям

Кроме того, требования могут прийти от:

• Пользователей. Они могут написать отзыв и предложить какую-то новую функцию, которая кажется им полезной
• Конкурентов. Аналитики нашей компании могут изучить продукты конкурентов и предложить функциональность, как у них
• Законодательства. В законе могут быть прописаны какие-нибудь обязательные моменты, которые должны быть в приложении. Самый наглядный пример — закон о защите персональных данных, который описывает, как хранить данные пользователей и какие технологии использовать
• Экспертов в предметной области. Например, сотрудники банков могут предлагать новые фичи для банковского приложения, потому что они знают, как люди пользуются картами и счетами
• Команд других продуктов. Иногда появляются требования, необходимые для интеграции с другим продуктом. Например, ваше приложение должно работать в связке с другим продуктом, у которого свои протоколы и интерфейсы — нужно под них подстроиться

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

В тестировании требования делятся на две категории:

• Функциональные — описывают основные действия, которые должна выполнять система. Они играют важную роль в разработке, поэтому команда тщательно обдумывает все формулировки. Например, для интернет-магазина функция «Добавить товар в корзину» будет функциональной, потому что без нее приложение не имеет смысла
• Нефункциональные — определяют свойства системы, которые не связаны с ее поведением. Например, способность сайта обрабатывать 100 заказов в минуту — это не функциональность, а характеристика производительности

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

Явные и неявные требования

Еще требования могут отличаться по уровню детализации:

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

В неявные требования входит все, что нужно продукту, но не обозначено в документации. Для примера представим сайт с кнопками «Да» и «Нет». Если сайт цветной, то у кнопок должен быть какой-то цвет. Если он не описан, то это неявное требование.

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

Кроме того, требования бывают производными — они не зафиксированные требования, которые вытекают из явных требований и относятся к конкретным аспектам системы.

Для примера возьмем приложение интернет-магазина с явным требованием «Система должна выдерживать нагрузку в 1000 пользователей». Само по себе это требование не имеет смысла — ведь пользователи не просто заходят посмотреть, но и делают покупки. Значит, нужно сформулировать производное требование «Платежная система должна выдерживать 500 запросов в секунду».

Для тестирования производных требований часто используются запросы к API. Например, они помогают проверить, способен ли сайт принять 100 заказов в минуту — причем без использования интерфейса. Именно так тестируются высоконагруженные системы с десятками и сотнями тысяч запросов в секунду.

Какими должны быть требования

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

Кроме того, хорошее требование должно быть:

• Ясным
• Последовательным
• Не противоречащим другим требованиям, документации и законодательству
• Атомарным (описывающим только одну функцию)
• С явным источником требования
• Актуальным
• Выполнимым в условиях текущего проекта

Дополнительные материалы

1. Основы Программной Инженерии по SWEBOK — программные требования