ТРЕНАЖЕР ТЕСТИРОВЩИКА

Модель качества ПО: 6 характеристик

• Функциональность: исправность, соответствие стандартам, совместимость, безопасность, точность.
• Надёжность: завершённость, восстанавливаемость, устойчивость к отказам.
• Удобство использования: удобство изучения, понятность, простота использования.
• Удобство сопровождения: стабильность, анализируемость, контролепригодность, изменяемость.
• Эффективность: эффективность по времени, эффективность использования ресурсов.
• Портативность: удобство установки, заменяемость, совместимость.

Типы тестирования

• Функциональное — проверяем, что система делает то, что должна.
• Интеграционное — как модули работают вместе.
• Регрессионное — что старый функционал не сломали изменениями.
• Smoke — базовая проверка “система вообще жива”.
• Sanity — быстрый чек конкретного фикса/фичи.

Качество ПО: ключевые характеристики

• Функциональность (Functionality) — способность ПО решать задачи пользователя при заданных условиях использования. ПО должно работать исправно и точно, быть совместимым по функционалу, соответствовать отраслевым стандартам и быть защищённым от несанкционированного доступа.
• Удобство использования (Usability) — насколько легко ПО понимать, изучать, использовать и насколько оно привлекательно для пользователя.
• Удобство сопровождения (Maintainability) — насколько легко ПО анализировать, тестировать, изменять для исправления дефектов и реализации новых требований, а также адаптировать к новому окружению.

Жизненный цикл бага (пример)

• New / Open → In Progress → Fixed → Ready for QA → Closed / Reopened.
• Каждый статус отражает этап жизни дефекта от заведения до закрытия.

SDLC — жизненный цикл разработки ПО

• Software Development Life Cycle (SDLC) — это этапы, которые проходит продукт во время его создания.
• На каждом этапе выполняются разные действия (анализ, проектирование, разработка, тестирование, внедрение, сопровождение).
• У каждого этапа есть свой результат (артефакт): требования, дизайн, код, тестовая документация, релиз и т.д.

Этапы жизненного цикла ПО (детально)

• Этап 1 — Идея: у заказчика появляется идея продукта. Результат: сама идея, сформулированная задача “что хотим получить”.
• Этап 2 — Сбор требований: бизнес‑аналитик и QA собирают требования, формируют бизнес‑требования и приемочные критерии (Acceptance criteria), QA проверяет полноту и понятность требований. Результат: набор бизнес‑требований и согласованные критерии приёмки.
• Этап 3 — Архитектура и дизайн: системный архитектор выбирает технологии, строит архитектуру, дизайнер создаёт макеты и UX/UI. Результат: технические требования и дизайн будущего продукта.
• Этап 4 — Разработка: разработчики пишут код, собирают систему. Результат: рабочий билд (сборка), пригодный для тестирования.
• Этап 5 — Тестирование: QA/QC проверяют соответствие билда требованиям, ищут дефекты, оценивают качество. Результат: баг‑репорты и понимание состояния сборки.
• Этап 6 — Исправление дефектов: разработчики исправляют найденные ошибки (баг‑фиксинг), QA перепроверяет. Результат: исправлены все критические дефекты на текущем этапе.
• Этап 7 — Верификация и RC Build: тестировщики перепроверяют исправленные дефекты. Возможны две ситуации: (1) все критические дефекты действительно исправлены и мы получаем RC‑билд (Release Candidate), (2) находятся новые или не до конца исправленные проблемы, и цикл “баг‑фиксинг → верификация” повторяется до получения стабильного RC‑билда. Итог: получен RC Build, готовый к релизу.

QA vs QC — в чём разница

• QA (Quality Assurance) — обеспечение качества: процедуры и практики, которые охватывают весь жизненный цикл ПО (от идей и требований до релиза и поддержки), чтобы процесс разработки в целом был качественным.
• Главная цель QA — выстроить такой процесс, при котором дефектов возникает меньше, а продукт стабилен и предсказуем по качеству.
• QC (Quality Control) — контроль качества: часть QA, сосредоточенная на проверке конкретного продукта (билда) — анализ результатов тестирования, поиск ошибок, сравнение с требованиями.
• Примеры QC‑задач: проверить соответствие требованиям и уровню качества, оценить готовность к релизу, найти и описать критические дефекты.
• Главная цель QC — убедиться, что конкретный билд соответствует заявленным требованиям и уровню качества заказчика.

Testing — тестирование как часть QC

• Testing — это конкретные действия по проверке продукта, которые входят в QC и запускаются после получения билда на этапе тестирования жизненного цикла ПО.
• Основные активности тестирования:
  • создание тестов (чек‑листы, тест‑кейсы, сценарии);
  • выполнение тестов (ручное и/или автоматизированное);
  • анализ полученных результатов (что прошло, что упало, где риски);
  • поиск и локализация дефектов для последующего баг‑репорта.
• Таким образом, QA задаёт каккак

Роли в процессе обеспечения качества

• Test Engineer (тестировщик) — работает внутри процесса Testing/QC: проектирует и выполняет тест‑кейсы и чек‑листы, ищет и локализует дефекты, оформляет баг‑репорты.
• QC Engineer (Quality Control Engineer) — тест‑лид, работающий в рамках QC‑процесса: следит за уровнем качества продукта на этапе тестирования, сравнивает фактическое качество с требованиями и целями, принимает участие в решении “готово ли к релизу”.
• Главная цель QC Engineer — выявить недостатки продукта после завершения разработки, но до релиза, и дать честную картину готовности продукта.
• Особенность: QC Engineer ориентирован на оценку уже реализованного продукта, а не только на написание тест‑кейсов.

Чек‑листы

• Чек‑лист тестировщика — структурированный список проверок, который упорядочивает тестирование ПО. Он содержит перечень элементов, функций или сценариев, которые нужно протестировать для оценки качества.
• Цель чек‑листа — структурировать проверку и снизить риск пропустить важные шаги, особенно в рутине (регресс, smoke, базовые проверки форм и т.п.).
• Отличие от тест‑кейса: чек‑лист не требует детального описания шагов — он показывает, чтокак
• 2 основных типа чек‑листов:
• Специальные — создаются под конкретный проект с учётом его особенностей. Обычно не подходят для других проектов из‑за специфики.
• Универсальные — применимы в однотипных проектах и описывают общие сценарии, которые можно использовать многократно (например, smoke/регресс для типового веб‑приложения).
• В симуляторе чек‑листы используются как:
  • рабочий инструмент (отмечаешь выполненные проверки по фиче или регрессу);
  • тренажёр — нужно выстроить шаги в правильном порядке и понять, что и зачем проверяется.

