Профессия тестировщика: роли, грейды, собеседования, развитие

Это последняя статья трека, и она про людей, а не про техники. Предыдущие четырнадцать статей отвечали на вопрос «как тестировать». Эта отвечает на вопрос «кем при этом быть» — и он оказывается сложнее, потому что ответ меняется каждые несколько лет, а профессия по-прежнему страдает от собственной репутации «входа в IT за три месяца».

Сразу оговорка про аудиторию. Статья написана для двух читателей одновременно: для тестировщика, который строит карьеру, и для разработчика, который хочет понять, зачем в команде отдельный человек и как с ним работать. Там, где взгляды расходятся, я буду это отмечать явно — расхождения здесь не косметические.

Что тестировщик на самом деле продаёт

Начнём с честного определения ценности, потому что от него зависит всё остальное — грейды, зарплата, вопросы на собеседовании.

Тестировщик не продаёт «найденные баги». Баг — это побочный продукт. Тестировщик продаёт информацию для принятия решения о рисках: можно ли выкатывать, где именно продукт хрупкий, что сломается, если пойти этим путём, и сколько будет стоить проверить остальное. Именно так это формулирует Джеймс Бах и школа context-driven testing — тестирование как исследование, результат которого знание, а не отметка «проверено» (satisfice.com/blog).

Разница практическая. Человек, который продаёт баги, на вопрос «мы готовы к релизу?» отвечает «я нашёл 12 дефектов, 3 критичных». Человек, который продаёт информацию о рисках, отвечает: «Основной сценарий оплаты проверен на трёх провайдерах, работает. Не проверен возврат средств при частичной отмене — там переписали логику вчера, и это самая большая непокрытая зона. Если релиз нужен сегодня, я бы выкатил с отключённой частичной отменой; если есть день — проверю». Второй ответ стоит в разы дороже, и разница между грейдами в значительной степени — это разница между этими двумя ответами.

Взгляд разработчика. Со стороны разработки первый тип QA выглядит как налог: человек, генерирующий тикеты, часть из которых — не баги, а непонимание. Второй тип выглядит как усилитель: он экономит вам ночь дежурства. Если вы разработчик и вам «не нужен QA» — велика вероятность, что вы просто не работали со вторым типом.

Карта ролей: кто вообще есть в QA

Слово «тестировщик» покрывает десяток разных профессий с разным ежедневным трудом. Вот карта — не для заучивания, а чтобы понимать, куда двигаться.

Несколько важных уточнений к этой карте.

QA Automation и SDET — не синонимы. Automation Engineer автоматизирует проверки существующего продукта. SDET (Software Development Engineer in Test) — это разработчик, чей продукт — инструменты качества: фреймворки, генераторы данных, моки внешних систем, инфраструктура прогонов. Разница как между пользователем библиотеки и её автором. Зарплатная вилка SDET обычно совпадает с вилкой обычного разработчика того же грейда, и требования на собеседовании тоже разработческие: алгоритмы, дизайн, конкурентность.

«Ручной тестировщик» — плохое название для хорошей работы. Проблема не в слове «ручной», а в том, что рынок читает его как «умеет только кликать». Исследовательское тестирование — интеллектуально самая сложная часть профессии, её нельзя автоматизировать по определению (см. статью про ручное тестирование). Но продавать себя как «ручного тестировщика» в 2020-х — значит соглашаться на нижнюю вилку. Продавайте себя как человека, который находит то, что автотесты не ловят, и покажите, как именно вы это делаете.

Quality Engineer — тренд последних лет. Роль, где человек не тестирует продукт сам, а делает так, чтобы команда тестировала хорошо: настраивает пайплайны, учит разработчиков тест-дизайну, чинит тестопригодность, разбирает инциденты. Ближе к DevOps по духу (см. трек DevOps).

Как профессия менялась и куда идёт

Главный вывод из этой линии: дешевеет исполнение, дорожает суждение. Написать сто тестов на форму — задача, стоимость которой падает каждый год. Понять, что из этой сотни имеет смысл, а что создаст болото поддержки, — навык, который дорожает. Стройте карьеру вокруг второго.

Грейды: что реально стоит за словами junior/middle/senior

Годы опыта — плохой предиктор. Человек с восемью годами может пять раз повторить один и тот же год. Смотрите на профиль компетенций.

