3.

Уровни, виды и методы тестирования

3.1. Уровни тестирования.

Тестирование на разных уровнях производится на протяжении всего жизненного цикла
разработки и сопровождения программного обеспечения. Уровень тестирования определяет то,
над чем производятся тесты: над отдельным модулем, группой модулей или системой, в целом.
Проведение тестирования на всех уровнях системы - это залог успешной реализации и сдачи
проекта.
Выделяют следующие уровни тестирования:
1. Компонентное или Модульное тестирование (Component Testing or Unit Testing);
2. Интеграционное тестирование (Integration Testing);
3. Системное тестирование (System Testing);
4. Приемочное тестирование (Acceptance Testing).

1. Компонентное или Модульное тестирование (Component or Unit Testing)

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

2. Интеграционное тестирование (Integration Testing)

Интеграционное тестирование предназначено для проверки связи между компонентами, а
также взаимодействия с различными частями системы (операционной системой,
оборудованием либо связи между различными системами). Например, тестирование сайта в
различных браузерах - это интеграционное тестирование.
3. Системное тестирование (System Testing)
Основной задачей системного тестирования является проверка как функциональных, так и
не функциональных требований в системе в целом. При этом выявляются дефекты, такие как
неверное использование ресурсов системы, не предусмотренные комбинации данных
пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии
использования, отсутствующая или неверная функциональность, неудобство использования и
т.д. Для минимизации рисков, связанных с особенностями поведения системы в той или иной
среде, во время тестирования рекомендуется использовать окружение максимально
приближенное к тому, на которое будет установлен продукт после выдачи.
 4. Приемочное тестирование или Приемо-сдаточное испытание (Acceptance Testing)
Формальный процесс тестирования, который проверяет соответствие системы требованиям и
проводится с целью:
● определения удовлетворяет ли система приемочным критериям;
● вынесения решения заказчиком или другим уполномоченным лицом принимается
приложение или нет.
Приемочное тестирование выполняется на основании набора типичных тестовых случаев и
сценариев, разработанных на основании требований к данному приложению. Решение о
проведении приемочного тестирования принимается, когда:
● продукт достиг необходимого уровня качества;
● заказчик ознакомлен с Планом Приемочных Работ (Product Acceptance Plan) или иным
документом, где описан набор действий, связанных с проведением приемочного
тестирования, дата проведения, ответственные и т.д.
Фаза приемочного тестирования длится до тех пор, пока заказчик не выносит решение об
отправлении приложения на доработку или выдаче приложения.

3.2. Виды тестирования.

Все виды тестирования программного обеспечения, в зависимости от преследуемых целей,
можно условно разделить на следующие группы:
1. функциональные;
2. нефункциональные;
3. связанные с изменениями.
1. Функциональные виды тестирования
Функциональные виды тестирования рассматривают внешнее поведение системы. Одни из
самых распространенных видов функционального тестирования:
● функциональное тестирование (Functional testing);
● тестирование безопасности (Security and Access Control Testing);
● тестирование взаимодействия (Interoperability Testing).

Функциональное тестирование (Functional testing) - рассматривает предварительно заданное

поведение программы, опираясь на анализ всей системы и спецификации функциональности
элемента.
Тестирование безопасности (Security and Access Control Testing) - проверяет всю систему на
предмет безопасной работы. Помогает провести анализ рисков, которые связаны с
организацией защиты программы от различных вирусов и взломщиков, неправомерного
проникновения для просмотра секретной информации.
Тестирование взаимодействия (Interoperability Testing) - тестирует приложение на
возможность одновременного взаимодействия с одним или несколькими модулями или
внешними приложениями. Включает в себя интеграционное тестирование и тестирование на
совместимость.

2. Нефункциональные виды тестирования

Нефункциональное тестирование определяет характеристики программного обеспечения,
которые могут быть измерены различными величинами. В целом, это тестирование того, как
система работает. Основные виды нефункционального тестирования:
● все виды тестирования производительности:
○ нагрузочное тестирование (Performance and Load Testing);
 ○ стрессовое тестирование (Stress Testing);
○ тестирование стабильности или надежности (Stability / Reliability Testing);
○ объемное тестирование (Volume Testing);
● тестирование установки (Installation testing);
● тестирование удобства пользования (Usability Testing);
● тестирование на отказ и восстановление (Failover and Recovery Testing);
● конфигурационное тестирование (Configuration Testing).

Нагрузочное тестирование (Performance and Load Testing)- эмулирует работу большого

количества пользователей на каком-то ресурсе.

Стрессовое тестирование (Stress Testing) - проверяет работоспособность приложения в

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

Тестирование стабильности или надежности (Stability / Reliability Testing) - во время этого

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

Объемное тестирование (Volume Testing) - задача такого тестирования – получить оценку

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

Тестирование установки (Installation testing) - проверяет инсталляцию и ее настройки,

обновления и удаление ПО.

Тестирование удобства пользования (Usability Testing) - этот метод тестирования направлен на

определение степени удобности применения, понятности и привлекательности для
пользователей.

Тестирование на отказ и восстановление (Failover and Recovery Testing)- делает проверку

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

Конфигурационное тестирование (Configuration Testing)- проверяет персональный компьютер

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

3. Связанные с изменениями виды тестирования

После проведения необходимых изменений, таких как исправление бага/дефекта,
программное обеспечение должно быть перетестировано для подтверждения того факта, что
проблема была действительно решена. Ниже перечислены виды тестирования, которые
необходимо проводить после установки программного обеспечения, для подтверждения
работоспособности приложения или правильности осуществленного исправления дефекта:
● дымовое тестирование (Smoke Testing);
● регрессионное тестирование (Regression Testing);
● тестирование сборки (Build Verification Test);
● повторное;
● санитарное тестирование или проверка согласованности/исправности (Sanity Testing).
Дымовое тестирование (Smoke Testing)- можно рассматривать в виде нескольких небольших
тестов, которые выполняются для подтверждения того, что необходимое приложение
нормально запускается и выполняет свои функции после сборки кода.