Модель качества ПО: 6 характеристик

• Функциональность, Надёжность, Удобство использования, Удобство сопровождения, Эффективность, Портативность.

Что такое документация

• Документация — это не только официально согласованные документы. Письма, переписка в мессенджерах, заметки в тетради, записки, сделанные во время митингов с командой, абсолютно всё, что обсуждается или создаётся в процессе разработки, можно считать документацией.

Задача документации для тестирования

• Задача документации для тестирования — уменьшение неопределённости в процессе тестирования, а также исключение двусмысленных и непонятных задач.

Виды документации

• Документацию можно разделить на два больших вида, которые используются на проектах по разработке ПО:

Создать документацию (фичу)

Проектная документация

• Такая документация включает в себя всё, что относится к проекту в целом:
• Документацию по разрабатываемому продукту (требования, технические спецификации)
• Пользовательскую и сопроводительную документацию (инструкции для пользователей, лицензионные соглашения)
• Маркетинговую документацию (исследования рынка перед началом разработки, рекламная продукция для продвижения продукта)

Продуктная документация

• Является частью проектной документации, которая относится непосредственно к разрабатываемому ПО.
• Примеры того, что включает в себя продуктная документация:
• план проекта
• требования к продукту
• функциональные требования
• макеты архитектуры и дизайна приложения
• тест-кейсы и наборы тест-кейсов
• технические спецификации (схемы баз данных, описания алгоритмов)
• Важно: продуктная документация является частью проектной документации.

Требования

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

Почему требования важны

• Позволяют понять, что система должна делать и с соблюдением каких условий.
• Помогают оценить масштаб изменений и объём работ.
• Лежат в основе плана проекта (в том числе плана тестирования).
• Помогают предотвращать и разрешать конфликтные ситуации (например: «Это баг или фича?»).
• Упрощают расстановку приоритетов при разработке.
• Позволяют объективно оценить степень прогресса в разработке.

Всегда держите в голове

• Если проблему в требованиях найти на самой первой стадии (формирование и тестирование требований), её решение часто сводится к правке пары слов в тексте.
• Та же проблема, пропущенная на этапе требований и найденная уже на стадии использования продукта, может привести к полному провалу проекта.

Типы требований

• Функциональные требования — описывают, что должна делать система (поведение, проверки, обработка данных).
• Нефункциональные требования — описывают, какой

Бизнес‑требования

• Бизнес‑требования — документ, который отражает видение и желания заказчика и, главное, цель, ради которой разрабатывается продукт.
• Отвечают на вопросы: «Зачем нужен продукт?», «Какую пользу он принесёт?», «Как бизнес будет зарабатывать?».
• Обычно это текстовый документ с описанием целей, приоритетов, рисков, иногда с таблицами и графиками.
• Примеры: «Нужно упростить механизм отправки приглашений с сайта», «Необходимо автоматизировать процесс доставки товара».

Пользовательские требования

• Пользовательские требования — документ, описывающий задачи, которые пользователь может выполнить с помощью системы.
• Могут включать поведение системы, пользовательские сценарии, функциональные и нефункциональные особенности.
• Примеры: «При первом входе пользователя в систему должно отображаться лицензионное соглашение», «Чтобы подать заявку, пользователь переходит в раздел “Курсы” и нажимает кнопку “Подать заявку”».

Системные требования

• Системные требования — документ, описывающий условия, необходимые для запуска и работы ПО.
• Включают требования к «железу» (CPU, память, диск) и окружению (ОС, драйверы, браузеры и т.п.).
• Пример: «ОС: Windows 10; 2 ГБ ОЗУ; 40 ГБ свободного места; стабильное интернет‑соединение».

Функциональные требования — примеры

• «При нажатии на кнопку “Добавить” товар появляется в корзине».
• «Программа должна автоматически выполнять резервное копирование данных ежедневно в 12:30 по МСК».

Нефункциональные требования — примеры

• Производительность: «Новая учётная запись пользователя создаётся менее чем за 2000 мс».
• Надёжность: «Система должна иметь доступность не менее 99,9%».
• Ёмкость: «Система обслуживает до 1000 одновременных пользователей».
• Масштабируемость: «Система должна быть масштабируемой для роста числа пользователей».
• Удобство использования: «Пользователь может перейти на любую страницу сайта максимум за 3 клика».

Непротиворечивость требований

• Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.

Частые ошибки в требованиях

• Противоречия внутри одного требования (в одном тексте одновременно «нельзя» и «можно»).
• Противоречия между разными требованиями (одно разрешает действие, другое его запрещает).
• Если два требования вступают в конфликт, как минимум одно из них некорректно и требует уточнения.

Пример конфликта требований

• Плохое требование: «Пользователь может авторизоваться через VK, Instagram, Google» — в одном требовании зашито сразу несколько возможностей.
• Лучше разбить:
• Требование 4. Пользователь может авторизоваться через VK.
• Требование 5. Пользователь может авторизоваться через Instagram.
• Требование 6. Пользователь может авторизоваться через Google.
• Так проще увидеть, что, например, для одной соцсети авторизация реализована, а для другой — нет.
• Другой пример: в одном требовании сказано, что кнопка «Купить» жёлтая, а в другом — что она зелёная. Правильное решение — одно чёткое требование с указанием цвета.

Недвусмысленность требований

• Недвусмысленность — требование сформулировано так, что допускает только одно объективное понимание, без неочевидных аббревиатур и расплывчатых слов.

Частые ошибки (недвусмысленность)

• Использование субъективных формулировок: «удобный», «быстрый», «простой», «улучшенный», «гибкий».
• Использование союза «и», который прячет сразу несколько требований в одну строчку.
• Неочевидные или двусмысленные аббревиатуры без расшифровки.

Примеры (недвусмысленность)

• Плохо: «Приложение должно иметь понятный и удобный интерфейс» — непонятно, как измерить «понятный» и «удобный».
• Хорошо: «Приложение должно иметь интерфейс, основанный на макете (приложение 1)» — есть конкретный артефакт, с которым можно сравнивать.

