Отличие чек листа от тест кейса

Добавил пользователь Алексей Ф.
Обновлено: 19.09.2024

Какое место тест-дизайн занимает в тестировании. Тест-кейсы и чек-листы. Позитивное и негативное тестирование. Анализ продукта.

Слайд 3

Согласно ISTQB, состоит из следующих основных групп активностей: Планирование тестирования Мониторинг и контроль тестирования Анализ тестирования Проектирование тестов Реализация тестов Выполнение тестов Завершение тестирования ПРОЦЕСС ТЕСТИРОВАНИЯ Тест- лид Тест- лид Тестировщик

Слайд 4

ПРОЕКТИРОВАНИЕ ТЕСТОВ Проектирование тестов плотно связано с техниками тест-дизайна и видами тестирования. Тест-дизайн ( Test Design ) – этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы) в соответствии с определёнными ранее критериями качества и целями тестирования. Если говорить совсем просто - это техники, с помощью которых создаются тест-кейсы.

Слайд 5

ДЛЯ ЧЕГО ТЕСТ-ДИЗАЙН Не знаем техник - тестируем наобум. Например, есть 10 правильных аккаунтов. А если их 1 000 ? Цель тест-дизайна - качественное покрытие функционала или продукта тестами. Под качеством имеется в виду следующее: Тесты должны обеспечивать максимально полное покрытие функционала. Тестов должно быть минимальное количество. Плотное тестирование при минимуме проверок.

Слайд 6

Слайд 7

Слайд 8

ТЕСТ-КЕЙС Тестовый случай, тестовый сценарий ( test case ) - набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки соответствия определенному требованию. [IEEE 610] Это артефакт, который описывает наши тесты. Рецепт – пошаговый план приготовление единицы продукта. Что в нем есть? Название. Ингредиенты. Шаги по приготовлению. Фото Не описан ваш результат приготовления. Цели: Помочь другому человеку правильно приготовить продукт. Запомнить для себя, как его делать правильно.

Слайд 9

ШАБЛОН ТЕСТ-КЕЙСА ID – уникальный номер, обычно проставляется автоматически в системах хранения тест-кейсов. ID Краткое описание тест-кейса Требования : Автор : Приоритет : Версия : Предварительные условия … … … Шаги … … … … Ожидаемый результат … … … … Приложения

Слайд 10

Слайд 11

ШАБЛОН ТЕСТ-КЕЙСА ID – уникальный номер, обычно проставляется автоматически в системах хранения тест-кейсов. ID Краткое описание тест-кейса Требования Автор Приоритет Версия Предварительные условия … … … Шаги … … … … Ожидаемый результат … … … … Приложения Краткое описание тест-кейса ( Name ) – одна фраза из которой станет ясно, что проверяется данным сценарием. Требования – ссылка на требование или ТЗ, на основе которого был составлен тест-кейс.

Слайд 12

Слайд 13

Слайд 14

ШАБЛОН ТЕСТ-КЕЙСА Название/Модуль/Версия продукта ( Component/Version ) – описание ПО, на котором можно выполнить тест-кейс. ID Краткое описание тест-кейса Требования Автор Приоритет Версия Предварительные условия … … … Шаги … … … … Ожидаемый результат … … … … Приложения ID – уникальный номер, обычно проставляется автоматически в системах хранения тест-кейсов. Краткое описание тест-кейса ( Name ) – одна фраза из которой станет ясно, что проверяется данным сценарием. Требования – ссылка на требование или ТЗ, на основе которого был составлен тест-кейс. Автор ( Author ) – тестировщик, который написал тест-кейс. Приоритет ( Priority ) – насколько важен этот тест-кейс.

Слайд 15