Повторное тестирование- выполняет проверочные скрипты, выявляющие ошибки в момент

последнего запуска. Это нужно для подтверждения того, что ошибки исправлены.

Регрессионное тестирование (Regression Testing) - этот вид тестирования проверяет, что

внесенные изменения не повлияли на работу функционала, разработанного ранее.

Тестирование сборки (Build Verification Test)- дает возможность определить соответствие

выпущенной версии основным параметрам качества.

Санитарное тестирование или проверка согласованности/исправности (Sanity Testing) -

проверяет работу определенной функции согласно прописанным требованиям, представляет
собой разновидность регрессионного тестирования. Применяется с целью проверки работы
какого-то фрагмента программы после внесения изменений в текущий или связанные модули.

Также отдельным пунктом стоит выделить Тестирование пользовательского интерфейса

(UI). Проводится абсолютный тест по следующим пунктам:
1. соответствие реализации прототипу дизайна;
2. тестирование навигации (переходов) между компонентами;
3. адаптивность верстки для различных устройств.

3.3. Методы тестирования.

Существуют различные методы, которые обычно используют для тестирования
программного обеспечения:
1. Тестирование Black-Box;
2. Тестирование White-box;
3. Тестирование Gray-box.

Тестирование Black-Box
Методика тестирования без каких-либо знаний о внутренней работе приложения называется
«черным ящиком». Тестировщик не обращает внимания на архитектуру системы и не имеет
доступа к исходному коду. Как правило, при выполнении теста с «черным ящиком» он будет
взаимодействовать с пользовательским интерфейсом системы, предоставляя входные данные и
анализируя выходы, не зная, как и где обрабатываются входы.
Метод «черного ящика» выгодно применять, если вы ищете:
○ неправильно реализованные функции приложения или сервиса;
○ ошибки в пользовательском интерфейсе;
○ ошибки в функциональных спецификациях.
Достоинства метода:
○ тестирование методом «черного ящика» позволяет найти ошибки, которые невозможно
обнаружить методом «белого ящика». Простейший пример: разработчик забыл добавить
какую-то функциональность. С точки зрения кода все работает идеально, но с точки
зрения спецификации это – сверх критичный баг.
 ○ «Черный ящик» позволяет быстро выявить ошибки в функциональных спецификациях
(в них описаны не только входные значения, но и то, что мы должны в итоге получить).
Если полученный при тестировании результат отличается от заявленного в
спецификации, то у нас появляется повод для общения с аналитиком для уточнения
конечного результата.
○ тестировщику не нужна дополнительная квалификация. Часто мы пользуемся
различными сервисами и приложениями, не очень в них разбираясь. Для того, чтобы
открыть инстаграм и обработать свою фотографию, нам совсем не нужно знать способ
реализации фильтров. Мы хотим открыть фотографию, выбрать фильтр и получить
красивую картинку на выходе. Задача тестировщика, который тестирует эту функцию в
инстаграм, – убедиться, что пользователь получит эту самую красивую картинку в
соответствии с выбранным фильтром. При этом нам совсем не обязательно иметь какую-
либо специализацию – нужны лишь телефон и инстаграм.
○ тестирование проходит «с позиции пользователя». Пользователь всегда прав, он
конечный потребитель практически любого ПО, а значит, ему должно быть удобно,
комфортно и понятно.
○ составлять тест-кейсы можно сразу после подготовки спецификации. Это значительно
сокращает время на тестирование: к тому моменту, как продукт готов к тестированию,
тест-кейсы уже разработаны, и тестировщик может сразу приступать к проверке.
Недостатки метода:
○ основным недостатком метода «черного ящика» является возможность пропуска
границ и переходов, которые не очевидны из спецификации, но есть в реализации кода
(собственно, это и заставляет тестировщиков использовать метод «белого ящика»).
Вспоминается случай, когда система получала котировки валют с биржи Forex и
округляла до 3 знаков после запятой. Система успешно прошла тестирование методом
«черного ящика» (так как ни одна валюта не выходила за соответствующие границы) и
хорошо работала до тех пор, пока курс доллара к биткоин не вышел за границы 1000
долларов. Тестирование «белым ящиком» выявило бы ошибку: специалист увидел бы,
что коэффициент конверсии валюты ограничен 3 знаками.
○ можно протестировать только небольшое количество возможных вводных (входящих)
значений, многие варианты остаются без проверки.
○ тесты могут быть избыточными, если разработчик уже проверил данную
функциональность (например, Unit-тестом).
○ при отсутствии четкой и полной спецификации проектировать тесты и тест-сценарии
оказывается затруднительно.

Тестирование White-box
Проверка белого ящика - это подробное исследование внутренней логики и структуры кода.
Тестирование с использованием белого ящика также называется тестированием стекла или
открытым тестированием . Чтобы выполнить тестирование белого ящика в приложении,
тестировщик должен знать внутреннюю работу кода, должен уметь заглянуть внутрь него и
выяснить, какой блок кода ведет себя некорректно. Поэтому, как правило, таким видом
тестирования на проектах занимаются сами программисты.
Достоинства метода:
– тестирование может производиться на ранних этапах: нет необходимости ждать создания
пользовательского интерфейса;
– можно провести более тщательное тестирование, с покрытием большого количества путей
выполнения программы.
 Недостатки метода:
– для выполнения тестирования белого ящика необходимо большое количество специальных
знаний;
– при использовании автоматизации тестирования на этом уровне, поддержка тестовых
скриптов может оказаться достаточно накладной, если программа часто изменяется.

