Тестирование веб-ориентированных приложений (Kulikov - 2017) PDF

Министерство образования Республики Беларусь
Учреждение образования
«Белорусский государственный университет
информатики и радиоэлектроники»
Факультет компьютерных систем и сетей
Кафедра программного обеспечения

информационных технологий
С. С. Куликов, Г. В. Данилова
Р
УИ
ТЕСТИРОВАНИЕ
БГ
ВЕБ-ОРИЕНТИРОВАННЫХ ПРИЛОЖЕНИЙ
а
Рекомендовано УМО по образованию в области информатики
и радиоэлектроники для специальности
ек
1-40 01 01 «Программное обеспечение

информационных технологий»
т
в качестве учебно-методического пособия

ио
бл
Би
Минск БГУИР 2017

УДК 004.414.3(076.5)
ББК 32.973.26-018.2я73
К90
Р е ц е н з е н т ы:
кафедра информатики и веб-дизайна

учреждения образования
«Белорусский государственный технологический университет»
(протокол №3 от 13.10.2016);
доцент кафедры
Р
многопроцессорных систем и сетей
Белорусского государственного университета,
УИ
кандидат физико-математических наук, доцент Т. В. Соболева
БГ
а
т ек
Куликов, С. С.
ио
К90 Тестирование веб-ориентированных приложений : учеб.-

метод. пособие / С. С. Куликов, Г. В. Данилова. – Минск : БГУИР,
2017. – 100 с. : ил.
бл
ISBN 978-985-543-328-7.
Содержит материалы к практическим занятиям, включающие вопросы и

задания.
Би
УДК 004.414.3(076.5)
ББК 32.973.26-018.2я73
ISBN 978-985-543-328-7 © Куликов С. С., Данилова Г. В., 2017

© УО «Белорусский государственный
университет информатики
и радиоэлектроники», 2017
Тестирование веб-ориентированных пр иложений
СОДЕРЖАНИЕ
1 ТЕСТИРОВАНИЕ ДОКУМЕНТАЦИИ И ТРЕБОВАНИЙ ........................ 4

1.1 ЧТО ТАКОЕ «ТРЕБОВАНИЕ» ..................................................................... 4
1.2 ВАЖНОСТЬ ТРЕБОВАНИЙ ........................................................................ 4
1.3 ИСТОЧНИКИ И ПУТИ ВЫЯВЛЕНИЯ ТРЕБОВАНИЙ ......................................... 9
1.4 УРОВНИ И ТИПЫ ТРЕБОВАНИЙ ............................................................... 12
1.5 СВОЙСТВА КАЧЕСТВЕННЫХ ТРЕБОВАНИЙ ............................................... 17
1.6 ТЕХНИКИ ТЕСТИРОВАНИЯ ТРЕБОВАНИЙ.................................................. 24
1.7 КОНТРОЛЬНЫЕ ВОПРОСЫ И ЗАДАНИЯ ..................................................... 29
Р
2 ЧЕК-ЛИСТЫ, ТЕСТ-КЕЙСЫ, НАБОРЫ ТЕСТ-КЕЙСОВ .................... 30
УИ
2.1 ЧЕК-ЛИСТЫ .......................................................................................... 30
2.2 ТЕСТ-КЕЙСЫ ........................................................................................ 35
2.3 АТРИБУТЫ (ПОЛЯ) ТЕСТ-КЕЙСА ............................................................. 38
2.4 СВОЙСТВА КАЧЕСТВЕННЫХ ТЕСТ-КЕЙСОВ .............................................. 45
2.5
2.6
БГ
НАБОРЫ ТЕСТ-КЕЙСОВ ......................................................................... 59
КОНТРОЛЬНЫЕ ВОПРОСЫ И ЗАДАНИЯ ..................................................... 66
3 ОТЧЁТЫ О ДЕФЕКТАХ ........................................................................ 67
а
3.1 ОШИБКИ, ДЕФЕКТЫ, СБОИ, ОТКАЗЫ ........................................................ 67
3.2 ОТЧЁТ О ДЕФЕКТЕ И ЕГО ЖИЗНЕННЫЙ ЦИКЛ............................................ 70
ек
3.3 АТРИБУТЫ (ПОЛЯ) ОТЧЁТА О ДЕФЕКТЕ ................................................... 74

3.4 СВОЙСТВА КАЧЕСТВЕННЫХ ОТЧЁТОВ О ДЕФЕКТАХ................................... 87
3.5 КОНТРОЛЬНЫЕ ВОПРОСЫ И ЗАДАНИЯ ..................................................... 93
т
ио
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ ...................................... 95

бл
Би
3
1 ТЕСТИРОВАНИЕ ДОКУМЕНТАЦИИ И ТРЕБОВАНИЙ
1.1 Что такое «требование»
Всё так или иначе начинается с документации и требований.
Требование (requirement1) – описание того, какие функции и с

соблюдением каких условий должно выполнять приложение в
процессе решения полезной для пользователя задачи.
Небольшое «историческое отступление»: если поискать опре-
Р
деления требования в литературе 10-, 20-, 30-летней давности,
то можно заметить, что изначально о пользователях, их задачах
УИ
и полезных для них свойствах приложения в определении тре-
бования не было сказано. Пользователь выступал некоей аб-
страктной фигурой, не имеющей отношения к приложению. В
настоящее время такой подход недопустим, т. к. он не только
БГ
приводит к коммерческому провалу продукта на рынке, но и
многократно повышает затраты на разработку и тестирование.
Хорошим кратким предисловием ко всему тому, что будет рас-

а
смотрено в данной главе, можно считать небольшую статью
«What is documentation testing in software testing»2.
ек
1.2 Важность требований

т
Требования являются отправной точкой для определения того, что

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

Элементарная логика говорит нам, что если в требованиях что-то «не то»,
то и реализовано будет «не то», т. е. колоссальная работа множества лю-
бл
дей будет выполнена впустую. Эту мысль иллюстрирует рисунок 1.a.

Брайан Хэнкс, описывая важность требований3, подчёркивает, что
они:
Би
 Позволяют понять, что и с соблюдением каких условий си-

стема должна делать.
 Предоставляют возможность оценить масштаб изменений и
управлять изменениями.
1
Requirement. A condition or capability needed by a user to solve a problem or achieve an
objective that must be met or possessed by a system or system component to satisfy a contract,
standard, specification, or other formally imposed document. ISQTQB glossary.
2
What is documentation testing in software testing. URL: http://istqbexamcertification.com/
what-is-documentation-testing/.
3
Requirements in the Real World / B. Hanks URL: https://classes.soe.ucsc.edu/cmps109/
Winter02/notes/requirementsLecture.pdf.
4
 Являются основой для формирования плана проекта (в том
числе плана тестирования).
 Помогают предотвращать или разрешать конфликтные ситу-
ации.
 Упрощают расстановку приоритетов в наборе задач.
 Позволяют объективно оценить степень прогресса в разра-
ботке проекта.
Вне зависимости от того, какая модель разработки ПО использует-
ся на проекте, чем позже будет обнаружена проблема, тем сложнее и
дороже будет её решение. А в самом начале («водопада», «спуска по
букве v», «итерации», «витка спирали») идёт планирование и работа с
Р
требованиями.
Если проблема в требованиях будет выяснена на этой стадии, её
УИ
решение может свестись к исправлению пары слов в тексте, в то время
как недоработка, вызванная пропущенной проблемой в требованиях и
обнаруженная на стадии эксплуатации, может даже полностью уничто-
жить проект.
1000
Стоимость
исправления
ошибки
БГ
а
ек
500
т
ио
20
бл
Время,
затраченное
на проект
0
Общее Системные Детализированный Интеграция и Системное Итоговая

Би
планирование требования дизайн модульные тесты тестирование отчётность

Пользовательские Техническая Разработка и Инсталляционное Приёмочное
Эксплуатация
требования архитектура отладка тестирование тестирование
Рисунок 1.a – Стоимость исправления ошибки в зависимости

от момента её обнаружения
Если графики вас не убеждают, попробуем проиллюстрировать ту

же мысль на простом примере. Допустим, вы с друзьями составляете
список покупок перед поездкой в гипермаркет. Вы поедете покупать, а
друзья ждут вас дома. Сколько «стоит» дописать, вычеркнуть или изме-
нить пару пунктов, пока вы только-только составляете список? Нисколь-
5
ко. Если мысль о несовершенстве списка настигла вас по пути в гипер-
маркет, уже придётся звонить (дёшево, но не бесплатно). Если вы поня-
ли, что в списке «что-то не то» в очереди на кассу, придётся возвра-
щаться в торговый зал и тратить время. Если проблема выяснилась по
пути домой или даже дома, придётся вернуться в гипермаркет. И, нако-
нец, «клинический» случай: в списке изначально было что-то уж совсем
неправильное (например, «100 кг конфет – и всё»), поездка совершена,
все деньги потрачены, конфеты привезены и только тут выясняется, что
«ну, мы же пошутили».
Задание 1.a: представьте, что ваш с друзьями бюджет ограни-
Р
чен, и в списке требований появляются приоритеты (что-то ку-
пить надо обязательно, что-то, если останутся деньги, и т. п.).
УИ
Как это повлияет на риски, связанные с ошибками в списке?
Ещё одним аргументом в пользу тестирования требований являет-

ся то, что по разным оценкам в них зарождается от ½ до ¾ всех проблем
БГ
с программным обеспечением. В итоге есть риск, что получится так, как
показано на рисунке 1.b.
а
т ек
ио
Так клиент Так проект был

Так клиента понял Так аналитик Так программист
объяснил, чего он прорекламирован
менеджер проекта описал проект реализовал проект
хочет консультантами
бл
Би
Так проект был В такую сумму Так работала Что на самом деле
Так проект был
сдан в проект обошёлся техническая было нужно
задокументирован
эксплуатацию заказчику поддержка клиенту
Рисунок 1.b – Типичный проект с плохими требованиями
6
Поскольку мы постоянно говорим «документация и требования», а
не просто «требования», то стоит рассмотреть перечень документации,
которая должна подвергаться тестированию в процессе разработки ПО
(хотя далее мы будем концентрироваться именно на требованиях).
В общем случае документацию можно разделить на два больших
вида в зависимости от времени и места её использования (здесь будет
очень много сносок с определениями, т. к. по видам документации очень
часто поступает множество вопросов и потому придётся рассмотреть
некоторые моменты подробнее).
 Продуктная документация (product documentation, develop-
ment documentation4) используется проектной командой во время
Р
разработки и поддержки продукта. Она включает:
o План проекта (project management plan5) и в том числе
УИ
тестовый план (test plan6).
o Требования к программному продукту (product require-
ments document, PRD7) и функциональные спецификации
(functional specifications8 document, FSD9; software requirements
4
specification, SRS10).
БГ
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 de-
а
scription, test and review reports (suggesting product improvements), and self-reflective docu-
ments written by team members, analyzing the process from their perspective. Barker Thomas T.
ек
Documentation for software and IS development.

5
Project management plan. A formal, approved document that defines how the project is
execu-ted, 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. – 3rd ed.
6
Test plan. A document describing the scope, approach, resources and schedule of in-
ио
tended 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.
бл
7
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 cus-
tomer support efforts. The purpose of the product requirements document (PRD) or product spec is
to clearly and unambiguously articulate the product’s purpose, features, functionality, and behavior.
Би
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. Cagan M. How to
write a good PRD.
8
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.
9
Functional specifications document, FSD. См. «Software requirements specification,
SRS».
10
Software requirements specification, SRS. SRS describes as fully as necessary the ex-
pected behavior of the software system. The SRS is used in development, testing, quality assur-
ance, project management, and related project functions. People call this deliverable by many dif-
ferent names, including business requirements document, functional spec, requirements docu-
ment, and others. Wiegers K., Beatty J. Software Requirements. – 3rd ed.
7
o Архитектуру и дизайн (architecture and design11).
o Тест-кейсы и наборы тест-кейсов (test cases12, test
suites13).
o Технические спецификации (technical specifications14),
такие как схемы баз данных, описания алгоритмов, интер-
фейсов и т. д.
 Проектная документация (project documentation15) включает
в себя как продуктную документацию, так и некоторые дополни-
тельные виды документации и используется не только на стадии
разработки, но и на более ранних и поздних стадиях (например, на
стадии внедрения и эксплуатации). Она включает:
Р
o Пользовательскую и сопроводительную документацию
(user and accompanying documentation16), такую как встроен-
УИ
ная помощь, руководство по установке и использованию, ли-
цензионные соглашения и т. д.
o Маркетинговую документацию (market requirements doc-
ument, MRD17), которую представители разработчика или за-
БГ
казчика используют как на начальных этапах (для уточнения
сути и концепции проекта), так и на финальных этапах разви-
тия проекта (для продвижения продукта на рынке).
В некоторых классификациях часть документов из продуктной до-
а
кументации может быть перечислена в проектной документации – это
ек
11
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 con-
ио
straints 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 implementa-
tion. Documenting Software Architectures / P. Clements [et al.]. Очень подробное описание раз-
личия архитектуры и дизайна можно найти в статье Eden A., Kazman R. Architecture, Design,
бл
Implementation. URL: http://www.eden-study.org/articles/2003/icse03.pdf.

12
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 particu-
lar program path or to verify compliance with a specific requirement. ISTQB Glossary.
Би
13
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.
14
Technical specifications. Scripts, source code, data definition language, etc. PMBOK,
3 ed. Также см. «Specification».
rd
15
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. Wiegers K., Beatty J. Software Requirements. – 3rd ed.
16
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.
17
Market requirements document, MRD. An MRD goes into details about the target mar-
ket segments and the issues that pertain to commercial success. Wiegers K., Beatty J. Software
Requirements. – 3rd ed.
8
совершенно нормально, т. к. понятие проектной документации по опре-
делению является более широким. Поскольку с этой классификацией
связано очень много вопросов и непонимания, отразим суть ещё раз –
графически (рисунок 1.c) – и напомним, что мы договорились класси-
фицировать документацию по признаку того, где (для чего) она является
наиболее востребованной.
Р
УИ
БГ
а
ек
Рисунок 1.c – Соотношение понятий «продуктная документация»

и «проектная документация»
т
Степень важности и глубина тестирования того или иного вида до-

кументации и даже отдельного документа определяется большим коли-
ио
чеством факторов, но неизменным остаётся общий принцип: всё, что мы

создаём в процессе разработки проекта (даже рисунки маркером на дос-
ке, даже письма, даже переписку в скайпе), можно считать документаци-
бл
ей и так или иначе подвергать тестированию (например, вычитывание

письма перед отправкой – это тоже своего рода тестирование докумен-
тации).
Би
1.3 Источники и пути выявления требований
Требования «начинают свою жизнь» на стороне заказчика. Их сбор

(gathering) и выявление (elicitation) осуществляются с помощью следую-
щих основных техник18 (рисунок 1.d).
18
Здесь можно почитать подробнее о том, в чём разница между сбором и выявлени-
ем требований. Brandenburg L. Requirements Gathering vs. Elicitation. URL: http://www.bridging-
the-gap.com/requirements-gathering-vs-elicitation/.
9
Интервью. Самый универсальный путь выявления требований, за-
ключающийся в общении проектного специалиста (как правило, специа-
листа по бизнес-анализу) и представителя заказчика (или эксперта,
пользователя и т. д.) Интервью может проходить в классическом пони-
мании этого слова (беседа в виде «вопрос – ответ»), в виде переписки и
т. п. Главным здесь является то, что ключевыми фигурами выступают
двое – интервьюируемый и интервьюер (хотя это и не исключает нали-
чия «аудитории слушателей», например, в виде лиц, поставленных в ко-
пию переписки).
Работа с фокусными группами. Может выступать как вариант
«расширенного интервью», где источником информации является не од-
Р
но лицо, а группа лиц (как правило, представляющих собой целевую
аудиторию, и/или обладающих важной для проекта информацией, и/или
УИ
уполномоченных принимать важные для проекта решения).
Работа
Интервью с фокусными Анкетирование
Семинары
БГ
группами
а
и мозговые Наблюдение Прототипирование
штурмы
ек
Моделирование
т
Анализ документов процессов Самостоятельное

ио
и взаимодействий описание
Рисунок 1.d – Основные техники сбора и выявления требований

бл
Анкетирование. Этот вариант выявления требований вызывает

много споров, т. к. при неверной реализации может привести к нулевому
Би
результату при объёмных затратах. В то же время при правильной орга-

низации анкетирование позволяет автоматически собрать и обработать
огромное количество ответов от огромного количества респондентов.
Ключевым фактором успеха является правильное составление анкеты,
правильный выбор аудитории и правильное преподнесение анкеты.
Семинары и мозговой штурм. Семинары позволяют группе лю-
дей очень быстро обменяться информацией (и наглядно продемонстри-
ровать те или иные идеи), а также хорошо сочетаются с интервью, анке-
тированием, прототипированием и моделированием – в том числе для
обсуждения результатов и формирования выводов и решений. Мозговой
10
штурм может проводиться и как часть семинара, и как отдельный вид
деятельности. Он позволяет за минимальное время сгенерировать
большое количество идей, которые в дальнейшем можно не спеша рас-
смотреть с точки зрения их использования для развития проекта.
Наблюдение. Может выражаться как в буквальном наблюдении за
некими процессами, так и во включении проектного специалиста в эти
процессы в качестве участника. С одной стороны, наблюдение позволя-
ет увидеть то, о чём (по совершенно различным соображениям) могут
умолчать интервьюируемые, анкетируемые и представители фокусных
групп, но с другой – отнимает очень много времени и чаще всего поз-
воляет увидеть лишь часть процессов.
Р
Прототипирование. Состоит в демонстрации и обсуждении про-
межуточных версий продукта (например, дизайн страниц сайта может
УИ
быть сначала представлен в виде картинок и лишь затем свёрстан). Это
один из лучших путей поиска единого понимания и уточнения требова-
ний, однако он может привести к серьёзным дополнительным затратам
при отсутствии специальных инструментов (позволяющих быстро созда-
БГ
вать прототипы) и слишком раннем применении (когда требования ещё
не стабильны, и высока вероятность создания прототипа, имеющего ма-
ло общего с тем, что хотел заказчик).
Анализ документов. Хорошо работает тогда, когда эксперты в
а
предметной области (временно) недоступны, а также в предметных об-
ластях, имеющих общепринятую устоявшуюся регламентирующую до-
ек
кументацию. Также к этой технике относится и просто изучение докумен-

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

ио
Моделирование процессов и взаимодействий. Может приме-

няться как к «бизнес-процессам и взаимодействиям» (например: «дого-
вор на закупку формируется отделом закупок, визируется бухгалте-
бл
рией и юридическим отделом…»), так и к «техническим процессам и

взаимодействиям» (например: «платёжное поручение генерируется
модулем “Бухгалтерия”, шифруется модулем “Безопасность” и пере-
Би
даётся на сохранение в модуль “Хранилище”»). Данная техника требует

высокой квалификации специалиста по бизнес-анализу, т. к. сопряжена с
обработкой большого объёма сложной (и часто плохо структурирован-
ной) информации.
Самостоятельное описание. Является не столько техникой выяв-
ления требований, сколько техникой их фиксации и формализации.
Очень сложно (и даже нельзя!) пытаться самому «придумать требования
за заказчика», но в спокойной обстановке можно самостоятельно обра-
ботать собранную информацию и аккуратно оформить её для дальней-
шего обсуждения и уточнения.
11
Часто специалисты по бизнес-анализу приходят в свою профес-
сию из тестирования. Если вас заинтересовало это направле-
ние, стоит ознакомиться со следующими книгами:
 Корнипаев И. Требования для программного обеспечения:
рекомендации по сбору и документированию.
 Cadle J., Paul D., Turner P. Business Analysis Techniques. 72
Essential Tools for Success.
 Paul D., Yeates D., Cadle J. Business Analysis. – 2 еd.
1.4 Уровни и типы требований
Р
Форма представления, степень детализации и перечень полезных
УИ
свойств требований зависят от уровней и типов требований19, которые
схематично представлены на рисунке 1.e.
Бизнес-требования (business requirements20) выражают цель, ради
которой разрабатывается продукт (зачем вообще он нужен, какая от не-
БГ
го ожидается польза). Результатом выявления требований на этом
уровне является общее видение (vision and scope21) – документ, кото-
рый, как правило, представлен простым текстом и таблицами. Здесь нет
детализации поведения системы и иных технических характеристик, но
а
вполне могут быть определены приоритеты решаемых бизнес-задач,
риски и т. п.
ек
Несколько простых, изолированных от контекста и друг от друга

примеров бизнес-требований:
т
 Нужен инструмент, в реальном времени отображающий

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

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

Би
19
Очень подробное описание уровней и типов требований (а также их применения)
можно найти в статье Westfall L. Software Requirements Engineering: What, Why, Who, When,
and How. URL: http://www.westfallteam.com/Papers/The_Why_What_Who_When_and_How_Of_
Software_Requirements.pdf.
20
Business requirement. Anything that describes the financial, marketplace, or other
business benefit that either customers or the developing organization wish to gain from the prod-
uct. Wiegers K., Beatty J. Software Requirements. – 3rd ed.
21
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. Wiegers K.,
Beatty J. Software Requirements. – 3rd ed.
12
Бизнес-требования
Уровень бизнес-
требований
Общее видение
проекта
Уровень
Пользовательские
пользовательских Бизнес-правила Атрибуты качества
требования
требований
Варианты
использования
Функциональные Нефункциональные
требования требования
Р
Уровень
продуктных
требований Ограничения
УИ
Спецификация Требования к
требований интерфейсам
Требования к данным
БГ
Рисунок 1.e – Уровни и типы требований
Пользовательские требования (user requirements22) описывают

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

оценки объёма работ, стоимости проекта, времени разработки и т. д.
Пользовательские требования оформляются в виде вариантов исполь-
т
зования (use cases23), пользовательских историй (user stories24), пользо-

ио
вательских сценариев (user scenarios25). (Также см. «Создание пользо-

вательских сценариев» в подразделе 2.5).
бл
примеров пользовательских требований:

 При первом входе пользователя в систему должно отобра-
жаться лицензионное соглашение.
Би
22
User requirement. User requirements are general statements of user goals or business
tasks that users need to perform. Wiegers K., Beatty J. Software Requirements. – 3rd ed.
23
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 in-
formation with the system. ISTQB Glossary.
24
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.
25
A scenario is a hypothetical story, used to help a person think through a complex
problem or system. Kaner C. An Introduction to Scenario Testing. URL:
http://www.kaner.com/pdfs/ScenarioIntroVer4.pdf.
13
 Администратор должен иметь возможность просматри-
вать список всех пользователей, работающих в данный момент
в системе.
 При первом сохранении новой статьи система должна вы-
давать запрос на сохранение в виде черновика или публикацию.
Бизнес-правила (business rules26) описывают особенности приня-
тых в предметной области (и/или непосредственно у заказчика) процес-
сов, ограничений и иных правил. Эти правила могут относиться к бизнес-
процессам, правилам работы сотрудников, нюансам работы ПО и т. д.
примеров бизнес-правил:
Р
 Никакой документ, просмотренный посетителями сайта
хотя бы один раз, не может быть отредактирован или удалён.
УИ
 Публикация статьи возможна только после утверждения
главным редактором.
 Подключение к системе извне офиса запрещено в нерабо-
чее время.
БГ
Атрибуты качества (quality attributes27) расширяют собой нефунк-
циональные требования и на уровне пользовательских требований мо-
гут быть представлены в виде описания ключевых для проекта показа-
телей качества (свойств продукта, не связанных с функциональностью,
а
но являющихся важными для достижения целей создания продукта –
производительность, масштабируемость, восстанавливаемость). Атри-
ек
бутов качества очень много28, но для любого проекта реально важными

являются лишь некоторые их подмножества.
т

примеров атрибутов качества:
ио
 Максимальное время готовности системы к выполнению

новой команды после отмены предыдущей не может превышать
одну секунду.
бл
 Внесённые в текст статьи изменения не должны быть

утеряны при нарушении соединения между клиентом и сервером.
 Приложение должно поддерживать добавление произволь-
Би
ного количества неиероглифических языков интерфейса.
26
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 remov-
al of persistent data in an information system. Defining Business Rules – What Are They Really /
D. Hау [et al.].
27
Quality attribute. A feature or characteristic that affects an item’s quality. ISTQB
Glossary.
28
Даже в Википедии их список огромен. URL: http://en.wikipedia.org/wiki/
List_of_system_quality_attributes.
14
Функциональные требования (functional requirements29) описы-
вают поведение системы, т. е. её действия (вычисления, преобразова-
ния, проверки, обработку и т. д.) В контексте проектирования функцио-
нальные требования в основном влияют на дизайн системы.
примеров функциональных требований:
 В процессе инсталляции приложение должно проверять
остаток свободного места на целевом носителе.
 Система должна автоматически выполнять резервное ко-
пирование данных ежедневно в указанный момент времени.
 Электронный адрес пользователя, вводимый при реги-
Р
страции, должен быть проверен на соответствие требованиям
RFC822.
УИ
Нефункциональные требования (non-functional requirements30)
описывают свойства системы (удобство использования, безопасность,
надёжность, расширяемость и т. д.), которыми она должна обладать при
реализации своего поведения. Здесь приводится более техническое и
БГ
детальное описание атрибутов качества. В контексте проектирования
нефункциональные требования в основном влияют на архитектуру си-
стемы.
а
примеров нефункциональных требований:
 При одновременной непрерывной работе с системой 1000