ШАБЛОН ТЕСТ-КЕЙСА Название/Модуль/Версия продукта ( Component/Version ) – описание ПО, на котором можно выполнить тест-кейс. ID Краткое описание тест-кейса Требования Автор Приоритет Версия Предварительные условия … … … Шаги … … … … Ожидаемый результат … … … … Приложения Предварительные условия ( Pre-conditions ) – шаги, которые необходимо выполнить перед началом тестирования по тест-кейсу. ID – уникальный номер, обычно проставляется автоматически в системах хранения тест-кейсов. Краткое описание тест-кейса ( Name ) – одна фраза из которой станет ясно, что проверяется данным сценарием. Требования – ссылка на требование или ТЗ, на основе которого был составлен тест-кейс. Автор ( Author ) – тестировщик, который написал тест-кейс. Приоритет ( Priority ) – насколько важен этот тест-кейс.

Слайд 16

ШАБЛОН ТЕСТ-КЕЙСА Название/Модуль/Версия продукта ( Component/Version ) – описание ПО, на котором можно выполнить тест-кейс. ID Краткое описание тест-кейса Требования Автор Приоритет Версия Предварительные условия … … … Шаги … … … … Ожидаемый результат … … … … Приложения Предварительные условия ( Pre-conditions ) – шаги, которые необходимо выполнить перед началом тестирования по тест-кейсу. Шаги ( Steps ) – точная последовательность действий для выполнения проверки. ID – уникальный номер, обычно проставляется автоматически в системах хранения тест-кейсов. Краткое описание тест-кейса ( Name ) – одна фраза из которой станет ясно, что проверяется данным сценарием. Требования – ссылка на требование или ТЗ, на основе которого был составлен тест-кейс. Автор ( Author ) – тестировщик, который написал тест-кейс. Приоритет ( Priority ) – насколько важен этот тест-кейс.

Слайд 17

ШАБЛОН ТЕСТ-КЕЙСА Название/Модуль/Версия продукта ( Component/Version ) – описание ПО, на котором можно выполнить тест-кейс. ID Краткое описание тест-кейса Требования Автор Приоритет Версия Предварительные условия … … … Шаги … … … … Ожидаемый результат … … … … Приложения Предварительные условия ( Pre-conditions ) – шаги, которые необходимо выполнить перед началом тестирования по тест-кейсу. Шаги ( Steps ) – точная последовательность действий для выполнения проверки. Ожидаемый результат ( Expected Result ) – что должны получить после выполнения шагов. ID – уникальный номер, обычно проставляется автоматически в системах хранения тест-кейсов. Краткое описание тест-кейса ( Name ) – одна фраза из которой станет ясно, что проверяется данным сценарием. Требования – ссылка на требование или ТЗ, на основе которого был составлен тест-кейс. Автор ( Author ) – тестировщик, который написал тест-кейс. Приоритет ( Priority ) – насколько важен этот тест-кейс.

Слайд 18

Слайд 19

НАЗВАНИЕ ТЕСТ-КЕЙСА Название тест-кейса должно быть коротким и понятным. Назвать тест-кейс “Проверить успешную регистрацию” логично. НО на это действие у нас может быть несколько кейсов. Проверить успешную регистрацию Проверить успешную регистрацию Проверить успешную регистрацию Проверить успешную регистрацию Проверить успешную регистрацию .

Слайд 20

НАЗВАНИЕ ТЕСТ-КЕЙСА Проверить успешную регистрацию Проверить успешную регистрацию Проверить успешную регистрацию Проверить успешную регистрацию Проверить успешную регистрацию . Название тест-кейса должно быть коротким и понятным. Назвать тест-кейс “Проверить успешную регистрацию” логично. НО на это действие у нас может быть несколько кейсов. Слишком длинное название сложно читается. “Проверить правильную регистрацию, когда вводим логин латинскими буквами без цифр и пробелов с паролем из цифр”

Слайд 21

Слайд 22

Слайд 23

ШАГИ ТЕСТ-КЕЙСА Шаги должны быть четкими и понятными. В идеале их нужно писать так, чтобы понял даже человек, который видит проект и тестирование в первый раз. Четкие шаги снизят риски того, что тест-кейс будет неправильно понят. Описывать шаги лучше следующим образом. Неправильно: Ввожу данные… Ввел данные.. Введи данные…. Правильно : Ввести данные… Нажать на кнопку…

