Рабочий процесс тестировщика
2026-02-26 17:10 Diff
https://ru.hexlet.io/courses/qa-engineer-workflow/lessons/program-requirements/theory_unit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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