Тестовой документацией называется набор проверок, регулярно исполняемых в ходе релизного цикла. Если вы когда-либо интересовались авиацией, здесь довольно много аналогий. Если рейс – это релиз, то авиаконструкторы – это разработчики, пассажиры – пользователи, то экипаж воздушного судна – это тестирование, релиз-менеджмент и поддержка пользователей. Перед самым взлетом вы можете слышать, как по бортовой связи старший бортпроводник передает «внимание бортпроводникам – двери в положение armed, cross-check». Экипаж блокирует двери самолета и перепроверяет друг друга. Это всего лишь маленький фрагмент предполетных проверок, которые проходит экипаж.

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

Что из себя представляет чек-лист? Это перечень требуемых конфигураций самолета, для безошибочного выполнения полета. Пилоты – это, в первую очередь, люди. С каждым новым полетом все действия начинают выполняться «на автомате», но может случиться непоправимое, если, например, при посадке забудут выпустить шасси… Для того, чтобы это не допустить, и были разработаны чек-листы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чек-листы

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