Полный ответ

QA, или Quality Assurance, — это подход к предотвращению дефектов в процессе разработки. Testing — часть QA, которая проверяет уже реализованное поведение. Хороший разработчик думает о качестве раньше тестов: уточняет требования, проверяет edge cases, пишет поддерживаемый код, добавляет автоматические проверки и делает поведение диагностируемым.

Полный ответ

QA отвечает за процесс и предотвращение проблем: требования, Definition of Done, test strategy, review, CI и quality gates. QC, или Quality Control, проверяет результат: ручное тестирование, автотесты, acceptance checks, регрессию и дефекты. В современной команде разработчик участвует в обоих направлениях.

Полный ответ

• Unit tests проверяют маленькую единицу логики.
• Component tests проверяют UI-компонент или небольшой участок интерфейса.
• Integration tests проверяют совместную работу нескольких модулей, DI, HTTP, БД или очередей.
• Contract tests фиксируют совместимость между consumer и provider.
• E2E tests проверяют пользовательский или системный сценарий целиком.
• Visual regression tests ловят неожиданные изменения внешнего вида.
• Load tests проверяют поведение под нагрузкой.

Важно выбирать уровень по риску. Не нужно проверять простой mapper через E2E, а критичный checkout не стоит оставлять только на unit-тестах.

Полный ответ

Тестовая пирамида — принцип, по которому быстрых unit и integration tests должно быть больше, чем дорогих E2E tests. Нижние уровни дают быстрый feedback и легко локализуют ошибку. Верхние уровни проверяют реальные пользовательские сценарии, но дороже в поддержке и чаще флакают.

Полный ответ

Минимум: требования, happy path, основные ошибки, loading/empty states, доступы, валидацию, responsive layout, сетевые ошибки, миграции данных и обратную совместимость API. Также важно запустить релевантные unit, integration, E2E, lint, typecheck и build. QA не должен быть первым человеком, который открыл новую фичу.

Полный ответ

Definition of Done описывает, когда задача действительно готова: реализовано ожидаемое поведение, пройдены проверки, обновлены тесты, обработаны ошибки, нет регрессий доступности и производительности, добавлена наблюдаемость, если она нужна. Для backend также важны контракт API, миграции, безопасность и rollback plan.

Полный ответ

Начинают с риска: что сломает пользователя, деньги, безопасность, данные или релиз. Pure logic удобно покрывать unit-тестами. UI behavior — component или integration tests. Контракт frontend и backend — contract или API tests. Критичный пользовательский путь — E2E. Нагрузку и отказоустойчивость проверяют отдельными performance tests.

Полный ответ

Частый стек:

• Vitest, Jest, Jasmine, Karma — unit и integration tests;
• Testing Library, Angular Testing Library, React Testing Library — DOM-first проверки поведения;
• TestBed, Component Harnesses — Angular component testing;
• Playwright, Cypress — E2E и browser-level tests;
• Storybook — каталог состояний компонентов;
• Chromatic, Percy, Loki, Playwright screenshots — visual regression;
• MSW — mock server для frontend tests;
• Lighthouse, WebPageTest, Chrome DevTools Performance — performance;
• axe, pa11y, eslint-plugin-jsx-a11y, angular-eslint — accessibility;
• Sentry, LogRocket, OpenReplay — runtime диагностика.

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

Полный ответ

Обычно проверяют поведение: что пользователь видит, какие действия может выполнить и какой результат получает. Внутренние поля, private methods, случайные CSS classes и точная структура DOM делают тесты хрупкими. Реализацию проверяют только тогда, когда она сама является публичным контрактом.

Полный ответ

Нужно проверить валидные данные, обязательные поля, ошибки формата, disabled states, server errors, повторную отправку, keyboard flow и доступные labels. Для сложной формы полезны component или integration tests, а для критичного сценария отправки — один E2E test.

Полный ответ

Playwright нужен для browser-level сценариев: авторизация, checkout, routing, интеграция с backend, загрузка файлов, проверка нескольких браузеров, tracing, screenshots и видео падений. Он особенно полезен, когда unit или component tests не покрывают реальное поведение браузера и сетевого слоя.

Полный ответ

Visual regression testing сравнивает screenshots или snapshots UI между прогонами и ловит неожиданные изменения верстки. Он полезен для design systems, компонентных библиотек, сложных страниц и критичных визуальных состояний. Чтобы тесты не флакали, фиксируют данные, viewport, шрифты, анимации и состояние окружения.

Полный ответ

Автоматически проверяют базовые нарушения через axe, eslint rules, Lighthouse или pa11y. Вручную проверяют keyboard navigation, focus order, visible focus, labels, error messages, screen reader flow, contrast и состояние interactive elements. Автотесты помогают, но не заменяют ручную проверку ключевых сценариев.