Тестирование Gray-box
Тестирование Gray-box - это метод тестирования программного продукта или приложения с
частичным знанием его внутреннего устройства. Для выполнения тестирования «серого
ящика» нет необходимости в доступе тестировщика к исходному коду. Тесты пишутся на
основе знания алгоритма, архитектуры, внутренних состояний или других высокоуровневых
описаний поведения программы.
Достоинства метода:
○ тестирование серого ящика включает в себя плюсы тестирования «черного» и «белого».
Другими словами, тестировщик смотрит на объект тестирования с позиции «черного»
ящика, но при этом проводит анализ на основе тех данных, что он знает о системе;
○ тестировщик может проектировать и использовать более сложные сценарии
тестирования;
○ тестировщик работает совместно с разработчиком, что позволяет на начальном этапе
убрать избыточные тест-кейсы. Это сокращает время функционального и
нефункционального тестирования и положительно влияет на общее качество продукта;
○ предоставляет разработчику достаточно времени для исправления дефектов.
Недостатки метода:
○ возможность анализа кода и тестового покрытия ограничена, так как доступ к исходному
коду отсутствует;
○ тесты могут быть избыточными в том случае, когда разработчик также проверяет свой
код Unit-тестами;
○ нельзя протестировать все возможные потоки ввода и вывода, поскольку на это
требуется слишком много времени.
Таким образом, метод «серого ящика» помогает в следующих случаях:
○ когда нет возможности использовать «белый ящик»;
○ когда необходимо более полное покрытие по сравнению с «черным ящиком».

4. Тестирование требований
Что такое «требование»?
Требование (requirement) — описание того, какие функции и с соблюдением каких условий
должно выполнять приложение в процессе решения полезной для пользователя задачи.
Требования являются отправной точкой для определения того, что проектная команда будет
проектировать, реализовывать и тестировать. Элементарная логика говорит нам, что если в
требованиях что-то «не то», то и реализовано будет «не то», т.е. колоссальная работа
множества людей будет выполнена впустую.
Важно отметить, что требования:
1. позволяют понять, что и с соблюдением каких условий система должна делать;
 2. предоставляют возможность оценить масштаб изменений и управлять изменениями;
3. являются основой для формирования плана проекта (в том числе плана тестирования);
4. помогают предотвращать или разрешать конфликтные ситуации;
5. упрощают расстановку приоритетов в наборе задач;
6. позволяют объективно оценить степень прогресса в разработке проекта.
Поскольку мы постоянно говорим «документация и требования», а не просто «требования»,
то стоит рассмотреть перечень документации, которая должна подвергаться тестированию в
процессе разработки ПО.
В общем случае документацию можно разделить на два больших вида в зависимости от
времени и места её использования :
1. Продуктная документация (product documentation, development documentation) -
используется проектной командой во время разработки и поддержки продукта. Она
включает:
- план проекта (project management plan) и в том числе тестовый план (test
plan51);
- требования к программному продукту (product requirements document, PRD) и
функциональные спецификации (functional specifications document, FSD;
software requirements specification, SRS);
- архитектуру и дизайн (architecture and design);
- тест-кейсы и наборы тест-кейсов (test cases, test suites);
- технические спецификации (technical specifications), такие как схемы баз
данных, описания алгоритмов, интерфейсов и т.д.
2. Проектная документация (project documentation) включает в себя как продуктную
документацию, так и некоторые дополнительные виды документации и используется
не только на стадии разработки, но и на более ранних и поздних стадиях (например, на
стадии внедрения и эксплуатации). Она включает:
- пользовательскую и сопроводительную документацию (user and accompanying
documentation), такую как встроенная помощь, руководство по установке и
использованию, лицензионные соглашения и т.д.
- маркетинговую документацию (market requirements document, MRD), которую
представители разработчика или заказчика используют как на начальных этапах (для
уточнения сути и концепции проекта), так и на финальных этапах развития проекта
(для продвижения продукта на рынке).

