Перейти на PRO

Как вы определяете критерии тестирования при полном отсутствии каких-либо требований?

Тип вопроса: Тестовая документация Вероятность: 10% Категория: QA Тестировщик

Ответ

В ситуации полного отсутствия формальных требований я строю тестовые сценарии на основе комбинации следующих источников и принципов:

Ключевые подходы:

  1. Сравнительный анализ (Competitive Analysis): Тестирование и изучение поведения прямых аналогов или похожих продуктов для формирования гипотез об ожидаемом функционале.
  2. Отраслевые стандарты и нормативы:
    • WCAG — для проверки доступности веб-интерфейсов.
    • ISO 25010 — как модель качества программного обеспечения.
    • RFC-стандарты — для сетевых протоколов.
  3. Основные принципы UX/UI: Проверка на соответствие интуитивно понятным паттернам (логичность потока, ясность сообщений об ошибках, консистентность).
  4. Прямая коммуникация: Инициативное общение с заказчиком или продукт-менеджером для уточнения бизнес-целей и ожиданий.
  5. Исследование существующей системы: Если это доработка, тщательно анализирую текущее поведение (reverse engineering).

Почему это работает: Такой подход смещает фокус с проверки «как должно быть по документу» на исследование «как система ведет себя сейчас» и «как это соотносится с общепринятыми нормами».

Пример: Эвристическое тестирование формы логина

# Псевдокод/логика проверок для формы входа без требований
def explore_login_form(page):
    """Исследовательское тестирование формы входа на основе эвристик."""
    findings = []

    # Эвристика 1: Наличие обязательных полей
    if not page.has_field("username"):
        findings.append("Отсутствует поле для имени пользователя/email")
    if not page.has_field("password"):
        findings.append("Отсутствует поле для пароля")

    # Эвристика 2: Безопасность (пароль должен маскироваться)
    if not page.password_field_is_masked():
        findings.append("Текст пароля отображается открыто")

    # Эвристика 3: Наличие понятного действия
    if not page.has_button(["Login", "Sign In", "Войти"]):
        findings.append("Отсутствует четко обозначенная кнопка отправки формы")

    # Эвристика 4: Базовая валидация ввода
    page.fill("username", "invalid-email")
    page.submit()
    if not page.shows_validation_error():
        findings.append("Отсутствует валидация некорректного формата логина")

    return findings

Результатом такого исследования становится де-факто набор требований, который можно задокументировать и согласовать.

Ответ 18+ 🔞

Вот, смотри, как я действую, когда от меня требуют протестировать что-то, а на руки дают нихуя — ни ТЗ, ни спецификаций, один чистый воздух и доверчивый взгляд менеджера. Не, ну а хули делать-то? Сидеть и ныть? Так я не из таких, блядь.

Я беру и строю проверки из того, что есть под рукой, как заправский МакГайвер. Вот мои священные источники истины, когда документов — ноль ебать:

На чём базируюсь, когда нихуя не понятно:

  1. Гляжу на соседей (Competitive Analysis): Беру прямых конкурентов или просто похожие сервисы и начинаю их долбить. Смотрю, как у них всё устроено. Если у всех кнопка «Купить» зелёная и справа, а у нашего продукта она серая и слева — это уже повод задуматься, не ебнулись ли дизайнеры.
  2. Цепляюсь за стандарты, блядь: Это же святое! Если интерфейс — лезу в WCAG проверять, доступный ли он для людей. Если про качество софта думать — ISO 25010 в руки. Сети, протоколы? RFC-стандарты, ёпта! Это как закон, его нарушать — себя не уважать.
  3. Здравый смысл и принципы UX: Ну вот смотри, если я нажимаю на крестик, а меня не закрывает, а кидает на главную — это же пиздец, да? Или если сообщение об ошибке написано технарским языком, который нихуя не понятен обычному пользователю. Вот за такое и цепляюсь.
  4. Иду и спрашиваю: Да-да, иногда надо просто встать с жопы, подойти к продакту или заказчику и спросить: «Слушай, а какую вообще хуйню мы тут пытаемся сделать? Какая бизнес-цель?». Часто выясняется, что они и сами не до конца в курсе, но хоть какое-то направление появляется.
  5. Ковыряюсь в том, что уже есть: Если это новая фича для старой системы, то я первым делом изучаю, как эта система живёт сейчас. Что куда кликается, какие данные куда летят. Фактически, реверс-инжиниринг, блядь.

А почему это работает? Потому что я перестаю искать «как должно быть по бумажке» и начинаю смотреть на вещи трезво: «Как эта штука работает сейчас?» и «Насколько это вообще адекватно с точки зрения любого нормального человека?».

Вот, например, как я могу наброситься на форму логина, если про неё нихуя не сказано:

# Псевдокод/логика проверок для формы входа без требований
def explore_login_form(page):
    """Исследовательское тестирование формы входа на основе эвристик."""
    findings = []

    # Эвристика 1: Наличие обязательных полей
    if not page.has_field("username"):
        findings.append("Отсутствует поле для имени пользователя/email")
    if not page.has_field("password"):
        findings.append("Отсутствует поле для пароля")

    # Эвристика 2: Безопасность (пароль должен маскироваться)
    if not page.password_field_is_masked():
        findings.append("Текст пароля отображается открыто")

    # Эвристика 3: Наличие понятного действия
    if not page.has_button(["Login", "Sign In", "Войти"]):
        findings.append("Отсутствует четко обозначенная кнопка отправки формы")

    # Эвристика 4: Базовая валидация ввода
    page.fill("username", "invalid-email")
    page.submit()
    if not page.shows_validation_error():
        findings.append("Отсутствует валидация некорректного формата логина")

    return findings

И вот из этого всего бардака и импровизации рождается, понимаешь, фактический список требований. Я его оформляю, несу всем показывать и говорю: «Вот, блядь, как система себя ведёт. Давайте теперь решим, это баг или фича, и как нам жить дальше». И все такие: «О, а ведь и правда, мы об этом не подумали!». Вот так и работаем, в рот меня чих-пых.

© ХакСобесов, 2026
support@hacksobesov.com