посередине.
Попробуйте написать чек-лист на страничку отправки денег, где есть два поля ввода – у первого написано «Сумма оплаты – до 1000 рублей», а над вторым «Номер карты (строго 16 цифр)». Кроме того, на странице есть кнопка Отправить. С учетом различных тестовых данных и особенностями платформы у вас может получиться 30—50 пунктов.
Пункты чек-листа должны трактоваться однозначно. Предположим, у нас есть функция аудио/видеозвонков, и мы пишем чек-лист, чтобы покрыть ее проверками. Мы, конечно, можем написать один пункт «Включение микрофона», но лучше будет его разделить на два и проверять отдельно включение микрофона в аудиозвонке и в видеозвонке, так как использоваться будут разные микрофоны.
Один пункт – одна проверка (или атомарность проверок). Пункт «Позвонить на другой аккаунт и отправить сообщение» нужно разделить на большое множество проверок, иначе этот пункт чаще всего будет красный, и когда он будет красный, вам и разработке потребуется время, чтобы локализовать проблему.
Преимущества:
1. Чек-лист легко читается;
2. По чек-листу быстро тестировать: в тест-кейсе нужно отмечать статус каждого шага, в то время как в чек-листе достаточно одной строчки;
3. Чек-лист – источник результатов для отчёта: можно быстро посчитать сколько проверок выполнено, в каком они статусе, узнать количество открытых репортов;
4. В любой момент можно узнать статус – всегда есть то, что нужно проверить в первую очередь, можно упорядочить пункты чек-листа или изменить порядок, когда это требуется.
Недостатки:
1. Неопределенность тестового набора: каждый тестировщик выполняет пункт чек-листа по-своему;
2. Неопределенность тестовых данных;
3. Недостаточность детализации;
4. Сложнее обучить начинающих сотрудников: пункты чек-листа чаще абстрагируются от конкретных элементов интерфейса и описывают то, что нужно сделать;
5. Чек-лист менее эффективен для начинающих тестировщиков, лучше использовать тест-кейсы.
Тест-кейсы
Тест-кейс – это форма записи проверки, которую проводит тестировщик. По сути, это алгоритм действий, по которому предполагается тестировать уже написанную программу. В нём подробно прописаны шаги, которые нужно сделать для подготовки к тесту, сама проверка и ожидаемый результат. Почти как баг-репорт, но нет фактического результата – мы его вписываем каждый раз, когда проводим проверку по тест-кейсу.
Тестировщик выполняет тест-кейс последовательно, шаг за шагом. Если фактический результат соответствует ожидаемому – всё хорошо. Если нет, тестировщик анализирует, что произошло. Это может быть ошибка в программе, в тест-кейсе из-за его неактуальности или в тестовом стенде. Если дело в программе, инженер составляет отчёт об ошибке и отправляет его разработчикам.