Расшифровка по уровням — с примером одной и той же задачи.

Задача: «В личном кабинете добавили экспорт истории заказов в CSV. Протестируй».

• Junior. Выполняет по понятной постановке. Проверит, что кнопка есть, файл скачивается, открывается в Excel, колонки соответствуют макету. Заведёт баг, если что-то не так. Задаст вопрос, если постановка непонятна (и это хорошо — junior, который не задаёт вопросов, опаснее). Ключевой навык: аккуратность и умение довести до конца.
• Middle. Видит границы: пустая история, 100 000 заказов, кириллица и запятые внутри полей, BOM для Excel, таймзона в датах, параллельный экспорт, права доступа — можно ли выгрузить чужие заказы, подменив id. Сам строит чек-лист по технике тест-дизайна, не дожидаясь ТЗ. Автоматизирует то, что стоит автоматизировать.
• Senior. Начинает с другого вопроса: сколько это стоит и что здесь самое дорогое, если сломается. Экспорт персональных данных — значит, главный риск не «кривая колонка», а утечка чужих заказов и выгрузка, кладущая базу. Пойдёт к разработчику спросить, идёт ли выгрузка потоком или собирается в память; предложит ограничение по объёму до релиза; автоматизирует только проверку прав и контракт файла, остальное закроет одной исследовательской сессией. Умеет сказать «это тестировать не будем, вот почему» и защитить решение.
• Lead / Staff. Спрашивает, почему такие фичи каждый раз проходят через ручной цикл: нет ли системной дыры — например, отсутствия типовых проверок авторизации на уровне фреймворка. Чинит класс проблем, а не одну фичу. Работает с несколькими командами, отвечает за стоимость качества в целом.

Взгляд разработчика. У разработчиков грейд растёт по оси «сложность систем, которые я могу построить». У тестировщиков — по оси «неопределённость, в которой я могу принять решение». Поэтому senior QA и senior dev — разные звери, и разработчик, перешедший в QA, часто оказывается сильным middle: техника есть, а навыка работы с неполной информацией и с людьми — ещё нет.

Ловушка «вечного middle»

Самый частый застой: человек отлично автоматизирует, знает фреймворк, быстро пишет тесты — и не растёт годами. Причина почти всегда одна: он остаётся исполнителем чужих решений о том, что тестировать. Senior начинается там, где вы приносите решение, а не запрос на решение.

Практический переход выглядит так. Вместо «какой приоритет у этого бага?» — «я поставил Major: воспроизводится у 100% пользователей мобильного веба, обход есть, но неочевидный; если не согласны, снижу до Minor». Вместо «автоматизировать ли этот сценарий?» — «сценарий стабильный, гоняем вручную раз в спринт по 40 минут, автоматизация обойдётся в 2 дня, окупится за квартал — беру». Разбор такой экономики — в статье про стратегию автоматизации.

Профили навыков: почему «просто глубже» не работает

Практический вывод: вторая ножка гребёнки почти никогда не должна быть вторым UI-фреймворком. Знать и Playwright, и Cypress — это не два навыка, а один с двумя синтаксисами. А вот «автоматизация + предметная область платежей» или «автоматизация + перформанс» — это действительно редкое сочетание.

Как выбирать, куда углубляться:

Верхний правый квадрант — это то, что делает вас дорогим на рынке. Нижний правый — гигиена: без API и SQL вас просто не будут рассматривать, но и преимущества они не дают. Левая половина — то, что делает вас ценным здесь и сейчас и бесполезным при смене работы; иметь такое нормально, строить на этом карьеру — нет.

Собеседования: как это устроено

Типичная воронка в компании средних размеров.

Дальше — по типам задач, с разбором того, что интервьюер на самом деле проверяет.

Задача 1: «Протестируй поле ввода промокода»

Классика. Проверяют не эрудицию, а систематичность: есть ли у вас метод или вы выдаёте случайные идеи, пока не кончатся.

Плохой ответ — поток сознания: «ну, пустое значение, длинное значение, спецсимволы, SQL-инъекция…». Хороший ответ идёт по осям и начинается с вопросов.

Последний шаг — то, что отличает senior. Скажите вслух: «При двух часах я проверю только денежные и защитные сценарии, комбинаторику форматов отложу — её дешевле закрыть юнит-тестами валидатора». Интервьюер выдохнет.

