Книга Станислава Куликова "Тестирование программного обеспечения Базовый курс"

Я таки осилил эту книгу.

Кратко озвучу своё мнение, а потом сделаю краткое содержание этой книги, т.к. не нашел оного.

Это вторая книга по тестированию, которую я прочитал.

Первая была Романа Савина - мой отзыв можно почитать здесь . И благо есть уже сокращение книги Р.Савина и плюс её в простоте языка, которым она написана, в изобилии примеров, в т.ч. наглядных, понятной структуры - в общем это хорошая книга для новичка. Чего не могу сказать о книге С.Куликова.

Прежде чем читать его книгу очень рекомендую заглянуть сюда. Здесь идёт общение автора с читателями и обсуждение книги. И разбирают довольно подробно вопрос: "А для кого эта книга написана?"

Моё личное мнение: для новичка тяжеловато она читается, скучно и даже нудно написана. Но есть там полезные вещи поэтому прочитать стоит. А здесь я постараюсь дать сокращенный вариант. Опять же сокращать буду исходя из своего понимания предмета. Скорее даже выдержки из книги.

Раздел 1: тестирование и тестировщики
1.1. Что такое тестирование и откуда оно появилось

Тестирование программного обеспечения — процесс анализа программного средства и сопутствующей документации с целью выявления дефектов и повышения качества продукта.

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

Раздел 2: основные знания и умения
2.1. Процессы тестирования и разработки ПО

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

2.2. Тестирование документации и требований
2.2.1. Что такое «требование»

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

2.2.5. Свойства качественных требований

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

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

Изменение формата файла и документа.

Отметка того факта, что с требованием всё в порядке.
Описание одной и той же проблемы в нескольких местах.
Написание вопросов и комментариев без указания места требования, к которым они относятся.
Задавание плохо сформулированных вопросов.
Написание очень длинных комментариев и/или вопросов.
Критика текста или даже его автора.
Категоричные заявления без обоснования.
Указание проблемы с требованиями без пояснения её сути.
Плохое оформление вопросов и комментариев.
Описание проблемы не в том месте, к которому она относится.
Ошибочное восприятие требования как «требования к пользователю».
Скрытое редактирование требований.
Анализ, не соответствующий уровню требований.

2.3. Виды и направления тестирования

2.3.1. Упрощённая классификация тестирования

По запуску кода на исполнение:

o Статическое тестирование — без запуска.

o Динамическое тестирование — с запуском.

По доступу к коду и архитектуре приложения:

o Метод белого ящика — доступ к коду есть.

o Метод чёрного ящика — доступа к коду нет.

o Метод серого ящика — к части кода доступ есть, к части — нет.

По степени автоматизации:

o Ручное тестирование — тест-кейсы выполняет человек.

o Автоматизированное тестирование — тест-кейсы частично или полностью выполняет специальное инструментальное средство.

По уровню детализации приложения (по уровню тестирования):

o Модульное (компонентное) тестирование — проверяются отдельные небольшие части приложения.

o Интеграционное тестирование — проверяется взаимодействие между несколькими частями приложения.

o Системное тестирование — приложение проверяется как единое целое.

По (убыванию) степени важности тестируемых функций (по уровню функционального тестирования):

o Дымовое тестирование (обязательно изучите этимологию термина — хотя бы в Википедии) — проверка самой важной, самой ключевой функциональности, неработоспособность которой делает бессмысленной саму идею использования приложения.

o Тестирование критического пути — проверка функциональности, используемой типичными пользователями в типичной повседневной деятельности.

o Расширенное тестирование — проверка всей (остальной) функциональности, заявленной в требованиях.

По принципам работы с приложением:

o Позитивное тестирование — все действия с приложением выполняются строго по инструкции без никаких недопустимых действий, некорректных данных и т.д. Можно образно сказать, что приложение исследуется в «тепличных условиях».

o Негативное тестирование — в работе с приложением выполняются (некорректные) операции и используются данные, потенциально приводящие к ошибкам (классика жанра — деление на ноль).

2.4. Чек-листы, тест-кейсы, наборы тест-кейсов

2.4.1. Чек-лист

Чек-лист (checklist) — набор идей [тест-кейсов]. Последнее слово не зря взято в скобки, т.к. в общем случае чек-лист — это просто набор идей: идей по тестированию, идей по разработке, идей по планированию и управлению — любых идей.

2.4.2. Тест-кейс и его жизненный цикл

Тест (test) — набор из одного или нескольких тест-кейсов.

