Тестируем яблоко: смартфоны, планшеты и часы - страница 6

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

Преимущества:

1. Чек-лист легко читается;

2. По чек-листу быстро тестировать: в тест-кейсе нужно отмечать статус каждого шага, в то время как в чек-листе достаточно одной строчки;

3. Чек-лист – источник результатов для отчёта: можно быстро посчитать сколько проверок выполнено, в каком они статусе, узнать количество открытых репортов;

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

Недостатки:

1. Неопределенность тестового набора: каждый тестировщик выполняет пункт чек-листа по-своему;

2. Неопределенность тестовых данных;

3. Недостаточность детализации;

4. Сложнее обучить начинающих сотрудников: пункты чек-листа чаще абстрагируются от конкретных элементов интерфейса и описывают то, что нужно сделать;

5. Чек-лист менее эффективен для начинающих тестировщиков, лучше использовать тест-кейсы.

Тест-кейсы

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

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

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

Одна из самых популярных test management system – TestRail

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

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

Очень часто в профессиональном сообществе появляются вопросы «Что чаще всего спрашивают на собеседованиях?», и ответ на него максимально банальный – чаще всего на собеседованиях спрашивают, какие девайсы тестировщик возьмет себе для тестирования приложения.