Основы тестирования ПО: Быстрый старт

Открывая сайты с вакансиями в IT, вы наверняка замечали, что должности специалистов, проверяющих программы на ошибки, называются по-разному: QA Engineer, QC Specialist, Software Tester (тестировщик). Часто работодатели и даже сами IT-специалисты используют эти термины как синонимы. Однако с профессиональной точки зрения между ними существует огромная разница.

Понимание этой разницы — это не просто академическое знание. Это фундамент, который формирует правильное инженерное мышление. На собеседовании на позицию Junior QA вопрос «В чем разница между QA, QC и тестированием?» звучит в 90% случаев. Умение четко, с примерами из бизнеса объяснить эти концепции сразу выделит вас среди сотен других кандидатов.

Более того, если ваша глобальная цель — внедрять искусственный интеллект (ИИ) в бизнес-процессы продаж и поставок, вам необходимо понимать, на каком именно уровне работает та или иная оптимизация. ИИ может автоматически нажимать кнопки (уровень тестирования), анализировать метрики релизов (уровень QC) или предсказывать сбои в логистике до написания кода (уровень QA).

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

Тестирование (Software Testing): Поиск ошибок здесь и сейчас

Тестирование программного обеспечения — это процесс исследования и испытания продукта с целью проверки его соответствия требованиям и поиска дефектов (багов).

Это самая базовая, тактическая и практическая часть работы. Тестировщик взаимодействует с уже готовым (или частично готовым) продуктом. Его главная задача — сломать систему, найти уязвимости, несоответствия и убедиться, что заявленные функции работают корректно.

Тестирование отвечает на вопрос: «Работает ли эта конкретная кнопка так, как ожидается?»

Как это выглядит на практике

Представьте, что компания разрабатывает CRM-систему (систему управления взаимоотношениями с клиентами) для отдела оптовых продаж. Разработчик только что закончил писать код для модуля «Корзина оптовика» и передал его на проверку.

Действия на уровне тестирования:

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

> Тестирование — это процесс оценки системы или её компонентов с целью определения, удовлетворяют ли они заданным требованиям, или выявления различий между ожидаемыми и фактическими результатами. > > Глоссарий ISTQB (International Software Testing Qualifications Board)

Контроль качества (Quality Control, QC): Оценка готового продукта

Контроль качества (QC) — это набор мероприятий, направленных на проверку готового продукта (или его части) на соответствие стандартам качества.

Если тестирование — это сам процесс поиска багов, то QC — это управление этим процессом и анализ его результатов. Специалист по контролю качества смотрит на продукт шире. Он не просто ищет ошибки, он оценивает, готов ли продукт к передаче пользователям.

QC отвечает на вопрос: «Соответствует ли этот релиз нашим стандартам качества и можем ли мы отдать его клиентам?»

Задачи на уровне QC

В задачи QC входит:

Пример из сферы поставок

Вернемся к нашей CRM-системе. Допустим, разработан новый модуль интеграции со складом.

Тестировщик проверил, что статусы заказов меняются. А вот специалист уровня QC берет отчет тестировщика и видит: найдено 15 минорных (незначительных) визуальных багов и 1 критический баг (система не списывает товар со склада при отгрузке). QC принимает решение: релиз блокируется, пока критический баг не будет исправлен. Визуальные баги можно оставить на следующий патч.

QC работает с продуктом реактивно — то есть реагирует на уже созданный объект, проверяя его качество.

Обеспечение качества (Quality Assurance, QA): Управление процессами

Обеспечение качества (QA) — это совокупность проактивных мероприятий, направленных на улучшение процесса разработки программного обеспечения, чтобы предотвратить появление дефектов.

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

QA отвечает на вопрос: «Как нам организовать работу, чтобы делать качественный продукт с первого раза?»

Задачи на уровне QA

Пример из бизнес-процессов

Представьте логистическую компанию.

!Взаимосвязь QA, QC и тестирования: матрешка качества

Сравнительная таблица: QA vs QC vs Тестирование

Чтобы окончательно структурировать понимание, сопоставим три понятия по ключевым критериям.

| Характеристика | Тестирование (Testing) | Контроль качества (QC) | Обеспечение качества (QA) | | :--- | :--- | :--- | :--- | | Фокус | Исходный код, интерфейс, конкретные функции | Готовый продукт или его инкремент | Процессы разработки и жизненный цикл ПО | | Подход | Реактивный (найти баг в том, что есть) | Реактивный (проверить продукт перед релизом) | Проактивный (предотвратить появление бага) | | Главная цель | Обнаружить дефекты | Убедиться, что продукт соответствует требованиям | Улучшить процессы, чтобы дефектов не было | | Что делают? | Пишут тест-кейсы, кликают, проверяют базы данных, заводят баги | Анализируют метрики, проводят ревью, принимают решение о релизе | Анализируют требования, внедряют стандарты, проводят аудиты | | Вопрос | Работает ли это? | Готово ли это к выпуску? | Как нам делать это лучше? |

Реальность рынка труда: почему все называются QA?

Изучив теорию, вы можете задаться вопросом: почему тогда большинство вакансий для новичков называются Junior QA Engineer, если по факту новичок будет заниматься только тестированием?

Исторически в IT-индустрии произошла подмена понятий. Компании начали называть тестировщиков QA-инженерами, чтобы подчеркнуть важность их роли и повысить престиж профессии.

В реальности распределение задач на разных грейдах выглядит примерно так:

Несмотря на то, что на старте вы будете заниматься преимущественно тестированием, работодатели ищут кандидатов с QA-мышлением.

QA-мышление означает, что найдя ошибку в логике расчета скидки для оптового клиента, вы не просто заведете баг-репорт. Вы зададите вопрос: «А почему этот баг вообще появился? Может быть, у нас неполные требования? Давайте добавим в шаблон технического задания обязательный пункт с формулой расчета скидки, чтобы разработчики больше не ошибались». Именно такой подход делает из обычного «кликальщика» ценного инженера.

Взгляд в будущее: как ИИ трансформирует QA, QC и тестирование

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

ИИ на уровне тестирования: Нейросети (например, на базе архитектуры Transformer, такие как ChatGPT или специализированные модели) могут автоматически генерировать сотни тест-кейсов на основе текстового описания задачи. Инструменты автоматизации с элементами ИИ умеют самостоятельно находить изменившиеся элементы интерфейса (кнопки, которые переехали в другое место) и «чинить» сломанные автотесты без участия человека (функция Self-healing).

ИИ на уровне QC: Алгоритмы машинного обучения анализируют огромные массивы данных о прошлых релизах. Если ИИ видит, что в модуле «Управление складом» исторически находили больше всего критических уязвимостей, он автоматически пометит этот модуль как зону высокого риска в новом релизе и порекомендует QC-менеджеру выделить на его проверку в три раза больше времени.

ИИ на уровне QA: На стратегическом уровне ИИ выступает как аналитик процессов. Он может анализировать коммуникацию команды в таск-трекерах (например, Jira) и предсказывать сбои. Например, ИИ может заметить: «В задачах, связанных с интеграцией платежных шлюзов, требования менялись в среднем 4 раза за спринт. Это приводит к росту дефектов на 40%. Рекомендация для процесса: замораживать требования по платежам за неделю до начала разработки».

Понимание разницы между простым поиском багов (тестированием) и выстраиванием надежных процессов (QA) — это ваш первый шаг к тому, чтобы стать не просто тестировщиком, а инженером, который способен улучшать бизнес-процессы целых организаций.

В предыдущей статье мы разобрали структуру идеального тест-кейса и научились описывать шаги так, чтобы их понял любой член команды. Однако перед каждым тестировщиком неизбежно встает главный вопрос: какие именно данные вводить в эти шаги?

Представьте, что вы тестируете поле ввода возраста для регистрации на B2B-портале оптовых закупок. Пользователь может ввести любую цифру от 1 до 150. Означает ли это, что вам нужно написать 150 тест-кейсов, проверяя каждое число по очереди? А если поле принимает еще и буквы, спецсимволы, отрицательные значения и пробелы? Количество возможных комбинаций стремится к бесконечности.

Здесь вступает в силу второй базовый принцип тестирования: исчерпывающее тестирование невозможно. Мы физически не можем проверить все существующие варианты ввода. Нам нужен математически обоснованный подход, который позволит сократить количество проверок до минимума, сохранив при этом максимальную вероятность нахождения бага. Этот подход называется тест-дизайном (Test Design).

Суть классов эквивалентности

Самая популярная и фундаментальная техника тест-дизайна — эквивалентное разбиение или классы эквивалентности (Equivalence Partitioning).

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

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

Бытовая аналогия: Сортировка яблок

Представьте автоматическую линию на ферме, которая сортирует яблоки для продажи.

Если вы хотите проверить, правильно ли работает конвейер для супермаркетов, вам не нужно кидать в него яблоки диаметром 5.1 см, 5.2 см, 5.3 см и так далее. Достаточно взять одно любое яблоко размером 7 см. Если конвейер отправил его в правильную коробку, значит, механизм для этого диапазона работает. Вы протестировали весь класс эквивалентности одним действием.

!Схема разбиения на классы эквивалентности: числовая ось разделена на допустимые и недопустимые диапазоны

Валидные и невалидные классы

В тестировании данные всегда делятся на две большие категории, которые формируют позитивные и негативные сценарии.

Профессиональный QA-инженер всегда начинает с позитивного тестирования (проверки валидных классов), чтобы убедиться, что основной функционал вообще работает. Только после этого он переходит к негативному тестированию (проверке невалидных классов).

Практический пример: Логистическая система

Давайте применим технику на реальном примере из сферы логистики.

Бизнес-требование: Система расчета стоимости доставки принимает вес посылки в килограммах.

Математически наши валидные диапазоны выглядят так: (где — вес посылки, тариф 300 руб.) (где — вес посылки, тариф 1000 руб.)

Давайте выделим классы эквивалентности и подберем для них тестовые значения.

| Тип класса | Описание диапазона | Выбранное тестовое значение | Ожидаемый результат | | :--- | :--- | :--- | :--- | | Валидный 1 | От 0.1 до 5 кг | 3 | Расчет успешен: 300 руб. | | Валидный 2 | От 5.1 до 20 кг | 12 | Расчет успешен: 1000 руб. | | Невалидный 1 | Меньше или равно 0 | -4 | Ошибка: "Вес должен быть больше 0" | | Невалидный 2 | Больше 20 кг | 25 | Ошибка: "Превышен максимальный вес" | | Невалидный 3 | Нечисловые символы | "пять" | Ошибка: "Введите числовое значение" | | Невалидный 4 | Пустое поле | ничего не введено | Ошибка: "Поле не может быть пустым" |

Обратите внимание на невалидные классы 3 и 4. Начинающие тестировщики часто забывают о них, концентрируясь только на цифрах. Однако пользователи регулярно нажимают кнопку «Отправить» с пустыми полями или случайно вставляют текст из буфера обмена. Система должна уметь это обрабатывать.

!Интерактивный симулятор классов эквивалентности: введите вес посылки, чтобы увидеть, как система относит его к определенному классу и назначает тариф

Типичные ошибки при использовании техники

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

Ошибка 1: Избыточное тестирование внутри одного класса

Предположим, вы тестируете скидку для заказов от 10 000 до 50 000 рублей. Вы пишете три тест-кейса со значениями: 15 000, 25 000 и 40 000.

Почему это плохо: Вы потратили время на написание и прохождение трех тестов, но с точки зрения покрытия логики вы не узнали ничего нового. Все три числа лежат в одном классе эквивалентности. Если работает 15 000, с вероятностью 99.9% сработает и 40 000. Выберите одно значение (например, 25 000) и двигайтесь дальше.

Ошибка 2: Игнорирование скрытых классов (типов данных)

Разработчики используют разные типы данных в базах данных и коде. Например, если поле принимает целые числа, оно может быть ограничено типом Integer.

Если бизнес-требование гласит: «Введите количество товара от 1 до 100», валидный класс очевиден. Но что будет, если ввести 3 000 000 000? Это число может превысить лимит переменной в коде, что вызовет критический сбой (переполнение буфера). Поэтому в невалидные классы всегда стоит добавлять экстремально большие числа, даже если они кажутся абсурдными для бизнес-логики.

Ошибка 3: Смешивание независимых условий

Представьте форму авторизации: Логин и Пароль. Нельзя проверять невалидный логин и невалидный пароль одновременно в одном тест-кейсе. Если система выдаст ошибку «Доступ запрещен», вы не будете знать, что именно сработало: проверка логина или проверка пароля.

Правило: в одном негативном тест-кейсе должно быть только одно невалидное значение. Все остальные данные должны быть валидными.

Анализ граничных значений: неразлучный спутник

Классы эквивалентности редко используются в вакууме. Они всегда идут в паре с техникой Анализа граничных значений (Boundary Value Analysis).

Почему? Потому что разработчики — люди, а людям свойственно ошибаться в знаках неравенства. В коде условие «до 5 кг включительно» должно выглядеть как . Но программист может случайно написать (строго меньше).

Если вы выберете тестовое значение из середины класса (например, 3 кг), тест пройдет успешно в обоих случаях. Баг останется незамеченным. Ошибка проявит себя только тогда, когда пользователь попытается отправить посылку весом ровно 5 кг.

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

Внедрение ИИ для генерации классов эквивалентности

Ручное выделение классов эквивалентности для сложных систем (например, расчет кредитного скоринга с десятками параметров) занимает часы. Это рутинная аналитическая работа, с которой современные LLM (Large Language Models) справляются за секунды.

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

Как правильно составить промпт для ИИ

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

Пример эффективного промпта: > «Ты — Senior QA Engineer. Проанализируй следующее бизнес-требование для системы оптовых продаж: 'Пользователь может применить промокод на скидку 15%, если сумма его корзины составляет от 50 000 до 200 000 рублей включительно. Промокод действует только для аккаунтов со статусом VIP'. > > Твоя задача: примени технику классов эквивалентности. Выдели все валидные и невалидные классы для суммы корзины и статуса аккаунта. > Ответ оформи в виде Markdown-таблицы со столбцами: Параметр, Тип класса (Валидный/Невалидный), Описание условия, Тестовое значение, Ожидаемый результат. Учитывай негативные сценарии с типами данных».

ИИ мгновенно сгенерирует таблицу, где учтет не только суммы 40 000 и 60 000, но и отрицательные суммы, пустые корзины, а также обычные (не VIP) аккаунты. Вам останется лишь перенести эти данные в систему управления тест-кейсами.

Более того, ИИ отлично находит логические дыры в самих требованиях. Если аналитик забыл указать, что происходит с заказами свыше 200 000 рублей (скидка фиксируется, отменяется или увеличивается?), нейросеть укажет на это слепое пятно еще до начала разработки.

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

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

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

В программном обеспечении действует тот же закон. Абсолютное большинство дефектов логики скрывается не внутри классов эквивалентности, а на стыках между ними. Чтобы находить эти дефекты, тестировщики используют технику анализа граничных значений (Boundary Value Analysis, BVA).

Анатомия ошибки: почему ломаются границы

Чтобы понять, почему баги «любят» границы, нужно посмотреть на систему глазами разработчика. Программисты описывают бизнес-логику с помощью условных операторов.

Допустим, бизнес-аналитик написал требование для B2B-портала: «Скидка 10% предоставляется при заказе от 500 штук товара включительно».

В идеальном мире код разработчика должен выглядеть так: Если , применить скидку (где — количество товара).

Но разработчик — живой человек. Он мог отвлечься, неправильно прочитать техническое задание или просто опечататься. В результате в коде появляется: Если , применить скидку.

Разница всего в одном символе (строго больше вместо больше или равно). Это классическая ошибка на единицу (Off-by-one error).

Если вы, используя только классы эквивалентности, протестируете систему значением 800 (середина валидного класса), скидка применится. Тест пройден. Если вы проверите значение 200 (середина невалидного класса), скидка не применится. Тест тоже пройден.

Вы с чистой совестью отправляете продукт в релиз. А на следующий день оптовый клиент заказывает ровно 500 единиц товара, не получает обещанную скидку и уходит к конкурентам. Баг проскользнул именно там, где меняется логика системы.

Базовые принципы анализа граничных значений

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

!Схема метода анализа граничных значений: визуализация валидного класса и его границ

Понятие шага (Precision)

Прежде чем искать соседние значения, тестировщик обязан определить шаг — минимально возможное изменение данных для конкретного поля. Шаг напрямую зависит от типа данных и бизнес-контекста.

Игнорирование шага — самая частая ошибка начинающих QA-инженеров. Если граница веса равна 5 кг, а вы проверяете 4 кг и 6 кг, вы оставляете огромную «слепую зону» от 4.1 до 4.9 кг.

Два подхода к тестированию границ

В мировой практике обеспечения качества существуют два стандарта работы с границами. Выбор зависит от критичности системы и выделенного на тестирование времени.

Двухзначный анализ (2-value BVA)

Этот подход требует проверки двух значений для каждой границы: самой границы и ближайшего значения за ее пределами (в соседнем классе).

Если условие звучит как (где — вес в кг с шагом 0.1), мы проверяем:

Этот метод быстрее, он отсекает большинство логических ошибок и применяется в стандартных веб-приложениях, e-commerce и CRM-системах.

Трехзначный анализ (3-value BVA)

Более параноидальный подход. Для каждой границы проверяется три значения: сама граница, значение чуть меньше и значение чуть больше.

Для того же условия мы проверим:

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

Практический пример: Логистическая платформа

Давайте применим трехзначный анализ на реальном примере из логистики.

Бизнес-требование: Курьерская служба принимает к отправке малогабаритные грузы. Длина коробки должна быть от 10 см до 50 см включительно. Точность измерения — до 1 сантиметра (шаг = 1).

Математическая модель: (где — длина коробки).

У нас есть две границы: нижняя (10) и верхняя (50). Распишем тестовые значения по методу 3-value BVA.