Тест-кейс (test case) — набор входных данных, условий выполнения и ожидаемых результатов, разработанный с целью проверки того или иного свойства или поведения программного средства.

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

Цель написания тест-кейсов

Тестирование можно проводить и без тест-кейсов (не нужно, но можно; да, эффективность такого подхода варьируется в очень широком диапазоне в зависимости от множества факторов). Наличие же тест-кейсов позволяет:

• Структурировать и систематизировать подход к тестированию (без чего крупный проект почти гарантированно обречён на провал).
• Вычислять метрики тестового покрытия (test coverage metrics) и принимать меры по его увеличению (тест-кейсы здесь являются главным источником информации, без которого существование подобных метрик теряет смысл).
• Отслеживать соответствие текущей ситуации плану (сколько примерно понадобится тест-кейсов, сколько уже есть, сколько выполнено из запланирован-ного на данном этапе количества и т.д.).
• Уточнить взаимопонимание между заказчиком, разработчиками и тестировщиками (тест-кейсы зачастую намного более наглядно показывают поведение приложения, чем это отражено в требованиях).
• Хранить информацию для длительного использования и обмена опытом между сотрудниками и командами (или как минимум — не пытаться удержать в голове сотни страниц текста).
• Проводить регрессионное тестирование и повторное тестирование (которые без тест-кейсов было бы вообще невозможно выполнить).
• Повышать качество требований (мы это уже рассматривали: написание чек-листов и тест-кейсов — хорошая техника тестирования требований).
• Быстро вводить в курс дела нового сотрудника, недавно подключившегося к проекту.

2.4.5. Свойства качественных тест-кейсов

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

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

2.4.6. Наборы тест-кейсов

Набор тест-кейсов (test case suite, test suite, test set) — совокупность тест-кейсов, выбранных с некоторой общей целью или по некоторому об-щему признаку. Иногда в такой совокупности результаты завершения одного тест-кейса становятся входным состоянием приложения для следующего тест-кейса.

2.4.7. Логика создания эффективных проверок

Вся суть работы тестировщика в конечном итоге направлена на повышение качества (процессов, продуктов и т.д.)

Качество — это некая ценность для конечного пользователя (заказчика).

Есть простая логика:

• Тесты ищут ошибки.
• Но все ошибки найти невозможно.
• Значит, наша задача — найти максимум ВАЖНЫХ ошибок за имеющееся время.

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

Ситуация усугубляется следующими фактами:

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

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

• Что перед вами? Если вы не понимаете, что вам предстоит тестировать, вы не уйдёте дальше бездумных формальных проверок.
• Кому и зачем оно нужно (и насколько это важно)? Ответ на этот вопрос позволит вам быстро придумать несколько характерных сценариев использования того, что вы собираетесь тестировать.
• Как оно обычно используется? Это уже детализация сценариев и источник идей для позитивного тестирования (их удобно оформить в виде чек-листа).
• Как оно может сломаться, т.е. начать работать неверно? Это также детализация сценариев использования, но уже в контексте негативного тестирования (их тоже удобно оформить в виде чек-листа).

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

Ошибки оформления и формулировок

Отсутствие заглавия тест-кейса или плохо написанное заглавие.

Отсутствие нумерации шагов и/или ожидаемых результатов (даже если таковой всего лишь один).

Ссылка на множество требований.

Использование личной формы глаголов.

Использование прошедшего или будущего времени в ожидаемых результатах.

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

Описание стандартных элементов интерфейса вместо использования их устоявшихся названий.

Пунктуационные, орфографические, синтаксические и им подобные ошибки.

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

Описание действий в качестве наименований модуля/подмодуля.

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

«Выдумывание» особенностей поведения приложения.

Отсутствие описания приготовления к выполнению тест-кейса.

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

Непонимание принципов работы приложения и вызванная этим некорректность тест-кейсов.

Проверка типичной «системной» функциональности.
Неверное поведение приложения как ожидаемый результат.

Общая некорректность тест-кейсов.

Неверное разбиение наборов данных на классы эквивалентности.

Тест-кейсы, не относящиеся к тестируемому приложению.

Формальные и/или субъективные проверки.

2.5. Отчёты о дефектах

2.5.1. Ошибки, дефекты, сбои, отказы и т.д.

Упрощённый взгляд на понятие дефекта

Дефект — расхождение ожидаемого и фактического результата.

Ожидаемый результат — поведение системы, описанное в требованиях.

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

Расширенный взгляд на терминологию, описывающую проблемы