Requirements start life on the customer's side. Their collection and identification is carried out using
the following techniques:
Interview. The most universal way to identify requirements is to communicate between the project
specialist and the customer's representative. The interview can take place in the classical sense of the
word (conversation in the form of a "question-answer"), in the form of correspondence, etc. The main
thing here is that there are two key figures - the interviewee and the interviewer (although this does
not exclude the presence of an “audience of listeners”, for example, in the form of persons included in
the copy of the correspondence).
Working with focus groups. It can act as a variant of the "extended interview", where the source of
information is not one person, but a group of people.
Questioning. This option for identifying requirements is highly controversial. if implemented
incorrectly, it can lead to zero results at volumetric costs. At the same time, if properly organized, the
questionnaire can automatically collect and process a huge number of responses from a huge number
of respondents. The key success factor is the correct formulation, the correct audience selection and
the correct presentation of the questionnaire.
Seminars and brainstorming. Seminars allow a group of people to very quickly exchange information
(and clearly demonstrate certain ideas), and also work well with interviews, questionnaires,
prototyping and modeling - including for discussing results and forming conclusions and decisions.
Brainstorming can be done as part of a workshop or as a separate activity. It allows you to generate a
large number of ideas in the shortest possible time, which in the future can be slowly considered from
the point of view of their use for the development of the project.
Observation. It can be expressed both in literal observation of certain processes, and in the inclusion
of a project specialist in these processes as a participant. On the one hand, observation allows you to
see what the interviewees, respondents and representatives of focus groups can keep silent about, but
on the other hand, it takes a lot of time and most often allows you to see only part of the processes.
Prototyping. It consists in demonstrating and discussing intermediate versions of the product (for
example, the design of the site pages can be first presented in the form of pictures, and only then laid
out). This is one of the best ways to find a common understanding and clarification of requirements,
but it can lead to serious additional costs in the absence of special tools (allowing rapid prototyping)
and too early application (when the requirements are not yet stable, and there is a high probability of
creating a prototype that has little in common with what the customer wanted).
Analysis of documents. Works well when subject matter experts are (temporarily) unavailable, as well
as subject areas that have well-established, well-established regulatory documentation. This technique
also includes simply the study of documents regulating business processes in the subject area of the
customer or in a specific organization, which allows you to acquire the knowledge necessary for a
better understanding of the essence of the project.
Modeling processes and interactions. Can be applied to both “business processes and interactions”
and “technical processes and interactions”. This technique requires a highly qualified business
analyst, since associated with processing a large amount of complex information.
Self-description. It is not so much a technique for identifying requirements as a technique for fixing
and formalizing them. It is very difficult to try to "come up with the requirements for the customer"
yourself, but in a calm atmosphere you can independently process the collected information and
carefully arrange it for further discussion and clarification.
Интервью. Самый универсальный способ определения требований - общение специалиста
проекта и представителя заказчика. Интервью может проходить в классическом понимании
этого слова (беседа в форме «вопрос-ответ»), в форме переписки и т. Д. Главное здесь то, что
есть две ключевые фигуры - интервьюируемый и собеседник. интервьюер (хотя это не
исключает наличия «аудитории слушателей», например, в виде лиц, включенных в копию
переписки).
Работа с фокус-группами. Он может действовать как вариант «расширенного интервью», когда
источником информации является не один человек, а группа людей.
Анкетирование. Этот вариант определения требований вызывает большие споры. при
неправильной реализации это может привести к нулевым результатам при объемных затратах.
В то же время, при правильной организации анкета может автоматически собирать и
обрабатывать огромное количество ответов от огромного количества респондентов. Ключевым
фактором успеха является правильная формулировка, правильный выбор аудитории и
правильное оформление анкеты.
Семинары и мозговой штурм. Семинары позволяют группе людей очень быстро обмениваться
информацией (и четко демонстрировать определенные идеи), а также хорошо работать с
интервью, анкетами, прототипированием и моделированием, в том числе для обсуждения
результатов и формирования выводов и решений. Мозговой штурм можно провести как часть
семинара или как отдельное мероприятие. Это позволяет в кратчайшие сроки сгенерировать
большое количество идей, которые в будущем можно будет постепенно рассматривать с точки
зрения их использования для развития проекта.
Наблюдение. Это может выражаться как в буквальном наблюдении за определенными
процессами, так и во включении специалиста проекта в эти процессы в качестве участника. С
одной стороны, наблюдение позволяет увидеть, о чем могут молчать интервьюируемые,
респонденты и представители фокус-групп, но с другой стороны, это занимает много времени
и чаще всего позволяет увидеть только часть процессов.
Прототипирование. Он заключается в демонстрации и обсуждении промежуточных версий
продукта (например, дизайн страниц сайта может быть сначала представлен в виде картинок, а
уже потом выложен). Это один из лучших способов найти общее понимание и разъяснение
требований, но он может привести к серьезным дополнительным расходам из-за отсутствия
специальных инструментов (позволяющих быстрое создание прототипов) и слишком раннего
применения (когда требования еще не стабильны и высока вероятность создания прототипа,
имеющего мало общего с тем, что хотел заказчик).
Анализ документов. Хорошо работает, когда профильные эксперты недоступны (временно), а
также в предметных областях, которые имеют хорошо отработанную нормативную
документацию. Также эта методика включает в себя просто изучение документов,
регламентирующих бизнес-процессы в предметной области заказчика или в конкретной
организации, что позволяет получить знания, необходимые для лучшего понимания сути
проекта.
Моделирование процессов и взаимодействий. Может применяться как к «бизнес-процессам и
взаимодействиям», так и к «техническим процессам и взаимодействиям». Эта техника требует
высококвалифицированного бизнес-аналитика, поскольку связана с обработкой большого
количества сложной информации.
Самоописание. Это не столько метод определения требований, сколько метод их фиксации и
формализации. Самостоятельно «придумать требования к заказчику» очень сложно, но в
спокойной обстановке можно самостоятельно обработать собранную информацию и аккуратно
оформить ее для дальнейшего обсуждения и уточнения.

4.1. Виды и уровни требований.

Бизнес-требования (business requirements) выражают цель, ради которой разрабатывается

продукт (зачем вообще он нужен, какая от него ожидается польза). Результатом выявления
требований на этом уровне является общее видение (vision and scope) — документ, который,
как правило, представлен простым текстом и таблицами. Здесь нет детализации поведения
системы и иных технических характеристик, но вполне могут быть определены приоритеты
решаемых бизнес-задач, риски и т.п.
Пользовательские требования (user requirements) описывают задачи, которые пользователь
может выполнять с помощью разрабатываемой системы (реакцию системы на действия
пользователя, сценарии работы пользователя). Поскольку здесь уже появляется описание
поведения системы, требования этого уровня могут быть использованы для оценки объёма
работ, стоимости проекта, времени разработки и т.д. Пользовательские требования
оформляются в виде вариантов использования (use cases), пользовательских историй (user
stories), пользовательских сценариев (user scenarios).
Бизнес-правила (business rules) описывают особенности принятых в предметной области (и/или
непосредственно у заказчика) процессов, ограничений и иных правил. Эти правила могут
относиться к бизнес-процессам, правилам работы сотрудников, нюансам работы ПО и т.д.
Атрибуты качества (quality attributes) расширяют собой нефункциональные требования и на
уровне пользовательских требований могут быть представлены в виде описания ключевых для
проекта показателей качества (свойств продукта, не связанных с функциональностью, но
являющихся важными для достижения целей создания продукта — производительность,
масштабируемость, восстанавливаемость).
Функциональные требования (functional requirements) описывают поведение системы, т.е. её
действия (вычисления, преобразования, проверки, обработку и т.д.) В контексте
проектирования функциональные требования в основном влияют на дизайн системы.
Нефункциональные требования (non-functional requirements) описывают свойства системы
(удобство использования, безопасность, надёжность, расширяемость и т.д.), которыми она
должна обладать при реализации своего поведения. Здесь приводится более техническое и
детальное описание атрибутов качества. В контексте проектирования нефункциональные
требования в основном влияют на архитектуру системы.
Ограничения (limitations, constraints) представляют собой факторы, ограничивающие выбор
способов и средств (в том числе инструментов) реализации продукта.
Требования к интерфейсам (external interfaces requirements) описывают особенности
взаимодействия разрабатываемой системы с другими системами и операционной средой.
Требования к данным (data requirements) описывают структуры данных (и сами данные),
являющиеся неотъемлемой частью разрабатываемой системы. Часто сюда относят описание
базы данных и особенностей её использования.
Спецификация требований (software requirements specification, SRS) объединяет в себе
описание всех требований уровня продукта и может представлять собой весьма объёмный
документ (сотни и тысячи страниц). Поскольку требований может быть очень много, а их
приходится не только единожды написать и согласовать между собой, но и постоянно
обновлять, работу проектной команды по управлению требованиями значительно облегчают
соответствующие инструментальные средства (requirements management tools).

