Виды тестирования на собеседовании системного аналитика

Зачем спрашивают на собесе SA

SA участвует в приёмочном тестировании, пишет тест-кейсы, согласует AC. На собесе SA: «отличие unit и integration», «когда regression», «что такое UAT». Senior — нюансы testing strategy, automation, contract testing.

Уровни тестирования

Unit. Тестирует одну функцию / класс изолированно. Все зависимости — моки.

def test_calculate_total():
    cart = Cart()
    cart.add_item(Item("apple", 100))
    cart.add_item(Item("bread", 50))
    assert cart.total() == 150

Быстрые (мс), много (тысячи), запускаются на каждом коммите.

Integration. Тестирует взаимодействие модулей: с БД, с очередью, с другим сервисом.

• Сервис ↔ БД (с реальной тестовой БД).
• API ↔ внешний сервис (с моком или test instance).
• Несколько модулей вместе.

Средняя скорость (секунды), сотни тестов.

System / End-to-End. Тестирует всю систему через UI / API.

Открыть страницу → залогиниться → положить в корзину → оформить → проверить email

Медленные (минуты), мало (десятки), хрупкие.

Acceptance. Проверяет соответствие requirements / AC.

• UAT (User Acceptance Test) — стейкхолдеры проверяют.
• BAT (Business Acceptance Test) — бизнес проверяет.

Виды по знанию системы

Black box. Тестировщик не знает внутренностей. Тестирует через input / output.

White box. Тестировщик знает код. Может проверить пути выполнения, edge cases в реализации.

Gray box. Знание частичное (схема БД, контракт API).

В современной разработке:

• Dev пишет unit + integration (white box).
• QA пишет E2E (gray / black).
• Бизнес делает UAT (black).

Виды по цели

Functional — что должна делать.

• Smoke. «Дым из выхлопа» — критические сценарии. Прошёл — система живая.
• Sanity. Проверяет конкретный bug-fix или фичу.
• Regression. После изменений — не сломали ли существующее.
• Acceptance. Бизнес-правила.

Non-functional — характеристики.

• Performance / Load. SLA по времени отклика при нагрузке.
• Stress. За пределами лимитов — как падает.
• Volume. Большие данные.
• Endurance / Soak. Долгая работа без leaks.
• Security. Penetration testing, OWASP проверки.
• Usability. Удобство.
• Accessibility. WCAG.
• Compatibility. Браузеры, OS, devices.
• Recovery. Восстановление после падений.
• Localization. Перевод, форматы дат / валют.

Test pyramid и trophy

Test Pyramid (Mike Cohn).

        E2E   (мало)
       ▲▲▲▲
      Integration (среднее)
     ▲▲▲▲▲▲▲▲▲▲▲
    Unit (много)
   ▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲

Логика: unit — быстрые, дешёвые, надёжные. E2E — медленные, дорогие, хрупкие. Большинство тестов внизу.

Test Trophy (Kent C. Dodds).

       E2E
       ▲▲▲
       Integration  (больше веса)
      ▲▲▲▲▲▲▲▲▲▲▲
       Unit        (меньше)
       ▲▲▲▲▲
       Static
       ▲▲▲▲▲▲▲▲▲▲▲▲

Логика: на frontend integration tests дают больше уверенности при разумной скорости. Static (TS, ESLint) ловит баги без тестов.

В РФ-командах часто свой mix — pyramid для backend, trophy для frontend.

Роль SA в тестировании

На стадии анализа:

• Пишет AC (по сути — тест-кейсы в зачаточной форме).
• Описывает edge cases в требованиях.
• Согласует test plan с QA.

На стадии разработки:

• Отвечает на вопросы QA по требованиям.
• Уточняет ambiguous AC.

На стадии тестирования:

• Помогает с интеграционным test data setup.
• Проводит UAT с бизнесом или фасилитирует.
• Принимает приёмку (Demo).

После релиза:

• Анализирует production bugs — что упустили в требованиях.
• Обновляет AC / документацию.

Частые ошибки

Тестировать только happy path. Edge cases (empty input, large input, концурентность) — критичны.

Игнорировать non-functional. «Медленно» / «нестабильно» — это баг. Performance/load tests обязательны.

Только E2E. Хрупкие, медленные. Test pyramid важна.

Пропускать regression. После каждого release — авто-regression suite минимум.

UAT в last minute. Бизнес видит фичу за день до прода → нет времени менять. Подключать раньше.

Mock везде. Integration tests с реальной БД важнее, чем 100 unit с моком БД.

Не покрывать failure scenarios. «Сервис недоступен», «timeout» — типичные проблемы прода.

Связанные темы

• Acceptance Criteria Given/When/Then на собесе SA
• User Stories и Acceptance Criteria для SA
• Scrum vs Kanban для SA
• ТЗ vs SRS на собесе SA
• Подготовка к собесу системного аналитика

FAQ

Severity vs priority?

Severity — степень дефекта (как сильно ломает). Priority — насколько срочно фиксить. Critical severity + low priority — баг ломает систему, но в обходной ситуации; до релиза — не блокер.

Что такое test plan?

Документ: scope, approach, resources, schedule. Высокоуровневый. Test cases — внутри test plan.

Можно ли автоматизировать UAT?

Частично. Автоматизировать E2E flows. Но финальное «бизнес доволен» всегда manual.

Это официальная информация?

Нет. Статья основана на ISTQB syllabus, материалах ISO/IEC/IEEE 29119 (testing standards).

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.