Ошибка (error, mistake) — действие человека, приводящее к некорректным результатам.

Дефект (defect, bug, problem, fault) — недостаток в компоненте или системе, способный привести к ситуации сбоя или отказа.

Сбой (interruption) или отказ (failure) — отклонение поведения системы от ожидаемого.

В ГОСТ 27.002-89 даны хорошие и краткие определения сбоя и отказа:

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

Отказ — событие, заключающееся в нарушении работоспособного состояния объекта.

Аномалия (anomaly) или инцидент (incident, deviation) — любое отклонение наблюдаемого (фактического) состояния, поведения, значения, результата, свойства от ожиданий наблюдателя, сформированных на основе требований, спецификаций, иной документации или опыта и здравого смысла.

Дефект — отклонение (deviation) фактического результата (actual result) от ожиданий наблюдателя (expected result), сформированных на основе требований, спецификаций, иной документации или опыта и здравого смысла.

2.5.2. Отчёт о дефекте и его жизненный цикл

Отчёт о дефекте (defect report) — документ, описывающий и приоритизирующий обнаруженный дефект, а также содействующий его устранению.

Отчёт о дефекте пишется со следующими основными целями:

• предоставить информацию о проблеме — уведомить проектную команду и иных заинтересованных лиц о наличии проблемы, описать суть проблемы;
• приоритизировать проблему — определить степень опасности проблемы для проекта и желаемые сроки её устранения;
• содействовать устранению проблемы — качественный отчёт о дефекте не только предоставляет все необходимые подробности для понимания сути случившегося, но также может содержать анализ причин возникновения проблемы и рекомендации по исправлению ситуации.

Отчёт о дефекте (и сам дефект вместе с ним) проходит определённые стадии жизненного цикла, которые схематично можно показать так:

• Обнаружен (submitted) — начальное состояние отчёта (иногда называется «Новый» (new)), в котором он находится сразу после создания. Некоторые средства также позволяют сначала создавать черновик (draft) и лишь потом публиковать отчёт.
• Назначен (assigned) — в это состояние отчёт переходит с момента, когда кто-то из проектной команды назначается ответственным за исправление дефекта. Назначение ответственного производится или решением лидера команды разработки, или коллегиально, или по добровольному принципу, или иным принятым в команде способом или выполняется автоматически на ос-нове определённых правил.
• Исправлен (fixed) — в это состояние отчёт переводит ответственный за исправление дефекта член команды после выполнения соответствующих действий по исправлению.
• Проверен (verified) — в это состояние отчёт переводит тестировщик, удостоверившийся, что дефект на самом деле был устранён. Как правило, такую проверку выполняет тестировщик, изначально написавший отчёт о дефекте.
• Закрыт (closed) — состояние отчёта, означающее, что по данному дефекту не планируется никаких дальнейших действий.
• Открыт заново (reopened) — в это состояние (как правило, из состояния «Исправлен») отчёт переводит тестировщик, удостоверившийся, что дефект по прежнему воспроизводится на билде, в котором он уже должен быть исправлен.
• Рекомендован к отклонению (to be declined) — в это состояние отчёт о дефекте может быть переведён из множества других состояний с целью вынести на рассмотрение вопрос об отклонении отчёта по той или иной причине. Если рекомендация является обоснованной, отчёт переводится в состояние «Отклонён» (см. следующий пункт).
• Отклонён (declined) — в это состояние отчёт переводится в случаях, подробно описанных в пункте «Закрыт», если средство управления отчётами о дефектах предполагает использование этого состояния вместо состояния «Закрыт» для тех или иных резолюций по отчёту.
• Отложен (deferred) — в это состояние отчёт переводится в случае, если исправление дефекта в ближайшее время является нерациональным или не представляется возможным, однако есть основания полагать, что в обозримом будущем ситуация исправится (выйдет новая версия библиотеки, вернётся из отпуска специалист по некоей технологии, изменятся требования заказчика и т.д.)

2.5.3. Атрибуты (поля) отчёта о дефекте

Идентификатор (id)

Краткое описание (summary) должно в предельно лаконичной форме давать исчерпывающий ответ на вопросы «Что произошло?» «Где это произошло»? «При каких условиях это произошло?».

Подробное описание (description)

Шаги по воспроизведению (steps to reproduce, STR)

Воспроизводимость (reproducibility)

Важность (severity)

Срочность (priority)

Возможность обойти (workaround)

Комментарий (comments, additional info)

Вложения (attachments)

