Чек лист тестирование пример

1.

Тестовая документация

2.

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

3.

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

4.

Шаблон тест плана
Что надо тестировать? — описание объекта тестирования: системы, приложения,
оборудования
Что будете тестировать? список функций и описание тестируемой системы и её
компонент в отдельности
Как будете тестировать? — стратегия тестирования, а именно: виды тестирования и
их применение по отношению к объекту тестирования
Когда будете тестировать? — последовательность проведения работ: подготовка
(Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в
разрезе запланированных фаз разработки
Критерии начала тестирования: -готовность тестовой платформы (тестового
стенда) , законченность разработки требуемого функционала , наличие всей необходимой
документации
Критерии окончания тестирования:
результаты тестирования удовлетворяют критериям качества продукта:

5.

Тест план
Introduction (Введение)
Test Items (Объекты тестирования)
Features To Be Tested (Функциональности для тестирования)
Features Not To Be Tested (Функциональности которые не будут тестироватся )
Approach (Стратегия тестирования (виды, подходы, методы))
Item Pass/Fail Criteria (Критерии успешности тестирования )
Suspension Criteria and Resumption Requirements (Критерии остановки и
возобновления тестирования )
8) Test Deliverables (Тестовые результаты)
9) Environmental Needs (Тестовое окружение)
10) Responsibilities (Ответсвенность)
1)
2)
3)
4)
5)
6)
7)

6.

Чек лист
Чек-лист — это документ, описывающий что должно быть протестировано
Зачем нужен чек-лист?
• Не забыть требуемые тесты
• Для деления задач по уровню квалификации
• Для сохранения отчётности и результатов тестирования
Что может (должно) быть в чек-листе?
• Номер
• Список проверок (с требуемой степенью детализации)
• Статус проверки (сборка, окружение, тестировщик)
• Приоритет
• Результат

7.

Чек лист- пример

8.

Тестовые данные
Тестовые данные (Test data) — данные которые
используются для тестирования
Пример:
410039303350 — счет заблокирован (зачисления на
счет запрещены)
4100322407607 — корректный номер (зачисление
успешно пройдет)
[email protected] – тестовый логин
123 – тестовый пароль

9.

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

10.

Пример тест кейса
Атрибуты тест-кейса
1) Номер (ID)
2) Название (Summary/Name
3) Предусловие (PreConditions)
4) Шаги тест кейса и описание
(Steps and Descriptions )
5) Ожидаемый результат (Expected
result)
6) Пост-условие (PostConditions)
7) Автор (Designer)
8) Статус (Status)
9) Дата создания (Created)
Test Name:
Status:
Created Date:
Designer:
Pre Conditions:
Steps
Step 1
Step 2
Step 3
Step 4
Post Conditions:
Description
Expected Result

11.

Практикум
Написать тест кейсы на проверку формы регистрации

12.

Тест комплект
Набор тестов (тест комплект )(test suite) — это набор тест кейсов,
которые объединены тем что относятся к одному тестируемому
модулю, функциональности, приоритету или одному типу
тестирования.

13.

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

English     РусскийRules

Что такое чек-лист и для чего он нужен?

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

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

  • Можно бесконечно долго тестировать приложение, но так и не убедиться в том, что проверено действительно все. Чтобы этого не произошло, нужно придерживаться фиксированного набора тестов, охватывающих весь функционал.
  • Нельзя сделать вывод о степени готовности продукта к выпуску. Только на основе чек-листа можно увидеть в процентах, какая часть общего функционала работает корректно.
  • В силу ограниченности человеческой памяти и внимания без чек-листа практически невозможно сказать со 100% уверенностью, какие именно компоненты продукта уже проверялись, а какие все еще нуждаются в проверке.
  • Без фиксированного набора тестов нельзя оценить затраты времени, необходимые для проведения тестирования.

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

  1. Чек-лист должен охватывать весь функционал разрабатываемого продукта. Ни одно заявленное в спецификации требование не должно остаться без внимания.
  2. Число тестов нужно минимизировать. Чем больше требований проверяется одним тестом – тем лучше.
  3. Набор тестов должен не повторять требования, а проверять их.

Когда следует приступать к созданию чек-листа?

На завершающем этапе создания Спецификаций. Замечания QA-специалиста нужно обсудить и внести в требования до начала процесса разработки. Иначе возрастает риск потратить несоизмеримо больше ресурсов на переделку уже реализованных модулей или выдать продукт, который не соответствует ожиданиям заказчика.