| Граница | Тестовое значение | Ожидаемый результат | Обоснование | | :--- | :--- | :--- | :--- | | Нижняя | 9 | Ошибка | Сразу за пределами допустимого минимума | | Нижняя | 10 | Успех | Точное совпадение с минимальной границей | | Нижняя | 11 | Успех | Сразу внутри допустимого диапазона | | Верхняя | 49 | Успех | Сразу внутри допустимого диапазона | | Верхняя | 50 | Успех | Точное совпадение с максимальной границей | | Верхняя | 51 | Ошибка | Сразу за пределами допустимого максимума |

Итого: вместо того чтобы проверять все 41 возможное значение длины, мы сделали всего 6 точечных проверок, которые покрывают 99% возможных рисков в этом функционале.

Неочевидные границы: текст, даты и массивы

Анализ граничных значений применяется не только к числам. Эта техника универсальна для любых данных, имеющих измеримые пределы.

Текстовые поля

Если вы тестируете поле «Название компании» при регистрации контрагента, и в требованиях указано ограничение от 2 до 100 символов, вашими границами будут не сами буквы, а длина строки (шаг = 1 символ).

Тестовые значения для нижней границы:

Тестовые значения для верхней границы:

> Важный нюанс: для текстовых полей всегда нужно проверять абсолютный ноль — пустую строку (0 символов). Это отдельный невалидный класс эквивалентности, который часто вызывает падение базы данных, если поле обязательно для заполнения.

Даты и время

В системах продаж часто встречаются акции с ограниченным сроком действия. Требование: «Промокод действует до 31 декабря 23:59:59».

Здесь шагом является минимальная единица времени, которую учитывает система (в данном случае — 1 секунда).

Тестовые значения:

Типичные ошибки при поиске границ

Даже зная теорию, на практике легко допустить ошибки, которые снизят эффективность тестирования.

Ошибка 1: Тестирование «на глазок» вместо точного шага. Если граница равна 1000, тестировщик проверяет 900 и 1100. Это не анализ граничных значений, это проверка случайных чисел из разных классов. Баг может скрываться на значении 1001, и вы его пропустите.

Ошибка 2: Игнорирование технических ограничений. Бизнес-аналитик может написать: «Сумма перевода не ограничена». С точки зрения бизнеса верхней границы нет. Но с точки зрения архитектуры ПО она есть всегда. Переменная в коде имеет максимальный размер. Например, стандартный тип Integer в базах данных вмещает число 2 147 483 647. Если пользователь введет число больше, система может выдать критическую ошибку (Crash). Профессиональный QA всегда ищет невидимые технические границы.

Ошибка 3: Дублирование проверок. Если у вас есть два смежных диапазона (например, скидка 5% от 10 до 50 товаров, и скидка 10% от 51 до 100 товаров), граница 50/51 является общей. Не нужно писать отдельные тест-кейсы для верхней границы первого класса и нижней границы второго. Они проверяются одними и теми же значениями: 50, 51.

Внедрение ИИ для анализа границ

Выделение граничных значений — процесс алгоритмичный и строгий. Это делает его идеальным кандидатом для делегирования искусственному интеллекту. Современные LLM (Large Language Models) способны за секунды проанализировать многостраничное техническое задание и извлечь из него все скрытые границы.

Более того, ИИ отлично справляется с определением правильного шага на основе контекста. Если вы дадите нейросети текст про вес золота, она выберет шаг 0.001 грамма. Если про количество вагонов в поезде — шаг 1.

Пример промпта для генерации граничных значений

Чтобы получить качественный результат от ИИ, используйте структурированный промпт:

> «Ты — Senior QA Engineer. Проанализируй следующее бизнес-требование для логистической ERP-системы: 'Стоимость страховки груза составляет 1% от объявленной ценности, если ценность от 10 000 до 500 000 рублей включительно. Грузы дешевле 10 000 руб. не страхуются. Грузы дороже 500 000 руб. требуют индивидуального расчета'. > > Твоя задача: примени техники классов эквивалентности и трехзначного анализа граничных значений (3-value BVA). > 1. Определи правильный шаг для денежных значений. > 2. Выдели все границы. > 3. Составь таблицу тестовых значений с колонками: Граница, Тестовое значение, Ожидаемый результат, Тип (Валидное/Невалидное). > Учти технические ограничения и нулевые значения».

Нейросеть не только выдаст точные значения (9 999.99, 10 000.00, 10 000.01), но и напомнит вам проверить отрицательные суммы и экстремально большие числа, которые бизнес-аналитик забыл описать в требованиях.

Анализ граничных значений в связке с классами эквивалентности формирует непробиваемый фундамент функционального тестирования. Овладев этими двумя техниками, вы сможете сократить количество тест-кейсов в десятки раз, одновременно повысив вероятность нахождения самых критичных дефектов бизнес-логики.

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

Но в реальных бизнес-системах поля редко существуют изолированно. Чаще всего результат работы программы зависит от сложной комбинации множества факторов.

Представьте логистическую систему: если клиент VIP, а вес груза больше 100 кг, но доставка нужна в выходной день — какую скидку применить? Классы эквивалентности здесь не помогут, потому что каждое значение по отдельности валидно. Ошибка возникнет именно в логике взаимодействия этих условий.

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

Таблицы принятия решений: укрощение комбинаторного взрыва

Таблица принятия решений (Decision Table) — это техника тест-дизайна, которая используется для тестирования систем со сложной логикой, где различные комбинации входных условий приводят к различным действиям системы.

Главная ценность этой техники в том, что она переводит запутанные текстовые требования бизнес-аналитиков в строгую математическую матрицу. Это исключает двоякое толкование и гарантирует, что ни одна комбинация не будет пропущена.

Анатомия таблицы

Любая таблица принятия решений состоит из четырех ключевых квадрантов:

!Структура таблицы принятия решений

Математика комбинаций

Если все наши условия бинарные (отвечают на вопрос Да/Нет), количество возможных правил вычисляется по формуле:

Где — количество правил (тест-кейсов), а — количество условий.

Если у нас 3 условия, таблица будет содержать правил. Если условий 5, правил будет уже 32. Это наглядно показывает, почему тестирование «наугад» обречено на провал: человек физически не способен удержать в голове 32 уникальные комбинации и обязательно пропустит критический сценарий.

Практический пример: B2B-портал продаж

Давайте составим таблицу для реального бизнес-требования из сферы оптовых продаж.

Требование: «Клиент получает базовую скидку 10%, если сумма заказа превышает 500 000 рублей. Если клиент имеет статус 'Партнер', он получает бесплатную доставку независимо от суммы. Если заказ больше 500 000 рублей и клиент 'Партнер', он получает и скидку 10%, и бесплатную доставку, а также за ним закрепляется персональный менеджер».

Шаг 1. Выделяем условия ():

Шаг 2. Выделяем действия:

Шаг 3. Строим таблицу ( правила):

| Элементы | Правило 1 | Правило 2 | Правило 3 | Правило 4 | | :--- | :--- | :--- | :--- | :--- | | Условие 1: Заказ > 500к | Да | Да | Нет | Нет | | Условие 2: Статус 'Партнер' | Да | Нет | Да | Нет | | Действие 1: Скидка 10% | Выполнить | Выполнить | Игнорировать | Игнорировать | | Действие 2: Беспл. доставка | Выполнить | Игнорировать | Выполнить | Игнорировать | | Действие 3: Перс. менеджер | Выполнить | Игнорировать | Игнорировать | Игнорировать |

Имея такую таблицу, Junior QA может за 5 минут написать 4 идеальных тест-кейса, которые покрывают 100% бизнес-логики данного функционала.

Оптимизация: символ «Не имеет значения»

В реальных проектах таблица на 6 условий создаст 64 правила. Проверять их все дорого и долго. К счастью, таблицы можно оптимизировать (схлопывать).