ек
пользователей, минимальное время между возникновением сбоев

должно быть более или равно 100 ч.
т
 Ни при каких условиях общий объём используемой приложе-

нием памяти не может превышать 2 ГБ.
ио
 Размер шрифта для любой надписи на экране должен под-

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

(здесь для простоты рассмотрены лишь три таких подгруппы, но их мо-
жет быть и гораздо больше; как правило, они проистекают из атрибутов
Би
качества, но высокая степень детализации позволяет отнести их к уров-

ню требований к продукту).
Ограничения (limitations, constraints31) представляют собой факто-
29
Functional requirement. A requirement that specifies a function that a component or
system must perform. [ISTQB Glossary] Functional requirements describe the observable behav-
iors the system will exhibit under certain conditions and the actions the system will let users take.
Wiegers K., Beatty J. Software Requirements. – 3rd ed.
30
Non-functional requirement. A requirement that does not relate to functionality, but to
attributes such as reliability, efficiency, usability, maintainability and portability. ISTQB Glossary.
31
Limitation, constraint. Design and implementation constraints legitimately restrict the
options available to the developer. Wiegers K., Beatty J. Software Requirements. – 3rd ed.
15
ры, ограничивающие выбор способов и средств (в том числе инструмен-
тов) реализации продукта.
примеров ограничений:
 Все элементы интерфейса должны отображаться без про-
крутки при разрешениях экрана от 800x600 до 1920x1080.
 Не допускается использование Flash при реализации кли-
ентской части приложения.
 Приложение должно сохранять способность реализовывать
функции с уровнем важности «критический» при отсутствии у
клиента поддержки JavaScript.
Р
Требования к интерфейсам (external interfaces requirements32)
описывают особенности взаимодействия разрабатываемой системы с
УИ
другими системами и операционной средой.
примеров требований к интерфейсам:
 Обмен данными между клиентской и серверной частями

БГ
приложения при осуществлении фоновых AJAX-запросов должен
быть реализован в формате JSON.
Протоколирование событий должно вестись в журнале со-
бытий операционной системы.
а
 Соединение с почтовым сервером должно выполняться со-
ек
гласно RFC3207 («SMTP over TLS»).

Требования к данным (data requirements33) описывают структуры
данных (и сами данные), являющиеся неотъемлемой частью разрабаты-
т
ваемой системы. Часто сюда относят описание базы данных и особен-

ностей её использования.
ио

примеров требований к данным:
 Все данные системы, за исключением пользовательских до-
бл
кументов, должны храниться в БД под управлением СУБД

MySQL, пользовательские документы должны храниться в БД
под управлением СУБД MongoDB.
Би
 Информация о кассовых транзакциях за текущий месяц

должна храниться в операционной таблице, а по завершении ме-
сяца переноситься в архивную.
 Для ускорения операций поиска по тексту статей и обзо-
32
External interface requirements. Requirements in this category describe the connec-
tions between the system and the rest of the universe. They include interfaces to users, hardware,
and other software systems. Wiegers K., Beatty J. Software Requirements. – 3rd ed.
33
Data requirements. Data requirement describe the format, data type, allowed values, or
default value for a data element; the composition of a complex business data structure; or a report
to be generated. Wiegers K., Beatty J. Software Requirements. – 3rd ed.
16
Одобренный
user, 03.06.2020, 8:36:25
ров должны быть предусмотрены полнотекстовые индексы на

соответствующих полях таблиц.
Спецификация требований (software requirements specification,
SRS ) объединяет в себе описание всех требований уровня продукта и
34
может представлять собой весьма объёмный документ (сотни и тысячи

страниц).
Поскольку требований может быть очень много, а их приходится не
только единожды написать и согласовать между собой, но и постоянно
обновлять, работу проектной команды по управлению требованиями
значительно облегчают соответствующие инструментальные средства
(requirements management tools35, 36).
Р
Для более глубокого понимания принципов создания, организа-
УИ
ции и использования набора требований рекомендуется озна-
комиться с фундаментальной работой Карла Вигерса «Разра-
ботка требований к программному обеспечению» (Wiegers K.,
Beatty J. Software Requirements. – 3rd еd. (Developer Best Practic-
БГ
es). В этой же книге (в приложениях) приведены весьма нагляд-
ные учебные примеры документов, описывающих требования
различного уровня.
а
1.5 Свойства качественных требований
ек
В процессе тестирования требований проверяется их соответствие

определённому набору свойств (рисунок 1.f).
т
Завершённость (completeness37). Требование является полным и

ио
законченным с точки зрения представления в нём всей необходимой

информации, ничто не пропущено по соображениям «это и так всем по-
нятно».
бл
34
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 assur-
Би
ance, project management, and related project functions. People call this deliverable by many dif-
ferent names, including business requirements document, functional spec, requirements docu-
ment, and others. Wiegers K., Beatty J. Software Requirements. – 3rd ed.
35
Requirements management tool. A tool that supports the recording of requirements,
requirements attributes (e.g. priority, knowledge responsible) and annotation, and facilitates trace-
ability through layers of requirements and requirements change management. Some requirements
management tools also provide facilities for static analysis, such as consistency checking and vio-
lations to predefined requirements rules. ISTQB Glossary.
36
Обширный список инструментальных средств управления требованиями можно
найти здесь. URL: http://makingofsoftware.com/resources/list-of-rm-tools.
37
Each requirement must contain all the information necessary for the reader to understand
it. In the case of functional requirements, this means providing the information the developer needs
to be able to implement it correctly. No requirement or necessary information should be absent.
17
Типичные проблемы с завершённостью:
 Отсутствуют нефункциональные составляющие требования
или ссылки на соответствующие нефункциональные требования
(например: «пароли должны храниться в зашифрованном виде» –
каков алгоритм шифрования?).
 Указана лишь часть некоторого перечисления (например:
«экспорт осуществляется в форматы PDF, PNG и т. д.» – что
мы должны понимать под «и т. д.»?).
 Приведённые ссылки неоднозначны (например: «см. выше»
вместо «см. раздел 123.45.b»).
Р
Обязательность Актуальность
УИ
Модифицируемость Атомарность
Прослеживаемость Завершённость
Корректность и
Недвусмысленность
Непротиворечивость
проверяемость
БГ Выполнимость
а
Проранжированность
ек
Важность Стабильность Срочность

т
Рисунок 1.f – Свойства качественного требования

ио
Атомарность, единичность (atomicity38). Требование является

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

Типичные проблемы с атомарностью:
 В одном требовании фактически содержится несколько неза-
висимых (например: «кнопка “Restart” не должна отображаться
Би
при остановленном сервисе, окно “Log” должно вмещать не ме-

нее 20-ти записей о последних действиях пользователя» –
здесь зачем-то в одном предложении описаны совершенно разные
элементы интерфейса в совершенно разных контекстах).
 Требование допускает разночтение в силу грамматических
особенностей языка (например: «если пользователь подтвержда-
38
Each requirement you write represents a single market need that you either satisfy or fail
to satisfy. A well written requirement is independently deliverable and represents an incremental
increase in the value of your software. Blain T. Writing Good Requirements – The Big Ten Rules.
URL: http://tynerblain.com/blog/2006/05/25/writing-good-requirements-the-big-ten-rules/.
18
ет заказ и редактирует заказ или откладывает заказ, должен
выдаваться запрос на оплату» – здесь описаны три разных слу-
чая, и это требование стоит разбить на три отдельных во избежа-
ние путаницы). Такое нарушение атомарности часто влечёт за со-
бой возникновение противоречивости.
 В одном требовании объединено описание нескольких неза-
висимых ситуаций (например: «когда пользователь входит в си-
стему, ему должно отображаться приветствие; когда пользо-
ватель вошёл в систему, должно отображаться имя пользова-
теля; когда пользователь выходит из системы, должно отобра-
жаться прощание» – все эти три ситуации заслуживают того,
Р
чтобы быть описанными отдельными и куда более детальными
требованиями).
УИ
Непротиворечивость, последовательность (consistency39). Тре-
бование не должно содержать внутренних противоречий и противоречий
другим требованиям и документам.
Типичные проблемы с непротиворечивостью:

БГ
Противоречия внутри одного требования (например: «после
успешного входа в систему пользователя, не имеющего права
входить в систему…» – тогда как он успешно вошёл в систему,
если не имел такого права?).
а
 Противоречия между двумя и более требованиями, между
таблицей и текстом, рисунком и текстом, требованием и прототи-
ек
пом и т. д. (например: «712.a Кнопка “Close” всегда должна быть

красной» и «36452.x Кнопка “Close” всегда должна быть синей» –
т
так всё же красной или синей?).

 Использование неверной терминологии или использование
ио
разных терминов для обозначения одного и того же объекта или

явления (например: «в случае, если разрешение окна составляет
менее 800x600…» – разрешение есть у экрана, у окна есть раз-
бл
мер).
Недвусмысленность (unambiguousness40, clearness). Требование
описано без использования жаргона, неочевидных аббревиатур и рас-
Би
плывчатых формулировок и допускает только однозначное объективное

понимание. Требование атомарно в плане невозможности различной
трактовки сочетания отдельных фраз.
39
Consistent requirements don’t conflict with other requirements of the same type or with
higher-level business, user, or system requirements. Wiegers K., Beatty J. Software Requirements. –
3rd ed.
40
Natural language is prone to two types of ambiguity. One type I can spot myself, when I
can think of more than one way to interpret a given requirement. The other type of ambiguity is
harder to catch. That’s when different people read the requirement and come up with different in-
terpretations of it. Wiegers K., Beatty J. Software Requirements. – 3rd ed.
19
Типичные проблемы с недвусмысленностью:
 Использование терминов или фраз, допускающих субъективное
толкование (например: «приложение должно поддерживать передачу
больших объёмов данных» – насколько «больших»?). Вот лишь не-
большой перечень слов и выражений, которые можно считать верны-
ми признаками двусмысленности: адекватно (adequate), быть способ-
ным (be able to), легко (easy), обеспечивать (provide for), как минимум
(as a minimum), быть способным (be capable of), эффективно (effective-
ly), своевременно (timely), применимо (as applicable), если возможно (if
possible), будет определено позже (to be determined, TBD), по мере
необходимости (as appropriate), если это целесообразно (if practical),
Р
но не ограничиваясь (but not limited to), быть способно (capability of),
иметь возможность (capability to), нормально (normal), минимизиро-
УИ
вать (minimize), максимизировать (maximize), оптимизировать
(optimize), быстро (rapid), удобно (user-friendly), просто (simple), часто
(often), обычно (usual), большой (large), гибкий (flexible), устойчивый
(robust), по последнему слову техники (state-of-the-art), улучшенный
БГ
(improved), результативно (efficient). Вот утрированный пример требо-
вания, звучащего очень красиво, но совершенно нереализуемого и
непонятного: «В случае необходимости оптимизации передачи
больших файлов система должна эффективно использовать мини-
а
мум оперативной памяти, если это возможно».
 Использование неочевидных или двусмысленных аббревиа-
ек
тур без расшифровки (например: «доступ к ФС осуществляется

посредством системы прозрачного шифрования» и «ФС предо-
ставляет возможность фиксировать сообщения в их текущем
т
состоянии с хранением истории всех изменений» – ФС здесь

ио
обозначает файловую систему? Точно? А не какой-нибудь «Фикса-

тор Сообщений»?).
 Формулировка требований из соображений, что нечто должно
бл
быть всем очевидно (например: «Система конвертирует входной

файл из формата PDF в выходной файл формата PNG» – и при
этом автор считает совершенно очевидным, что имена файлов си-
Би
стема получает из командной строки, а многостраничный PDF кон-

вертируется в несколько PNG-файлов, к именам которых добавля-
ется «page-1», «page-2» и т. д.). Эта проблема перекликается с
нарушением корректности.
Выполнимость (feasibility41). Требование технологически выпол-
нимо и может быть реализовано в рамках бюджета и сроков разработки
проекта.
41
It must be possible to implement each requirement within the known capabilities and limi-
tations of the system and its operating environment, as well as within project constraints of time,
budget, and staff. Wiegers K., Beatty J. Software Requirements. – 3rd ed.
20
Типичные проблемы с выполнимостью:
 Так называемое «озолочение» (gold plating) – требования,
которые крайне долго и/или дорого реализуются и при этом прак-
тически бесполезны для конечных пользователей (например:
«настройка параметров для подключения к базе данных должна
поддерживать распознавание символов из жестов, полученных с
устройств трёхмерного ввода»).
 Технически нереализуемые на современном уровне развития
технологий требования (например: «анализ договоров должен вы-
полняться с применением искусственного интеллекта, который
будет выносить однозначное корректное заключение о степени
Р
выгоды от заключения договора»).
 В принципе нереализуемые требования (например: «система
УИ
поиска должна заранее предусматривать все возможные вари-
анты поисковых запросов и кэшировать их результаты»).
Обязательность, нужность (obligation42) и актуальность (up-to-
date). Если требование не является обязательным к реализации, оно
БГ
должно быть просто исключено из набора требований. Если требование
нужное, но «не очень важное», для указания этого факта используется
указание приоритета (см. «проранжированность по…»). Также исключе-
ны (или переработаны) должны быть требования, утратившие актуаль-
а
ность.
Типичные проблемы с обязательностью и актуальностью:
ек
 Требование было добавлено «на всякий случай», хотя реаль-

ной потребности в нём не было и нет.
т
 Требованию выставлены неверные значения приоритета по

критериям важности и/или срочности.
ио
 Требование устарело, но не было переработано или удалено.

Прослеживаемость (traceability43, 44). Прослеживаемость бывает
вертикальной (vertical traceability45) и горизонтальной (horizontal traceabil-
бл
Би
42
Each requirement should describe a capability that provides stakeholders with the antici-
pated business value, differentiates the product in the marketplace, or is required for conformance
to an external standard, policy, or regulation. Every requirement should originate from
a source that has the authority to provide requirements. Wiegers K., Beatty J. Software Require-
ments. – 3rd ed.
43
Traceability. The ability to identify related items in documentation and software, such as
requirements with associated tests. ISTQB Glossary.
44
A traceable requirement can be linked both backward to its origin and forward to derived
requirements, design elements, code that implements it, and tests that verify its implementation.
45
Vertical traceability. The tracing of requirements through the layers of development
documentation to components. ISTQB Glossary.
21
ity46). Вертикальная позволяет соотносить между собой требования на раз-
личных уровнях требований, горизонтальная позволяет соотносить требо-
вание с тест-планом, тест-кейсами, архитектурными решениями и т. д.
Для обеспечения прослеживаемости часто используются специ-
альные инструменты по управлению требованиями (requirements man-
agement tool47) и/или матрицы прослеживаемости (traceability matrix48).
Типичные проблемы с прослеживаемостью:
 Требования не пронумерованы, не структурированы, не име-
ют оглавления, не имеют работающих перекрёстных ссылок.
 При разработке требований не были использованы инстру-
менты и техники управления требованиями.
Р
 Набор требований неполный, носит обрывочный характер с
явными «пробелами».
УИ
Модифицируемость (modifiability49). Это свойство характеризует
простоту внесения изменений в отдельные требования и в набор требо-
ваний. Можно говорить о наличии модифицируемости в том случае, ес-
ли при доработке требований искомую информацию легко найти, а её
Типичные проблемы с модифицируемостью:


БГ
изменение не приводит к нарушению иных описанных в этом перечне
свойств.
Требования неатомарны (см. «атомарность») и непрослежи-

а
ваемы (см. «прослеживаемость»), а потому их изменение с высо-
кой вероятностью порождает противоречивость (см. «непротиво-
ек
речивость»).
 Требования изначально противоречивы (см. «непротиворечи-
т
вость»). В такой ситуации внесение изменений (не связанных с

устранением противоречивости) только усугубляет ситуацию, уве-
ио
личивая противоречивость и снижая прослеживаемость.

бл
46
Horizontal traceability. The tracing of requirements for a test level through the layers of
test documentation (e.g. test plan, test design specification, test case specification and test proce-
dure specification or test script). ISTQB Glossary.
Би
47
Requirements management tool. A tool that supports the recording of requirements,
requirements attributes (e.g. priority, knowledge responsible) and annotation, and facilitates trace-
ability through layers of requirements and requirements change management. Some requirements
management tools also provide facilities for static analysis, such as consistency checking and vio-
lations to predefined requirements rules. ISTQB Glossary.
48
Traceability matrix. A two-dimensional table, which correlates two entities (e.g., re-
quirements and test cases). The table allows tracing back and forth the links of one entity to the
other, thus enabling the determination of coverage achieved and the assessment of impact of pro-
posed changes. ISTQB Glossary.
49
To facilitate modifiability, avoid stating requirements redundantly. Repeating a require-
ment in multiple places where it logically belongs makes the document easier to read but harder to
maintain. The multiple instances of the requirement all have to be modified at the same time to
avoid generating inconsistencies. Cross-reference related items in the SRS to help keep them syn-
chronized when making changes. Wiegers K., Beatty J. Software Requirements. – 3rd ed.
22
 Требования представлены в неудобной для обработки форме
(например, не использованы инструменты управления требовани-
ями, и в итоге команде приходится работать с десятками огромных
текстовых документов).
Проранжированность по важности, стабильности, срочности
(ranked50 for importance, stability, priority). Важность характеризует зави-
симость успеха проекта от успеха реализации требования. Стабиль-
ность характеризует вероятность того, что в обозримом будущем в тре-
бование не будет внесено никаких изменений. Срочность определяет
распределение во времени усилий проектной команды по реализации
того или иного требования.
Р
Типичные проблемы с проранжированностью состоят в её отсут-
ствии или неверной реализации и приводят к следующим последствиям.
УИ
 Проблемы с проранжированностью по важности повышают
риск неверного распределения усилий проектной команды,
направления усилий на второстепенные задачи и конечного прова-
ла проекта из-за неспособности продукта выполнять ключевые за-
дачи с соблюдением ключевых условий.

БГ
Проблемы с проранжированностью по стабильности повы-
шают риск выполнения бессмысленной работы по совершенство-
ванию, реализации и тестированию требований, которые в самое
а
ближайшее время могут претерпеть кардинальные изменения
(вплоть до полной утраты актуальности).
ек
 Проблемы с проранжированностью по срочности повышают

риск нарушения желаемой заказчиком последовательности реали-
т
зации функциональности и ввода этой функциональности в экс-

плуатацию.
ио
Корректность (correctness51) и проверяемость (verifiability52). Фак-

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

проверяемость подразумевает возможность создания объективного
тест-кейса (тест-кейсов), однозначно показывающего, что требование
Би
реализовано верно и поведение приложения в точности соответствует

требованию.
50
Prioritize business requirements according to which are most important to achieving the
desired value. Assign an implementation priority to each functional requirement, user requirement,
use case flow, or feature to indicate how essential it is to a particular product release. Wiegers K.,
Beatty J. Software Requirements. – 3rd ed.
51
Each requirement must accurately describe a capability that will meet some stakeholder’s
need and must clearly describe the functionality to be built. Wiegers K., Beatty J. Software Re-
quirements. – 3rd ed.
52
If a requirement isn’t verifiable, deciding whether it was correctly implemented becomes a
matter of opinion, not objective analysis. Requirements that are incomplete, inconsistent, infeasi-
ble, or ambiguous are also unverifiable. Wiegers K., Beatty J. Software Requirements. – 3rd ed.
23
К типичным проблемам с корректностью также можно отнести:
 Опечатки (особенно опасны опечатки в аббревиатурах, пре-
вращающие одну осмысленную аббревиатуру в другую также
осмысленную, но не имеющую отношения к некоему контексту; та-
кие опечатки крайне сложно заметить).
 Наличие неаргументированных требований к дизайну и архи-
тектуре.
 Плохое оформление текста и сопутствующей графической
информации, грамматические, пунктуационные и иные ошибки в
тексте.
 Неверный уровень детализации (например, слишком глубо-
Р
кая детализация требования на уровне бизнес-требований или не-
достаточная детализация на уровне требований к продукту).
УИ
 Требования к пользователю, а не к приложению (например:
«пользователь должен быть в состоянии отправить сообщение» –
увы, мы не можем влиять на состояние пользователя).
1.6 Техники тестирования требований

БГ
Тестирование документации и требований относится к разряду не-
а
функционального тестирования (non-functional testing53). Основные тех-
ники такого тестирования в контексте требований таковы.
ек
Взаимный просмотр (peer review54). Взаимный просмотр («рецен-

зирование») является одной из наиболее активно используемых техник
т
тестирования требований и может быть представлен в одной из трёх

следующих форм (по мере нарастания его сложности и цены):
ио
 Беглый просмотр (walkthrough55) может выражаться как в

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

коллега высказал свои вопросы и замечания. Это самый быстрый и
наиболее широко используемый вид просмотра.
Би
Для запоминания: аналог беглого просмотра – это ситуация,

когда вы в школе с одноклассниками проверяли перед сдачей со-
чинения друг друга, чтобы найти описки и ошибки.
53
Non-functional testing. Testing the attributes of a component or system that do not re-
late to functionality, e.g. reliability, efficiency, usability, maintainability and portability. ISTQB Glos-
sary.
54
Peer review. A review of a software work product by colleagues of the producer of the
product for the purpose of identifying defects and improvements. Examples are inspection, tech-
nical review and walkthrough. ISTQB Glossary.
55
Walkthrough. A step-by-step presentation by the author of a document in order to gather
information and to establish a common understanding of its content. ISTQB Glossary.
24
 Технический просмотр (technical review56) выполняется
группой специалистов. В идеальной ситуации каждый специалист
должен представлять свою область знаний. Просматриваемый
продукт не может считаться достаточно качественным, пока хотя
бы у одного просматривающего остаются замечания.
Для запоминания: аналог технического просмотра – это си-
туация, когда некий договор визирует юридический отдел, бухгал-
терия и т. д.
 Формальная инспекция (inspection57) представляет собой
структурированный, систематизированный и документируемый
подход к анализу документации. Для его выполнения привлекается
Р
большое количество специалистов, само выполнение занимает до-
статочно много времени, и потому этот вариант просмотра исполь-
УИ
зуется достаточно редко (как правило, при получении на сопро-
вождение и доработку проекта, созданием которого ранее занима-
лась другая компания).
Для запоминания: аналог формальной инспекции – это си-
шкафов, холодильника, кладовки и т. д.).

