Практический курс: Профессия Тестировщик ПО (QA Engineer)

Основы тестирования: жизненный цикл разработки и виды тестирования на практике

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

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

QA, QC и Тестирование: разберемся в понятиях

В индустрии часто путают термины QA (Quality Assurance), QC (Quality Control) и Testing. Чтобы стать профессионалом, важно понимать разницу.

Quality Assurance (Обеспечение качества)

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

Quality Control (Контроль качества)

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

Testing (Тестирование)

Это непосредственное исполнение проверок. Тестировщик нажимает кнопки, вводит данные, сверяет фактический результат с ожидаемым. Это часть QC, которая, в свою очередь, является частью QA.

!Вложенность понятий: Тестирование входит в QC, а QC входит в QA

Жизненный цикл разработки ПО (SDLC)

Программное обеспечение не появляется из ниоткуда. Оно проходит через определенные стадии, называемые SDLC (Software Development Life Cycle). Тестировщик участвует почти на каждом этапе.

Сбор и анализ требований. Заказчик говорит: «Хочу кнопку купить». Тестировщик уже здесь задает вопросы: «А что если товара нет на складе?», «А если интернет пропадет в момент нажатия?». Ошибки, найденные на этом этапе, стоят дешевле всего.

Дизайн и проектирование. Создаются макеты интерфейса и архитектура базы данных.

Разработка (Coding). Программисты пишут код.

Тестирование. Активная фаза поиска дефектов.

Развертывание (Deployment). Продукт попадает к пользователям.

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

!Этапы жизненного цикла разработки программного обеспечения

Жизненный цикл тестирования (STLC)

Внутри этапа «Тестирование» есть свой собственный цикл — STLC (Software Testing Life Cycle). Нельзя просто сесть и начать «тыкать» в приложение. Процесс выглядит так:

* Анализ требований. Изучаем документацию. Планирование. Решаем, что будем тестировать, кто это будет делать и сколько* времени это займет. Пишем Тест-план. * Разработка тестов. Пишем тест-кейсы (инструкции по проверке) и чек-листы. * Выполнение тестов. Проходим по написанным инструкциям и заводим баг-репорты (отчеты об ошибках), если что-то не работает. * Завершение. Пишем отчет о результатах тестирования.

Виды тестирования: классификация на практике

Тестирование можно разделить на категории по разным признакам. Рассмотрим самые важные для начинающего специалиста.

По доступу к коду

Метод черного ящика (Black Box). Вы не видите код и внутреннюю структуру программы. Вы действуете как обычный пользователь: вводите данные и смотрите на результат. Пример: проверка формы регистрации на сайте.* * Метод белого ящика (White Box). Вы видите код, знаете архитектуру и пишете тесты, проверяющие логику работы функций. Этим чаще занимаются разработчики (Unit-тесты). * Метод серого ящика (Grey Box). Комбинация методов. Вы видите базу данных или логи сервера, но тестируете через интерфейс.

По уровню детализации (Пирамида тестирования)

Модульное (Unit Testing). Проверка отдельной функции или класса. Самый низкий уровень, выполняется быстро.

Интеграционное. Проверка взаимодействия между модулями. Например, как модуль «Корзина» передает данные модулю «Оплата».

Системное. Проверка всей системы целиком от начала до конца.

Приемочное. Финальная проверка перед передачей заказчику.

По цели тестирования

Это самое важное разделение для ежедневной работы.

#### Функциональное тестирование Отвечает на вопрос: «Что делает система?». Мы проверяем функции продукта. * Может ли пользователь войти в систему? * Добавляется ли товар в корзину? * Рассчитывается ли скидка правильно?

#### Нефункциональное тестирование Отвечает на вопрос: «Как работает система?». * Тестирование производительности: Как быстро загружается страница при 1000 пользователей одновременно? * Тестирование безопасности: Можно ли взломать аккаунт, не зная пароля? * Юзабилити (UI/UX): Удобно ли пользоваться приложением? Не перекрывает ли кнопка текст?

Практический кейс: Тестирование формы логина

Перейдем к практике. Допустим, вам нужно протестировать простую форму входа на сайте, состоящую из полей «Email», «Пароль» и кнопки «Войти».

1. Позитивное тестирование (Happy Path)