Корректность требований

• Корректность — каждое требование чётко и конкретно описывает нужную функциональность и не содержит ошибок или устаревших данных.

Частые ошибки (корректность)

• Орфографические и смысловые ошибки в тексте, меняющие смысл.
• Неточности в данных (неверные статусы, коды ошибок, лимиты и т.д.).
• Устаревшие требования, которые давно не отражают фактическое поведение системы.

Полнота требований

• Полнота — требование содержит всю информацию, необходимую разработчику и тестировщику, чтобы правильно спроектировать, реализовать и проверить функциональность.

Частые ошибки (полнота)

• Опора на «это же очевидно» — важные детали не описаны явно.
• Слишком общие формулировки без условий и шагов.
• Часть сценариев (ошибки, альтернативные потоки) не описана.

Примеры (полнота)

• Плохо: «Программа должна сохранить рисунок при нажатии на кнопку» — неясно, в каком формате, куда и что увидеть пользователю.
• Лучше разбить на несколько требований:
• Требование 1. Программа должна отображать кнопку сохранения рисунка.
• Требование 2. Программа должна сохранять рисунок в галерею в формате .png.
• Требование 3. Программа должна выводить уведомление о сохранении рисунка.

Проверяемость требований

• Проверяемость — требование сформулировано так, что существует понятный способ однозначно ответить: «выполнено оно или нет».

Частые ошибки (проверяемость)

• Нет чётких критериев успеха: невозможно сказать, выполнено требование или нет.
• Формулировки уровня «удобный/понятный интерфейс» без конкретики.

Примеры (проверяемость)

• Плохо: «В случае ошибки приложение должно закрыться» — непонятно, о какой ошибке речь.
• Хорошо: «В случае ошибки ER500 приложение должно закрыться» — можно воспроизвести конкретный код ошибки и проверить поведение.

Приоритетность требований

• Приоритет — количественная оценка важности требования для бизнеса и пользователя.
• Чем выше приоритет, тем раньше и внимательнее реализуется и тестируется требование.

Частые ошибки (приоритет)

• Все требования помечаются как одинаково важные.
• 90% требований получают наивысший приоритет — команда теряет фокус на действительно критичных задачах.

Хороший пример разметки приоритета

• Требование 143 — низкий приоритет.
• Требование 144 — высокий приоритет.
• Требование 145 — средний приоритет.
• Чёткая градация помогает планировать релизы и тестирование.

Прослеживаемость требований

• Прослеживаемость — у каждого требования есть уникальный идентификатор, по которому на него можно сослаться в других документах, тест‑кейcах и баг‑репортах.

Частые ошибки (прослеживаемость)

• Требования не пронумерованы или имеют дублирующиеся номера.
• Набор требований неполный, есть явные «дыры» в нумерации.
• Ссылки ведут на старые или удалённые документы.
• Перекрёстные ссылки в тексте не работают или ведут не туда.

Пример хорошей прослеживаемости

• Требование 1. При создании пользователя данные должны отправляться в базу данных (см. Требование 26).
• Требование 26. Отправка данных в базу данных осуществляется посредством POST‑запроса по описанному алгоритму.
• Тест‑кейс TC‑001 ссылается на Требование 1 и Требование 26 — легко понять, что именно проверяется.

Модифицируемость требований

• Модифицируемость — насколько просто вносить изменения в отдельные требования и в набор требований в целом.
• Говорить о модифицируемости можно только тогда, когда нужную информацию легко найти, а её изменение не ломает другие свойства хороших требований.

Частые ошибки (модифицируемость)

• Требования представлены в неудобной для обработки форме (сплошные абзацы текста без структуры).
• Присутствует избыточность: одно и то же описано в нескольких местах разными словами.
• Слишком сложная структура документа или полное отсутствие структуры.

Пример (модифицируемость и атомарность)

• Плохо: «Когда пользователь входит в систему, он должен видеть приветствие. Когда пользователь вошёл в систему, он должен видеть имя пользователя. Когда пользователь выходит из системы, должно отображаться прощание» — в одном требовании зашито сразу несколько разных сценариев.
• Хорошо:
• Требование 1. Когда пользователь входит в систему, должно отображаться приветствие.
• Требование 2. Когда пользователь вошёл в систему, должно отображаться имя пользователя.
• Требование 3. Когда пользователь выходит из системы, должно отображаться прощание.
• Так каждое требование можно легко найти, изменить и протестировать отдельно.

План тестирования (Test Plan)

• План тестирования — документ, который описывает весь объём работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
• Важно знать: этот документ формальный, он может быть в любом виде, может содержать те или иные пункты или не содержать их.
• Ответственность за создание документа плана тестирования лежит на Тест‑лиде или Тим‑лиде.

Примерное содержание тест‑плана

• 1. Что надо тестировать? — содержит описание объекта тестирования: системы, приложения, оборудования.
• 2. Что будете тестировать? — содержит список функций и описание тестируемой системы и её компонентов в отдельности.
• 3. Как будете тестировать? — содержит стратегию тестирования, а именно: типы и виды тестирования и их применение по отношению к объекту тестирования.
• 4. Когда будете тестировать? — содержит последовательность проведения работ: подготовка, тестирование, анализ результатов.
• 5. Критерии начала тестирования:
  • Готовность тестовой платформы (тестового стенда)
  • Законченность разработки требуемого функционала
  • Наличие всей необходимой документации
  • Остановка внесения изменений в исходный код на период тестирования (Code Freeze)
• 6. Критерии окончания тестирования:
  • Результаты тестирования удовлетворяют критериям качества продукта
  • Результаты тестирования удовлетворяют приемочным критериям
  • Нет критических дефектов
• 7. Хорошие дополнения:
  • Окружение тестируемой системы (Браузер, ОС и т.д.)
  • Необходимое для тестирования оборудование и программные средства (тестовый стенд и его конфигурация, программы для автоматизированного тестирования и т.д.)
  • Риски и пути их разрешения

Тестовая стратегия (Test Strategy)

