Test instruction

Инструкция по тестированию в нашем проекте

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

---

Ремарки

Устройство задач

Если Вы не ознакомились с устройством нашей системы labels для issues, крайне рекомендуется это сделать.

Начало работы

Тестировщик работает уже с написанным разработчиком кодом. Причём этот код в большинстве случаев покрыт базовыми тестами от самого разработчика. Обычно тестировщик приступает к работе в момент, когда разработчик заканчивает решение задачи, описанной в issue, и создаёт Pull Request. Именно создание PR является сигналом для тестировщика, что код уже готов к проверке и тестированию. Начинать тестирование незавершённого кода — плохая затея, потому что код может несколько раз измениться, что сделает уже написанные тесты бесполезными.

ВНИМАНИЕ! Разработчик создаёт PR после выполнения первой task из feature. Сразу после этого тестировщик подключается к проверке решения.

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

Продукт работы тестировщика

Результатом деятельности тестировщика всегда является проверка, что описанная в issue задача корректно решена. При этом крайне нежелательна ситуация, при которой в результате тестирования некоего кода тестировщик сам вносит правки для исправления кода, чтобы тот начал проходить тесты. Часто тестировщик может неправильно понять, что и как хотел сделать разработчик. Это может привести к тому, что ситуация только усугубится. Поэтому после выявления некорректности решения задачи на каких-либо входных данных стоит задокументировать найденную ошибку. В большинстве случаев достаточно добавить комментарий в PR, который проверяется. Но если ошибка влечёт за собой нарушение работы всей системы, то стоит создать отдельную задачу в issues для решения данной проблемы с меткой code maintenance. Если Вы знаете, как исправить ошибку, то укажите решение в комментарии или issue.

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

---

Инструкция

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

Ниже приводится инструкция для работы с созданным разработчиком Pull Request:

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

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

3. Тестирование. Pull Request проходит проверку от системы CI, а значит Вам стоит подтянуть в свой локальный репозиторий внесённые изменения и приступить к тестированию решения. Сам процесс тестирования кода мы не будем описывать (причины описаны выше).

4. Запрос изменений. Если Ваше тестирование не выявило проблем, то скорее всего Вы плохо протестировали решение перейдите к следующему пункту. После нахождения ошибок Вам следует оформить отчёт в виде "Review" (зелёная кнопка в правом углу PR). Можно написать комментарий, в котором описать все найденные проблемы. Либо можно указать конкретные методы, которые содержат ошибки. Написали разработчику обо всех ошибках? Тогда нажимайте "Request changes" и ждите исправлений от разработчика. После внесения новых изменений перейдите снова к п. 2 данной инструкции.

5. Завершение работы с PR. После завершения тестирования решения задачи, необходимо оповестить участников команды о том, что тестирование этой задачи завершено. Для этого нажмите "Review", а затем "Approve". После проверки Вашего отчёта руководителем команды, разработчик проводит merge PR. Иногда руководитель может запросить проведение дополнительного раунда тестирования, если считает, что текущие тесты не полностью проверяют внесённые изменения.