Как вы определяете ожидаемое поведение программы (software) для составления тест-кейсов?

«Как вы определяете ожидаемое поведение программы (software) для составления тест-кейсов?» — вопрос из категории Тестовая документация, который задают на 10% собеседований QA Тестировщик. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Определение ожидаемого поведения программы — это процесс анализа нескольких взаимодополняющих источников информации для формирования однозначных и проверяемых критериев.

Основные источники и их роль: Источник Что дает Пример использования в тестах
Требования (SRS, User Stories) Формальное описание что должна делать система. Основы для happy path и основных функциональных тестов.
Документация (API Docs, мануалы) Технические детали как система это делает. Тестирование граничных значений, форматов запросов/ответов.
Стандарты и Best Practices Отраслевые нормы и соглашения. Тесты на безопасность, доступность, производительность.
Аналогичные системы Референсное поведение. Формирование гипотез при отсутствии других источников.
Коммуникация с командой Уточнение неявных требований. Разрешение противоречий, прояснение бизнес-логики.

Процесс на практике:

  1. Сбор данных из доступных источников.
  2. Анализ на противоречия и неоднозначности.
  3. Уточнение спорных моментов у аналитиков или разработчиков.
  4. Формализация в виде четких, проверяемых утверждений (assertions).

Пример: Тестирование сценария логина

import requests
# Ожидаемое поведение основано на требованиях (редирект) и best practices (безопасность).
def test_successful_login_flow():
    """
    Ожидаемое поведение после успешного ввода учетных данных:
    1. HTTP-статус 302 (Found) для перенаправления. (Из требований)
    2. Заголовок Location указывает на страницу /dashboard. (Из требований)
    3. В ответе установлен cookie сессии. (Best practice для аутентификации)
    4. Сам cookie помечен как HttpOnly и Secure. (Best practice безопасности)
    """
    login_url = "https://app.example.com/login"
    credentials = {"username": "valid_user", "password": "correct_password"}

    # Отправляем запрос, отключив автоматическое следование редиректу
    response = requests.post(login_url, data=credentials, allow_redirects=False)

    # 1. Проверка редиректа
    assert response.status_code == 302, "После успешного логина должен быть редирект (302)"

    # 2. Проверка цели редиректа
    redirect_location = response.headers.get("Location")
    assert redirect_location == "/dashboard", f"Ожидался редирект на /dashboard, а не на {redirect_location}"

    # 3. Проверка наличия cookie сессии
    session_cookie = response.cookies.get("session_id")
    assert session_cookie is not None, "В ответе должен быть установлен cookie сессии"

    # 4. Проверка атрибутов безопасности cookie (на примере объекта response.cookies)
    # Примечание: Детальная проверка флагов может требовать анализа raw-заголовков.
    print(f"Cookie session_id установлен: {session_cookie}")
    # Дальнейшие проверки безопасности лучше проводить через анализ заголовков Set-Cookie

Для UI-тестов эталоном часто служат утвержденные макеты дизайна (UI mockups). В случае выявления расхождения между поведением программы и ожиданиями, создается баг-репорт, который служит точкой для обсуждения и уточнения требований.