Полный ответ

Ключевые метрики: LCP для скорости основного контента, INP для отзывчивости, CLS для стабильности layout, TTFB для ответа сервера, FCP для первого видимого контента и bundle size для стоимости загрузки. Важно смотреть не только lab tests, но и real user monitoring, потому что реальные устройства и сети отличаются от CI.

Полный ответ

Частый стек:

• Vitest, Jest, Mocha, Node test runner — unit и integration tests;
• Supertest, PactumJS, Frisby — HTTP API tests;
• Testcontainers — тесты с реальными PostgreSQL, Redis, Kafka или RabbitMQ;
• Pact — consumer-driven contract testing;
• OpenAPI validators, Schemathesis, Dredd — проверка API-контрактов;
• k6, Artillery, autocannon, wrk — нагрузочные тесты;
• ESLint, TypeScript strict, Knip, dependency-cruiser — статический анализ;
• Snyk, npm audit, osv-scanner, Trivy — security и dependency checks;
• OpenTelemetry, Prometheus, Grafana, Sentry, Datadog — observability.

Разработчик должен понимать не только запуск тестов, но и какие риски каждый инструмент закрывает.

Полный ответ

Проверяют status codes, response schema, headers, authorization, validation errors, pagination, sorting, filtering, idempotency и backward compatibility. Для handler logic можно использовать integration test с контролируемыми dependencies. Для публичного API полезно проверять соответствие OpenAPI spec.

Полный ответ

Чистую domain logic тестируют без БД. Repository, migrations, transactions, constraints и SQL queries лучше проверять на реальной тестовой БД через Testcontainers или отдельное test environment. Моки БД быстрее, но хуже ловят ошибки schema, transaction isolation и несовместимость запросов.

Полный ответ

Contract testing проверяет, что provider API совместим с ожиданиями consumer. Это особенно полезно, когда frontend и backend релизятся независимо. Контракт фиксирует method, path, headers, request body, response body и ошибки. Такие тесты не заменяют E2E, но уменьшают число поломок на границе сервисов.

Полный ответ

Нужно проверять anonymous user, authenticated user, разные роли, чужие ресурсы, expired tokens, malformed tokens и отсутствующие scopes. Важны негативные сценарии: пользователь не должен получить данные другого tenant, выполнить запрещенную операцию или обойти проверку через прямой API-запрос.

Полный ответ

Проверяют idempotency, retry policy, dead-letter queue, порядок обработки, дубликаты, подписи webhook, timeout и частичную недоступность зависимостей. Для unit-теста выносят чистую обработку события в функцию. Для integration-теста поднимают реальный broker или контролируемый fake.

Полный ответ

Смотрят latency, p50, p95, p99, throughput, RPS, error rate, saturation, CPU, memory, GC pauses, event loop lag, database query duration, queue depth и timeout rate. Среднее время ответа почти всегда недостаточно: p95 и p99 лучше показывают, как система ведет себя для медленных пользователей и под нагрузкой.

Полный ответ

Allure Report — open-source инструмент для визуализации результатов автотестов. Он преобразует структурированные данные о прогоне в интерактивный HTML-отчет с тестами, шагами, длительностью, ошибками, attachments, labels, историей и аналитикой.

Allure не запускает тесты и не заменяет Playwright, Cypress, Jest, Vitest или другой test runner. Между test runner и Allure обычно работает adapter или reporter, который записывает результаты в понятном Allure формате.

Полный ответ

Упрощенный процесс:

1. Test runner запускает автотесты.
2. Allure adapter получает события test runner: начало и завершение тестов, ошибки, steps, labels и attachments.
3. Adapter записывает структурированные файлы в каталог allure-results.
4. Allure CLI читает результаты и генерирует HTML-отчет, обычно в каталоге allure-report.
5. Отчет открывают локально или публикуют как CI artifact либо статический сайт.

Сбор результатов и генерация HTML-отчета — два отдельных этапа.

Полный ответ

allure-results содержит исходные данные, созданные adapter во время выполнения тестов: test result files, containers, attachments, environment и другие metadata.

allure-report — готовый HTML-сайт, сгенерированный из этих результатов. Его можно открыть в браузере, сохранить как artifact или опубликовать на web server. Удаленный отчет можно сгенерировать заново, если сохранен allure-results.

Полный ответ

Частые сущности:

• test case — отдельный тест;
• suite — группа тестов;
• step — шаг внутри теста;
• attachment — screenshot, trace, video, log, request или response;
• label — epic, feature, story, owner, severity, tag;
• status — passed, failed, broken, skipped;
• history — информация о предыдущих запусках.