• Стратегия тестирования — самый важный документ для любой команды QA, который содержит описание подхода к проведению тестирования.
• По сути своей, это относительно небольшой статический документ, который предшествует плану тестирования.
• Написание эффективного стратегического документа — это навык, который тестировщик развивает с опытом.
• Прежде чем писать объёмный и подробный план, стоит формализовать некоторые базовые подходы к тестированию и убедиться, что все заинтересованные лица понимают одинаково, что и как будет тестироваться.
• Вероятность пропустить какую‑либо тестовую активность очень мала, если существует правильная стратегия тестирования.

Что включает в себя стратегия тестирования

• Роли и обязанности в команде тестирования — описание того, кто и за что отвечает.
• Область тестирования — компонент или весь программный продукт.
• Тестовые инструменты — какие инструменты будут использоваться в ходе тестирования.
• Тестовая среда — в каком окружении будет проводиться тестирование (обычно это dev или production).
• График тестирования — последовательность и сроки работ.
• Сопутствующие риски — описание того, что можем не успеть протестировать и прочее.

Подготовка к собеседованию: документация и требования

• Документация: уметь объяснить, что это такое, какие есть виды (проектная и продуктная), и зачем она нужна тестировщику.
• Требования: знать определение, уметь привести примеры бизнес‑, пользовательских и системных требований.
• Типы требований: различать функциональные и нефункциональные требования и приводить по ним конкретные примеры.
• Свойства качественных требований: называть и пояснять хотя бы часть из списка: атомарность, непротиворечивость, недвусмысленность, корректность, полнота, проверяемость, приоритетность, прослеживаемость, модифицируемость.
• Стратегия тестирования: понимать её содержание (роли, область тестирования, инструменты, среда, график, риски) и отличие от тест‑плана.
• Тест‑план: уметь объяснить, зачем он нужен и что в него входит: что/как/когда тестируем, критерии начала/окончания, окружение, оборудование, риски.

Основные принципы тестирования требований

• Тестирование требований лучше проводить до старта разработки. Для этого нужно рассчитать необходимое время на проверку и заморозить тестируемую документацию до окончания проверки (не вносить изменения).
• Проводить тестирование требований могут как аналитики, так и тестировщики. Однако, для достижения лучшего результата описание и проверку требований следует поручать разным людям.
• Выявление дефектов по документации ничем не отличается от выявления дефектов по продукту: баги следует заносить в систему баг‑трекинга, как обычно.
• В том случае, когда проверка требований ведётся параллельно с разработкой, крайне желательно предупредить команду разработки о найденных дефектах (чтобы они могли вовремя исправить ошибку).
• Уровень детализации требований (как и глубина тестирования) сильно зависит от уровня проекта. Нет смысла проверять время реакции на кнопку в проекте, который только запустился (если это, конечно, не относится к ключевому функционалу).
• Главное правило: умение ставить себя на место пользователя, попавшего в определённую проблемную ситуацию.

Техники тестирования требований

• Взаимный просмотр (рецензирование) — автор показывает требования коллегам и собирает замечания. Бывает:
  • Беглый просмотр — быстрый просмотр документа одним‑двумя коллегами для поиска описок, нестыковок и очевидных ошибок.
  • Технический просмотр — обсуждение документа группой специалистов (аналитики, разработчики, дизайнеры, тестировщики). Требования считаются качественными, когда у всех участников не остаётся критичных замечаний.
• Вопросы — при любом непонимании или сомнении по требованию задаются уточняющие вопросы заказчику, аналитику или более опытным коллегам. Ответ должен приводить к улучшению формулировки требования.
• Тест‑кейсы и чек‑листы — по требованию легко составляются пункты чек‑листа и/или тест‑кейсы. Если придумать проверки сложно, скорее всего требование неполное или непроверяемое.
• Исследование поведения системы — мысленно (или на бумаге) моделируются сценарии работы пользователя по этим требованиям, чтобы найти неоднозначные или упущенные варианты использования.
• Рисунки и схемы — графические диаграммы, пользовательские флоу и схемы состояния помогают увидеть несостыковки, пропуски и противоречия, которые трудно заметить в тексте.
• Прототипирование — быстрые прототипы интерфейса (скетчи, кликабельные макеты) позволяют оценить, насколько требования реалистичны и понятны с точки зрения будущего UX.

Пример: тестирование формы отправки письма (Outlook)

• Функциональность полей: адресаты (To/Cc/Bcc), тема, тело письма (plain/HTML), вложения, выбор отправителя/аккаунта.
• Валидация: формат email, обязательность адресата, поведение при пустой теме, ограничения на размер/тип вложений.
• Отправка: успешная отправка, появление письма в папке “Отправленные”, доставка нескольким адресатам, обработка ошибок (нет сети, неверный адрес).
• Дополнительно: сохранение черновиков, автосохранение, корректное отображение форматирования и вложений у получателя.

Пример: тест‑кейсы для мобильного приложения “Кубик”

• Диапазон значений: при броске всегда выпадает число от 1 до 6, нет других значений.
• Соответствие UI: значение 1‑6 соответствует правильной грани кубика (точки расположены корректно).
• Повторные броски: быстрое многократное нажатие или жест не ломает приложение, каждый бросок даёт один результат.
• Жесты/кнопки: бросок срабатывает от всех заявленных способов (кнопка, shake и т.п.), нет случайных срабатываний.
• Вибро/звук: при включенных настройках есть отклик, при отключённых — нет.
• Поворот экрана: при смене ориентации последнее значение не теряется и отображается корректно.
• История/статистика (если есть): история бросков и счётчик значений обновляются корректно.

Тестовое задание №1: автомат со скидочными баллами

• Условие: автомат принимает накопительные карты и по количеству баллов выбирает скидку: 0–100 баллов — 1%, 100–200 — 3%, 200–500 — 5%, от 500 и выше — 10%.
• Что от тебя хотят: составить такой набор тест‑данных, чтобы по ним можно было гарантированно проверить правильность расчёта скидки.
• Разбор по шагам:
  • Сначала проясни границы: «0–100» — это 0 включительно и 100 не входит, или наоборот? Важно зафиксировать это в виде [0; 100), [100; 200) и т.д.
  • Для каждого диапазона выбери минимум 3 значения: нижнюю границу, типичное значение внутри и верхнюю границу–1 (например, 0, 1, 99; 100, 150, 199; 200, 350, 499; 500, 750, 10 000).
  • Отдельно продумай «необычные» значения: отрицательные баллы, слишком большие числа, буквы вместо числа — и договорись, как система должна реагировать.