Часто встречаются ситуации, когда при определенном значении одного условия, остальные условия уже не влияют на результат. В тестировании это называется «Не имеет значения» (Don't care condition) и обозначается прочерком «—».

Пример: Если при оформлении кредита условие «Возраст заемщика > 18 лет» равно «Нет», система выдаст отказ. Нам не имеет значения, какая у него зарплата и кредитная история. Вместо того чтобы писать 4 разных правила для несовершеннолетнего с разной зарплатой, мы пишем одно правило, ставя прочерки в остальных условиях. Это радикально сокращает количество тест-кейсов без потери качества.

Диаграммы переходов состояний: тестирование с памятью

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

Но большинство современных систем имеют память. Статус заказа в логистике, жизненный цикл заявки в CRM, процесс оплаты в интернет-магазине — всё это объекты, которые меняются во времени. Вы не можете нажать кнопку «Оформить возврат», если заказ еще не перешел в статус «Доставлен».

Для тестирования таких систем применяется Диаграмма переходов состояний (State Transition Diagram).

Базовые элементы диаграммы

Эта техника рассматривает систему как конечный автомат (Finite State Machine), который состоит из четырех элементов:

!Интерактивная модель жизненного цикла заказа

Практический пример: Жизненный цикл заказа

Рассмотрим упрощенную логистическую систему. Заказ может находиться в следующих состояниях: Создан, Оплачен, Отправлен, Доставлен, Отменен.

Бизнес-логика диктует жесткие правила:

Как писать тест-кейсы по диаграмме

Глядя на диаграмму, тестировщик должен выбрать уровень покрытия (Coverage). Существует два основных подхода:

1. Покрытие всех состояний (All States Coverage) Самый слабый уровень. Задача — составить тест-кейс так, чтобы объект хотя бы один раз побывал в каждом кружочке (состоянии). Путь: Создан Оплачен Отправлен Доставлен. Проблема: Мы не проверили состояние «Отменен» и упустили множество переходов.

2. Покрытие всех переходов (0-switch coverage / All Transitions) Золотой стандарт тестирования. Задача — пройти по каждой стрелке на диаграмме хотя бы один раз. Для нашего примера потребуется минимум два тест-кейса:

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

Внедрение ИИ в техники тест-дизайна

Таблицы решений и диаграммы состояний — это строгие логические структуры. Именно поэтому искусственный интеллект справляется с ними блестяще. Внедрение LLM (Large Language Models) в эти процессы экономит часы рутинной работы.

ИИ для таблиц принятия решений

Бизнес-требования часто пишутся сплошным текстом, в котором легко запутаться. Вы можете скормить этот текст нейросети с правильным промптом:

> «Ты — Senior QA. Проанализируй следующее требование для системы расчета скидок: [текст]. > 1. Выдели все независимые условия и возможные действия. > 2. Построй полную таблицу принятия решений в формате Markdown. > 3. Оптимизируй таблицу, используя символ '-' (Не имеет значения) для логически невозможных или избыточных комбинаций. > 4. Напиши тест-кейсы на основе оптимизированной таблицы».

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

ИИ для диаграмм состояний

При тестировании сложных ERP-систем жизненный цикл сущности может состоять из 30-40 состояний. Рисовать это вручную мучительно.

Вы можете попросить ИИ сгенерировать код диаграммы в формате Mermaid.js на основе текстового описания. Более того, ИИ отлично генерирует тестовые пути:

> «На основе предоставленного списка состояний и переходов заказа, сгенерируй минимальный набор тест-кейсов, который обеспечит 100% покрытие всех переходов (All Transitions Coverage). Укажи шаги для каждого тест-кейса и ожидаемый результат».

В продвинутых сценариях (к которым вы придете на этапе анализа данных) ИИ может анализировать реальные логи серверов, самостоятельно строить диаграмму того, как пользователи на самом деле переводят систему из состояния в состояние, и сравнивать это с идеальной бизнес-моделью, находя скрытые аномалии.

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

Жизненный цикл дефекта: статусы и переходы

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

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

Чтобы таких ситуаций не возникало, в инженерии качества используется строгий процесс управления дефектами. Баг — это не просто ошибка, это сущность, которая рождается, живет, меняет состояния и, в идеале, умирает. Этот процесс называется Жизненным циклом дефекта (Defect Life Cycle или Bug Life Cycle).

Что такое жизненный цикл дефекта

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

По сути, это классическая диаграмма переходов состояний (которую мы изучали ранее), примененная не к бизнес-объекту (например, заказу), а к самому процессу разработки. Управление этим циклом обычно происходит в баг-трекинговых системах (Bug Tracking Systems), таких как Jira, YouTrack, Redmine или Azure DevOps.

> Хорошо настроенный жизненный цикл дефекта превращает хаос разработки в предсказуемый конвейер, где ни одна ошибка не может исчезнуть без следа. > > Рекс Блэк, эксперт по тестированию ПО и автор стандартов ISTQB

Идеальный путь: от рождения до закрытия

Рассмотрим базовый сценарий (Happy Path), при котором команда работает слаженно, а баг исправляется с первой попытки.

1. New (Новый)

На этом этапе баг еще ничей. Это просто сигнал о проблеме.

2. Assigned (Назначен)

3. Open / In Progress (Открыт / В работе)

4. Fixed (Исправлен)

Важное правило: Статус Fixed означает лишь то, что разработчик считает проблему решенной. Это еще не гарантия качества.

5. Retest / Ready for QA (Повторное тестирование)

6. Verified (Подтвержден)

7. Closed (Закрыт)

!Интерактивная модель жизненного цикла дефекта

Альтернативные пути: когда что-то идет не так

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

Reopened (Переоткрыт)

Rejected / Not a Bug (Отклонен / Не баг)

В этом случае баг закрывается без исправлений. Чтобы избегать таких ситуаций, тестировщик должен тщательно изучать документацию перед заведением дефекта.

Duplicate (Дубликат)

Deferred (Отложен)

Cannot Reproduce (Не воспроизводится)

Причины могут быть разными:

В такой ситуации ваша задача — собрать больше данных (логи, видео экрана, консоль браузера) и доказать, что проблема существует, переведя баг обратно в Reopened.

Метрики качества: Плотность дефектов

Управление жизненным циклом дефектов позволяет не только чинить код, но и собирать статистику для бизнеса. Одной из ключевых метрик является Плотность дефектов (Defect Density).

Она вычисляется по формуле:

Где:

Зачем это нужно? Если в прошлом месяце на 100 часов разработки приходилось 5 багов, а в этом месяце — 25, это сигнал для QA-менеджера. Возможно, команда взяла слишком сложную архитектуру, или новые разработчики не понимают бизнес-логику. Метрика позволяет принимать управленческие решения на основе данных, а не интуиции.

Внедрение ИИ в управление дефектами

Процесс сортировки (Triage) и маршрутизации багов отнимает огромное количество времени у менеджеров и лидов. В современных корпорациях, занимающихся логистикой и продажами, этот процесс всё чаще передают искусственному интеллекту.

Как ИИ трансформирует жизненный цикл дефекта:

Понимание жизненного цикла дефекта — это базовый навык, без которого невозможно пройти собеседование на Junior QA. Вы должны четко понимать разницу между Fixed и Closed, а также уметь аргументированно защищать свои баги, если они получают статус Cannot Reproduce.

В следующей статье мы перейдем к практической автоматизации и посмотрим, как можно использовать Python для того, чтобы находить баги быстрее и надежнее.

Баг-репорты: структура, атрибуты и правила оформления

В предыдущей статье мы разобрали жизненный цикл дефекта — путь, который проходит найденная ошибка от статуса New до Closed. Однако этот путь не начнется, если тестировщик не сможет грамотно задокументировать свою находку.

Представьте, что вы работаете на складе логистической компании. Вы подходите к инженеру и говорите: «Там конвейер сломался». Инженер спросит: «Какой именно? В каком цеху? Что значит 'сломался' — не едет лента или не работает сканер штрих-кодов? Что ты нажал перед этим?». Пока вы будете выяснять детали, фуры с товаром будут простаивать, а компания — терять деньги.

В разработке программного обеспечения происходит то же самое. Баг-репорт (Bug Report, отчет о дефекте) — это технический документ, который описывает несоответствие между ожидаемым и фактическим поведением системы, а также содержит всю необходимую информацию для локализации и исправления этой ошибки.

Качество ваших баг-репортов — это ваша визитная карточка. Разработчики судят о квалификации QA-инженера именно по тому, насколько понятно, лаконично и полно оформлены задачи в баг-трекере (например, в Jira).

Фундаментальная формула дефекта

С технической точки зрения, баг существует только тогда, когда нарушается базовое математическое условие тестирования:

Где:

Если вы не можете четко сформулировать (опираясь на документацию, здравый смысл или стандарты), вы не можете завести баг-репорт. Без ожидаемого результата это не баг, а вопрос к аналитику.

Анатомия идеального баг-репорта

Стандартный отчет об ошибке состоит из строго определенного набора полей. Рассмотрим их на примере тестирования B2B-портала оптовых продаж.

1. Заголовок (Summary / Title)

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

Золотое правило написания заголовков — принцип «Что? Где? Когда?» (или «Что? Где? При каких условиях?»).

Заголовок должен быть кратким (обычно до 100 символов), но исчерпывающим.

2. Окружение (Environment)

Программное обеспечение работает по-разному на разных устройствах и серверах. Ошибка, которая воспроизводится на вашем iPhone, может отсутствовать на Android-устройстве разработчика.

В блоке окружения необходимо указать:

3. Предусловия (Preconditions)

Это состояние, в котором должна находиться система перед началом выполнения шагов. Предусловия экономят время, избавляя от необходимости писать очевидные действия.

Вместо того чтобы писать в шагах: «1. Открыть сайт. 2. Ввести логин. 3. Ввести пароль. 4. Нажать Войти. 5. Перейти в профиль», вы выносите это в предусловия.

Пример предусловия: Пользователь авторизован в системе под ролью «Оптовый покупатель». В корзину добавлен 1 товар.

4. Шаги воспроизведения (Steps to Reproduce)

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

Пример шагов:

Правило: шагов не должно быть слишком много (в идеале 3–7). Если их больше 10, скорее всего, вы забыли вынести часть действий в Предусловия.

5. Фактический и Ожидаемый результаты (AR и ER)

Здесь мы описываем ту самую формулу .

> Лучший способ описать ожидаемый результат — процитировать конкретный пункт из спецификации требований. > > Кем Канер, автор книги «Тестирование программного обеспечения»

6. Вложения (Attachments)

Словам тестировщика не верят — верят доказательствам. К каждому баг-репорту должны быть прикреплены артефакты:

!Структура идеального баг-репорта: от заголовка до доказательств.

Серьезность и Приоритет: в чем разница?

Это самый частый вопрос на собеседованиях для Junior QA. Тестировщик должен четко разделять техническое влияние бага на систему и его влияние на бизнес.

Серьезность (Severity)

Показывает степень технического разрушения системы. Отвечает на вопрос: «Насколько сильно сломалась программа?». Устанавливается тестировщиком.

Градации Severity:

Приоритет (Priority)

Показывает важность бага для бизнеса. Отвечает на вопрос: «Как быстро мы должны это починить?». Устанавливается менеджером проекта (PM) или владельцем продукта (PO), но тестировщик может предлагать свое значение.

Градации Priority:

Нестандартные комбинации

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

Высокий приоритет (High Priority) + Низкая серьезность (Low Severity): Технически система работает идеально, но бизнес несет репутационные потери. Пример из продаж: На главной странице сайта Apple в день презентации нового iPhone в слове «Инновации» допущена опечатка. Технически это Trivial (ничего не сломано), но для бизнеса это High Priority — исправить нужно за 5 минут.

Низкий приоритет (Low Priority) + Высокая серьезность (High Severity): Технически это катастрофа, но она затрагивает 0.001% пользователей. Пример из логистики: Приложение курьера намертво зависает (Blocker), если курьер использует операционную систему Windows Phone 8 (которой пользуется 1 человек из 10 000). Бизнес поставит Low Priority, так как дешевле купить этому курьеру новый телефон на Android, чем тратить неделю работы разработчика на починку старого кода.

Золотые правила оформления баг-репортов

Внедрение ИИ в работу с баг-репортами

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

Современные LLM-модели (Large Language Models) кардинально меняют рутину QA-инженера:

Умение четко, структурированно и без эмоций описывать проблемы — это базовый навык, который отличает профессионального инженера по качеству от обычного пользователя. В следующей статье мы перейдем к автоматизации и посмотрим, как можно научить Python выполнять рутинные проверки за вас.

Системы трекинга задач: работа с дефектами в Jira

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

Система отслеживания задач (Issue Tracking System, ITS) — это программное обеспечение, которое позволяет командам фиксировать ошибки, планировать новые функции и контролировать процесс разработки ПО на каждом этапе жизненного цикла (SDLC).

Безоговорочным лидером на рынке корпоративного ПО является Jira от компании Atlassian. Понимание архитектуры Jira и умение быстро находить в ней нужную информацию — это базовый технический навык, который ожидается от любого Junior QA-инженера в первый же день работы.

Базовая архитектура Jira: Проекты и Задачи

Jira построена на строгой иерархии данных. Чтобы не потеряться в тысячах записей, необходимо понимать, как они структурированы.

Проекты (Projects)

Проект в Jira — это глобальная папка или контейнер, объединяющий все задачи, относящиеся к определенному продукту, команде или направлению.

Каждый проект имеет свой уникальный текстовый ключ (Project Key), обычно состоящий из 2–4 заглавных букв. Этот ключ становится префиксом для всех задач внутри проекта. Например, если проект называется «Логистический портал», его ключ может быть LOG. Первая созданная задача получит идентификатор LOG-1, сотая — LOG-100.

Задачи (Issues)

Задача (Issue, часто в профессиональном сленге называемая «тикет») — это базовая единица информации в Jira. Это карточка, которая описывает конкретный объем работы.

Задачи делятся на типы (Issue Types), чтобы команда могла отличать разработку новых функций от исправления старых ошибок. Стандартная иерархия типов задач выглядит так:

Перенос баг-репорта в карточку Jira

Когда вы находите дефект, вы нажимаете кнопку Create (Создать) в Jira. Перед вами открывается форма с множеством полей. Рассмотрим, как теоретическая структура баг-репорта ложится на реальные поля системы.

* Summary (Тема): Сюда вписывается заголовок по правилу «Что? Где? Когда?». Это поле обязательно для заполнения. * Description (Описание): Это большое текстовое поле, поддерживающее форматирование. Сюда вы переносите Предусловия, Шаги воспроизведения, Фактический результат (AR) и Ожидаемый результат (ER). Environment (Окружение): В некоторых проектах для версий ОС, браузеров и тестовых стендов выделено отдельное поле. Если его нет, эта информация добавляется в начало поля Description*. * Attachment (Вложения): Сюда загружаются скриншоты, видеозаписи экрана и файлы логов.

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

* Assignee (Исполнитель): Человек, который в данный момент должен выполнить работу по задаче. Когда вы заводите баг, вы можете назначить его на конкретного разработчика (если знаете, кто писал код) или на Team Lead, который распределит задачу позже. Reporter (Автор): Тот, кто создал задачу. Это поле заполняется автоматически вашим именем. Если разработчику будут непонятны шаги воспроизведения, он придет с вопросами именно к Reporter*. Priority (Приоритет): Влияние бага на бизнес (от Highest до Lowest*). Как мы обсуждали ранее, QA может выставить предварительный приоритет, но финальное слово остается за менеджером продукта. * Labels (Метки/Теги): Ключевые слова для быстрой фильтрации. Например, метки frontend, cart_page, regression_test помогут быстро найти все баги интерфейса корзины, найденные во время регрессионного тестирования. * Components (Компоненты): Более жесткая, чем метки, структура разделения проекта на модули (например, «База данных», «API», «Пользовательский интерфейс»). За каждым компонентом может быть закреплен свой разработчик, и при выборе компонента Jira автоматически назначит баг на него.

!Схема движения карточки дефекта по Kanban-доске в Jira.

Жизненный цикл дефекта на доске Jira

В статье о жизненном цикле дефекта (DLC) мы рассматривали статусы как абстрактные этапы. В Jira эти статусы визуализируются на Доске (Board).

Доска — это визуальное представление рабочего процесса (Workflow). Она состоит из колонок, каждая из которых соответствует определенному статусу. Карточка бага перемещается слева направо по мере выполнения работы.

Типичный рабочий процесс для бага выглядит следующим образом:

Разница между Status и Resolution

Это один из самых неочевидных моментов для новичков, который часто вызывает путаницу в отчетах.

Status (Статус) показывает, на каком этапе процесса находится задача прямо сейчас (например, Closed).

Resolution (Резолюция) объясняет, почему задача перешла в финальный статус.

Представьте, что вы завели баг: «Не работает кнопка отмены заказа». Через час вы видите, что статус задачи изменился на Closed. Значит ли это, что баг починили? Не обязательно. Нужно смотреть на поле Resolution:

Если Resolution = Done (или Fixed*), значит, разработчик действительно исправил код. * Если Resolution = Duplicate, значит, кто-то из ваших коллег уже завел точно такой же баг раньше, и вашу карточку закрыли как дубликат. Если Resolution = Won't Do (или Declined*), значит, бизнес решил, что это не баг, а фича, или исправление стоит слишком дорого, и ошибку оставили в системе намеренно. Если Resolution = Cannot Reproduce, значит, разработчик не смог повторить вашу ошибку по описанным шагам. В этом случае вам нужно переоткрыть баг (Reopen*) и добавить больше деталей или логов.

Поиск задач: Введение в JQL

Когда в проекте 50 задач, найти нужную можно глазами на доске. Когда их 50 000, базовой строки поиска становится недостаточно. Для точной выборки данных в Jira встроен собственный язык запросов — JQL (Jira Query Language).

Знание JQL отличает уверенного пользователя Jira от новичка. Синтаксис JQL очень похож на SQL (язык запросов к базам данных, который мы будем изучать в следующих модулях).

Каждый запрос в JQL состоит из трех базовых элементов: Поле + Оператор + Значение

Например: project = LOG (найти все задачи в проекте LOG).

Для объединения нескольких условий используются логические операторы AND (И) и OR (ИЛИ).

Практические примеры JQL для QA-инженера

Сценарий 1: Найти все баги, которые нужно протестировать прямо сейчас. Вам нужно найти задачи типа «Баг» в вашем проекте, которые разработчики перевели в статус «В тестировании» и назначили на вас.

project = LOG AND issuetype = Bug AND status = "In Testing" AND assignee = currentUser()

Примечание: currentUser() — это динамическая функция, которая подставляет имя того пользователя, который выполняет запрос. Это позволяет сохранить фильтр и поделиться им с коллегами — у каждого он будет показывать его собственные задачи.

Сценарий 2: Поиск критических дефектов перед релизом. Завтра релиз. Вам нужно убедиться, что в системе не осталось открытых багов с высоким приоритетом.

project = LOG AND issuetype = Bug AND priority in (High, Highest) AND status != Closed

Примечание: Оператор in позволяет указать список значений в скобках. Оператор != означает «не равно» (статус не является закрытым).

Сценарий 3: Поиск задач без исполнителя. Вы Team Lead и хотите найти «потерянные» баги, которыми никто не занимается.

project = LOG AND issuetype = Bug AND assignee is EMPTY

Примечание: Для проверки на пустоту используется оператор is EMPTY, а не знак равенства.

Сортировка результатов Чтобы отсортировать найденные задачи, в конец запроса добавляется ключевое слово ORDER BY.

project = LOG AND issuetype = Bug ORDER BY created DESC

Этот запрос выведет все баги проекта, отсортированные по дате создания по убыванию (DESC — descending), то есть самые свежие баги будут наверху списка.

Дашборды и метрики качества

JQL нужен не только для поиска конкретных задач, но и для построения Дашбордов (Dashboards) — информационных панелей с графиками и диаграммами.

QA Lead использует дашборды для мониторинга «здоровья» проекта. На основе сохраненных JQL-фильтров строятся следующие метрики:

Внедрение ИИ в системы трекинга задач

Работа с баг-трекером исторически требовала много рутины: заполнение полей, поиск дубликатов, назначение задач. Сегодня искусственный интеллект (в частности, интеграция LLM в платформы вроде Atlassian Intelligence) радикально меняет этот процесс.

Если ваша цель — внедрять ИИ в бизнес-процессы, Jira — отличный полигон для первых экспериментов.

1. Генерация JQL из естественного языка

Написание сложных JQL-запросов требует знания точных названий полей и статусов. Современные ИИ-ассистенты в Jira позволяют использовать промпты на естественном языке.

Вы пишете в строку поиска: «Покажи мне все критические баги в проекте логистики, которые создал Иван за последнюю неделю и которые до сих пор не закрыты».

ИИ мгновенно переводит это в синтаксис: project = LOG AND issuetype = Bug AND priority = Critical AND reporter = "Ivan Ivanov" AND created >= -7d AND status != Closed.

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

2. Умная маршрутизация (Smart Triage)

В крупных компаниях (например, в техподдержке B2B-порталов) ежедневно создаются сотни тикетов. Раньше специальный человек (диспетчер) читал каждый тикет и решал, какому отделу его передать.

Сейчас ИИ анализирует текст поля Description. Если он видит слова «ошибка 500», «база данных», «таймаут», он автоматически ставит метку backend и назначает задачу на команду серверов. Если видит «кнопка съехала», «не тот цвет» — ставит метку frontend и отправляет дизайнерам и верстальщикам. Это экономит часы ручного труда ежедневно.

3. Предиктивная аналитика сроков исправления

ИИ анализирует исторические данные проекта: как долго разработчик «А» обычно чинит баги, связанные с API, и как долго разработчик «Б» чинит интерфейс.

Когда вы заводите новый баг, ИИ может автоматически рассчитать Estimated Time (ожидаемое время выполнения) и предупредить менеджера: «С вероятностью 85% этот дефект не будет исправлен до конца текущего спринта, так как разработчик перегружен». Это позволяет бизнесу управлять рисками до того, как они станут проблемами.

4. Автоматическое создание Summary (Резюме)

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

ИИ-ассистент по нажатию одной кнопки анализирует всю историю комментариев и выдает краткое резюме: «Суть проблемы: конфликт версий библиотек. Принятое решение: откатить версию API до 1.4. Блокер: ждем подтверждения от отдела безопасности».

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

Основы веб-тестирования: клиент-серверная архитектура

В предыдущих материалах мы научились находить дефекты, описывать их по строгим правилам и управлять их жизненным циклом в системах вроде Jira. Однако до сих пор мы относились к тестируемому приложению как к «черному ящику». Мы нажимали кнопки на экране и смотрели на результат.

Чтобы стать востребованным QA-инженером и научиться локализовать сложные дефекты, необходимо заглянуть под капот. Большинство современных корпоративных систем — от порталов B2B-продаж до логистических трекеров — работают через интернет. Понимание того, как данные передаются по сети, позволяет тестировщику точно определить: ошибка произошла на устройстве пользователя, потерялась по пути или система сломалась глубоко в недрах серверов компании.

Концепция клиент-серверной архитектуры

Фундаментом современного интернета является клиент-серверная архитектура. Это вычислительная модель, в которой задачи распределены между поставщиками ресурсов (серверами) и заказчиками этих ресурсов (клиентами).

Кто такой Клиент?

Клиент (Client) — это программное обеспечение или устройство, которое запрашивает информацию или услугу.

С точки зрения пользователя, клиент — это то, с чем он взаимодействует напрямую. Это может быть браузер Google Chrome на вашем ноутбуке, мобильное приложение курьерской службы на смартфоне или даже умный терминал на складе, который сканирует штрихкоды. Клиент отвечает за отображение интерфейса (кнопки, формы, таблицы) и сбор данных от пользователя.

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

Кто такой Сервер?

Сервер (Server) — это мощный компьютер (или кластер компьютеров), который хранит данные, обрабатывает бизнес-логику и отвечает на запросы клиентов.

Сервер работает круглосуточно. Он находится в специализированном дата-центре и не имеет привычного монитора или мышки. Когда клиент нажимает кнопку «Оформить заказ», именно сервер проверяет, есть ли товар на складе, списывает деньги с карты и формирует накладную для логистического отдела.

Ресторанная аналогия

Чтобы навсегда запомнить, как взаимодействуют эти компоненты, представим поход в ресторан:

!Инфографика — клиент-серверная архитектура в виде метафоры ресторана

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

Язык общения: HTTP и структура URL

Клиент и сервер могут быть написаны на разных языках программирования и работать на разных операционных системах. Чтобы они понимали друг друга, им нужен универсальный язык общения. В вебе таким языком является протокол HTTP (HyperText Transfer Protocol) и его защищенная версия HTTPS (где 'S' означает Secure — данные шифруются).

Взаимодействие всегда строится по принципу: Запрос (Request) от клиента Ответ (Response) от сервера.

Анатомия URL-адреса

Чтобы отправить запрос, клиент должен знать, куда именно стучаться. Для этого используется URL (Uniform Resource Locator) — единый указатель ресурса. QA-инженер должен уметь читать URL как открытую книгу.

Рассмотрим пример ссылки из системы логистики: https://logistics-portal.com/api/v1/shipments?status=delivered&region=eu

Разберем ее на компоненты: * https:// — Протокол. Указывает, что мы используем защищенное соединение. * logistics-portal.com — Домен (или хост). Это имя сервера в интернете. Система доменных имен (DNS) переведет это понятное человеку имя в IP-адрес (например, 192.168.1.15), чтобы найти конкретный компьютер в сети. /api/v1/shipments — Путь (Path*). Указывает на конкретный ресурс на сервере. В данном случае мы обращаемся к первой версии API для работы с отправлениями (shipments). ?status=delivered&region=eu — Параметры запроса (Query Parameters*). Начинаются со знака вопроса ?, а между собой разделяются амперсандом &. Это фильтры. Мы просим сервер вернуть не все отправления в мире, а только те, которые доставлены (status=delivered) в Европе (region=eu).

HTTP-методы: Глаголы интернета

Когда клиент обращается по URL, он должен указать свое намерение: что именно он хочет сделать с ресурсом. Для этого используются HTTP-методы.

* GET (Получить): Самый частый метод. Клиент просит сервер просто отдать данные, ничего не меняя в базе. Пример: Открытие страницы товара, просмотр статуса посылки. * POST (Создать): Клиент отправляет новые данные на сервер для создания нового объекта. Пример: Регистрация нового пользователя, оформление нового заказа, добавление товара в корзину. * PUT / PATCH (Обновить): Клиент просит изменить существующие данные. PUT обычно заменяет объект целиком, а PATCH обновляет только часть. Пример: Изменение адреса доставки в существующем заказе. * DELETE (Удалить): Клиент просит сервер уничтожить ресурс. Пример: Отмена заказа, удаление профиля.

> Важное правило тестирования: метод GET должен быть безопасным и идемпотентным. Это значит, что сколько бы раз вы ни обновляли страницу (отправляли GET-запрос), состояние системы на сервере меняться не должно. Если при обновлении страницы у пользователя списываются деньги — это критический баг архитектуры.

HTTP Статус-коды: Как отвечает сервер

Получив запрос, сервер обрабатывает его и возвращает ответ. Ответ всегда содержит Статус-код (Status Code) — трехзначное число, которое сообщает клиенту о результате операции.

Знание статус-кодов — это суперсила QA-инженера. Они делятся на 5 классов (по первой цифре):

| Класс | Значение | Описание для QA | Примеры | | :--- | :--- | :--- | :--- | | 1xx | Информационные | Сервер принял запрос и продолжает обработку. В ручном тестировании встречаются редко. | 100 Continue | | 2xx | Успех | Запрос успешно обработан. Ожидаемое поведение для позитивных тест-кейсов. | 200 OK (успешный GET), 201 Created (успешный POST) | | 3xx | Перенаправление | Ресурс перемещен. Клиенту нужно сделать дополнительный запрос по новому адресу. | 301 Moved Permanently | | 4xx | Ошибка клиента | Виноват клиент (или пользователь). Отправлены неверные данные, нет прав доступа или ресурс не существует. | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found | | 5xx | Ошибка сервера | Виноват сервер. Запрос был правильным, но сервер сломался при его обработке (упала база данных, ошибка в коде). | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable |

Разница между 4xx и 5xx на практике

Представьте, что вы тестируете форму создания накладной в B2B-портале. Вы вводите вес груза -5 кг и нажимаете «Отправить».

Сценарий А: Система показывает красную ошибку, а сервер возвращает код 400 Bad Request (Неверный запрос). Это правильное поведение системы (если мы тестируем негативный сценарий). Сервер посмотрел на отрицательный вес, понял, что это противоречит законам физики, и отказался обрабатывать запрос, сказав клиенту: «Ты прислал мне чушь, исправь».

Сценарий Б: Система зависает, а затем выдает белый экран. Сервер возвращает код 500 Internal Server Error. Это критический баг. Сервер попытался умножить -5 кг на тариф, его математическая логика сломалась, и программа аварийно завершила работу. Сервер никогда не должен отвечать пятисотыми ошибками. Любые некорректные действия пользователя должны перехватываться и превращаться в понятные ошибки 4xx.

Инструменты разработчика (DevTools): Рентген для QA

Как тестировщику увидеть эти запросы и статус-коды, если на экране отображается только красивый интерфейс?

Для этого в каждом современном браузере встроены Инструменты разработчика (Developer Tools или DevTools). Они открываются клавишей F12 (или Ctrl+Shift+I / Cmd+Option+I).

Самая важная вкладка для QA-инженера — это Network (Сеть).

Если вы откроете вкладку Network и нажмете кнопку на сайте, вы увидите таблицу со всеми запросами, которые браузер отправил на сервер. Кликнув на конкретный запрос, вы сможете изучить его детали:

Локализация дефектов: Frontend или Backend?

Умение пользоваться вкладкой Network позволяет QA-инженеру правильно маршрутизировать баг-репорты в Jira. В современной разработке команды часто разделены: одни программисты пишут интерфейс (Frontend), другие — серверную логику (Backend).

Допустим, вы нажимаете кнопку «Скачать отчет», но ничего не происходит. Кто виноват?

Такая локализация экономит часы рабочего времени команды. Вместо того чтобы перекидывать задачу друг на друга, разработчики сразу видят, на чьей стороне проблема.

Внедрение ИИ в анализ клиент-серверного взаимодействия

Понимание сетевой архитектуры — это первый шаг к автоматизации и внедрению искусственного интеллекта в процессы обеспечения качества. Если ваша цель — оптимизировать работу B2B-компаний, ИИ может стать мощным союзником на уровне сети.

1. Интеллектуальный анализ сетевых логов

В крупных логистических системах за одну секунду происходят тысячи клиент-серверных взаимодействий. Когда происходит сбой, тестировщику приходится вручную просматривать огромные файлы логов (журналов событий сервера), чтобы найти причину ошибки 500.

Современные LLM (большие языковые модели) можно интегрировать в системы мониторинга. ИИ анализирует миллионы строк логов, находит аномалии и выдает QA-инженеру готовое резюме: «Сбой произошел из-за того, что в 14:05 клиент из региона EU отправил POST-запрос с неверным форматом даты, что вызвало переполнение памяти в модуле базы данных».

2. Умные Mock-серверы (Заглушки)

Часто бывает так, что Frontend-команда уже сделала интерфейс, а Backend-команда еще не написала серверную логику. Как тестировать интерфейс, если ему некуда отправлять запросы?

Для этого создаются Mock-серверы — программы-имитаторы, которые притворяются настоящим сервером и возвращают заранее заготовленные ответы. Раньше QA-инженерам приходилось писать эти ответы вручную. Сегодня ИИ может проанализировать документацию к системе и автоматически сгенерировать реалистичный Mock-сервер, который будет отвечать на запросы так же, как это делал бы настоящий бэкенд, включая имитацию сетевых задержек и случайных ошибок 5xx для проверки устойчивости клиента.

3. Предиктивная генерация тестовых данных (Payloads)

При тестировании API (программного интерфейса сервера) тестировщику нужно отправлять на сервер различные комбинации данных (Payloads), чтобы проверить классы эквивалентности и граничные значения.

ИИ может анализировать структуру базы данных и автоматически генерировать сотни сложных JSON-запросов, комбинируя валидные и невалидные данные. Например, для системы продаж ИИ сгенерирует запросы с отрицательными ценами, несуществующими валютами и экстремально длинными названиями товаров, чтобы попытаться «сломать» сервер и выявить скрытые уязвимости.

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

Использование панелей разработчика DevTools в тестировании

В предыдущем материале мы разобрали клиент-серверную архитектуру и выяснили, что браузер (клиент) общается с сервером с помощью HTTP-запросов. Мы узнали о статус-кодах и методах, но пока это оставалось теорией. Чтобы увидеть этот скрытый обмен данными своими глазами, тестировщику нужен специальный инструмент — «рентгеновский аппарат» для веб-приложений.

Таким инструментом являются Инструменты разработчика (Developer Tools или сокращенно DevTools). Это набор утилит для веб-разработки и отладки, встроенный прямо в браузер (Google Chrome, Mozilla Firefox, Safari, Edge). Для QA-инженера DevTools — это основное рабочее пространство, позволяющее локализовать дефекты, проверять безопасность, тестировать верстку и подготавливать базу для написания автотестов.

Чтобы открыть DevTools в большинстве браузеров (например, в Google Chrome), достаточно нажать клавишу F12, комбинацию Ctrl+Shift+I (Windows/Linux) или Cmd+Option+I (macOS). Также можно кликнуть правой кнопкой мыши по любому элементу на странице и выбрать пункт «Посмотреть код» (Inspect).

DevTools состоит из множества вкладок, но для успешного старта в ручном и функциональном тестировании критически важно освоить пять основных: Elements, Console, Network, Application и Device Toolbar.

Вкладка Elements: Анатомия интерфейса

Вкладка Elements (Элементы) показывает внутреннюю структуру веб-страницы. Когда сервер присылает ответ на запрос браузера, он передает код, который браузер превращает в визуальный интерфейс. Этот код организован в виде DOM-дерева (Document Object Model — объектная модель документа).

DOM-дерево состоит из HTML-тегов, вложенных друг в друга. Справа от HTML-кода (или снизу, в зависимости от компоновки) находится панель Styles, где отображаются CSS-правила, определяющие внешний вид элементов (цвет, размер, отступы).

Зачем Elements нужен тестировщику?

> Изменения, которые вы вносите во вкладке Elements, происходят только локально в вашем браузере. Как только вы обновите страницу (F5), браузер заново скачает оригинальный код с сервера, и все ваши правки исчезнут. Вы не можете «взломать» сайт или изменить реальную цену товара в базе данных через Elements.

Вкладка Console: Дневник ошибок браузера

Вкладка Console (Консоль) — это журнал событий, куда браузер и само веб-приложение записывают служебную информацию. Современные сайты — это не просто статичные картинки, это сложные программы, написанные на языке JavaScript (JS), которые выполняются прямо в вашем браузере.

Когда JavaScript-код сталкивается с проблемой, он «падает» (прекращает работу) и выводит сообщение об ошибке в Консоль.

Типы сообщений в консоли

* Info / Log (Белые/Серые): Обычные информационные сообщения от разработчиков. Например: «Приложение успешно загружено». * Warnings (Желтые): Предупреждения. Код работает, но что-то идет не по плану. Часто это предупреждения об использовании устаревших функций. Для QA это повод обратить внимание, но не всегда баг. * Errors (Красные): Критические ошибки JavaScript. Это всегда баг.

Локализация «тихих» дефектов

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

Неопытный тестировщик напишет баг-репорт: «Не работает выбор курьера». Разработчик потратит часы, пытаясь понять, где именно сломалась логика.

Опытный QA-инженер перед созданием репорта откроет DevTools Console, повторит действие и увидит там красный текст: TypeError: Cannot read properties of undefined (reading 'vehicleType').

Приложив скриншот этой ошибки к баг-репорту, вы сэкономите разработчику массу времени. Ошибка четко говорит: интерфейс попытался прочитать тип автомобиля курьера, но эти данные не пришли (они undefined), из-за чего скрипт аварийно остановился.

Вкладка Network: Пульс клиент-серверного общения

Вкладка Network (Сеть) — это самый мощный и часто используемый инструмент QA-инженера. Она логирует абсолютно все сетевые запросы, которые браузер отправляет на сервер, и ответы, которые приходят обратно.

Именно здесь теория HTTP-методов (GET, POST) и статус-кодов (200, 400, 500) превращается в практику.

!Схема взаимодействия браузера, панелей DevTools и сервера

Как читать вкладку Network

Когда вы открываете страницу, во вкладке Network появляются десятки строк. Это браузер скачивает HTML, картинки, шрифты и скрипты. Чтобы не утонуть в этом потоке, тестировщики используют фильтр Fetch/XHR. Он оставляет только те запросы, которые передают бизнес-данные (API-запросы), скрывая картинки и стили.

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

Практика: Чья это ошибка — Frontend или Backend?

Умение работать с Network позволяет точно маршрутизировать баги между командами. Разберем на примере B2B-портала.

Сценарий: Вы заполняете форму регистрации новой компании-поставщика, вводите ИНН, название, нажимаете кнопку «Зарегистрировать». Кнопка нажимается, крутится индикатор загрузки, но регистрация не происходит.

Действия QA-инженера:

Вариант А (Баг Фронтенда): В таблице Network не появляется новых запросов. Вывод: Браузер (Frontend) даже не попытался отправить данные на сервер. Возможно, сломалась валидация формы на стороне клиента. Баг назначается Frontend-разработчику.

Вариант Б (Баг Бэкенда): Запрос появился. В секции Headers статус-код 500 Internal Server Error. В секции Payload данные отправлены верно (ИНН и название присутствуют). Вывод: Клиент отработал идеально, он собрал данные и отправил их. Сервер принял данные, но при попытке сохранить их в базу данных произошел сбой. Баг назначается Backend-разработчику.

Вариант В (Баг Фронтенда, скрытый под маской Бэкенда): Запрос появился. Статус-код 400 Bad Request (Неверный запрос). Вы открываете вкладку Payload и видите, что в поле inn отправлено пустое значение "", хотя в интерфейсе вы ввели цифры. Вывод: Сервер ответил 400-й ошибкой абсолютно справедливо — он отказался регистрировать компанию без ИНН. Виноват Frontend, который по какой-то причине не считал введенные вами цифры из поля ввода и отправил на сервер пустоту.

Вкладка Application: Память браузера

Браузер умеет запоминать информацию, чтобы вам не приходилось вводить логин и пароль при каждом обновлении страницы. Эта память управляется через вкладку Application (Приложение).

Здесь нас интересуют три основных хранилища:

Практическое применение в QA

* Тестирование авторизации: Когда вы входите в систему, сервер присылает специальный ключ (токен), который сохраняется в Cookies или Local Storage. Если вы вручную удалите этот токен во вкладке Application и обновите страницу, система должна «выкинуть» вас на экран логина. Если вы остались авторизованы — это серьезная уязвимость безопасности. * Очистка состояния: Часто баги воспроизводятся только на «чистом» профиле. Вместо того чтобы постоянно чистить всю историю браузера, тестировщик может зайти в Application Storage и нажать кнопку Clear site data. Это мгновенно сбросит состояние конкретного сайта до заводских настроек.

Device Toolbar: Эмуляция мобильных устройств

В левом верхнем углу DevTools (рядом с кнопкой выбора элементов) находится иконка смартфона и планшета — Toggle device toolbar.

Эта функция позволяет проверить, как веб-приложение выглядит и работает на экранах разных размеров. Вы можете выбрать конкретную модель (например, iPhone 14 Pro) или вручную менять ширину и высоту экрана (Responsive mode).

Эмуляция плохой сети (Throttling)

В логистике и доставке приложения часто используются в условиях нестабильного интернета (курьер зашел в лифт или спустился в подвал). Как протестировать поведение системы в таких условиях, сидя в офисе с гигабитным Wi-Fi?

В DevTools (на панели Network или в настройках Device Toolbar) есть выпадающий список Throttling (Дросселирование). По умолчанию там стоит No throttling. Вы можете переключить его на Slow 3G или Offline.

Пример из практики: Вы переводите сеть в режим Offline и нажимаете кнопку «Доставить заказ» в веб-приложении курьера. Качественное приложение должно сохранить этот статус локально (в Local Storage) и показать сообщение: «Нет сети. Данные будут отправлены позже». Плохое приложение зависнет или выдаст непонятную ошибку.

Внедрение ИИ в работу с DevTools

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

Умение свободно ориентироваться в панелях Elements, Console, Network и Application — это водораздел между начинающим тестировщиком, который просто «кликает по кнопкам», и техническим специалистом, который понимает архитектуру приложения. Этот навык не только гарантирует успешное прохождение технических собеседований, но и является абсолютно необходимым фундаментом для следующего этапа нашего курса — автоматизации тестирования на Python.

Особенности ручного тестирования мобильных приложений

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

Мобильное тестирование переносит нас в совершенно иную реальность. Смартфон находится в кармане курьера, спускающегося в подвал, или в руках менеджера по продажам, который оформляет сделку на ходу, переключаясь между Wi-Fi и мобильной связью. Эта динамичная среда требует от QA-инженера совершенно новых подходов и проверок.

Архитектура мобильных приложений

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

Нативные приложения (Native apps) разрабатываются специально для конкретной операционной системы (ОС) с использованием ее «родных» языков программирования. Для iOS это Swift или Objective-C, для Android — Kotlin или Java. Они работают максимально быстро, имеют полный доступ к аппаратному обеспечению устройства (камера, GPS, биометрия) и могут работать офлайн.

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

Веб-приложения (Web apps) — это мобильные версии сайтов, адаптированные под экраны смартфонов. Они открываются через мобильный браузер (Safari, Chrome) и не требуют установки из магазинов приложений (App Store или Google Play). Их главный минус — ограниченный доступ к функциям телефона и зависимость от интернета.

Гибридные приложения (Hybrid apps / Cross-platform) пишутся на едином языке (например, Dart во фреймворке Flutter или JavaScript в React Native), а затем компилируются под обе платформы. Это экономит бюджет бизнеса, так как одна команда разработчиков создает продукт сразу для iOS и Android.

Пример: B2B-портал для оптовых закупок. Клиентам нужен удобный каталог и корзина. Гибридного подхода здесь более чем достаточно, так как приложению не требуются сложные вычисления или глубокая интеграция с «железом» телефона.

| Характеристика | Нативные | Гибридные | Веб-приложения | | :--- | :--- | :--- | :--- | | Производительность | Высокая | Средняя | Зависит от браузера | | Доступ к железу | Полный | Частичный | Минимальный | | Стоимость разработки| Высокая (нужно 2 команды) | Средняя (одна команда) | Низкая | | Обновление | Через магазин приложений | Через магазин приложений | Мгновенно на сервере |

Фрагментация устройств и экранов

Главная боль мобильного тестирования — фрагментация (Fragmentation). Если в вебе мы тестируем сайт в 3-4 популярных браузерах, то в мобильном мире существуют тысячи комбинаций устройств, версий ОС, оболочек от производителей (особенно на Android) и разрешений экранов.

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

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

!Инфографика: Ключевые факторы мобильного тестирования

Специфика мобильного контекста

Тестирование бизнес-логики (классы эквивалентности, граничные значения) в мобилках работает так же, как в вебе. Но к этому добавляется проверка поведения приложения в естественной среде обитания смартфона.

1. Тестирование прерываний (Interruption Testing)

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

* Входящие звонки (сотовые и мессенджеры). * СМС и Push-уведомления. * Сигналы будильника и таймера. * Предупреждения о низком заряде батареи (20%, 10%).

Пример из продаж: Пользователь вводит данные банковской карты для оплаты крупной партии товара. В этот момент ему звонит начальник. Пользователь сворачивает приложение, отвечает на звонок (разговор длится 5 минут), а затем возвращается к оплате. Плохое приложение сбросит введенные данные или, что хуже, отправит платеж дважды из-за потери сессии. Качественное приложение сохранит состояние экрана (State) и позволит завершить покупку.

2. Зависимость от сети (Network Testing)

В отличие от офисного ПК, смартфон постоянно переключается между вышками связи и роутерами. Тестировщик обязан проверять переходы:

* Wi-Fi 4G/5G 3G EDGE (очень медленный интернет). * Полная потеря сети (режим «В самолете» или «Мертвая зона»). * Подключение к сети с авторизацией (публичный Wi-Fi в метро).

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

3. Жесты и управление (Gestures)

В мобильных приложениях нет курсора мыши и состояния Hover (наведение). Управление происходит через сенсорный экран. QA-инженер должен проверять не только обычные нажатия (Tap), но и специфические жесты:

Swipe* (смахивание) — удаление товара из корзины. Scroll* (прокрутка) — загрузка длинного списка накладных. Pinch / Zoom* (щипок) — масштабирование карты маршрута. Long press* (долгое нажатие) — вызов контекстного меню.

4. Аппаратные датчики

Мобильные приложения активно используют «железо». Тестировщик проверяет, как система запрашивает разрешения (Permissions) на доступ к камере, микрофону, геолокации или FaceID/TouchID. Важный негативный сценарий — что произойдет, если пользователь нажмет «Запретить доступ»? Приложение не должно падать, оно должно корректно объяснить, почему функция недоступна.

Среды тестирования: Эмуляторы, Симуляторы и Реальные устройства

Обеспечить QA-отдел всеми существующими моделями смартфонов невозможно. Поэтому в работе используются программные заменители.

Эмулятор (Emulator) — это программа, которая полностью имитирует как программную (ОС), так и аппаратную (процессор, память) часть устройства. Самый популярный пример — Android Emulator в составе Android Studio. Эмулятор переводит инструкции мобильного процессора (ARM) в инструкции процессора вашего компьютера (x86), из-за чего работает медленно, но максимально точно воспроизводит поведение реального устройства.

Симулятор (Simulator) — имитирует только программную среду. Он не пытается копировать «железо», а просто создает слой ОС поверх архитектуры вашего компьютера. Яркий пример — iOS Simulator в Xcode. Он работает очень быстро, но не подходит для точного тестирования производительности или расхода батареи.

> Симуляторы и эмуляторы отлично подходят для функционального тестирования на ранних этапах. Но финальное тестирование перед релизом (особенно проверка камеры, Bluetooth, GPS и плавности анимаций) всегда должно проводиться на реальных устройствах.

Установка, обновление и удаление

Жизненный цикл мобильного приложения включает этапы, которых почти нет в вебе.

Тестирование установки (Installation testing) проверяет загрузку приложения из стора. Но гораздо важнее тестирование обновлений (Update testing).

Пользователи редко удаляют старую версию перед установкой новой. Они просто нажимают «Обновить». QA-инженер должен убедиться, что при накатывании версии 2.0 поверх версии 1.0:

Внедрение ИИ в мобильное тестирование

Мобильное тестирование исторически сложнее поддается автоматизации, чем веб, из-за зоопарка устройств и нестабильности UI-элементов. Однако искусственный интеллект радикально меняет этот процесс, что особенно важно для выстраивания современных QA-процессов в бизнесе.

Визуальное регрессионное тестирование. Вместо того чтобы вручную проверять, не съехала ли кнопка на 50 разных экранах, ИИ-модели (компьютерное зрение) делают скриншоты приложения на множестве устройств и попиксельно сравнивают их с эталонным дизайном. ИИ понимает контекст: он проигнорирует изменившееся время на часах смартфона, но поднимет тревогу, если текст налез на иконку корзины.

Умные боты-исследователи (AI Monkey Testing). Классическое «Monkey testing» подразумевает хаотичные нажатия по экрану для поиска крашей. Современные AI-агенты (на базе обучения с подкреплением) ведут себя как реальные пользователи. Они анализируют DOM-дерево мобильного экрана, понимают, где находится форма авторизации, вводят осмысленные тестовые данные, свайпают списки и пытаются сломать бизнес-логику, генерируя сложные цепочки шагов, до которых человек мог бы не додуматься.

Предиктивная аналитика девайсов. ИИ анализирует логи с продакшена (какие устройства используют реальные клиенты логистической компании, где чаще всего происходят сбои) и формирует для QA-отдела оптимальную матрицу устройств. Система может подсказать: «Вам не нужно тестировать на 100 моделях Android. Достаточно проверить на этих 4 моделях, так как они покрывают 85% аппаратных конфигураций вашей аудитории».

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

Оценка трудозатрат и приоритизация задач в тестировании

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

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

Природа оценки: Конус неопределенности

Оценка трудозатрат (Estimation) — это процесс прогнозирования времени, усилий и ресурсов, необходимых для выполнения задачи. Главная проблема любой оценки заключается в том, что в начале работы мы знаем о задаче меньше всего.

В проектном менеджменте это явление называется Конусом неопределенности (Cone of Uncertainty). Суть концепции в том, что на старте проекта (когда есть только общая бизнес-идея) погрешность оценки может составлять от 25% до 400%. По мере уточнения требований, написания тест-плана и начала тестирования неопределенность сужается, и оценка становится точнее.

Представьте, что логистическая компания решает внедрить ИИ-маршрутизатор для курьеров. На первой встрече менеджер спрашивает: «Сколько займет тестирование?». Если QA-инженер сразу ответит «Две недели», он совершит грубую ошибку. На этом этапе неизвестно, сколько платформ нужно поддерживать, как работает API и какие данные использует ИИ. Правильный ответ на старте: «От одного до четырех месяцев, точная оценка будет дана после анализа спецификаций».

Методы оценки трудозатрат

Чтобы снизить влияние Конуса неопределенности, в IT-индустрии применяются стандартизированные техники оценки. Рассмотрим три наиболее популярные из них.

1. Декомпозиция (Work Breakdown Structure)

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

Допустим, вам нужно протестировать новый модуль «Корзина оптового покупателя» в B2B-портале продаж. Оценить модуль целиком сложно. Применяем декомпозицию: * Проверка добавления товара в корзину (2 часа) * Проверка расчета скидки от объема партии (3 часа) * Проверка интеграции с платежным шлюзом (4 часа) * Проверка сохранения корзины при обрыве сессии (2 часа)

Суммируя мелкие оценки, мы получаем реалистичные 11 часов работы. К этой сумме обычно добавляют буфер времени (около 20%) на непредвиденные риски — настройку среды или падение тестового сервера.

2. Оценка по трем точкам (PERT)

Метод PERT (Program Evaluation and Review Technique) пришел из аэрокосмической отрасли. Он учитывает, что в IT всегда что-то идет не по плану. Вместо одной цифры тестировщик дает три оценки:

Для расчета финального ожидаемого времени () используется формула средневзвешенного значения:

Где — ожидаемое время, — оптимистичная оценка, — наиболее вероятная оценка, — пессимистичная оценка. Умножение на 4 придает наибольший вес самому реалистичному сценарию.

Пример из продаж: нужно протестировать выгрузку отчета по сделкам за год. Оптимистично это займет 2 часа. Пессимистично (если база данных будет зависать) — 14 часов. Вероятнее всего — 5 часов. Считаем: часов.

!Интерактивный калькулятор PERT

3. Planning Poker и Story Points

В гибких методологиях (Agile/Scrum) часто отказываются от оценки в часах. Люди склонны ошибаться в абсолютных величинах (часах), но хорошо справляются с относительными (сравнением).

Для этого используются Story Points (очки историй) — абстрактная метрика сложности задачи. Задачи оцениваются по числам из последовательности Фибоначчи: 1, 2, 3, 5, 8, 13, 21. Чем больше число, тем выше сложность, объем работы и неопределенность.

Процесс оценки проходит в формате игры Planning Poker:

Этот метод исключает давление авторитета (когда Junior боится спорить с Senior) и заставляет команду синхронизировать понимание задачи.

Приоритизация задач: Искусство говорить «Нет»

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

Метод MoSCoW

Это популярный фреймворк для распределения требований и тестовых сценариев по четырем категориям критичности. Название является акронимом:

Must have (Должно быть) — критические функции. Без них продукт не имеет смысла. Пример:* В приложении для логистики курьер должен иметь возможность изменить статус заказа на «Доставлен». Если это не работает, бизнес останавливается. Should have (Следует иметь) — важные, но не критичные функции. Их отсутствие болезненно, но есть обходные пути. Пример:* Фильтрация заказов по району. Без нее неудобно, но курьер может пролистать список вручную. Could have (Могло бы быть) — желательные функции, улучшающие пользовательский опыт (UX), но не влияющие на базовую логику. Пример:* Темная тема оформления в приложении. * Won't have (Не будет в этот раз) — функции, от которых осознанно отказываются в текущем релизе ради экономии времени.

!Матрица приоритизации MoSCoW

При нехватке времени тестировщик в первую очередь прогоняет тест-кейсы из группы Must have. Если время остается — переходит к Should have.

Риск-ориентированное тестирование (Risk-Based Testing)

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

Приоритизация тестов выстраивается на основе бизнес-рисков. Тестировщик задает себе вопрос: «Где компания потеряет больше всего денег, если произойдет сбой?».

Сравним две задачи в интернет-магазине:

Даже если форма подписки сложнее технически, приоритет всегда отдается модулю оплаты. Ошибка в оплате — это прямая потеря выручки (высокий Impact). Ошибка в рассылке — это упущенная маркетинговая выгода (средний Impact).

Внедрение ИИ в процессы оценки и приоритизации

Оценка и приоритизация исторически опирались на интуицию и опыт Senior-специалистов. Однако сегодня искусственный интеллект трансформирует этот процесс, делая его data-driven (основанным на данных). Для специалиста, планирующего внедрять ИИ в бизнес-процессы, это одна из самых перспективных зон роста.

Предиктивная оценка трудозатрат (AI Estimation). Современные LLM и ML-модели могут интегрироваться с системами трекинга задач (например, Jira). ИИ анализирует исторические данные: сколько времени у конкретной команды занимали похожие задачи в прошлом, сколько багов было найдено, какие разработчики писали код. На основе этого ИИ предлагает свою оценку в Story Points. Если команда оценивает задачу в 3 балла, а ИИ говорит «Исторически такие задачи занимают 8 баллов из-за скрытых проблем с базой данных», это повод для команды пересмотреть свой прогноз.

Умная приоритизация дефектов (Smart Triage). В крупных B2C-продуктах пользователи ежедневно создают сотни обращений в поддержку. ИИ-агенты способны автоматически анализировать текст жалоб, классифицировать их и присваивать приоритет. Например, если ИИ замечает всплеск сообщений со словами «не могу оплатить», «ошибка 500 в корзине», он автоматически создает баг-репорт с наивысшим приоритетом (Blocker) и назначает его на дежурного инженера, минуя ручную сортировку.

Анализ тепловых карт использования (Usage-based Prioritization). ИИ анализирует логи продакшен-серверов и строит тепловые карты поведения реальных пользователей. Система может подсказать QA-отделу: «Вы тратите 30% времени на тестирование модуля X, но им пользуется только 2% клиентов. При этом модуль Y генерирует 80% выручки, но покрыт автотестами лишь наполовину». Это позволяет динамически менять приоритеты тестирования (MoSCoW) на основе реальной бизнес-ценности, а не субъективных ощущений команды.

Умение грамотно оценивать свои силы и фокусироваться на главном отличает начинающего тестировщика от инженера, который приносит реальную пользу бизнесу. В сочетании с инструментами ИИ эти навыки позволяют выстроить максимально эффективный и предсказуемый процесс обеспечения качества.

В предыдущем материале мы разобрали, что обеспечение качества (QA) — это не просто поиск ошибок в готовом коде, а управление процессами. Чтобы управлять процессом, нужно досконально понимать, из каких этапов он состоит и по каким правилам работает.

Любая программа, будь то простейший калькулятор или сложная ERP-система для управления международными цепочками поставок, проходит определенный путь от идеи до вывода из эксплуатации. Этот путь называется Жизненным циклом разработки программного обеспечения (Software Development Life Cycle, SDLC).

Понимание SDLC — это базовый навык для любого инженера. На собеседованиях уровня Junior QA вопросы о методологиях разработки звучат всегда, потому что от выбранной методологии зависит, когда именно вы начнете тестировать продукт, какие документы будете использовать и как будете взаимодействовать с командой.

Более того, если ваша цель — внедрение искусственного интеллекта в бизнес-процессы, вам необходимо понимать SDLC, чтобы знать, на каком именно этапе разработка «буксует» и куда выгоднее всего интегрировать AI-инструменты.

Базовые этапы SDLC

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

То, в каком порядке, с какой скоростью и насколько строго выполняются эти этапы, определяется методологией разработки.

Каскадная методология (Waterfall)

Waterfall (Водопад) — это традиционная, линейная и строго последовательная модель разработки. В ней каждый следующий этап SDLC начинается только после полного завершения предыдущего. Возврат на предыдущий шаг не предусмотрен или обходится очень дорого.

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

Особенности Waterfall

Проблемы Waterfall для тестировщика

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

> Стоимость исправления бага на этапе тестирования в 15 раз выше, чем на этапе проектирования, а на этапе поддержки (после релиза) — в 100 раз выше. > > Исследование IBM Systems Sciences Institute

Когда используют Waterfall: В проектах с критическими требованиями к безопасности и надежности, где цена ошибки — человеческие жизни или миллиарды долларов. Это медицинское ПО, аэрокосмическая отрасль, банковские ядра, государственные системы.

Гибкая методология (Agile)

В начале 2000-х годов IT-индустрия осознала, что бизнес меняется слишком быстро. Пока компания два года пишет CRM-систему по Waterfall, конкуренты уже захватывают рынок, а изначальные требования устаревают.

Ответом стал Agile (Гибкая методология). Это не конкретная инструкция, а набор принципов (философия), описанных в Agile Manifesto. Главная идея: разработка ведется короткими циклами (итерациями), в конце каждого из которых заказчик получает работающий кусочек продукта.

Вернемся к примеру со складом. В Agile мы не строим огромный ангар сразу. Сначала мы ставим небольшую палатку и начинаем хранить там самые важные товары (первая итерация). Затем заменяем палатку на контейнер (вторая итерация). Затем строим капитальное здание (третья итерация). На каждом этапе бизнес уже получает пользу.

Особенности Agile

!Сравнение методологий Waterfall и Agile

В Agile зародился важнейший концепт современного тестирования — Shift-Left Testing (Сдвиг влево). Если представить SDLC как линию времени слева направо, то тестирование «сдвигается» максимально влево, к началу проекта. Тестировщик начинает работу еще на этапе обсуждения идеи, предотвращая баги до написания кода.

Фреймворки Agile: Scrum и Kanban

Scrum (Скрам) Весь процесс разбивается на равные отрезки времени — спринты (Sprints), обычно от 1 до 4 недель. Перед началом спринта команда берет задачи из общего списка (бэклога), оценивает их и обязуется выполнить за эти две недели. В конце спринта команда должна показать работающий инкремент (новую функцию). Во время спринта добавлять новые задачи нельзя.

Kanban (Канбан) В отличие от Scrum, здесь нет жестких спринтов. Работа идет непрерывным потоком. Главный инструмент — Канбан-доска с колонками (например: «Нужно сделать», «В разработке», «В тестировании», «Готово»). Главное правило Канбана — ограничение незавершенной работы (WIP-limits). Например, тестировщик не может взять на проверку больше двух задач одновременно. Это предотвращает появление «бутылочных горлышек» (заторов) на этапе QA.

Сравнительная таблица: Waterfall против Agile

| Характеристика | Waterfall (Каскадная модель) | Agile (Гибкая методология) | | :--- | :--- | :--- | | Подход к планированию | Жесткий, всё планируется заранее | Гибкий, планирование перед каждой итерацией | | Документация | Объемная и исчерпывающая | Минимально необходимая | | Роль тестировщика | Вступает в работу на поздних этапах | Участвует в процессе с первого дня | | Изменение требований | Практически невозможно или очень дорого | Приветствуется на любом этапе | | Релиз продукта | Один масштабный релиз в самом конце | Частые релизы небольших обновлений | | Идеально подходит для... | Госзаказов, медицины, авиации | Стартапов, e-commerce, мобильных приложений |

Внедрение ИИ в жизненный цикл разработки

Понимание SDLC открывает двери для оптимизации процессов с помощью искусственного интеллекта. ИИ не заменяет методологии, он радикально ускоряет каждый из этапов.

Если вы планируете внедрять AI в бизнес-процессы разработки и поставок, вот как это выглядит на практике:

Переход от ручного тестирования к управлению качеством с помощью ИИ требует глубокого понимания того, как создается программное обеспечение. Зная разницу между Waterfall и Agile, вы сможете не просто находить ошибки, но и предлагать бизнесу оптимальные пути разработки, экономя время и деньги компании.

Подготовка к собеседованию: частые вопросы на позицию Junior QA

Собеседование на позицию Junior QA — это не экзамен на идеальное знание терминологии наизусть. Это проверка вашего образа мышления, способности логически рассуждать и умения применять теорию к реальным бизнес-задачам. Компании ищут инженеров, которые понимают, зачем они нажимают кнопки, а не просто следуют инструкциям.

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

Блок 1: Теория и процессы обеспечения качества

Этот блок проверяет ваш фундамент. Интервьюер хочет убедиться, что вы понимаете свое место в цикле разработки и не путаете базовые понятия.

Вопрос 1: В чем разница между QA, QC и тестированием?

Что проверяют: Понимание глобальной картины разработки ПО. Знает ли кандидат, что тестирование — это лишь часть большого процесса?

Типичная ошибка: Сказать, что это одно и то же, просто разные названия одной профессии.

Идеальный ответ: > Тестирование — это процесс поиска багов в уже написанном коде. Это реактивный подход. Контроль качества (QC) — это проверка готового продукта на соответствие требованиям перед релизом, включающая тестирование и сбор метрик. Обеспечение качества (QA) — это проактивный процесс выстраивания работы всей команды так, чтобы баги вообще не появлялись. QA работает с процессами, QC — с продуктом, а тестирование — с кодом.

Пример из практики: В логистической компании тестирование — это проверка того, что алгоритм построил маршрут. QC — это проверка того, что маршрут соответствует стандартам расхода топлива. QA — это внедрение правила, по которому разработчики пишут unit-тесты для алгоритма до передачи его в отдел тестирования.

Вопрос 2: Назовите основные принципы тестирования и объясните один из них.

Что проверяют: Знание стандартов ISTQB и умение применять их к реальности.

Типичная ошибка: Перечислить все семь принципов заученным текстом, но не смочь объяснить, как они работают на практике.

Идеальный ответ: > Один из главных принципов — «Исчерпывающее тестирование невозможно». Мы не можем проверить все возможные комбинации данных. Например, если в B2B-портале продаж есть 10 фильтров товаров, количество их комбинаций вычисляется по формуле , что дает более 1000 вариантов. У нас нет на это времени. Поэтому мы используем техники тест-дизайна, такие как классы эквивалентности, чтобы выбрать минимальное, но достаточное количество проверок.

Блок 2: Тестовая документация и техники тест-дизайна

Здесь проверяется ваше умение оптимизировать работу. Джуниор, который пишет 100 тестов там, где достаточно 5, обходится бизнесу слишком дорого.

Вопрос 3: Чем чек-лист отличается от тест-кейса? Когда вы выберете одно, а когда другое?

Что проверяют: Понимание уровня детализации документации и умение экономить время.

| Характеристика | Чек-лист | Тест-кейс | | :--- | :--- | :--- | | Суть | Список идей для проверки | Пошаговая инструкция | | Детализация | Низкая (только суть) | Высокая (шаги, тестовые данные, ожидаемый результат) | | Время на создание | Минимальное | Значительное | | Кто может пройти | Только опытный тестировщик, знающий продукт | Любой человек, даже не из IT |

Идеальный ответ: > Я выберу чек-лист, если проект работает по Agile, требования часто меняются, и нам нужно быстро проверить функционал без бюрократии. Тест-кейс я напишу для критически важного функционала (например, модуля оплаты), или если этот сценарий планируется передать в автоматизацию.

Вопрос 4: Как вы будете тестировать поле ввода скидки от 1 до 99 процентов?

Что проверяют: Владение техниками «Классы эквивалентности» и «Анализ граничных значений» (BVA).

Типичная ошибка: Начать перечислять случайные числа: «Ну, введу 5, потом 50, потом 100, потом буквы».

Идеальный ответ: > Я применю анализ граничных значений и классы эквивалентности. Шаг для целых процентов равен 1. > > Сначала определю границы: 1 и 99. > Позитивные проверки (валидные классы и границы): 1 (нижняя граница), 2 (чуть больше), 50 (номинальное значение из середины), 98 (чуть меньше верхней), 99 (верхняя граница). > Негативные проверки (невалидные классы): 0 (меньше минимума), 100 (больше максимума), отрицательные числа (-5), ввод букв, спецсимволов и пустое поле.

!Алгоритм ответа на вопрос о тестировании объекта

Блок 3: Дефекты и баг-трекинг

Умение правильно описать проблему — главный навык ручного тестировщика. Баг-репорт — это ваше лицо перед командой разработки.

Вопрос 5: В чем разница между Серьезностью (Severity) и Приоритетом (Priority)?

Что проверяют: Понимание разницы между техническим влиянием бага на систему и его влиянием на бизнес.

Идеальный ответ: > Severity определяет, насколько сильно баг ломает систему технически (от Trivial до Blocker). Priority определяет, как быстро разработчик должен это исправить с точки зрения бизнеса (от Low до Highest). Severity выставляет тестировщик, а Priority — менеджер или Product Owner.

Пример из практики: * High Priority / Low Severity: На главной странице логистической компании в слове «Доставка» опечатка — написано «Досавка». Технически ничего не сломано (Low Severity), но это видит каждый клиент, что бьет по репутации. Исправить нужно немедленно (High Priority). * Low Priority / High Severity: Приложение курьера падает (Blocker/High Severity), но только если перевернуть экран горизонтально на очень старой версии Android, которой пользуется 0.01% курьеров. Бизнесу выгоднее отложить эту задачу (Low Priority) и заняться новыми фичами.

Вопрос 6: Из каких обязательных полей состоит баг-репорт?

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

Идеальный ответ: > Хороший баг-репорт включает: > 1. Понятный заголовок по правилу «Что? Где? Когда?» (или «Что? Где? При каких условиях?»). > 2. Окружение (Environment) — версия ОС, браузер, тестовый стенд. > 3. Предусловия (Preconditions) — что нужно сделать до начала шагов. > 4. Шаги для воспроизведения (Steps to reproduce) — четко и атомарно. > 5. Фактический результат (Actual Result) — что пошло не так. > 6. Ожидаемый результат (Expected Result) — как должно быть согласно требованиям. > 7. Вложения (Attachments) — скриншоты, видео, логи сервера.

Блок 4: Веб-технологии и инструменты

Современный тестировщик не просто кликает по кнопкам, он понимает, как данные передаются по сети.

Вопрос 7: Что такое клиент-серверная архитектура?

Что проверяют: Понимание того, как работает интернет и веб-приложения.

Идеальный ответ: > Это архитектура, в которой приложение разделено на две части. Клиент (frontend) — это то, что видит пользователь, например, браузер или мобильное приложение. Он отвечает за отображение интерфейса. Сервер (backend) — это удаленный компьютер, который хранит базу данных и выполняет бизнес-логику. Клиент отправляет HTTP-запросы (например, GET или POST), а сервер возвращает HTTP-ответы с данными и статус-кодом.

Вопрос 8: Как вы используете DevTools в тестировании?

Что проверяют: Умение локализовать дефект. Если кнопка не работает, виноват frontend или backend?

Идеальный ответ: > Я использую DevTools постоянно. > Во вкладке Elements я проверяю верстку и ищу локаторы для будущих автотестов. > Во вкладке Console я ищу скрытые ошибки JavaScript (красный текст), которые могут не проявляться визуально. > Вкладка Network — самая важная. Если я нажимаю «Оформить заказ» и ничего не происходит, я открываю Network. Если запрос ушел, но вернулся статус (Internal Server Error) — баг на бэкенде. Если запрос вообще не сформировался или ушел с пустым телом (payload) — баг на фронтенде. > Во вкладке Application я проверяю сохранение токенов авторизации в Cookies или LocalStorage.

Блок 5: Ситуационные вопросы (Soft Skills)

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

Вопрос 9: Вы завели баг, а разработчик закрывает его со статусом «Не баг, а фича» (Won't Fix). Ваши действия?

Что проверяют: Умение аргументировать свою позицию без агрессии и опираться на факты, а не на эмоции.

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

Идеальный ответ: > Я не буду вступать в эмоциональный спор. Сначала я перечитаю требования (спецификацию). Если в требованиях четко сказано, что система должна вести себя иначе, я прикреплю ссылку на этот пункт к баг-репорту, верну его в статус Reopened и вежливо попрошу разработчика ознакомиться. > > Если требований нет или они описаны размыто, я обращусь к бизнес-аналитику или Product Owner'у. Я объясню им ситуацию с точки зрения пользователя: «Сейчас система работает так-то, это может привести к потере клиентов». Окончательное решение о том, баг это или фича, принимает бизнес, а не тестировщик или разработчик.

Вопрос 10: Релиз завтра утром. У вас есть 100 тест-кейсов, но вы успеваете пройти только 30. Что вы будете делать?

Что проверяют: Навыки приоритизации, знание риск-ориентированного тестирования и умение брать на себя ответственность.

Идеальный ответ: > Я применю риск-ориентированный подход и метод MoSCoW. Я не буду тестировать кейсы по порядку. > > Сначала я выделю критический функционал (Must have), поломка которого остановит бизнес-процессы (например, авторизация, оплата, создание накладной). Я выполню эти тесты в первую очередь. > Затем я проверю функционал со средним приоритетом (Should have). > Тесты на UI, шрифты и второстепенные функции (Could have) я пропущу или оставлю на пост-релизное тестирование. > Главное — я немедленно предупрежу команду и менеджера о рисках, чтобы решение о релизе принималось прозрачно.

Вопрос 11: Как протестировать карандаш (или лифт, или кофеварку)?

Что проверяют: Способность выйти за рамки IT и применить методологию тестирования к любому объекту. Это тест на аналитическое мышление.

Идеальный ответ: > Любое тестирование начинается с требований. Сначала я спрошу: для кого этот карандаш? Для художника, для ребенка или для космонавта? От этого зависят критерии качества. > > Допустим, это обычный офисный карандаш. Я разделю проверки на категории: > 1. Функциональные (Позитивные): Оставляет ли он след на бумаге? Стирается ли след ластиком? Можно ли его заточить? > 2. Функциональные (Негативные): Что будет, если писать им по стеклу или пластику (ожидаемый результат — следа нет, карандаш не ломается). > 3. Нефункциональные (Нагрузочные/Стресс): Какое давление нужно оказать, чтобы грифель сломался? Сколько метров линии можно провести до полного стачивания? > 4. Юзабилити и Безопасность: Удобно ли его держать? Не токсична ли краска, если человек по привычке начнет его грызть?

Блок 6: Как выделиться с помощью ИИ (AI Advantage)

Сегодня рынок Junior QA перенасыщен. Чтобы выделиться среди сотен кандидатов, вам нужно показать, что вы не просто знаете теорию, но и умеете использовать современные инструменты для ускорения своей работы.

Если в конце собеседования вас спросят: «Как вы оптимизируете свою рутину?» или «Какие инструменты вы изучаете дополнительно?», упомяните использование искусственного интеллекта.

Пример того, что стоит сказать: > «Помимо стандартных инструментов вроде Jira и DevTools, я активно внедряю в свою работу LLM-модели (например, ChatGPT или Claude). Я использую промпт-инжиниринг для генерации синтетических тестовых данных. Например, если мне нужно протестировать форму регистрации B2B-клиентов, я прошу ИИ сгенерировать 50 реалистичных профилей компаний с валидными и невалидными ИНН. > > Также я использую ИИ для анализа сложных логов. Если я вижу непонятную ошибку в консоли браузера, я скармливаю ее нейросети, чтобы быстрее понять первопричину и написать более точный баг-репорт для разработчика. Это экономит мне до 30% времени на рутинных задачах».

Такой ответ покажет интервьюеру, что вы мыслите на уровне Middle-специалиста, следите за трендами и нацелены на повышение эффективности бизнеса.

Собеседование — это диалог двух профессионалов. Не бойтесь брать паузу на подумать, рассуждайте вслух и всегда опирайтесь на здравый смысл и бизнес-логику. Успешного старта в карьере QA!

В предыдущем материале мы выяснили, что любая программа проходит через жизненный цикл разработки (SDLC), и сравнили две главные методологии: строгий Waterfall и гибкий Agile. Мы также затронули концепцию «сдвига влево» (Shift-Left), которая гласит, что тестирование должно начинаться как можно раньше.

Но что именно делает тестировщик, когда проект только стартует? Как организована его ежедневная работа? Чтобы процесс обеспечения качества не превратился в хаотичное «нажимание всех кнопок подряд», в инженерии существует Жизненный цикл тестирования программного обеспечения (Software Testing Life Cycle, STLC).

STLC — это последовательность шагов, которые QA-команда выполняет для того, чтобы гарантировать соответствие продукта заявленным требованиям. Если SDLC описывает, как создается продукт в целом, то STLC описывает исключительно процесс проверки этого продукта. По сути, STLC работает внутри SDLC.

Понимание этапов STLC — это абсолютный фундамент для прохождения собеседования на позицию Junior QA. Более того, если ваша конечная цель — внедрение искусственного интеллекта в бизнес-процессы продаж и логистики, вам необходимо четко понимать каждый шаг этого цикла. ИИ не может автоматизировать хаос; он автоматизирует только четко выстроенные процессы.

Каждый этап STLC имеет два важнейших атрибута:

Рассмотрим шесть классических этапов STLC на примере разработки системы управления складом (Warehouse Management System, WMS) для крупной логистической компании.

!Цикл STLC: шесть последовательных этапов тестирования

1. Анализ требований (Requirement Analysis)

Тестирование начинается задолго до того, как программисты напишут первую строчку кода. На этом этапе QA-инженеры изучают документацию, общаются с бизнес-аналитиками, заказчиками и разработчиками.

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

Представьте, что бизнес-аналитик написал требование для модуля оптовых продаж: «Если клиент заказывает большую партию товара, система должна автоматически применять скидку на доставку».

Для QA-инженера это требование — катастрофа. Оно нетестируемо. Тестировщик задает уточняющие вопросы:

В результате требование переписывается в точный математический формат: «Если объем заказа $V

2. Планирование тестирования (Test Planning)

Когда требования ясны, QA-лид (или старший тестировщик) начинает планировать, как именно команда будет проверять продукт. Результатом этого этапа становится Тест-план (Test Plan) — стратегический документ, описывающий весь процесс.

Что определяется на этапе планирования:

> Тест-план — это не просто бюрократия. Это контракт между QA-отделом и бизнесом. Он защищает команду тестирования от необоснованных претензий в стиле «почему вы не проверили работу приложения на iPhone 6», если в тест-плане было четко указано, что поддержка старых устройств не планируется.

3. Разработка тестовой документации (Test Case Development)

Это самый объемный этап ручного тестирования. На основе требований QA-инженеры пишут подробные инструкции — Тест-кейсы (Test Cases).

Тест-кейс — это пошаговый сценарий проверки одной конкретной функции. Он всегда содержит:

На этом же этапе подготавливаются тестовые данные (Test Data). Если мы тестируем систему поставок, нам нужны фиктивные базы данных с тысячами товаров, адресами складов и профилями водителей. Использовать реальные данные клиентов (с их настоящими паспортами и кредитными картами) строго запрещено из соображений безопасности.

4. Настройка тестовой среды (Test Environment Setup)

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

Поэтому создается Тестовая среда (Test Environment или Staging) — точная копия реальной системы, изолированная от внешнего мира.

Настройка среды включает:

Часто этот этап выполняется параллельно с написанием тест-кейсов. Этим занимаются системные администраторы, DevOps-инженеры или сами тестировщики, если проект небольшой.

5. Выполнение тестов (Test Execution)

Код написан разработчиками, среда настроена, тест-кейсы готовы. Начинается этап выполнения.

QA-инженер берет тест-кейс, выполняет шаги в тестовой среде и сравнивает Фактический результат (Actual Result) с Ожидаемым результатом (Expected Result).

Если результаты совпадают — тест пройден (Passed). Если система ведет себя не так, как описано в требованиях — тест провален (Failed), и тестировщик нашел дефект (баг).

В этом случае QA-инженер создает Баг-репорт (Bug Report или Отчет о дефекте) в системе отслеживания задач (например, в Jira).

Хороший баг-репорт должен отвечать на три вопроса: Что произошло? Где это произошло? При каких условиях?

Пример структуры баг-репорта для системы продаж:

После того как разработчик исправляет баг, тестировщик проводит Ре-тест (Re-test), чтобы убедиться, что ошибка действительно исчезла.

6. Закрытие цикла тестирования (Test Cycle Closure)

Когда все запланированные тесты выполнены, а критические баги исправлены, цикл завершается. Команда собирается для анализа проделанной работы.

Формируется Отчет о результатах тестирования (Test Summary Report). В нем указываются метрики:

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

Внедрение ИИ в жизненный цикл тестирования

Теперь, когда вы понимаете механику STLC, давайте посмотрим, как искусственный интеллект трансформирует этот процесс. Это именно та зона, где вы, как будущий эксперт по внедрению ИИ, сможете приносить бизнесу колоссальную ценность.

Традиционный STLC требует огромного количества ручного труда. ИИ не меняет сами этапы, но он радикально ускоряет их прохождение:

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

В предыдущих материалах мы разобрали жизненные циклы разработки (SDLC) и тестирования (STLC). Вы узнали, как выстроен процесс создания продукта и какие шаги предпринимает QA-инженер от анализа требований до финального отчета. Однако знание этапов — это лишь механика. Чтобы стать настоящим инженером по качеству, необходимо понимать фундаментальные законы, по которым работает эта профессия.

Международный совет по тестированию программного обеспечения (ISTQB) сформулировал Семь базовых принципов тестирования. Это не просто теоретические догмы, а практические аксиомы, которые ежедневно спасают IT-компании от миллионных убытков. Понимание этих принципов — обязательное требование на любом собеседовании уровня Junior QA, а для будущего эксперта по внедрению ИИ — это основа для понимания того, какие именно процессы нужно автоматизировать.

1. Тестирование демонстрирует наличие дефектов, а не их отсутствие

Главная задача тестирования — снизить вероятность того, что в программе остались скрытые ошибки. Но ни один QA-инженер в мире не может гарантировать, что продукт на 100% идеален.

Тестирование доказывает, что баги есть. Если в ходе проверок вы не нашли ни одной ошибки, это не значит, что их нет. Это значит лишь то, что ваши текущие тест-кейсы не смогли их обнаружить.

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

2. Исчерпывающее тестирование невозможно

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

Допустим, вы тестируете форму оформления оптового заказа. В ней есть:

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

!Визуализация комбинаторного взрыва

Вместо того чтобы пытаться проверить всё, QA-инженеры используют техники тест-дизайна (например, анализ граничных значений), чтобы выбрать минимальное количество тестов, покрывающих максимальное количество рисков.

3. Раннее тестирование экономит время и деньги

Этот принцип тесно связан с концепцией Shift-Left (сдвиг влево), которую мы упоминали ранее. Чем раньше обнаружен дефект, тем дешевле его исправить.

Рассмотрим стоимость ошибки на примере внедрения новой системы скидок в отделе продаж:

> Качество нельзя «встроить» в продукт в самом конце. Оно должно закладываться на этапе фундамента.

4. Кластеризация дефектов

В тестировании работает принцип Парето (правило 80/20): 80% всех багов содержится в 20% модулей программы.

Ошибки не распределяются по коду равномерно. Как правило, они скапливаются в самых сложных частях системы. Если вы тестируете крупную ERP-систему для управления предприятием, модуль смены аватарки пользователя, скорее всего, будет работать стабильно. А вот модуль интеграции с банковским шлюзом для проведения платежей будет постоянно ломаться, потому что там сложная логика, шифрование данных и зависимость от сторонних сервисов.

!Кластеризация дефектов

Опытный тестировщик знает «узкие места» своего продукта и направляет основные усилия именно туда, а не тратит время на равномерную проверку каждой кнопки.

5. Парадокс пестицида

Если фермер будет из года в год опрыскивать поле одним и тем же химикатом, насекомые выработают к нему иммунитет, и пестицид перестанет работать.

В тестировании происходит то же самое. Если вы будете постоянно прогонять один и тот же набор тест-кейсов, со временем они перестанут находить новые баги. Разработчики адаптируют свой код под ваши проверки, и старые тесты будут всегда проходить успешно (Passed), в то время как новые дефекты останутся незамеченными в других частях системы.

Чтобы преодолеть парадокс пестицида, тестовую документацию необходимо регулярно пересматривать, обновлять и дополнять новыми сценариями, особенно после добавления нового функционала.

6. Тестирование зависит от контекста

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

Контекст определяет, какие виды тестирования будут в приоритете: нагрузочное, тестирование безопасности, юзабилити или функциональное.

7. Заблуждение об отсутствии ошибок

Представьте, что вы потратили полгода на создание идеальной системы управления складом (WMS). Вы выловили 100% багов, система работает молниеносно, не падает при высоких нагрузках и имеет безупречный код.

Но когда вы устанавливаете её на терминалы кладовщиков, выясняется, что для оформления приемки одного паллета им нужно сделать 15 кликов и заполнить 8 обязательных полей. Кладовщики работают в толстых перчатках на холодном складе, им неудобно нажимать мелкие кнопки, и процесс приемки замедляется в три раза.

Программа без багов, которая не решает бизнес-задачу пользователя или неудобна в использовании — это провальный продукт. Отсутствие технических дефектов не гарантирует успеха.

Как ИИ трансформирует принципы тестирования

Для специалиста, планирующего внедрять искусственный интеллект в бизнес-процессы, эти семь принципов — отличная карта для поиска точек оптимизации. ИИ не отменяет эти законы, он помогает работать с ними эффективнее:

Понимание этих семи принципов формирует правильное мышление QA-инженера (QA Mindset). Вы перестаете быть просто «искателем ошибок» и становитесь инженером, который управляет рисками. В следующем материале мы перейдем к практике и начнем изучать автоматизацию тестирования на языке Python, чтобы поручить рутинные проверки машине.

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

Фундамент работы любого QA-инженера — это функциональное тестирование. Это процесс проверки того, что делает программное обеспечение, а не того, как оно это делает. Если вы разрабатываете систему управления складом (WMS), функциональное тестирование ответит на вопрос: «Может ли кладовщик успешно списать бракованный товар?». Вопросы скорости работы приложения или его дизайна относятся к нефункциональным видам тестирования, которые мы затронем позже.

Для специалиста, планирующего внедрять искусственный интеллект в бизнес-процессы логистики и продаж, понимание функционального тестирования критически важно. ИИ-модели, автоматизирующие закупки или маршрутизацию, опираются на жесткую бизнес-логику. Если эта логика не протестирована, алгоритм масштабирует ошибку на всю компанию.

Техники тест-дизайна: искусство выбирать правильные проверки

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

Рассмотрим две самые популярные техники, которые спрашивают на каждом собеседовании уровня Junior QA.

Классы эквивалентности

Эквивалентное разделение (Equivalence Partitioning) — это метод, при котором все возможные вводимые данные разбиваются на группы (классы). Программа должна обрабатывать любые значения внутри одного класса абсолютно одинаково. Следовательно, нам достаточно проверить только одно значение из каждой группы.

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

Вместо того чтобы тестировать все числа от 1 до 1000, мы выделяем классы эквивалентности:

Мы сократили бесконечное количество тестов всего до четырех проверок. Если система правильно рассчитала доставку для 25 кг, с вероятностью 99.9% она правильно рассчитает ее и для 30 кг, так как они обрабатываются одним и тем же блоком кода.

Анализ граничных значений

Анализ граничных значений (Boundary Value Analysis) — это логическое продолжение предыдущей техники. Статистика и принцип кластеризации дефектов показывают, что подавляющее большинство ошибок программисты допускают на стыке условий — на границах классов эквивалентности.

Разработчик мог написать в коде if (weight < 50) вместо if (weight <= 50). Из-за этой пропущенной черточки посылка весом ровно 50 кг вызовет сбой системы.

Поэтому мы обязаны протестировать сами границы и значения, максимально к ним приближенные. Для нашего примера с доставкой границами будут стыки между условиями. Мы берем само граничное значение, шаг до него и шаг после него (если шаг равен 1 кг):

!Интерактивный калькулятор классов эквивалентности и граничных значений

Комбинируя классы эквивалентности и анализ граничных значений, тестировщик создает компактный, но непробиваемый набор проверок для любой бизнес-логики.

Тест-кейс: чертеж для проверки качества

Когда QA-инженер определил, что нужно тестировать, он должен задокументировать как это сделать. Для этого создаются тест-кейсы (Test Cases).

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

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

Структура идеального тест-кейса

Рассмотрим структуру на примере проверки применения скидки в B2B-портале продаж.

| Поле | Описание | Пример заполнения | | :--- | :--- | :--- | | ID | Уникальный номер для ссылок | TC-142 | | Название | Краткая суть проверки (Что? Где? Когда?) | Применение промокода "VIP10" в корзине оптового покупателя | | Предусловия | Что должно быть готово до начала теста | 1. Пользователь авторизован как "Оптовик".<br>2. В корзине лежит товар на сумму 100 000 руб. | | Шаги | Конкретные действия (1 шаг = 1 действие) | 1. Перейти в раздел "Корзина".<br>2. Ввести "VIP10" в поле "Промокод".<br>3. Нажать кнопку "Применить". | | Ожидаемый результат | Как должна отреагировать система | 1. Появляется зеленое уведомление "Скидка применена".<br>2. Итоговая сумма меняется на 90 000 руб. |

Если при выполнении этого тест-кейса фактический результат совпадает с ожидаемым, тест считается пройденным (Passed). Если система выдает ошибку или сумма не меняется — тест провален (Failed), и тестировщик переходит к следующему этапу: заведению дефекта.

Баг-репорт: искусство сообщать о проблемах

Баг-репорт (Bug Report) — это технический документ, описывающий найденную ошибку. Его главная цель — предоставить разработчику исчерпывающую информацию для быстрого воспроизведения и исправления дефекта.

Плохой баг-репорт звучит так: «Кнопка оплаты не работает, всё сломалось, почините срочно!». Разработчик, получив такое сообщение, потратит часы на выяснение того, какой браузер использовался, какой товар покупали и что значит «не работает».

Хороший баг-репорт строится по правилу «Что? Где? При каких условиях?».

Обязательные атрибуты баг-репорта

!Жизненный цикл дефекта

Серьезность (Severity) и Приоритет (Priority)

Это два важнейших атрибута любого баг-репорта, разницу между которыми часто путают новички. Понимание этой разницы отличает простого тестировщика от инженера, понимающего бизнес-процессы.

Серьезность (Severity) определяет степень технического влияния бага на систему. Насколько сильно сломана программа?

Приоритет (Priority) определяет очередность исправления бага для бизнеса. Насколько быстро разработчик должен бросить все дела и чинить это?

Матрица Серьезности и Приоритета (Примеры из практики)

Чтобы лучше понять разницу, рассмотрим четыре классические комбинации на примере интернет-магазина:

Как ИИ трансформирует функциональное тестирование

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

Современные LLM (большие языковые модели) уже способны кардинально ускорить работу QA-отдела:

Функциональное тестирование учит системному мышлению. Вы учитесь декомпозировать сложные бизнес-процессы на атомарные шаги и находить уязвимости в логике. Это мышление станет вашим главным преимуществом, когда вы начнете проектировать архитектуру внедрения ИИ в реальные компании. В следующем материале мы сделаем первый шаг к автоматизации и узнаем, как заставить язык Python выполнять эти проверки за вас.

Нефункциональное тестирование: производительность и юзабилити

В предыдущих материалах мы разобрали, как проверять бизнес-логику программного обеспечения. Вы научились писать тест-кейсы и заводить баг-репорты, чтобы гарантировать: система делает ровно то, что от нее требует бизнес. Однако в реальном мире правильного ответа программы часто бывает недостаточно.

Представьте систему управления складом (WMS). Кладовщик сканирует штрихкод товара, и система корректно списывает его из базы данных. Функциональное тестирование пройдено успешно. Но что, если обработка одного штрихкода занимает три минуты? А если в период новогодних распродаж на смену выходят сто кладовщиков одновременно, и сервер полностью зависает?

Программа работает правильно, но бизнес все равно несет колоссальные убытки. Именно здесь на сцену выходит нефункциональное тестирование.

> Нефункциональное тестирование проверяет атрибуты качества системы: как система работает, а не что она делает. Оно оценивает скорость, масштабируемость, удобство, безопасность и совместимость.

Для специалиста, внедряющего искусственный интеллект в логистику и продажи, эти метрики критически важны. ИИ-модели требуют огромных вычислительных мощностей. Если алгоритм динамического ценообразования рассчитывает идеальную скидку для клиента дольше, чем клиент готов ждать на странице оформления заказа, эта инновация становится бесполезной.

Тестирование производительности: проверка на прочность

Тестирование производительности (Performance Testing) — это комплекс проверок, направленных на определение скорости отклика, пропускной способности и стабильности системы под определенной нагрузкой.

В сфере электронной коммерции (e-commerce) производительность напрямую конвертируется в деньги. Статистика показывает, что увеличение времени загрузки страницы всего на одну секунду снижает конверсию в покупку на 7%.

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

Нагрузочное тестирование (Load Testing)

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

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

Главные метрики здесь:

Стресс-тестирование (Stress Testing)

Если нагрузочное тестирование проверяет работу в нормальных условиях, то стресс-тестирование ищет предел прочности. Мы намеренно подаем на сервер экстремальную нагрузку, превышающую ожидаемую в несколько раз (например, 5000 пользователей вместо 500).

Зачем ломать систему?

!Интерактивный график нагрузочного и стресс-тестирования

Объемное тестирование (Volume Testing)

Объемное тестирование проверяет работу приложения при огромных объемах данных в базе.

В логистике база данных трекинга посылок растет экспоненциально. Система может летать, когда в базе 10 тысяч записей. Но когда через три года там накопится 50 миллионов записей, простой SQL-запрос «Показать историю перемещений груза» может положить сервер. QA-инженер искусственно заполняет тестовую базу миллионами синтетических записей и замеряет деградацию производительности.

| Тип тестирования | Объем нагрузки | Главный вопрос бизнеса | | :--- | :--- | :--- | | Нагрузочное | Ожидаемый максимум (100%) | Справимся ли мы с обычным наплывом клиентов? | | Стресс-тестирование | Экстремальный (200-500%) | Что сломается первым при вирусной популярности? | | Объемное | Огромная база данных | Не замедлится ли система через 5 лет работы? |

Тестирование удобства использования (Usability Testing)

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

В B2B-сегменте (корпоративное ПО) юзабилити часто недооценивают, считая, что «сотрудники привыкнут». Это опасное заблуждение. Если интерфейс CRM-системы заставляет менеджера по продажам делать 15 кликов вместо 3 для оформления сделки, компания ежедневно теряет сотни человеко-часов рабочего времени.

Эвристики Якоба Нильсена

В основе тестирования юзабилити лежат 10 эвристик (принципов), сформулированных пионером веб-дизайна Якобом Нильсеном. Рассмотрим три самые важные для бизнес-приложений:

!Тепловая карта внимания пользователей

Частью юзабилити также является доступность (Accessibility или A11y). Это проверка того, могут ли приложением пользоваться люди с ограниченными возможностями (слабовидящие, дальтоники, люди с нарушениями моторики). Внедрение поддержки экранных диктофонов (Screen Readers) и правильный контраст цветов — это не только социальная ответственность, но и требование законодательства во многих странах.

Совместимость и Безопасность

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

Тестирование совместимости (Compatibility Testing) гарантирует, что приложение работает одинаково хорошо в разных условиях.

Тестирование безопасности (Security Testing) — это отдельная, сложная отрасль (Penetration Testing). Однако базовые вещи проверяет и обычный QA. Например, он убеждается, что пароли не передаются в открытом виде в URL-адресе, а пользователь с правами «Младший менеджер» не может получить доступ к финансовым отчетам директора, просто изменив ID документа в адресной строке браузера.

Искусственный интеллект в нефункциональном тестировании

Нефункциональное тестирование требует огромного количества данных и сложных симуляций. Это идеальная среда для внедрения ИИ.

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

Однако вручную симулировать 5000 пользователей или проверять сайт в 20 разных браузерах невозможно. Для этого нужны инструменты автоматизации. В следующем этапе нашего пути мы перейдем к программированию и узнаем, как заставить язык Python выполнять рутинные проверки за доли секунды.

Тестовая документация: структура и назначение тест-плана

В предыдущих материалах мы разобрали механики поиска дефектов: от проверки бизнес-логики до стресс-тестирования серверов. Вы научились писать тест-кейсы и оформлять баг-репорты. Однако в реальной коммерческой разработке хаотичный поиск ошибок не работает. Если команда из десяти тестировщиков начнет проверять крупную систему управления складом без единого вектора, они потратят 80% времени на дублирование проверок и упустят критические уязвимости.

Чтобы хаос превратился в инженерный процесс, необходима тестовая документация. Это фундамент, который делает тестирование прозрачным, измеримым и управляемым. Для специалиста, планирующего внедрять искусственный интеллект в бизнес-процессы, понимание документации критически важно: ИИ-модели обучаются именно на структурированных исторических данных, логах и планах, а не на устных договоренностях.

Иерархия тестовой документации

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

!Иерархия тестовой документации

На позиции Junior QA вы будете работать преимущественно с 4 и 5 уровнями. Однако на собеседованиях всегда проверяют понимание 3 уровня — тест-плана. Умение читать и анализировать тест-план отличает инженера от простого «нажимателя кнопок».

Что такое Тест-план?

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

Представьте, что логистическая компания внедряет новый модуль динамического ценообразования для оптовых клиентов. Если тестировщик просто откроет сайт и начнет вводить разные цены, он не сможет ответить бизнесу на главные вопросы: «Когда мы закончим тестирование?», «Проверили ли мы интеграцию с бухгалтерией?» и «Готовы ли мы к релизу в эту пятницу?».

Тест-план отвечает на эти вопросы до того, как будет написан первый тест-кейс. Исторически стандартом для написания тест-планов считается IEEE 829, однако в современных Agile-командах его адаптируют и сокращают, оставляя только самые важные для бизнеса разделы.

Ключевые разделы Тест-плана

Рассмотрим структуру качественного тест-плана на примере разработки CRM-системы для отдела продаж.

1. Идентификатор и Введение (Identifier & Introduction)

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

Пример: Тестирование релиза 2.4 системы SalesForce_Custom. Цель релиза — внедрение функции автоматической отправки email-уведомлений клиентам при смене статуса заказа.

2. Объект тестирования (Features to be Tested)

Раздел содержит четкий список функций, которые подлежат проверке в рамках текущего цикла. Это защищает команду QA от претензий бизнеса в стиле «А почему вы не проверили вот ту старую кнопку?».

В нашем примере это будут:

3. Функции, не подлежащие тестированию (Features Not to be Tested)

Один из самых важных разделов для экономии бюджета. Здесь фиксируется то, что мы сознательно игнорируем.

Почему мы можем отказаться от тестирования функции?

Пример: В текущем релизе НЕ тестируется модуль генерации PDF-отчетов, так как его код не затрагивался, а регрессионное тестирование покрыто автоматизацией.

4. Подход к тестированию (Approach)

Здесь описывается, как именно мы будем проверять заявленные функции. Указываются виды тестирования (функциональное, интеграционное, нагрузочное) и распределение усилий.

Например, для модуля email-уведомлений подход может быть следующим: 70% времени уделяется интеграционному тестированию API почтового шлюза, 20% — функциональному тестированию интерфейса настройки шаблонов, 10% — кроссбраузерному тестированию отображения писем.

5. Критерии входа и выхода (Entry and Exit Criteria)

Это контрольные точки, которые не позволяют тестированию превратиться в бесконечный процесс.

Критерии входа определяют, при каких условиях QA-инженеры вообще приступают к работе:

Критерии выхода (или критерии приемки) указывают, когда тестирование считается успешно завершенным:

6. Требования к среде (Environmental Needs)

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

В этом разделе перечисляются:

7. Расписание и Роли (Schedule & Responsibilities)

Проектный менеджмент в чистом виде. Кто за что отвечает и в какие сроки.

| Роль | Имя сотрудника | Зона ответственности | Сроки | | :--- | :--- | :--- | :--- | | QA Lead | Анна С. | Написание тест-плана, контроль метрик | 01.10 - 02.10 | | Middle QA | Иван П. | Тестирование API, настройка Postman | 03.10 - 07.10 | | Junior QA | Елена В. | Ручное тестирование UI, кроссбраузерность | 03.10 - 08.10 |

8. Риски и пути их снижения (Risks and Mitigation)

Опытный инженер всегда предполагает, что всё пойдет не по плану. Управление рисками — это способность предвидеть проблемы и иметь план «Б».

В инженерии риск часто оценивается математически:

где — уровень риска (Risk Level), — вероятность возникновения (Probability, от 1 до 5), — влияние на проект (Impact, от 1 до 5).

Если вероятность того, что сторонний API для отправки SMS упадет во время тестирования, равна 4, а влияние этого на нашу работу равно 5 (мы не сможем тестировать регистрацию), то риск равен 20 (очень высокий).

План снижения риска (Mitigation): Разработчики должны заранее написать заглушку (Mock), которая будет имитировать успешный ответ от SMS-шлюза, чтобы QA-команда не простаивала в случае сбоя внешнего сервиса.

Тест-план против Тестовой стратегии

На собеседованиях часто просят объяснить разницу между этими двумя документами. Главное отличие заключается в масштабе и частоте изменений.

Тестовая стратегия создается один раз на старте проекта (или для всей компании). Она статична. Она отвечает на вопрос «Как мы тестируем в принципе?». Например: «В нашей компании все API покрываются автотестами на Python, а UI тестируется вручную».

Тест-план создается для каждого нового релиза, спринта или крупной фичи. Он динамичен. Он отвечает на вопрос «Как мы будем тестировать конкретно эту сборку на следующей неделе?».

От плана к действию: Чек-листы и Тест-кейсы

Когда тест-план утвержден, Junior и Middle QA инженеры приступают к декомпозиции — разбиению крупных задач на конкретные шаги. Для этого используются чек-листы и тест-кейсы.

Чек-лист — это простой список проверок. Он отвечает на вопрос «Что проверить?», но не говорит «Как». Пример:

Чек-листы идеальны для опытных тестировщиков, которые хорошо знают систему и не нуждаются в подробных инструкциях. Они экономят время на написание документации.

Тест-кейс — это подробная инструкция. Он содержит предусловия, пошаговые действия, тестовые данные и ожидаемый результат. Тест-кейсы необходимы, когда систему тестирует новичок, или когда процесс готовится к автоматизации (скрипту нужны точные шаги).

> «Плохой тест-кейс заставляет тестировщика думать над тем, какие данные ввести. Хороший тест-кейс содержит конкретные значения, позволяя сфокусироваться на поиске аномалий в поведении системы». > > Рекс Блэк, эксперт ISTQB

Искусственный интеллект в работе с тестовой документацией

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

Понимание структуры тест-плана делает вашу работу осмысленной. Вы перестаете быть просто пользователем, который ищет ошибки, и становитесь инженером, который управляет качеством продукта. В следующем шаге нашего обучения мы перейдем от теории к практике и начнем изучать язык Python, чтобы автоматизировать те рутинные проверки, которые мы сегодня научились планировать.

Чек-листы: правила составления и использования

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

Как убедиться, что вы ничего не забыли? Как доказать менеджеру, что форма оформления заказа проверена полностью? Для этого глобальные задачи из тест-плана декомпозируются (разбиваются) на конкретные проверки. Самый быстрый и популярный инструмент для этого в современных Agile-командах — это чек-лист.

Понимание того, как грамотно составлять чек-листы, является базовым навыком для позиции Junior QA. Более того, для специалиста, который планирует внедрять искусственный интеллект в процессы обеспечения качества, чек-листы представляют особый интерес: именно они легче всего поддаются автоматической генерации с помощью современных языковых моделей (LLM).

Что такое чек-лист?

> Чек-лист (от англ. check list — контрольный список) — это документ, описывающий, что именно должно быть протестировано, без детального описания того, как это нужно делать.

Представьте, что вы собираетесь в продуктовый магазин. Вы пишете на листке бумаги: «Молоко, яйца, хлеб, яблоки». Это чек-лист. Вы не расписываете пошагово: «Зайти в магазин, повернуть направо в отдел молочной продукции, найти полку номер 3, взять пакет молока жирностью 3.2%, проверить срок годности, положить в корзину». Вы просто фиксируете объект проверки, полагаясь на свой жизненный опыт.

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

!Сравнение чек-листа и тест-кейса

Чек-лист против Тест-кейса: главное отличие

На любом собеседовании на позицию Junior QA вас спросят: «В чем разница между чек-листом и тест-кейсом?».

Тест-кейс (Test Case) — это подробная пошаговая инструкция. В ней есть предусловия, конкретные тестовые данные (например, «ввести логин test@mail.com и пароль 123456»), шаги и ожидаемый результат для каждого шага. Тест-кейс может пройти даже человек, который видит систему впервые.

Чек-лист — это просто идея для проверки.

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

Пункт чек-листа:

Тот же сценарий в виде тест-кейса:

Когда использовать чек-листы, а когда тест-кейсы?

В коммерческой разработке время — это деньги. Написание подробных тест-кейсов занимает в 3–5 раз больше времени, чем составление чек-листов.

| Характеристика | Чек-лист | Тест-кейс | | :--- | :--- | :--- | | Уровень детализации | Низкий (только суть проверки) | Высокий (пошаговая инструкция) | | Скорость создания | Очень высокая | Низкая | | Поддержка при изменениях | Легко обновлять | Требует много времени на переписывание шагов | | Требования к тестировщику | Требует знания продукта и опыта | Может выполнить новичок | | Идеально подходит для... | Опытных команд, Agile-проектов, исследовательского тестирования | Автоматизации, передачи задач новичкам, строгих финансовых систем |

В современных стартапах и продуктовых компаниях (особенно в e-commerce и логистике) 80% ручного тестирования проводится именно по чек-листам. Тест-кейсы пишут только для самого критичного функционала (например, списание денег с карты) или для подготовки базы под автотесты.

Анатомия правильного чек-листа

Несмотря на то, что чек-лист — это простой список, в IT-индустрии есть стандарты его оформления. Если вы просто напишете в блокноте «проверить корзину», это не поможет команде. Хороший чек-лист обычно ведется в таблицах (Excel, Google Sheets) или специализированных системах управления тестированием (TestRail, Zephyr, Allure TestOps).

Каждая строка чек-листа должна содержать следующие атрибуты:

5 золотых правил составления чек-листов

Чтобы чек-лист был эффективным инструментом, а не просто списком слов, при его составлении необходимо соблюдать ряд правил.

Правило 1: Атомарность (Одна строка = одна проверка)

Атомарность означает неделимость. В одной строке чек-листа должна содержаться только одна логическая проверка. Если вы объедините несколько проверок, и одна из них провалится, а другая пройдет успешно, вы не сможете поставить корректный статус всей строке.

Плохо: Проверить регистрацию с правильным паролем, а затем с пустым полем email. (Если регистрация работает, а валидация пустого поля сломана — какой статус ставить? Passed или Failed?)

Хорошо:

Правило 2: Понятность и однозначность

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

Плохо: Проверить, что поиск работает хорошо. Хорошо: Проверить поиск товара по полному совпадению артикула.

Правило 3: Позитивное и негативное тестирование

Начинающие тестировщики часто проверяют только то, как система должна работать при правильных действиях пользователя (позитивное тестирование). Но реальные пользователи совершают ошибки. Чек-лист обязательно должен включать проверки на нестандартное поведение (негативное тестирование).

Пример для системы оптовых продаж (B2B портал):

Правило 4: Логическая группировка

Если в вашем чек-листе 100 пунктов, с ним невозможно работать. Проверки необходимо группировать по смысловым блокам. Это позволяет распределять работу между тестировщиками (например, один проверяет UI, другой — логику корзины).

Группировать можно по:

Правило 5: Использование техник тест-дизайна

Не нужно писать проверки для каждого возможного значения. Если поле принимает возраст от 18 до 99 лет, не нужно писать 81 строку в чек-листе. Используйте техники тест-дизайна (анализ граничных значений и классы эквивалентности), о которых мы говорили в предыдущих статьях.

Достаточно проверить:

Практический пример: Чек-лист для модуля продаж

Давайте составим фрагмент реального чек-листа для формы применения промокода в интернет-магазине. Это классическая задача, с которой сталкивается любой Junior QA.

Модуль: Корзина -> Промокоды

| ID | Проверка | Тип | Статус | Баг-репорт | | :--- | :--- | :--- | :--- | :--- | | PRM-01 | Применение действующего промокода на скидку 10% | Позитивный | | | | PRM-02 | Применение промокода с истекшим сроком действия | Негативный | | | | PRM-03 | Применение промокода, который уже был использован этим клиентом | Негативный | | | | PRM-04 | Ввод несуществующего промокода | Негативный | | | | PRM-05 | Ввод промокода в другом регистре (например, sale вместо SALE) | Позитивный | | | | PRM-06 | Применение промокода к товарам, на которые уже действует максимальная скидка | Негативный | | | | PRM-07 | Отмена примененного промокода (удаление из корзины) | Позитивный | | |

Обратите внимание: мы не пишем, какие именно кнопки нажимать. Мы фиксируем бизнес-логику, которую нужно проверить. Если тестировщик знает, как работает корзина, этого списка ему будет более чем достаточно.

Внедрение ИИ в работу с чек-листами

Создание чек-листов — это творческий, но рутинный процесс. Вы должны прочитать требования бизнеса (например, спецификацию на 20 страниц) и вычленить оттуда все возможные сценарии использования. Именно на этом этапе искусственный интеллект становится мощнейшим помощником QA-инженера.

Если ваша цель — не просто тестировать руками, а оптимизировать процессы с помощью ИИ, вам необходимо понимать, как LLM (Large Language Models, такие как ChatGPT или Claude) работают с тестовой документацией.

1. Генерация базовых проверок из требований

Вы можете загрузить в ИИ-модель текст бизнес-требований (User Story) и попросить сгенерировать чек-лист.

Пример промпта (запроса) для ИИ: > «Ты — Senior QA Engineer. Проанализируй следующие требования к модулю 'Расчет стоимости доставки' и составь атомарный чек-лист для функционального тестирования. Раздели проверки на позитивные и негативные. Примени техники анализа граничных значений. Требования: Доставка до 5 кг стоит 300 руб, от 5 до 20 кг — 800 руб, свыше 20 кг — доставка запрещена».

ИИ за секунды выдаст вам готовый список проверок (вес 4.9 кг, 5.0 кг, 5.1 кг и т.д.), сэкономив вам 20-30 минут рутинной работы.

2. Поиск пропущенных сценариев (Edge Cases)

Человеческий мозг склонен мыслить линейно. Мы хорошо придумываем стандартные сценарии, но часто забываем про редкие комбинации (edge cases — граничные случаи). ИИ отлично справляется с комбинаторикой.

Вы можете скормить ИИ свой готовый чек-лист и спросить: «Какие негативные сценарии или уязвимости я упустил?». Модель может подсказать неочевидные вещи: например, что произойдет, если два курьера одновременно попытаются взять один и тот же заказ в приложении логистики (проверка на состояние гонки — race condition).

3. Трансформация чек-листов в автотесты

Это следующий шаг вашей эволюции как инженера. Когда у вас есть хорошо структурированный чек-лист, современные ИИ-инструменты (например, GitHub Copilot) могут помочь перевести эти проверки на язык программирования (Python), создавая каркас для автоматизированных тестов.

Резюме и следующие шаги

Чек-лист — это ваш главный рабочий инструмент на каждый день. Он позволяет быстро охватить систему тестами, не увязнув в написании многостраничных инструкций.

Главные правила хорошего чек-листа:

Умение быстро декомпозировать сложную систему на простые проверки — это навык, который отличает хорошего тестировщика. А умение делегировать рутинную часть этой декомпозиции искусственному интеллекту — это навык, который сделает вас незаменимым специалистом на рынке.

В следующей части нашего курса мы перейдем к тому, что происходит, когда пункт чек-листа получает статус Failed. Мы научимся грамотно документировать найденные ошибки, создавая баг-репорты, которые разработчики будут понимать с первого раза.

Тест-кейсы: атрибуты и правила написания эффективных сценариев

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

Здесь на сцену выходит тест-кейс (Test Case) — фундаментальная единица тестовой документации. Умение писать грамотные, понятные и поддерживаемые тест-кейсы — это базовый навык, который ожидают от любого Junior QA на первом же собеседовании. Более того, именно качественно написанные ручные тест-кейсы в будущем станут основой для ваших автоматизированных скриптов на Python.

Что такое тест-кейс и зачем он нужен?

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

Если чек-лист — это список покупок («купить молоко»), то тест-кейс — это подробный кулинарный рецепт («взять 200 мл молока жирностью 3.2%, нагреть до 40 градусов, добавить дрожжи»).

Тест-кейсы решают три главные задачи бизнеса:

Анатомия идеального тест-кейса

В разных компаниях (и в разных системах управления тестированием, таких как Jira + Zephyr, TestRail или Allure TestOps) визуальное представление тест-кейса может отличаться. Однако его логическая структура всегда остается неизменной.

Каждый профессиональный сценарий состоит из строго определенного набора атрибутов.

1. Идентификатор (ID) и Название (Title)

ID — это уникальный номер тест-кейса в системе (например, LOG-145). Он нужен для того, чтобы ссылаться на проверку в отчетах или баг-трекерах.

Название должно отвечать на три вопроса: Что мы делаем? Где мы это делаем? При каких условиях?

Плохое название: Проверка корзины. Хорошее название: Применение валидного промокода на скидку 10% в корзине неавторизованного пользователя.

2. Предусловия (Preconditions)

Это состояние, в котором должна находиться система до начала выполнения первого шага. Предусловия экономят время: мы не расписываем в шагах, как зарегистрироваться или как добавить товар в корзину, если тестируем только оплату.

Пример для системы логистики:

3. Шаги (Steps) и Ожидаемый результат (Expected Result)

Это ядро тест-кейса. Шаги описывают конкретные действия пользователя, а ожидаемый результат — реакцию системы на эти действия. Важно понимать: ожидаемый результат может быть как у всего тест-кейса в целом, так и у каждого отдельного шага.

!Структура идеального тест-кейса

4. Тестовые данные (Test Data)

Конкретные значения, которые нужно ввести в поля. Если вы напишете «ввести правильный email», разные тестировщики введут разные данные. Один введет test@mail.ru, другой admin@company.com. Если система упадет, будет сложно понять, что именно вызвало ошибку. Пишите конкретно: test_user_01@gmail.com.

5. Постусловия (Postconditions)

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

Пример: Если в процессе теста мы создали тестовый заказ, в постусловиях нужно указать: «Удалить заказ №999 из базы данных или перевести его в статус 'Отменен'». Если этого не сделать, тестовые заказы засорят базу, и аналитика отдела продаж будет испорчена.

Практический пример: Тест-кейс для B2B-портала

Давайте соберем все атрибуты вместе и напишем реальный тест-кейс для системы оптовых продаж.

ID: B2B-ORD-012 Название: Оформление заказа при превышении доступного кредитного лимита компании. Приоритет: High (Высокий)

Предусловия:

Шаги и Ожидаемые результаты:

| № | Шаг (Действие) | Ожидаемый результат | Тестовые данные | | :--- | :--- | :--- | :--- | | 1 | Открыть раздел «Каталог товаров» | Открыта страница каталога со списком доступных позиций | | | 2 | Добавить в корзину «Промышленный насос X-100» в количестве 1 шт. | Товар добавлен в корзину. Счетчик корзины обновился на «1» | Цена насоса: 15 000 руб. | | 3 | Перейти в раздел «Корзина» | Отображается добавленный товар. Общая сумма заказа: 15 000 руб. Доступный лимит: 10 000 руб. | | | 4 | Нажать кнопку «Оформить заказ» | Заказ не оформлен. Появляется модальное окно с текстом ошибки | Текст ошибки: «Сумма заказа превышает ваш доступный кредитный лимит. Пожалуйста, пополните баланс» | | 5 | Нажать кнопку «Закрыть» в модальном окне | Окно закрыто, пользователь остался на странице корзины | |

Постусловия:

4 золотых правила написания шагов

Начинающие тестировщики часто совершают одни и те же ошибки при написании шагов. Чтобы ваш тест-кейс был профессиональным, соблюдайте следующие правила.

Правило 1: Независимость (Атомарность)

Тест-кейсы не должны зависеть друг от друга.

Типичная ошибка: Тест-кейс №2 начинается со слов «Продолжить действия из тест-кейса №1». Почему это плохо: Если тест-кейс №1 провалится из-за бага (например, сломалась авторизация), вы не сможете даже начать тест-кейс №2, хотя он проверяет совершенно другой модуль (например, редактирование профиля). Каждый тест-кейс должен быть самодостаточным. Используйте предусловия, чтобы задать начальную точку.

Правило 2: Никакой вариативности

В тест-кейсе не должно быть условий «если».

Типичная ошибка: «Нажать кнопку 'Оплатить'. Если появится окно ошибки, закрыть его, если откроется банк — ввести данные карты». Почему это плохо: Тест-кейс должен проверять один конкретный путь (позитивный или негативный). Если путей два — это два разных тест-кейса.

Правило 3: Очевидность действий

Пишите так, чтобы вас понял человек с улицы. Избегайте технических терминов там, где они не нужны, и не заставляйте тестировщика додумывать.

Плохо: «Проверить валидацию поля email». Хорошо: «Ввести в поле email значение test@ и нажать Enter».

Правило 4: Баланс детализации

Не впадайте в крайности. Слишком короткие шаги непонятны, а слишком подробные превращают тест-кейс в роман, который невозможно поддерживать.

Слишком подробно: «Навести курсор мыши на поле 'Логин'. Нажать левую кнопку мыши. На клавиатуре нажать клавишу T, затем E, затем S, затем T». Оптимально: «Ввести 'test' в поле 'Логин'».

Жизненный цикл тест-кейса и статусы выполнения

Тест-кейс — это живой документ. Он создается, выполняется, обновляется и, в конечном итоге, устаревает. Когда вы запускаете тест-кейс (этот процесс называется Test Execution), вы должны присвоить ему статус по результатам прохождения.

Основные статусы:

Внедрение ИИ в работу с тест-кейсами

Написание тест-кейсов — самая ресурсоемкая часть работы QA-инженера. В крупных проектах счет идет на тысячи сценариев. Именно здесь искусственный интеллект (AI) показывает феноменальную эффективность, забирая на себя рутину и освобождая время для исследовательского тестирования.

Если ваша цель — стать экспертом по внедрению ИИ в бизнес-процессы, вам нужно научиться использовать LLM (Large Language Models) для генерации тестовой документации.

1. Генерация шагов из User Story

Бизнес-аналитики пишут требования (User Stories). Вы можете передать эти требования ИИ и попросить сгенерировать готовые тест-кейсы в табличном формате.

Пример эффективного промпта для ChatGPT/Claude: > «Ты — Senior QA Engineer в логистической компании. Проанализируй следующее требование: 'Курьер должен иметь возможность прикрепить фото накладной (форматы JPG, PNG, до 5 МБ) при переводе заказа в статус Доставлен'. > Напиши 3 позитивных и 3 негативных тест-кейса. Ответ выдай в формате Markdown-таблицы со столбцами: ID, Название, Предусловия, Шаги, Ожидаемый результат, Тестовые данные. Соблюдай правило атомарности».

ИИ за несколько секунд создаст структуру, на написание которой у человека ушло бы 20-30 минут. Вам останется только проверить логику и скорректировать детали.

2. Поддержка актуальности (Test Maintenance)

Интерфейсы меняются. Вчера кнопка называлась «Купить», сегодня — «В корзину». Обновление сотен тест-кейсов вручную — боль любого QA-отдела.

С помощью ИИ-инструментов (или скриптов, обращающихся к API нейросетей) можно массово рефакторить тестовую документацию. Вы загружаете старые тест-кейсы и описание изменений в UI, а ИИ переписывает шаги под новый дизайн.

3. Мост к автоматизации на Python

Это ваш следующий шаг в обучении. Когда у вас есть идеально написанный ручной тест-кейс с четкими шагами и тестовыми данными, современные ИИ-ассистенты (например, GitHub Copilot) могут автоматически перевести этот текст в код на Python (используя фреймворки Pytest и Selenium/Playwright).

Ручной шаг: «Ввести 'admin' в поле 'Логин'». Сгенерированный ИИ код: page.locator("#login-input").fill("admin")

Чем точнее и однозначнее написан ваш ручной тест-кейс, тем качественнее ИИ напишет для него автоматизированный код. Плохой ручной тест-кейс приведет к созданию нестабильного (flaky) автотеста.

Резюме

Тест-кейс — это фундамент предсказуемого качества. В отличие от чек-листов, тест-кейсы обеспечивают высокую детализацию, независимость проверок и возможность передачи задач между сотрудниками без потери контекста.

Запомните главные правила:

Когда тест-кейс получает статус Failed, работа тестировщика не заканчивается — она только начинается. Инженеру необходимо сообщить команде разработки о найденной проблеме так, чтобы ее можно было быстро локализовать и исправить. О том, как правильно документировать ошибки и составлять идеальные баг-репорты, мы подробно поговорим в следующей статье нашего курса.