БГ
туация генеральной уборки квартиры (включая содержимое всех
Вопросы. Следующей очевидной техникой тестирования и повы-

шения качества требований является (повторное) использование техник
а
выявления требований, а также (как отдельный вид деятельности) –
задавание вопросов. Если хоть что-то в требованиях вызывает у вас не-
ек
понимание или подозрение – задавайте вопросы. Можно спросить

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

ио
полученная от заказчика. Главное, чтобы ваш вопрос был сформулиро-

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

бок, рассмотрим подробнее. В таблице 1.a приведено несколько плохо
сформулированных требований, а также примеров плохих и хороших
Би
вопросов. Плохие вопросы провоцируют на бездумные ответы, не со-

держащие полезной информации.
56
Technical review. A peer group discussion activity that focuses on achieving consensus
on the technical approach to be taken. ISTQB Glossary.
57
Inspection. A type of peer review that relies on visual examination of documents to de-
tect defects, e.g. violations of development standards and non-conformance to higher level docu-
mentation. The most formal review technique and therefore always based on a documented pro-
cedure. ISTQB Glossary.
25
Таблица 1.a – Пример плохих и хороших вопросов к требованиям
Плохое Плохие вопросы Хорошие вопросы
требование
«Приложение «Насколько быстро?» «Каково максимально
должно быстро (На это вы рискуете по- допустимое время за-
запускаться» лучить ответы в стиле пуска приложения, на
«очень быстро», «мак- каком оборудовании и
симально быстро», при какой загруженно-
«нууу… просто быст- сти этого оборудования
ро».) операционной систе-
«А если не получится мой и другими прило-
Р
быстро?» (Этим вы жениями? На достиже-
рискуете просто уди- ние каких целей влияет
УИ
вить или даже разо- скорость запуска при-
злить заказчика.) ложения? Допускается
«Всегда?» («Да, все- ли фоновая загрузка
гда». Хм, а вы ожидали отдельных компонентов
другого ответа?)
БГ приложения? Что явля-
ется критерием того,
что приложение закон-
чило запуск?»
а
«Опционально «Любых документов?» «Насколько возмож-
должен поддер- (Ответы «да, любых» ность экспорта в PDF
ек
живаться экспорт или «нет, только откры- важна? Как часто, кем и
документов в тых» вам всё равно не с какой целью она бу-
формат PDF» помогут.) дет использоваться?
т
«В PDF какой версии Является ли PDF един-

ио
должен производиться ственным допустимым

экспорт?» (Сам по себе форматом для этих це-
вопрос хорош, но он не лей или есть альтерна-
бл
даёт понять, что име- тивы? Допускается ли

лось в виду под «опци- использование внеш-
онально».) них утилит (например,
Би
«Зачем?» («Нужно!» виртуальных PDF-

Именно так хочется от- принтеров) для экспор-
ветить, если вопрос не та документов в PDF?»
раскрыт полностью.)
26
Продолжение таблицы 1.a
Плохое Плохие вопросы Хорошие вопросы
требование
«Если дата собы- «А если указана?» (То «Возможно, имелось в
тия не указана, она указана. Логично, виду, что дата генери-
она выбирается не так ли?) руется автоматически,
автоматически» «А если дату невоз- а не выбирается? Ес-
можно выбрать автома- ли да, то по какому ал-
тически?» (Сам вопрос горитму она генериру-
интересен, но без по- ется? Если нет, то из
яснения причин невоз- какого набора выбира-
Р
можности звучит как ется дата и как генери-
насмешка.) руется этот набор? P.S.
УИ
«А если у события нет Возможно, стоит ис-
даты?» (Тут автор во- пользовать текущую
проса, скорее всего, хо- дату?»
тел уточнить, обяза-
БГ
тельно ли это поле для
заполнения. Но из са-
мого требования видно,
что обязательно: если
а
оно не заполнено чело-
веком, его должен за-
ек
полнить компьютер.)
Тест-кейсы и чек-листы. Мы помним, что хорошее требование

т
является проверяемым, а значит, должны существовать объективные

ио
способы определения того, верно ли реализовано требование. Проду-

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

листа, это ещё не признак того, что с требованием всё хорошо (напри-
мер, оно может противоречить каким-то другим требованиям). Но если
Би
никаких идей по тестированию требования в голову не приходит – это

тревожный знак.
Рекомендуется для начала убедиться, что вы понимаете требова-
ние (в том числе прочесть соседние требования, задать вопросы колле-
гам и т. д.) Также можно пока отложить работу с данным конкретным
требованием и вернуться к нему позднее – возможно, анализ других
требований позволит вам лучше понять и это «конкретное». Но если ни-
что не помогает – скорее всего, с требованием что-то не так.
Справедливости ради надо отметить, что на начальном этапе про-
работки требований такие случаи встречаются очень часто – требова-
27
ния сформированы очень поверхностно, расплывчато и явно нуждаются
в доработке, т. е. здесь нет необходимости проводить сложный анализ,
чтобы констатировать непроверяемость требования.
На стадии же, когда требования уже хорошо сформулированы и
протестированы, вы можете продолжать использовать эту технику, сов-
мещая разработку тест-кейсов и дополнительное тестирование требо-
ваний.
Исследование поведения системы. Эта техника логически выте-
кает из предыдущей (продумывания тест-кейсов и чек-листов), но отли-
чается тем, что здесь тестированию подвергается, как правило, не одно
требование, а целый набор. Тестировщик мысленно моделирует про-
Р
цесс работы пользователя с системой, созданной по тестируемым тре-
бованиям, и ищет неоднозначные или вовсе неописанные варианты по-
УИ
ведения системы. Этот подход сложен, требует достаточной квалифика-
ции тестировщика, но способен выявить нетривиальные недоработки,
которые почти невозможно заметить, тестируя требования по отдельно-
сти.
БГ
Рисунки (графическое представление). Чтобы увидеть общую кар-
тину требований целиком, очень удобно использовать рисунки, схемы,
диаграммы, интеллект-карты58 и т. д. Графическое представление удоб-
но одновременно своей наглядностью и краткостью (например, UML-
а
схема базы данных, занимающая один экран, может быть описана не-
сколькими десятками страниц текста). На рисунке очень легко заметить,
ек
что какие-то элементы «не стыкуются», что где-то чего-то не хватает

и т. д. Если вы для графического представления требований будете ис-
пользовать общепринятую нотацию (например, уже упомянутый UML),
т
вы получите дополнительные преимущества: вашу схему смогут без

ио
труда понимать и дорабатывать коллеги, а в итоге может получиться хо-

рошее дополнение к текстовой форме представления требований.
Прототипирование. Можно сказать, что прототипирование часто
бл
является следствием создания графического представления и анализа

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

«прототип ради прототипа», а заготовку для дальнейшей разработки,
если окажется, что реализованное в прототипе (возможно, с небольши-
ми доработками) устраивает заказчика.
58
Mind map. URL: http://en.wikipedia.org/wiki/Mind_map.
28
1.7 Контрольные вопросы и задания
 Сформулируйте определение требования.

 Кто является основным источником и потребителем требова-
ний?
 Какова связь требований и архитектуры проекта?
 Опишите уровни требований – в чём они выражаются и что
описывают?
 Какие типы требований вы знаете?
 Перечислите свойства хорошего требования.
 Приведите примеры плохих и хороших вопросов к требованиям.
Р
 Какими свойствами должны обладать наборы требований?

УИ
Какие проблемы чаще всего возникают при работе с требова-
ниями? В чём их суть?
 Назовите основные пути выявления требований.
 Перечислите характеристики хороших наборов требований.



БГ
Назовите основные проблемы с наборами требований.
Каковы преимущества и недостатки анкетирования как спосо-
ба определения требований?
Каковы преимущества и недостатки наблюдения как способа
а
определения требований?
 Каковы преимущества и недостатки самостоятельного опре-
ек
деления требований на основе документов?

 Каковы преимущества и недостатки семинаров как способа
определения требований?
т
 Каковы преимущества и недостатки прототипирования как

ио
способа определения требований?

 Перечислите основные источники требований.
 Сделайте сравнительный анализ основных техник выявления
бл
требований.
 Какие требования относятся к группе нефункциональных тре-
бований?
Би
 Какие требования относятся к группе функциональных требо-

ваний?
 Назовите основную цель функционального тестирования.
 Назовите основные техники тестирования требований.
 Чем отличается проектная документация от продуктной?
 Перечислите основные виды тестирования. Сформулируйте
их определения.
 Перечислите основные уровни тестирования. Дайте им опре-
деления.
 Какие виды документации можно тестировать? Перечислите.
29
2 ЧЕК-ЛИСТЫ, ТЕСТ-КЕЙСЫ, НАБОРЫ ТЕСТ-КЕЙСОВ
2.1 Чек-листы
Тестировщику приходится работать с огромным количеством ин-

формации, выбирать из множества вариантов решения задач и изобре-
тать новые. В процессе этой деятельности объективно невозможно
удержать в голове все мысли, а потому продумывание и разработку
тест-кейсов рекомендуется выполнять с использованием так называе-
мых «чек-листов».
Р
Чек-лист (checklist59) – набор идей [тест-кейсов]. Последнее
УИ
слово не зря взято в скобки, т. к. в общем случае чек-лист – это
просто набор идей: идей по тестированию, идей по разработке,
идей по планированию и управлению – любых идей.
БГ
Чек-лист чаще всего представляет собой обычный и привычный
нам список, который может быть:
 Списком, в котором последовательность пунктов не имеет
значения (например, список значений некоего поля).
а
 Списком, в котором последовательность пунктов важна
(например, шаги в краткой инструкции).
ек
 Структурированным (многоуровневым) списком (вне зависи-

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

ио
чений при разработке чек-листов – главное, чтобы они помогали в ра-

боте. Иногда чек-листы могут даже выражаться графически (например, с
использованием ментальных карт60 или концепт-карт61), хотя традицион-
бл
но их составляют в виде многоуровневых списков.

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

должен обладать рядом важных свойств.
Логичность. Чек-лист пишется не «просто так», а на основе целей
59
Понятие «чек-листа» не завязано на тестирование как таковое – это совершенно
универсальная техника, которая может применяться в любой без исключения области жиз-
ни. В русском языке вне контекста информационных технологий чаще используется понят-
ное и привычное слово «список» (например, «список покупок», «список дел» и т. д.), но в те-
стировании прижилась калькированная с английского версия – «чек-лист».
60
Mind map. URL: http://en.wikipedia.org/wiki/Mind_map.
61
Concept map. URL: http://en.wikipedia.org/wiki/Concept_map.
30
и для того, чтобы помочь в достижении этих целей. К сожалению, одной из
самых частых и опасных ошибок при составлении чек-листа является пре-
вращение его в свалку мыслей, которые никак не связаны друг с другом.
Последовательность и структурированность. Со структуриро-
ванностью всё достаточно просто – она достигается за счёт оформле-
ния чек-листа в виде многоуровневого списка. Что до последовательно-
сти, то даже в том случае, когда пункты чек-листа не описывают цепочку
действий, человеку всё равно удобнее воспринимать информацию в ви-
де неких небольших групп идей, переход между которыми является по-
нятным и очевидным (например, сначала можно прописать идеи про-
стых позитивных тест-кейсов SPECIAL_TERMINS_Positive_Testing, потом
Р
идеи простых негативных тест-кейсов, потом постепенно повышать
сложность тест-кейсов, но не стоит писать эти идеи вперемешку).
УИ
Полнота и неизбыточность. Чек-лист должен представлять собой
аккуратную «сухую выжимку» идей, в которых нет дублирования (часто
появляется из-за разных формулировок одной и той же идеи), и в то же
время ничто важное не упущено.
БГ
Правильно создавать и оформлять чек-листы также помогает вос-
приятие их не только как хранилища наборов идей, но как «требования
для составления тест-кейсов». Эта мысль приводит к пересмотру и пе-
реосмыслению свойств качественных требований (см. подраздел 1.5) в
а
применении к чек-листам.
ек
Задание 2.a: перечитайте подраздел 1.5 и подумайте, какие

свойства качественных требований можно также считать и
свойствами качественных чек-листов?
т
ио
Итак, рассмотрим процесс создания чек-листа.

Поскольку мы не можем сразу «протестировать всё приложение»
(это слишком большая задача, чтобы решить её одним махом), нам уже
бл
сейчас нужно выбрать некую логику построения чек-листов – да, их бу-

дет несколько (в итоге их можно будет структурированно объединить в
один, но это не обязательно).
Би
Типичными вариантами такой логики является создание отдельных

чек-листов для:
 различных уровней функционального тестирования;
 отдельных частей (модулей и подмодулей) приложения (см.
«Модуль и подмодуль приложения» в подразделе 2.3);
 отдельных требований, групп требований, уровней и типов
требований (см. подраздел 1.4);
 типичных пользовательских сценариев (см. «Пользователь-
ские сценарии (сценарии использования)» в подразделе 2.5);
31
 частей или функций приложения, наиболее подверженных
рискам.
Этот список можно расширять и дополнять, можно комбинировать
его пункты, получая, например, чек-листы для проверки наиболее ти-
пичных сценариев, затрагивающих некую часть приложения.
Чтобы проиллюстрировать принципы построения чек-листов, мы
воспользуемся логикой разбиения функций приложения по степени их
важности (классификацию по убыванию степени важности функций при-
ложения) на три категории:
 Базовые функции, без которых существование приложения
теряет смысл (т. е. самые важные – то, ради чего приложение во-
Р
обще создавалось), или нарушение работы которых создаёт объ-
ективные серьёзные проблемы для среды исполнения.
УИ
 Функции, востребованные большинством пользователей в их
повседневной работе.
 Остальные функции (разнообразные «мелочи», проблемы с
которыми не сильно повлияют на ценность приложения для конеч-
ного пользователя).
БГ
Рассмотрим функции, без которых существование приложения те-
ряет смысл. Сначала приведём целиком весь чек-лист для дымового те-
стирования, а потом рассмотрим его подробнее:
а
 Конфигурирование и запуск.

ек
Обработка файлов (таблица 2.a).
Таблица 2.a – Обработка файлов

т
Кодировки Форматы входных файлов

входных
ио
TXT HTML MD
файлов
WIN1251 + + +
CP866 + + +
бл
KOI8R + + +
 Остановка.
Би
Здесь перечислены все ключевые функции приложения.

Конфигурирование и запуск. Если приложение невозможно
настроить для работы в пользовательской среде, оно бесполезно. Если
приложение не запускается, оно бесполезно. Если на стадии запуска
возникают проблемы, они могут негативно отразиться на функциониро-
вании приложения и потому также заслуживают пристального внимания.
Примечание – В нашем примере мы столкнулись со скорее нети-
пичным случаем – приложение конфигурируется параметрами команд-
ной строки, а потому разделить операции «конфигурирования» и «запус-
ка» не представляется возможным; в реальной жизни для подавляюще-
32
го большинства приложений эти операции выполняются раздельно.
Обработка файлов. Приложение разрабатывалось для обработки
файлов, потому здесь, даже на стадии создания чек-листа, мы не поле-
нились создать матрицу, отражающую все возможные комбинации допу-
стимых форматов и допустимых кодировок входных файлов, чтобы ни-
чего не забыть и подчеркнуть важность соответствующих проверок.
Остановка. С точки зрения пользователя эта функция может не
казаться столь уж важной, но остановка (и запуск) любого приложения
связана с большим количеством системных операций, проблемы с кото-
рыми могут привести к множеству серьёзных последствий (вплоть до
невозможности повторного запуска приложения или нарушения работы
Р
операционной системы).
Рассмотрим функции, востребованные большинством пользовате-
УИ
лей. Следующим шагом мы будем выполнять проверку того, как прило-
жение ведёт себя в обычной повседневной жизни, пока не затрагивая
«экзотические» ситуации. Очень частым вопросом является допусти-
мость дублирования проверок на разных уровнях функционального те-
БГ
стирования – можно ли так делать? Одновременно и «нет», и «да».
«Нет» – в том смысле, что не допускается (не имеет смысла) повторе-
ние тех же проверок, которые только что были выполнены. «Да» – в том
смысле, что любую проверку можно детализировать и снабдить допол-
а
нительными деталями:
 Конфигурирование и запуск:
ек
o С верными параметрами:
 Значения SOURCE_DIR, DESTINATION_DIR,
LOG_FILE_NAME указаны и содержат пробелы и кирил-
т
лические символы (повторить для форматов путей в

ио
Windows- и *nix-файловых системах, обратить внимание

на имена логических дисков и разделители имён катало-
гов (“/” и “\”)).
бл
 Значение LOG_FILE_NAME не указано.

o Без параметров.
o С недостаточным количеством параметров.
Би
o С неверными параметрами:
 Недопустимый путь SOURCE_DIR.
 Недопустимый путь DESTINATION_DIR.
 Недопустимое имя LOG_FILE_NAME.
 DESTINATION_DIR находится внутри
SOURCE_DIR.
 Значения DESTINATION_DIR и SOURCE_DIR сов-
падают.
 Обработка файлов:
o Разные форматы, кодировки и размеры (таблица 2.b).
33
Таблица 2.b – Разные форматы и кодировки входных файлов
Кодировки входных Форматы входных файлов
файлов TXT HTML MD
WIN1251 100 КБ 50 МБ 10 МБ
CP866 10 МБ 100 КБ 50 МБ
KOI8R 50 МБ 10 МБ 100 КБ
Любая 0Б
Любая 50 МБ + 1 Б 50 МБ + 1 Б 50 МБ + 1 Б
– Любой недопустимый формат
Любая Повреждения в допустимом формате
Р
o Недоступные входные файлы:
УИ
 Нет прав доступа.
 Файл открыт и заблокирован.
 Файл с атрибутом «только для чтения».
 Остановка:

o
Журнал работы приложения:
o
o
БГ
Закрытием окна консоли.
Автоматическое создание (при отсутствии журнала).

Продолжение (дополнение журнала) при повторных за-
а
пусках.
ек
 Производительность:
o Элементарный тест с грубой оценкой.
Обратите внимание, что чек-лист может содержать не только
т
«предельно сжатые тезисы», но и вполне развёрнутые комментарии, ес-

ио
ли это необходимо – лучше пояснить суть идеи подробнее, чем потом

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

тами и размерами) звучит расплывчато, но этот недочёт будет устранён
уже на уровне полноценных тест-кейсов.
Би
Рассмотрим остальные функции и особые сценарии. Пришло вре-

мя обратить внимание на разнообразные мелочи и «хитрые» нюансы,
проблемы с которыми едва ли сильно озаботят пользователя, но фор-
мально всё же будут считать ошибками:
 Конфигурирование и запуск:
o Значения SOURCE_DIR, DESTINATION_DIR,
LOG_FILE_NAME:
 В разных стилях (Windows-пути + *nix-пути) – од-
но в одном стиле, другое – в другом.
 С использованием UNC-имён.
34
 LOG_FILE_NAME внутри SOURCE_DIR.
 LOG_FILE_NAME внутри DESTINATION_DIR.
o Размер LOG_FILE_NAME на момент запуска:
 2-4 ГБ.
 4+ ГБ.
o Запуск двух и более копий приложения с:
 Одинаковыми параметрами SOURCE_DIR, DESTI-
NATION_DIR, LOG_FILE_NAME.
 Одинаковыми SOURCE_DIR и LOG_FILE_NAME,
но разными DESTINATION_DIR.
 Одинаковыми DESTINATION_DIR и
Р
LOG_FILE_NAME, но разными SOURCE_DIR.
 Обработка файлов:
УИ
o Файл верного формата, в котором текст представлен в
двух и более поддерживаемых кодировках одновременно.
o Размер входного файла:
 2-4 ГБ.
 4+ ГБ.
БГ
Задание 2.b: возможно, вам захотелось что-то изменить в при-
ведённых выше чек-листах – это совершенно нормально и
а
справедливо: нет и не может быть некоего «единственно верно-
го идеального чек-листа» и ваши идеи вполне имеют право на
ек
существование, потому составьте свой собственный чек-лист

или отметьте недостатки, которые вы заметили в приведённом
выше чек-листе.
т
ио
Как мы увидим в подразделе 2.2, создание качественного тест-

кейса может потребовать длительной кропотливой и достаточно моно-
тонной работы, которая при этом не требует от опытного тестировщика
бл
немалых интеллектуальных усилий, а потому переключение между ра-

ботой над чек-листами (творческая составляющая) и расписыванием их
в тест-кейсы (механическая составляющая) позволяет разнообразить
Би
рабочий процесс и снизить утомляемость. Хотя, конечно, написание

сложных и притом качественных тест-кейсов может оказаться ничуть не
менее творческой работой, чем продумывание чек-листов.
2.2 Тест-кейсы
Терминология и общие сведения

Для начала определимся с терминологией, поскольку здесь есть
много путаницы, вызванной разными переводами англоязычных терми-
нов на русский язык и разными традициями в тех или иных странах,
фирмах и отдельных командах.
35
Во главе всего лежит термин «тест». Официальное определение
звучит так.
Тест (test62) – набор из одного или нескольких тест-кейсов.
Поскольку среди всех прочих терминов этот легче и быстрее всего

произносить, в зависимости от контекста под ним могут понимать и от-
дельный пункт чек-листа, и отдельный шаг в тест-кейсе, и сам тест-кейс,
и набор тест-кейсов и т. д. Главное здесь одно: если вы слышите или
видите слово «тест», воспринимайте его в контексте.
Р
Теперь рассмотрим самый главный для нас термин – «тест-кейс».
УИ
Тест-кейс (test case63) – набор входных данных, условий вы-
полнения и ожидаемых результатов, разработанный с целью
проверки того или иного свойства или поведения программного
средства.
БГ
Под тест-кейсом также может пониматься соответствующий до-
кумент, представляющий формальную запись тест-кейса.
а
Критически важно понять и запомнить: если у тест-кейса не указа-
ны входные данные, условия выполнения и ожидаемые результаты
ек
и/или не ясна цель тест-кейса – это плохой тест-кейс (иногда он не

имеет смысла, иногда его и вовсе невозможно выполнить).
Примечание – Иногда термин «test case» на русский язык перево-
т
дят как «тестовый случай». Это вполне адекватный перевод, но из-за то-
ио
го, что «тест-кейс» удобнее произносить, наибольшее распространение

получил именно этот вариант.
бл
Остальные термины, связанные с тестами, тест-кейсами и те-

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

ми: на начальном этапе изучения тестирования нет необходи-
мости глубоко рассматривать их все, однако некоторые всё же
заслуживают внимания. Они представлены ниже.
62
Test. A set of one or more test cases. ISTQB Glossary.
63
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 particu-
lar program path or to verify compliance with a specific requirement. ISTQB Glossary.
36
Высокоуровневый тест-кейс (high level test case64) – тест-кейс
без конкретных входных данных и ожидаемых результатов.
Как правило, ограничивается общими идеями и операциями, схож
по своей сути с подробно описанным пунктом чек-листа. Достаточно ча-
сто встречается в интеграционном тестировании и системном тестиро-
вании, а также на уровне дымового тестирования. Может служить от-
правной точкой для проведения исследовательского тестирования или
для создания низкоуровневых тест-кейсов.
Низкоуровневый тест-кейс (low level test case65) – тест-кейс с
конкретными входными данными и ожидаемыми результатами.
Представляет собой «полностью готовый к выполнению» тест-кейс
Р
и вообще является наиболее классическим видом тест-кейсов. Начина-
ющих тестировщиков чаще всего учат писать именно такие тесты, т. к.
УИ
прописать все данные подробно – намного проще, чем понять, какой
информацией можно пренебречь, при этом не снизив ценность тест-
кейса.
Спецификация тест-кейса (test case specification66) – документ,
БГ
описывающий набор тест-кейсов (включая их цели, входные данные,
условия и шаги выполнения, ожидаемые результаты) для тестируемого
элемента (test item67, test object68).
Спецификация теста (test specification69) – документ, состоящий
а
из спецификации тест-дизайна (test design specification70), спецификации
тест-кейса (test case specification66) и/или спецификации тест-процедуры
ек
(test procedure specification71).

Тест-сценарий (test scenario72, test procedure specification, test
script) – документ, описывающий последовательность действий по вы-
т
полнению теста (также известен как «тест-скрипт»).

ио
64
High level test case (logical test case). A test case without concrete (implementation
level) values for input data and expected results. Logical operators are used; instances of the ac-
бл
tual values are not yet defined and/or available. ISTQB Glossary.
65
Low level test case. A test case with concrete (implementation level) values for input da-
ta and expected results. Logical operators from high level test cases are replaced by actual values
that correspond to the objectives of the logical operators. ISTQB Glossary.
Би
66
Test case specification. A document specifying a set of test cases (objective, inputs,
test actions, expected results, and execution preconditions) for a test item. ISTQB Glossary.
67
Test item. The individual element to be tested. There usually is one test object and many
test items. ISTQB Glossary.
68
Test object. The component or system to be tested. ISTQB Glossary.
69
Test specification. A document that consists of a test design specification, test case
specification and/or test procedure specification. ISTQB Glossary.
70
Test design specification. A document specifying the test conditions (coverage items)
for a test item, the detailed test approach and identifying the associated high level test cases.
ISTQB Glossary.
71
Test procedure specification (test procedure). A document specifying a sequence of
actions for the execution of a test. Also known as test script or manual test script. ISTQB Glossary.
72
Test scenario. A document specifying a sequence of actions for the execution of a test.
Also known as test script or manual test script. ISTQB Glossary.
37
Внимание! Из-за особенностей перевода очень часто под тер-
мином «тест-сценарий» («тестовый сценарий») имеют в виду
набор тест-кейсов.
Цель написания тест-кейсов

Тестирование можно проводить и без тест-кейсов (не нужно, но
можно; да, эффективность такого подхода варьируется в очень широком
диапазоне в зависимости от множества факторов). Наличие же тест-
кейсов позволяет:
 Структурировать и систематизировать подход к тестированию
(без чего крупный проект почти гарантированно обречён на про-
Р
вал).
 Вычислять метрики тестового покрытия (test coverage73 met-
УИ
rics) и принимать меры по его увеличению (тест-кейсы здесь явля-
ются главным источником информации, без которого существова-
ние подобных метрик теряет смысл).
 Отслеживать соответствие текущей ситуации плану (сколько

БГ
примерно понадобится тест-кейсов, сколько уже есть, сколько вы-
полнено из запланированного на данном этапе количества и т. д.).
Уточнить взаимопонимание между заказчиком, разработчи-
ками и тестировщиками (тест-кейсы зачастую намного более
а
наглядно показывают поведение приложения, чем это отражено в
требованиях).
ек
 Хранить информацию для длительного использования и об-

мена опытом между сотрудниками и командами (или как минимум –
т
не пытаться удержать в голове сотни страниц текста).

 Проводить регрессионное тестирование и повторное тести-
ио
рование (которые без тест-кейсов было бы вообще невозможно

выполнить).
 Повышать качество требований (мы это уже рассматривали
бл
(«Тест-кейсы и чек-листы» в подразделе 1.6): написание чек-

листов и тест-кейсов – хорошая техника тестирования
требований).
Би
 Быстро вводить в курс дела нового сотрудника, недавно под-

ключившегося к проекту.
2.3 Атрибуты (поля) тест-кейса

Как уже было сказано выше, термин «тест-кейс» может относиться
к формальной записи тест-кейса в виде технического документа. Эта за-
73
Coverage (test coverage). The degree, expressed as a percentage, to which a specified
coverage item (an entity or property used as a basis for test coverage, e.g. equivalence partitions
or code statements) has been exercised by a test suite. ISTQB Glossary.
38
пись имеет общепринятую структуру, компоненты которой называются
атрибутами (полями) тест-кейса.
В зависимости от инструмента управления тест-кейсом внешний
вид их записи может немного отличаться, могут быть добавлены или
убраны отдельные поля, но концепция остаётся неизменной.
Общий вид всей структуры тест-кейса представлен на рисунке 2.a.
Связанное с тест-кейсом требование

Ожидаемый результат по
Иденти- Приоритет каждому шагу тест-кейса
фикатор
Заглавие (суть) тест-кейса
Р
UG_U1.12 A R97 Галерея Загрузка Галерея, за- 1. Появляет-
УИ
файла грузка файла, ся окно за-
имя со спец- грузки кар-
символами тинки.
Модуль и подмо- Приготовления: 2. Появляет-
дуль приложения
Исходные данные, не-

обходимые для выпол-
нения тест-кейса
БГ
создать непу-
стой файл с
именем
#$%^&.jpg.
ся диалого-
вое окно
браузера
выбора
а
1. Нажать кнопку файла для
«Загрузить кар- загрузки.
ек
тинку». 3. Имя вы-

2. Нажать кнопку бранного
Шаги тест-кейса
«Выбрать». файла появ-
т
3. Выбрать из ляется в по-

ио
списка приго- ле «Файл».

товленный 4. Диалого-
файл. вое окно
бл
4. Нажать кнопку файла за-

«OK». крывается, в
5. Нажать кнопку поле «Файл»
Би
«Добавить в га- появляется

лерею» полное имя
файла.
5. Выбран-
ный файл
появляется
в списке
файлов га-
лереи
Рисунок 2.a – Общий вид тест-кейса
39
Теперь рассмотрим каждый атрибут подробно.
Идентификатор (identifier) представляет собой уникальное значе-
ние, позволяющее однозначно отличить один тест-кейс от другого и ис-
пользуемое во всевозможных ссылках. В общем случае идентификатор
тест-кейса может представлять собой просто уникальный номер, но (ес-
ли позволяет инструментальное средство управления тест-кейсами) мо-
жет быть и куда сложнее: включать префиксы, суффиксы и иные осмыс-
ленные компоненты, позволяющие быстро определить цель тест-кейса и
часть приложения (или требований), к которой он относится.
Приоритет (priority) показывает важность тест-кейса. Он может
быть выражен буквами (A, B, C, D, E), цифрами (1, 2, 3, 4, 5), словами
Р
(«крайне высокий», «высокий», «средний», «низкий», «крайне низкий»)
или иным удобным способом. Количество градаций также не фиксиро-
УИ
вано, но чаще всего лежит в диапазоне от трёх до пяти.
Приоритет тест-кейса может коррелировать с:
 Важностью требования, пользовательского сценария (см.
«Пользовательские сценарии (сценарии использования)» в под-

БГ
разделе 2.5) или функции, с которыми связан тест-кейс.
 Потенциальной важностью дефекта (см. «Важность (severity)»
в подразделе 2.5), на поиск которого направлен тест-кейс.
Степенью риска, связанного с проверяемым тест-кейсом тре-
а
бованием, сценарием или функцией.
Основная задача этого атрибута – упрощение распределения
ек
внимания и усилий команды (более высокоприоритетные тест-кейсы по-

лучают их больше), а также упрощение планирования и принятия реше-
т
ния о том, чем можно пожертвовать в некоей форс-мажорной ситуации,

не позволяющей выполнить все запланированные тест-кейсы.
ио
Связанное с тест-кейсом требование (requirement) показывает то

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

тест-кейса, как прослеживаемость (см. «Прослеживаемость» в подраз-
деле 2.5).
Би
Частые вопросы, связанные с заполнением этого поля, таковы:

 Можно ли его оставить пустым? Да. Тест-кейс вполне мог
разрабатываться вне прямой привязки к требованиям, и (пока) зна-
чение этого поля определить сложно. Хоть такой вариант и не счи-
тается хорошим, он достаточно распространён.
 Можно ли в этом поле указывать несколько требований? Да,
но чаще всего стараются выбрать одно самое главное или «более
высокоуровневое» (например, вместо того, чтобы перечислять
R56.1, R56.2, R56.3 и т. д., можно просто написать R56). Чаще все-
го в инструментах управления тестами это поле представляет со-
40
бой выпадающий список, где можно выбрать только одно значение,
и этот вопрос становится неактуальным. К тому же многие тест-
кейсы всё же направлены на проверку строго одного требования, и
для них этот вопрос также неактуален.
Модуль и подмодуль приложения (module and submodule) ука-
зывают на части приложения, к которым относится тест-кейс, и позволя-
ют лучше понять его цель.
Идея деления приложения на модули и подмодули проистекает из
того, что в сложных системах практически невозможно охватить взгля-
дом весь проект целиком, и вопрос «как протестировать это приложе-
ние» становится недопустимо сложным. Тогда приложение логически
Р
разделяется на компоненты (модули), а те, в свою очередь, – на более
мелкие компоненты (подмодули). И вот уже для таких небольших частей
УИ
приложения придумать чек-листы и создать хорошие тест-кейсы стано-
вится намного проще.
Как правило, иерархия модулей и подмодулей создаётся как еди-
ный набор для всей проектной команды, чтобы исключить путаницу из-
БГ
за того, что разные люди будут использовать разные подходы к такому
разделению или даже просто разные названия одних и тех же частей
приложения.
Теперь – самое сложное: как выбираются модули и подмодули. В
а
реальности проще всего отталкиваться от архитектуры и дизайна при-
ложения. Например, в уже знакомом нам приложении можно выделить
ек
такую иерархию модулей и подмодулей:

 Механизм запуска:
o механизм анализа параметров;
т
o механизм сборки приложения;

ио
o механизм обработки ошибочных ситуаций.

 Механизм взаимодействия с файловой системой:
o механизм обхода дерева SOURCE_DIR;
бл

 Механизм преобразования файлов:
o механизм определения кодировок;
Би
o механизм преобразования кодировок;

 Механизм ведения журнала:
o механизм записи журнала;
o механизм отображения журнала в консоли;
Согласитесь, что такие длинные названия с постоянно повторяю-
щимся словом «механизм» читать и запоминать сложно. Перепишем:
 Стартер:
o анализатор параметров;
41
o сборщик приложения;
o обработчик ошибок.
 Сканер:
o обходчик;
 Преобразователь:
o детектор;
o конвертер;
 Регистратор:
o дисковый регистратор;
Р
o консольный регистратор;
УИ
Но что делать, если мы не знаем «внутренностей» приложения
(или не очень разбираемся в программировании)? Модули и подмодули
можно выделять на основе графического интерфейса пользователя
(крупные области и элементы внутри них), на основе решаемых прило-
БГ
жением задач и подзадач и т. д. Главное, чтобы эта логика была одина-
ковым образом применена ко всему приложению.
Внимание! Частая ошибка! Модуль и подмодуль приложения –

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

виду именно части приложения, отвечающие за печать и за
т
настройку принтера (и названы они отглагольными существи-

тельными), а не процесс печати или настройки принтера).
ио
Сравните (на примере человека): «дыхательная система, лёг-