• Как оформить результат: в виде небольшой таблицы/списка (ID теста, входные баллы, ожидаемый процент скидки, комментарий). В репозитории это обычно кладут в файл вроде TaskTestData.md.

Тестовое задание №2: end‑to‑end автотест для Avito

• Условие: нужно написать автотест, который:
  • авторизуется на avito.ru (логин/пароль в тестовом задании не выкладывают, оставляют пустыми);
  • выбирает любое доставочное объявление из категории «личные вещи» по готовой ссылке;
  • нажимает «Купить с доставкой» и переходит к оформлению заказа;
  • проверяет, что поле «Телефон» при оформлении доставки пустое.
• Требования к решению: любой язык и технологии, код на GitHub, тесты должны запускаться и показывать passed/failed, желательно использовать Page Object.
• Как мыслить как тестировщик/авто‑QA:
  • Разбей задачу на шаги: логин → выбор объявления → переход к доставке → проверка поля телефона.
  • Продумай устойчивость теста: как ты находишь объявление (по первому в списке, по какому‑то фильтру), как ждёшь загрузку страницы (явные/неявные ожидания).
  • Спрячь чувствительные данные: логин/пароль не выкладываются в репозиторий, в коде вместо них оставляют заглушки или читают из переменных окружения (для реальной жизни).
  • Структурируй код через Page Object: отдельный класс для страницы логина, отдельный — для карточки объявления, отдельный — для страницы оформления доставки.
• Что обычно спрашивают на собесе по такому заданию: как ты выбирал локаторы, как справлялся бы с капчей/нестабильностью, как бы параметризовал тест под разные города/объявления.

Тестовое задание №3: интерфейс «Объекты/Пользователи» (Makves)

• Зачем это задание: проверить, как ты ориентируешься в незнакомом веб‑интерфейсе и умеешь ли по нему быстро набросать адекватный тест‑план/набор тест‑кейсов.
• Условие (кратко): зайти в Chrome на стенд по адресу http://dev.makves.ru:8001/ под логином reader и паролем e995513fcd7a5af5a5de0ea887c34c4de99d384dbc, открыть раздел меню «Объекты/Пользователи» и составить 15–20 тест‑кейсов на проверку интерфейса этой страницы (на русском языке).
• Как на него смотреть как на тестировщик:
  • Сначала исследуй страницу: какие есть таблицы, фильтры, поля поиска, кнопки, выпадающие списки, пагинация, сортировки, массовые действия и т.п.
  • Разбей будущие тест‑кейсы на логические блоки: отображение данных, фильтрация/поиск, сортировка, пагинация, действия с пользователями/объектами, валидация полей (если есть формы), права доступа (что может делать пользователь с ролью reader).
  • Для каждого блока продумай позитивные сценарии (всё работает как должно) и базовые негативные сценарии (невалидный ввод, пустые результаты, ошибки загрузки, отсутствие прав и т.п.).
• Как может выглядеть решение (пример структуры):
  • TC‑UI‑01 — «Страница “Объекты/Пользователи” открывается без ошибок, заголовки и основные элементы интерфейса отображаются корректно».
  • TC‑UI‑02 — «Таблица пользователей загружается: колонки, данные, корректный текст при пустом списке».
  • TC‑UI‑03…TC‑UI‑06 — проверки сортировки по разным столбцам (по возрастанию/убыванию, индикатор сортировки, сохранение состояния при перезагрузке, если актуально).
  • TC‑UI‑07…TC‑UI‑10 — фильтры и поиск: поиск по имени/логину/ID, комбинации фильтров, отсутствие результатов, сброс фильтров.
  • TC‑UI‑11…TC‑UI‑14 — пагинация: переход между страницами, изменение размера страницы (если есть), корректный подсчёт количества записей.
  • TC‑UI‑15…TC‑UI‑18 — действия над строками (открытие карточки пользователя/объекта, доступность/недоступность кнопок для роли reader, сообщения об ошибке при отсутствии прав).
• Формат отправки решения: набор тест‑кейсов в XLS или в виде читаемого скрина таблицы (ID, Название, Предусловия, Шаги, Ожидаемый результат).

Тестовое задание №4: логин с Yandex SmartCaptcha (OneCell)

• Контекст проблемы: сейчас страница логина https://dev1.onecell.ru/login не защищена от брута: можно бесконечно подбирать пароль.
• Решение по требованию: добавить Yandex SmartCaptcha так, чтобы она включалась только при подозрительной активности:
  • Правило 1: если за 5 минут было совершено 5 неуспешных попыток авторизации — показывается капча («Я не робот» или задание). Капча отключается один раз в 15 минут или после успешного логина.
  • Правило 2: если за 3 минуты было совершено 10 неуспешных попыток авторизации с одного IP — капча показывается всем пользователям с этого IP. Отключение для IP — через 10 минут.
• Что тебе нужно сделать как QA:
  • Протестировать модуль авторизации/аутентификации (логин‑форма, обработка валидных/невалидных данных, ошибки, локализация).
  • Спроектировать тест‑кейсы или чек‑лист по логике капчи: счётчики попыток, таймеры (3 и 5 минут), привязка к IP, отключение капчи после успешного входа и по истечении времени.
  • По найденным дефектам оформить баг‑репорты с полным набором артефактов (шаги, ожидаемый/фактический результат, окружение, скриншоты/видео).
• Как разложить задачу по шагам:
  • 1. Базовая авторизация без капчи. При 0–4 неуспешных попытках в пределах 5 минут капча не показывается, при валидном логине/пароле вход проходит успешно.
  • 2. Проверка правила 1 (5 попыток за 5 минут).
    • Совершить 5 заведомо неверных попыток логина подряд (или в пределах 5 минут) — убедиться, что после этого появляется капча.
    • Проверить, что 4 неуспешные попытки подряд капчу не включают.
    • После появления капчи ввести верные логин/пароль, успешно авторизоваться — убедиться, что капча перестала требоваться (правило «выключается при успешной авторизации»).
    • Проверить, что если не логиниться успешно, а просто подождать 15 минут, капча сама перестанет появляться.
  • 3. Проверка правила 2 (10 попыток за 3 минуты с IP).
    • С одного IP (можно просто с одной машины/браузера) выполнить 10 неуспешных попыток за 3 минуты — убедиться, что капча начинает показываться для всех пользователей с этого IP (даже если они ещё не ошибались).
    • Убедиться, что с другого IP (другой сети/прокси) в это время капча не появляется, если там не было своих попыток.
    • Проверить, что через 10 минут после достижения порога капча для IP автоматически перестаёт показываться (при прочих равных).
  • 4. Комбинации и крайние случаи.
    • Сначала сработало правило 1 (для пользователя), потом на этом же IP добили до порога по правилу 2 — как система ведёт себя для других пользователей?
    • Проверить, не сбрасываются ли счётчики попыток при перезагрузке страницы, смене браузера/устройства, но при том же IP.
    • Проверить поведение при «пограничных» значениях: ровно 5 попыток за чуть более чем 5 минут, ровно 10 попыток чуть больше 3 минут и т.д.