4.2. Что отличает хорошие требования от плохих, проблемы с

требованиями.
Завершённость (completeness). Требование является полным и законченным с точки зрения
представления в нём всей необходимой информации, ничто не пропущено по соображениям
«это и так всем понятно».
Атомарность, единичность (atomicity). Требование является атомарным, если его нельзя
разбить на отдельные требования без потери завершённости и оно описывает одну и только
одну ситуацию.
Непротиворечивость, последовательность (consistency). Требование не должно содержать
внутренних противоречий и противоречий другим требованиям и документам.
Недвусмысленность (unambiguousness, clearness). Требование описано без использования
жаргона, неочевидных аббревиатур и расплывчатых формулировок и допускает только
однозначное объективное понимание. Требование атомарно в плане невозможности различной
трактовки сочетания отдельных фраз.
Выполнимость (feasibility). Требование технологически выполнимо и может быть реализовано
в рамках бюджета и сроков разработки проекта.
Обязательность, нужность (obligation) и актуальность (up-to-date). Если требование не
является обязательным к реализации, оно должно быть просто исключено из набора
требований. Если требование нужное, но «не очень важное», для указания этого факта
используется указание приоритета.Также исключены (или переработаны) должны быть
требования, утратившие актуальность.
Прослеживаемость (traceability). Прослеживаемость бывает вертикальной (vertical traceability)
и горизонтальной (horizontal traceability). Вертикальная позволяет соотносить между собой
требования на различных уровнях требований, горизонтальная позволяет соотносить
требование с тест-планом, тест-кейсами, архитектурными решениями и т.д. Для обеспечения
прослеживаемости часто используются специальные инструменты по управлению
требованиями (requirements management tool) и/или матрицы прослеживаемости (traceability
matrix).
Модифицируемость (modifiability). Это свойство характеризует простоту внесения изменений в
отдельные требования и в набор требований. Можно говорить о наличии модифицируемости в
том случае, если при доработке требований искомую информацию легко найти, а её изменение
не приводит к нарушению иных описанных в этом перечне свойств.
Проранжированность по важности, стабильности, срочности (ranked for importance,
stability, priority). Важность характеризует зависимость успеха проекта от успеха реализации
требования. Стабильность характеризует вероятность того, что в обозримом будущем в
требование не будет внесено никаких изменений. Срочность определяет распределение во
времени усилий проектной команды по реализации того или иного требования. Типичные
проблемы с проранжированностью состоят в её отсутствии или неверной реализации и
приводят к следующим последствиям:
- проблемы с проранжированностью по важности повышают риск неверного
распределения усилий проектной команды, направления усилий на второстепенные
задачи и конечного провала проекта из-за неспособности продукта выполнять
ключевые задачи с соблюдением ключевых условий;
- проблемы с проранжированностью по стабильности повышают риск выполнения
бессмысленной работы по совершенствованию, реализации и тестированию
требований, которые в самое ближайшее время могут претерпеть кардинальные
изменения (вплоть до полной утраты актуальности);
 - проблемы с проранжированностью по срочности повышают риск нарушения
желаемой заказчиком последовательности реализации функциональности и ввода этой
функциональности в эксплуатацию.
Корректность (correctness) и проверяемость (verifiability). Фактически эти свойства вытекают
из соблюдения всех вышеперечисленных (или можно сказать, что они не выполняются, если
нарушено хотя бы одно из вышеперечисленных). В дополнение можно отметить, что
проверяемость подразумевает возможность создания объективного тест-кейса (тест-кейсов),
однозначно показывающего, что требование реализовано верно и поведение приложения в
точности соответствует требованию.

4.3. Техники работы с требованиями, пути выявления проблем.

Тестирование документации и требований относится к разряду нефункционального
тестирования (non-functional testing). Основные техники такого тестирования в контексте
требований таковы:
1. Взаимный просмотр (peer review). Взаимный просмотр («рецензирование») является
одной из наиболее активно используемых техник тестирования требований и может
быть представлен в одной из трёх следующих форм (по мере нарастания его сложности
и цены):
- беглый просмотр (walkthrough)- может выражаться как в показе автором своей
работы коллегам с целью создания общего понимания и получения обратной
связи, так и в простом обмене результатами работы между двумя и более
авторами с тем, чтобы коллега высказал свои вопросы и замечания. Это самый
быстрый, самый дешёвый и наиболее широко используемый вид просмотра;
- технический просмотр (technical review)- выполняется группой специалистов. В
идеальной ситуации каждый специалист должен представлять свою область
знаний. Просматриваемый продукт не может считаться достаточно
качественным, пока хотя бы у одного просматривающего остаются замечания;
- формальная инспекция (inspection) представляет собой структурированный,
систематизированный и документируемый подход к анализу документации.
Для его выполнения привлекается большое количество специалистов, само
выполнение занимает достаточно много времени, и потому этот вариант
просмотра используется достаточно редко (как правило, при получении на
сопровождение и доработку проекта, созданием которого ранее занималась
другая компания).
2. Вопросы. Следующей очевидной техникой тестирования и повышения качества
требований является (повторное) использование техник выявления требований, а также
(как отдельный вид деятельности) — задавание вопросов. Если хоть что-то в
требованиях вызывает у вас непонимание или подозрение — задавайте вопросы.
Можно спросить представителей заказчика, можно обратиться к справочной
информации. По многим вопросам можно обратиться к более опытным коллегам при
условии, что у них имеется соответствующая информация, ранее полученная от
заказчика. Главное, чтобы ваш вопрос был сформулирован таким образом, чтобы
полученный ответ позволил улучшить требования.
3. Тест-кейсы и чек-листы. Мы помним, что хорошее требование является проверяемым,
а значит, должны существовать объективные способы определения того, верно ли
реализовано требование. Продумывание чек-листов или даже полноценных тест-кейсов
в процессе анализа требований позволяет нам определить, насколько требование
 проверяемо. Если вы можете быстро придумать несколько пунктов чек-листа, это ещё
