QA Engineer
  • Введение
  • FAQ
    • Качества и навыки, которыми нужно обладать тестировщику?
    • Что должен знать и уметь Midle? Что спросят на собеседовании?
    • Как происходит процесс найма?
    • Как проходить собеседование?
    • Ошибки в работе у начинающих тестировщиков
    • Как взаимодействовать с коллегами?
  • МОДУЛЬ 1. ТЕОРИЯ ТЕСТИРОВАНИЯ
    • Общее понимание тестирования
  • Виды тестирования
    • Функциональное тестирование
    • Нефункциональное тестирование
    • Тестирование связанное с изменениями
  • Уровни тестирования
  • Методы тестирования
    • Black box testing
    • White Box Testing
    • Grey box testing
  • Тест-Дизайн
  • Тестовая документация
    • Требования
      • Тестирование требований
    • Тест-план
    • Чек-лист
    • Тест-кейс
    • Баг-репорт
  • ЗАДАНИЕ. ТЕСТ
  • МОДУЛЬ 2. API (BackEnd)
    • API. Что это?
  • Архитектуры ПО
    • Монолитная архитектура
    • Микросервисная архитектура
  • Брокеры сообщений
    • Kafka
  • Клиент-серверное взаимодействие
  • Тестирование API (BackEnd)
    • REST и SOAP
    • jRPC
    • JSON
    • XML
    • Протоколы
    • Коды состояния ответов HTTP(S)
    • Логирование (Logs)
  • Swagger
  • Postman
  • ЗАДАНИЕ. ТЕСТИРОВАНИЕ API
  • МОДУЛЬ 3. FRONTEND и WEB
    • Теория FrontEnd
    • Элементы интерфейса сайта
  • Верстка
  • Основы HTML
  • CSS
  • Сети и около них
    • Идентификация ресурсов в сети (Identifying resources on the Web)
    • Веб-сервис (WS - Web service)
    • Сокет/веб-сокет (socket/websocket)
    • Рендеринг в интернете (Rendering on the Web)
  • DevTools
    • Network
    • Application
    • Source
    • Elements
    • Console
    • Performances
  • Кроссбраузерность
  • Сетевые данные
    • Сache
    • Сookie
  • МОДУЛЬ 4. SDLC и STLC
    • Жизненный цикл разработки SDLC
    • Жизненный цикл тестирования STLC
    • Модели разработки ПО
      • «V-Model»
      • «Waterfall Model» (каскадная модель или «водопад»)
      • «Agile Model» (гибкая методология разработки)
    • Agile
    • Scrum
    • Подходы к разработке/тестированию
  • МОДУЛЬ 5. БАЗЫ ДАННЫХ.
    • Теория
    • Типы БД
      • Реляционные
      • Нереляционные
    • SQL. ОСНОВЫ
      • Работа с Select * From
      • JOIN
    • Задание
  • ALL SOFT (Ознакомление)
    • Jira и Confluence
    • SOAP UI
    • Git
    • Kibana
    • Docker
    • Jenkins
Powered by GitBook
On this page
  1. Тестовая документация

Тест-кейс

PreviousЧек-листNextБаг-репорт

Last updated 1 year ago

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

Предварительные условия - что нужно сделать до проведения тестирования, например, протестировать только на устройстве Android, или только в браузере Safari. (Предварительные условия не являются обязательной частью). Шаги (Действия) – последовательность действий, которые мы должны осуществить для проверки тестируемого функционала с целью убедиться, что всё работает согласно заявленным требованиям.

Ожидаемый результат - что должно получиться по результатам наших действий.

Виды Тестовых Сценариев: Тест-кейсы разделяются по ожидаемому результату на позитивные и негативные: • Позитивный тест-кейс использует только корректные данные и проверяет, что приложение работает согласно заявленным требованиям. • Негативный тест-кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и проверяет, что вызываемая приложением функция не выполняется. (т.е. на примере формы авторизации vk.com когда мы вводим корректный логин и некорректный пароль нам выведется уведомление о том, что введены некорректные данные, т.е. осуществились проверки полей и сработал обработчик ошибок, который вывел уведомление о неправильном пароле).

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

Тест-кейс No 1. Проверка функционала формы авторизации. Шаги:

  • - Зайтинасайтzdorovr.ru.

  • - В шапке сайта в правом верхнем углу нажать на кнопку "Войти".

  • - Впоявившейсяформеавторизациивполе"Электроннаяпочта"ввестизначение

    – sramotnik1@mail.ru.

  • - Вполе"Пароль"ввестизначение–Sramota1.

  • - Нажатьнакнопку"Войти".

Тест-кейс No 2. Проверка формы авторизации без ввода логина и пароля. Шаги:

- Зайтинасайтzdorovr.ru. - В шапке сайта в правом верхнем углу нажать на кнопку "Войти". - Оставить пустыми поля логин и пароль - Нажатьнакнопку"Войти".

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

Поля "Электронная почта" и "Пароль" подсветятся красным цветом с подсказкой,

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

Отличия чек-листов от тест-кейсов

Чек-лист менее детализирован чем тестовый сценарий. Его уместно использовать тогда, когда тестовые сценарии будут избыточны. (Например, проверить функционал лайка, кол-ва просмотров записи на стене, функционал репоста).