Конкретика по промокоду — таблица классов эквивалентности, которую не стыдно показать на доске:

Обратите внимание: колонка «Риск» — половина ценности таблицы. Без неё это список, с ней — план.

Задача 2: найди баг и напиши тесты

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

def apply_discount(total: float, percent: int) -> float:
    """Применяет процентную скидку к сумме заказа."""
    if percent > 0:
        return total - total * percent / 100
    return total

Что здесь не так — по убыванию важности:

1. Нет верхней границы процента. percent=150 даст отрицательный итог — магазин доплатит покупателю. Это денежный дефект, severity Critical.
2. Нет проверки отрицательной суммы. total=-100 тихо проходит.
3. float для денег. Классика: apply_discount(0.1 + 0.2, 0) уже даёт 0.30000000000000004. Деньги считают в Decimal или в минорных единицах (копейках) целыми числами — см. «What Every Computer Scientist Should Know About Floating-Point Arithmetic».
4. Округление не определено. 33% от 10.00 — это 6.70 или 6.7000000000001? Правило округления должно быть в требованиях, а не в реализации случайно.

Тесты на pytest, которые стоит написать на доске:

from decimal import Decimal
import pytest

# Позитивные границы: 0% ничего не меняет, 100% обнуляет
@pytest.mark.parametrize(
    "total, percent, expected",
    [
        (Decimal("100.00"), 0, Decimal("100.00")),
        (Decimal("100.00"), 1, Decimal("99.00")),
        (Decimal("100.00"), 99, Decimal("1.00")),
        (Decimal("100.00"), 100, Decimal("0.00")),
    ],
)
def test_valid_discounts(total, percent, expected):
    assert apply_discount(total, percent) == expected


# Невалидный процент должен падать явно, а не тихо портить деньги
@pytest.mark.parametrize("percent", [-1, 101, 1000])
def test_invalid_percent_rejected(percent):
    with pytest.raises(ValueError):
        apply_discount(Decimal("100.00"), percent)


# Инвариант: итог никогда не отрицателен и не больше исходной суммы.
# Свойство важнее любого числа примеров — оно ловит то, что мы не придумали.
def test_result_within_bounds():
    for percent in range(0, 101):
        result = apply_discount(Decimal("57.33"), percent)
        assert Decimal("0.00") <= result <= Decimal("57.33")

Сильный ход на собеседовании — сказать после этого: «а ещё я бы закрыл это property-based тестом через Hypothesis, потому что перебор диапазона — бедный родственник настоящих свойств» (hypothesis.readthedocs.io). Детали — в статье про юнит-тесты.

Задача 3: почини флаки-тест

Дают что-то в таком духе и просят объяснить, почему он падает раз в двадцать прогонов.

// Так писать не надо — это источник флаки
test('заказ создаётся', async ({ page }) => {
  await page.goto('/orders/new');
  await page.click('.btn-primary');          // селектор по стилю
  await page.waitForTimeout(2000);            // «подождём, обычно хватает»
  const rows = await page.$$('.order-row');
  expect(rows.length).toBe(1);                // зависит от состояния БД
});

Разбор, который хочет услышать интервьюер:

• .btn-primary — селектор, привязанный к оформлению: смена темы ломает тест, а второй primary-кнопки достаточно, чтобы кликнуть не туда.
• waitForTimeout — фиксированное ожидание. На загруженном CI-агенте двух секунд не хватит, а на быстром вы просто теряете время в каждом прогоне.
• rows.length === 1 предполагает пустую базу — тест не изолирован и падает при параллельном прогоне.

Починенная версия:

test('заказ создаётся', async ({ page, request }) => {
  // 1. Изоляция: свой пользователь на каждый прогон, состояние готовим по API
  const user = await createUserViaApi(request);
  await loginAs(page, user);

  await page.goto('/orders/new');
  // 2. Семантические локаторы: роль и текст, а не классы
  await page.getByRole('button', { name: 'Создать заказ' }).click();

  // 3. Ожидание условия, а не времени — Playwright сам ретраит до таймаута
  await expect(page.getByRole('row', { name: /Заказ №/ })).toHaveCount(1);
});

Три принципа, которые вы этим показываете: изоляция данных, семантические локаторы, ожидание состояния вместо сна. Подробно — в статье про E2E и про флаки в CI.