Как мы создаем и ведем чек-листы в Magora Systems?

  1. Когда готов документ с первичными спецификациями, к проекту подключают QA специалиста. Он знакомится с документом, вносит предложения, задаёт уточняющие вопросы.
  2. После утверждения спецификации клиентом, тестировщик приступает к определению набора тестов, необходимых для проверки разрабатываемого продукта. Существует несколько способов записи тестов. Наиболее удобная форма – таблица, содержащая 3 столбца: ID теста – Шаги теста – Ожидаемый результат.
  3. Кто-то использует для ведения чек-листов Excel, кто-то таблицы Google Drive (более удобный вариант, документ динамически обновляется, у всех участников проекта есть доступ к актуальной версии).

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

  4. Как только разрабатываемый продукт передан на тестирование, специалист приступает к прохождению чек-листа последовательно во всех поддерживаемых конфигурациях. В результате экспертизы иногда возникает потребность в дополнении чек-листа тестами, тогда тестировщик расширяет его.
  5. После выполнения всех тестов подготавливается баг-репорт и отчет о статусе продукта.
  6. После устранения/исправления обнаруженных в ходе тестирования проблем, специалист приступает к верификации и регрессионному тестированию, также фиксируя результаты в чек-листе.
  7. Пройденные чек-листы хранятся в сервисе Sitechko. В любой момент времени можно просмотреть историю, которая включает все итерации тестирования и  отчеты о результатах на каждом этапе.



Обратная связь

ПОЗНАВАТЕЛЬНОЕ

Сила воли ведет к действию, а позитивные действия формируют позитивное отношение


Как определить диапазон голоса — ваш вокал


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


Целительная привычка


Как самому избавиться от обидчивости


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


Тренинг уверенности в себе


Вкуснейший «Салат из свеклы с чесноком»


Натюрморт и его изобразительные возможности


Применение, как принимать мумие?

Мумие для волос, лица, при переломах, при кровотечении и т.д.


Как научиться брать на себя ответственность


Зачем нужны границы в отношениях с детьми?


Световозвращающие элементы на детской одежде


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


Как слышать голос Бога


Классификация ожирения по ИМТ (ВОЗ)


Глава 3. Завет мужчины с женщиной


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


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


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

b)Структура Тестовых Случаев (Test Case Structure).

Каждый тест кейс должен состоять из трех частей. В таблице показаны эти части.

Таблица. Структура Test case.

Pre conditions   Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test case description Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
Post conditions Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state)

 

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

Пример тест-кейса:

do A1, verify B1

do A2, verify B2

do A3, verify B3.

В приведенном примере конечная проверка — В3. Это значит, что именно она является ключевой. Значит, A1 и А2 — это действия приводящие систему в тестопригодное состояние. А В1 и В2 — условия того, что система находится в состоянии пригодном для тестирования. Таким образом, в таблице ниже показано условие тест-кейса.

Таблица. Условие тест-кейса.

Action Expected Result Test Result (passed/failed/blocked)
Preconditions    
do A1 verify B1  
do A2 verify B2  
Test Case Description    
do A3 verify B3  
Postconditions    
     

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

Нужно ответить на вопрос: "Почему данное разбиение удобно использовать?"

Ответ в таблице ниже: конечная проверка одна, т.е. в случае если тест провален (test failed) будет сразу ясно из-за чего. Т.к. если провальными окажутся проверки В1 и/или В2, то тест кейс будет заблокирован (test blocked), из-за того, что функцию не возможно привести в тестопригодное состояние (состояние пригодное для проведения тестирования), но это не значит, что тестируемая функция не работает.

Таблица. Один из вариантов результата.

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    
     

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

Таблица. Пример тест-кейса 1.

Проверка отображения страницы
Действие Ожидаемый результат Результат теста
Открыть страницу "Вход в систему" — окно "Вход в систему" открыто; — название окна — Вход в систему; — логотип компании отображается в правом верхнем углу; — на форме 2 поля — Имя и Пароль; — кнопка Вход доступна; — ссылка "забыл пароль" — доступна.

 

Пример тест кейса 2:

Название: Проверка отображения страницы

Действие: Открыть страницу "Вход в систему"

Проверка: Проверьте, что отображаемая страница соответствует странице на картинке 1 (и прилагаем изображение страницы "Вход в систему").

В примере 1 и 2 покрытие будет одинаковым, но вот время, которое потребуется для прохождения, будет разным. Второй пример будет нагляднее.

D)Атрибуты тест-кейса.

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

Таблица.

Атрибуты тест кейса.

Атрибут тест кейса Описание
Test Case ID Уникальное значение в пределах не только документа, но и всей фирмы
Test Case Priority Приоритет. Измеряется от 1 до n 1 – самый высокий n – самый низкий (для не очень больших проектов рационально выбирать n=4)
IDEA Описание идеи, проверяемой тест-кейсом
SETUP and ADDITIONAL INFO Входные параметры
Revision History История редактирования. Пример формата: Created on <date> by<name> Modified on<date>by<name> Change – какие изменения и зачем они  
Execution Part Выполнимая часть тест кейса. Пример формата: Action – список команд EXPECTED RESULT – ожидаемый результат TEST RESULT – (passed, failed, blocked)

 

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

