Читать книгу Тестирование программного обеспечения. Основы - - Страница 20

В процессе работы специалисты по тестированию создают различные артефакты[11] и документы. Кстати, дефект – это один из артефактов работы тестировщика. Познакомимся поближе с документами и артефактами, которые могут создавать и с которыми могут работать специалисты по тестированию.

План тестирования

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

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

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

В плане тестирования фиксируется следующая информация:

– Цели и задачи тестирования. Здесь определяется, что именно нужно проверить в программном обеспечении.

– Объекты тестирования[12]. Какие модули, функциональные возможности, интерфейсы и т. д. будут тестироваться.

– Уровни, типы и виды тестов. Например, функциональное тестирование, нефункциональное тестирование, тестирование производительности, и т. д.

– Приоритеты тестов. В какой последовательности будут выполняться тесты.

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

– График тестирования. План со сроками, в котором указано, когда и в какие сроки должно быть проведено и завершено тестирование.

– Тестовое окружение. Какое тестовое окружение будет использоваться в тестах.

– Риски. Что может увеличить сроки тестирования или блокировать тестирование и как эти риски нивелировать.

– Критерии успешности тестирования. Что считать успешным тестированием и какие условия должны выполняться.

В зависимости от организации в план тестирования могут включать и другую информацию, которую посчитают важной. С примером плана тестирования вы можете ознакомиться на сайте автора[13].

Разработку планов тестирования проводят опытные специалисты по тестированию или руководители и менеджеры по тестированию.

Функциональная карта

Функциональную карту ещё называют «интеллектуальной картой», «диаграммой связей», «ассоциативной картой» и т. д. Мы её называем «функциональной», так как на ней отражены функциональные области программы, которые необходимо тестировать.

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

Цель функциональной карты – дать общее представление о структуре и логике работы программы, выделить её основные возможности. Она используется на этапе планирования и проектирования тестов. В функциональной карте отображают основные модули или разделы программы, вспомогательные функции, обеспечивающие работу основных модулей.

Как функциональные карты применяются специалистами по тестированию в работе? Создавая функциональную карту программы, специалист разбивает программу на логические функциональные блоки и описывает её ветвлениями. Рассмотрим на простом примере, взяв за основу программу «Блокнот», которая имеется в операционной системе Windows:

У программы «Блокнот» есть «Заголовок» (1), «Строка меню» (2), «Форма ввода данных» (3). Названные блоки (элементы) в свою очередь делятся на дополнительные элементы.

Заголовок (1) имеет:

– название программы в заголовке;

– кнопка «Свернуть»;

– кнопка «Развернуть»;

– кнопка «Закрыть».

Строка меню (2) имеет:

– пункт меню «Файл»;

– пункт меню «Правка»;

– пункт меню «Формат»;

– пункт меню «Вид»;

– пункт меню «Справка».

Форма ввода данных (3) имеет:

– поле ввода текста;

– полоса прокрутки.

Всё перечисленное можно отобразить на функциональной карте:

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

– синий круг – это значит ветвление будет дальше продолжаться;

– зелёный круг с галочкой – это является конечной проверкой.

Визуально видим, как ветвится функционал программы и остаётся только продолжить следование по пунктам меню или функционалу программы. Для большей наглядности продолжим разбор пункта меню «Справка»:

Пункт меню «Справка» имеет пункты:

– просмотреть справку.

– отправить отзыв.

– о программе.

Функциональная карта получит следующее продолжение:

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

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

Тест-кейс

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

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

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

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

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

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

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

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

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

2) Заголовок – краткое, понятное и ёмкое описание сути проверки.

3) Предусловия – описание действий, которые необходимо предварительно выполнить или учесть перед началом проведения проверок.

4) Шаги проверки – описание последовательности действий, которые надо выполнить для проверки.

5) Ожидаемый результат – проверка, которая устанавливает, что мы ожидаем получить после выполнения определённых действий в соответствующем шаге.

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

Рассмотрим тест-кейс на примере программы для сложения чисел:

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

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

Правило № 1. Заголовок:

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

– не может содержать выполняемые шаги и ожидаемый результат.

Правило № 2. Предусловие:

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

11

Артефакт – это результат какой-либо деятельности. Им может быть любая документация, написанный код и прочее.

12

Объект тестирования – компонент или программа, которые должны быть протестированы.

13

Ознакомиться с планом тестирования можно по ссылке https://victorz.ru/books/book-1