Файл: Обеспечения Базовый курс (3е издание) Версия книги 2 от 17. 04. 2023.pdf

Основные принципы тестирования
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 31/301
Тестирование зависит от контекста
Согласитесь, вы будете по-разному подходить к приготовлению «чего-нибудь перекусить для себя» и к организации семейного ужина по какому-то очень торже- ственному поводу.
В тестировании логика та же: программные продукты могут относиться к раз- ным предметным областям, быть построены с использованием различных техно- логий, использоваться для решения более или менее «ответственных» задач и т.д.
— всё это и многое другое влияет на то, как должен быть организован процесс те- стирования.
Набор характеристик программного продукта влияет на глубину тестирова- ния, используемый набор техник и инструментов, принципы организации работы тестировщиков и т.д.
Основная идея данного принципа состоит в том, что невозможно выработать некий «универсальный подход к тестированию» на все случаи жизни, и даже просто бездумное копирование подходов к тестированию с одних проектов на другие часто не заканчивается ничем хорошим.
Если же принимать во внимание как общие, так и уникальные свойства теку- щего проекта и выстраивать тестирования соответствующим образом — оно ока- зывается наиболее эффективным и результативным.
Отсутствие дефектов — не самоцель
Представьте, что вы купили кому-то апельсин. Идеальный. Самый лучший в мире. Достойный стать эталоном апельсинов на все времена. Но тот, кому вы по- купали этот апельсин, разочарован — он ведь просил грейпфрут.
Так и программный продукт должен не только быть избавлен от дефектов настолько, насколько это возможно, но и удовлетворять требованиям заказчика и конечных пользователей — в противном случае он станет непригодным для исполь- зования.
Стоит отметить, что нередко нарушение данного принципа заключается в не- достаточной проработке и реализации нефункциональных требований
{41}
к про- дукту, что влечёт за собой справедливую критику со стороны конечных пользовате- лей и общее падение популярности продукта.
Если объединить этот принцип с предыдущим, получается: именно понима- ние контекста продукта и потребностей пользователей позволяет тестировщикам выбрать наилучшую стратегию и добиться наилучшего результата.
Несмотря на то, что данные принципы тестирования сами по себе не явля- ются магической гарантией успеха, их понимание должно позволить вам лучше вос- принять и усвоить представленный далее материал.

Тестирование документации и требований
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 32/301

Важность требований
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 33/301
2.2.2.
Важность требований
Требования являются отправной точкой для определения того, что проектная команда будет проектировать, реализовывать и тестировать. Элементарная логика говорит нам, что если в требованиях что-то «не то», то и реализовано будет «не то», т.е. колоссальная работа множества людей будет выполнена впустую. Эту мысль иллюстрирует рисунок 2.2.a.
Брайан Хэнкс, описывая важность требований
52
, подчёркивает, что они:
• Позволяют понять, что и с соблюдением каких условий система должна де- лать.
• Предоставляют возможность оценить масштаб изменений и управлять изме- нениями.
• Являются основой для формирования плана проекта (в том числе плана те- стирования).
• Помогают предотвращать или разрешать конфликтные ситуации.
• Упрощают расстановку приоритетов в наборе задач.
• Позволяют объективно оценить степень прогресса в разработке проекта.
Вне зависимости от того, какая модель разработки ПО используется на про- екте, чем позже будет обнаружена проблема, тем сложнее и дороже будет её ре- шение. А в самом начале («водопада», «спуска по букве v», «итерации», «витка спирали») идёт планирование и работа с требованиями.
Если проблема в требованиях будет выяснена на этой стадии, её решение может свестись к исправлению пары слов в тексте, в то время как недоработка, вызванная пропущенной проблемой в требованиях и обнаруженная на стадии экс- плуатации, может даже полностью уничтожить проект.
Рисунок 2.2.a — Стоимость исправления ошибки в зависимости от момента её об- наружения
Если графики вас не убеждают, попробуем проиллюстрировать ту же мысль на простом примере. Допустим, вы с друзьями составляете список покупок перед поездкой в гипермаркет. Вы поедете покупать, а друзья ждут вас дома. Сколько
52
«Requirements in the Real World», Brian F. Hanks, February 28, 2002.
Общее планирование
Пользовательские требования
Системные требования
Техническая архитектура
Детализированный дизайн
Разработка и отладка
Интеграция и модульные тесты
Инсталляционное тестирование
Системное тестирование
Приёмочное тестирование
Итоговая отчётность
0 20 500 1000
Эксплуатация
Время, затраченное на проект
Стоимость исправления ошибки