Слайд 24

ШАГИ ТЕСТ-КЕЙСА Описывать шаги лучше следующим образом. Шаги должны быть четкими и понятными. В идеале их нужно писать так, чтобы понял даже человек, который видит проект и тестирование в первый раз. Четкие шаги снизят риски того, что тест-кейс будет неправильно понят. Неправильно: Ввожу данные… Ввел данные.. Введи данные…. Правильно : Ввести данные… Нажать на кнопку…

Слайд 25

ОЖИДАЕМЫЙ РЕЗУЛЬТАТ Когда ожидаемый результат один. ID Краткое описание тест-кейса Требования Автор Приоритет Версия Предварительные условия … … … Шаги … … … … Ожидаемый результат Приложения ID Краткое описание тест-кейса Требования Автор Приоритет Версия Предварительные условия … … … Шаги … … … … Ожидаемый результат … … … … Приложения Когда ожидаемый результатов несколько и они зависят от шагов.

Слайд 26

ОЖИДАЕМЫЙ РЕЗУЛЬТАТ Когда ожидаемый результат один. ID Краткое описание тест-кейса Требования Автор Приоритет Версия Предварительные условия … … … Шаги … … … … Ожидаемый результат Приложения ID Краткое описание тест-кейса Требования Автор Приоритет Версия Предварительные условия … … … Шаги … … … … Ожидаемый результат … … … … Приложения Когда ожидаемых результатов несколько и они зависят от шагов.

Когда-то в юности я начала работать сотрудницей отдела тестирования в одной компании. Тестовая документация там существовала в виде чек-листов в Excel и каких-то требований на 1-2 странички для разработчиков, куда также иногда могли заглянуть и тестировщики. Со временем компания перестала выделять время на написание ЧЛ, но документация для разработчиков все еще оставалась в более или менее достойном виде. Так как компания занималась обычной разработкой программного обеспечения для мобильных устройств, то поддерживать актуальной тестовую документацию и вообще её создавать для тестировщиков оказалось накладно. Спецификация стала редкостью.

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

— Мы закончили делать in-app покупку тем!
— Ad-hoc сборка уже собралась! Через час надо выложить!
— Ещё мы критические баги исправили и вот эту “штуковину” засунули в код.
— Прогоните какой-то смоук, вдруг что-то сломалось!
— и т. д.

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

— Слушайте, а кто-нибудь помнит, что тут было? Кто-то знает, как оно должно работать?
— Не помню уже. Надо спросить у разработчиков…
— Хм… Думаешь, я помню, что я делал три месяца назад? У меня 5 приложений! Я уже не помню, где и что я когда-то писал…
… (время уходит)
— Да не знаю. Ну, пусть так будет.
— У меня твой баг не повторяется. А-а-а… ты э-э-ту кнопку нажимаешь при выходе. А я всегда ту нажимаю…
— Слушай, а ты не помнишь, как мы проверяли такие подписки? И вот это каким должно быть? Кажется, оно не должно быть таким… Не помню.

И спросить не у кого. Специалистов, которые бы занимались документацией, нет. Тестировщиками часто проводилось полное тестирование приложения, что отнимало много времени – целые недели, а иногда, и месяцы. И на вопрос: “Когда вы закончите проверять?”, следовал ответ: “Критические баги лезуууут!” Не было четкого понимания, сколько времени необходимо для тестирования программы. А время, как известно, – деньги. В итоге получалось нечто, что начинало жить своей жизнью…

Как, что и по каким законам там происходило – не было понятно никому. Особенно новым разработчикам, которым передавали дальнейшую разработку:

Коллеги, я потратил три дня на изучение кода, потому что разработчиков этой программы уже нет, и ничего не понятно. Комментариев в коде мало. Непонятно, для чего какой костыль. Если я начну писать, то сломаю то, что работает. Мне легче это всё переписать заново. Давайте напишем нормально.

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

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

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

В каком виде и для чего нужна тестовая документация?

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

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

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

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

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