2.5.4. Инструментальные средства управления отчётами о дефектах

Jira

1. Project (проект) позволяет указать, к какому проекту относится дефект.

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

• Improvement (предложение по улучшению) — было описано подробно в разделе, посвящённом полям отчёта о дефекте (см. описание поля «симптом», значение «предложение по улучшению»).
• New feature (новая особенность) — описание новой функциональности, нового свойства, новой особенности продукта.
• Task (задание) — некое задание для выполнения тем или иным участником проектной команды.
• Custom issue (произвольный артефакт) — как правило, это значение при настройке JIRA удаляют, заменяя своими вариантами, или пере-именовывают в Issue.

3. Summary (краткое описание) позволяет указать краткое описание дефекта.

4. Priority (срочность) позволяет указать срочность исправления дефекта. По умолчанию JIRA предлагает следующие варианты:

• Highest (самая высокая срочность).
• High (высокая срочность).
• Medium (обычная срочность).
• Low (низкая срочность).
• Lowest (самая низкая срочность).

Обратите внимание: по умолчанию поля severity (важность) нет. Но его можно добавить.

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

6. Affected versions (затронутые версии) содержит перечень версий продукта, в которых проявляется дефект.

7. Environment (окружение) содержит описание аппаратной и программной кон-фигурации, в которой проявляется дефект.

8. Description (подробное описание) позволяет указать подробное описание дефекта.

9. Original estimate (начальная оценка времени исправления) позволяет указать начальную оценку того, сколько времени займёт устранение дефекта.

10. Remaining estimate (расчётное остаточное время исправления) показывает, сколько времени осталось от начальной оценки.

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

12. Labels (метки) содержит метки (теги, ключевые слова), по которым можно группировать и классифицировать дефекты и иные артефакты.

13. Epic/Theme (история/область) содержит перечень высокоуровневых меток, описывающих относящиеся к дефекту крупные области требований, крупные модули приложения, крупные части предметной области, объёмные пользовательские истории и т.д.

14. External issue id (идентификатор внешнего артефакта) позволяет связать от-чёт о дефекте или иной артефакт с внешним документом.

15. Epic link (ссылка на историю/область) содержит ссылку на историю/область (см. пункт 13), наиболее близко относящуюся к дефекту.

16. Has a story/s (истории) содержит ссылки и/или описание пользовательских историй, связанных с дефектом (как правило, здесь приводятся ссылки на внешние документы).

17. Tester (тестировщик) содержит имя автора описания дефекта.

18. Additional information (дополнительная информация) содержит полезную дополнительную информацию о дефекте.

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

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

(Такой же обзор в книге дан на Bugzilla и Mantis)

2.5.5. Свойства качественных отчётов о дефектах

Тщательное заполнение всех полей точной и корректной информацией.

Правильный технический язык.

Специфичность описания шагов.

Отсутствие лишних действий и/или их длинных описаний.

Отсутствие дубликатов.

Очевидность и понятность.

Прослеживаемость.

Отдельные отчёты для каждого нового дефекта.

Соответствие принятым шаблонам оформления и традициям.

2.5.6. Логика создания эффективных отчётов о дефектах

При создании отчёта о дефекте рекомендуется следовать следующему алгоритму:

0. Обнаружить дефект.

1. Понять суть проблемы.

2. Воспроизвести дефект.

3. Проверить наличие описания найденного вами дефекта в системе управления дефектами.

4. Сформулировать суть проблемы в виде «что сделали, что получили, что ожи-дали получить».

5. Заполнить поля отчёта, начиная с подробного описания.

6. После заполнения всех полей внимательно перечитать отчёт, исправив неточности и добавив подробности.

7. Ещё раз перечитать отчёт, т.к. в пункте 6 вы точно что-то упустили.

2.5.7. Типичные ошибки при написании отчётов о дефектах

Ошибки оформления и формулировок

Плохие краткие описания (summary).

Ещё раз напомним его суть:

• Отвечает на вопросы «что?», «где?», «при каких условиях?».
• Должно быть предельно кратким.
• Должно быть достаточно информативным для понимания сути проблемы

Идентичные краткое и подробное описания (summary и description).

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

Игнорирование кавычек, приводящее к искажению смысла.

Общие проблемы с формулировками фраз на русском и английском языках.

Лишние пункты в шагах воспроизведения.

Копии экрана в виде «копий всего экрана целиком».

Копии экрана, на которых не отмечена проблема.

Откладывание написания отчёта «на потом».

