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

Например, при подготовке самолета к посадке, командир воздушного судна начинает зачитывать чек-лист:

– Шасси выпущены.

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

– Посадочные огни включены.

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

– Закрылки выпущены…

Один читает, второй проверяет. Формального подхода здесь быть не должно.

Чек-лист по эксплуатации самолета

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

В IT чаще всего цена ошибки куда ниже, но и здесь они могут стоит компании огромных денег и ресурсов, поэтому важно помнить главное правило – цена ошибки тем ниже, чем раньше она была обнаружена. Это значит, что баг, найденный до релиза, можно исправить очень дешево, а вот если баг, особенно критический, попадет на пользователей, то потери компании возрастают в разы. В этом мы убедились и на примере истории с шаттлом – если бы тестирование выявило фатальные проблемы до старта, их исправление вышло бы несоизмеримо дешевле, чем в итоге составили общие людские и материальные потери NASA.

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

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

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

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

Чек-листы

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

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

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

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