не признак того, что с требованием всё хорошо (например, оно может противоречить
каким-то другим требованиям). Но если никаких идей по тестированию требования в
голову не приходит — это тревожный знак. Рекомендуется для начала убедиться, что
вы понимаете требование (в том числе прочесть соседние требования, задать вопросы
коллегам и т.д.). Также можно пока отложить работу с данным конкретным
требованием и вернуться к нему позднее — возможно, анализ других требований
позволит вам лучше понять и это конкретное. Но если ничто не помогает — скорее
всего, с требованием что-то не так. Справедливости ради надо отметить, что на
начальном этапе проработки требований такие случаи встречаются очень часто —
требования сформированы очень поверхностно, расплывчато и явно нуждаются в
доработке, т.е. здесь нет необходимости проводить сложный анализ, чтобы
констатировать непроверяемость требования. На стадии же, когда требования уже
хорошо сформулированы и протестированы, вы можете продолжать использовать эту
технику, совмещая разработку тест-кейсов и дополнительное тестирование требований.
4. Исследование поведения системы. Эта техника логически вытекает из предыдущей
(продумывания тест-кейсов и чек-листов), но отличается тем, что здесь тестированию
подвергается, как правило, не одно требование, а целый набор. Тестировщик мысленно
моделирует процесс работы пользователя с системой, созданной по тестируемым
требованиям, и ищет неоднозначные или вовсе неописанные варианты поведения
системы. Этот подход сложен, требует достаточной квалификации тестировщика, но
способен выявить нетривиальные недоработки, которые почти невозможно заметить,
тестируя требования по отдельности.
5. Рисунки (графическое представление). Чтобы увидеть общую картину требований
целиком, очень удобно использовать рисунки, схемы, диаграммы, интеллект-карты и
т.д. Графическое представление удобно одновременно своей наглядностью и
краткостью. На рисунке очень легко заметить, что какие-то элементы «не стыкуются»,
что где-то чего-то не хватает и т.д. Если вы для графического представления
требований будете использовать общепринятую нотацию (например,UML), вы
получите дополнительные преимущества: вашу схему смогут без труда понимать и
дорабатывать коллеги, а в итоге может получиться хорошее дополнение к текстовой
форме представления требований.
6. Прототипирование. Можно сказать, что прототипирование часто является следствием
создания графического представления и анализа поведения системы. С использованием
специальных инструментов можно очень быстро сделать наброски пользовательских
интерфейсов, оценить применимость тех или иных решений и даже создать не просто
«прототип ради прототипа», а заготовку для дальнейшей разработки, если окажется,
что реализованное в прототипе устраивает заказчика.

4.4. Типичные ошибки при анализе и тестировании требований

For a better understanding and memorization of the material, let us consider typical mistakes made
in the process of analyzing and testing requirements.
1. Change the file and document format. For some incomprehensible reason, many novice
testers tend to completely destroy the original document, replacing the text with tables (or
vice versa), transferring data from Word to Excel, etc. This can be done only in one case: if
you have previously agreed on such changes with the author of the document. Otherwise,
 you completely destroy someone's work, making the further development of the document