Задача 4: SQL и API

Почти всегда спрашивают. Уровень — не аналитический, а прикладной: подготовить данные, проверить результат, найти расхождение.

-- Типичная проверка: не задвоились ли начисления бонусов после релиза.
-- Ищем пользователей с несколькими одинаковыми транзакциями в одну минуту.
SELECT
    user_id,
    amount,
    date_trunc('minute', created_at) AS minute,
    COUNT(*) AS cnt
FROM bonus_transactions
WHERE created_at >= NOW() - INTERVAL '1 day'
GROUP BY user_id, amount, date_trunc('minute', created_at)
HAVING COUNT(*) > 1
ORDER BY cnt DESC
LIMIT 50;

Что должно быть в голове: JOIN всех видов, GROUP BY / HAVING, оконные функции хотя бы на уровне узнавания, понимание индексов и того, почему ваш запрос на проде положит реплику. Основа — в треке по базам данных.

По API проверяют: коды ответов, идемпотентность, работу с токенами, чтение OpenAPI-схемы, умение воспроизвести баг через curl. См. статью про тестирование API.

Задача 5: конфиг CI

Для позиций с автоматизацией часто просят «набросать, как это будет запускаться». Достаточно вот такого — важно не знание синтаксиса наизусть, а понимание структуры прогона.

# .github/workflows/tests.yml — минимальный, но осмысленный пайплайн
name: tests
on: [push, pull_request]

jobs:
  unit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.12" }
      - run: pip install -r requirements.txt
      # Быстрый барьер: если юниты красные, дальше не тратим минуты
      - run: pytest tests/unit -q --junitxml=unit.xml

  e2e:
    needs: unit                 # запускаем только после зелёных юнитов
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        shard: [1, 2, 3, 4]     # параллелим прогон на 4 шарда
    steps:
      - uses: actions/checkout@v4
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test --shard=${{ matrix.shard }}/4
      - uses: actions/upload-artifact@v4
        if: failure()           # артефакты нужны именно при падении
        with:
          name: traces-${{ matrix.shard }}
          path: test-results/

Хороший комментарий вслух: «повторный запуск упавших тестов я бы сюда не ставил по умолчанию — он маскирует флаки; лучше карантин с отдельным отчётом».

Поведенческие вопросы, которые решают исход

Технику проверяют все, а отказы чаще случаются здесь.

• «Расскажите про конфликт с разработчиком». Проверяют, умеете ли вы спорить о проблеме, а не о людях. Плохой ответ: «он не хотел чинить баг, я пошёл к менеджеру». Хороший: «мы разошлись в severity; я собрал данные — сколько пользователей затронуто и есть ли обходной путь — и мы решили по данным, а не по громкости».
• «Баг ушёл в прод. Что делали?» Проверяют отношение к ошибкам. Нужен ответ без поиска виноватых: что произошло, как чинили, что изменили в процессе, чтобы класс проблем не повторился.
• «Релиз завтра, вы не успеваете проверить всё». Проверяют, умеете ли вы приоритизировать и коммуницировать неполноту. Верный каркас: что проверено, что не проверено, какой риск от непроверенного, какие есть варианты (сдвинуть, выкатить под флагом, выкатить на 5% трафика).
• «Как вы поймёте, что ваша работа полезна?» Проверяют, не измеряете ли вы себя количеством багов (см. следующий раздел).

Красные флаги — в обе стороны

От кандидата интервьюер настораживается, когда: тестирование описывается как «проверить по тест-кейсам»; на вопрос «что не будете тестировать» ответ «всё надо тестировать»; ответственность за качество перекладывается целиком на себя («я — последний рубеж») или целиком на разработчиков; покрытие называется целью.

Кандидату стоит насторожиться, когда компания говорит: «у нас QA отвечает за качество» (значит, крайний назначен заранее); «разработчики тесты не пишут» (значит, вы будете латать дно пирамиды E2E-тестами); «нужно поднять покрытие до 80%» как самостоятельная задача; «регресс гоняем вручную две недели перед релизом». Про то, почему метрика покрытия — плохая цель, подробно в статье про тесты в CI.

Что спрашивать самому

Короткий список, который многое вскрывает за пять минут:

1. Сколько времени проходит от коммита до прода и что в этом пути занимает больше всего?
2. Кто чинит упавший тест в общей ветке — автор изменения или дежурный QA?
3. Какая доля прогонов CI падает не из-за реальных дефектов? (Если цифры нет — её никто не измеряет.)
4. Что произошло с последним крупным инцидентом и что изменилось после него?
5. Есть ли у команды возможность сказать «не выкатываем» и что для этого нужно?
6. Как выглядит рост на этой позиции через два года — с примерами реальных людей?

Как оценивают работу QA (и почему почти все метрики врут)

Тема, которая напрямую бьёт по карьере: по чему вас будут мерить на ревью.

Практический вывод для карьеры: не позволяйте оценивать себя по числу багов. Предложите замену сами — например, отчёт вида «какие риски мы закрыли в этом квартале, какие сознательно оставили открытыми, что из открытого выстрелило». Это разговор senior-уровня, и он же лучший способ показать, что вы им стали.

Взгляд разработчика. Разработчику метрики QA кажутся чужой бухгалтерией — ровно до момента, когда «поднять покрытие до 80%» становится задачей в вашем спринте. Плохая метрика в QA всегда через месяц превращается в бессмысленную работу для разработки. Стоит участвовать в выборе метрик, а не наблюдать со стороны.

Обучение и сертификации: что стоит времени

ISTQB Foundation. Честно: это словарь, а не навык. Даёт общую терминологию и структуру (полезно — половина споров в командах происходит из-за разного понимания слов «регресс» и «приёмка»), но не учит тестировать. В некоторых странах и в аутсорсе на неё смотрят при найме, в продуктовых компаниях — почти нет. Разумная стратегия: прочитать силлабус (istqb.org) за пару вечеров ради терминологии, сдавать — только если этого требует конкретный работодатель.

Что действительно двигает:

• Lisa Crispin, Janet Gregory, «Agile Testing» и «More Agile Testing» — как тестирование живёт внутри команды, а не рядом с ней.
• Elisabeth Hendrickson, «Explore It!» — лучшая книга про исследовательское тестирование, тонкая и практичная.
• Gerald Weinberg, «Perfect Software: And Other Illusions About Testing» — про психологию вокруг тестирования и ожидания менеджмента.
• Michael Bolton и James Bach, материалы Rapid Software Testing (rapid-software-testing.com).
• Kent Beck, «Test-Driven Development: By Example» — даже если вы не пишете продуктовый код, полезно понимать, как думает разработчик; см. также статью про TDD и BDD.
• Официальная документация инструментов, которыми пользуетесь ежедневно. Прочитанная целиком документация Playwright или pytest даёт больше, чем десять курсов.

Публичное портфолио. Работает лучше сертификатов: небольшой репозиторий с автотестами на открытое API, разбор реального бага с воспроизведением, несколько статей о том, как вы решали конкретную проблему. Интервьюеру нужен не объём — ему нужно увидеть ход вашей мысли.

Как писать резюме, чтобы его читали

Главная ошибка — перечисление инструментов вместо результатов. Сравните.

Было:

Тестирование веб-приложения. Написание тест-кейсов. Автоматизация на Selenium. Работа с Jira, TestRail, Postman.

Стало:

Тестирование биллинга (Python, pytest, Playwright, PostgreSQL). — Перевёл регресс с ручного прогона (2 дня на релиз) на автотесты: 40 сценариев, прогон 12 минут в CI, релизный цикл сократился с недели до двух дней. — Снизил долю флаки-падений в E2E с 18% до 3% за счёт изоляции тестовых данных и перехода на семантические локаторы. — Нашёл и описал дефект двойного списания при повторной отправке платежа (гонка на стороне API); после починки внедрили идемпотентные ключи.

Второй вариант — это те же три года работы, но в нём видно инженера. Каждый пункт — «что было, что сделал, что изменилось в цифрах». Цифры не обязаны быть идеальными, они обязаны быть честными: на собеседовании про каждую спросят.

План развития на год

Конкретика вместо «учить всё подряд».

Junior → Middle (примерно 9–12 месяцев).

1. Освоить технический минимум до автоматизма: HTTP и REST, чтение OpenAPI-схемы, SQL с джойнами и агрегатами, чтение логов, базовый Git, умение поднять сервис локально в Docker.
2. Довести тест-дизайн до рефлекса: классы эквивалентности и границы должны применяться без напоминания (разбор техник).
3. Научиться писать баг-репорт, который чинят без уточняющих вопросов (как именно).
4. Написать первые 20–30 автотестов и — обязательно — пожить с ними три месяца, чиня падения. Боль поддержки учит быстрее любого курса.