Хорошая структура отчета помогает не читать весь CI log ради одной ошибки.

Полный ответ

Steps разбивают тест на понятные действия: открыть страницу, заполнить форму, отправить запрос, проверить результат. Они помогают увидеть, на каком этапе произошла ошибка и сколько времени занял каждый этап.

Steps должны описывать бизнес-действия или значимые технические операции. Слишком мелкие steps создают шум, а один step на весь тест не помогает локализовать проблему.

Полный ответ

Attachment — файл или данные, связанные с тестом либо step. Для E2E-теста полезно сохранять screenshot, video, Playwright trace, browser console logs и network logs. Для API-теста — request, response, headers и server logs. Для visual regression — actual, expected и diff images.

Attachments должны помогать расследовать падение без повторного запуска. Нельзя публиковать access tokens, пароли, cookies, персональные данные и другие секреты: их нужно удалять или маскировать.

Полный ответ

failed обычно означает, что assertion не прошел или проверяемое поведение не соответствует ожиданию. broken чаще означает ошибку самого теста или инфраструктуры: exception в setup, ошибка fixture, timeout окружения или неподнятый backend.

Точное преобразование ошибок в failed и broken зависит от конкретного adapter.

Полный ответ

Общий принцип одинаковый:

1. Установить совместимый с test runner Allure adapter или reporter.
2. Подключить его в конфигурации test runner.
3. Указать каталог для результатов.
4. Запустить тесты и проверить, что появились result files и attachments.
5. Сгенерировать или открыть отчет через Allure CLI.
6. В CI сохранить результаты и готовый отчет как artifacts либо опубликовать отчет.

Конкретные package names и options зависят от test runner и версии интеграции.

Полный ответ

Полезные метрики:

• pass rate, fail rate, skip rate;
• количество failed и broken tests;
• duration всего прогона и отдельных тестов;
• trend по запускам;
• flaky tests и нестабильные suites;
• самые медленные тесты;
• падения по feature, story, owner, severity и tag;
• история конкретного теста.

Метрики нужны для решений: что чинить первым, где замедление и какие тесты перестали защищать продукт.

Полный ответ

Labels позволяют искать, фильтровать и группировать тесты:

• epic, feature, story описывают продуктовую иерархию;
• owner показывает ответственную команду или человека;
• severity отражает критичность сценария;
• tag добавляет классификацию, например smoke, regression или payments.

Labels полезны, когда они стабильны и связаны с реальной структурой продукта.

Полный ответ

Для trends Allure должен получить history data предыдущего отчета при генерации следующего. Поэтому CI pipeline обычно:

1. Загружает history предыдущего отчета или artifact.
2. Добавляет эти данные к результатам нового запуска способом, который поддерживает используемая версия Allure.
3. Генерирует новый отчет.
4. Сохраняет новый отчет и его history для следующего запуска.

Если CI job всегда начинается с чистого workspace и history не восстанавливается, отчет покажет только текущий запуск.

Полный ответ

Allure должен стабильно идентифицировать один и тот же test case между попытками и запусками. Обычно идентификатор зависит от framework, полного имени теста, параметров и metadata.

Если постоянно менять title, suite или параметры, Allure может воспринимать тест как новый, и история разорвется. Retry может быть временным safety net, но не должен маскировать нестабильность теста.

Полный ответ

Каждый worker или CI job генерирует свою часть Allure results. После выполнения shards результаты собирают в один каталог, а отчет генерируют один раз из объединенного набора.

Обычно отдельный aggregate job скачивает artifacts всех shards, объединяет result files и запускает генератор. Важно не потерять attachments и не перезаписать файлы результатами другого worker.

Полный ответ

Flaky test иногда проходит, а иногда падает без изменения кода. Причины: race conditions, реальные timers, нестабильная сеть, shared state, зависимость от порядка тестов, динамические данные, анимации, неявные ожидания и перегруженное CI окружение. Flaky tests опасны, потому что команда перестает доверять проверкам.

Полный ответ

Нужно воспроизвести падение, изучить trace, video, screenshot и logs, затем убрать недетерминизм. Помогают стабильные locators, явные ожидания состояния, изоляция данных, независимые тесты, test fixtures, mock network, отключение анимаций, контролируемые часы и отказ от произвольных sleep. Retry не заменяет исправление причины.

Полный ответ

Полезный порядок:

1. Проверить status, error message и stack trace.
2. Найти последний успешный step.
3. Открыть screenshot, trace, video и logs.
4. Сравнить environment, параметры и test data.
5. Посмотреть retries и историю теста.
6. Проверить, падают ли соседние тесты по той же причине.
7. Определить класс проблемы: product, test, data, environment или infrastructure.