Это сценарий, при котором пользователь не совершает ошибок. Мы проверяем основной функционал. * Действие: Ввести валидный (существующий) email, ввести верный пароль, нажать «Войти». * Ожидаемый результат: Успешный вход, перенаправление в личный кабинет.

2. Негативное тестирование

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

Сценарий А: Неверный пароль * Действие: Ввести верный email, ввести неверный пароль. * Ожидаемый результат: Сообщение «Неверный логин или пароль». Доступ запрещен.

Сценарий Б: Пустые поля * Действие: Оставить поля пустыми, нажать «Войти». * Ожидаемый результат: Подсветка полей красным, сообщение «Поля обязательны для заполнения».

Сценарий В: SQL-инъекция (Безопасность) * Действие: Ввести в поле пароля спецсимволы, например ' OR '1'='1. * Ожидаемый результат: Система воспринимает это как текст, вход не выполнен, база данных не скомпрометирована.

3. Граничные значения

Ошибки часто прячутся на границах допустимых диапазонов. Если пароль должен быть от 6 до 20 символов, мы проверим: * 5 символов (негативный тест) * 6 символов (позитивный тест, нижняя граница) * 20 символов (позитивный тест, верхняя граница) * 21 символ (негативный тест)

Жизненный цикл дефекта (Bug Lifecycle)

Когда вы находите ошибку, вы создаете баг-репорт. У этого отчета тоже есть свой жизненный путь:

New (Новый). Вы завели баг.

Assigned (Назначен). Тимлид назначил баг на разработчика.

In Progress (В работе). Разработчик чинит ошибку.

Fixed (Исправлен). Разработчик говорит, что починил.

Verified (Проверен). Вы проверяете исправление. Если работает — закрываете баг (Closed). Если нет — возвращаете разработчику (Reopened).

Итоги

QA, QC и Тестирование — это разные уровни работы с качеством. QA настраивает процесс, QC контролирует продукт, а Тестирование — это инструмент проверки.

Раннее тестирование экономит бюджет. Чем раньше найдена ошибка (например, на этапе требований), тем дешевле ее исправить.

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

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

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

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

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

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

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

Чек-лист (Checklist): Искусство краткости

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

Когда использовать чек-лист?

Когда мало времени. Нужно срочно проверить функционал перед релизом.

Когда продукт часто меняется. Поддерживать подробные инструкции (тест-кейсы) слишком дорого.

Для опытных тестировщиков. Вам не нужно расписывать каждый шаг, достаточно напоминания «Проверить оплату картой».

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

Чек-лист должен быть атомарным. Один пункт — одна проверка.

Плохой пример: * Проверить регистрацию, авторизацию и восстановление пароля.

Хороший пример: * Регистрация с валидными данными. * Регистрация с уже существующим email. * Авторизация с верным паролем. * Восстановление пароля через email.

> Чек-лист отвечает на вопрос «Что тестировать?», но не всегда объясняет «Как?».

Тест-кейс (Test Case): Подробная инструкция

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

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

!Анатомия стандартного тест-кейса

Атрибуты тест-кейса

Разберем структуру на реальном примере функции «Перевод денег по номеру телефона».

#### 1. ID (Идентификатор) Уникальный номер. Например, TC-001.

#### 2. Title (Заголовок) Должен быть кратким, но емким. Хороший заголовок отвечает на вопросы: Что? Где? Когда? Плохо:* Перевод денег. Хорошо:* Успешный перевод денег клиенту того же банка по номеру телефона.

#### 3. Preconditions (Предварительные условия) Что должно быть сделано до начала теста, чтобы мы могли его выполнить. Пример:* Пользователь авторизован, на балансе есть 1000 рублей.

#### 4. Test Data (Тестовые данные) Конкретные логины, пароли или номера карт, которые мы используем.

#### 5. Steps (Шаги) Инструкция к действию. Используйте повелительное наклонение: «Нажать», «Ввести», «Перейти».

#### 6. Expected Result (Ожидаемый результат) Самая важная часть. Что должно произойти после выполнения шагов. Не пишите «Система работает правильно». Пишите конкретику.

Практический пример: Тест-кейс №15