кие» – это модуль и подмодуль, а «дыхание», «сопение», «чи-
бл
хание» – нет; «голова, мозг» – это модуль и подмодуль, а

«кивание», «думание» – нет.
Би
Наличие полей «Модуль и подмодуль приложения» улучшает та-

кое свойство тест-кейса, как прослеживаемость (см. «Прослеживае-
мость» в подразделе 2.5).
Заглавие (суть) тест-кейса (title) призвано упростить быстрое по-
нимание основной идеи тест-кейса без обращения к его остальным ат-
рибутам. Именно это поле является наиболее информативным при про-
смотре списка тест-кейсов.
Сравните (таблица 2.c).
42
Таблица 2.c – Сравнение тестов
Плохо Хорошо
Тест 1 Запуск, одна копия, верные параметры
Тест 2 Запуск одной копии с неверными путями
Тест 78 (улучшенный) Запуск, много копий, без конфликтов
Остановка Остановка по Ctrl+C
Закрытие Остановка закрытием консоли
… …
Заглавие тест-кейса может быть полноценным предложением,

фразой, набором словосочетаний – главное, чтобы выполнялись сле-
Р
дующие условия:
 Информативность.
УИ
 Хотя бы относительная уникальность (чтобы не путать раз-
ные тест-кейсы).
Внимание! Частая ошибка! Если инструмент управления тест-
кейсами не требует писать заглавие, его всё равно надо пи-
БГ
сать. Тест-кейсы без заглавий превращаются в запутанную ин-
формацию, использование которой сопряжено с колоссальными
и совершенно бессмысленными затратами.
И ещё одна небольшая мысль, которая может помочь лучше фор-
а
мулировать заглавия. В дословном переводе с английского «test case»
обозначает «тестовый случай (ситуация)». Так вот, заглавие как раз и
ек
описывает этот случай (ситуацию), т. е. что происходит в тест-кейсе, ка-

кую ситуацию он проверяет.
т
Исходные данные, необходимые для выполнения тест-кейса

(precondition, preparation, initial data, setup), позволяют описать всё то,
ио
что должно быть подготовлено до начала выполнения тест-кейса,

например:
 Состояние базы данных.
бл
 Состояние файловой системы и её объектов.

 Состояние серверов и сетевой инфраструктуры.
ОЧЕНЬ ВАЖНО! Всё, что описывается в этом поле, готовится
Би
БЕЗ использования тестируемого приложения, и, таким обра-

зом, если здесь возникают проблемы, нельзя писать отчёт о
дефекте в приложении. Эта мысль очень и очень важна, потому
поясним её простым жизненным примером. Представьте, что вы
дегустируете конфеты. В поле «исходные данные» можно про-
писать «купить конфеты таких-то сортов в таком-то количе-
стве». Если таких конфет нет в продаже, если закрыт магазин,
если не хватило денег и т. д. – всё это НЕ проблемы вкуса
конфет, и нельзя писать отчёт о дефекте конфет вида «конфе-
ты невкусные потому, что закрыт магазин».
43
Шаги тест-кейса (steps) описывают последовательность действий,
которые необходимо реализовать в процессе выполнения тест-кейса.
Общие рекомендации по написанию шагов таковы:
 Начинайте с понятного и очевидного места, не пишите лиш-
них начальных шагов (запуск приложения, очевидные операции с
интерфейсом и т. п.).
 Даже если в тест-кейсе всего один шаг, нумеруйте его (иначе
возрастает вероятность в будущем случайно «приклеить» описа-
ние этого шага к новому тексту).
 Если вы пишете на русском языке, используйте безличную
форму (например, «открыть», «ввести», «добавить» вместо «от-
Р
кройте», «введите», «добавьте»).
 Соотносите степень детализации шагов и их параметров с
УИ
целью тест-кейса, его сложностью, уровнем и т. д. – в зависимо-
сти от этих и многих других факторов степень детализации может
варьироваться от общих идей до предельно чётко прописанных
значений и указаний.

БГ
Ссылайтесь на предыдущие шаги и их диапазоны для сокра-
щения объёма текста (например, «повторить шаги 3–5 со значени-
ем…»).
 Пишите шаги последовательно, без условных конструкций
а
вида «если…, то…».
ек
Внимание! Частая ошибка! Категорически запрещено ссылаться

на шаги из других тест-кейсов и другие тест-кейсы целиком: ес-
т
ли те, другие, тест-кейсы будут изменены или удалены, ваш

тест-кейс начнёт ссылаться на неверные данные или в пустоту,
ио
а если в процессе выполнения те, другие, тест-кейсы или шаги

приведут к возникновению ошибки, вы не сможете закончить
выполнение вашего тест-кейса.
бл
Ожидаемые результаты (expected results) по каждому шагу тест-

кейса описывают реакцию приложения на действия, описанные в поле
Би
«шаги тест-кейса». Номер шага соответствует номеру результата.

По написанию ожидаемых результатов можно порекомендовать
следующее:
 Описывайте поведение системы так, чтобы исключить субъ-
ективное толкование (например, «приложение работает верно» –
плохо, «появляется окно с надписью…» – хорошо).
 Пишите ожидаемый результат по всем шагам без исключе-
ния, если у вас есть хоть малейшие сомнения в том, что результат
некоего шага будет совершенно тривиальным и очевидным (если
вы всё же пропускаете ожидаемый результат для какого-то триви-
44
ального действия, лучше оставить в списке ожидаемых результа-
тов пустую строку – это облегчает восприятие).
 Пишите кратко, но не в ущерб информативности.
 Избегайте условных конструкций вида «если…, то…».
Внимание! Частая ошибка! В ожидаемых результатах ВСЕГДА

описывается КОРРЕКТНАЯ работа приложения. Нет и не может
быть ожидаемого результата в виде «приложение вызывает
ошибку в операционной системе и аварийно завершается с по-
терей всех пользовательских данных».
Р
При этом корректная работа приложения вполне может предпо-
лагать отображение сообщений о неверных действиях пользо-
УИ
вателя или неких критических ситуациях. Так, сообщение «Не-
возможно сохранить файл по указанному пути: на целевом но-
сителе недостаточно свободного места» – это не ошибка при-
ложения, это его совершенно нормальная и правильная работа.
БГ
Ошибкой приложения (в этой же ситуации) было бы отсутствие
такого сообщения, и/или повреждение, или потеря записывае-
мых данных.
а
2.4 Свойства качественных тест-кейсов
ек
Даже правильно оформленный тест-кейс может оказаться некаче-

ственным, если в нём нарушено одно из следующих свойств.
т
Правильный технический язык. Это свойство в равной мере от-

ио
носится и к требованиям, и к тест-кейсам, и к отчётам о дефектах – к

любой документации. Из самого общего и важного напомним и добавим:
 Пишите лаконично, но понятно.
бл
 Используйте безличную форму глаголов (например, «от-

крыть» вместо «откройте»).
 Обязательно указывайте точные имена и технически верные
Би
названия элементов приложения.

 Не объясняйте базовые принципы работы с компьютером
(предполагается, что ваши коллеги знают, что такое, например,
«пункт меню» и как с ним работать).
Баланс между специфичностью и общностью. Тест-кейс счита-
ется тем более специфичным, чем более детально в нём расписаны
конкретные действия, конкретные значения и т. д., т. е. чем в нём боль-
ше конкретики. Соответственно, тест-кейс считается тем более общим,
чем в нём меньше конкретики.
45
Рассмотрим поля «шаги» и «ожидаемые результаты» двух тест-
кейсов (подумайте, какой тест-кейс вы бы посчитали хорошим, а какой –
плохим и почему).
Тест-кейс 1 представлен в таблице 2.d.
Таблица 2.d – Тест-кейс 1

Шаги Ожидаемые результаты
Конвертация из всех поддер- 1. Отображается консольный
живаемых кодировок журнал приложения с сообще-
Приготовления: нием «текущее_время started,
 Создать папки C:/A, C:/B, source dir c:/a, destination dir
Р
C:/C, C:/D. c:/b, log file c:/c/converter.log», в
 Разместить в папке C:/D папке C:/C появляется файл
УИ
файлы 1.html, 2.txt, 3.md из converter.log, в котором появ-
прилагаемого архива. ляется запись «текущее_время
1. Запустить приложение, вы- started, source dir c:/a, destina-
полнив команду «php convert- tion dir c:/b, log file
er.php c:/a
c:/c/converter.log».
2. Скопировать файлы 1.html,
c:/b
2.txt, 3.md из папки C:/D в пап-

БГ
c:/c/converter.log».
2. Файлы 1.html, 2.txt, 3.md по-
являются в папке C:/A, затем
пропадают оттуда и появляют-
а
ку C:/A. ся в папке C:/B. В консольном
3. Остановить приложение журнале и файле
ек
нажатием Crtl+C C:/C/converter.log появляются

сообщения (записи) «теку-
щее_время processing 1.html
т
(KOI8-R)», «текущее_время
ио
processing 2.txt (CP-1251)»,

«текущее_время processing
3.md (CP-866)».
бл
3. В файле C:/C/converter.log
появляется запись «теку-
щее_время closed». Приложе-
Би
ние завершает работу
46
Тест-кейс 2 представлен в таблице 2.e.
Таблица 2.e – Тест-кейс 2

Конвертация из всех поддер- 1. Файлы перемещаются в пап-
живаемых кодировок ку-приёмник, кодировка всех
1. Выполнить конвертацию файлов меняется на UTF-8
трёх файлов допустимого раз-
мера в трёх разных кодировках
всех трёх допустимых форма-
тов
Р
Если вернуться к вопросу «какой тест-кейс вы бы посчитали хоро-
УИ
шим, а какой – плохим и почему», то ответ таков: оба тест-кейса плохие
потому, что первый является слишком специфичным, а второй – слиш-
ком общим. Можно сказать, что здесь до абсурда доведены идеи низко-
уровневых (см. «Низкоуровневый тест-кейс» в подразделе 2.5) и высоко-
БГ
уровневых (см. «Высокоуровневый тест-кейс» в подразделе 2.5) тест-
кейсов.
Почему плоха излишняя специфичность (тест-кейс 1):
 При повторных выполнениях тест-кейса всегда будут выпол-
а
няться строго одни и те же действия со строго одними и теми же
данными, что снижает вероятность обнаружения ошибки.
ек
 Возрастает время написания, доработки и даже просто про-

чтения тест-кейса.
т
 В случае выполнения тривиальных действий опытные специ-

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

описываются только самые сложные и неочевидные ситуации.
Почему плоха излишняя общность (тест-кейс 2):
бл
 Тест-кейс сложен для выполнения начинающими тестиров-

щиками или даже опытными специалистами, лишь недавно под-
ключившимися к проекту.
Би
 Недобросовестные сотрудники склонны халатно относиться к

таким тест-кейсам.
 Тестировщик, выполняющий тест-кейс, может понять его ина-
че, чем было задумано автором (и в итоге будет выполнен факти-
чески совсем другой тест-кейс).
Выход из этой ситуации состоит в том, чтобы придерживаться зо-
лотой середины (хотя, конечно же, какие-то тесты будут чуть более спе-
цифичными, какие-то – чуть более общими). Вот пример такого сре-
динного подхода.
47
Тест-кейс 3 представлен в таблице 2.f.
Таблица 2.f – Тест-кейс 3

Конвертация из всех поддер- 1. Приложение запускается и
живаемых кодировок выводит сообщение о своём
Приготовления: запуске в консоль и файл жур-
 Создать в корне любого нала.
диска четыре отдельные пап- 2. Файлы из папки для вход-
ки для входных файлов, вы- ных файлов перемещаются в
ходных файлов, файла жур- папку для выходных файлов, в
Р
нала и временного хранения консоли и файле журнала
тестовых файлов. отображаются сообщения о
УИ
 Распаковать содержимое конвертации каждого из фай-
прилагаемого архива в папку лов с указанием его исходной
для временного хранения те- кодировки.
стовых файлов. 3. Приложение выводит со-
1. Запустить приложение,
указав в параметрах соответ-
ствующие пути из приготовле-
ния к тесту (имя файла жур-
БГ
общение о завершении работы
в файл журнала и завершает
работу
а
нала – произвольное).
2. Скопировать файлы из
ек
папки для временного хране-

ния в папку для входных фай-
т
лов.
3. Остановить приложение
ио
В этом тест-кейсе есть всё необходимое для понимания и выпол-

нения, но при этом он стал короче и проще для выполнения, а отсут-
бл
ствие строго указанных значений приводит к тому, что при многократном

выполнении тест-кейса (особенно – разными тестировщиками) кон-
кретные параметры будут менять свои значения, что увеличивает веро-
Би
ятность обнаружения ошибки.

Ещё раз главная мысль: сами по себе специфичность или общ-
ность тест-кейса не являются чем-то плохим, но резкий перекос в ту или
иную сторону снижает качество тест-кейса.
Баланс между простотой и сложностью. Здесь не существует
академических определений, но принято считать, что простой тест-кейс
оперирует одним объектом (или в нём явно виден главный объект), а
также содержит небольшое количество тривиальных действий; сложный
тест-кейс оперирует несколькими равноправными объектами и содержит
много нетривиальных действий.
48
Преимущества простых тест-кейсов:
 Их можно быстро прочесть, легко понять и выполнить.
 Они понятны начинающим тестировщикам и новым людям на
проекте.
 Они делают наличие ошибки очевидным (как правило, в них
предполагается выполнение повседневных тривиальных действий,
проблемы с которыми видны невооружённым взглядом и не вызы-
вают дискуссий).
 Они упрощают начальную диагностику ошибки, т. к. сужают
круг поиска.
Преимущества сложных тест-кейсов:
Р
 При взаимодействии многих объектов повышается вероят-
ность возникновения ошибки.
УИ
 Пользователи, как правило, используют сложные сценарии, а
потому сложные тесты более полноценно эмулируют работу поль-
зователей.
 Программисты редко проверяют такие сложные случаи (и они
Рассмотрим примеры. БГ
совершенно не обязаны это делать).
Слишком простой тест-кейс представлен в таблице 2.g.

Таблица 2.g – Простой тест-кейс
а
ек
Запуск приложения 1. Приложение запускается

1. Запустить приложение
т
Слишком сложный тест-кейс представлен в таблице 2.h.

ио
Таблица 2.h – Сложный тест-кейс

Повторная конвертация
Приготовления:
бл
 Создать в корне любого

диска три отдельные папки
для входных файлов, выход-
Би
ных файлов, файла журнала.

 Подготовить набор из не-
скольких файлов максималь-
ного поддерживаемого разме-
ра поддерживаемых форма- 2. Файлы постепенно пере-
тов с поддерживаемыми ко- мещаются из входной в вы-
дировками, а также несколь- ходную папку, в консоли и
ких файлов допустимого раз- файле журнала появляются
мера, но недопустимого фор- сообщения об успешной кон-
мата. вертации файлов.
49
Продолжение таблицы 2.h
1. Запустить приложение, 3. Файлы постепенно пере-
указав в параметрах соответ- мещаются из входной в вы-
ствующие пути из приготовле- ходную папку, в консоли и
ния к тесту (имя файла жур- файле журнала появляются
нала – произвольное). сообщения об успешной кон-
2. Скопировать в папку вертации файлов.
для входных файлов нес-
колько файлов допустимого
формата. 5. Файлы постепенно пере-
Р
3. Переместить сконвертиро- мещаются из входной в вы-
ванные файлы из папки с ре- ходную папку, в консоли и
УИ
зультирующими файлами в файле журнала появляются
папку для входных файлов. сообщения об успешной кон-
4. Переместить сконвертиро- вертации файлов допустимого
ванные файлы из папки с ре- формата и сообщения об иг-
зультирующими файлами в
папку с набором файлов для
теста.
5. Переместить все файлы из
БГ
норировании файлов недопу-
стимого формата.
6. Файлы постепенно пере-
мещаются из входной в вы-
а
папки с набором файлов для ходную папку, в консоли и
теста в папку для входных файле журнала появляются
ек
файлов. сообщения об успешной кон-

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

ио
папку для входных файлов стимого формата
Этот тест-кейс одновременно является слишком сложным по избы-

бл
точности действий и по спецификации лишних данных и операций.
Задание 2.с: перепишите этот тест-кейс, устранив его недостат-

Би
ки, но сохранив общую цель (проверку повторной конвертации

уже ранее сконвертированных файлов).
Примером хорошего простого тест-кейса может служить тест-

кейс 3.
Пример хорошего сложного тест-кейса может выглядеть так, как
показано в таблице 2.i.
50
Таблица 2.i – Хороший сложный тест-кейс
Много копий приложения, 3. Все три копии приложения
конфликт файловых операций запускаются, в файле журнала
Приготовления: появляются последовательно
 Создать в корне любого три записи о запуске приложе-
диска три отдельные папки ния.
для входных файлов, выход-
ных файлов, файла журнала. 5. Файлы постепенно пере-
 Подготовить набор из не- мещаются из входной в вы-
скольких файлов максималь- ходную папку, в консоли и
Р
ного поддерживаемого разме- файле журнала появляются
ра поддерживаемых форма- сообщения об успешной кон-
УИ
тов с поддерживаемыми ко- вертации файлов, а также
дировками. (возможно) сообщения вида:
1. Запустить первую копию a. “source file inaccessi-
приложения, указав в пара- ble, retrying”.
метрах соответствующие пути
из приготовления к тесту (имя
файла журнала – произволь-
ное).
БГ
b.
c.
trying”.
“destination file inac-
cessible, retrying”.
“log file inaccessible, re-
а
2. Запустить вторую копию
приложения с теми же пара- Ключевым показателем кор-
ек
метрами (см. шаг 1). ректной работы является

3. Запустить третью копию успешная конвертация всех
файлов, а также появление в
т
приложения с теми же пара-

метрами (см. шаг 1). консоли и файле журнала со-
ио
4. Изменить приоритет про- общений об успешной конвер-

цессов второй (“high”) и тре- тации каждого файла (от одной
тей (“low”) копий. до трёх записей на каждый
бл
5. Скопировать подготовлен- файл).