Allure собирает признаки в одном месте, но инженер все равно должен проверить гипотезу и локализовать причину.

Полный ответ

Для unit и integration tests полезны coverage, junit report и Allure results. Для E2E важны screenshots, videos, Playwright traces, browser console logs, network logs и server logs. Для performance tests сохраняют summary, thresholds, raw metrics и сравнение с baseline. Артефакты должны помогать расследовать проблему без повторного запуска.

Полный ответ

Allure Report не заменяет:

• test runner и сами автотесты;
• корректные assertions и test design;
• CI/CD pipeline;
• code coverage;
• логи приложения и observability;
• issue tracker и процесс triage;
• test management систему, если команде нужны test plans и manual cases.

Красивый отчет не исправляет flaky tests, слабые проверки или отсутствие важных сценариев.

Полный ответ

Метрики отчета можно использовать как один из сигналов: количество failed и broken tests, pass rate, критичные сценарии, длительность или рост нестабильности. Но merge или release gate должен опираться на надежные machine-readable результаты, а не только на HTML-страницу.

Нельзя автоматически блокировать релиз по любой нестабильной метрике без анализа причин: flaky tests и ошибки инфраструктуры могут остановить разработку.

Полный ответ

Отчет и attachments могут содержать URL, headers, cookies, tokens, персональные данные, содержимое форм, screenshots внутренних систем и stack traces. Перед публикацией нужно маскировать секреты, ограничивать доступ и задавать срок хранения artifacts.

Особенно внимательно нужно проверять automatic request/response attachments: они часто сохраняют больше данных, чем ожидает автор теста.

Полный ответ

Обычно запускают format check, lint, typecheck, unit tests, integration tests, build, dependency audit, secret scan, coverage, contract tests и E2E для критичных flows. Для frontend также полезны accessibility и visual regression checks. Для backend — migrations check, API schema validation и smoke tests.

Полный ответ

Quality gate — набор условий, без которых изменение нельзя слить или выпустить. Например: нет failed tests, build проходит, coverage не падает ниже порога, нет critical vulnerabilities, API contract совместим, p95 latency не хуже baseline. Gate должен защищать продукт, а не просто имитировать строгость.

Полный ответ

Сначала измеряют, где время: install, build, unit, integration, E2E, browser setup или artifacts. Затем используют cache, parallelization, test sharding, affected tests, отдельные suites по риску, быстрые smoke checks и nightly full regression. Удалять важные проверки без замены опасно: лучше менять уровень теста или улучшать инфраструктуру.

Полный ответ

Нужно сравнить окружение: viewport, browser version, timezone, locale, CPU, network, test data, feature flags и backend. Дальше смотреть trace, screenshot, video, console и network logs. Частые причины — race condition, слишком слабое ожидание, тестовые данные, анимации, порядок тестов и недостаточная изоляция state.

Полный ответ

Code coverage показывает, какая часть кода была выполнена тестами. Частые метрики: statements, branches, functions и lines. Coverage полезен как индикатор непроверенных зон, но не доказывает качество: тест может выполнить строку и не проверить важное поведение.

Полный ответ

Coverage не говорит, были ли правильные assertions, проверены ли edge cases, соответствуют ли тесты требованиям и ловят ли они реальные регрессии. Можно получить высокий coverage тестами, которые повторяют реализацию или проверяют только happy path. Качество тестов важнее красивого процента.

Полный ответ

Смотрят, какие риски покрыты, насколько быстро тесты дают feedback, легко ли понять падение, насколько они стабильны и не мешают рефакторингу. Хороший набор ловит важные регрессии, локализует проблему, не завязан на случайные детали реализации и поддерживается вместе с продуктовым кодом.

Полный ответ

Нужно разобрать требования, риски, пользователей, данные, интеграции, права доступа, observability и rollback. Затем выбрать минимальный набор проверок: unit для логики, integration для границ, contract для API, E2E для критичного пути, manual exploratory testing для новых UX-сценариев. После релиза важны мониторинг, error alerts и быстрый feedback loop.

Полный ответ

Хорошие сценарии:

• E2E падает только в CI. Как расследовать?
• После релиза вырос error rate. Какие действия?
• Тесты стали идти в три раза дольше. Что измерять?
• Пользователь видит баг, но локально он не воспроизводится. Что делать?
• Как протестировать авторизацию, upload file, поиск, оплату или webhook?
• Какие проверки поставить в CI для frontend и Node.js backend?
• Какие метрики посмотреть в Allure после нестабильного релиза?

Ответ должен показывать инженерное мышление: риск, изоляцию причины, артефакты, проверку гипотез и понятный следующий шаг.