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

Таким образом, правильно написанная тестовая документация может убить сразу двух зайцев:

1. Сократить time to market – время от написанной документации до релиза функциональности на пользователей

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

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

Чек-листы

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

Чек-листы могут выполняться на разных уровнях. Можно написать чек-лист на компонент и проверять его каждый раз, когда его встраивают в новую страницу и видоизменяют, можно написать чек-лист на раздел приложения. При должной подробности чек-лист на компонент будет иметь 10—15 пунктов, чек-лист на раздел – до 1000. Зачастую нет смысла проходиться чек-листом по компонентам по отдельности, также не представляется возможным постоянно проверять раздел приложения (найдите человека, который согласится прогонять чек-лист на 1000 пунктов каждую неделю!), поэтому предлагаем использовать что-то посередине.

Попробуйте написать чек-лист на страничку отправки денег, где есть два поля ввода – у первого написано «Сумма оплаты – до 1000 рублей», а над вторым «Номер карты (строго 16 цифр)». Кроме того, на странице есть кнопка Отправить. С учетом различных тестовых данных и особенностями платформы у вас может получиться 30—50 пунктов.

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

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

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

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

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

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

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

Недостатки:

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

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

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

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

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

Тест-кейсы

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

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

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

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

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

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

Подбор девайсов для тестирования

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.