Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Product requirements document, PRD. The PRD describes the product your company will build. It drives the efforts of the entire product team and the company’s sales, marketing and customer support efforts. The purpose of the product requirements doc- ument (PRD) or product spec is to clearly and unambiguously articulate the product’s purpose, features, functionality, and be- havior. The product team will use this specification to actually build and test the product, so it needs to be complete enough to provide them the information they need to do their jobs. [ «How to write a good PRD», Martin Cagan] 56 Specification. A document that specifies, ideally in a complete, precise and verifiable manner, the requirements, design, behavior, or other characteristics of a component or system, and, often, the procedures for determining whether these provisions have been satisfied. [ISTQB Glossary] 57 Functional specifications document, FSD. См. «Software requirements specification, SRS». 58 Software requirements specification, SRS. SRS describes as fully as necessary the expected behavior of the software system. The SRS is used in development, testing, quality assurance, project management, and related project functions. People call this deliverable by many different names, including business requirements document, functional spec, requirements document, and others. [ «Software Requirements (3 rd edition) », Karl Wiegers and Joy Beatty] 59 Architecture. Design. A software architecture for a system is the structure or structures of the system, which comprise elements, their externally- visible behavior, and the relationships among them. … Architecture is design, but not all design is architecture. That is, there are many design decisions that are left unbound by the architecture, and are happily left to the discretion and good judgment of downstream designers and implementers. The architecture establishes constraints on downstream activities, and those activities must produce artifacts (finer-grained designs and code) that are compliant with the architecture, but architecture does not define an implementation. [ «Documenting Software Architectures», Paul Clements и др.] 60 Test case. A set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement. [ISTQB Glossary] 61 Test suite. A set of several test cases for a component or system under test, where the post condition of one test is often used as the precondition for the next one. [ISTQB Glossary] 62 Technical specifications. Scripts, source code, data definition language, etc. [PMBOK, 3 rd edition] Также см. «Specification». 63 Project documentation. Other expectations and deliverables that are not a part of the software the team implements, but that are necessary to the successful completion of the project as a whole. [ «Software Requirements (3 rd edition) », Karl Wiegers and Joy Beatty] Важность требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 33/298 o Пользовательскую и сопроводительную документацию (user and ac- companying documentation 64 ), такую как встроенная помощь, руковод- ство по установке и использованию, лицензионные соглашения и т.д. o Маркетинговую документацию (market requirements document, MRD 65 ), которую представители разработчика или заказчика используют как на начальных этапах (для уточнения сути и концепции проекта), так и на финальных этапах развития проекта (для продвижения продукта на рынке). В некоторых классификациях часть документов из продуктной документации может быть перечислена в проектной документации — это совершенно нормально, т.к. понятие проектной документации по определению является более широким. Поскольку с этой классификацией связано очень много вопросов и непонимания, отразим суть ещё раз — графически (см. рисунок 2.2.c) — и напомним, что мы до- говорились классифицировать документацию по признаку того, где (для чего) она является наиболее востребованной. Рисунок 2.2.c — Соотношение понятий «продуктная документация» и «проектная документация» Степень важности и глубина тестирования того или иного вида документации и даже отдельного документа определяется большим количеством факторов, но неизменным остаётся общий принцип: всё, что мы создаём в процессе разработки проекта (даже рисунки маркером на доске, даже письма, даже переписку в скайпе), можно считать документацией и так или иначе подвергать тестированию (напри- мер, вычитывание письма перед отправкой — это тоже своего рода тестирование документации). 64 User documentation. User documentation refers to the documentation for a product or service provided to the end users. The user documentation is designed to assist end users to use the product or service. This is often referred to as user assistance. The user documentation is a part of the overall product delivered to the customer. [ На основе статей doc-department.com ] 65 Market requirements document, MRD. An MRD goes into details about the target market segments and the issues that pertain to commercial success. [ «Software Requirements (3 rd edition) », Karl Wiegers and Joy Beatty] Источники и пути выявления требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 34/298 2.2.3. Источники и пути выявления требований Требования начинают свою жизнь на стороне заказчика. Их сбор (gathering) и выявление (elicitation) осуществляются с помощью следующих основных техник 66 ( рисунок 2.2.d). Интервью. Самый универсальный путь выявления требований, заключаю- щийся в общении проектного специалиста (как правило, специалиста по бизнес- анализу) и представителя заказчика (или эксперта, пользователя и т.д.). Интервью может проходить в классическом понимании этого слова (беседа в виде «вопрос- ответ»), в виде переписки и т.п. Главным здесь является то, что ключевыми фигу- рами выступают двое — интервьюируемый и интервьюер (хотя это и не исключает наличия «аудитории слушателей», например, в виде лиц, поставленных в копию переписки). Работа с фокусными группами. Может выступать как вариант «расширен- ного интервью», где источником информации является не одно лицо, а группа лиц (как правило, представляющих собой целевую аудиторию, и/или обладающих важ- ной для проекта информацией, и/или уполномоченных принимать важные для про- екта решения). Рисунок 2.2.d — Основные техники сбора и выявления требований Анкетирование. Этот вариант выявления требований вызывает много спо- ров, т.к. при неверной реализации может привести к нулевому результату при объ- ёмных затратах. В то же время при правильной организации анкетирование позво- ляет автоматически собрать и обработать огромное количество ответов от огром- ного количества респондентов. Ключевым фактором успеха является правильное составление анкеты, правильный выбор аудитории и правильное преподнесение анкеты. Семинары и мозговой штурм. Семинары позволяют группе людей очень быстро обменяться информацией (и наглядно продемонстрировать те или иные идеи), а также хорошо сочетаются с интервью, анкетированием, прототипирова- нием и моделированием — в том числе для обсуждения результатов и формирова- ния выводов и решений. Мозговой штурм может проводиться и как часть семинара, и как отдельный вид деятельности. Он позволяет за минимальное время сгенери- 66 Здесь можно почитать подробнее о том, в чём разница между сбором и выявлением требований: «Requirements Gathering vs. Elicitation » (Laura Brandenburg): http://www.bridging-the-gap.com/requirements-gathering-vs-elicitation/ Интервью Работа с фокусными группами Анкетирование Семинары и мозговой штурм Наблюдение Прототипирование Анализ документов Моделирование процессов и взаимодействий Самостоятельное описание Источники и пути выявления требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 35/298 ровать большое количество идей, которые в дальнейшем можно не спеша рассмот- реть с точки зрения их использования для развития проекта. Наблюдение. Может выражаться как в буквальном наблюдении за некими процессами, так и во включении проектного специалиста в эти процессы в качестве участника. С одной стороны, наблюдение позволяет увидеть то, о чём (по совер- шенно различным соображениям) могут умолчать интервьюируемые, анкетируе- мые и представители фокусных групп, но с другой — отнимает очень много времени и чаще всего позволяет увидеть лишь часть процессов. Прототипирование. Состоит в демонстрации и обсуждении промежуточных версий продукта (например, дизайн страниц сайта может быть сначала представ- лен в виде картинок, и лишь затем свёрстан). Это один из лучших путей поиска единого понимания и уточнения требований, однако он может привести к серьёз- ным дополнительным затратам при отсутствии специальных инструментов (позво- ляющих быстро создавать прототипы) и слишком раннем применении (когда требо- вания ещё не стабильны, и высока вероятность создания прототипа, имеющего мало общего с тем, что хотел заказчик). Анализ документов. Хорошо работает тогда, когда эксперты в предметной области (временно) недоступны, а также в предметных областях, имеющих обще- принятую устоявшуюся регламентирующую документацию. Также к этой технике от- носится и просто изучение документов, регламентирующих бизнес-процессы в предметной области заказчика или в конкретной организации, что позволяет при- обрести необходимые для лучшего понимания сути проекта знания. Моделирование процессов и взаимодействий. Может применяться как к «бизнес-процессам и взаимодействиям» (например: «договор на закупку формиру- ется отделом закупок, визируется бухгалтерией и юридическим отделом…»), так и к «техническим процессам и взаимодействиям» (например: «платёжное по- ручение генерируется модулем “Бухгалтерия”, шифруется модулем “Безопас- ность” и передаётся на сохранение в модуль “Хранилище”»). Данная техника тре- бует высокой квалификации специалиста по бизнес-анализу, т.к. сопряжена с обра- боткой большого объёма сложной (и часто плохо структурированной) информации. Самостоятельное описание. Является не столько техникой выявления тре- бований, сколько техникой их фиксации и формализации. Очень сложно (и даже нельзя!) пытаться самому «придумать требования за заказчика», но в спокойной обстановке можно самостоятельно обработать собранную информацию и акку- ратно оформить её для дальнейшего обсуждения и уточнения. Часто специалисты по бизнес-анализу приходят в свою профессию из те- стирования. Если вас заинтересовало это направление, стоит ознако- миться со следующими книгами: • «Требования для программного обеспечения: рекомендации по сбору и документированию» (Илья Корнипаев). • «Business Analysis Techniques. 72 Essential Tools for Success» (James Cadle, Debra Paul, Paul Turner). • «Business Analysis (Second Edition)» (Debra Paul, Donald Yeates, James Cadle). Уровни и типы требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 36/298 2.2.4. Уровни и типы требований Форма представления, степень детализации и перечень полезных свойств требований зависят от уровней и типов требований 67 , которые схематично пред- ставлены на рисунке 2.2.e 68 Бизнес-требования (business requirements 69 ) выражают цель, ради которой разрабатывается продукт (зачем вообще он нужен, какая от него ожидается польза, как заказчик с его помощью будет получать прибыль). Результатом выявления тре- бований на этом уровне является общее видение (vision and scope 70 ) — документ, который, как правило, представлен простым текстом и таблицами. Здесь нет дета- лизации поведения системы и иных технических характеристик, но вполне могут быть определены приоритеты решаемых бизнес-задач, риски и т.п. Несколько простых, изолированных от контекста и друг от друга примеров бизнес-требований: • Нужен инструмент, в реальном времени отображающий наиболее выгод- ный курс покупки и продажи валюты. • Необходимо в два-три раза повысить количество заявок, обрабатывае- мых одним оператором за смену. • Нужно автоматизировать процесс выписки товарно-транспортных накладных на основе договоров. Рисунок 2.2.e — Уровни и типы требований 67 Очень подробное описание уровней и типов требований (а также их применения) можно найти в статье «Software Require- ments Engineering: What, Why, Who, When, and How », Linda Westfall [ http://www.westfallteam.com/Pa- pers/The_Why_What_Who_When_and_How_Of_Software_Requirements.pdf ] 68 В основу данного рисунка положены идеи, представленные в книге «Software Requirements (3 rd edition )» (Karl Wiegers and Joy Beatty). 69 Business requirement. Anything that describes the financial, marketplace, or other business benefit that either customers or the developing organization wish to gain from the product. [«Software Requirements (3 rd edition)», Karl Wiegers and Joy Beatty] 70 Vision and scope. The vision and scope document collects the business requirements into a single deliverable that sets the stage for the subsequent development work. [«Software Requirements (3 rd edition)», Karl Wiegers and Joy Beatty] Уровни и типы требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 37/298 Пользовательские требования (user requirements 71 ) описывают задачи, ко- торые пользователь может выполнять с помощью разрабатываемой системы (ре- акцию системы на действия пользователя, сценарии работы пользователя). По- скольку здесь уже появляется описание поведения системы, требования этого уровня могут быть использованы для оценки объёма работ, стоимости проекта, времени разработки и т.д. Пользовательские требования оформляются в виде ва- риантов использования (use cases 72 ), пользовательских историй (user stories 73 ), пользовательских сценариев (user scenarios 74 ). (Также см. создание пользователь- ских сценариев {143} в процессе выполнения тестирования.) Несколько простых, изолированных от контекста и друг от друга примеров пользовательских требований: • При первом входе пользователя в систему должно отображаться лицен- зионное соглашение. • Администратор должен иметь возможность просматривать список всех пользователей, работающих в данный момент в системе. • При первом сохранении новой статьи система должна выдавать запрос на сохранение в виде черновика или публикацию. Бизнес-правила (business rules 75 ) описывают особенности принятых в пред- метной области (и/или непосредственно у заказчика) процессов, ограничений и иных правил. Эти правила могут относиться к бизнес-процессам, правилам работы сотрудников, нюансам работы ПО и т.д. Несколько простых, изолированных от контекста и друг от друга примеров бизнес-правил: • Никакой документ, просмотренный посетителями сайта хотя бы один раз, не может быть отредактирован или удалён. • Публикация статьи возможна только после утверждения главным редак- тором. • Подключение к системе извне офиса запрещено в нерабочее время. Атрибуты качества (quality attributes 76 ) расширяют собой нефункциональ- ные требования и на уровне пользовательских требований могут быть представ- лены в виде описания ключевых для проекта показателей качества (свойств про- дукта, не связанных с функциональностью, но являющихся важными для достиже- ния целей создания продукта — производительность, масштабируемость, восста- навливаемость). Атрибутов качества очень много 77 , но для любого проекта реально важными является лишь некоторое их подмножество. Несколько простых, изолированных от контекста и друг от друга примеров атрибутов качества: • Максимальное время готовности системы к выполнению новой команды 71 User requirement. User requirements are general statements of user goals or business tasks that users need to perform. [ «Soft- ware Requirements (3 rd edition) », Karl Wiegers and Joy Beatty] 72 Use case. A sequence of transactions in a dialogue between an actor and a component or system with a tangible result, where an actor can be a user or anything that can exchange information with the system. [ISTQB Glossary] 73 User story. A high-level user or business requirement commonly used in agile software development, typically consisting of one or more sentences in the everyday or business language capturing what functionality a user needs, any non-functional criteria, and also includes acceptance criteria. [ISTQB Glossary] 74 A scenario is a hypothetical story, used to help a person think through a complex problem or system. «An Introduction to Scenario Testing », Cem Kaner. [ http://www.kaner.com/pdfs/ScenarioIntroVer4.pdf ] 75 Business rule. A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. A business rule expresses specific constraints on the creation, updating, and removal of persistent data in an information system. [ «Defining Business Rules — What Are They Really», David Hay и др.] 76 Quality attribute. A feature or characteristic that affects an item’s quality. [ISTQB Glossary] 77 Даже в Википедии их список огромен: http://en.wikipedia.org/wiki/List_of_system_quality_attributes Уровни и типы требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 38/298 после отмены предыдущей не может превышать одну секунду. • Внесённые в текст статьи изменения не должны быть утеряны при нару- шении соединения между клиентом и сервером. • Приложение должно поддерживать добавление произвольного количества неиероглифических языков интерфейса. |