• Примеры тест‑кейсов (структура):
  • TC‑AUTH‑01 — «Успешная авторизация валидными данными при отсутствии капчи».
  • TC‑AUTH‑02 — «Отображение сообщения об ошибке при неверном пароле, капча не показывается при <5 ошибках за 5 минут».
  • TC‑CAPTCHA‑01 — «Появление капчи после 5‑й неуспешной попытки в пределах 5 минут, исчезновение после успешного логина».
  • TC‑CAPTCHA‑02 — «Автоматическое отключение капчи через 15 минут без успешной авторизации (правило 1)».
  • TC‑CAPTCHA‑03 — «Появление капчи для всех пользователей IP после 10 неуспешных попыток за 3 минуты».
  • TC‑CAPTCHA‑04 — «Автоматическое отключение капчи для IP через 10 минут (правило 2)».
  • TC‑CAPTCHA‑05 — «Капча не появляется на другом IP, пока там не достигнуты свои пороги ошибок».
• Какие баги здесь чаще всего вылезают:
  • Неправильный учёт времени (капча включается/выключается слишком рано или поздно).
  • Сброс счётчика попыток не там, где нужно (после перезагрузки страницы, смены браузера).
  • Капча продолжает требоваться даже после успешного логина.
  • Правило по IP срабатывает не только для этого IP, но и для других пользователей (ошибка в определении IP).
  • Отсутствие понятного сообщения пользователю, почему появилась капча или почему вход заблокирован.
• Как оформить результат: тест‑кейсы/чек‑лист и баг‑репорты можно оформить в Google Sheets/Docs, Notion, TestRail, Qase или просто в таблице/тексте — главное, чтобы были видны шаги, ожидаемый результат и фактический результат.

Тестовое задание №5: сайт «ФрутоНяня» — регистрация, авторизация и пользовательский сценарий

• Сайт: https://frutonyanya.ru/.
• Что просят в задании:
  • 1. Составить чек‑лист тестирования регистрации на сайте.
  • 2. По задаче «Пользователь не смог авторизоваться, проверить корректность работы авторизации» — описать, какие данные тебе нужны и как будешь проверять.
  • 3. Расписать любой сценарий поведения пользователя в виде тест‑кейса.
• Как правильно «прочитать» задание:
  • Это не просто «потыкать сайт», а показать, что ты умеешь:
    • выделять функциональность (регистрация, авторизация, личный кабинет и т.п.);
    • структурировать проверки в виде чек‑листа и тест‑кейсов;
    • задавать правильные вопросы по инциденту с авторизацией.
  • Работать нужно как с боевым продуктом: аккуратно с реальными данными (почта/телефон), помнить про согласие на рассылки и т.д.
• 1. Чек‑лист регистрации на сайте (что обязательно учесть):
  • Страница и доступность формы:
    • Страница регистрации открывается по ожидаемой ссылке/кнопке (например, «Регистрация», «Войти» → «Зарегистрироваться»).
    • Форма отображается корректно: поля, подписи, чекбоксы, кнопка отправки видны и не перекрыты.
  • Поля и валидация (типичный набор):
    • Email/телефон/логин (в зависимости от того, что использует сайт).
    • Пароль и подтверждение пароля.
    • Имя/фамилия/дата рождения ребёнка и т.п. — если такие поля есть.
    • Чекбоксы «Согласен с условиями», «Согласие на рассылку» и т.п.
  • Позитивные проверки:
    • Регистрация с валидным набором данных проходит успешно (пользователь видит понятное сообщение/попадает в личный кабинет).
    • При повторной попытке регистрации с тем же email/телефоном система выдаёт корректную ошибку «Такой пользователь уже существует» (если это предусмотрено).
  • Негативные проверки:
    • Пустая форма → подсветка обязательных полей, понятные сообщения об ошибке.
    • Неверный формат email (без «@», без домена и т.п.).
    • Слишком короткий/длинный пароль, запрещённые символы, отсутствие цифр/букв (если есть требования).
    • Несовпадение пароля и подтверждения.
    • Отсутствие галочки «Согласен с условиями» (если без неё нельзя зарегистрироваться).
  • Письмо/подтверждение (если есть e‑mail‑верификация):
    • Письмо приходит на корректный адрес, тема и текст понятны.
    • Ссылка внутри письма рабочая, переводит на нужную страницу, аккаунт активируется.
    • Проверка истечения срока действия ссылки (если ограничено по времени).
  • UX‑мелочи:
    • Понятные подсказки в полях и сообщения об ошибках.
    • Сохранение введённых данных при ошибке (чтобы не вводить всё заново).
• 2. Инцидент: «Пользователь не смог авторизоваться» — какие данные нужны и как проверять:
  • Какие данные запросить:
    • Логин пользователя (email/телефон/ID) — точное значение.
    • Скриншоты/видео с ошибкой (сообщение, URL, время).
    • Примерное время, когда была попытка входа (для поиска в логах).
    • Информация об устройстве/браузере (мобильный/десктоп, Chrome/Safari и т.д.).
    • Уточнение, менял ли пользователь недавно пароль, подтверждал ли аккаунт по почте.
  • Как будешь проверять (план действий):
    • Воспроизвести сценарий пользователя: попробовать авторизоваться с тем же логином/шагами (если есть доступ к тестовой среде с похожими данными).
    • Проверить разные типы ошибок: неверный пароль, неактивированный аккаунт, заблокированный пользователь.
    • Сверить поведение фронта: корректные ли тексты ошибок, нет ли «тихих» падений.
    • Если есть доступ — проверить логи/админку: статус аккаунта (активен/заблокирован), правильность сохранённого логина.
    • Сравнить с ожидаемым дизайном/требованиями: нет ли рассинхрона («по ТЗ тут одно сообщение, а на фронте другое»).