Пунктуационные, орфографические, синтаксические и им подобные ошибки.

Логические ошибки

Выдуманные дефекты.

Отнесение расширенных возможностей приложения к дефектам.

Неверно указанные симптомы.

Чрезмерно заниженные (или завышенные) важность и срочность.

Концентрация на мелочах в ущерб главному.

Техническая безграмотность.

Указание в шагах воспроизведения информации, неважной для воспроизведения ошибки.

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

Игнорирование т.н. «последовательных дефектов».

2.6. Оценка трудозатрат, планирование и отчётность

2.6.1. Планирование и отчётность

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

Отчётность (reporting) — сбор и распространение информации о результатах работы (включая текущий статус, оценку прогресса и прогноз развития ситуации).

2.6.2. Тест-план и отчёт о результатах тестирования

Тест-план 

Тест-план (test plan) — документ, описывающий и регламентирующий перечень работ по тестированию, а также соответствующие техники и подходы, стратегию, области ответственности, ресурсы, расписание и ключевые даты.

В общем случае тест-план включает следующие разделы:

• Цель (purpose). Предельно краткое описание цели разработки приложения (частично это напоминает бизнес-требования, но здесь информация подаётся в ещё более сжатом виде и в контексте того, на что следует обращать первостепенное внимание при организации тестирования и повышения качества).
• Области, подвергаемые тестированию (features to be tested). Перечень функций и/или нефункциональных особенностей приложения, которые будут подвергнуты тестированию. В некоторых случаях здесь также приводится приоритет соответствующей области.
• Области, не подвергаемые тестированию (features not to be tested). Перечень функций и/или нефункциональных особенностей приложения, которые не будут подвергнуты тестированию. Причины исключения той или иной области из списка тестируемых могут быть самыми различными — от предельно низкой их важности для заказчика до нехватки времени или иных ресурсов. Этот перечень составляется, чтобы у проектной команды и иных заинтересованных лиц было чёткое единое понимание, что тестирование таких-то особенностей приложения не запланировано — такой подход позволяет исключить появление ложных ожиданий и неприятных сюрпризов.
• Тестовая стратегия (test strategy) и подходы (test approach). Описание процесса тестирования с точки зрения применяемых методов, подходов, видов тестирования, технологий, инструментальных средств и т.д.
• Критерии (criteria). Этот раздел включает следующие подразделы:
• Приёмочные критерии, критерии качества (acceptance criteria) — любые объективные показатели качества, которым разрабатываемый продукт должен соответствовать с точки зрения заказчика или пользователя, чтобы считаться готовым к эксплуатации.
• Критерии начала тестирования (entry criteria) — перечень условий, при выполнении которых команда приступает к тестированию. Наличие этого критерия страхует команду от бессмысленной траты усилий в условиях, когда тестирование не принесёт ожидаемой пользы.
• Критерии приостановки тестирования (suspension criteria) — перечень условий, при выполнении которых тестирование приостанавливается. Наличие этого критерия также страхует команду от бессмысленной траты усилий в условиях, когда тестирование не принесёт ожидаемой пользы.
• Критерии возобновления тестирования (resumption criteria) — перечень условий, при выполнении которых тестирование возобновляется (как правило, после приостановки).
• Критерии завершения тестирования (exit criteria) — перечень условий, при выполнении которых тестирование завершается. Наличие этого критерия страхует команду как от преждевременного прекращения тестирования, так и от продолжения тестирования в условиях, когда оно уже перестаёт приносить ощутимый эффект.
• Ресурсы (resources). В данном разделе тест-плана перечисляются все необходимые для успешной реализации стратегии тестирования ресурсы, которые в общем случае можно разделить на:
• программные ресурсы (какое ПО необходимо команде тестировщиков, сколько копий и с какими лицензиями (если речь идёт о коммерческом ПО));
• аппаратные ресурсы (какое аппаратное обеспечение, в каком количестве и к какому моменту необходимо команде тестировщиков);
• человеческие ресурсы (сколько специалистов какого уровня и со знаниями в каких областях должно подключиться к команде тестировщиков в тот или иной момент времени);
• временные ресурсы (сколько по времени займёт выполнение тех или иных работ);
• финансовые ресурсы (в какую сумму обойдётся использование имею-щихся или получение недостающих ресурсов, перечисленных в предыдущих пунктах этого списка); во многих компаниях финансовые ресурсы могут быть представлены отдельным документом, т.к. являются конфиденциальной информацией.
• Расписание (test schedule). Фактически это календарь, в котором указано, что и к какому моменту должно быть сделано. Особое внимание уделяется т.н. «ключевым точкам» (milestones), к моменту наступления которых должен быть получен некий значимый ощутимый результат.
• Роли и ответственность (roles and responsibility). Перечень необходимых ролей (например, «ведущий тестировщик», «эксперт по оптимизации производительности») и область ответственности специалистов, выполняющих эти роли.
• Оценка рисков (risk evaluation). Перечень рисков, которые с высокой вероятностью могут возникнуть в процессе работы над проектом. По каждому риску даётся оценка представляемой им угрозы и приводятся варианты вы-хода из ситуации.
• Документация (documentation). Перечень используемой тестовой документации с указанием, кто и когда должен её готовить и кому передавать.
• Метрики (metrics). Числовые характеристики показателей качества, способы их оценки, формулы и т.д. На этот раздел, как правило, формируется множество ссылок из других разделов тест-плана.
  

