Ключевые вопросы со всех тем, которые чаще всего встречаются на технических собеседованиях QA-инженера. С развёрнутыми ответами, примерами и типичными ошибками.
Page Object — это слой, где хранятся локаторы и действия со страницей, а не бизнес-логика теста.
Так тесты остаются читаемыми: сценарий описывает поведение пользователя, а технические детали скрыты в page-классе.
Из практики: при изменении интерфейса обычно правим один Page Object, а не десятки тестов.
Вертикальное (scale up) — увеличить ресурсы одного сервера (CPU, RAM, диск). Просто, но ограничено железом и обычно сопровождается даунтаймом.
Горизонтальное (scale out) — добавить новые инстансы и распределить нагрузку. Практически без ограничений, отказоустойчиво, но требует stateless-приложения, балансера и репликации данных.
Из практики: для cloud-native приложений по умолчанию выбирают horizontal. БД часто масштабируют вертикально + read-replica горизонтально, потому что распределённая запись сложна.
Load Balancer — компонент, распределяющий входящие запросы между несколькими инстансами приложения. Может работать на L4 (TCP/UDP) или L7 (HTTP).
Алгоритмы: round-robin (по очереди), least connections (на наименее загруженный), least response time, hash (по IP/токену для sticky), weighted (с учётом мощности). Примеры: NGINX, HAProxy, AWS ELB.
Из практики: round-robin прост, но не учитывает реальную нагрузку. Least connections лучше для разнородных запросов.
Основные SQL-проверки: SELECT для сверки данных из API/UI с тем, что реально сохранилось в БД; COUNT(*) для проверки количества записей; сравнение NULL-полей и граничных значений.
Дополнительно использую JOIN для проверки связей между таблицами, GROUP BY для агрегатов, и прямые UPDATE/DELETE для подготовки тестовых данных.
Из практики: первым делом иду в базу после любого POST/PUT-запроса — это быстрее всего показывает, что реально сохранилось и нет ли расхождения с ответом API.
СУБД — программное обеспечение, которое управляет данными: создание структур, хранение, выборка, обновление, удаление, контроль доступа и обеспечение целостности.
Основные функции: выполнение SQL-запросов, транзакционность (ACID), контроль целостности через ограничения, управление параллельным доступом, резервное копирование.
Из практики: для QA важно понимать СУБД не только как хранилище, но и как слой валидации — ограничения на уровне схемы ловят дефекты, которые прошли через приложение.
SQL-БД — реляционные, хранят данные в таблицах с фиксированной схемой, поддерживают ACID-транзакции, используют SQL. Примеры: PostgreSQL, MySQL, Oracle.
NoSQL — нереляционные хранилища без жёсткой схемы, масштабируются горизонтально, но часто жертвуют частью ACID. Типы: документные (MongoDB), ключ-значение (Redis), колоночные (Cassandra), графовые.
Из практики: выбор между SQL и NoSQL зависит от структуры данных и требований к консистентности. В тестировании важно знать, какой тип БД используется, — это определяет, как и где проверять данные.
CRUD — четыре базовые операции с данными: Create, Read, Update, Delete.
В SQL им соответствуют операторы INSERT (создать), SELECT (прочитать), UPDATE (обновить) и DELETE (удалить).
Для тестирования важно понимать, какая операция выполняется на каждом шаге сценария и как проверить результат запросом к базе.
Из практики: такие проверки быстро показывают, где данные теряются или записываются не туда.
DDL — это команды для структуры базы: создать таблицу, изменить схему, удалить объект.
Типичные команды: CREATE, ALTER, DROP, TRUNCATE.
Из практики: перед релизом всегда проверяю DDL-изменения на копии боевых данных, чтобы не словить неожиданные блокировки.
DML — это команды для работы с данными внутри таблиц: добавить, обновить, удалить и выбрать записи.
Обычно сюда относят INSERT, UPDATE, DELETE и SELECT.
Из практики: при проверке DML-сценариев я всегда сверяю итоговое состояние данных в базе, а не только ответ интерфейса.
Агрегирующие функции вычисляют сводное значение по набору строк. Часто применяются с группировкой (GROUP BY) для получения агрегатов по категориям.
Сортировка осуществляется через ORDER BY. Джоины (JOIN) позволяют объединять строки из нескольких таблиц по связанным полям.
Из практики: ошибки чаще всего возникают в неверной группировке и условиях JOIN, поэтому их проверяю в первую очередь.
UNION объединяет результаты двух запросов вертикально — складывает строки из двух выборок друг за другом. Столбцы должны совпадать по количеству и типам. UNION ALL сохраняет дубликаты, UNION — удаляет.
JOIN соединяет таблицы горизонтально, объединяя столбцы на основе связанных ключей: результат — одна широкая таблица с полями из обеих.
Из практики: UNION использую чтобы объединить продажи двух регионов в один отчёт (одинаковая структура данных); JOIN — чтобы добавить к заказу имя клиента из другой таблицы (связь через ключ).
Проверяю первичные и внешние ключи, уникальные индексы, NOT NULL ограничения, CHECK-ограничения на диапазоны и enum-значения.
Смотрю, что некорректные записи не попадают в таблицы даже при прямой записи в БД в обход приложения — ограничения должны работать на уровне БД, а не только в коде.
Из практики: ограничения на уровне БД — последний рубеж обороны против грязных данных. Проверяю их через прямые INSERT/UPDATE с нарушением ограничений — каждое нарушение должно давать ошибку БД.
INNER JOIN возвращает только строки, у которых есть совпадение в обеих таблицах. LEFT JOIN — все строки левой таблицы плюс совпадения справа (или NULL, если справа нет). RIGHT JOIN — симметрично, все справа. FULL JOIN — объединение LEFT и RIGHT: все строки с обеих сторон, NULL там, где нет пары.
CROSS JOIN — декартово произведение, каждая строка слева с каждой справа. Часто нужен для генерации комбинаций.
Из практики: 80% задач решается INNER и LEFT. RIGHT почти не встречается (тот же LEFT с переставленными таблицами). FULL — для сверок и поиска расхождений между двумя списками.
WHERE фильтрует строки до группировки — работает с отдельными строками. HAVING фильтрует результаты после GROUP BY — работает с агрегатами.
Например, WHERE status = 'paid' уберёт неоплаченные заказы. HAVING SUM(amount) > 1000 оставит только тех клиентов, у кого сумма заказов больше 1000.
Из практики: если условию не нужен агрегат — пишите его в WHERE, оптимизатор быстрее обработает. HAVING — только для условий по агрегатам.
GROUP BY объединяет строки с одинаковыми значениями в указанных столбцах в одну группу. К каждой группе можно применить агрегатные функции: COUNT, SUM, AVG, MIN, MAX.
В SELECT можно класть только либо столбцы из GROUP BY, либо агрегаты. Иначе СУБД не знает, какое из значений показать.
Из практики: применяют для отчётов «сколько заказов на пользователя», «сумма по дням», «среднее по категории». GROUP BY несколькими столбцами создаёт группы по их комбинации.
Индекс — это отдельная структура данных (чаще всего B-tree), которая хранит значения столбца и ссылки на строки таблицы. По нему СУБД находит нужные строки за логарифмическое время вместо полного сканирования.
Самые частые сценарии, где помогает: WHERE col = X, JOIN по столбцу, ORDER BY, поиск диапазона, проверка UNIQUE.
Из практики: индекс ускоряет чтение, но замедляет вставку и обновление, потому что его нужно поддерживать. На большие таблицы индексы строят осторожно и только под конкретные запросы.
Внешний ключ (FOREIGN KEY) — это ссылка одного столбца (или нескольких) на первичный ключ другой таблицы. Он гарантирует, что в зависимой таблице не появится значение, которого нет в родительской.
Действия при удалении/обновлении родителя: CASCADE (удалить/обновить и потомков), SET NULL (выставить NULL у потомков), SET DEFAULT (значение по умолчанию), RESTRICT/NO ACTION (запретить операцию, если есть потомки).
Из практики: CASCADE удобен для тесно связанных данных (комментарии при удалении поста). Для важных бизнес-сущностей чаще выбирают RESTRICT — заставить разработчика подумать.
HAVING фильтрует группы после GROUP BY по агрегатам. Например, SELECT user_id, COUNT(*) FROM orders GROUP BY user_id HAVING COUNT(*) > 10 — пользователи с более 10 заказами.
В отличие от WHERE, HAVING работает с агрегатами, которые видны только после группировки.
Из практики: незаменим для отчётов «у кого больше N» или «у кого сумма выше X». Если можно отфильтровать строкой — WHERE.
CASE WHEN condition THEN value [WHEN ...] ELSE other END — выражение if/else в SQL. Можно использовать в SELECT, WHERE, ORDER BY, GROUP BY.
Простая форма: CASE column WHEN val1 THEN ... WHEN val2 THEN ... END. Поисковая — с произвольными условиями.
Из практики: типовой инструмент для условной агрегации (SUM(CASE WHEN status='paid' THEN amount END)), категоризации, сортировки по приоритету.
NOT NULL запрещает значение NULL в столбце. При попытке вставки/обновления с NULL — ошибка.
Это самый базовый способ обеспечить наличие данных. Часто комбинируют с DEFAULT.
Из практики: ставьте NOT NULL по умолчанию там, где можно. Это убирает целый класс багов «забыли заполнить поле».
COUNT(*) считает все строки. COUNT(column) — только строки, где column не NULL.
COUNT(DISTINCT column) — уникальные не-NULL значения.
Из практики: помнить, что COUNT(column) пропускает NULL — типовая ошибка. Если столбец NOT NULL — оба варианта дадут одно число.
1:1 — одна строка слева соответствует не более чем одной справа (пользователь и его профиль). 1:N — одной строке слева соответствует много справа (клиент и его заказы). N:M — обе стороны имеют много (студенты и курсы).
1:1 редко самостоятельна — обычно следствие разделения таблицы по причинам производительности или безопасности. N:M реализуется через промежуточную таблицу-связку.
Из практики: при описании предметной области сначала рисую сущности и связи на бумаге. Потом превращаю в физическую схему — это снимает половину будущих изменений.
Первичный ключ (PK) — атрибут или набор атрибутов, однозначно идентифицирующий каждую строку таблицы. Свойства: уникальность, NOT NULL, неизменяемость (по согласию команды).
Бывает естественный (значение из домена — ИНН, email) и суррогатный (искусственный UUID/serial). На практике чаще используют суррогатный — он стабильнее и не зависит от изменений бизнеса.
Из практики: естественный ключ кажется «честным», но почти всегда подводит — ИНН меняется, email перевыпускается. Суррогатный безопаснее по умолчанию.
Внешний ключ (FK) — атрибут или набор атрибутов в одной таблице, ссылающийся на PK другой (или той же) таблицы. Гарантирует ссылочную целостность: нельзя вставить orders.client_id, которого нет в clients.id.
Поведение при удалении/обновлении родителя задаётся ON DELETE / ON UPDATE: CASCADE (удалить детей), SET NULL, SET DEFAULT, RESTRICT, NO ACTION.
Из практики: отказ от FK на уровне БД «ради производительности» — частая ошибка. Сэкономленные миллисекунды оборачиваются битыми данными, которые потом чинят руками.
Транзакция — логически целостная последовательность операций, которая выполняется как единое целое: либо вся целиком (commit), либо никак (rollback).
Гарантии транзакции описывают свойства ACID. Типичный пример: списать со счёта A и зачислить на B — оба действия должны произойти вместе.
Из практики: не любая «логическая операция» — это БД-транзакция. Распределённые операции через очереди и микросервисы требуют отдельных подходов (Saga, outbox), а не одной транзакции на всё.
Atomicity — атомарность: всё или ничего. Consistency — согласованность: после commit БД остаётся в валидном состоянии (соблюдены constraints). Isolation — изолированность: параллельные транзакции не видят промежуточных состояний друг друга. Durability — устойчивость: после commit изменения переживают сбой.
ACID обычно полностью реализуют реляционные БД (PostgreSQL, Oracle, MS SQL). В NoSQL и распределённых системах часто жертвуют Consistency ради Availability/Performance.
Из практики: чаще всего «теряется» Isolation — её уровень в коде явно не указывают, и в продакшене ловят странные баги.
DDL (Data Definition) — структура: CREATE, ALTER, DROP, TRUNCATE. DML (Data Manipulation) — данные: SELECT, INSERT, UPDATE, DELETE, MERGE. DCL (Data Control) — права: GRANT, REVOKE. TCL (Transaction Control) — транзакции: BEGIN/COMMIT/ROLLBACK/SAVEPOINT.
Иногда выделяют отдельно DQL (Data Query) для SELECT. Это условное деление — в разных учебниках границы немного разные.
Из практики: понимание групп помогает в коде и в код-ревью. DDL внутри миграции — отдельно; DML — в приложении; DCL — у админов.
JOIN — операция соединения строк двух таблиц по условию. INNER JOIN — только совпадающие пары. LEFT JOIN — все строки слева, совпадения справа (несовпавшие — NULL). RIGHT JOIN — зеркально. FULL OUTER JOIN — все строки с обеих сторон. CROSS JOIN — декартово произведение.
Дополнительно: SELF JOIN (таблица сама с собой), NATURAL JOIN (по одноимённым колонкам — лучше избегать), USING (короткая запись ON).
Из практики: LEFT JOIN с проверкой `WHERE right.id IS NULL` — типовой способ найти «строки в одной таблице, которых нет в другой».
WHERE фильтрует строки ДО группировки, HAVING — группы ПОСЛЕ агрегации. В WHERE нельзя использовать агрегатные функции (SUM, COUNT), в HAVING — можно.
Пример: `SELECT region, SUM(amount) FROM orders WHERE status='paid' GROUP BY region HAVING SUM(amount) > 1000`. WHERE отсекает строки с другим статусом, HAVING — регионы с маленькой суммой.
Из практики: ставить условие в HAVING вместо WHERE — типовой косяк по производительности. Если можно в WHERE — кладите туда: меньше строк дойдёт до агрегации.
DELETE — DML, удаляет строки по условию (можно с WHERE), пишет в журнал, срабатывают триггеры, обратимо в транзакции. TRUNCATE — DDL, удаляет все строки одной операцией без построчного журнала, обычно сбрасывает счётчики, может быть необратим. DROP — DDL, удаляет саму таблицу со схемой и данными.
По скорости: TRUNCATE > DELETE для больших таблиц. По безопасности: DELETE контролируем условием, DROP/TRUNCATE — массовые операции.
Из практики: в проде команды TRUNCATE и DROP — это всегда чек-лист и резервная копия. DELETE без WHERE опасен не меньше.
UNION объединяет результаты двух SELECT и убирает дубликаты строк (внутренне делает SORT/HASH). UNION ALL объединяет без проверки на дубли — поэтому быстрее.
Используйте UNION ALL, если знаете, что дубликатов не будет или они не мешают. UNION — только когда явно нужна дедупликация.
Из практики: UNION без необходимости — частая причина медленных отчётов. На больших объёмах разница может быть в разы.
Классика: `SELECT col1, col2, COUNT(*) FROM t GROUP BY col1, col2 HAVING COUNT(*) > 1`. Покажет, какие комбинации полей повторяются.
Для просмотра самих дублирующихся строк удобнее ROW_NUMBER: `SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY col1, col2 ORDER BY id) AS rn FROM t) WHERE rn > 1`.
Из практики: перед DELETE дублей обязательно нужен SELECT с теми же условиями — иначе можно случайно снести лишнее.
SQL-инъекция — это атака, когда злоумышленник подставляет в пользовательский ввод фрагмент SQL, и сервер исполняет его, потому что запрос строится конкатенацией строк.
Защита: всегда использовать параметризованные запросы (prepared statements). Параметры передаются отдельно от текста запроса, и СУБД никогда не интерпретирует их как код.
Из практики: при ревью кода первое, на что смотрят — есть ли «склейка» строк в SQL. Любое "SELECT * FROM users WHERE name = '" + name + "'" — потенциальная инъекция.
Идентификация — «кто ты говоришь, что есть» (логин, email). Аутентификация — проверка, что ты действительно тот (пароль, токен, биометрия, 2FA). Авторизация — что тебе разрешено делать (доступ к ресурсу, операции).
Последовательность: идентификация → аутентификация → авторизация. Без аутентификации авторизация бессмысленна.
Из практики: путаница ведёт к 401 vs 403 ошибкам, неправильным сообщениям пользователю и архитектурным дырам.
Стейкхолдер — любой, чьи интересы затрагивает проект: заказчик, спонсор, конечные пользователи, регуляторы, смежные команды, поддержка.
Классифицирую по двум осям: «влияние × интерес» (матрица Менделоу) и «внутренние/внешние». Это даёт 4 квадранта: ключевые игроки (high/high) — управлять плотно; держать удовлетворёнными (high/low); держать в курсе (low/high); минимум усилий (low/low).
Из практики: первое, что делаю на проекте — карта стейкхолдеров на одну страницу с ролью, мотивом и каналом коммуникации. Помогает не «забыть» юриста или ИБ за неделю до релиза.
Базовый набор: интервью (1:1), воркшопы (несколько ролей сразу), наблюдение (shadowing), анкетирование, анализ документов, прототипирование, бенчмарк конкурентов.
Выбор зависит от задачи. Новый процесс — воркшоп + прототип. Незнакомый домен — наблюдение + интервью. Массовая обратная связь — анкета. Конфликты ролей — фасилитированный воркшоп, где разногласия видны всем.
Из практики: ни один метод не закрывает картину один. Обычно комбинирую 2–3 и сверяю результаты — расхождения и есть «золото» аналитика.
SWOT — матрица 2×2: Strengths и Weaknesses (внутренние факторы), Opportunities и Threats (внешние). Цель — увидеть свою позицию и опереть стратегию на сильные стороны, закрывая слабые.
Применяю на старте инициативы, при выходе на новый рынок, перед редизайном продукта. Дальше — пары: SO (сила × возможность = на чём расти), WT (слабость × угроза = что прикрывать).
Из практики: SWOT полезен только если оценки конкретны. «Сильная команда» — не пункт; «3 senior backend с опытом fintech» — пункт.
AS-IS — модель текущего процесса как он есть, со всеми костылями. TO-BE — модель целевого процесса после изменений. Часто рисуются в BPMN для наглядности.
Пример: оформление кредита AS-IS — 7 ручных шагов, 3 дня, 4 системы. TO-BE — 2 шага, 15 минут, 1 окно с автоматическим скорингом.
Из практики: AS-IS обязателен. Без него TO-BE — это фантазия, а не план изменений; не видно, какие операции исчезают и куда деваются люди, которые их делали.
MVP — минимально жизнеспособный продукт: минимальный набор функций, который позволяет проверить ключевую гипотезу с реальными пользователями. Не «дешёвая первая версия», а инструмент обучения.
Границы определяю от гипотезы. Гипотеза: «пользователи готовы платить за X». MVP включает только то, без чего эта гипотеза не проверяется. Всё остальное — в backlog.
Из практики: каждую фичу прохожу вопросом «если её не будет, гипотеза не проверится?». Если ответ «проверится» — фича не в MVP.
BRD (Business Requirements Document) — документ на языке бизнеса: цели проекта, бизнес-потребности, scope, бизнес-правила, заинтересованные стороны. Отвечает на «что» и «зачем».
SRS (Software Requirements Specification) — техническая спецификация на языке системы: функциональные и нефункциональные требования, ограничения, интерфейсы. Отвечает на «как именно».
Из практики: BRD читает спонсор и бизнес, SRS читает команда разработки. Один документ для обоих почти всегда плох в обеих ролях.
IP-адрес — это адрес устройства в сети, по которому пакеты находят получателя.
IPv4 использует 32 бита (примерно 4,3 млрд адресов), записывается как четыре числа через точку. IPv6 использует 128 бит, адресов на порядки больше, запись — через двоеточия.
Из практики: при интеграционных проблемах важно сразу смотреть, какой именно IP видит сервер и нет ли подмены через прокси или NAT.
Cookie хранят состояние сессии, настройки пользователя и токены авторизации. Проверяю атрибуты безопасности: HttpOnly (недоступен JS), Secure (только HTTPS), SameSite (защита от CSRF), срок действия.
Кэш браузера может отдавать устаревшие данные — проверяю корректность заголовков Cache-Control и Expires в ответах, а также поведение при принудительном обновлении.
Из практики: после выкладки новой версии дефекты часто объясняются именно кэшем — пользователь видит старый JS/CSS. Проверяю, что cache-busting работает через хэши в именах файлов.
VPN создаёт зашифрованный канал между устройством и удалённой сетью, скрывая прямой маршрут трафика.
Для QA он нужен для безопасного доступа к внутренним стендам и сервисам, недоступным из открытого интернета.
Из практики: при проблемах доступа первым делом проверяю маршрут, DNS и политику VPN-профиля.
HTML — язык разметки, который определяет структуру и содержимое веб-страницы с помощью тегов: заголовки, параграфы, ссылки, формы, изображения.
Браузер парсит HTML и строит DOM-дерево; JavaScript работает с этим деревом динамически. QA важно понимать DOM, чтобы строить надёжные локаторы и понимать, почему элемент может быть недоступен.
Из практики: при нестабильных локаторах в автотестах первым делом смотрю структуру DOM — часто элемент есть в HTML, но ещё не отрендерен или скрыт стилями.
CSS — язык описания стилей: задаёт оформление HTML-элементов (цвета, шрифты, размеры, отступы, расположение). Работает каскадно — несколько правил могут применяться к одному элементу, приоритет определяется специфичностью.
QA важно понимать CSS для тестирования адаптивности (медиа-запросы), кроссбраузерных различий и доступности (контраст, размеры шрифтов).
Из практики: визуальные баги часто связаны с конфликтами CSS-правил или неожиданным поведением flexbox/grid на разных браузерах — DevTools → Computed Styles быстро локализует проблему.
Проверяю основные контрольные ширины экрана и ориентации устройства, чтобы убедиться, что интерфейс не распадается.
Смотрю читаемость текста, доступность кнопок и поведение таблиц и форм на малых экранах.
Из практики: на мобильных ширинах часто ломаются sticky-элементы и таблицы, их проверяю отдельно.
Стартовая строка (метод, путь, версия), заголовки (Host, User-Agent, Accept, Content-Type и др.) и (необязательно) тело сообщения.
Заголовки разделены пустой строкой от тела. Запросы GET, DELETE обычно без тела; POST, PUT, PATCH — с телом.
Из практики: для тестирования важно различать query parameters (в URL после ?), path parameters, тело и заголовки — все они могут влиять на поведение.
1xx — informational (101 Switching Protocols). 2xx — success (200 OK, 201 Created, 204 No Content). 3xx — redirect (301 Permanent, 302 Found, 304 Not Modified). 4xx — client error (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 422 Unprocessable). 5xx — server error (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout).
Каждый код несёт смысл. Например, 401 — «не авторизован» (логиньтесь), 403 — «авторизован, но запрещено».
Из практики: тестировщик обязан различать 401/403, 400/404/409/422 — это основа правильного API-дизайна и часто источник пользовательских недоразумений.
GET — получить ресурс, без побочных эффектов, идемпотентен. POST — создать ресурс (или выполнить действие), не идемпотентен. PUT — заменить ресурс целиком, идемпотентен. PATCH — частично обновить, обычно не идемпотентен. DELETE — удалить, идемпотентен.
Идемпотентный метод — это тот, повтор которого даёт тот же результат на сервере. Это важно для повторов запросов после сбоя.
Из практики: реальные API не всегда строго следуют семантике — встречаются «POST для всего». При тестировании важно понимать, что обещает REST и что фактически делает API.
Cookies — это пары ключ-значение, которые сервер устанавливает в браузере и которые автоматически отправляются обратно в каждом запросе на тот же домен.
Важные флаги: Secure (только по HTTPS), HttpOnly (недоступны JS — защита от кражи через XSS), SameSite (Lax/Strict/None — защита от CSRF), Expires/Max-Age (срок жизни), Domain и Path.
Из практики: для сессионных и токен-cookies всегда HttpOnly + Secure + SameSite. Отсутствие любого из этих флагов — типовая находка пентеста.
HTTPS — это HTTP поверх TLS. TLS обеспечивает шифрование канала (никто посередине не прочитает данные), подлинность сервера (сертификат) и целостность (никто не подменит ответ).
Для тестировщика важно понимать: HTTPS защищает данные в дороге, но не на клиенте и не на сервере. Чувствительные данные нужно дополнительно защищать.
Из практики: проверяют валидность сертификата, отсутствие смешанного содержимого (HTTPS-страница, грузящая HTTP-ассеты), наличие HSTS, корректные редиректы с HTTP на HTTPS.
Сетевой протокол — набор правил для обмена данными между узлами: формат пакетов, порядок установления соединения, обработка ошибок. Без общего протокола машины не понимают друг друга.
OSI — концептуальная модель из 7 уровней: физический, канальный, сетевой, транспортный, сеансовый, представления, прикладной. TCP/IP — практическая модель из 4 уровней: link, internet, transport, application. Большинство современных систем работает по TCP/IP.
Из практики: знать OSI полезно для общего словаря: «это L4-балансер», «проблема на L7». В реальности почти всегда работают TCP/IP-протоколы (HTTP, TCP, IP, Ethernet).
DNS (Domain Name System) — иерархическая распределённая система, преобразующая доменные имена в IP-адреса. Резолв проходит по цепочке: корневые сервера → TLD-сервера (.com) → серверы домена.
Записи: A (имя → IPv4), AAAA (IPv6), CNAME (псевдоним), MX (почта), TXT (произвольный текст, SPF/DKIM), NS (delegation), SRV (сервис). TTL — сколько хранить ответ в кэше.
Из практики: «странные» проблемы DNS чаще всего из-за кэширования и TTL. После изменения записи нужно подождать TTL — иначе пол-мира видит старое.
Жизненный цикл дефекта — это последовательность статусов: New (зарегистрирован) → Open (подтверждён) → In Progress (в работе) → Fixed (исправлен) → Retest (на перепроверке) → Closed (закрыт). Также возможны Rejected (отклонён) и Deferred (отложен).
Severity показывает техническую тяжесть дефекта (насколько он влияет на систему), Priority — бизнес-срочность исправления. Пример: опечатка на главной странице — Severity Low, Priority High.
Из практики: если эти шкалы разделены, приоритизация становится прозрачной и быстрой — разработчик и менеджер говорят на одном языке без споров.
Я проверяю баг-репорт по простому правилу: любой человек в команде должен воспроизвести дефект без устных пояснений.
В отчёте должны быть шаги, окружение, ожидаемый/фактический результат и доказательства проблемы.
Из практики: перед созданием тикета всегда проверяю, достаточно ли данных для быстрого старта исправления.
Пример: опечатка в кнопке «Оплатить» на главной странице маркетинговой кампании.
Технически тяжесть низкая, но приоритет высокий, потому что ошибка заметна всем и бьёт по доверию и конверсии.
Из практики: такие дефекты часто чинят в первую очередь перед публичным запуском.
Пример: редкий сбой в фоновом расчёте отчёта для узкой роли администратора.
Серьёзность высокая, потому что нарушается корректность данных, но приоритет может быть ниже из-за маленькой аудитории и обходного пути.
Из практики: такие баги обычно планируют в ближайший релиз, но не всегда блокируют текущий.
Retest — это проверка конкретного шага из тикета на сборке с фиксом. Подтверждаем, что баг больше не воспроизводится в тех же условиях.
После retest проводят таргетированную регрессию — функциональность, которая могла бы пострадать от изменения (соседние экраны, общие компоненты). Не обязательно полную регрессию, но достаточную, чтобы поймать побочки.
Из практики: если исправление точечное, регрессия маленькая. Если фикс затронул общий слой (контроллер, утилита) — регрессия шире. Глубину выбирают по риску.
Минимум: заголовок (краткий и описательный), шаги воспроизведения, ожидаемый и фактический результат, окружение (версия приложения, ОС, устройство, версия БД и т.д.), приоритет/серьёзность, артефакты (скриншоты, видео, логи).
Дополнительно полезно: ссылка на тестовые данные, ID запроса/трассы, точное время воспроизведения, частота (всегда/иногда).
Из практики: правило простое — баг-репорт должен позволять разработчику воспроизвести дефект без устных пояснений. Если устные пояснения нужны — баг-репорт неполный.
Playwright — это фреймворк автоматизации браузера от Microsoft. Управляет Chromium, Firefox и WebKit через единое API. Тесты пишут на TypeScript/JavaScript, Python, Java или .NET.
Отличия от Selenium: встроенное авто-ожидание элементов, изоляция тестов через контексты, поддержка emulation мобильных устройств, перехват сети, скриншоты/видео/трассы без плагинов, более быстрый запуск.
Из практики: на новых проектах для веб-автотестов чаще выбирают Playwright — он стабильнее и удобнее. Selenium остаётся в энтерпрайз-проектах с историей и где нужна совместимость со старым WebDriver-сервером.
page.locator() — основной способ. Внутри можно использовать CSS, XPath, тексты, role. Также есть удобные ярлыки: getByRole, getByText, getByLabel, getByPlaceholder, getByTestId.
Официальная рекомендация: getByRole и getByText. Они отражают то, как пользователь видит интерфейс, и устойчивы к изменениям разметки. getByTestId — компромисс, когда роли недостаточны.
Из практики: если разработчики аккуратно расставляют data-testid, локаторы получаются стабильными и понятными. CSS и XPath остаются для редких случаев, где роль не подходит.
Сценарии установки: чистая установка, установка при нехватке места, обновление через Store с сохранением данных, даунгрейд на предыдущую версию.
Миграция данных: сохранность пользовательских настроек и локального кэша при обновлении, совместимость форматов внутренней БД приложения между версиями.
Из практики: самый частый дефект при обновлении — потеря данных при миграции внутренней БД. Проверяю обновление с минимально поддерживаемой версии, а не только с предыдущей.
Appium — это фреймворк для автоматизации мобильных, веб- и гибридных приложений на iOS и Android по протоколу WebDriver. Он реализует тот же интерфейс, что и Selenium, поэтому опыт UI-автоматизации легко переносится.
Под капотом Appium общается с системными драйверами: на Android это UiAutomator2 (или Espresso), на iOS — XCUITest. На сервере Appium собирает команды и проксирует их.
Из практики: один и тот же тест-код можно прогнать против Android и iOS, поменяв только capabilities. Это снижает порог входа для команд, которые уже знают Selenium.
Capabilities — это набор параметров, который клиент передаёт серверу при создании сессии. Они описывают, на каком устройстве и приложении тестировать.
Обязательные обычно: platformName (Android/iOS), automationName (UiAutomator2, XCUITest), deviceName, и либо app (путь к APK/IPA), либо bundle/package + activity для уже установленного приложения.
Из практики: capabilities передают через JSON или билдер. На реальных устройствах добавляют udid; на эмуляторах — platformVersion и avd. В команде их часто выносят в фабрику окружений.
Главные отличия: огромная фрагментация устройств и версий ОС, особенности интерфейса (тачи, жесты, разные экраны), особые сценарии (звонки, разряд батареи, потеря сети), магазины (Google Play, App Store) с их правилами, требования к производительности и батарее.
Также мобильное приложение работает в условиях, когда система может его выгрузить из памяти, переключить в фон, отозвать разрешения. Тесты учитывают это.
Из практики: помимо UI и API, в чек-листы добавляют сценарии перехода в фон, прерываний (входящий звонок, push, выключение экрана), работы в офлайн, разных уровней яркости/доступности.
Включают авиарежим, отключают Wi-Fi, ослабляют сигнал (через эмулятор или сетевую утилиту), имитируют медленную сеть (Charles, Network Link Conditioner, эмулятор Android).
Проверяют: понятное сообщение пользователю, повтор запроса при возврате сети, корректное состояние UI (нет вечного спиннера), сохранение черновика данных.
Из практики: типовые баги — приложение «зависает» в загрузке, теряет введённые данные при попытке отправки, не повторяет автоматически и требует ручного действия. Тесты на офлайн — обязательная часть приёмки.
Прерывание — это любое событие, отвлекающее приложение: входящий звонок, push, будильник, низкий заряд, потеря сети, переход в фон по нажатию Home.
Тест-кейс: воспроизвести прерывание в ключевые моменты (оплата, ввод формы, загрузка) и проверить, что после возврата состояние корректно. Особое внимание — данным, которые не должны потеряться.
Из практики: для типового приложения проверяют как минимум: звонок при оплате, push в момент загрузки, переход в фон во время длительной операции, разрыв сети при отправке.
Не «контролёр на выходе», а полноценный участник команды: уточняет требования, помогает в дизайне, пишет автотесты, участвует в код-ревью (с точки зрения тестируемости), консультирует команду.
Также QA отвечает за стратегию тестирования, ведёт качество как метрику, прокачивает практики автоматизации.
Из практики: в зрелых командах QA не «принимают» работу разработчиков, а вместе строят процесс, при котором баги ловятся как можно раньше — на ревью, в pre-commit hooks, на CI.
Waterfall — последовательные этапы, каждый завершён до следующего. V-model — Waterfall с явной привязкой тестирования к этапам анализа/дизайна. RUP — итеративная с фазами Inception/Elaboration/Construction/Transition. Agile — итерации, эмпиризм, ценность; внутри — Scrum (фиксированные спринты), Kanban (поток без спринтов), XP (инженерные практики). SAFe/LeSS — масштабирование Agile на много команд.
Выбор зависит от: стабильности требований, размера, регулирования, культуры. Жёсткий фикс-скоуп с регулятором — Waterfall/V-model. Гибкость, обучение, продукт — Agile.
Из практики: «чистых» методологий мало. Большинство команд — гибрид: Scrum-ish с Kanban-элементами и собственными ритуалами.
Sprint Planning — планирование спринта. Daily Scrum — ежедневный 15-минутный синк. Sprint Review — демо результатов стейкхолдерам в конце спринта. Sprint Retrospective — ретро команды для улучшения процесса. Backlog Refinement — регулярное уточнение и оценка задач (не обязательная по гайду, но почти всегда есть).
Сам спринт — тоже событие (контейнер для остальных). Длина обычно 1–4 недели, фиксированная.
Из практики: ретро — самое ценное событие. Команды, которые ретро отменяют, перестают улучшаться.
Product Owner — отвечает за максимизацию ценности продукта, владеет backlog, расставляет приоритеты. Scrum Master — отвечает за процесс и устранение препятствий, не менеджер команды. Developers (команда разработки) — кросс-функциональная команда, делает инкремент. По гайду — это всё.
Аналитик и BA в Scrum формально — часть Developers (или работают «рядом», помогая PO). В Scrum нет роли «аналитик» — это часть командной экспертизы.
Из практики: часто PO перегружен и берёт BA как «делегата по требованиям». Это работает, если границы ответственности понятны.
Kanban — метод управления потоком задач без фиксированных итераций. Принципы: визуализация (доска с колонками), WIP-лимиты (макс. задач в одной колонке), управление потоком (минимизация ожидания), явные правила, регулярная улучшающая обратная связь.
Работает «pull» — следующая задача берётся, когда есть ёмкость, а не «push» (всё на исполнителей).
Из практики: Kanban отлично подходит для поддержки, инфраструктурных команд, и продуктовых, где приоритеты часто меняются. WIP-лимиты — ключевая практика.
Артефакт — любой документ или модель, который остаётся как результат работы и используется другими ролями: BRD, SRS, user stories с AC, BPMN-диаграммы, Sequence, ERD, контракты API (OpenAPI), глоссарий, decision log.
Какие именно — зависит от методологии и проекта. В Agile-команде продукта чаще всего: user stories с AC, sequence-диаграммы интеграций, OpenAPI, краткие тех. спецификации. В госпроекте — полный комплект по ГОСТ.
Из практики: артефакт без потребителя — мусор. Перед тем как заводить новый документ, спрашиваю, кто и зачем будет его читать.
BPMN — бизнес-процессы. UML — модели ПО (структура, поведение, взаимодействие). ER/IDEF1X — модели данных. DFD — потоки данных. C4 — архитектура. ArchiMate — корпоративная архитектура.
Выбор нотации зависит от аудитории. BPMN читает бизнес, UML Sequence — разработчики, C4 — архитекторы и менеджеры. Нет «самой правильной» нотации.
Из практики: на одном проекте редко обходится одной нотацией. AS-IS процесса — BPMN, интеграция — Sequence, данные — ERD.
Категории элементов: Flow Objects (события, активности, шлюзы), Connecting Objects (поток управления, поток сообщений, ассоциации), Swimlanes (Pool, Lane), Artifacts (data object, group, аннотация).
Минимально достаточный набор для 80% диаграмм: Start/End event, Task, Gateway (XOR/AND), Sequence Flow, Lane. Этого хватает, чтобы описать большинство бизнес-процессов читаемо.
Из практики: чем больше уникальных типов значков на диаграмме, тем меньше людей её поймут. Лучше повторно использовать базовые.
Pool — отдельный участник процесса (организация, система, внешний сервис). Pool'ы общаются только через message flow, не sequence flow.
Lane — подразделение внутри Pool: отдел, роль, система-компонент. Внутри Pool связи идут sequence flow.
Из практики: правило «один Pool — один процесс». Если у вас 5 Pool'ов с равноправными процессами, скорее всего нужно разделить на 5 диаграмм с явной интеграцией.
Две категории: структурные (Class, Object, Component, Composite Structure, Package, Deployment, Profile) и поведенческие (Use Case, Activity, State Machine, Sequence, Communication, Timing, Interaction Overview).
Самые ходовые: Class (модель домена), Sequence (взаимодействие во времени), State Machine (поведение объекта), Use Case (функциональные требования верхнего уровня), Activity (процесс/алгоритм).
Из практики: в Agile-проектах UML используют выборочно — обычно Sequence для интеграций и Class для домена. Полный набор UML — это редкая практика крупных регулируемых проектов.
Use Case Diagram — диаграмма поведения, показывающая, какие сценарии система выполняет для разных типов пользователей. Высокоуровневый взгляд на функциональность.
Элементы: акторы (человек/система/таймер), use cases (овалы), системные границы (прямоугольник), отношения (association, include, extend, generalization).
Из практики: ценность не в самой диаграмме, а в обсуждении при её создании. После согласования use cases раскрываются в текстовые спецификации или user stories.
Тестирование — это проверка продукта, чтобы понять, насколько он соответствует ожиданиям и требованиям.
Главная цель — снизить риски релиза и дать команде прозрачную картину качества.
Из практики: хороший результат тестирования — это не только найденные дефекты, но и понятные решения по выпуску.
QA — это система процессов, которая предотвращает дефекты заранее.
QC — контроль качества готового результата, а тестирование — один из основных инструментов QC.
Из практики: когда фокус только на тестах без QA-процессов, одни и те же проблемы повторяются в каждом релизе.
Тестирование стоит начинать с этапа требований: так риски и противоречия выявляются до разработки.
В V-модели это видно наглядно: каждому этапу разработки (требования, дизайн, код) параллельно сопоставлен уровень тестирования (приёмочное, интеграционное, модульное), а тест-дизайн стартует вместе с этим этапом.
Ранний старт экономит время и стоимость исправлений: баги не успевают «прорасти» в архитектуру и код.
Из практики: участие QA в груминге и дизайне задачи снижает число критичных сюрпризов перед релизом.
Модульный уровень проверяет отдельные функции и классы, интеграционный — взаимодействие компонентов.
Системный уровень проверяет продукт целиком, а приёмочный подтверждает, что решение подходит бизнесу и пользователю.
Из практики: проблемы на стыках чаще ловятся на интеграционном уровне, даже если модульные тесты зелёные.
По цели чаще выделяют функциональные и нефункциональные проверки.
По уровню — модульные, интеграционные, системные и приёмочные.
Из практики: набор видов выбираю по рискам конкретного релиза, а не по шаблону.
Верификация отвечает на вопрос «правильно ли мы строим продукт по спецификации».
Валидация отвечает на вопрос «решает ли продукт реальную задачу пользователя».
Из практики: можно пройти верификацию и всё равно провалить валидацию, если неверно поняли пользовательскую потребность.
Ключевые методы: чёрный, белый и серый ящик, а также исследовательское тестирование.
Обычно они комбинируются: бизнес-сценарии проверяем как «чёрный ящик», а технические риски — глубже через API, логи и данные.
Из практики: лучший результат даёт не один метод, а правильное сочетание под конкретный риск.
Базовые принципы: тестирование показывает наличие дефектов, но не доказывает их отсутствие; полное тестирование недостижимо.
Нужно начинать рано, учитывать контекст продукта и регулярно обновлять набор проверок.
Из практики: если не пересматривать тесты под новые риски, они перестают находить реальные проблемы.
Парадокс пестицида — это ситуация, когда один и тот же набор тестов со временем теряет эффективность.
Команда проходит старые проверки, но новые дефекты остаются незамеченными.
Из практики: поэтому я регулярно обновляю тесты и добавляю свежие сценарии из продовых инцидентов.
Обычно этапы такие: анализ требований, планирование, дизайн проверок, выполнение, отчётность и ретроспектива.
На каждом этапе важна прозрачная коммуникация с командой, чтобы качество не превращалось в отдельный «остров».
Из практики: процесс работает только тогда, когда его реально используют в ежедневной работе, а не держат в документе.
SDLC (Software Development Life Cycle) — это цикл разработки продукта в целом: анализ требований, проектирование, разработка, тестирование, релиз, поддержка.
STLC (Software Testing Life Cycle) — подцикл тестирования: анализ требований к тестированию, планирование, дизайн тест-кейсов, настройка среды, выполнение, закрытие.
Из практики: STLC встраивается в SDLC. QA подключается с самых ранних фаз (анализ требований), а не только на этапе тестирования готового кода.
Верификация — «делаем продукт правильно»: соответствует ли реализация спецификации. Это работа с фактом построения.
Валидация — «делаем правильный продукт»: решает ли продукт реальную потребность пользователя. Это работа с уместностью.
Из практики: можно верифицировать всё, но создать ненужный продукт. И можно сделать правильный продукт с ошибками. QA участвует в обеих активностях.
QA (Quality Assurance) — это процессно-ориентированная активность: организовать так, чтобы качество встраивалось в процесс с самого начала. Шире, чем тестирование.
QC (Quality Control) — это проверка готового продукта на соответствие требованиям. По сути — тестирование.
Тестировщик — исполнитель тестов. На практике границы размыты, и часто все три слова используют как синонимы. Но важно понимать, что качество строится в процессе, а не «проверяется» в конце.
Unit — тестирование отдельной функции/класса в изоляции. Быстро, точечно, дёшево. Integration — взаимодействие двух или более компонентов (например, сервис и БД). End-to-end — весь поток через систему, как у пользователя.
Пирамида тестирования: больше unit, меньше integration, ещё меньше e2e. E2E дорогие и нестабильные, поэтому их меньше всего.
Из практики: пирамида — ориентир. Реальное распределение зависит от проекта. Главное — не делать только e2e (как «мороженое») или только unit (без интеграционной проверки).
Регрессионное тестирование — это проверка, что ранее работавшая функциональность не сломалась после изменений в коде.
Применяют после рефакторинга, исправления багов, добавления фич, обновления зависимостей.
Из практики: полная регрессия — долго. Поэтому стараются автоматизировать критичные сценарии и запускать на каждом PR. Ручную регрессию используют для UX-критичных и редкоизменяемых областей.
Smoke — это поверхностная проверка, что сборка вообще работает: запускается, основные экраны открываются, главные сценарии проходят. Обычно 5-15 минут.
Sanity — это короткая проверка после внесения изменений в одну область: затронуло ли это смежные функции, ничего не сломалось «по соседству». Уже точечная.
Из практики: на проде «дымит ли» проверяет smoke. Sanity нужен в момент быстрых правок — посмотреть, что не разнесло окрестности.
Functional проверяет, что система делает то, что должна (правильно работают функции, формы, расчёты, переходы).
Non-functional — проверяет «как»: производительность, безопасность, удобство, надёжность, масштабируемость, доступность, совместимость.
Из практики: оба вида одинаково важны. Без функционального продукт не работает; без нефункционального — работает, но плохо (тормозит, небезопасно, неудобно).
Тестовая среда — это окружение, в котором проводят тесты: набор серверов, БД, интеграций, конфигов, тестовых данных, в котором продукт ведёт себя «как на проде, но безопасно».
Типовая иерархия: dev (для разработчиков), test/staging (для QA), pre-prod (приближено к проду), prod (живые пользователи). Между ними отличия — конфиги, данные, обновления.
Из практики: чем ближе test-среда к prod, тем надёжнее результаты тестов. Большой разрыв — типовая причина «у нас работало».
Классические этапы: 1) инициация (идея, цели, ROI); 2) анализ требований; 3) проектирование (архитектура, UX, БД); 4) разработка; 5) тестирование; 6) внедрение (deploy, обучение, миграция); 7) сопровождение и эксплуатация.
В Agile эти этапы не последовательны, а итеративны: каждый спринт включает мини-цикл анализ-дизайн-разработка-тест. Но сами стадии не исчезают.
Из практики: SDLC — не «методология», а скелет процесса. Waterfall и Agile — это разные способы пройти его.
Чек-лист — быстрый список проверок без детальных шагов.
Тест-кейс — подробная проверка с шагами и ожидаемым результатом, а тест-сценарий — крупный бизнес-поток из нескольких кейсов.
Из практики: для ежедневной регрессии чаще беру чек-листы, для критичных флоу — кейсы и сценарии.
Тест-кейс детализирован и хорошо подходит для стабильной регрессии и передачи знаний.
Чек-лист быстрее в поддержке и удобен там, где команда опытная и сценарии понятные.
Из практики: часто использую гибрид — критичные зоны оформляю кейсами, остальное закрываю чек-листом.
Эквивалентные классы помогают не проверять все значения подряд: делим входные данные на группы, которые должны вести себя одинаково.
Граничные значения нужны, потому что ошибки чаще всего живут на границах диапазона: минимум, максимум и соседние значения.
Из практики: для поля возраста 18–65 я проверяю 17, 18, 19, 64, 65, 66 — этого обычно достаточно, чтобы быстро поймать дефект в валидации.