1) открыть vk.com;

2) ввести в поле “Имя пользователя” значение “user”;

3) ввести в поле “Пароль” значение “password”;

4) нажать кнопку “Войти”;

5) ввести в поле “Искать людей” значение “Петр Петров”;

6) нажать кнопку “Поиск”;

7) нажать на страницу с Петр Петров;

8) в открывшейся странице нажать на ссылку “Отправить подарок”;

9) в открывшейся странице нажать на любую ссылку с подарком;

10) в открывшейся странице нажать на кнопку “Подарить”;

11) в открывшейся странице нажать на ссылку “Банковские карты”;

12) ввести в поле “Номер карты” значение карты VISA “1111-1111-1111-1111”;

13) ввести в поле “Действительно до” значение “07/15”;

14) ввести в поле “CVC” значение “111”;

15) нажать кнопку “Оплатить”;

16) записать номер заказа;

17) запросить базу данных “select res from payment where id = <номер заказа>”.

Ожидаемый результат: “10”

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

Для выполнения одного и того же сценария на N наборах тестовых данных создается N тестов.

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

Такой вид тест кейса называется управляемый данными (data-driven).

Проблемы сценария в примере:

– пункты 1-4 могут меняться в связи с миграцией сайта на новый домен, изменением интерфейса и т.д.;

– поиск друга в пунктах 5-7 “Петр Петров” может привести в никуда при удалении страницы;

– пункты 8-15 могут быть легко изменены за счет нового дизайна сайта.

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

Таблица. Тест-кейс для примера.

Test Case ID/Priority VV12345
IDEA: Оплата картой VISA “подарка другу” SETUP and ADDITIONAL INFO: Аккаунт: user/password Имя друга: Петр Петров Номер карты: 1111-1111-1111-1111 Срок действия: 07/15 CVC: 111 Запрос SQL: select res from payment where id = <номер заказа>
Revision History
Created on 23/01/2014 by Иван Иванов Новый тест кейс
Execution Part
ACTION EXPECTED RESULT TEST RESULT
1) открыть vk.com; 2) ввести в поле “Имя пользователя” значение “user”; 3) ввести в поле “Пароль” значение “password”; 4) нажать кнопку “Войти”; 5) ввести в поле “Искать людей” значение “Петр Петров”; 6) нажать кнопку “Поиск”; 7) нажать на страницу с Петр Петров; 8) в открывшейся странице нажать на ссылку “Отправить подарок”; 9) в открывшейся странице нажать на любую ссылку с подарком; 10) в открывшейся странице нажать на кнопку “Подарить”; 11) в открывшейся странице нажать на ссылку “Банковские карты”; 12) ввести в поле “Номер карты” значение карты VISA “11111111-1111-1111”; 13) ввести в поле “Действительно до” значение “07/15”; 14) ввести в поле “CVC” значение “111”; 15) нажать кнопку “Оплатить”; 16) записать номер заказа; 17) запросить базу данных “select res from payment where id = <номер заказа>”.    
         

Если же разбить задачу на несколько тест-кейсов, например, за пункты 1-4 будет отвечать тест-кейс “Вход в систему”, за пункты 5-7 “Поиск друга”, 8-15 – “Оплата подарка” (на внутреннем уровне каждого из них возможно еще более детальное разделение), то можно переписать тест-кейс так, как указано в таблице ниже.

Таблица. Упрощение тест-кейса.

Test Case ID/Priority VV12347
IDEA: Оплата картой VISA “подарка другу” SETUP and ADDITIONAL INFO: Аккаунт: user/password Имя друга: Петр Петров Номер карты: 1111-1111-1111-1111 Срок действия: 07/15 CVC: 111 Запрос SQL: select res from payment where id = <номер заказа>
Revision History
Created on 23/01/2014 by Марина Гончарова Новый тест кейс
Modified on 23/01/2014 by Иванов Евгений Упрощение шагов
Execution Part
ACTION EXPECTED RESULT TEST RESULT
1) войти в систему; 2) найти друга; 3) платить подарок; 4) записать номер заказа; 5) запросить базу данных “select res from payment where id = <номер заказа>”      

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

Таблица. Упрощение тест-кейса.

Test Case ID/Priority VV12348
IDEA: Подтверждение оплаты SETUP and ADDITIONAL INFO: Номер заказа: параметр
Revision History
Created on 23/01/2014 by Марина Гончарова Новый тест кейс
Modified on 23/01/2014 by Иванов Евгений Упрощение шагов
Modified on 24/01/2014 by Сергей Галкин Изменение структуры
Execution Part
ACTION EXPECTED RESULT TEST RESULT
Запросить базу данных “select res from payment where id = <номер заказа>”      

Неизвестным параметр <Номер заказа> после завершения выполнения теста получит свое значение, которое будет задокументировано.


Добавить комментарий

Закрыть меню