ТЗ помогает сотрудникам понять программу лучше. Непонимание разрабатываемого продукта приводит к ошибкам.

При тестировании не будет возникать попыток проверять лишнее. В первую очередь, проверке подвергнется то, что обязательно должно работать по ТЗ.

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

ЧТЗ (частное техническое задание) – создается на основе ТЗ. Обычно содержит полное описание конкретной части разрабатываемого продукта и ВИ (варианты использования, сценарии использования предмета разработки пользователями, макеты разрабатываемой части предмета разработки, его логику и суть).

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

Помогает новым сотрудникам разобраться в крупных и масштабных проектах, так как на некоторые системы нужны недели изучения. Имея под рукой ЧТЗ, сотрудник с легкостью сможет найти в нем необходимую информацию, сразу приступив к тестированию. Не нужно будет привлекать других сотрудников, знающих продукт, тем самым отвлекая их от работы. Очевидная экономия времени!

Дает возможность примерно оценить трудозатраты на разработку и тестирование еще до начала работ.

Помогает тестировщикам создать ЧЛ и тест-кейсы до начала работ и тестирования.

ЧТЗ и ТЗ можно отобразить:

в текстовом виде с картинками

в виде графического шаблона-таблицы

в виде интеллект-карт, UML или подобного алгоритма

Проектная документация, подготавливаемая тестировщиками

ЧЛ (чек-лист) – список того, что нужно проверить.

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

Хранит историю пройденных тестов. Можно будет легко вспомнить, какие именно тесты проходили с ошибками, и перепроверить именно их.

ЧЛ с результатами наглядно показывает любому сотруднику компании текущее состояние разрабатываемого продукта. Помогает определить его степень готовности.

Помогает помнить, что уже было проверено, а что нет.

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

Чек-листы можно записать:

в виде таблиц (удобно в Google Sheets)

в виде интеллект-карт (удобно в XMind)

в виде списка проверок в специально предназначенной системе (удобно в Sitechco)

в виде списка в текстовом документе, который привычен.

ТК (тест-кейс) – создается на основе ЧТЗ (если оно есть) тест-аналитиками и тестировщиками.

Совместно с ЧЛ может хранить историю тестирования и отображать, что именно и как тестировалось. Можно убедиться, что та или иная функциональность обязательно была или будет проверена и затронута при тестировании.

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

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

Тест-кейсы можно отобразить:

в виде таблицы с текстовыми данными

в специальном сервисе для ведения тест-кейсов (например, в TestLink).

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

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

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

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

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

Пример отчета в письменном виде:

Как определить, какую именно документацию необходимо внедрить в проект?

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

На проекте до 15 человек (проекты низкой сложности):

техническое задание (предотвращает неверное понимание задачи разработчиками, т. к. документации нет);

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

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

На проекте от 15 до 50 человек (проекты средней сложности):

база знаний (например, в Wiki);

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

Большой проект – от 50 человек и больше (проекты высокой сложности):

частное техническое задание;

база знаний (например, в Wiki);

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

прочее (зависит от типа, целей и нужд компании).

Что из этого выбрать — решать самим сотрудникам, т. к. именно они будут заниматься разработкой и смогут понять, что им нужнее. Все вышеперечисленное — лишь примерное представление и рекомендации.

Что делать, если написание документации занимает много времени?

Опыт показывает, что при работе над небольшим проектом нужно уметь приспосабливаться. Можно видоизменить документацию так, чтобы ее ведение было удобным и не занимало много времени. Например, ТЗ можно сделать в виде презентации или вебинара и получить от разработчиков уточняющие вопросы. Каждый из видов документации обладает своими плюсами и минусами, поэтому нужно экспериментировать и не бояться создавать что-то новое. Все научные открытия совершаются методом проб и ошибок, при этом случаются и неудачи!
Но отрицательный результат – это тоже результат! Нужно уметь им воспользоваться и учесть его в своих дальнейших экспериментах, пока не будет достигнут приемлемый итог. Великолепных вам решений и успехов в написании документаций!