extremely difficult.
The worst thing you can do with a document is to save it in the end in some format designed
for reading rather than editing (PDF, a set of pictures, and the like). If requirements are
initially created in some kind of requirements management system, this question is irrelevant,
but most customers are used to seeing high-level requirements in a regular DOCX document,
and Word provides such excellent document management capabilities as change tracking and
comments.
2. Marking the fact that the requirement is okay. If you do not have any questions and / or
comments on the requirement, do not write about it. Any markings in a document are
subconsciously perceived as a sign of a problem, and such "approval of requirements" only
annoys and makes it difficult to work with the document - it becomes more difficult to notice
markings related to problems.
3. Description of the same problem in several places. Remember that your notes, comments,
remarks and questions should also have the properties of good requirements. If you write the
same thing about the same thing many times in different places, you violate at least the
modifiability property. In this case, try to put your text at the end of the document, indicate in
it (at the beginning) a list of points of requirements to which it relates, and in the
requirements themselves in the comments, simply refer to this text.
4. Writing questions and comments without specifying the place of the requirement to which
they relate. If your tool allows you to specify a part of the requirement to which you are
writing a question or comment, do so (for example, Word allows you to select any part of the
text for commenting - at least one character). If this is not possible, cite the appropriate
portion of the text. Otherwise, you create ambiguity or even make your mark meaningless,
because it becomes impossible to understand what it is all about.
5. Asking poorly formulated questions. There are three types of bad questions:
- the first type arises due to the fact that the author of the question does not know the
generally accepted terminology or typical behavior of standard interface elements (for
example, "what is a check-box?", "How can you select several items in a list?", "How can a
hint pop up ? ");
- the second kind of bad questions is similar to the first because of the wording: instead of
writing "what do you mean by {something}?", the author of the question writes "what is
{something}?" That is, instead of a completely logical clarification, a situation is obtained
that is very similar to that considered in the previous paragraph;
- the third type is difficult to tie to the cause of its occurrence, but its essence is that a question
like "what will happen if we do this?" is asked to an incorrect and / or impossible
requirement. Nothing will happen, tk. we will definitely not do it. And the question should be
completely different (which one depends on the specific situation, but definitely not the
same).
And once again, remember the accuracy of the wording: sometimes one or two words can completely
destroy a great idea, turning a good question into a bad one. Compare: "What is the default date
format?" and "What is the default date format?" The first option simply shows the incompetence of
the author of the question, while the second one allows you to get useful information. The
misunderstanding of the context belongs to the same problem. You can often see questions like "What
application are we talking about?", "What is a system?" and the like. Most often, the author of such
questions simply took the requirement out of the context, according to which it was completely clear
what was being discussed.
6. Writing very long comments and / or questions. History knows of cases where one page of
initial requirements turned into 20-30 pages of analysis and questions. This is a bad
approach. All the same thoughts can be expressed much more succinctly than save both your
time and the time of the author of the original document. Moreover, it should be borne in
mind that at the initial stages of working with requirements, they are very unstable, and it
may turn out that your 5-10 pages of comments refer to a requirement that will simply be
deleted or changed beyond recognition.
7. Criticism of the text or even its author. Remember that your job is to make the requirements
better, not to show their flaws (or the author's flaws). Therefore, comments like “bad
demand”, “don’t you understand how stupid it sounds”, “must be reformulated” are
inappropriate and unacceptable.
8. Categorical statements without justification. As a continuation of the mistake “criticizing the
text or even its author”, we can also note simply categorical statements like “this is
impossible”, “we will not do this”, “it is not necessary”. Even if you understand that the
requirement is meaningless or impracticable, this idea should be formulated in the correct
form and supplemented with questions that allow the author of the document to make the
final decision himself. For example, “it is not necessary” can be reformulated as follows:
“We doubt that this feature will be in demand by users. What is the importance of this
requirement? Are you sure of its necessity? ".
9. Indicating the problem with requirements without explaining its essence. Please be aware
that the author of the original document may not be a testing or business analyst. Therefore,
just a note in the style of "incompleteness", "ambiguity", etc. may not tell him anything.
Explain your idea. This can also include a small but annoying flaw related to inconsistency:
if you find some inconsistencies, make the appropriate notes in all conflicting places, and not
just in one of them. For example, you find that Requirement 20 conflicts with Requirement
30. Then in Requirement 20, note that Requirement 20 conflicts with Requirement 30, and
vice versa. And explain the essence of the contradiction.
10. Poor design of questions and comments. Try to make your questions and comments as easy
to understand as possible. Remember not only the brevity of the wording, but also the design
of the text. Reread your text, correct typos, grammatical and punctuation errors, etc.
11. The description of the problem is not in the place to which it relates. A classic example
would be an inaccuracy in a footnote, appendix or figure, which for some reason is not
described where it is located, but in the text referring to the corresponding element. An
exception can be considered inconsistency, in which the problem must be described in both
places.
12. Misperception of the requirement as a “requirement for the user”. For example, phrases like
"the user can click any of the buttons", "the user should see the main menu" actually means
"all displayed buttons should be clickable" and "the main menu should be displayed". Yes,
this flaw is also worth fixing, but it should not be flagged as a critical issue.
13. Latent editing of requirements. This error can be safely attributed to the category of
extremely dangerous. Its essence lies in the fact that the tester arbitrarily makes changes to
the requirements without noticing this fact. Accordingly, the author of the document, most
likely, will not notice such a change, and then he will be very surprised when something in
the product is implemented completely differently from what was once described in the
requirements. Therefore, a simple recommendation: if you are editing something, be sure to
mark it (by means of your instrument or simply explicitly in the text). It is even better to
mark the revision as a proposal for a change rather than a fait accompli. the author of the
original document may have a completely different view of the situation.
 14. Analysis that does not meet the level of requirements. When testing requirements, keep in
mind what level they belong to, because otherwise, the following typical errors appear:
- adding small technical details to business requirements;
- duplication at the level of custom requirements of part of the business requirements (if you
want to increase the traceability of a set of requirements, it makes sense to just use links);
- insufficient detailing of product-level requirements (general phrases, permissible, for
example, at the level of business requirements, here should already be extremely detailed,
structured and supplemented with detailed technical information).

Для лучшего понимания и запоминания материала рассмотрим типичные ошибки,

допущенные в процессе анализа и тестирования требований.
1. Изменение формата файла и документа. По непонятной причине многие начинающие
тестировщики стремятся полностью уничтожить оригинал документа, заменяя текст таблицами
(или наоборот), перенося данные из Word в Excel и т.д. Это можно сделать только в одном
случае: если вы предварительно согласовали такие изменения с автором документа. В
противном случае вы полностью уничтожаете чью-либо работу, что крайне затрудняет
дальнейшее развитие документа.
Самое худшее, что можно сделать с документом - сохранить его в конце концов в каком-
нибудь формате, предназначенном для чтения, а не для редактирования (PDF, набор картинок
и т.п.). Если изначально требования создаются в какой-то системе управления требованиями,
этот вопрос не имеет значения, но большинство клиентов привыкли видеть требования
высокого уровня в обычном документе DOCX, а Word предоставляет такие отличные
возможности управления документами, как отслеживание изменений и комментарии.
2. Обозначение того факта, что требование нормальное. Если у вас нет никаких вопросов
и / или комментариев по этому требованию, не пишите об этом. Любые пометки в документе
подсознательно воспринимаются как признак проблемы, а такое "утверждение требований"
только раздражает и затрудняет работу с документом - становится сложнее заметить пометки,
связанные с проблемами.
3. Описание одной и той же проблемы в нескольких местах. Помните, что ваши заметки,
комментарии, замечания и вопросы также должны обладать свойствами хороших требований.
Если вы пишете одно и то же о одной и той же проблеме много раз в разных местах, вы
нарушаете, по крайней мере, свойство модифицируемости. В этом случае постарайтесь
поместить свой текст в конец документа, укажите в нем (в начале) список пунктов требований,
к которым он относится, а в самих требованиях в комментариях просто сослаться на этот текст.
4. Письменные вопросы и комментарии без указания места требования, к которому они
относятся. Если ваш инструмент позволяет указать часть требования, к которой вы пишете
вопрос или комментарий, сделайте это (например, Word позволяет выделить для комментариев
любую часть текста - хотя бы один символ). Если это невозможно, укажите соответствующую
часть текста. В противном случае вы создадите двусмысленность или даже сделаете свой знак
бессмысленным, потому что становится невозможным понять, о чем идет речь.
5. Задавать плохо сформулированные вопросы. Есть три типа плохих вопросов:
- первый тип возникает из-за того, что автор вопроса не знает общепринятой терминологии
или типичного поведения стандартных элементов интерфейса (например, "Что такое флажок?",
"Как выбрать несколько элементов в списке?", "Как всплывает подсказка? ");
- второй вид плохих вопросов похож на первый из-за формулировки: вместо того, чтобы
написать "что вы имеете в виду под {something}?", автор вопроса пишет "что такое
{something}?". То есть вместо вполне логичного разъяснения получается ситуация, очень
похожая на ту, которая рассматривалась в предыдущем абзаце;
- третий тип трудно связать с причиной его возникновения, но его суть заключается в том, что
вопрос типа "что произойдет, если мы это сделаем?" задается с некорректным и/или
невозможным требованием. Ничего не произойдет, тк. мы точно этого не сделаем. И вопрос
должен быть совершенно другим (который зависит от конкретной ситуации, но определенно не
одним и тем же).
И еще раз запомните правильность формулировки: иногда одно или два слова могут
полностью уничтожить великую идею, превратив хороший вопрос в плохой. Сравните: "Какой
формат даты по умолчанию?" и "Какой формат даты по умолчанию?". Первый вариант просто
показывает некомпетентность автора вопроса, а второй позволяет получить полезную
информацию. Непонимание контекста относится к одной и той же проблеме. Часто можно
встретить вопросы типа "О каком приложении идет речь?", "Что такое система?" и тому
подобное. Чаще всего автор таких вопросов просто выносит требование из контекста, согласно
которому совершенно ясно, о чем идет речь.
6. Написание очень длинных комментариев и/или вопросов. История знает случаи, когда
одна страница исходных требований превращалась в 20-30 страниц анализа и вопросов. Это
плохой подход. Все те же мысли можно выразить гораздо лаконичнее, чем сэкономить и ваше
время, и время автора оригинала документа. Более того, следует иметь в виду, что на
начальных этапах работы с требованиями они очень нестабильны, и может оказаться, что ваши
5-10 страниц комментариев относятся к требованию, которое будет просто удалено или
изменено до неузнаваемости.
7. Критика текста или даже его автора. Помните, что ваша задача - сделать требования
лучше, а не показывать их недостатки (или недостатки автора). Поэтому такие комментарии,
как "плохое требование", "вы не понимаете, как глупо это звучит", "нужно
переформулировать", неуместны и неприемлемы.
8. Категорические высказывания без обоснования. В качестве продолжения ошибки
"критики текста или даже его автора" можно отметить просто категорические высказывания
типа "это невозможно", "мы этого не сделаем", "это не нужно". Даже если вы понимаете, что
требование бессмысленно или неосуществимо, эта идея должна быть сформулирована в
правильной форме и дополнена вопросами, позволяющими автору документа принять
окончательное решение самостоятельно. Например, "не обязательно" можно
переформулировать следующим образом: "Мы сомневаемся, что эта особенность будет
востребована пользователями". Какова важность этого требования? Уверены ли Вы в его
необходимости? ".
9. Указание на проблему с требованиями без объяснения их сущности. Пожалуйста,
имейте в виду, что автор оригинала документа не может быть тестировщиком или бизнес-
аналитиком. Поэтому просто пометка в стиле "неполнота", "двусмысленность" и т.п. может
ничего ему не сказать. Поясните свою идею. Сюда можно отнести и небольшой, но досадный
изъян, связанный с несогласованностью: если вы обнаружили какие-то нестыковки, делайте
соответствующие пометки во всех конфликтующих местах, а не только в одном из них.
Например, вы обнаружили, что Требование 20 противоречит Требованию 30. Затем в
Требовании 20 обратите внимание, что Требование 20 противоречит Требованию 30, и
наоборот. И объясните суть противоречия.
10. Плохо продуманная конструкция вопросов и комментариев. Постарайтесь сделать свои
вопросы и комментарии как можно более понятными. Помните не только лаконичность
формулировки, но и оформление текста. Перечитывайте текст, исправляйте опечатки,
грамматические и пунктуационные ошибки и т.д.
11. Описание проблемы не в том месте, к которому она относится. Классическим
примером может быть неточность в сноске, приложении или рисунке, которая по каким-то
причинам описывается не в том месте, где она находится, а в тексте, относящемся к
соответствующему элементу. Исключением может считаться непоследовательность, при
которой проблема должна быть описана в обоих местах.
12. Неправильное восприятие требования как "требования для пользователя". Например,
фразы типа "пользователь может нажать любую из кнопок", "пользователь должен видеть
главное меню" на самом деле означают "все отображаемые кнопки должны быть доступны" и
"главное меню должно быть показано". Да, этот недостаток также стоит исправить, но он не
должен быть отмечен как критический.
13. Скрытое редактирование требований. Эту ошибку можно смело отнести к категории
крайне опасных. Ее суть в том, что тестер произвольно вносит изменения в требования, не
замечая этого факта. Соответственно, автор документа, скорее всего, не заметит такого
изменения, и тогда он очень удивится, когда что-то в продукте будет реализовано совершенно
иначе, чем то, что когда-то было описано в требованиях. Поэтому простая рекомендация: если
вы что-то редактируете, обязательно пометьте это (при помощи инструмента или просто явно в
тексте). Еще лучше пометить ревизию как предложение об изменении, а не как свершившийся
факт. автор оригинала документа может иметь совершенно иное представление о ситуации.
14. Анализ, который не соответствует уровню требований. При тестировании требований
помните, к какому уровню они относятся, так как в противном случае возникают следующие
типичные ошибки:
- добавление мелких технических деталей к требованиям бизнеса;
- дублирование на уровне пользовательских требований части требований бизнеса (если вы
хотите увеличить прослеживаемость набора требований, имеет смысл просто использовать
ссылки);
- недостаточная детализация требований на уровне продукта (общие фразы, допустимые,
например, на уровне бизнес-требований, здесь уже должны быть предельно подробными,
структурированными и дополненными подробной технической информацией).