Чек-лист для начинающих тестировщиков

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

Алия Токарева

Инженер-тестировщик 2 категории компании ICL Services

Процесс разработки

Перед тем, как углубляться в мир тестирования, необходимо знать рабочий процесс разработки программного обеспечения (SDLC), а это:

• жизненный цикл разработки,
• жизненный цикл тестирования,
• модели жизненного цикла,
• методологии управления проектами (особенно гибкие методологии, например, Scrum, Kanban).

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

Начала изучения тестирования

Для первых шагов тестирования необходимо знать базовый набор тестирования. Сюда можно отнести:

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

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

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

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

API-тестирование

На одном из этапах жизненного цикла разработки, программы не имеют графического интерфейса, поэтому знать, как проводить API-тестирование при помощи Postman или других аналогичных программных продуктов — это must have для каждого начинающего тестировщика. Особенно необходимо знать, что такое метод CRUD и какие запросы он в себя включает, а также почему такой метод не всегда эффективен в API-тестировании.

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

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

1. Компонентное тестирование (модульное тестирование — тестируется один или несколько модулей одной программы без взаимодействия друг с другом);
2. Интеграционное тестирование (тестируется на взаимодействие между модулями программы или системами);
3. Системное тестирование (более масштабное тестирование, в котором проходит проверку интеграция компонентов или группы компонентов между разными программами, а также фокусируется на поведении и возможностях целой системы);
4. Приемочное тестирование (понимается тестирование перед выкладкой релиза, которое обычно фокусируется на поведении и возможностях системы или программы в целом).

Также важно уметь отличать типы тестирования:

1. Функциональное тестирование;
2. Нефункциональное тестирование;
3. Тестирование методом белого ящика;
4. Тестирование, связанное с изменениями.

Техники тест-дизайна

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

1. К черному ящику следует отнести тесты:

• Анализ граничных значений (например, поле, принимающее 20 значений, имеет границы: нижнее 0 (пустое поле) и 1; верхнее: 20 и 21);
• Эквивалентное разбиение, которое помогает исключить некоторые тесты, чтобы предотвратить исчерпывающее тестирование (к примеру, в поле, принимающее 20 значений, нет смысла тестировать приграничные значения 2 и 19, потому что при вводе граничных значений 1 и 20 ошибок не возникло. P.S. если в этом поле запустить все 22 теста (от пустого поля до 21 символа) — то это уже является исчерпывающим тестированием, которое недостижимо);
• Тестирование с помощью таблицы альтернатив помогает выявить баги в программных модулях, которые имеют условия. Например, существует ли регистрация пользователя при покупке товара в интернет-магазине:
  
• Тестирование с помощью диаграммы (таблицы) состояния-переходов. К примеру, какое состояние будет иметь сайт интернет-магазина, если отменить операцию покупки на этапе оплаты? Или какое состояние примет веб-приложение, если указаны неверные реквизиты при оплате товара?
  
• Тестирование с помощью сценариев использования. Для примера, сможет ли зарегистрированный пользователь (участник) зайти в личный кабинет интернет-магазина (субъект)? Или удастся ли незарегистрированному пользователю открыть страницу личного кабинета? Или, если уже зарегистрированный пользователь указал неверные данные при входе, откроет ли страницу личного кабинета?

2. Метод, основанный на опыте, включающий в себя три вида:

• Предположение об ошибках;
• Исследовательское тестирование (обычно без применения каких-либо тестов);
• Тестирование на основе чек-листов.

Инструменты тестирования

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

1. Инструменты управления тестированием и тестовым окружением (тест-план, инструменты управления требованиями — таблица трассировки, управление дефектами — Jira, YouTrack и т. д., управление конфигурацией — Git);
2. Инструменты статического тестирования (рецензирование — планирование и контроль процесса рецензирования, передачи данных, совместное рецензирование для сбора показателей и составления отчетности);
3. Инструменты проектирования и реализации тестов (техники тест-дизайна, maind-map, подготовка тестовых данных);
4. Инструменты покрытия и выполнения тестов (таблица трассировки, TestRail, тест-кейсы, TestManagement и т. д.).

Баг

Баг-репорт

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

1. S — (specific) конкретность, прозрачность;
2. M — (measurable) измеримость;
3. A — (attainable) достижимость, реалистичность;
4. R — (relevant) актуальность;
5. T — (time-bound) ограничения во времени

Баг-репорт состоит из:

1. ID номер бага;
2. Наименование (хорошее название — это шаг к быстрому понимаю бага разработчиком);
3. Спецификация (версия ПО, ссылки, браузер, тестовая среда и т. д.);
4. Предусловие (не всегда применяется, но иногда необходим, когда нужно выполнить какое-то условие перед воспроизведением бага);
5. Шаги воспроизведения (которые должны иметь конкретность, прозрачность, локальность);
6. Ожидаемый результат (важно помнить, что ожидаемый результат = требуемому результату);
7. Полученный результат (описание самого бага или поведения программы);
8. Аттачи (настройки INI, скриншоты, файлы, логи и т. д., которые помогают воспроизвести баг);
9. Исполнитель (разработчик, который должен исправить дефект);
10. Приоритетность;
11. Комментарии (не всегда они применяются, но более опытные тестировщики описывают ходы, как можно исправить тот или иной баг).

Заключение

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