QA ( aнгл. Quality assurance — обеспечение качества) — это процесс или результат формирования требуемых свойств и характеристик продукции по мере её создания.

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

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

Система отслеживания ошибок ( англ. bug tracking system ) — программа учета и/или контроля багов:

•HP ALM ( HP Application Lifecycle Management )

Приоритет багов ( англ. Bug priority ) — важность той или иной ошибки в ПО:

•Trivial — косметическая малозаметная проблема

•Minor — очевидная, незначительная проблема

•Major — значительная проблема

•Critical — проблема, нарушающая работу c ключевыми функциями ПО

•Blocker — проблема, нарушающая функционирование ПО

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

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

Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы.

UX ( англ. User eXperience — опыт пользователя ) — ощущение, испытываемое пользователем во время использования цифрового продукта

Анализ Граничных Значений ( англ. Boundary Value Analysis — BVA ). Анализ граничных значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

Баг Репорт ( англ. Bug Report — отчет об ошибке ) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

Валидация ( англ. validation — проверка ) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе.

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

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

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

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

Матрица соответствия требований ( англ. Traceability matrix ) — это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases).

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

Причина / Следствие ( англ. Cause/Effect — CE ). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Из этого состоят тест-кейсы.

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

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

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

Релиз или RTM ( англ. Release to manufacturing — промышленное издание ) — издание продукта, готового к тиражированию.

Пост-релиз или Post-RTM ( англ. post-release to manufacturing ), издание продукта, у которого есть несколько отличий от RTM и помечается как самая первая стадия разработки следующего продукта.

Тест дизайн ( англ. Test design ) — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы).

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

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

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

Чек-лист ( англ. Check list ) — это документ, описывающий что должно быть протестировано. Обычно составляется на те или иные требования. И очень часто по чек-листу составляется тест план. С чек-листа начинается наша работа. Мы составляем список того, чем мы собираемся заниматься и отдаем его, обычно, менеджеру для подтверждения и далее на его основе начинаем делать тестовый план.

Буду рад Вашим комментариям и Вашей поддержке моего канала. Подписывайтесь, ставьте лайки! Всем удачи!

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

Текст-кейс и автотест

Тест-кейс — это документация тестировщика. Это список действий, который нужно совершить, чтобы достичь поставленной цели. Он включает в себя, в среднем, 5 пунктов:

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

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

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

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

Также полезно Гид по профессии тестировщик: чем занимается специалист в сфере QA, сколько зарабатывает, что надо знать и где учиться.

Тестирование функциональности

В большинстве случаев это тестирование проводится вручную. Этапа три, они идут по порядку:

Регрессионное тестирование

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

Сэм Канер, профессор программной инженерии Технологического института, директор Образовательного и исследовательского центра тестирования программного обеспечения Флориды, выделяет три основных типа этого теста:

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

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

Тестирование в проектной работе

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

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

Тестирование совместимости — нефункциональный тест, цель которого — проверить, корректно ли работает приложение в определённом окружении. Это может быть аппаратная платформа, различные ОС, браузеры и расширения.

Интеграционное тестирование — фаза теста ПО, где отдельные модули программы объединяют и тестируют в группе. Интеграционное тестирование можно автоматизировать с помощью систем непрерывной интеграции (например, Jenkins, TeamCity, Travis CI, Gitlab CI, Circle CI, GoCD или другие).

Предрелизное тестирование

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

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

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

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

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

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

Тестирование на поддержке

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

Во время тестирования на поддержке нужно проверять сборку: основной функционал после обновлений. Когда тестировщик обнаружит баг, он должен описать его. Дальнейшая работа над проблемой будет происходить по принципу тестирования во время спринта.

Вывод и чек-лист

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

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

Этап 1: тестирование в спринте.
- тест-кейс и автотест — создаётся документация тестировщика и автотесты;
- тестирование функциональности — ручной тест (позитивный и негативный);
- регрессионное тестирование — отслеживаются исправления;
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях

Читайте также: