Уровень 3
Работа и разработка артефактов тестирования
Уважаемый студент, мобильная версия данного уровня не доступна, пожалуйста перейдите в десктопную версию.
Добро пожаловать на третий уровень, мой юный подаван! На этом уровне тебе предстоит познать темные и светлые силы тестирования. Сразись с темной стороной, чтобы понять, как она действует и стань настоящим тестировщиком, который владеет позитивным и негативным тестированием. В этом уровне ты познакомишься со святыней тестирования - тест-кейсом.
А также со всей сопутствующей документацией.
Начнем с пожалуй основого столба тестирования. Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Под тест кейсом понимается структура вида:
Action > Expected Result > Test Result
(Действие > Ожидаемый результат > Фактический результат)
Test Case
Основные понятия
В соответствии с процессами или методологиями разработки ПО, во время проведения тестирования создается и используется определенное количество тестовых артефактов (документы, модели и т.д.). Наиболее распространенными тестовыми артефактами являются:
-
Набор тест кейсов и тестов (Test-Case & Test-suite)
-
Дефекты / Баг Репорты (Bug Reports / Defects)
-
План тестирования (уровень 7)
-
План приёмосдаточных испытаний (уровень 8)
-
Описание дефектов (уровень 5)
-
Отчет о тестировании
-
Чек лист
-
Use cases/User story
Как вы поняли, трое из артефактов так серьезны, что им посвященны целые уровни далее. Так что они будут c нетерпением вас ждать впереди.
Test Result
passed/failed/blocked
Expected Result
Action
Open page "login"
Login page is opened
passed
Сложноватое определение, подумать могли вы. А если сказать по-простому, то тест-кейс - это запись действий тестировщика. Как протестировал, так и записал. Нужно это для того, чтобы любой другой тестровщик или даже новичок, не знакомый с вашим продуктом, мог произвести тестирование в ваше отсутствие. Также тест-кейсы удобны для того, чтобы понимать какой обьем работы вы уже выполнили и какой остался, отслеживать и документировать процесс работы. Начальство, знаете ли, очень любит документы.
Стандартные атрибуты тест-кейса
Давайте разберем, что такое тест кейс на практике. Тест-кейс, он как борщ - у каждой хозяйки разный, хоть и ингридиенты вроде бы все используют одинаковые. Нет 100% эталонного тест-кейса, поэтому мы рассмотрим различные варианты оформления тест кейсов, и тогда вы будьте готовы к любому развитию событий. Вот один из примеров тест кейса, написанный для тестирования сайта из домашнего задания:
1
2
3
4
5
6
7
1. Номер - уникальный идентификатор тест кейса. Его удобно использовать для четкого понимания, о какой проверке идет речь (например, дать ссылку в описании бага на этот тест кейс)
2. Название - краткое описание сути проверки. Должно помещаться в твиттер и быть понятным! Кратко, но емко. Тут главное не увлекаться краткостью - о чем идет речь, должно быть понятно всем, а не только вам.
3. Предварительные шаги (PreConditions) - описание действий, которые необходимо выполнить, но прямого отношения к проверке они не имеют (например, зарегистрироваться в системе для проверки создания элемента). Если предварительных шагов нет, то секция не заполняется
4. Шаги — описание действий, необходимых для проверки (например, создание элемента)
5. Пост шаги (PostConditions) - список действий, переводящих систему в первоначальное состояние (состояние до проведения теста - initial state)
6. Ожидаемый результат (Expected result) — сама проверка: что мы ожидаем получить после выполнения шагов ("Элемент создан")
7. Результат теста (Test Result ) - passed/failed/blocked
8. Приоритет тест-кейса (Test Case Priority) - это важность тест кейса. Важность проставляют выбрать в виде числа От 1 до N или приоритетов: minor, major, critical, еще есть блокер blocker, но это редко применимо к тест кейсу
Виды Тестовых Случаев
Негативный тест кейс
Оперирует как корректными, так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора.
Позитивный тест кейс
Использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
Примеры
Action
Expected Result
Test Result
PreConditions
do A1
verify B1
do A2
verify B2
Test Case Description
do A3
verify B3
PostConditions
delete this user
В приведенном примере конечная проверка - В3. Это значит, что именно она является ключевой. Значит, A1 и А2 - это действия приводящие систему в тестопригодное состояние. А В1 и В2 - условия того, что система находится в состоянии пригодном для тестирования. Таким образом имеем:
Выполнение:
Action
Expected Result
Test Result
(passed/failed/blocked)
PreConditions
do A1
verify B1
passed
do A2
verify B2
failed
Test Case Description
do A3
verify B3
blocked
PostConditions
delete this user
В этом примере при прохождении тест-кейсов тестировщик не сумел выполнить шаг А2 и в результате этого, система не пришла в тестопригодное состояние. В таком случае он заводит баг со статусом "blocker" и проставляет все дальнейшие стасусы как заблокированно - "blocked". Прохождение такого тест кейса возобновится, только после исправления этой ошибки. В случае если обнаружен баг, который не блокирует дальнейшие шаги, тест кейс всегда проходится до конца.
Еще примеры
В зависимости от требований к покрытию функционала и правил написания тест-кейсов в конкретной компании можно уменьшать детализацию тест кейсов:
Проверка отображения страницы
Действие
Ожидаемый результат
Результат теста
Открыть страницу "Вход в систему"
- Окно "Вход в систему" открыто
- Название окна - Вход в систему
- Логотип компании отображается в правом верхнем углу
- На форме 2 поля - Имя и Пароль
- Кнопка Вход доступна
- Ссылка "забыл пароль" - доступна
Название окна “вход в”
Открыл баг #BG23
Test suite
Test suite (тестовый набор) – является контейнером, который содержит набор тест-кейсов и помогает тестировщикам структурировать, выполнять и давать отчеты по выполнению тест-кейсов. Аналогично тест-кейсам, тест-сьютам присваивают статус выполнения: Active, Inprogress, Completed.
Тест-кейсы объединяются в тест-сьюты для большего удобства при проходжении тест-кейсов. Т.к. необходимо проходить их последовательно от модуля к модулю, от одного типа тестирования к другому, а не сумбурно, бросаясь из одного угла в угол, оставив не проверенным большую часть модуля или общей функциональности.
Тест-кейс может быть добавлен в несколько тест-сьютов и тест-планов. Один сьют может содержать любое количество кейсов.
Структура тестовой документации
Вся структрура станет тебе понятной после этой схемы. Тест-кейсы группируются в тест-сьюты для тестирования определенных фич вашего проекта. А сами тест-сьюты определяются тест планом, в котором содержится вся стратегия тестирования.
Пример тест-кейсов
Отнесись к этим примерам не просто серьезно, а серьезнее всего. Потратьте столько времени на изучение их сколько нужно. Понятно что читать тест кейсы это не журнал "Красотки галактики" листать. Но вам необходимо понять правила создания тест-кейсов, и лучше всего это сделать на реальных примерах. И так к вашим услугам:
1. Тест-кейс в виде классической таблицы
2. Тест-кейс в виде таблицы с вариантами
3. Тест-план с банком, более 50 тест кейсов. Это же просто Джек пот! (Вкладка Покрытие тест-кейсами)
4. Тест-кейс в баг трекинговой системе Jira
Пример тест кейса выполненного в баг трекинговой система Jira
Будь осторожен с силами тьмы. Тьма не дремлет и поджидает тебя в самом неожиданном месте
Test Report - Тестовый отчет
Test Report - это способ коммуникации, направленный на установление прозрачности в деятельности QA команды в течение суток либо другого временного цикла (спринта) и включает в себя информацию как о найденных дефектах, так и о результатах пройденных тестов.
Тестовый отчет бывает в виде:
• Отправки Email/документа (чаще всего)
• Meeting/presentation. Встреча и устный отчет либо отчет с презентацией
• Отчет в блоге
• Одновременно ежедневный email и еженедельный мит-ап
Обычно тест-репорт предназначен для:
• Разработчиков
• Заказчика проекта
• Всяческих боссов и тим лидов
• Команды поддержки тестовой среды
• Бизнес-аналитика / Продакт менеджер и других членов команды проекта
Все они являются получателями / участниками встречи
Содержание тестового отчета
• Количество тестов, запланированных на отчетный период
• Количество тестов, выполненных в этот период
• Количество тестов, выполненых всего (из намеченного плана)
• Количество дефектов, найденных в этот период, и их текущий статус
• Общее количество дефектов, найденных в этот период, и их текущий статус
• Количество открытых критических дефектов
• Blockers - Проблемы тестового окружения (только при их наличии)
• Showstoppers – все, что мешает работать - например глючит ПК
• Приложение/cсылка на документ с выполнением тестов
• Ссылка на баг репорт, на дефект, на вашу тулзу тестирования
Как выглядит тим лид когда слушает твой тест репорт
Практические советы от магистра:
- Помечайте общее состояние теста цветным индикатором. Например: зеленый – протестировано вовремя, оранжевый - чуть с опозданием, красный - тест задерживается или блокирован.
- Включайте некоторые простые показатели в отчет, например, как: процент успешных пройденных тестов до сих пор, плотность дефектов в %, процент критических дефектов из всех; делая это, вы не просто даете числа, вы на самом деле даете взглянуть на качество продукта, который вы проверяете.
- Если большая часть работы завершена – упомяните это.
- Если есть критический дефект, который будет блокировать часть будущей работы, подчеркните это.
- При использовании презентации, не забудьте включить несколько графиков, чтобы сделать более понятной ее суть.
- Также можно упомянуть планы на ближайшее будущее в разделе TODO.
Давай рассмотрим два примера репортов. Это будет познавательно.
Пример таблицы тест репорта
Когда однозначно нужно использовать таблицу? В случае если над заполнением работает несколько человек. Либо, если большой объем данных отчета. Давайте рассмотрим пример подробно:
1. Module - логический раздел в функционале проекта. Аналогично примеру тест кейса №3
2. Scenarios - название сценария теста. Аналогично елементу чек листа
3. Sub levels - под-сценарий теста
4. Complexity - сложность теста
5. Responsible tester - ответственный за выполнение человечешка
6. Date - дата выполнения теста
7. Status - pass/fail/locked/not executed (пройден/не пройден/заблокирован/не выполнен). Далее будет без перевода, пожалуйста выучите статусы!
8. Defect ID and brief description - идентификатор дефекта и его короткое описание
9. Severity/Priority - серьезность или приоритет дефекта
10. Status - статус дефекта
Пример письма тест репорта
Hello.
Short update about feature status.
In general Automation with 2.983 RC and backgroundperpage open - Pass QA.
But I met a problems with Image compare test (failed 116 tests), because appears scroll on screenshot from site with experiment. This don't reproduces manually.
So I've sent a letter to automation team because don't know how to handle this.
Link to investigation table
Manual QA cycle:
Founded one more critical bug - WOH-9557 - Some templates doesn't show background with experiment turned on
Plans TODO:
- Run image compare test with experiment on
- Check bug fix and perform Sanity cycle after
Blockers: 116 automation test fail due to automation bug. Autotest need be fixed.
Regards
Перевод на русский
Чек-лист
Чек-листы - один из фундаментальных инструментов тестирования. Они позволяют не забывать о важных тестах, фиксировать результаты своей работы и отслеживать статистику о статусе программного продукта.
Чек-листы предназначены для тестировщиков с опытом и знанием продукта.
Чек-лист - это документ, содержащий список того, что должно быть протестировано. При этом чек-лист может быть абсолютно разного уровня детализации. Насколько детальным будет чек-лист зависит от требований к отчётности, уровня знания продукта сотрудниками и сложности продукта.
Важно запомнить - при всей своей краткости чек-лист не допускает абстрактности и двузначности. Например: "Проверить корректность футера" - неправильно! Правильно - "Проверить работоспособность ссылок и иконок соц. сетей в футере сайта".
Добрый день.
Короткое обновление статуса тестирования фичи backgroundperpage.
Цикл автоматизированного тестирования:
Автоматизированное тестирование релиз кандидата 2.983.0 и фичи backgroundperpage - Pass QA.
Но при этом возникли проблемы с тестами для сравнения скриншотов GUI (упало 116 тестов). Причина падения тестов - появление горизонтальyого scroll bar (прокрутки). Скролл не появляется при открытии сайта вручную, поэтому был сделан вывод, что баг в автотесте. Ссылка на таблицу результатов анализа автотестов.
Цикл ручного тестирования:
Был найден еще один критический баг - WOH-9557 - Некторые из шаблонов сайтов не отображают фоновое изображение.
Планы TODO:
- Запустить автотесты с выключенным экспериментом
- Проверить исправление найденной ошибки
- Провести выборочное регрессионное тестирование после исправления всех ошибок
Blockers: проблема с появлением горизонтального скролла в автотестах
С Уважением, Магистр Оби Ван Кенноби.
Преимущества чек-листа
Главный принцип чек-листов заключается в том, что каждый тестировщик по-своему проходит их, расширяя тестовый набор своей экспертизой и личным видением тестирования.
Какие преимущества чек-листов по сравнению с тест-кейсами:
• Нивелирование эффекта пестицида в регрессионном тестировании
• Расширение тестового покрытия за счёт отличий при прохождении
• Сокращение затрат на содержание и поддержку тестов: не надо писать много буковок!
• Отсутствие рутины, которую так не любят квалифицированные тестировщики
• Возможность проходить и комбинировать тесты по-разному, в зависимости от предпочтений сотрудников
Недостатки чек-листов
Да-да. Несмотря на всю привлекательность чек-листов, не спешите их использовать с самого начала вашей карьеры. У них есть-таки свои недостатки:
-
Начинающие тестировщики не всегда эффективно проводят тесты без достаточно подробной документации
-
Чек-листы невозможно использовать для обучения начинающих сотрудников, так как в них недостаточно подробной информации
-
Заказчику или руководству может быть недостаточно того уровня детализации, который предлагают чек-листы
Пример чек-листа
Для того чтобы проверить верстку сайта может использоваться следующий
чек лист (он тебе пригодится на уровене 9).
Для верификации верстки любой веб-страницы выполнить такие проверки:
-
Соответствие вида страницы макету
-
Кроссбраузерность, кодировка и DOCTYPE
-
Валидность, доступность, микроформаты
-
Независимость блоков в CSS: минимизация каскада, использование техник БЭМ/MCSS/SMACSS
-
Сайт должен нормально смотреться во всех стандартных разрешениях от 1024 и выше, не иметь горизонтального скролла и вписываться в экран мобильных устройств
-
Корректная работа при вбивании реального текста, надёжность верстки
-
Проверка и оптимизация скорости загрузки
-
Наличие Win/Mac/Linux-аналогов шрифтов
-
Доступность при выключенных(загружающихся) картинках
-
HTML5 формы, линковка, валидация
-
Семантичность. Отсутствие глупостей в html и css, единообразие, аккуратность
-
Правильная структура заголовков (H1,H2,… и т.д. и TITLE)
-
Работоспособность при выключенном JavaScript
-
Работоспособность при выключенном Flash
-
Отсутствие багов при увеличенном шрифте
-
И последний пункт – мелкие проверки (ниже подробней)
И еще пример чек-листа. В этом случае проводилась проверка десктопного приложения в разных OС. Каждый раз, как на работе приходится выполнять кросс платформенное тестирование мы создаем чек лист в Google Doc. В ней каждый тестировщик отмечает статус своего участка работы. Подробнее на примере:
Use case
Use case (Варианты использования) – описания поведения системы при ее взаимодействии с окружающим миром.
Use case описывает то, как действующее лицо пытается достичь некой цели, используя программу.
Варианты использования предназначены в первую очередь для определения функциональных требований к системе и управляют всем процессом разработки. Все основные виды деятельности, такие как анализ, проектирование, тестирование - выполняются на основе вариантов использования. Во время анализа и проектирования варианты использования позволяют понять, как результаты, которые хочет получить пользователь, влияют на архитектуру системы и как должны себя вести компоненты системы, для того чтобы реализовать нужную для пользователя функциональность.
Для чего используются use cases ?
-
Дают представление о поведении системы
-
Понятны заказчикам и разработчикам
-
Позволяют описать множество альтернатив
(исключений)
-
Список вариантов использования - это перечень функциональности системы
Позволяют описывать функционал итеративно (перечень Use Cases -> Краткие описания ->
Основные потоки -> Расширения)
-
Цель
-
Действующие лица
-
Предусловия
-
Максимальные и минимальные гарантии
-
Основной сценарий
-
Альтернативные сценарии
Cтруктура Use case
Как видит Use Case менеджер
Сложно? А кто сказал что будет легко? Не время сдаваться, идем дальше!
Case: Зарегистрироваться на сайте
Description: Сайт должен предоставлять пользователю возможность зарегистрироваться. Для регистрации пользователь должен заполнить форму. После регистрации сайт должен
отправить на e-mail пользователя подтверждение регистрации
Как запишет Use case QA
Описание в формате Use Case
UC name: Зарегистрироваться на сайте
Действующее лицо: пользователь сайта
Предусловия: пользователь находится на главной странице
сайта
Основной сценарий:
- Пользователь нажимает кнопку "Зарегистрироваться"
- Сайт отображает форму регистрации
- Пользователь заполняет поля формы и подтверждает регистрацию
- Сайт подтверждает правильность заполнения формы
- Сайт регистрирует пользователя и отправляет на его e-mail письмо с подтверждением регистрации
Альтернативные сценарии:
1. Пользователь регистрируется с помощью соц аккаунта...
User story
Перечень функциональности (user stories) - это подробный список того, что пользователь может делать в системе. Вся функциональность будущего продукта разбивается на простейшие возможности в виде <кто> <что делает> <с чем>. Каждая из функций имеет приоритет, определяющий важность для общего успеха продукта. Кроме того, для функции описываются критерии приемки — реакция на действия пользователя, при которых она считается правильно работающей.
Перечень функциональности пересекается с вариантами использования. Разница в том, что первые помогают в точном учете требований, а вторые — в понимании того, как работают функции и система в целом. User stories говорят о том, что нужно сделать, а Use cases - как это работает.
Еще вот User story , Use case - названия такие подобные, а как же разобрать где что?
Для тестировщиков Use Case являются отличной базой для формирования тестовых сценариев - test case, так как они описывают, в каком контексте должно производиться каждое действие пользователя. Use Case по умолчанию являются тестируемыми требованиями, так как в них всегда указана цель, которой нужно достигнуть, и какие шаги надо для этого воспроизвести
Минуточку! Я вижу, вы собираетесь заканчивать уровень. Но мне вот непонятно, зачем он нужен, этот Use case?
Я объясню, мой лохматый друг,
User Story - это один из сценариев, тогда как Use Case - это набор сценариев
Use Case объединяет несколько сценариев и показывает отношения
между ними
По-настоящему он поймет только увидев пример. Вот use case, построеный на базе трех user story: US1, US2, US3.
Пример Use Case
Пример use case дам тебе я. Прочитай и попробуй разобраться, что к чему. Чтобы тестирования джедаем стать, разбираться в таких вещах необходимо
Формула User Story
Пользовательскую историю можно описывать по–разному. Но наиболее продуктивным для понимания задания, а также наиболее кратким и при этом ёмким оказывается следующая формула:
Я, как X, хочу Y, чтобы Z.
X — это персонаж, от имени которого ведется повествование. Это пользователь продукта. Это тот, для кого будет строиться функциональность. Y — это задача, действие или свойство, которое необходимо персонажу. Z — это конечная бизнес–ценность, которую получит персонаж.
Например, пользовательские истории могут выглядеть так:
Как Падаван Тестирования, прохожу курс Galaxy QA Academy, чтобы научиться тестировать.
Как магистр тестирования, хочу видеть прогресс студентов и проверять их работы, чтобы быть уверенным в качестве их знаний.
Основной смысл в User Story для тестировщика - использовать их для генерации критериев приёмки. Критерии приёмки (acceptance criteria) — это требования от заказчика; спецификация по которой может быть проверена система/user story. Фактически, критерии приемки - это бизнес-правила, которым подчиняется прорабатываемая пользовательская история. А уже детали приемочных тестов, описанных в конкретных тестах и сформируют приемочные тесты, которые и позволят выполнить тестирование уже готового продукта.
Магия превращения требований к продукту в конкретные тест кейсы и есть работа тестировщика. Давайте посмотрим процесс создания тест кейсов на примере. Изначально приходит общее требование к продукту. Например,- "Доступ к новой фиче имеют только руководящие должности". Тогда я нахожу все роли пользователей в ПО и разделяю их на руководящие и рядовые должности. Для каждой должности создам тест кейс: если она руководящая то проверю, что доступ нет, в обратном случае доступа быть не должно. А теперь в виде схемы:
Вопросы и итоги
Мой народ не так развит, как звездные джедаи, но мы тоже хотим обучаться тестированию. Мы не знали, как работать с Google-таблицами раньше, но нашли в интернете это видео - оно помогло нам научиться работать с Google-таблицами. Вдруг тебе тоже это пригодится, начинающий тестировщик? Смело пропускай это, если знаком с таблицами.
Практическое задание
Поздравляю тебя, ты прошел реально зубодробительный уровень по теории! И я знаю, что ты сможешь теперь свернуть горы на практике. Начнем по порядку:
1. Пройди рабочий тест-кейс магистра Кенноби
2. Напиши собственный чек-лист для проверки уже знакомого сайта из первого уровня
3. Теперь, когда ты поднаторел на практике, тебе не составит никакого труда ответить на пару теоретических вопросов
4. Загляни к магистру Йоде - у него для тебя есть какое-то личное здание
Когда все выполнишь - отправь задание в совет магистров через форму. Магистры отметили тебя как выдающегося ученика. Порадуй их хорошей работой
Практика создание тест кейсов
Это задание для двоих. Поэтому, тебе стоит обратиться за помощью к своему другу Чубаке.
Тебе придется создать тест-кейс для тестирования покупки сладостей (обожаю сладости). Вводный use case такой:
Юзер приходит на главную страницу, смотрит галерею, картинки, кликает на ссылки и прочее - все должно работать. Затем переходит на страницу категорий по ссылке и выбирает разные виды печеньев или конфет, помещая их в корзину (мы не знаем точно, что он выберет, поэтому нужно покрыть тестами все уникальные варианты выбора). Затем идет в корзину и там еще увеличивает или уменьшает количество товаров, мы не знаем это наверняка поэтому проверяем все действия.
На базе данного сценария вам нужно построить тест кейс, проходя который некий тестировщик сможете убедится что сайт работает и все запланированные функции пользователь сможет выполнить.
Нужно понимать, что это программа минимум, для того чтобы ты не запутался в том, что нужно тебе делать. Помимо этого, необходимо наполнить тест-кейс теми проверками функционала сайта, которые тебе покажутся важными. Например, проверить компоненты главной страницы.
Затем, ты обмениваешься тест кейсами с Чубаккой, он проверит твой тест-кейс, а ты пройдешь его тест кейс и дашь ему свою рецензию на него - что ты хотел бы улучшить/исправить. Для того, чтобы это сделать - скопируй себе этот документ и укажи все правки и комментарии там.
Так же, чубака составил чек-лист для проверки одной странички сайта печенек, чтобы у тебя был пример.
P.S. посмотри его тест кейс перед тем, как отправить свой.
Для перехода на уровень 4, необходимо набрать минимум 21 балла за задания уровня 3.