Метрика (metric) — числовая характеристика показателя качества. Может включать описание способов оценки и анализа результата.

Отчёт о результатах тестирования

Отчёт о результатах тестирования (test progress report, test summary report) — документ, обобщающий результаты работ по тестированию и содержащий информацию, достаточную для соотнесения текущей ситуации с тест-планом и принятия необходимых управленческих решений.

В общем случае отчёт о результатах тестирования включает следующие разделы:

• Краткое описание (summary). В предельно краткой форме отражает основ-ные достижения, проблемы, выводы и рекомендации. В идеальном случае прочтения краткого описания может быть достаточно для формирования полноценного представления о происходящем, что избавит от необходимости читать весь отчёт (это важно, т.к. отчёт о результатах тестирования может попадать в руки очень занятым людям).
• Команда тестировщиков (test team). Список участников проектной команды, задействованных в обеспечении качества, с указанием их должностей и ролей в подотчётный период.
• Описание процесса тестирования (testing process description). Последовательное описание того, какие работы были выполнены за подотчётный пе-риод.
• Расписание (timetable). Детализированное расписание работы команды тестировщиков и/или личные расписания участников команды.
• Статистика по новым дефектам (new defects statistics). Таблица, в которой представлены данные по обнаруженным за подотчётный период дефектам (с классификацией по стадии жизненного цикла и важности).
• Список новых дефектов (new defects list). Список обнаруженных за подотчётный период дефектов с их краткими описаниями и важностью.
• Статистика по всем дефектам (overall defects statistics). Таблица, в которой представлены данные по обнаруженным за всё время существования про-екта дефектам (с классификацией по стадии жизненного цикла и важности). Как правило, в этот же раздел добавляется график, отражающий такие статистические данные.
• Рекомендации (recommendations). Обоснованные выводы и рекомендации по принятию тех или иных управленческих решений (изменению тест-плана, запросу или освобождению ресурсов и т.д.) Здесь этой информации можно отвести больше места, чем в кратком описании (summary), сделав акцент именно на том, что и почему рекомендуется сделать в имеющейся ситуации.
• Приложения (appendixes). Фактические данные (как правило, значения метрик и графическое представление их изменения во времени).

Логика построения отчёта о результатах тестирования

Для того чтобы отчёт о результатах тестирования был действительно полезным, при его создании следует постоянно помнить об универсальной логике отчётности, особенно актуальной для таких разделов отчёта о результатах тестирования, как краткое описание (summary) и рекомендации (recommendations):

• Выводы строятся на основе целей (которые были отражены в плане).
• Выводы дополняются рекомендациями.
• Как выводы, так и рекомендации строго обосновываются.
• Обоснование опирается на объективные факты.

Выводы должны быть:

• Краткими.
• Информативными.
• Полезными для читающего отчёт.

Рекомендации должны быть:

• Краткими.
• Реально выполнимыми.
• Дающими как понимание того, что надо сделать, так и некоторое пространство для принятия собственных решений.

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

• «Почему мы так считаем?»
• «Неужели это так?!»
• «Где взять дополнительные данные?»

2.6.3. Оценка трудозатрат

Трудозатраты (man-hours) — количество рабочего времени, необходимого для выполнения работы (выражается в человеко-часах).

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

• Как много времени понадобится на выполнение работы?
• Когда всё будет готово?
• Можно ли гарантированно выполнить работу к такому-то сроку?
• Каковы наиболее оптимистичный и пессимистичный прогнозы по времени?

Далее идёт раздел про автоматизацию и раздел с приложениями.