ный набор исходных файлов в
папку для входных файлов Сообщения (предупреждения)
Би
о недоступности входного
файла, выходного файла или
файла журнала также являют-
ся показателем корректной ра-
боты приложения, однако их
количество зависит от многих
внешних факторов и не может
быть спрогнозировано заранее
51
Иногда более сложные тест-кейсы являются также и более специ-
фичными, но это лишь общая тенденция, а не закон. Также нельзя по
сложности тест-кейса однозначно судить о его приоритете (в нашем
примере хорошего сложного тест-кейса он явно будет иметь очень низ-
кий приоритет, т. к. проверяемая им ситуация является искусственной и
крайне маловероятной, но бывают и сложные тесты с самым высоким
приоритетом).
Как и в случае специфичности и общности, сами по себе простота
или сложность тест-кейсов не являются чем-то плохим (более того –
рекомендуется начинать разработку и выполнение тест-кейсов с про-
стых, а затем переходить ко всё более и более сложным), однако из-
Р
лишняя простота и излишняя сложность также снижают качество тест-
кейса.
УИ
«Показательность» (высокая вероятность обнаружения ошиб-
ки). Начиная с уровня тестирования критического пути можно утвер-
ждать, что тест-кейс является тем более хорошим, чем он более показа-
телен (с большей вероятностью обнаруживает ошибку). Именно поэтому
зательны.
БГ
мы считаем непригодными слишком простые тест-кейсы – они непока-
Пример непоказательного (плохого) тест-кейса показан в таблице 2.j.

Таблица 2.j – Плохой тест-кейс
а
Запуск и остановка приложения
ек
1. Запустить приложение с кор- 1. Приложение запускается.

ректными параметрами. 2. Приложение завершает
2. Завершить работу приложения работу
т
ио
Пример показательного (хорошего) тест-кейса показан в таблице 2.k.

Таблица 2.k – Плохой тест-кейс
бл
Запуск с некорректными пара- 1. В консоли отображаются

метрами, несуществующие пути нижеуказанные сообщения,
1. Запустить приложение со всеми приложение завершает ра-
Би
тремя параметрами боту. Сообщения:

(SOURCE_DIR, DESTINA- a. SOURCE_DIR: direc-
TION_DIR, LOG_FILE_NAME), tory not exists or inaccessi-
значения которых указывают на ble.
несуществующие в файловой b. DESTINATION_DIR:
системе пути (например: z:\src\, directory not exists or inac-
z:\dst\, z:\log.txt при условии, cessible.
что в системе нет логического c. LOG_FILE_NAME:
диска z) wrong file name or inacces-
sible path
52
Обратите внимание, что показательный тест-кейс по-прежнему
остался достаточно простым, но он проверяет ситуацию, возникновение
ошибки в которой несравненно более вероятно, чем в ситуации, описы-
ваемой плохим непоказательным тест-кейсом.
Также можно сказать, что показательные тест-кейсы часто выпол-
няют какие-то «интересные действия», т. е. такие действия, которые ед-
ва ли будут выполнены просто в процессе работы с приложением
(например: «сохранить файл» – это обычное тривиальное действие,
которое явно будет выполнено не одну сотню раз даже самими разра-
ботчиками, а вот «сохранить файл на носитель, защищённый от запи-
си», «сохранить файл на носитель с недостаточным объёмом свободно-
Р
го пространства», «сохранить файл в папку, к которой нет доступа» –
это уже гораздо более интересные и нетривиальные действия).
УИ
Последовательность в достижении цели. Суть этого свойства
выражается в том, что все действия в тест-кейсе направлены на следо-
вание единой логике и достижение единой цели и не содержат никаких
отклонений.
БГ
Примерами правильной реализации этого свойства могут служить
представленные в этом подразделе в избытке примеры хороших тест-
кейсов. А нарушение может выглядеть так, как показано в таблице 2.l.
а
Таблица 2.l – Ошибки в тест-кейсах
ек
Конвертация из всех поддер-

живаемых кодировок
Приготовления: 1. Приложение запускается и
т
 Создать в корне любого выводит сообщение о своём

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

ки для входных файлов, вы- нала.
ходных файлов, файла жур-
бл
нала и временного хранения

тестовых файлов.
 Распаковать содержимое
Би
прилагаемого архива в папку

для временного хранения те-
стовых файлов.
1. Запустить приложение,
указав в параметрах соответ-
ствующие пути из приготовле-
ния к тесту (имя файла жур-
нала – произвольное).
53
Продолжение таблицы 2.l
2. Скопировать файлы из 2. Файлы из папки для вход-
папки для временного хране- ных файлов перемещаются в
ния в папку для входных фай- папку для выходных файлов, в
лов. консоли и файле журнала
3. Остановить приложение. отображаются сообщения о
4. Удалить файл журнала. конвертации каждого из фай-
5. Повторно запустить при- лов с указанием его исходной
ложение с теми же парамет- кодировки.
рами. 3. Приложение выводит со-
Р
6. Остановить приложение общение о завершении рабо-
ты в файл журнала и завер-
УИ
шает работу.
5. Приложение запускается и
выводит сообщение о своём
БГ
запуске в консоль и заново со-
зданный файл журнала.
6. Приложение выводит со-
общение о завершении работы
а
в файл журнала и завершает
работу
ек
Шаги 3–5 никак не соответствуют цели тест-кейса, состоящей в

проверке корректности конвертации входных данных, представленных
т
во всех поддерживаемых кодировках.

ио
Отсутствие лишних действий. Чаще всего это свойство подразу-

мевает, что не нужно в шагах тест-кейса долго и по пунктам расписывать
то, что можно заменить одной фразой (таблица 2.m).
бл
Таблица 2.m – Лишние действия в тест-кейсах

Би
1. Указать в качестве первого 1. Запустить приложение со все-

параметра приложения путь к ми тремя корректными парамет-
папке с исходными файлами. рами (например: c:\src\, c:\dst\,
2. Указать в качестве второго c:\log.txt – при условии, что соот-
параметра приложения путь к ветствующие папки существуют и
папке с конечными файлами. доступны приложению)
3. Указать в качестве третье-
го параметра приложения
путь к файлу журнала.
4. Запустить приложение
54
Вторая по частоте ошибка – начало каждого тест-кейса с запуска
приложения и подробного описания по приведению его в то или иное со-
стояние. В наших примерах мы рассматриваем каждый тест-кейс как
существующий в единственном виде в изолированной среде и потому
вынуждены осознанно допускать эту ошибку (иначе тест-кейс будет не-
полным), но в реальной жизни на запуск приложения будут свои тесты, а
длинный путь из многих действий можно описать как одно действие, из
контекста которого понятно, как это действие выполнить. Следующий
пример тест-кейса не относится к нашему «Конвертеру файлов», но
очень хорошо иллюстрирует эту мысль (таблица 2.n).
Р
Таблица 2.n – Частые ошибки в тест-кейсах
УИ
1. Запустить приложение. 1. Открыть DOCX-
2. Выбрать в меню пункт «Файл». файл с тремя и бо-
3. Выбрать подпункт «Открыть». лее страницами
4. Перейти в папку, в которой находится хотя
бы один файл формата DOCX с тремя и бо-
лее страницами
БГ
И сюда же можно отнести ошибку с повторением одних и тех же
а
приготовлений во множестве тест-кейсов (да, по описанным выше при-
чинам в примерах мы снова вынужденно делаем так, как на практике
ек
делать не надо). Куда удобнее объединить тесты в набор и указать при-

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

идеально решена в автоматизированном модульном тестирова-
нии74 с использованием фреймворков наподобие JUnit или
бл
TestNG – там существует специальный «механизм фиксаций»

(fixture), автоматически выполняющий указанные действия пе-
ред каждым отдельным тестовым методом или после него.
Би
Неизбыточность по отношению к другим тест-кейсам. В про-

цессе создания множества тест-кейсов очень легко оказаться в ситуа-
ции, когда два и более тест-кейса фактически выполняют одни и те же
проверки, преследуют одни и те же цели, направлены на поиск одних и
тех же проблем. Существуют разные способы минимизации количества
таких тест-кейсов, такие как использование классов эквивалентности и
граничных условий.
74
Unit testing (component testing). The testing of individual software components.
ISTQB Glossary.
55
Если вы обнаруживаете несколько тест-кейсов, дублирующих за-
дачи друг друга, лучше всего или удалить все, кроме одного, самого по-
казательного, или перед удалением остальных на их основе доработать
этот выбранный самый показательный тест-кейс.
Демонстративность (способность демонстрировать обнару-
женную ошибку очевидным образом). Ожидаемые результаты долж-
ны быть подобраны и сформулированы таким образом, чтобы любое от-
клонение от них сразу же бросалось в глаза и становилось очевидным,
что произошла ошибка. Сравните выдержки из двух тест-кейсов.
Выдержка из недемонстративного тест-кейса представлена в таб-
лице 2.o.
Р
Таблица 2.o – Недемонстративный тест-кейс
УИ
5. Разместить в файле текст «При- 6. Приложение игнори-
мер длинного текста, содержащего рует файл.
символы русского и английского алфа- 7. Текст принимает
вита вперемешку.» в кодировке KOI8-R
(в слове «Пример» буквы «р» – ан-
глийские).
6.
БГ
Сохранить файл под именем «test.
корректный вид в коди-
ровке UTF-8 с учётом
английских букв
а
txt» и отправить файл на конвертацию.
7. Переименовать файл в «test.txt»
ек
Выдержка из демонстративного тест-кейса представлена в таб-

лице 2.p.
т
ио
Таблица 2.p – Демонстративный тест-кейс

5. Разместить в файле текст 6. Текст принимает вид:
бл
«╨Я╤А╨╕╨╝╨╡╤А «Пример текста.» (кодировка

╤В╨╡╨║╤Б╤В╨░ ╨▓.» (Эти UTF8)
символы представляют собой
словосочетание «Пример тек-
Би
ста.» в кодировке KOI8-R).

6. Отправить файл на кон-
вертацию
В первом случае тест-кейс не подходит не только из-за неясности

формулировки «корректный вид в кодировке UTF-8 с учётом английских
букв», там также очень легко допустить ошибки при выполнении:
 Забыть сконвертировать вручную входной текст в KOI8-R.
 Не заметить, что в первый раз расширение начинается с про-
бела.
56
 Забыть заменить в слове «Пример» букву «р» на английскую.
 Из-за расплывчатости формулировки ожидаемого результата
принять ошибочное, но выглядящее правдоподобно поведение за
верное.
Второй тест-кейс чётко ориентирован на свою цель по проверке
конвертации (не содержит странной проверки с игнорированием файла с
неверным расширением) и описан так, что его выполнение не представ-
ляет никаких сложностей, а любое отклонение фактического результата
от ожидаемого будет сразу же заметно.
Прослеживаемость. Из содержащейся в качественном тест-кейсе
информации должно быть понятно, какую часть приложения, какие
Р
функции и какие требования он проверяет. Частично это свойство дости-
гается через заполнение соответствующих полей тест-кейса («Ссылка
УИ
на требование», «Модуль», «Подмодуль»), но и сама логика тест-кейса
играет не последнюю роль, т. к. в случае серьёзных нарушений этого
свойства можно долго с удивлением смотреть, например, на какое тре-
бование ссылается тест-кейс, и пытаться понять, как же они друг с дру-
гом связаны.
БГ
Пример непрослеживаемого тест-кейса представлен в таблице 2.q.
Таблица 2.q – Непрослеживаемый тест-кейс

а
Требо- Модуль Подмо- Шаги Ожидаемые ре-
вание дуль зультаты
ек
ПТ-4 Приложе- Совмещение ко- 1. Допусти-

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

ми и недопусти- остаются без
мыми кодировка- изменений
бл
ми.
1. Передать
файл на конвер-
Би
тацию
Да, этот тест-кейс не подходит сам по себе (в качественном тест-

кейсе сложно получить ситуацию непрослеживаемости), но в нём есть и
особые недостатки, затрудняющие прослеживаемость:
 Ссылка на несуществующее требование (убедитесь сами,
требования ПТ-4 нет).
 В поле «Модуль» указано значение «Приложение» (по боль-
шому счёту можно было оставлять это поле пустым – это было бы
столь же информативно), поле «Подмодуль» не заполнено.
57
 По заглавию и шагам можно предположить, что этот тест-кейс
ближе всего к ДС-5.1 и ДС-5.3, но сформулированный ожидаемый
результат не следует явно из этих требований.
Пример прослеживаемого тест-кейса представлен в таблице 2.r.
Таблица 2.r – Прослеживаемый тест-кейс

Требо- Мо- Подмо- Шаги Ожидаемые результаты
вание дуль дуль
ДС-2.4, Стар- Обра- Запуск с не- 1. В консоли отобра-
ДС-3.2 тер ботчик корректными жаются нижеуказанные
ошибок параметрами, сообщения, приложение
Р
несуществую- завершает работу. Со-
щие пути общения
УИ
1. Запустить a. SOURCE_DIR: direc-
приложение со tory not exists or inac-
всеми тремя cessible.
параметрами, b. DESTINTION_DIR:
БГ
значения кото-
рых указывают
на несуществу-
ющие в файло-
directory not exists or in-
accessible.
c. LOG_FILE_NAME:
wrong file name or in-
а
вой системе accessible path
пути
ек
Можно подумать, что этот тест-кейс затрагивает ДС-2 и ДС-3 цели-

т
ком, но в поле «Требование» есть вполне чёткая конкретизация, к тому

же указанные модуль, подмодуль и сама логика тест-кейса устраняют
ио
оставшиеся сомнения.
Возможность повторного использования. Это свойство редко
выполняется для низкоуровневых тест-кейсов (см. «Низкоуровневый
бл
тест-кейс» в подразделе 2.5), но при создании высокоуровневых тест-

кейсов (см. «Высокоуровневый тест-кейс» в подразделе 2.5) можно до-
биться таких формулировок, при которых тест-кейс практически без из-
Би
менений можно будет использовать для тестирования аналогичной

функциональности в других проектах или других областях приложения.
Примером тест-кейса, который тяжело использовать повторно, мо-
жет являться практически любой тест-кейс с высокой специфичностью.
Не самым идеальным, но очень наглядным примером тест-кейса,
который может быть легко использован в разных проектах, может слу-
жить следующий тест-кейс (таблица 2.s).
58
Таблица 2.s – Наглядный тест-кейс
Запуск, все параметры некор- 1. Приложение запускается,
ректны после чего выводит сообще-
1. Запустить приложение, ука- ние с описанием сути про-
зав в качестве всех парамет- блемы с каждым из парамет-
ров заведомо некорректные ров и завершает работу
значения
Соответствие принятым шаблонам оформления и традициям.

С шаблонами оформления, как правило, проблем не возникает: они
Р
строго определены имеющимся образцом или вообще экранной формой
инструментального средства управления тест-кейсами. Что же касается
УИ
традиций, то они отличаются даже в разных командах в рамках одной
компании, и тут невозможно дать иного совета, кроме как «почитайте
уже готовые тест-кейсы перед тем, как писать свои».
БГ
2.5 Наборы тест-кейсов
Терминология и общие сведения
Набор тест-кейсов (test case suite75, test suite, test set) – сово-
а
купность тест-кейсов, выбранных с некоторой общей целью или
по некоторому общему признаку. Иногда в такой совокупности
ек
результаты завершения одного тест-кейса становятся входным

состоянием приложения для следующего тест-кейса.
т
Внимание! Из-за особенностей перевода очень часто вместо

ио
«набор текст-кейсов» говорят «тестовый сценарий». Формально

это можно считать ошибкой, но это явление приобрело настоль-
ко широкое распространение, что стало вариантом нормы.
бл
Как мы только что убедились на примере множества отдельных

тест-кейсов, крайне неудобно (более того, это ошибка!) каждый раз пи-
Би
сать в каждом тест-кейсе одни и те же приготовления и повторять одни и

те же начальные шаги.
Намного удобнее объединить несколько тест-кейсов в набор или
последовательность. И здесь мы приходим к классификации наборов
тест-кейсов.
В общем случае наборы тест-кейсов можно разделить на свобод-
ные (порядок выполнения тест-кейсов не важен) и последовательные
(порядок выполнения тест-кейсов важен).
75
Test case suite (test suite, test set). A set of several test cases for a component or sys-
tem under test, where the post condition of one test is often used as the precondition for the next
one. ISTQB Glossary.
59
Преимущества свободных наборов:
 Тест-кейсы можно выполнять в любом удобном порядке, а
также создавать «наборы внутри наборов».
 Если какой-то тест-кейс завершился ошибкой, это не повлия-
ет на возможность выполнения других тест-кейсов.
Преимущества последовательных наборов:
 Каждый следующий в наборе тест-кейс в качестве входного
состояния приложения получает результат работы предыдущего
тест-кейса, что позволяет сильно сократить количество шагов в от-
дельных тест-кейсах.
 Длинные последовательности действий куда лучше имитиру-
Р
ют работу реальных пользователей, чем отдельные воздействия
на приложение.
УИ
Пользовательские сценарии (сценарии использования)
В данном случае речь НЕ идёт о use cases (вариантах исполь-

зования), представляющих собой форму требований (см. под-
БГ
раздел 1.4). Пользовательские сценарии как техника тестиро-
вания куда менее формализованы, хотя и могут строиться на
основе вариантов использования.
а
К отдельному подвиду последовательных наборов тест-кейсов
(или даже неоформленных идей тест-кейсов, таких, как пункты чек-
ек
листа) можно отнести пользовательские сценарии76 (или сценарии ис-

пользования), представляющие собой цепочки действий, выполняемых
т
пользователем в определённой ситуации для достижения определённой

цели.
ио
Поясним это сначала на примере, не относящемся к «Конвертеру

файлов». Допустим, пользователь хочет распечатать табличку на дверь
кабинета с текстом «Идёт работа, не стучать!» Для этого ему нужно:
бл
1) Запустить текстовый редактор.

2) Создать новый документ (если редактор не делает это са-
мостоятельно).
Би
3) Набрать в документе текст.

4) Отформатировать текст должным образом.
5) Отправить документ на печать.
6) Сохранить документ (спорно, но допустим).
7) Закрыть текстовый редактор.
Вот мы и получили пользовательский сценарий, пункты которого
76
A scenario is a hypothetical story, used to help a person think through a complex problem
or system. Kaner C. An Introduction to Scenario Testing. URL:
60
могут стать основой для шагов тест-кейса или целого набора отдельных
тест-кейсов.
Сценарии могут быть достаточно длинными и сложными, могут со-
держать внутри себя циклы и условные ветвления, но при всём этом они
обладают рядом весьма интересных преимуществ:
 Сценарии показывают реальные и понятные примеры ис-
пользования продукта (в отличие от обширных чек-листов, где
смысл отдельных пунктов может теряться).
 Сценарии понятны конечным пользователям и хорошо под-
ходят для обсуждения и совместного улучшения.
 Сценарии и их части легче оценивать с точки зрения важно-
Р
сти, чем отдельные пункты (особенно низкоуровневых) требова-
ний.
УИ
 Сценарии отлично показывают недоработки в требованиях
(если становится непонятно, что делать в том или ином пункте
сценария, – с требованиями явно что-то не то).
 В предельном случае (нехватка времени и прочие форс-
БГ
мажоры) сценарии можно даже не прописывать подробно, а просто
именовать – и само наименование уже подскажет опытному спе-
циалисту, что делать.
Последний пункт проиллюстрируем на примере. Классифицируем
а
потенциальных пользователей нашего приложения (напомним, что в
нашем случае «пользователь» – это администратор, настраивающий
ек
работу приложения) по степени квалификации и склонности к экспери-

ментам, а затем дадим каждому «виду пользователя» запоминающееся
т
имя (таблица 2.t).

ио
Таблица 2.t – Классификация пользователей

Вид Низкая квалифика- Высокая квалифи-
пользователя ция кация
бл
Не склонен к экспе- «Осторожный» «Консервативный»

риментам
Склонен к экспери- «Отчаянный» «Изощрённый»
Би
ментам
Согласитесь, уже на этой стадии не составляет труда представить

себе отличия в логике работы с приложением, например, «консерватив-
ного» и «отчаянного» пользователей.
Но мы пойдём дальше и озаглавим для них сами сценарии, напри-
мер, в ситуациях, когда такой пользователь позитивно и негативно отно-
сится к идее внедрения нашего приложения (таблица 2.u).
61
Таблица 2.u – Сценарии поведения на основе классификации
пользователей
Отношение «Осторож- «Консерва- «Отчаян- «Изощрён-
пользова- ный» тивный» ный» ный»
теля
«А можно «Начнём с ин- «Гляньте, «Я всё оп-
Позитивное вот так?» струкции!» что я при- тимизирую!»
думал!»
«Я ничего «У вас вот «Всё равно «А я гово-
Негативное не пони- здесь несоот- поломаю!» рил!»
маю.» ветствие…»
Р
Проявив даже немного воображения, можно представить, что и как
УИ
будет происходить в каждой из получившихся восьми ситуаций. Причём
на создание пары таких таблиц уходит всего несколько минут, а эффект
от их использования значительно превосходит бездумное «кликанье по
кнопкам в надежде найти баг».
БГ
Куда более полное и техничное объяснение того, что такое
сценарное тестирование, как его применять и выполнять
должным образом, можно прочесть в статье Сэма Канера «An
Introduction to Scenario Testing»77.
а
ек
Подробная классификация наборов тест-кейсов может быть выра-

жена таблицей 2.v.
т
Таблица 2.v – Подробная классификация наборов тест-кейсов

По образованию тест- По изолированности тест-кейсов
ио
кейсами строгой по- друг от друга

следовательности Изолированные Обобщённые
Изолированные Обобщённые
бл
Свободные
свободные свободные
Изолированные Обобщённые
Последовательные
последовательные последовательные
Би
Следует отметить следующие особенности:

 Набор изолированных свободных тест-кейсов (рисунок 2.b):
действия из раздела «приготовления» нужно повторить перед каж-
дым тест-кейсом, а сами тест-кейсы можно выполнять в любом по-
рядке.
77
Kaner C. An Introduction to Scenario Testing. URL:
62
 Набор обобщённых свободных тест-кейсов (рисунок 2.c): дей-
ствия из раздела «приготовления» нужно выполнить один раз (а
потом просто выполнять тест-кейсы), а сами тест-кейсы можно вы-
полнять в любом порядке.
 Набор изолированных последовательных тест-кейсов (рису-
нок 2.d): действия из раздела «приготовления» нужно повторить
перед каждым тест-кейсом, а сами тест-кейсы нужно выполнять в
строго определённом порядке.
 Набор обобщённых последовательных тест-кейсов (рисунок
2.e): действия из раздела «приготовления» нужно выполнить один
раз (а потом просто выполнять тест-кейсы), а сами тест-кейсы нуж-
Р
но выполнять в строго определённом порядке.
Главное преимущество изолированности: каждый тест-кейс выпол-
УИ
няется в «чистой среде», на него не влияют результаты работы преды-
дущих тест-кейсов.
Главное преимущество обобщённости: приготовления не нужно
повторять (экономия времени).
БГ
Главное преимущество последовательности: ощутимое сокраще-
ние шагов в каждом тест-кейсе, т. к. результат выполнения предыдущего
тест-кейса является начальной ситуацией для следующего.
Главное преимущество свободы: возможность выполнять тест-
а
кейсы в любом порядке, а также то, что при провале некоего тест-кейса
(приложение не пришло в ожидаемое состояние) остальные тест-кейсы
ек
по-прежнему можно выполнять.

т
Приготовления
ио
Приготовления Тест 3
Тест 1
бл
Би
Тест 2
Рисунок 2.b – Набор изолированных свободных тест-кейсов
63
Тест 3
Тест 1
Тест 2
Рисунок 2.c – Набор обобщённых свободных тест-кейсов
Р
УИ
Тест 1
БГ
Тест 2
а
ек
Тест 3
т
Рисунок 2.d – Набор изолированных последовательных тест-кейсов

ио
бл
Тест 1
Би
Тест 2
Тест 3
Рисунок 2.e – Набор обобщённых последовательных тест-кейсов
64
Ниже будут рассмотрены принципы построения наборов тест-
кейсов.
Главный вопрос: как формировать наборы тест-кейсов? Правиль-
ный ответ звучит очень кратко: логично. И это не шутка. Единственная
задача наборов – повысить эффективность тестирования за счёт уско-
рения и упрощения выполнения тест-кейсов, увеличения глубины ис-
следования некоей области приложения или функциональности, следо-
вания типичным пользовательским сценариям (см. «Пользовательские
сценарии (сценарии использования)» в подразделе 2.5) или удобной по-
следовательности выполнения тест-кейсов и т. д.
Набор тест-кейсов всегда создаётся с какой-то целью, на основе
Р
какой-то логики, и по этим же принципам в набор включаются тесты, об-
ладающие подходящими свойствами.
УИ
Если же говорить о наиболее типичных подходах к составлению
наборов тест-кейсов, то можно обозначить следующие:
 На основе чек-листов. Посмотрите внимательно на примеры
чек-листов, которые мы разработали в соответствующем подраз-
 БГ
деле 2.1: каждый пункт чек-листа может превратиться в несколько
тест-кейсов – и вот мы получаем готовый набор.
На основе разбиения приложения на модули и подмодули
(см. «Модуль и подмодуль приложения» в подразделе 2.3). Для
а
каждого модуля (или его отдельных подмодулей) можно составить
свой набор тест-кейсов.
ек
 По принципу проверки самых важных, менее важных и всех

остальных функций приложения (именно по этому принципу мы со-
т
ставляли примеры чек-листов в вышеупомянутом подразделе 2.1).

 По принципу группировки тест-кейсов для проверки некоего
ио
уровня требований или типа требований (см. подраздел 1.4), груп-

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

разом завершаются неудачей, значит, мы можем объединить их в
набор, условно названный «проблемные места в приложении»).
Би
 По архитектурному принципу: наборы для проверки пользо-

вательского интерфейса и всего уровня представления, для про-
верки уровня бизнес-логики, для проверки уровня данных.
 По области внутренней работы приложения, например: «тест-
кейсы, затрагивающие работу с базой данных», «тест-кейсы, затра-
гивающие работу с файловой системой», «тест-кейсы, затрагива-
ющие работу с сетью» и т. д.
 По видам тестирования.
Не нужно заучивать этот список. Это всего лишь примеры – грубо
говоря, «первое, что приходит в голову». Важен принцип: если вы види-
65
те, что выполнение некоторых тест-кейсов в виде набора принесёт вам
пользу, создавайте такой набор.
Примечание – Без хороших инструментальных средств управле-
ния тест-кейсами работать с наборами тест-кейсов крайне тяжело, т. к.
приходится самостоятельно следить за приготовлениями, «недостаю-
щими шагами», изолированностью или обобщённостью, свободностью
или последовательностью и т. д.
Р
 Какие разновидности тестов вы запомнили?
 Какие рекомендации по разработке тестов вы запомнили?
УИ
 Назовите основные шаги разработки тестов.
 Назовите несколько техник ускорения написания тестов.
 Каковы основные задачи планирования тестовых испытаний
и составления тестового плана?




Что такое тестовый план?
БГ
Каковы основные свойства тестового плана?
Что такое тестовый сценарий (test case)?
Зачем нужны тест-кейсы?
а
 Каковы критерии хорошего тестового сценария?
ек
 Каковы основные задачи планирования тестовых испытаний

и составления тестового плана?
 Какие основные действия необходимо выполнить на стадии
т
планирования?
ио
 Перечислите артефакты, создаваемые на стадии планирова-

ния тестирования.
 Каковы основные сложности планирования тестовых испыта-
бл
ний?
 Назовите основные разделы тестового плана. Что описыва-
ется в каждом из них?
 Что приводится в разделе «описание процесса тестирова-
Би
ния» тест-плана?
 Какая информация содержится в разделе «краткое описание»
тест-плана?
 Какие риски необходимо учитывать при планировании тесто-
вых испытаний?
 Каковы критерии хорошего тестового плана?
 Каковы преимущества хорошего тестового плана?
 Что такое позитивные и негативные тесты и зачем они
нужны?
66
3 ОТЧЁТЫ О ДЕФЕКТАХ
3.1 Ошибки, дефекты, сбои, отказы
Упрощённый взгляд на понятие дефекта

В этой главе мы будем изучать терминологию (она действительно
важна!), а потому начнём с очень простого: дефектом упрощённо можно
считать любое расхождение ожидаемого (свойства, результата, поведе-
ния и т. д., которое мы ожидали увидеть) и фактического (свойства, ре-
зультата, поведения и т. д., которое мы на самом деле увидели). При
обнаружении дефекта создаётся отчёт о дефекте.
Р
Дефект – расхождение ожидаемого и фактического результата.
УИ
Ожидаемый результат – поведение системы, описанное в
требованиях.
Фактический результат – поведение системы, наблюдаемое
в процессе тестирования.
БГ
ВАЖНО! Эти три определения приведены в предельно упрощён-
ной (и даже искажённой) форме с целью первичного ознакомле-
ния. Полноценные формулировки см. далее в данной главе.
а
Поскольку столь простая трактовка не покрывает все возможные
ек
формы проявления проблем с программными продуктами, мы сразу же

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

ио
проблемы. Разберёмся с широким спектром синонимов, которыми обо-

значают проблемы с программными продуктами и иными артефактами и
процессами, сопутствующими их разработке.
бл
В силлабусе ISTQB написано78, что человек совершает ошибки, ко-