• 3. Пример тест‑кейса (сценарий поведения пользователя):
  • TC‑FRU‑REG‑01 — «Успешная регистрация нового пользователя по email на frutonyanya.ru»
  • Предусловия: используется уникальный email, который ранее не регистрировался на сайте.
  • Шаги:
    • Открыть главную страницу https://frutonyanya.ru/.
    • Нажать на кнопку/ссылку «Войти» → выбрать «Регистрация» (или аналогичный путь).
    • Заполнить поле email валидным адресом (например, user+test@example.com).
    • Ввести пароль, удовлетворяющий требованиям (длина, символы), и повторить его в поле «Подтверждение пароля».
    • Заполнить остальные обязательные поля (имя, дата рождения ребёнка и т.п., если есть).
    • Отметить обязательные чекбоксы согласий.
    • Нажать кнопку «Зарегистрироваться».
  • Ожидаемый результат:
    • Форма отправляется без технических ошибок (нет 500/JS‑ошибок).
    • Появляется понятное сообщение об успешной регистрации или происходит редирект в личный кабинет.
    • Если предусмотрена e‑mail‑подтверждение — на указанный адрес приходит письмо с подтверждением.
• Как оформить решение: чек‑лист можно оформить таблицей (пункт чек‑листа + комментарий/статус), тест‑кейс — в стандартном шаблоне (ID, Название, Предусловия, Шаги, ОР). В этом тренажёре ты можешь использовать готовый чек‑лист «Регистрация: frutonyanya.ru» в разделе чек‑листов и дополнять его своими пунктами.

Что такое тест‑кейс

• Тест‑кейс — это документ, описывающий последовательность действий для проверки определённой функциональности с указанием ожидаемых результатов.
• По сути, это детальная инструкция: какие шаги выполнить, какие данные ввести и что должно получиться в каждом шаге.
• Хороший тест‑кейс позволяет разным тестировщикам провести проверку одинаково тщательно и получить сопоставимые результаты.
• В связке с чек‑листом: чек‑лист помогает не забыть, чтокак

Пример: отчёт «Победитель с не наименьшей ценой»

• В отчёте по закупочной процедуре есть признак: «Победитель с не наименьшей ценой» — значения Да/Нет.
• Правило: если среди всех заявок (и на основном этапе, и на переторговке) есть цена строго ниже цены победителя, то признак = «Да», иначе «Нет».
• Разбор примера: на основном этапе цены: 100, 1000, 5000; на переторговке: 100, 999, 4000; побеждает заявка с ценой 999 на переторговке.
• Минимальная цена среди всех заявок = 100, она меньше 999 ⇒ в отчёте должно быть «Да» (победитель выбрался не с минимальной ценой).
• Чтобы получить «Нет», нужно, чтобы цена победителя совпадала с минимальной ценой среди всех заявок (даже если были равные значения у других участников).

Примеры типовых задач на собеседовании: как отвечать

• Веб‑сайт с каталогом и регистрацией — «что будете тестировать?»
  • Разбей ответ на уровни: UI/UX (формы, сообщения об ошибках, навигация), бизнес‑логика (регистрация, авторизация, восстановление пароля, фильтры и сортировки каталога, корзина/избранное), данные/БД (создание записей пользователя, консистентность заказов), интеграции (оплата, e‑mail/SMS), нефункциональные проверки (перфоманс, безопасность, кроссбраузерность).
  • Приведи несколько конкретных кейсов: «регистрация с уже существующим email», «фильтр по цене + сортировка по популярности», «переход по прямой ссылке на товар без авторизации» и т.п.
• «Протестируйте воркфлоу баг‑трекинговой системы»
  • Сначала перечисли основные статусы (New → In Progress → Fixed → Ready for QA → Closed / Reopened) и роли (репортёр, разработчик, тестировщик, менеджер).
  • Затем опиши проверки по переходам: допустимые/недопустимые статусы, обязательные поля на каждом шаге, права доступа (кто может менять статус, редактировать поля, переоткрывать баги), уведомления и триггеры (почта, webhooks).
• «Тестировать форму отправки письма в Outlook» — в теории уже есть отдельный подробный пример; на собеседовании называется структура: поля, валидация, отправка, ошибки, черновики, отображение у получателя.
• «Мобильный кубик» — перечисли классы проверок: диапазон 1–6, соответствие UI, повторные броски, жесты/кнопки, звук/вибро, поворот экрана, история (есть детальный пример выше в теории).
• Портал с видео и отметкой просмотра на 80%
  • Выдели сценарии: обычный просмотр (чистые 80%), паузы и перемотка, смена скорости, перезагрузка страницы, просмотр нескольких роликов.
  • Проверь, что отметка «просмотрено» и добавление в список зависят именно от процента времени, а не от факта запуска, и что нельзя «обмануть» систему (перемотать в конец, открыть в двух вкладках и т.п.).
• Родительский контроль с категориями G/PG/R/NC‑17/18+
  • Суть вопроса — показать, что ты умеешь считать минимальный набор тестов по эквивалентным классам: для каждой категории нужны кейсы «ограничение включено/выключено», «канал виден/спрятан/заблокирован», плюс хотя бы один кросс‑кейс (несколько категорий для одного профиля).
  • Можно ответить: «минимум по одному позитивному и одному негативному сценарию на категорию + пара общих кейсов на переключение профиля/возврат к разрешениям», не расписывая 40×5 каналов.
• Функи и очки «Big boss / Baby boss»
  • Ожидается, что ты соберёшь недостающие требования: что именно считается «взрослый/ребёнок», как система узнаёт время (пятница после 19:00), как долго держатся метаморфозы, что показывают очки в разных состояниях (обычный розовый, розовый «у доски», обычный серый, серый‑после‑пятницы).
  • На собеседовании проговори: «я бы уточнил у аналитика правила смены цвета, приоритет надписей, что делать в пограничных ситуациях (ровно 19:00, смена дня, отпуск) и только потом строил тест‑кейсы».
