Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

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

2 <h2>Что такое требования</h2>

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

4 <ul><li>Текста</li>

5 <li>Изображений - например, в виде макетов страниц</li>

6 <li>Блок-схем</li>

7 <li>А также в других форматах</li>

8 </ul><h2>Кто определяет требования</h2>

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

10 <ul><li>Сначала вся команда продумывает идею приложения и определяет, какая функциональность должна в нем быть - самые базовые требования создаются именно на этом этапе</li>

11 <li>Дальше программисты разрабатывают приложение и сверяются, все ли требования выполнены</li>

12 <li>Дальше приложением занимаются тестировщики - они смотрят, соответствует ли реализованное приложение заданным требованиям</li>

13 </ul><p>Кроме того, требования могут прийти от:</p>

14 <ul><li>Пользователей. Они могут написать отзыв и предложить какую-то новую функцию, которая кажется им полезной</li>

15 <li>Конкурентов. Аналитики нашей компании могут изучить продукты конкурентов и предложить функциональность, как у них</li>

16 <li>Законодательства. В законе могут быть прописаны какие-нибудь обязательные моменты, которые должны быть в приложении. Самый наглядный пример - закон о защите персональных данных, который описывает, как хранить данные пользователей и какие технологии использовать</li>

17 <li>Экспертов в предметной области. Например, сотрудники банков могут предлагать новые фичи для банковского приложения, потому что они знают, как люди пользуются картами и счетами</li>

18 <li>Команд других продуктов. Иногда появляются требования, необходимые для интеграции с другим продуктом. Например, ваше приложение должно работать в связке с другим продуктом, у которого свои протоколы и интерфейсы - нужно под них подстроиться</li>

19 </ul><h2>Функциональные и нефункциональные требования</h2>

20 <p>В тестировании требования делятся на две категории:</p>

21 <ul><li><strong>Функциональные</strong>- описывают основные действия, которые должна выполнять система. Они играют важную роль в разработке, поэтому команда тщательно обдумывает все формулировки. Например, для интернет-магазина функция "Добавить товар в корзину" будет функциональной, потому что без нее приложение не имеет смысла</li>

22 <li><strong>Нефункциональные</strong>- определяют свойства системы, которые не связаны с ее поведением. Например, способность сайта обрабатывать 100 заказов в минуту - это не функциональность, а характеристика производительности</li>

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

24 <h2>Явные и неявные требования</h2>

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

26 <ul><li><strong>Явные</strong>- это конкретные инструкции, техническая документация, спецификации и пользовательские истории</li>

27 <li><strong>Неявные</strong>- это абстрактные представления о продукте, которые возникают из опыта, здравого смысла или стандартов</li>

28 </ul><p>В неявные требования входит все, что нужно продукту, но не обозначено в документации. Для примера представим сайт с кнопками "Да" и "Нет". Если сайт цветной, то у кнопок должен быть какой-то цвет. Если он не описан, то это неявное требование.</p>

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

30 <p>Кроме того, требования бывают<strong>производными</strong>- они не зафиксированные требования, которые вытекают из явных требований и относятся к конкретным аспектам системы.</p>

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

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

33 <h2>Какими должны быть требования</h2>

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

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

36 <ul><li>Ясным</li>

37 <li>Последовательным</li>

38 <li>Не противоречащим другим требованиям, документации и законодательству</li>

39 <li>Атомарным (описывающим только одну функцию)</li>

40 <li>С явным источником требования</li>

41 <li>Актуальным</li>

42 <li>Выполнимым в условиях текущего проекта</li>

43 </ul>