торые приводят к возникновению дефектов в коде, которые, в свою оче-
редь, приводят к сбоям и отказам приложения (однако сбои и отказы мо-
гут возникать и из-за внешних условий, таких как электромагнитное воз-
Би
действие на оборудование и т. д.)
78
A human being can make an error (mistake), which produces a defect (fault, bug) in the
program code, or in a document. If a defect in code is executed, the system may fail to do what it
should do (or do something it shouldn't), causing a failure. Defects in software, systems or docu-
ments may result in failures, but not all defects do so. Defects occur because human beings are
fallible and because there is time pressure, complex code, complexity of infrastructure, changing
technologies, and/or many system interactions. Failures can be caused by environmental condi-
tions as well. For example, radiation, magnetism, electronic fields, and pollution can cause faults in
firmware or influence the execution of software by changing the hardware conditions. ISTQB Sylla-
bus.
67
Таким образом, упрощённо можно изобразить схему, показанную
на рисунке 3.а.
Ошибка Дефект Сбой или отказ
Рисунок 3.a – Ошибки, дефекты, сбои и отказы
Если же посмотреть на англоязычную терминологию, представ-

ленную в глоссарии ISTQB и иных источниках, можно построить чуть бо-
лее сложную схему (рисунок 3.b).
Р
Defect
Failure,
Error (Mistake) (Problem, Bug,
Interruption
УИ
Fault)
Anomaly, Incident (Deviation)
БГ
Рисунок 3.b – Взаимосвязь проблем в разработке
программных продуктов
а
Рассмотрим все соответствующие термины.
ек
Ошибка (error79, mistake) – действие человека, приводящее к

некорректным результатам.
т
ио
Этот термин очень часто используют как наиболее универсальный,

описывающий любые проблемы («ошибка человека», «ошибка в коде»,
«ошибка в документации», «ошибка выполнения операции», «ошибка
передачи данных», «ошибочный результат» и т. п.) Более того, куда ча-
бл
ще вы сможете услышать «отчёт об ошибке», чем «отчёт о дефекте». И

это нормально, так сложилось исторически, к тому же термин «ошибка»
на самом деле имеет очень широкий смысл.
Би
Дефект (defect80, bug, problem, fault) – недостаток в компоненте

или системе, способный привести к ситуации сбоя или отказа.
79
Error, Mistake. A human action that produces an incorrect result. ISTQB Glossary.
80
Defect, Bug, Problem, Fault. A flaw in a component or system that can cause the com-
ponent or system to fail to perform its required function, e.g. an incorrect statement or data defini-
tion. A defect, if encountered during execution, may cause a failure of the component or system.
ISTQB Glossary.
68
Этот термин также понимают достаточно широко, говоря о дефек-
тах в документации, настройках, входных данных и т. д. Почему глава
называется именно «отчёты о дефектах»? Потому что этот термин как
раз стоит посередине – бессмысленно писать отчёты о человеческих
ошибках, равно как и почти бесполезно просто описывать проявления
сбоев и отказов – нужно «докопаться» до их причины, и первым шагом
в этом направлении является именно описание дефекта.
Сбой (interruption81) или отказ (failure82) – отклонение поведе-

ния системы от ожидаемого.
Р
В ГОСТ 27.002-89 даны хорошие и краткие определения сбоя и
отказа.
УИ
Сбой – самоустраняющийся отказ или однократный отказ,
устраняемый незначительным вмешательством оператора.
Отказ – событие, заключающееся в нарушении работоспособ-
ного состояния объекта.
БГ
Эти термины скорее относятся к теории надёжности и нечасто
встречаются в повседневной работе тестировщика, но именно сбои и от-
казы являются тем, что тестировщик замечает в процессе тестирования
а
(и отталкиваясь от чего, проводит исследование с целью выявить де-
фект и его причины).
ек
Аномалия (anomaly83) или инцидент (incident84, deviation84) –

любое отклонение наблюдаемого (фактического) состояния, по-
т
ведения, значения, результата, свойства от ожиданий наблюда-

ио
теля, сформированных на основе требований, спецификаций,

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

малий – отклонений фактического результата от ожидаемого. Стоит
отметить, что ожидаемый результат действительно может основываться
Би
на опыте и здравом смысле, т. к. поведение программного средства ни-
81
Interruption. A suspension of a process, such as the execution of a computer program,
caused by an event external to that process and performed in such a way that the process can be
resumed. URL: http://www.electropedia.org/iev/iev.nsf/display?openform&ievref=714-22-10.
82
Failure. Deviation of the component or system from its expected delivery, service or re-
sult. ISTQB Glossary.
83
Anomaly. Any condition that deviates from expectation based on requirements specifica-
tions, design documents, user documents, standards, etc. or from someone’s perception or experi-
ence. Anomalies may be found during, but not limited to, reviewing, testing, analysis, compilation,
or use of software products or applicable documentation. See also bug, defect, deviation, error,
fault, failure, incident, problem. ISTQB Glossary.
84
Incident, Deviation. Any event occurring that requires investigation. ISTQB Glossary.
69
когда не специфицируют до уровня базовых элементарных приёмов ра-
боты с компьютером.
Теперь, чтобы окончательно избавиться от путаницы и двусмыс-
ленности, договоримся, что именно мы будем считать дефектом в кон-
тексте данной книги.
Дефект – отклонение (deviation84) фактического результата (ac-

tual result85) от ожиданий наблюдателя (expected result86), сфор-
мированных на основе требований, спецификаций, иной доку-
ментации или опыта и здравого смысла.
Р
Отсюда логически вытекает, что дефекты могут встречаться не
только в коде приложения, но и в любой документации, в архитектуре и
УИ
дизайне, в настройках – где угодно.
Важно понимать, что приведённое определение дефекта позво-

ляет лишь поднять вопрос о том, является ли некое поведение
БГ
приложения дефектом. В случае, если из проектной документа-
ции не следует однозначного положительного ответа, обяза-
тельно стоит обсудить свои выводы с коллегами и добиться до-
несения поднятого вопроса до заказчика, если его мнение по
а
обсуждаемому «кандидату в баги» неизвестно.
ек
Хорошее представление о едва-едва затронутой нами теме

теории надёжности можно получить, прочитав книгу Рудольфа
т
Стапелберга «Руководство по надёжности, доступности, ремон-

топригодности и безопасности в инженерном проектировании»
ио
(Stapelberg R. F. Handbook of Reliability, Availability, Maintainability

and Safety in Engineering Design).
бл
А краткую, но достаточно подробную классификацию аномалий

в программных продуктах можно посмотреть в стандарте IEEE
1044:2009 Standard Classification For Software Anomalies.
Би
3.2 Отчёт о дефекте и его жизненный цикл
Как было сказано в подразделе 3.1, при обнаружении дефекта те-

стировщик создаёт отчёт о дефекте.
85
Actual result. The behavior produced/observed when a component or system is tested.
ISTQB Glossary.
86
Expected result, Expected outcome, Predicted outcome. The behavior predicted by
the specification, or another source, of the component or system under specified conditions.
ISTQB Glossary.
70
Отчёт о дефекте (defect report87) – документ, описывающий и
приоритизирующий обнаруженный дефект, а также содейству-
ющий его устранению.
Как следует из самого определения, отчёт о дефекте пишется со

следующими основными целями:
 Предоставить информацию о проблеме – уведомить проект-
ную команду и иных заинтересованных лиц о наличии проблемы,
описать суть проблемы.
 Приоритизировать проблему – определить степень опасно-
Р
сти проблемы для проекта и желаемые сроки её устранения.
 Содействовать устранению проблемы – качественный отчёт
УИ
о дефекте не только предоставляет все необходимые подробности
для понимания сути случившегося, но также может содержать ана-
лиз причин возникновения проблемы и рекомендации по исправ-
лению ситуации.
БГ
На последней цели следует остановиться подробнее. Есть мнение,
что «хорошо написанный отчёт о дефекте – половина решения про-
блемы для программиста». И действительно, как мы увидим далее, от
полноты, корректности, аккуратности, подробности и логичности отчёта
а
о дефекте зависит очень многое – одна и та же проблема может быть
описана так, что программисту останется буквально исправить пару
ек
строк кода, а может быть описана и так, что сам автор отчёта на следу-
ющий день не сможет понять, что же он имел в виду.
т
ВАЖНО! «Сверхцель» написания отчёта о дефекте состоит в

ио
быстром исправлении ошибки (а в идеале – и недопущении её

возникновения в будущем). Потому качеству отчётов о дефекте
следует уделять особое, повышенное внимание.
бл
Отчёт о дефекте (и сам дефект вместе с ним) проходит опреде-

лённые стадии жизненного цикла, которые схематично можно показать
Би
так (рисунок 3.c):

 Обнаружен (submitted) – начальное состояние отчёта (ино-
гда называется «Новый» (new)), в котором он находится сразу по-
сле создания. Некоторые средства также позволяют сначала со-
здавать черновик (draft) и лишь потом публиковать отчёт.
 Назначен (assigned) – в это состояние отчёт переходит с
момента, когда кто-то из проектной команды назначается ответ-
ственным за исправление дефекта. Назначение ответственного
87
Defect report, Bug report. A document reporting on any flaw in a component or system
that can cause the component or system to fail to perform its required function. ISTQB Glossary.
71
производится или решением лидера команды разработки, или кол-
легиально, или по добровольному принципу, или иным принятым в
команде способом или выполняется автоматически на основе
определённых правил.
 Исправлен (fixed) – в это состояние отчёт переводит ответ-
ственный за исправление дефекта член команды после выполне-
ния соответствующих действий по исправлению.
 Проверен (verified) – в это состояние отчёт переводит тести-
ровщик, удостоверившийся, что дефект на самом деле был устра-
нён. Как правило, такую проверку выполняет тестировщик, изна-
чально написавший отчёт о дефекте.
Р
Обнаружен Назначен Исправлен Проверен
УИ
Открыт заново Закрыт
БГ Рекомендован к
отклонению
а
ек
Отложен Отклонён
т
Рисунок 3.c – Жизненный цикл отчёта о дефекте с наиболее типичными

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

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

чётов о дефектах. Более того – многие такие средства позво-
ляют гибко настраивать эти параметры. На рисунке 3.c показан
Би
лишь общий принцип.
 Закрыт (closed) – состояние отчёта, означающее, что по

данному дефекту не планируется никаких дальнейших действий.
Здесь есть некоторые расхождения в жизненном цикле, принятом в
разных инструментальных средствах управления отчётами о де-
фектах:
o В некоторых средствах существуют оба состояния –
«Проверен» и «Закрыт», чтобы подчеркнуть, что в состоянии
«Проверен» ещё могут потребоваться какие-то дополнитель-
72
ные действия (обсуждения, дополнительные проверки в но-
вых билдах и т. д.), в то время как состояние «Закрыт» озна-
чает «с дефектом покончено, больше к этому вопросу не воз-
вращаемся».
o В некоторых средствах одного из состояний нет (оно по-
глощается другим).
o В некоторых средствах в состояние «Закрыт» или «От-
клонён» отчёт о дефекте может быть переведён из множе-
ства предшествующих состояний с резолюциями наподобие:
 «Не является дефектом» – приложение так и
должно работать, описанное поведение не является
Р
аномальным.
 «Дубликат» – данный дефект уже описан в дру-
УИ
гом отчёте.
 «Не удалось воспроизвести» – разработчикам не
удалось воспроизвести проблему на своём оборудова-
нии.

БГ
«Не будет исправлено» – дефект есть, но по ка-
ким-то серьёзным причинам его решено не исправлять.
 «Невозможно исправить» – непреодолимая при-
чина дефекта находится вне области полномочий ко-
а
манды разработчиков, например существует проблема
в операционной системе или аппаратном обеспечении,
ек
влияние которой устранить разумными способами не-

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

ио
ние «Закрыт», в некоторых – в состояние «Отклонён», в не-

которых – часть случаев закреплена за состоянием «За-
крыт», часть – за «Отклонён».
бл
 Открыт заново (reopened) – в это состояние (как правило, из

состояния «Исправлен») отчёт переводит тестировщик, удостове-
рившийся, что дефект по-прежнему воспроизводится на билде, в
Би
котором он уже должен быть исправлен.

 Рекомендован к отклонению (to be declined) – в это состоя-
ние отчёт о дефекте может быть переведён из множества других
состояний с целью вынести на рассмотрение вопрос об отклонении
отчёта по той или иной причине. Если рекомендация является
обоснованной, отчёт переводится в состояние «Отклонён» (см.
следующий пункт).
 Отклонён (declined) – в это состояние отчёт переводится в
случаях, подробно описанных в пункте «Закрыт», если средство
управления отчётами о дефектах предполагает использование это-
73
го состояния вместо состояния «Закрыт» для тех или иных резо-
люций по отчёту.
 Отложен (deferred) – в это состояние отчёт переводится в
случае, если исправление дефекта в ближайшее время является
нерациональным или не представляется возможным, однако есть
основания полагать, что в обозримом будущем ситуация исправит-
ся (выйдет новая версия библиотеки, вернётся из отпуска специа-
лист по некоей технологии, изменятся требования заказчика и т. д.)
Для полноты рассмотрения данной подтемы приведён пример жиз-
ненного цикла, принятого по умолчанию в инструментальном средстве
управления отчётами о дефектах JIRA88 (рисунок 3.d).
Р
УИ
Создание
Открыт Исправление Исправлен
Остановка
Закрытие
БГ Закрытие
а
работы
Повторное
ек
Начало Повторное открытие

работы
Закрыт открытие
т
Закрытие Закрытие
ио
бл
В работе Начало работы Открыт заново

Би
Исправление
Рисунок 3.d – Жизненный цикл отчёта о дефекте в JIRA
3.3 Атрибуты (поля) отчёта о дефекте
В зависимости от инструментального средства управления отчёта-

88
What is Workflow. URL: https://confluence.atlassian.com/display/JIRA/
What+is+Workflow.
74
ми о дефектах внешний вид их записи может немного отличаться, могут
быть добавлены или убраны отдельные поля, но концепция остаётся
неизменной.
Общий вид всей структуры отчёта о дефекте представлен на ри-
сунке 3.e.
Идентификатор Шаги по воспроизведению

Подробное описание
Краткое описание
Р
19 Бесконечный Если у входного файла 1. Поместить в
цикл обработки выставлен атрибут каталог-источник
УИ
входного фай- «только для чтения», по- файл допустимо-
ла с атрибутом сле обработки приложе- го типа и разме-
«только для нию не удаётся переме- ра.
чтения» стить его в каталог- 2. Установить
БГ
приёмник: создаётся ко-
пия файла, но оригинал
не удаляется, и прило-
жение снова и снова об-
данному файлу
атрибут «только
для чтения».
3. Запустить
а
рабатывает этот файл и приложение.
безуспешно пытается
ек
переместить его в ката- Дефект: обрабо-

лог-приёмник. танный файл по-
является в ката-
т
Ожидаемый результат:
после обработки файл логе-приёмнике,
ио
перемещён из каталога- но не удаляется

источника в каталог- из каталога-
приёмник. источника, файл
бл
Фактический резуль- в каталоге-

тат: обработанный файл приёмнике
копируется в каталог- непрерывно об-
Би
приёмник, но его ориги- новляется (вид-

нал остаётся в каталоге- но по значению
источнике. времени послед-
Требование: ДС-2.1. него изменения).
Рисунок 3.e – Общий вид отчёта о дефекте

(продолжение рисунка см. на с. 76)
75
Воспроизводимость Возможность обойти
Приложения
Срочность Комментарий
Важность Симптом
Всегда Средняя Обычная Некорректная Нет Если заказчик не -

операция планирует исполь-
зовать установку
атрибута «только
для чтения» фай-
лам в каталоге-
Р
источнике для до-
стижения неких
УИ
своих целей, можно
просто снимать
этот атрибут и спо-
койно перемещать
БГ
файл
Рисунок 3.e – Продолжение (начало см. на с. 75)

а
Задание 3.a: как вы думаете, почему этот отчёт о дефекте мож-
но по формальным признакам отклонить с резолюцией «не яв-
ек
ляется дефектом»?
Теперь рассмотрим каждый атрибут подробно.

т
Идентификатор (identifier) представляет собой уникальное значе-

ио
ние, позволяющее однозначно отличить один отчёт о дефекте от другого

и используемое во всевозможных ссылках. В общем случае идентифи-
катор отчёта о дефекте может представлять собой просто уникальный
бл
номер, но (если позволяет инструментальное средство управления от-

чётами) может быть и куда сложнее: включать префиксы, суффиксы и
иные осмысленные компоненты, позволяющие быстро определить суть
Би
дефекта и часть приложения (или требований), к которой он относится.

Краткое описание (summary) должно в предельно лаконичной
форме давать исчерпывающий ответ на вопросы «Что произошло?»
«Где это произошло»? «При каких условиях это произошло?». Напри-
мер: «Отсутствует логотип на странице приветствия, если пользователь
является администратором»:
 Что произошло? Отсутствует логотип.
 Где это произошло? На странице приветствия.
 При каких условиях это произошло? Если пользователь явля-
ется администратором.
76
Одной из самых больших проблем для начинающих тестировщиков
является именно заполнение поля «краткое описание», которое одно-
временно должно:
 Содержать предельно краткую, но в то же время достаточную
для понимания сути проблемы информацию о дефекте.
 Отвечать на только что упомянутые вопросы («что, где и при
каких условиях случилось») или как минимум на те 1–2 вопроса,
которые применимы к конкретной ситуации.
 Быть достаточно коротким, чтобы полностью помещаться на
экране (в тех системах управления отчётами о дефектах, где конец
этого поля обрезается или приводит к появлению скроллинга).
Р
 При необходимости содержать информацию об окружении,
под которым был обнаружен дефект.
УИ
 Быть законченным предложением русского или английского
(или иного) языка, построенным по соответствующим правилам
грамматики.
Для создания хороших кратких описаний дефектов рекомендуется
пользоваться следующим алгоритмом:
1.
БГ
Полноценно понять суть проблемы. До тех пор, пока у тести-
ровщика нет чёткого, «кристально чистого» понимания того, «что
сломалось», писать отчёт о дефекте вообще едва ли стоит.
а
2. Сформулировать подробное описание (description) дефекта –
сначала без оглядки на длину получившегося текста.
ек
3. Убрать из получившегося подробного описания всё лишнее,

уточнить важные детали.
т
4. Выделить в подробном описании слова (словосочетания,

фрагменты фраз), отвечающие на вопросы, «что, где и при каких
ио
условиях случилось».
5. Оформить результат, получившийся в пункте 4, в виде закон-
ченного грамматически правильного предложения.
бл
6. Если предложение получилось слишком длинным, перефор-

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

аналога.
Рассмотрим несколько примеров применения этого алгоритма.
Ситуация 1. Тестированию подвергается некое веб-приложение,
поле описания товара должно допускать ввод максимум 250 символов; в
процессе тестирования оказалось, что этого ограничения нет.
1. Суть проблемы: исследование показало, что ни на клиент-
ской, ни на серверной части нет никаких механизмов, проверяющих
и/или ограничивающих длину введённых в поле «О товаре» дан-
ных.
77
2. Исходный вариант подробного описания: в клиентской и сер-
верной части приложения отсутствуют проверка и ограничение
длины данных, вводимых в поле «О товаре» на странице
http://testapplication/admin/goods/edit/.
3. Конечный вариант подробного описания:
 Фактический результат: в описании товара (поле «О то-
варе», http://testapplication/admin/goods/edit/) отсутствуют про-
верка и ограничение длины вводимого текста (максимум 250
символов).
 Ожидаемый результат: в случае попытки ввода более
251 символа выводится сообщение об ошибке.
Р
4. Определение «что, где и при каких условиях случилось»:
 Что: отсутствуют проверка и ограничение длины вводи-
УИ
мого текста.
 Где: описание товара, поле «О товаре»,
http://testapplication/admin/goods/edit/.
 При каких условиях: (в данном случае дефект присут-
5.
БГ
ствует всегда, вне зависимости от каких бы то ни было осо-
бых условий).
Первичная формулировка: отсутствуют проверка и ограниче-
ние максимальной длины текста, вводимого в поле «О товаре»
а
описания товара.
Сокращение (итоговое краткое описание): нет ограничения
ек
6.
максимальной длины поля «О товаре». Английский вариант: no
check for «О товаре» max length.
т
Ситуация 2. Попытка открыть в приложении пустой файл приводит

к краху клиентской части приложения и потере несохранённых пользова-
ио
тельских данных на сервере:

1. Суть проблемы: клиентская часть приложения начинает
«вслепую» читать заголовок файла, не проверяя ни размер, ни
бл
корректность формата, ничего; возникает некая внутренняя ошиб-

ка, и клиентская часть приложения некорректно прекращает рабо-
ту, не закрыв сессию с сервером; сервер закрывает сессию по
Би
тайм-ауту (повторный запуск клиентской части запускает новую

сессию, так что старая сессия и все данные в ней в любом случае
утеряны).
2. Исходный вариант подробного описания: некорректный ана-
лиз открываемого клиентом файла приводит к краху клиента и не-
обратимой утере текущей сессии с сервером.
 Фактический результат: отсутствие проверки корректно-
сти открываемого клиентской частью приложения файла (в
том числе пустого) приводит к краху клиентской части и необ-
78
ратимой потере текущей сессии с сервером (см. BR852345).
 Ожидаемый результат: производится анализ структуры
открываемого файла; в случае обнаружения проблем отоб-
ражается сообщение о невозможности открытия файла.
 Что: крах клиентской части приложения.
 Где: (конкретное место в приложении определить едва
ли возможно).
 При каких условиях: при открытии пустого или повре-
ждённого файла.
5. Первичная формулировка: отсутствие проверки корректности
Р
открываемого файла приводит к краху клиентской части приложе-
ния и потере пользовательских данных.
УИ
6. Сокращение (итоговое краткое описание): крах клиента и по-
теря данных при открытии повреждённых файлов. Английский ва-
риант: client crash and data loss on damaged/empty files opening.
Ситуация 3. Крайне редко по совершенно непонятным причинам
БГ
на сайте нарушается отображение всего русского текста (как статиче-
ских надписей, так и информации из базы данных, генерируемой дина-
мически и т. д. – всё «становится вопросиками»).
1. Суть проблемы: фреймворк, на котором построен сайт, под-
а
гружает специфические шрифты с удалённого сервера; если со-
единение обрывается, нужные шрифты не подгружаются и исполь-
ек
зуются шрифты по умолчанию, в которых нет русских символов.

2. Исходный вариант подробного описания: ошибка загрузки
т
шрифтов с удалённого сервера приводит к использованию локаль-

ных несовместимых с требуемой кодировкой шрифтов.
ио

 Фактический результат: периодическая невозможность
загрузить шрифты с удалённого сервера приводит к исполь-
бл
зованию локальных шрифтов, несовместимых с требуемой

кодировкой.
 Ожидаемый результат: необходимые шрифты подгру-
Би
жаются всегда (или используется локальный источник необ-

ходимых шрифтов).
 Что: используются несовместимые с требуемой коди-
ровкой шрифты.
 Где: (по всему сайту).
 При каких условиях: в случае ошибки соединения с сер-
вером, с которого подгружаются шрифты.
5. Первичная формулировка: периодические сбои внешнего ис-
точника шрифтов приводят к сбою отображения русского текста.
79
6. Сокращение (итоговое краткое описание): неверный показ
русского текста при недоступности внешних шрифтов. Английский
вариант: wrong presentation of Russian text in case of external fonts
inaccessibility.
Для закрепления материала ещё раз представим эти три ситуации
в виде таблицы 3.a.
Таблица 3.a – Проблемные ситуации и формулировки кратких описаний

дефектов
Русский вариант Английский ва-
Ситуация краткого описания риант краткого
Р
описания
Тестированию подвергается Нет ограничения No check for «О
УИ
некое веб-приложение, поле максимальной дли- товаре» max
описания товара должно ны поля «О товаре» length
допускать ввод максимум
250 символов; в процессе
тестирования оказалось, что
этого ограничения нет
Попытка открыть в прило-
жении пустой файл приво-
БГ
Крах клиента и по- Client crash and
теря данных при от- data loss on dam-
а
дит к краху клиентской части крытии повреждён- aged/empty files
приложения и потере несо- ных файлов opening
ек
хранённых пользователь-
ских данных на сервере
Крайне редко по совершен- Неверный показ
т
Wrong presentation
но непонятным причинам на русского текста при of Russian text in
ио
сайте нарушается отобра- недоступности case of external

жение всего русского текста внешних шрифтов fonts inaccessibility
(как статических надписей,
бл
так и данных из базы дан-

ных, генерируемых динами-
чески и т. д. – всё «стано-
Би
вится вопросиками»)
Возвращаемся к рассмотрению полей отчёта о дефекте.

Подробное описание (description) представляет в развёрнутом
виде необходимую информацию о дефекте, а также (обязательно!) опи-
сание фактического результата, ожидаемого результата и ссылку на
требование (если это возможно).
Рассмотрим пример подробного описания:
80
Если в систему входит администратор, на странице привет-
ствия отсутствует логотип.
Фактический результат: логотип отсутствует в левом верхнем
углу страницы.
Ожидаемый результат: логотип отображается в левом верхнем
углу страницы.
Требование: R245.3.23b.
В отличие от краткого описания, которое, как правило, является

одним предложением, здесь можно и нужно давать подробную инфор-
Р
мацию. Если одна и та же проблема (вызванная одним источником) про-
является в нескольких местах приложения, можно в подробном описа-
УИ
нии перечислить эти места.
Шаги по воспроизведению (steps to reproduce, STR) описывают
действия, которые необходимо выполнить для воспроизведения дефек-
та. Это поле похоже на шаги тест-кейса, за исключением одного важного
БГ
отличия: здесь действия прописываются максимально подробно, с ука-
занием конкретных вводимых значений и самых мелких деталей, т. к. от-
сутствие этой информации в сложных случаях может привести к невоз-
можности воспроизведения дефекта.
а
Рассмотрим пример шагов воспроизведения:
ек
1. Открыть http://testapplication/admin/login/.
2. Авторизоваться с именем «defaultadmin» и паролем
«dapassword».
т
ио
Дефект: в левом верхнем углу страницы отсутствует логотип

(вместо него отображается пустое пространство с надписью
«logo»).
бл
Воспроизводимость (reproducibility) показывает, при каждом ли

прохождении по шагам воспроизведения дефекта удаётся вызвать его
Би
проявление. Это поле принимает всего два значения: всегда (always)

или иногда (sometimes).
Можно сказать, что воспроизводимость «иногда» означает, что те-
стировщик не нашёл настоящую причину возникновения дефекта. Это
приводит к серьёзным дополнительным сложностям в работе с дефек-
том:
 Тестировщику нужно потратить много времени на то, чтобы
удостовериться в наличии дефекта (т. к. однократный сбой в рабо-
те приложения мог быть вызван огромным количеством посторон-
них причин).
81
 Разработчику тоже нужно потратить время, чтобы добиться
проявления дефекта и убедиться в его наличии. После внесения
исправлений в приложение разработчик фактически должен пола-
гаться только на свой профессионализм, т. к. даже многократное
прохождение по шагам воспроизведения в таком случае не гаран-
тирует, что дефект был исправлен (возможно, через ещё 10–20 по-
вторений он бы проявился).
 Тестировщику, верифицирующему исправление дефекта и
вовсе остаётся верить разработчику на слово по той же самой при-
чине: даже если он попытается воспроизвести дефект 100 раз и
потом прекратит попытки, может так случиться, что на 101-й раз
Р
дефект всё же воспроизвёлся бы.
Как легко догадаться, такая ситуация является крайне неприятной,
УИ
а потому рекомендуется один раз потратить время на тщательную диа-
гностику проблемы, найти её причину и перевести дефект в разряд вос-
производимых всегда.
Важность (severity) показывает степень ущерба, который наносит-
ся проекту существованием дефекта.
 БГ
В общем случае выделяют следующие градации важности:
Критическая (critical) – существование дефекта приводит к
масштабным последствиям катастрофического характера, напри-
а
мер: потеря данных, раскрытие конфиденциальной информации,
нарушение ключевой функциональности приложения и т. д.
ек
 Высокая (major) – существование дефекта приносит ощути-

мые неудобства многим пользователям в рамках их типичной дея-
т
тельности, например: недоступность вставки из буфера обмена,

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

сценариев работы.
 Средняя (medium) – существование дефекта слабо влияет
бл
на типичные сценарии работы пользователей, и/или существует

обходной путь достижения цели, например: диалоговое окно не за-
крывается автоматически после нажатия кнопок «OK»/«Cancel»,
Би
при распечатке нескольких документов подряд не сохраняется зна-

чение поля «Двусторонняя печать», перепутаны направления сор-
тировок по некоему полю таблицы.
 Низкая (minor) – существование дефекта редко обнаружива-
ется незначительным процентом пользователей и (почти) не влия-
ет на их работу, например: опечатка в глубоко вложенном пункте
меню настроек, некое окно сразу при отображении расположено
неудобно (нужно перетянуть его в удобное место), неточно отоб-
ражается время до завершения операции копирования файлов.
82
Срочность (priority) показывает, как быстро дефект должен быть
устранён.
В общем случае выделяют следующие градации срочности:
 Наивысшая (ASAP, as soon as possible) срочность указывает
на необходимость устранить дефект настолько быстро, насколько
это возможно. В зависимости от контекста «настолько быстро,
насколько возможно» может варьироваться от «в ближайшем бил-
де» до единиц минут.
 Высокая (high) срочность означает, что дефект следует ис-
править вне очереди, т. к. его существование или уже объективно
мешает работе, или начнёт создавать такие помехи в самом бли-
Р
жайшем будущем.
 Обычная (normal) срочность означает, что дефект следует
УИ
исправить в порядке общей очерёдности. Такое значение срочно-
сти получает большинство дефектов.
 Низкая (low) срочность означает, что в обозримом будущем
исправление данного дефекта не окажет существенного влияния
БГ
на повышение качества продукта.
Несколько дополнительных рассуждений о важности и сроч-
ности стоит рассмотреть отдельно.
Один из самых частых вопросов относится к тому, какая между ни-
а
ми связь. Никакой. Для лучшего понимания этого факта можно сравнить
важность и срочность с координатами X и Y точки на плоскости. Хоть
ек
«на бытовом уровне» и кажется, что дефект с высокой важностью сле-

дует исправить в первую очередь, в реальности ситуация может выгля-
т
деть совсем иначе.

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

примеры приведены, а для разных степеней срочности – нет? И это не
случайно.
бл
Зная суть проекта и суть дефекта, его важность определить доста-

точно легко, т. к. мы можем проследить влияние дефекта на критерии
качества, степень выполнения требований той или иной важности и т. д.
Би
Но срочность исправления дефекта можно определить только в кон-

кретной ситуации.
Поясним на жизненном примере: насколько для жизни человека
важна вода? Очень важна, без воды человек умирает. Значит, важность
воды для человека можно оценить как критическую. Но можем ли мы от-
ветить на вопрос «Как быстро человеку нужно выпить воды?», не зная, о
какой ситуации идёт речь? Если рассматриваемый человек умирает от
жажды в пустыне, срочность будет наивысшей. Если он просто сидит в
офисе и думает, не попить ли чая, срочность будет обычной или даже
низкой.
83
Вернёмся к примерам из разработки программного обеспечения и
покажем четыре случая сочетания важности и срочности в таблице 3.b.
Таблица 3.b – Примеры сочетания важности и срочности дефектов

Важность
Срочность
Критическая Низкая
Проблемы с безопасно- На корпоративном сайте
Наивысшая стью во введённом в экс- повредилась картинка с
плуатацию банковском ПО фирменным логотипом
В самом начале разработ- В руководстве пользова-
ки проекта обнаружена си- теля обнаружено не-
Р
туация, при которой могут сколько опечаток, не
Низкая
быть повреждены или во- влияющих на смысл тек-
УИ
все утеряны пользова- ста
тельские данные
Симптом (symptom) – позволяет классифицировать дефекты по
БГ
их типичному проявлению. Не существует никакого общепринятого спис-
ка симптомов. Более того, далеко не в каждом инструментальном сред-
стве управления отчётами о дефектах есть такое поле, а там, где оно
есть, его можно настроить. В качестве примера рассмотрим следующие
а
значения симптомов дефекта:
 Косметический дефект (cosmetic flaw) – визуально заметный
ек
недостаток интерфейса, не влияющий на функциональность при-

ложения (например, надпись на кнопке выполнена шрифтом не той
гарнитуры).
т
 Повреждение/потеря данных (data corruption/loss) – в ре-

ио
зультате возникновения дефекта искажаются, уничтожаются (или

не сохраняются) некоторые данные (например, при копировании
файлов копии оказываются повреждёнными).
бл
 Проблема в документации (documentation issue) – дефект

относится не к приложению, а к документации (например, отсут-
ствует раздел руководства по эксплуатации).
Би
 Некорректная операция (incorrect operation) – некоторая

операция выполняется некорректно (например, калькулятор пока-
зывает ответ 17 при умножении 2 на 3).
 Проблема инсталляции (installation problem) – дефект про-
является на стадии установки и/или конфигурирования приложе-
ния.
 Ошибка локализации (localization issue) – что-то в приложе-
нии не переведено или переведено неверно на выбранный язык
интерфейса.
 Нереализованная функциональность (missing feature) –
84
некая функция приложения не выполняется или не может быть вы-
звана (например, в списке форматов для экспорта документа от-
сутствует несколько пунктов, которые там должны быть).
 Проблема масштабируемости (scalability) – при увеличении
количества доступных приложению ресурсов не происходит ожи-
даемого прироста производительности приложения).
 Низкая производительность (slow performance) – выполне-
ние неких операций занимает недопустимо большое время.
 Крах системы (system crash) – приложение прекращает ра-
боту или теряет способность выполнять свои ключевые функции
(также может сопровождаться крахом операционной системы, веб-
Р
сервера и т. д.).
 Неожиданное поведение (unexpected behavior) – в процессе
УИ
выполнения некоторой типичной операции приложение ведёт себя
необычным (отличным от общепринятого) образом (например, по-
сле добавления в список новой записи активной становится не но-
вая запись, а первая в списке).

БГ
Недружественное поведение (unfriendly behavior) – поведе-
ние приложения создаёт пользователю неудобства в работе
(например, на разных диалоговых окнах в разном порядке распо-
ложены кнопки «OK» и «Cancel»).
а
 Расхождение с требованиями (variance from specs) – этот
ек
симптом указывают, если дефект сложно соотнести с другими

симптомами, но тем не менее приложение ведёт себя не так, как
описано в требованиях.
т
 Предложение по улучшению (enhancement) – во многих ин-

струментальных средствах управления отчётами о дефектах для
ио
этого случая есть отдельный вид отчёта, т. к. предложение по

улучшению формально нельзя считать дефектом: приложение ве-
дёт себя согласно требованиям, но у тестировщика есть обосно-
бл
ванное мнение о том, как ту или иную функциональность можно

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

часто ведёт к потере или повреждению данных. Но в большинстве ин-
струментальных средств управления отчётами о дефектах значение по-
ля «Симптом» выбирается из списка, и потому нет возможности указать
два и более симптома одного дефекта. В такой ситуации рекомендуется
выбирать либо симптом, который лучше всего описывает суть ситуации,
либо «наиболее опасный» симптом (например, недружественное пове-
дение, состоящее в том, что приложение не запрашивает подтвержде-
ния перезаписи существующего файла, приводит к потере данных; здесь
«потеря данных» куда уместнее, чем «недружественное поведение»).
85
Возможность обойти (workaround) – показывает, существует ли
альтернативная последовательность действий, выполнение которой позво-
лило бы пользователю достичь поставленной цели (например, клавиатур-
ная комбинация Ctrl+P не работает, но распечатать документ можно, вы-
брав соответствующие пункты в меню). В некоторых инструментальных
средствах управления отчётами о дефектах это поле может просто прини-
мать значения «Да» и «Нет», в некоторых при выборе «Да» появляется
возможность описать обходной путь. Традиционно считается, что дефектам
без возможности обхода стоит повысить срочность исправления.
Комментарий (comments, additional info) – может содержать любые
полезные для понимания и исправления дефекта данные. Иными сло-
Р
вами, сюда можно писать всё то, что нельзя писать в остальные поля.
Приложения (attachments) – представляет собой не столько поле,
УИ
сколько список прикреплённых к отчёту о дефекте приложений (копий
экрана, вызывающих сбой файлов и т. д.)
Общие рекомендации по формированию приложений таковы:
 Если вы сомневаетесь, делать или не делать приложение,
лучше сделайте.

БГ
Обязательно прилагайте так называемые «проблемные ар-
тефакты» (например, файлы, которые приложение обрабатывает
некорректно).
а
 Если вы прилагаете копию экрана:
o Чаще всего вам будет нужна копия активного окна
ек
(Alt+PrintScreen), а не всего экрана (PrintScreen).

o Обрежьте всё лишее (используйте Snipping Tool или
т
Paint в Windows, Pinta или XPaint в Linux).

o Отметьте на копии экрана проблемные места (обведите,
ио
нарисуйте стрелку, добавьте надпись – сделайте всё необхо-

димое, чтобы с первого взгляда проблема была заметна и
понятна).
бл
o В некоторых случаях стоит сделать одно большое изоб-

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

скольких копий экрана, названных так, чтобы имена образо-
вывали последовательность, например: br_9_sc_01.png,
br_9_sc_02.png, br_9_sc_03.png.
o Сохраните копию экрана в формате JPG (если важна
экономия объёма данных) или PNG (если важна точная пере-
дача картинки без искажений).
 Если вы прилагаете видеоролик с записью происходящего на
экране, обязательно оставляйте только тот фрагмент, который от-
носится к описываемому дефекту (это будет буквально несколько
86
секунд или минут из возможных многих часов записи). Старайтесь
подобрать настройки кодеков так, чтобы получить минимальный
размер ролика при сохранении достаточного качества изображения.
 Поэкспериментируйте с различными инструментами создания
копий экрана и записи видеороликов с происходящим на экране.
Выберите наиболе удобное для вас программое обеспечение и
приучите себя постоянно его использовать.
3.4 Свойства качественных отчётов о дефектах
Отчёт о дефекте может оказаться некачественным (а следова-

тельно, вероятность исправления дефекта понизится), если в нём нару-
Р
шено одно из следующих свойств.
УИ
Тщательное заполнение всех полей точной и корректной ин-
формацией. Нарушение этого свойства происходит по множеству причин:
недостаточный опыт тестировщика, невнимательность, лень и т. д. Самы-
ми яркими проявлениями такой проблемы можно считать следующие:

БГ
Часть важных для понимания проблемы полей не заполнена.
В результате отчёт превращается в набор обрывочных сведений,
использовать которые для исправления дефекта невозможно.
 Предоставленной информации недостаточно для понимания
а
сути проблемы. Например, из такого плохого подробного описания
вообще не ясно, о чём идёт речь: «Приложение иногда неверно
ек
конвертирует некоторые файлы».

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

ио
внимательности (последствия ошибочного copy-paste и отсутствия

финальной вычитки отчёта перед публикацией).
 «Дефект» (именно так, в кавычках) найден в функционально-
бл
сти, которая ещё не была объявлена как готовая к тестированию.

То есть тестировщик констатирует, что неверно работает то, что и
не должно было (пока!) верно работать.

Би
В отчёте присутствует жаргонная лексика: как в прямом

смысле – нелитературные высказывания, так и некие технические
жаргонизмы, понятные крайне ограниченному кругу людей. Напри-
мер: «Фигово подцепились чартники». (Имелось в виду: «Не все
таблицы кодировок загружены успешно».)
 Отчёт вместо описания проблемы с приложением критикует
работу кого-то из участников проектной команды. Например: «Ну
каким дураком надо быть, чтобы такое сделать?!»
 В отчёте упущена некая незначительная на первый взгляд, но по
факту критичная для воспроизведения дефекта проблема. Чаще все-
87
го это проявляется в виде пропуска какого-то шага по воспроизведе-
нию, отсутствию или недостаточной подробности описания окруже-
ния, чрезмерно обобщённом указании вводимых значений и т. п.
 Отчёту выставлены неверные (как правило, заниженные)
важность или срочность. Чтобы избежать этой проблемы, стоит
тщательно исследовать дефект, определять его наиболее опасные
последствия и аргументированно отстаивать свою точку зрения,
если коллеги считают иначе.
 К отчёту не приложены необходимые копии экрана (особенно
важные для косметических дефектов) или иные файлы. Классика
такой ошибки: отчёт описывает неверную работу приложения с не-
Р
которым файлом, но сам файл не приложен.
 Отчёт написан безграмотно с точки зрения человеческого
УИ
языка. Иногда на это можно закрыть глаза, но иногда это становит-
ся реальной проблемой, например: «Not keyboard in parameters ac-
cepting values» (это реальная цитата; и сам автор так и не смог по-
яснить, что же имелось в виду).
БГ
Правильный технический язык. Это свойство в равной мере от-
носится и к требованиям, и к тест-кейсам, и к отчётам о дефектах – к
любой документации, а потому не будем повторяться – см. описанное
ранее в подразделе 2.1.
а
Сравните два подробных описания дефекта (таблица 3.с).
ек
Таблица 3.с – Сравнение описания дефектов

Плохое подробное Хорошее подробное описание
описание
т
Когда мы как будто бы хо- Не производится запрос подтверждения

ио
тим убрать папку, где что-то при удалении непустого подкаталога в

внутри есть, оно не спраши- каталоге SOURCE_DIR.
вает, хотим ли мы Act: производится удаление непустого
бл
подкаталога (со всем его содержимым)

в каталоге SOURCE_DIR без запроса
подтверждения.
Би
Exp: в случае, если в каталоге

SOURCE_DIR приложение обнаружива-
ет непустой подкаталог, оно прекраща-
ет работу с выводом сообщения «Non-
empty subfolder [имя подкаталога] in
SOURCE_DIR folder detected. Remove it
manually or restart application with --
force_file_operations key to remove auto-
matically.»
Req: UR.56.BF.4.c
88
Специфичность описания шагов. Говоря о тест-кейсах, мы под-
чёркивали, что в их шагах стоит придерживаться золотой середины
между специфичностью и общностью. В отчётах о дефектах предпочте-
ние, как правило, отдаётся специфичности по очень простой причине:
нехватка какой-то мелкой детали может привести к невозможности вос-
произведения дефекта. Потому, если у вас есть хоть малейшее сомне-
ние в том, важна ли какая-то деталь, считайте, что она важна.
Сравните два набора шагов по воспроизведению дефекта (табли-
ца 3.d).
Таблица 3.d – Воспроизведение описания дефектов
Р
Недостаточно специфич- Достаточно специфичные шаги
ные шаги
УИ
1. Отправить на конвер- 1. Отправить на конвертацию
тацию файл допустимого файл в формате HTML размером
формата и размера, в ко- от 100 КБ до 1 МБ, в котором рус-
тором русский текст пред- ский текст представлен в кодиров-
ставлен в разных кодиров-
ках.
Дефект: конвертация ко-

БГ
ках UTF8 (10 строк по 100 симво-
лов) и WIN-1251 (20 строк по 100
символов).
Дефект: текст, который был пред-
а
дировок производится не- ставлен в UTF8, повреждён (пред-
верно ставлен нечитаемым набором
ек
символов)
В первом случае воспроизвести дефект практически нереально,

т
т. к. он заключается в особенностях работы внешних библиотек по опре-

ио
делению кодировок текста в документе, в то время как во втором случае

данных достаточно если и не для понимания сути происходящего (де-
фект на самом деле очень «хитрый»), то хотя бы для гарантированного
бл
воспроизведения и признания факта его наличия.

Ещё раз главная мысль: в отличие от тест-кейса отчёт о дефекте
может обладать повышенной специфичностью, и это будет меньшей
Би
проблемой, чем невозможность воспроизведения дефекта из-за из-

лишне обобщённого описания проблемы.
Отсутствие лишних действий и/или их длинных описаний. Ча-
ще всего это свойство подразумевает, что не нужно в шагах по воспро-
изведению дефекта долго и по пунктам расписывать то, что можно за-
менить одной фразой (таблица 3.e).
89
Таблица 3.e – Лишние действия в описании дефектов
1. Указать в качестве первого 1. Запустить приложение со
параметра приложения путь к всеми тремя корректными па-
папке с исходными файлами. раметрами (особенно обратить
2. Указать в качестве второго внимание, чтобы SOURCE_DIR
параметра приложения путь к и DESTINATION_DIR не совпа-
папке с конечными файлами. дали и не были вложены друг в
3. Указать в качестве третье- друга в любом сочетании).
го параметра приложения
путь к файлу журнала. Дефект: приложение прекра-
Р
4. Запустить приложение. щает работу с сообщением
«SOURCE_DIR and DESTINA-
УИ
Дефект: приложение исполь- TION_DIR may not be the
зует первый параметр ко- same!» (судя по всему, первый
мандной строки и как путь к параметр командной строки
папке с исходными файлами, используется для инициализа-
и как путь к папке с конечными
файлами
БГ
ции имён обоих каталогов.)
Вторая по частоте ошибка – начало каждого отчёта о дефекте с

а
запуска приложения и подробного описания по приведению его в то или
иное состояние. Вполне допустимой практикой является написание в от-
ек
чёте о дефекте приготовлений (по аналогии с тест-кейсами) или описа-

ние нужного состояния приложения в одном (первом) шаге.
Сравните ошибки в описании дефектов по таблице 3.f.
т
ио
Таблица 3.f – Ошибки в описании дефектов

1. Запустить приложение со Предусловие: приложение запу-
бл
всеми верными параметрами. щено и проработало более 30

2. Подождать более 30 мин. мин.
3. Передать на конвертацию 1. Передать на конвертацию
Би
файл допустимого формата и файл допустимого формата и

размера. размера.
Дефект: приложение не обра- Дефект: приложение не обра-

батывает файл батывает файл
Отсутствие дубликатов. Когда в проектной команде работает

большое количество тестировщиков, может возникнуть ситуация, при ко-
торой один и тот же дефект будет описан несколько раз разными людь-
90
ми. А иногда бывает так, что даже один и тот же тестировщик уже забыл,
что когда-то давно уже обнаруживал некую проблему, и теперь описы-
вает её заново. Избежать подобной ситуации позволяет следующий
набор рекомендаций:
 Если вы не уверены, что дефект не был описан ранее, произ-
ведите поиск с помощью вашего инструментального средства
управления жизненным циклом отчётов о дефектах.
 Пишите максимально информативные краткие описания (т. к.
поиск в первую очередь проводят по ним). Если на вашем проекте
накопится множество дефектов с краткими описаниями в стиле
«Кнопка не работает», вы потратите очень много времени, раз за
Р
разом перебирая десятки таких отчётов в поисках нужной инфор-
мации.
УИ
 Используйте по максимуму возможности вашего инструмен-
тального средства: указывайте в отчёте о дефекте компоненты
приложения, ссылки на требования, расставляйте теги и т. д. –
всё это позволит легко и быстро сузить в будущем круг поиска.

БГ
Указывайте в подробном описании дефекта текст сообщений
от приложения, если это возможно. По такому тексту можно найти
даже тот отчёт, в котором остальная информация приведена в
слишком общем виде.
а
 Старайтесь по возможности участвовать в так называемых
«собраниях по прояснению» (clarification meetings89), т. к. пусть вы и
ек
не запомните каждый дефект или каждую пользовательскую исто-

рию дословно, но в нужный момент может возникнуть ощущение
т
«что-то такое я уже слышал», которое заставит вас произвести по-

иск и подскажет, что именно искать.
ио
 Если вы обнаружили какую-то дополнительную информацию,

внесите её в уже существующий отчёт о дефекте (или попросите
сделать это его автора), но не создавайте отдельный отчёт.
бл
Очевидность и понятность. Описывайте дефект так, чтобы у чи-

тающего ваш отчёт не возникло ни малейшего сомнения в том, что это
действительно дефект. Лучше всего это свойство достигается за счёт
Би
тщательного объяснения фактического и ожидаемого результата, а так-

же указания ссылки на требование в поле «Подробное описание».
Сравните описание дефектов по таблице 3.g.
89
Clarification meeting. A discussion that helps the customers achieve “advance clarity” –
consensus on the desired behavior of each story – by asking questions and getting examples.
Crispin L., Gregory J. Agile Testing.
91
Таблица 3.g – Очевидность и понятность в описании дефектов
Плохое подробное описание Хорошее подробное описание
Приложение не сообщает об Приложение не уведомляет поль-
обнаруженных подкаталогах в зователя об обнаруженных в ката-
каталоге SOURCE_DIR логе SOURCE_DIR подкаталогах,
что приводит к необоснованным
ожиданиям пользователями обра-
ботки файлов в таких подкатало-
гах.
Act: приложение начинает (про-
должает) работу, если в каталоге
Р
SOURCE_DIR находятся подката-
логи.
УИ
Exp: в случае если в каталоге
SOURCE_DIR приложение при за-
пуске или в процессе работы об-
наруживает пустой подкаталог,
БГ
оно автоматически его удаляет
(логично ли это?), если же обна-
ружен непустой подкаталог, при-
ложение прекращает работу с вы-
а
водом сообщения «Non-empty sub-
folder [имя подкаталога] in
ек
SOURCE_DIR folder detected. Re-

move it manually or restart applica-
т
tion with --force_file_operations key

to remove automatically.»
ио
Req: UR.56.BF.4.c
В первом случае после прочтения подробного описания очень хо-

бл
чется спросить: «И что? А оно разве должно уведомлять?» Второй же

вариант подробного описания даёт чёткое пояснение, что такое поведе-
ние является ошибочным согласно текущему варианту требований. Бо-
Би
лее того, во втором варианте отмечен вопрос (а в идеале нужно сделать

соответствующую отметку и в самом требовании), призывающий пере-
смотреть алгоритм корректного поведения приложения в подобной ситу-
ации: т. е. мы не только качественно описываем текущую проблему, но и
поднимаем вопрос о дальнейшем улучшении приложения.
Прослеживаемость. Из содержащейся в качественном отчёте о
дефекте информации должно быть понятно, какую часть приложения,
какие функции и какие требования затрагивает дефект. Лучше всего это
свойство достигается правильным использованием возможностей ин-
струментального средства управления отчётами о дефектах: указывайте
92
в отчёте о дефекте компоненты приложения, ссылки на требования,
тест-кейсы, смежные отчёты о дефектах (похожих дефектах; зависимых
и зависящих от данного дефектах), расставляйте теги и т. д.
Некоторые инструментальные средства даже позволяют строить
визуальные схемы на основе таких данных, что позволяет управление
прослеживаемостью даже на очень больших проектах превратить из не-
посильной для человека задачи в тривиальную работу.
Отдельные отчёты для каждого нового дефекта. Существует
два незыблемых правила:
 В каждом отчёте описывается ровно один дефект (если один
и тот же дефект проявляется в нескольких местах, эти проявления
Р
перечисляются в подробном описании).
 При обнаружении нового дефекта создаётся новый отчёт.
УИ
Нельзя для описания нового дефекта править старые отчёты, пе-
реводя их в состояние «открыт заново».
Нарушение первого правила приводит к объективной путанице, ко-
торую проще всего проиллюстрировать так: представьте, что в одном
БГ
отчёте описано два дефекта, один из которых был исправлен, а второй –
нет. В какое состояние переводить отчёт? Неизвестно.
Нарушение второго правила вообще порождает хаос: мало того,
что теряется информация о ранее возникавших дефектах, так к тому же
а
возникают проблемы со всевозможными метриками и банальным здра-
вым смыслом. Именно во избежание этой проблемы на многих проектах
ек
правом перевода отчёта из состояния «закрыт» в состояние «открыт за-

ново» обладает ограниченный круг участников команды.
Соответствие принятым шаблонам оформления и традициям.
т
Как и в случае с тест-кейсами, с шаблонами оформления отчётов о де-

ио
фектах проблем не возникает: они определены имеющимся образцом

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

единственный совет: почитайте уже готовые отчёты о дефектах, перед
тем как писать свои. Это может сэкономить вам много времени и сил.
Би
 Дайте определение понятия «дефект».

 Что такое отчёт о дефекте?
 Назовите атрибуты отчёта о дефекте.
 Что должно быть приведено в подробном описании дефекта?
 Перечислите и опишите этапы жизненного цикла дефекта.
 Перечислите основные симптомы дефектов.
93
 Какие рекомендации по написанию хороших отчётов о дефектах
вы знаете?
 Каковы преимущества хорошего отчёта о дефекте?
 В чём различие важности и срочности дефекта?
 Приведите несколько примеров отчётов о дефектах не из ИТ-
сферы и из ИТ-сферы.
 Какова стандартная периодичность выпуска отчёта о результа-
тах тестирования? Чем она может определяться?
 Зачем и кому нужен отчёт о результатах тестирования?
 Что такое баг-трэкинговая система и для чего она нужна?
 Каковы цели написания отчёта о результатах тестирования?
Р
УИ
БГ
а
т ек
ио
бл
Би
94
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1. Ammann, P. Introduction to Software Testing. Chapter 4. Input Space

Partition Testing / P. Ammann, J. Offut. – Saarbrücken : LAP Lambert
Academic Publishing, 2012. – 56 p.
2. Barker, T. T. Documentation for software and IS development. Encyclo-
pedia of Information Systems / T. T. Barker. – Amsterdam : Elsevier
Press, 2002. – Р. 679–680.
3. Barker, T. T. Writing Software Documentation: A Task-Oriented Ap-
Р
proach (Part of the Allyn & Bacon Series in Technical Communication) /
T. T. Barker. – 2nd еd. – Harlow : Longman Publishing Group, 2002. –
УИ
496 p.
4. Documenting Software Architectures / P. Clements [et al.]. – Boston :
Addison-Wesley Professional, 2003. – 512 p.
БГ
5. Copeland, L. A practitioner’s guide to software test design /
L. Copeland. – Norwood : Artech House, 2004. – 300 p.
6. Crispin, L. Agile Testing / L. Crispin, J. Gregory. – Boston : Addison-
Wesley, 2009. – 533 p.
а
7. Hass, A. M. Guide to Advanced Software Testing / A. M. Hass. –
ек
2nd еd. – Norwood : Artech House Publishers, 2014.– 482 p.

8. Jyoti, J. M. Software Testing and Quality Assurance / J. M. Jyoti,
S. T. Bhavana. – Hoboken : John Wiley & Sons, Inc., 2005. – 441 p.
т
9. Kerzner, H. Project Management: A Systems Approach to Planning,

ио
Scheduling, and Controlling / H. Kerzner. – Hoboken : Wiley, 2013. –

1296 p.
10. Nageshwar, R. P. Software Testing Concepts And Tools /
бл
R. P. Nageshwar. – M. : Dreamtech, 2006. – 492 р.

11. Ауэр, К. Экстремальное программирование: постановка процесса.
С первых шагов и до победного конца. Сер. Библиотека програм-
Би
миста / К. Ауэр, Р. Миллер. – СПб. : Питер, 2004. – 368 с.

12. Бейзер, Б. Тестирование черного ящика. Технологии функцио-
нального тестирования ПО. Сер. Библиотека программиста /
Б. Бейзер. – СПб. : Питер, 2004. – 320 с.
13. Бек, К. Экстремальное программирование: разработка через те-
стирование. Сер. Библиотека программиста / К. Бек. – СПб. :
Питер, 2003. – 224 с.
95
14. Блэк, Р. Ключевые процессы тестирования. Планирование, под-
готовка, проведение, совершенствование / Р. Блэк. – М. : Лори,
2011. – 544 с.
15. Браун, К. Быстрое тестирование / К. Браун, Р. Калбертсон,
Г. Кобб. – М. : Вильямс, 2002. – 384 с.
16. Вигерс, К. Разработка требований к программному обеспечению
(Software Requirements, Third Ed.) / К. Вигерс, Д. Битти. –
3-е изд. – M. : Русская редакция, 2014. – 737 c.
17. Дастин, Э. Автоматизированное тестирование программного
обеспечения / Э. Дастин, Д. Рэшка. – М. : Лори, 2005. – 592 с.
Р
18. Канер, С. Тестирование программного обеспечения. Фундамен-
УИ
тальные концепции менеджмента бизнес-приложений / С. Ка-
нер, Д. Фолк, Е. К. Нгуен. – Ярославль : ДиаСофт, 2001. – 538 с.
19. Котляров, В. П. Основы тестирования программного обеспече-
ния / В. П. Котляров. – М. : Интернет-университет информаци-
БГ
онных технологий ИНТУИТ.ру, 2006. – 285 с.
20. Майерс, Г. Искусство тестирования программ / Г. Майерс,
Т. Баджетт, К. Сандлер. – 3-е изд. – М. : Вильямс, 2012. – 272 с.
21. Макгрегор, Д. Тестирование объектно-ориентированного про-
а
граммного обеспечения : практ. пособие / Д. Макгрегор,
ек
Д. Сайкс. – Ярославль : Диасофт, 2002. – 432 с.

22. Макконнелл, С. Совершенный код. Русская редакция. Сер. Ма-
т
стер-класс / С. Макконнелл. – 2-е изд. – СПб. : Питер, 2005. –

896 с.
ио
23. Роббинс, Д. Отладка приложений. Сер. Мастер / Д. Роббинс. –

СПб. : BHV, 2001. – 512 с.
бл
24. Савин, Р. Тестирование Дот Ком, или Пособие по жестокому

обращению с багами в интернет-стартапах / Р. Савин. – М. : Де-
ло, 2007. – 312 с.
Би
25. Стотлемайер, Д. Тестирование Web-приложений / Д. Стотле-

майер. – М. : Кудиц-образ, 2003. – 240 с.
26. Тамре, Л. Введение в тестирование программного обеспечения
/ Л. Тамре. – М. : Вильямс, 2003. – 359 с.
27. Торрес, Дж. Практическое руководство по проектированию и
разработке пользовательского интерфейса / Дж. Торрес. – М. :
Вильямс, 2003. – 400 с.
96
28. Beginner’s Guide to Mobile Application Testing [Электронный ре-
сурс]. – 2016. – Режим доступа :
http://www.softwaretestinghelp.com/beginners-guide-to-mobile-
application-testing/.
29. Project Lifecycle Models: How They Differ and When to Use Them
[Электронный ресурс]. – 2002. – Режим доступа :
http://www.business-esolutions. com/islm.htm.
30. Smoke testing and sanity testing – Quick and simple differences
Р
http://www.softwaretestinghelp.com/smoke-testing-and-sanity-
testing-difference/.
УИ
31. Westfall, L. Software Requirements Engineering: What, Why, Who,
When, and How / L. Westfall [Электронный ресурс]. – 2015. –
Режим доступа : http://www.westfallteam.com/Papers/The_Why_
What_Who_When_and_How_Of_Software_Requirements.pdf.
БГ
32. Блок-схема выбора оптимальной методологии разработки ПО
http://megamozg.ru/post/23022/.
33. Blain, T. Writing Good Requirements – The Big Ten Rules /
а
T. Blain [Электронный ресурс]. – 2006. – Режим доступа :
http://tynerblain.com/blog/2006/05/25/writing-good-requirements-
ек
the-big-ten-rules/.
34. Boehm, B. A Spiral Model of Software Development and En-
hancement / B. Boehm [Электронный ресурс]. – 1988. – Режим
т
доступа : http://csse.usc.edu/csse/TECHRPTS/1988/usccse88-
ио
500/usccse88-500.pdf.
35. Boehm, B. Spiral Development: Experience, Principles, and Re-
finements / B. Boehm [Электронный ресурс]. – 1988. – Режим
бл
доступа : http://www.sei.cmu.edu/reports/00sr008.pdf.
36. Brandenburg, L. Requirements Gathering vs. Elicitation / L. Bran-
denburg [Электронный ресурс]. – 2006. – Режим доступа :
Би
http://www.bridging-the-gap.com/requirements-gathering-vs-
elicitation/.
37. Cohen, J. Best Kept Secrets of Peer Code Review (Modern Ap-
proach. Practical Advice.) / J. Cohen [Электронный ресурс]. –
2013. – Режим доступа :
http://smartbear.com/SmartBear/media/pdfs/best-kept-secrets-of-
peer-code-review.pdf.
38. Cross-Browser Testing – Overview [Электронный ресурс]. –
2016. – Режим доступа : http://support.smartbear.com
/viewarticle/55299/.
97
39. Firesmith, D. Using V Models for Testing / D. Firesmith [Электрон-
ный ресурс]. – 2013. – Режим доступа :
http://blog.sei.cmu.edu/post.cfm/using-v-models-testing-315.
40. Gelperin, D. The Growth of Software Testing / D. Gelperin,
B. Hetzel [Электронный ресурс]. – 1988. – Режим доступа :
http://www.clearspecs.com/downloads/ClearSpecs16V01_GrowthO
fSoftwareTest.pdf.
41. Ghahrai, A. Spiral Model / A. Ghahrai [Электронный ресурс]. –
2002. – Режим доступа : http://www.testingexcellence.com/spiral-
model/.
42. Hanks, B. Requirements in the Real World / B. Hanks [Электрон-
Р
https://classes.soe.ucsc.edu/cmps109/Winter02/notes/requirement
УИ
sLecture.pdf.
43. Kaner, C. A Tutorial in Exploratory Testing / C. Kaner [Электрон-
http://www.kaner.com/pdfs/QAIExploring.pdf.
[Электронный ресурс]. –
БГ
44. Kaner, C. An Introduction to Scenario Testing / C. Kaner
2003. – Режим
доступа
45. Kuijt, R. Extended Use Case Test Design Pattern / R. Kuijt [Элек-
:
а
тронный ресурс]. – 2013. – Режим доступа :
http://www.softwaretestingclass.com/positive-and-negative-testing-
ек
in-software-testing/.
46. Meerts, J. The History of Software Testing / J. Meerts [Электрон-
ный ресурс]. – Режим доступа
т
:
http://www.testingreferences.com/testinghistory.php.
ио
47. Rangaiah, J. Behaviour driven testing an introduction / J. Rangaiah

http://www.womentesters.com/behaviour-driven-testing-an-
бл
introduction/.
48. Rouse, M. Gray box testing (gray box) definition / M. Rouse [Элек-
тронный ресурс]. – 2013. – Режим доступа :
Би
http://searchsoftwarequality.techtarget.com/definition/gray-box.
49. SmartBear TestComplete user manual [Электронный ресурс]. –
2016. – Режим доступа : http://support.smartbear.com/
viewarticle/55004/.
50. What are Alpha, Beta and Gamma Testing? [Электронный ре-
сурс]. – 2012. – Режим доступа : http://www.360logica.com/blog/
2012/06/what-are-alpha-beta-and-gamma-testing.htm.
51. Whittaker, J. The 7th Plague and Beyond / J. Whittaker [Электрон-
http://googletesting.blogspot.com/2009/09/7th-plague-and-
beyond.html.
98
52. Whittaker, J. The Plague of Amnesia / J. Whittaker [Электронный
ресурс]. – 2009. – Режим доступа :
http://googletesting.blogspot.com/2009/07/plague-of-amnesia.html.
53. Whittaker, J. The Plague of Blindness / J. Whittaker [Электронный
http://googletesting.blogspot.com/2009/07/plague-of-blindness.html.
54. Whittaker, J. The Plague of Boredom / J. Whittaker [Электронный
http://googletesting.blogspot.com/2009/07/plague-of-boredom.html.
55. Whittaker, J. The Plague of Entropy / J. Whittaker [Электронный
Р
http://googletesting.blogspot.com/2009/09/plague-of-entropy.html.
56. Whittaker, J. The Plague of Homelessness / J. Whittaker [Элек-
УИ
тронный ресурс]. – 2009. – Режим доступа : http://googletesting.
blogspot.com/2009/07/plague-of-homelessness.html.
57. Whittaker, J. The plague of repetitiveness / J. Whittaker [Электрон-
БГ
http://googletesting.blogspot.com/2009/06/by-james.html.
58. Kelly, M. The ROI of Test Automation / M. Kelly [Электронный ре-
сурс]. – 1999. – Режим доступа : http://www.sqetraining.com/sites/
а
default/files/articles/XDD8502filelistfilename1_0.pdf.
59. The Return of Investment (ROI) of Test Automation / S. Münch
ек
[еt al.] [Электронный ресурс]. – 2012. – Режим доступа :

https://www.ispe.org/pe-ja/roi-of-test-automation.pdf.
60. Rooney, J. Root Cause Analysis for Beginners / J. Rooney,
т
L. V. Heuvel [Электронный ресурс]. – 2012. – Режим доступа :

ио
https://www.env.nm.gov/aqb/Proposed_Regs/Part_7_Excess_Emiss
ions/NMED_Exhibit_18-Root_Cause_Analysis_for_Beginners.pdf.
61. Garrett, T. Implementing Automated Software Testing – Continuous-
бл
ly Track Progress and Adjust Accordingly / T. Garrett [Электронный

ресурс]. – 2009. – Режим доступа : http://www.methodsandtools.
com/archive/archive.php?id=94.
Би
62. Patel, N. Test Case Point Analysis / N. Patel [Электронный

ресурс]. – 2001. – Режим доступа : http://www.stickyminds.com/
sites/default/files/article/file/2013/XUS373692file1_0.pdf.
63. Sherwood, G. On the Construction of Orthogonal Arrays and Cover-
ing Arrays Using Permutation Groups / G. Sherwood [Электронный
ресурс]. – 2002. – Режим доступа : http://testcover.com/pub/
background/cover.htm.
64. Bolton, M. Pairwise Testing / M. Bolton [Электронный ресурс]. –
2002. – Режим доступа : http://www.developsense.com/
pairwiseTesting.html.
99
65. Kuo-Chung, T. A Test Generation Strategy for Pairwise Testing /
T. Kuo-Chung, L. Yu [Электронный ресурс]. – 2002. – Режим
доступа : http://www.cs.umd.edu/class/spring2003/cmsc838p/
VandV/pairwise.pdf.
66. An Improved Test Generation Algorithm for Pair-Wise Testing / S.
Maity [еt al.] [Электронный ресурс]. – 2003. – Режим доступа :
http://www.iiserpune.ac.in/~soumen/115-FA-2003.pdf.
67. Nageswaran, S. Test Effort Estimation Using Use Case Points / S.
Nageswaran [Электронный ресурс]. – 2001. – Режим доступа :
http://www.bfpug.com.br/Artigos/UCP/Nageswaran-Test_Effort_
Estimation_Using_UCP.pdf.
Р
68. Software Estimation Techniques – Common Test Estimation
Techniques used in SDLC [Электронный ресурс]. – 2013. –
УИ
Режим доступа : http://www.softwaretestingclass.com/software-
estimation-techniques/.
69. Important Software Test Metrics and Measurements – Explained
with Examples and Graphs [Электронный ресурс]. – 2016. –
БГ
Режим доступа : [http://www.softwaretestinghelp.com/software-
test-metrics-and-measurements/.
а
т ек
ио
бл
Би
100
Св. план 2017, поз. 25
Учебное издание
Куликов Святослав Святославович
Р
Данилова Галина Владимировна
УИ
ТЕСТИРОВАНИЕ
ВЕБ-ОРИЕНТИРОВАННЫХ ПРИЛОЖЕНИЙБГ
а
УЧЕБНО-МЕТОДИЧЕСКОЕ ПОСОБИЕ
т ек
ио
Редактор Е. И. Герман
Корректор Е. Н. Батурчик
Компьютерная правка, оригинал-макет В. М. Задоля
бл
Би
Подписано в печать 12.10.2017. Формат 60×84 1/16. Бумага офсетная. Гарнитура «Ариал».
Отпечатано на ризографе. Усл. печ. л. 6,05. Уч.-изд. л. 5,0. Тираж 100 экз. Заказ 82.
Издатель и полиграфическое исполнение: учреждение образования

«Белорусский государственный университет информатики и радиоэлектроники».
Свидетельство о государственной регистрации издателя, изготовителя,
распространителя печатных изданий №1/238 от 24.03.2014,
№2/113 от 07.04.2014, №3/615 от 07.04.2014.
ЛП №02330/264 от 14.04.2014.
220013, Минск, П. Бровки, 6

Тестирование веб-ориентированных приложений (Kulikov - 2017) PDF

Загружено:

Авторское право:

Доступные форматы

Тестирование веб-ориентированных приложений (Kulikov - 2017) PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Тестирование веб-ориентированных приложений (Kulikov - 2017) PDF

Загружено:

Авторское право:

Доступные форматы

Министерство образования Республики Беларусь

Факультет компьютерных систем и сетей

Кафедра программного обеспечения

1-40 01 01 «Программное обеспечение

в качестве учебно-методического пособия

Минск БГУИР 2017

кафедра информатики и веб-дизайна

К90 Тестирование веб-ориентированных приложений : учеб.-

Содержит материалы к практическим занятиям, включающие вопросы и

ISBN 978-985-543-328-7 © Куликов С. С., Данилова Г. В., 2017

1 ТЕСТИРОВАНИЕ ДОКУМЕНТАЦИИ И ТРЕБОВАНИЙ ........................ 4

3.3 АТРИБУТЫ (ПОЛЯ) ОТЧЁТА О ДЕФЕКТЕ ................................................... 74

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ ...................................... 95

1.1 Что такое «требование»

Всё так или иначе начинается с документации и требований.

Требование (requirement1) – описание того, какие функции и с

Небольшое «историческое отступление»: если поискать опре-

Хорошим кратким предисловием ко всему тому, что будет рас-

1.2 Важность требований

Требования являются отправной точкой для определения того, что

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

дей будет выполнена впустую. Эту мысль иллюстрирует рисунок 1.a.

 Позволяют понять, что и с соблюдением каких условий си-

Общее Системные Детализированный Интеграция и Системное Итоговая

планирование требования дизайн модульные тесты тестирование отчётность

Рисунок 1.a – Стоимость исправления ошибки в зависимости

Если графики вас не убеждают, попробуем проиллюстрировать ту

Задание 1.a: представьте, что ваш с друзьями бюджет ограни-

Ещё одним аргументом в пользу тестирования требований являет-

Так клиент Так проект был

Рисунок 1.b – Типичный проект с плохими требованиями

Documentation for software and IS development.

Implementation. URL: http://www.eden-study.org/articles/2003/icse03.pdf.

Рисунок 1.c – Соотношение понятий «продуктная документация»

Степень важности и глубина тестирования того или иного вида до-

чеством факторов, но неизменным остаётся общий принцип: всё, что мы

ей и так или иначе подвергать тестированию (например, вычитывание

1.3 Источники и пути выявления требований

Требования «начинают свою жизнь» на стороне заказчика. Их сбор

Анализ документов процессов Самостоятельное

Рисунок 1.d – Основные техники сбора и выявления требований

Анкетирование. Этот вариант выявления требований вызывает

результату при объёмных затратах. В то же время при правильной орга-

кументацию. Также к этой технике относится и просто изучение докумен-

димые для лучшего понимания сути проекта знания.

Моделирование процессов и взаимодействий. Может приме-

рией и юридическим отделом…»), так и к «техническим процессам и

даётся на сохранение в модуль “Хранилище”»). Данная техника требует

1.4 Уровни и типы требований

Несколько простых, изолированных от контекста и друг от друга

 Нужен инструмент, в реальном времени отображающий

 Необходимо в два-три раза повысить количество заявок,

транспортных накладных на основе договоров.

Пользовательские требования (user requirements22) описывают

дения системы, требования этого уровня могут быть использованы для

зования (use cases23), пользовательских историй (user stories24), пользо-

вательских сценариев (user scenarios25). (Также см. «Создание пользо-

примеров пользовательских требований:

бутов качества очень много28, но для любого проекта реально важными