• Миграция новостей со старого сайта на новый
  • Разбей проверку на уровни: счёт записей (кол‑во новостей по разделам), целостность полей (заголовок, подзаголовок, текст, миниатюра, видео, галерея), корректность ссылок и медиа, соответствие разделов, проверка выборки/фильтров.
  • Обязательно упомяни выбор «эталонных» новостей (с разными комбинациями опциональных полей) и сравнение старой и новой версий по скриншотам/SQL/админке.
• «Из 5 попыток логина 4 неудачные, 1 успешная, логов нет»
  • Покажи, что будешь восстанавливать контекст: кто пользователь, с какого устройства/браузера, какие точные шаги делал, были ли капчи/ограничения по попыткам, менялся ли пароль.
  • Дальше — попытка воспроизведения на тестовом окружении с похожими учетками и внимательное наблюдение за фронтом и ответами сервера (DevTools, сниффер), плюс запрос логов/метрик у команды, если появятся.
• «API есть, интерфейса ещё нет»
  • Обычно ждут ответа в стиле: «буду использовать Postman/REST‑клиент, отправлю запрос нужного типа (GET/POST/PUT/DELETE) по спецификации, проверю коды ответа, тело ответа, заголовки, побочные эффекты (создание/изменение сущности в базе)».
  • Важно упомянуть позитивные и негативные сценарии: корректные и некорректные данные, отсутствие обязательных полей, неверные типы, ограничения по правам доступа.
• Задачи про бытовые предметы (чайник, лифт, карандаш, дверь и т.п.)
  • Правильный ответ — разложить на виды тестирования: функциональное (кипячение воды, двери открываются/закрываются), нефункциональное (надёжность, безопасность, эргономика, производительность), UX и граничные условия (минимальный/максимальный объём, экстремальные температуры и т.п.).
  • Можно использовать технику классов эквивалентности и граничных значений даже для предметов (объём, вес, нагрузка, возраст пользователя).
• UTM‑параметры и конструктор ссылок
  • На собеседовании важно проговорить: проверку обязательных/опциональных UTM‑параметров, кодирование спецсимволов, работу с уже существующими query‑параметрами в исходном URL, кроссбраузерность и адаптивность.
  • В модальном окне «Тестовые задания» есть отдельный разбор по этому сценарию с перечнем кейсов.

Тестовое задание №6: SQL‑задачи для начинающего QA/аналитика

• Часть 1. Профсоюзные взносы студентов (Oracle SQL):
  • Условие: каждый студент из таблицы Student(id, name, surname) должен ежемесячно платить 100 ₽, причём можно платить частями. В таблице Payment(student_id, amount, payment_date) хранятся все платежи, которые относим к месяцу по дате платежа. Нужно найти должников и сумму их долга за прошлый месяц (запрос должен работать при любой дате запуска).
  • Как думать:
    • Шаг 1: определить прошлый месяц относительно текущей даты: с первого числа прошлого месяца до первого числа текущего месяца (или до LAST_DAY прошлого месяца).
    • Шаг 2: посчитать сумму платежей каждого студента за этот интервал (агрегация SUM(amount) с GROUP BY student_id).
    • Шаг 3: «должниками» считаем всех, у кого paid < 100 или платежей нет вообще (поэтому нужен LEFT JOIN от всех студентов).
    • Шаг 4: долг = 100 - NVL(paid, 0), но показываем только случаи, где он > 0.
  • Готовый запрос (Oracle):

    SELECT
        s.id,
        s.name,
        s.surname,
        100 - NVL(p.paid, 0) AS debt
    FROM Student s
    LEFT JOIN (
        SELECT
            student_id,
            SUM(amount) AS paid
        FROM Payment
        WHERE payment_date >= TRUNC(ADD_MONTHS(SYSDATE, -1), 'MM')
          AND payment_date <  TRUNC(SYSDATE, 'MM')
        GROUP BY student_id
    ) p ON p.student_id = s.id
    WHERE NVL(p.paid, 0) < 100;

• Часть 2. Зарплаты и подчинённые (таблица db):
  • Структура: db(user_id INT, boss_id INT NULL, payment DOUBLE), где boss_id указывает на user_id руководителя.
  • Задача 1 — средняя зарплата руководителей: руководитель — тот, кто хотя бы у одного сотрудника указан как boss_id. Берём всех таких user_id и считаем среднее по их payment.
  • Запрос:

    SELECT AVG(payment) AS avg_boss_salary
    FROM db
    WHERE user_id IN (
        SELECT DISTINCT boss_id
        FROM db
        WHERE boss_id IS NOT NULL
    );

  • Задача 2 — среднее количество прямых подчинённых: сначала считаем, сколько сотрудников приходится на каждого boss_id, потом берём среднее по этим счетчикам.
  • Запрос:

    SELECT AVG(sub_cnt) AS avg_direct_subordinates
    FROM (
        SELECT boss_id, COUNT(*) AS sub_cnt
        FROM db
        WHERE boss_id IS NOT NULL
        GROUP BY boss_id
    );

  • Задача 3 — сотрудники с зарплатой выше, чем у их руководителей: нужно соединить сотрудника с его руководителем по boss_id = user_id и сравнить payment.
  • Запрос:

    SELECT e.user_id
    FROM db e
    JOIN db b ON e.boss_id = b.user_id
    WHERE e.payment > b.payment;

• Часть 3. Пользователи и их питомцы (коты породы Abyssinian):
  • Структура таблиц:
    • users(user_id, login, name, surname) — данные пользователя.
    • pets(user_id, pet_id, type, nickname, breed) — питомцы, где user_id — внешний ключ на владельца.
  • Задача: вернуть фамилию и имя всех владельцев котов породы Abyssinian, отсортировав по алфавиту.
  • Как думать:
    • Нужны только те записи из pets, где type соответствует «кот» (обычно cat) и breed = 'Abyssinian'.
    • Соединяем users и pets по user_id, берём surname и name, делаем DISTINCT на случай нескольких питомцев.
    • Сортируем ORDER BY surname, name.
  • Запрос:

    SELECT DISTINCT
        u.surname,
        u.name
    FROM users u
    JOIN pets p ON p.user_id = u.user_id
    WHERE LOWER(p.type) = 'cat'
      AND p.breed = 'Abyssinian'
    ORDER BY u.surname, u.name;