Middle → Senior (1,5–2 года).

1. Научиться считать: сколько стоит проверка, сколько стоит пропуск дефекта, когда автоматизация окупается. Начните с одной честной оценки в квартал.
2. Взять ответственность за область целиком: не «мои тест-кейсы», а «риски этого сервиса».
3. Освоить одну вертикаль всерьёз — нагрузку (статья), безопасность (статья) или доступность (статья).
4. Начать влиять на код продукта: тестопригодность, логи, флаги, точки расширения. Это требует умения говорить с разработчиками на их языке — отсюда полезность языковых треков (TypeScript, Go) и принципов разработки.
5. Наставничество: объяснить junior’у, почему тест плохой, — лучший способ понять это самому.

Senior → дальше. Здесь развилка, и её стоит выбирать осознанно:

Ни одна из веток не «выше» других. Выше та, где вы будете работать десять лет без ненависти к понедельникам.

Профессиональные болезни и как их не заработать

Выгорание от регресса. Многократный ручной прогон одного и того же — самая изматывающая часть работы, и она же чаще всего приводит к уходу из профессии. Если у вас регресс занимает больше 20% времени и никто не двигается к автоматизации — это не ваша лень, это организационная проблема. Поднимайте её с цифрами: «за квартал я потратил 15 дней на ручной регресс, это N рублей».

Синдром вратаря. Ощущение «если я пропущу баг — я виноват». Оно разрушительно и вдобавок неверно: качество — свойство процесса, а не последнего человека в цепочке. Тестировщик отвечает за информацию, решение о релизе принимает бизнес. Формулировка «я сообщил о риске X, решение выкатывать принял владелец продукта» — не уклонение, а корректное распределение ролей.

Изоляция от разработки. Отдельный QA-отдел, отдельные встречи, общение через тикеты. Результат — тестировщик узнаёт о фиче последним и проверяет то, что уже поздно менять. Лечится участием в обсуждении требований до кода: дешевле всего дефект стоит там, где его ещё не написали (про цену дефекта).

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

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

Мини-итог

• Ценность тестировщика — не в найденных багах, а в информации о рисках, на основе которой принимают решения. Грейд — это масштаб неопределённости, в которой вы способны принять решение и защитить его.
• Роли в QA сильно различаются: от исследовательского тестирования до разработки инструментов. Выбирайте не по зарплате в вакансии, а по тому, какой ежедневный труд вам подходит.
• Стройте T-профиль: широкая техническая база (API, SQL, CI, логи) плюс одна настоящая глубина. Вторая глубина эффективнее всего — предметная область, а не второй фреймворк.
• На собеседовании проверяют метод, а не эрудицию: уточните контекст, назовите риски, разверните по осям, честно скажите, что делать не будете.
• Опасайтесь метрик, поощряющих объём: число багов, процент автоматизации, покрытие. Предлагайте вместо них разговор о закрытых и принятых рисках.
• Автоматизация не отменяет тестирование — она отменяет ручное повторение. Дешевеет исполнение, дорожает суждение; вкладывайтесь в суждение.

Что дальше

Трек «Тестирование программного обеспечения» на этом закончен — от карты курса и цены отсутствия тестирования до профессии целиком. Дальше логично расширять контекст вокруг качества.

• Дорожная карта портала — как связаны треки между собой и в каком порядке их проходить.
• DevOps — естественное продолжение статьи про тесты в CI: пайплайны, окружения, релизы, наблюдаемость.
• Принципы разработки — почему один код легко тестировать, а другой невозможно; тестопригодность начинается здесь.
• Базы данных — SQL, транзакции и изоляция: без этого не проверить ни один сценарий с деньгами.
• TypeScript или Go — если хотите уйти в автоматизацию или SDET и начать читать продуктовый код всерьёз.
• Продуктовый менеджмент — если развилка ведёт вас в сторону продукта: те же риски, но с точки зрения ценности, а не дефектов.
• AI-инжиниринг — как тестировать системы, у которых нет детерминированного ожидаемого результата; для QA это самая быстрорастущая новая область.

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