| Атрибут | Значение | | :--- | :--- | | ID | PAY-15 | | Заголовок | Ошибка при переводе отрицательной суммы | | Предусловия | Пользователь залогинен, открыта страница «Переводы» | | Шаги | 1. Ввести номер телефона получателя +79990000000<br>2. В поле «Сумма» ввести -100<br>3. Нажать кнопку «Перевести» | | Ожидаемый результат | Кнопка «Перевести» неактивна. Под полем «Сумма» появилось сообщение красного цвета: «Сумма перевода должна быть больше 0» |

Баг-репорт (Bug Report): Хроника происшествия

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

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

Золотой стандарт оформления бага

#### 1. Summary (Тема) Это то, что разработчик увидит в списке задач. Тема должна отвечать на три вопроса: Что случилось? Где? При каких условиях?

Плохо:* Кнопка не работает. Плохо:* Ошибка в корзине. Хорошо:* Ошибка 404 при нажатии кнопки «Оплатить» в пустой корзине. Хорошо:* Невозможно ввести кириллицу в поле «Имя» в профиле пользователя.

#### 2. Description (Описание) Здесь мы подробно расписываем контекст.

#### 3. Steps to Reproduce (Шаги воспроизведения) Самая критичная часть. Шаги должны вести к багу кратчайшим путем.

Открыть сайт...

Нажать...

Ввести...

#### 4. Actual Result (Фактический результат) Что произошло на самом деле. Пример: Приложение закрылось без ошибки.

#### 5. Expected Result (Ожидаемый результат) Как система должна была повести себя согласно требованиям. Пример: Появилось сообщение «Недостаточно средств».

#### 6. Attachments (Вложения) Скриншоты, видео записи экрана, логи сервера. Один скриншот может заменить 1000 слов описания.

!Разница между плохим и хорошим баг-репортом

Severity и Priority: В чем разница?

В каждом баг-репорте есть два поля, которые часто путают новички: Серьезность (Severity) и Приоритет (Priority).

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

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

Blocker (Блокирующий): Система не работает, дальнейшее тестирование невозможно. Пример: Сайт не открывается.

Critical (Критический): Не работает ключевая бизнес-функция. Пример: Не проходит оплата.

Major (Значительный): Не работает часть функционала, но есть обходной путь. Пример: Не работает поиск по фильтрам, но работает общий поиск.

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

Trivial (Тривиальный): Опечатки, цвет фона отличается на полтона.

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

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

Матрица противоречий

Может ли быть высокий приоритет при низкой серьезности? Да!

* High Priority / Low Severity: Опечатка в названии компании на главной странице. На работу системы не влияет (Low Severity), но репутационные риски огромны, нужно чинить немедленно (High Priority). * Low Priority / High Severity: Приложение падает (High Severity), если нажать 10 кнопок одновременно на старом Android 4.0. Ошибка критичная, но таких пользователей 0.01%, поэтому чинить будем в последнюю очередь (Low Priority).

!Матрица соотношения Приоритета и Серьезности

Практикум: Разбор ошибок в баг-репортах

Давайте посмотрим на типичные ошибки новичков, чтобы вы их не допускали.

Ошибка №1: Эмоции вместо фактов > «Эта дурацкая программа опять упала, когда я хотел купить билет!»

Разработчику не интересны ваши эмоции. Ему нужны логи и шаги. Будьте профессионалом.

Ошибка №2: Обобщение > «Не работает вход в систему»

Как не работает? Кнопка не нажимается? Выдает ошибку 500? Пишет «неверный пароль»? Всегда уточняйте детали.

Ошибка №3: Отсутствие ожидаемого результата Вы написали: «При вводе 11 цифр поле подсвечивается красным». Разработчик может ответить: «Ну и отлично, так и задумано». Если вы не укажете, что поле должно принимать 11 цифр, баг могут закрыть как «Not a bug».

Итоги

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

Хороший заголовок тест-кейса или баг-репорта отвечает на вопросы: Что? Где? Когда (при каких условиях)?

Баг-репорт должен быть воспроизводимым. Если разработчик не может повторить ошибку по вашим шагам, он вернет тикет назад.

Severity (влияние на систему) и Priority (порядок исправления) — разные понятия. Опечатка на главной — это низкая серьезность, но высокий приоритет.

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