Презентация на тему Основные понятия в тестировании. Тестовые артефакты

и параметров, необходимых для проверки реализации тестируемой функции или

её части.

– кейса;
- Название;
- Окружение (Опционально);
- Предусловия

(Опционально);
- Шаги;
- Ожидаемый результат;
- История редактирования (Опционально).

Зависимостей от других Test Case;
- Нечеткой формулировки шагов

или ожидаемого результата;
- Отсутствия необходимой для прохождения Test Case информации;
- Излишней детализации.

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

выполнило вызываемую функцию.

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

Зайти на сайт www.dev_test.com (логин - test, пароль - test).
2. Войти под учетной

записью администратора (логин - admin, пароль - 1)
3. Перейти на вкладку "Жильцы".
4. Нажать на кнопку "Создать карточку жильца".
5. Нажать на кнопку "Сохранить", не заполняя никакие данные.
Ожидаемый результат Появляется сообщение об ошибке "Заполните обязательные поля, отмеченные *", карточка не сохраняется.

Click link Sign In.
3. Fill Email.
4. Fill Password.
5. Press

button Sign In.

Expected results:
User should be logged to site.

be on forgot password page.

Steps to reproduce:
1. Fill Email.
2.

Click button Reset Password.

Expected result:
User should get email with reset password instructions.

на сайт www.production.com.
2. Нажми на кнопку "Войти" в правом верхнем углу

экрана.
3. Авторизуйся с правами администратора.
4. Перейди на вкладку "Жильцы".
5. Нажми на кнопку "Создать карточку жильца".
6. Введи корректные ФИО, например, "Иванов Иван Иванович" и сохрани карточку.
Ожидаемый результат — карточка создана.

Тест-кейсы дают нам структурированный системный подход, что снижает вероятность

пропуска ошибки.

проектной информации.

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

или призванному на помощь коллеге из другого отдела, который

ничегошеньки о проекте не знает. Дополнительных вопросов с его стороны будет по минимуму — все и так (должно быть) понятно!

момент «вспомнить», что мы делали месяц, полгода, год назад.

X% тестов выполнено;

- Y% тестов прошло/завалилось;

- Z%

требований покрыто тестами.

– выполнение!» Тест-кейсы дают нам структурированный системный подход, что

снижает вероятность пропуска ошибки;
- Тест-кейсы – хороший способ хранения части проектной информации;
- Написание тест-кейсов – один из способов протестировать проектную документацию ещё до выхода первого билда;
- Наличие тест-кейсов значительно ускоряет регрессионное тестирование;
- Тест-кейсы – прекрасный способ быстро ввести в курс дела новичка или сотрудника, только что подключившегося к проекту;
- Имея тест-кейсы, мы можем в любой момент «вспомнить», что мы делали месяц, полгода, год назад;
- Тест-кейсы позволяют легко отслеживать прогресс (X% тестов выполнено, Y% тестов прошло (завалилось), Z% требований покрыто тестами).

в которых может привести к гибели (самолетостроение, медицина, ПО

для атомных станций);
- При тестировании сложных систем или сложных частей системы, чтобы не запутаться в чек-листе.

приложения и т. п.);
- Ситуации, когда в команде

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

- Тест-кейс это не набор обязательных шагов;

- Перед

написанием детализированных тест-кейсов запишите все, что можно протестировать в вашем приложении в вольной форме.

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

соотношение времени прохождения к тестовому покрытию.

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

Более быстрое введение в проект новых людей или подключение

коллег из других проектов для проведения сессии тестирования;
- Напоминание о конфигурировании и настройке системы;
- Незаменимы при работе над на «тяжелых» проектах;

участницами процесса;
- Напоминание о старой функциональности, которую все

еще нужно тестировать;
- Лучше, чем ничего)

одного функционала очень похожи;
- Сложность поддержки;
- Неактуальное

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

не тестирует его;
- Тестировщики выключают мозг, проходя Test

Case;
- Любой может выполнять их, они не заменяют опытных тестировщиков, которые могут тестировать;

для какой-либо работы. Отмечая пункты списка, вы, команда или

специалист, можете узнать о состоянии или корректности выполнения этой

– одна операция;
- Пункты написаны в утвердительной форме;

- Оптимальное количество пунктов – до 20;

- Удобный доступ.

деления задач по уровню квалификации.

● Для сохранения отчётности и

результатов тестирования.

Повышение скорости обучения новых сотрудников;

к некорректной работе объекта тестирования, с указанием причин и

ожидаемого результата.

Проект (Project);
- Компонент приложения (Component);
- Номер версии

(Version);
- Серьезность (Severity);
- Приоритет (Priority);
- Статус (Status);
- Автор (Author);
- Назначен на (Assigned To);

был найден баг: операционная система, сервис пак, для WEB

тестирования - браузер и его версия и прочее.

to Reproduce)
Шаги, по которым можно легко воспроизвести ситуацию, приведшую

к ошибке;

- Фактический Результат (Result)
Результат, полученный после прохождения шагов к воспроизведению;

- Ожидаемый результат (Expected Result)
Ожидаемый правильный результат.

скриншот или любой другой документ, который может помочь прояснить

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

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


Приоритет (Priority) -

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

важности выполнения задач для БИЗНЕСА.

Severity - Показывает технологическую степень

влияния БАГА на ВСЮ СИСТЕМУ.

в нерабочее состояние, в результате которого дальнейшая работа с

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

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

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

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

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

исправлена как можно быстрее, т.к. ее наличие является критической

для проекта.

P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.

P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

Порядок исправления ошибок по их приоритетам:

High -> Medium -> Low

учета информации, созданное для:

- Учета и контроля над

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

Design
Severity and Priority difference
Severity and Priority
Severity vs Priority на

пальцах