Важность требований
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 34/301
«стоит» дописать, вычеркнуть или изменить пару пунктов, пока вы только-только составляете список? Нисколько. Если мысль о несовершенстве списка настигла вас по пути в гипермаркет, уже придётся звонить (дёшево, но не бесплатно). Если вы поняли, что в списке «что-то не то» в очереди на кассу, придётся возвращаться в торговый зал и тратить время. Если проблема выяснилась по пути домой или даже дома, придётся вернуться в гипермаркет. И, наконец, клинический случай: в списке изначально было что-то уж совсем неправильное (например, «100 кг конфет — и всё»), поездка совершена, все деньги потрачены, конфеты привезены и только тут выясняется, что «ну мы же пошутили».
Задание 2.2.a: представьте, что ваш с друзьями бюджет ограничен, и в списке требований появляются приоритеты (что-то купить надо обяза- тельно, что-то, если останутся деньги, и т.п.). Как это повлияет на риски, связанные с ошибками в списке?
Ещё одним аргументом в пользу тестирования требований является то, что, по разным оценкам, в них зарождается от ½ до ¾ всех проблем с программным обеспечением. В итоге есть риск, что получится так, как показано на рисунке 2.2.b.
Поскольку мы постоянно говорим «документация и требования», а не просто
«требования», то стоит рассмотреть перечень документации, которая должна под- вергаться тестированию в процессе разработки ПО (хотя далее мы будем концен- трироваться именно на требованиях).
Рисунок 2.2.b — Типичный проект с плохими требованиями
В общем случае документацию можно разделить на два больших вида в за- висимости от времени и места её использования (здесь будет очень много сносок
Так клиент объяснил, чего он хочет
Так клиента понял менеджер проекта
Так аналитик описал проект
Так программист реализовал проект
Так проект был прорекламирован консультантами
Так проект был задокументирован
Так проект был сдан в эксплуатацию
В такую сумму проект обошёлся заказчику
Так работала техническая поддержка
Что на самом деле было нужно клиенту

Важность требований
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 35/301 с определениями, т.к. по видам документации очень часто возникает множество во- просов и потому придётся рассмотреть некоторые моменты подробнее).
• Продуктная документация (product documentation, development documenta- tion
53
) используется проектной командой во время разработки и поддержки продукта. Она включает: o
План проекта (project management plan
54
) и в том числе тестовый план
(test plan
55
). o
Требования к программному продукту (product requirements document,
PRD
56
) и функциональные спецификации (functional specifications
57
doc- ument, FSD
58
; software requirements specification, SRS
59
). o
Архитектуру и дизайн (architecture and design
60
). o
Тест-кейсы и наборы тест-кейсов (test cases
61
, test suites
62
). o
Технические спецификации (technical specifications
63
), такие как схемы баз данных, описания алгоритмов, интерфейсов и т.д.
• Проектная документация (project documentation
64
) включает в себя как про- дуктную документацию, так и некоторые дополнительные виды документа- ции и используется не только на стадии разработки, но и на более ранних и поздних стадиях (например, на стадии внедрения и эксплуатации). Она вклю- чает:
53
Development documentation. Development documentation comprises those documents that propose, specify, plan, review, test, and implement the products of development teams in the software industry. Development documents include proposals, user or customer requirements description, test and review reports (suggesting product improvements), and self-reflective documents written by team members, analyzing the process from their perspective. [
«Documentation for Software and IS Development»,
Thomas T. Barker,
«Encyclopedia of Information Systems» (Elsevier Press, 2002, pp. 684‐694.)]
54
Project management plan. A formal, approved document that defines how the project is executed, monitored and controlled. It may be summary or detailed and may be composed of one of more subsidiary management plans and other planning documents.
[PMBOK, 3
rd edition]
55
Test plan. A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process. [ISTQB Glossary]
56
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 a nd 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]
57
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]
58
Functional specifications document, FSD.
См. «Software requirements specification, SRS».
59
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]
60
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 и др.]
61
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]
62
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]
63
Technical specifications. Scripts, source code, data definition language, etc. [PMBOK, 3
rd edition]
Также см. «Specification».
64
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–2023
Стр: 36/301 o
Пользовательскую и сопроводительную документацию (user and ac- companying documentation
65
), такую как встроенная помощь, руковод- ство по установке и использованию, лицензионные соглашения и т.д. o
Маркетинговую документацию (market requirements document, MRD
66
), которую представители разработчика или заказчика используют как на начальных этапах (для уточнения сути и концепции проекта), так и на финальных этапах развития проекта (для продвижения продукта на рынке).
В некоторых классификациях часть документов из продуктной документации может быть перечислена в проектной документации — это совершенно нормально, т.к. понятие проектной документации по определению является более широким.
Поскольку с этой классификацией связано очень много вопросов и непонимания, отразим суть ещё раз — графически (см. рисунок 2.2.c) — и напомним, что мы до- говорились классифицировать документацию по признаку того, где (для чего) она является наиболее востребованной.
Рисунок 2.2.c — Соотношение понятий «продуктная документация» и «проектная документация»
Степень важности и глубина тестирования того или иного вида документации и даже отдельного документа определяется большим количеством факторов, но неизменным остаётся общий принцип: всё, что мы создаём в процессе разработки проекта (даже рисунки маркером на доске, даже письма, даже переписку в скайпе), можно считать документацией и так или иначе подвергать тестированию (напри- мер, вычитывание письма перед отправкой — это тоже своего рода тестирование документации).
65
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
]
66
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–2023
Стр: 37/301
2.2.3.
Источники и пути выявления требований
Требования начинают свою жизнь на стороне заказчика. Их сбор (gathering) и выявление (elicitation) осуществляются с помощью следующих основных техник
67
(
рисунок 2.2.d).
Интервью. Самый универсальный путь выявления требований, заключаю- щийся в общении проектного специалиста (как правило, специалиста по бизнес- анализу) и представителя заказчика (или эксперта, пользователя и т.д.). Интервью может проходить в классическом понимании этого слова (беседа в виде «вопрос- ответ»), в виде переписки и т.п. Главным здесь является то, что ключевыми фигу- рами выступают двое — интервьюируемый и интервьюер (хотя это и не исключает наличия «аудитории слушателей», например, в виде лиц, поставленных в копию переписки).
Работа с фокусными группами. Может выступать как вариант «расширен- ного интервью», где источником информации является не одно лицо, а группа лиц
(как правило, представляющих собой целевую аудиторию, и/или обладающих важ- ной для проекта информацией, и/или уполномоченных принимать важные для про- екта решения).
Рисунок 2.2.d — Основные техники сбора и выявления требований
Анкетирование. Этот вариант выявления требований вызывает много спо- ров, т.к. при неверной реализации может привести к нулевому результату при объ-
ёмных затратах. В то же время при правильной организации анкетирование позво- ляет автоматически собрать и обработать огромное количество ответов от огром- ного количества респондентов. Ключевым фактором успеха является правильное составление анкеты, правильный выбор аудитории и правильное преподнесение анкеты.
Семинары и мозговой штурм. Семинары позволяют группе людей очень быстро обменяться информацией (и наглядно продемонстрировать те или иные идеи), а также хорошо сочетаются с интервью, анкетированием, прототипирова- нием и моделированием — в том числе для обсуждения результатов и формирова- ния выводов и решений. Мозговой штурм может проводиться и как часть семинара, и как отдельный вид деятельности. Он позволяет за минимальное время сгенери-
67
Здесь можно почитать подробнее о том, в чём разница между сбором и выявлением требований: «Requirements Gathering vs. Elicitation
» (Laura Brandenburg): http://www.bridging-the-gap.com/requirements-gathering-vs-elicitation/
Интервью
Работа с фокусными группами
Анкетирование
Семинары и мозговой штурм
Наблюдение
Прототипирование
Анализ документов
Моделирование процессов и взаимодействий
Самостоятельное описание