Тестовая документация Flashcards
(38 cards)
Виды тестовой документации:
-Тест кейс
-Тест План
-Чеклист
-Баг репорт
-Отчет по тестированию
Дополнительно:
-Матрица трассировки
-Тестовая стратегия
-Тестовые сценарии
-Руководство по тестированию
-Юз кейс
План тестирования (Test Plan) - это
это ключевой документ в процессе тестирования ПО, который описывает стратегию, объем, ресурсы и график тестовых активностей. Тест-план - служит руководством для команды тестировщиков и других участников проекта, обеспечивая единое понимание целей тестирования, его объем, методов и критериев завершения.
Тест план пишет - Лид команды, также может писать рядовой QA.
Тест кейс - это и его атрибуты
подробное описание проверки, включающие в себя шаги проверки. Используются при проверки критически важного функционала и также когда в самой проверке больше одного шага выполнения.
Их пишет - рядовой QA(Редко - аналитик и менеджер). Тк это основная задача тестировщика.
1.Уникальный номер - автоматически выставляется системой
2.Заголовок - кратко и ёмко описывает точную цель тест кейса - что именно нужно проверить. Название - краткое и лаконичное.
3.Предусловие - условия, которые нужно соблюсти перед началом. Как правило, нужно авторизоваться или находиться в определенном разделе программы.
4.Шаги - последовательность шагов, которую нужно проделать
5.Ожидаемый результат тест кейса - то, что тестировщик должен получить от системы после или во время прохождения шагов.
6.Приоритет - выставляется приоритет.
7.Автор тест кейса - тот QA, который писал тест кейс и\или изменял в последний раз.
Чек лист - это и его атрибуты
простой список проверок. Менее детализированный чем тест-кейс. Часто используются для быстрых проверок функциональности и в случае, когда проверка предполагает 1-2- шага.Могут писаться перед написанием тест-кейса. Пишется, чтобы кратко наметить себе план тест кейсов и чтобы в будущем не забыть какие-то из них и просто помечать их “сделано”.
Их пишет - рядовой QA. Тк это одна из задач тестировщика. Редко - аналитик и менеджер.
-Приоритет
-Проверка
-Ор
Баг-репорт - это и его атрибуты
специальный документ, который содержит подробную информацию об ошибки, обнаруженной тестировщиком в процессе работы.
Их пишет - рядовой QA. Тк это основная задача тестировщика. Также их могут заводить любой из членов команды.
1.ID - уникальны идентификатор бага, обычно проставляется автоматически системой.
2.Заголовок - краткое описание бага. Отвечать на вопрос “Что?Где?Когда?”
3.Описание - подробное описание ошибки, включая шаги его воспроизведения.
4.Приоритет - обычно выставляет менеджер.
5.Серьезность - проставляет тестировщик.
6.Ор и Фр
7.Окружение
8.Статус - текущее состояние ошибки (новый, в работе, исправлен и тд)
9.Вложение - скрин или видео демонстрации бага.
Отчет о тестирование - это
документ, который предоставляет полную информацию о проведенном тестирование ПО, включая его результаты, выявленные дефекты, статус тестирования и рекомендации.
Их пишет - рядовой QA.
Для чего он нужен? Чтобы вся команда понимала статус текущего тестирования.
Отчет могут быть очень разными(Писаться от руки или автоматически в системе при нажатие определенных кнопок)
Техника Тест Дизайн
Техники тест дизайн необходимы, чтобы грамотно проводить проверки. С помощью техник тест дизайна проверяеться за меньшее количество проверок большой объем функциональности.
Плюсы Техник Тест Дизайна
- Увеличение покрытия тестирования. Техника тест-дизайна помогают создавать тесты, которые охватывают различные аспекты ПО, включая различные варианты использования и возможные ошибки.
2.Эффективное использование ресурсов. Позволяют оптимизировать количество тестовых случаев и ресурсы, необходимые для тестирования, снижая издержки и ускоряя процесс разработки.
3.Повышение качества ПО. Создание более полного и эффективного плана тестирования способствует выявлению ошибок и недочетов в ранние стадии разработки, что помогает улучшить качество программы и снизить возникновение проблем после выпуска в эксплуатацию.
Виды техник тест дизайна
Эквивалентное разделение, Анализ граничных значений, Переход состояний, Попарное тестирование, Предугадывание ошибок.
Эквивалентное разделение
-Подразумевает разбиение тестовых данных на классы по какому либо признаку. Этот метод имеет смысл только в том случае, если компоненты чем-то похожи и могут войти в общую группу.
-Если мы выбираем в качестве техники тест-дизайна эквивалентное разделение, это означает, что мы будем тестировать только несколько значений из каждого класса или по другому будем выбирать представителей класса.
-Эквивалентное разделение - хорошее решение для случаев, когда вы имеете дело с большим объемом входящих данных или множеством одинаковых вариантов ввода. В противном случае, возможно, имеет смысл тщательно охватить продукт тестами. Эквивалентное разделение почти всегда используется в паре со следующие техникой тест-дизайна: граничные значения.
Анализ граничных значений
При анализе граничных значений мы тоже группируем данные по эквивалентным классам, но проверяем не значения их определенного класса, а граничные значения - те, которые находятся на “границах” классов.
Когда применяется?
1)Чаще осознанное при проверки полей, где есть возможность ввода чисел.
2)Неосознанно, но логически эта логика может применяться для интеграционного тестирования. Мы проверяем отдельные элементы во время юнит-тестирования, а на следующем уровне ошибки, скорее всего, появится на “стыках” юнитов.
Переход состояний
Диаграмма перехода состояния визуализирует состояние программы в разные периоды времени и на разных этапах использования. Визуальную информацию воспринимать проще, чем текст. Таким образом, техника перехода состояний позволяет быстрее получить максимально тестовое покрытие.
Этот метод систематически изучает реакцию ПО на различные сценарии, обеспечивая правильное поведение ПО при переходах между состояниями, вызванными определенными событиями. Грубо говоря мы отрисовываем жизненный цикл событий. Эта техника тест дизайна используется реже, чем анализ граничных значений и эквивалентное разделение.
Попарное тестирование
Попарное тестирование считается самым сложным и запутанным из отобранных нами пяти техник - дизайна. И на это есть веская причина.
Попарное тестирование основано на математических алгоритмах, а именно на комбинаторике. Оно позволяет создавать уникальные пары и тестировать большое количество поступающих данных в разных сочетаниях, о расчеты могут быть сложными.
Чтобы охватить тестовыми сценариями максимум фич и при этом потратить минимальное время на тестирование, нужно правильно сопоставлять данные, комбинируя пары определенным образом на основе расчетов.
Предугадывание ошибок
Предугадывание ошибок обычно применяется вместе с другими техниками тест-дизайна. Суть этой техники в том, что тестировщик предугадывает, где могут появиться ошибки, опираясь на свой опыт, знание системы и требования к продукту. Таким образом он выявляет места, где могут накапливаться ошибки, и может уделить этим областям повышенное внимание.
TMS и его основные функции
Test Management System(система управления тестированием)
Это инструмент или платформа, где большую часть времени проводит тестировщик пр написание тестовой документации. Там хранятся наши тест-кейсы, формируют отчеты по тестирования и тд.
-Управление тест-кейсами. Создание, хранение и поддержка актуальности тест-кейсов, включая их описание и условия выполнения.
-Выполнение тестов. Запуск тестов, как ручных, так и автоматизированных и отслеживание их прогресса.
-Отчетность и анализ. Генерация отчетов о состоянии тестирования и качества ПО, анализ результатов для выявление трендов и областей для улучшения. Используется очень редко, чаще всего занимаются этим лиды.
-Интеграция с другими инструментами. Связь с системами управления проектами, инструментами автоматизации тестирования и другими системами для обмена данными и улучшения эффективности.
Тестовый прогон(Test Run) - это
процесс выполнения одного или нескольких тест-кейсов для проверки части или всего программного продукта на наличие ошибок и проверку соответствия его требованиям и спецификациям. В процессе тестового прогона могут быть задействованы как ручные, так и автоматизированные тесты.
Тестовый прогон помогает обеспечить, что ПО работает должным образом перед его релизом, уменьшает риски для бизнеса, связанные с нестабильной работой продукта, и улучшает общее восприятие качества продукта конечным пользователям.
Тестовые прогоны бывают для санити тестирования(фичи), либо смоук тестов, либо для регресса. Для санити тестирования формирует прогон назначенный QA на задачу, для смоук\регресса формирует либо лид, либо назначенный человек.
Важные аспекты тестового прогона:
-Подготовка: Перед началом тестового прогона необходима тщательная подготовка, которая включает в себя выбор тест-кейсов на основе критериев включения, настройку тестового окружения, обеспечение доступа к необходимым ресурсам и данным.
-Выполнение тестов: Во время тестового прогона тестировщики выполняют выбранные тест-кейсы, следуя их шагам и фиксируя результаты выполнения каждого шага. Для автоматизированных тестов тесты запускаются с помощью соответствующих инструментов автоматизации.
-Документирование результатов: Результаты каждого теста фиксируются для последующего анализа. Это включает в себя не только исходы успешных тестов, но и детальное описание ошибок, найденных в процессе тестирования.
-Анализ и отчетность: По завершении тестового прогона данные анализируются для оценки качества программного продукта. Результаты анализа представляются в виде отчетов, которые могут включать статистику по успешным и неуспешным тестам, обнаруженные дефекты и рекомендации по улучшению качества продукта.
-Управление дефектами: Все обнаруженные в ходе тестового прогона ошибки регистрируются в системе отслеживания дефектов (JIRA). Это позволяет разработчикам исправлять ошибки, а затем тестировщикам повторно проверять исправленные функции.
Написание тестовой документации на проекте:
- Уточнение требований - уточняем правильно ли мы поняли то или иное требование
- Дизайн тестов - придумываем как можно сократить количество тестов с минимальной потерей качества.
- Написание тест-кейсов - пишем тест - кейсы
- Ревью кейсов - перепроверка, просмотр чужой работы свежим взглядом.
Jira
- это инструмент управления рабочим процессом для команд разработчиков ПО, которые хотят систематизировать и отслеживать свою работу.
Эпик, История, Задача - это?
Эпик - это большая работа, которая состоит из множества связанных задач и историй. Требует значительного времени и ресурсов для завершения.
История - описание функциональности или особенности, которую пользователь хочет получить.
Задача - это конкретное действия или работа, необходимая для выполнения истории.
Пример Эпик, История, Задача
Бэклог - это
- это список задача, который используется для управления и планирования работы команды. Обычно тут лежат таски и баги которые мы вообще никогда не будет делать.
Возможные баги:
-Не кликабельные ссылки или кнопки
-Забытая буква Ё
-Заполнение обязательных полей
-Некорректная работа сортировки или фильтрации
-Форма не подстраивается под количество символов
-Смещение\наложение верстки
-Итоговая\конечная цена
-Отрицательное значение на месте цены или количества
-Настройка одного параметра сбрасывает несвязанный другой
-Опечатки
-Неактивный раздел тех. поддержки
Когда покрываем функционал Тест-кейсами, а когда чек листами?
Чек-листами - когда требование еще не готовы до конца, когда функционал не требует описание кейсами(слишком простой и мало шагов), для себя перед написание кейсов
Тест-кейсами - когда шагов больше 1, когда кейсов много и это критически важный функционал
