проще воспроизвести баг. Особенно, если баг сложно описать словами. Добавление скриншотов или коротких видео поможет избежать недопонимания. Только не забывайте, что визуальные материалы должны быть релевантными и понятными.
Составление тестовой документации
Тестовой документацией называется набор проверок, регулярно исполняемых в ходе релизного цикла. Если вы когда-либо интересовались авиацией, здесь довольно много аналогий. Если рейс – это релиз, то авиаконструкторы – это разработчики, пассажиры – пользователи, то экипаж воздушного судна – это тестирование, релиз-менеджмент и поддержка пользователей. Перед самым взлетом вы можете слышать, как по бортовой связи старший бортпроводник передает «внимание бортпроводникам – двери в положение armed, cross-check». Экипаж блокирует двери самолета и перепроверяет друг друга. Это всего лишь маленький фрагмент предполетных проверок, которые проходит экипаж.
Управление воздушным судном требует безоговорочного выполнения всех инструкций для сохранения всех пассажиров и членов экипажа, которые находятся на борту самолета. На каждый этап полета разработаны чек-листы, которые экипаж обязан зачитывать каждый полет.
Что из себя представляет чек-лист? Это перечень требуемых конфигураций самолета, для безошибочного выполнения полета. Пилоты – это, в первую очередь, люди. С каждым новым полетом все действия начинают выполняться «на автомате», но может случиться непоправимое, если, например, при посадке забудут выпустить шасси… Для того, чтобы это не допустить, и были разработаны чек-листы.
Например, при подготовке самолета к посадке, командир воздушного судна начинает зачитывать чек-лист:
– Шасси выпущены.
Второй пилот проверяет, запущены ли шасси. В случае утвердительного ответа КВС зачитывает следующий пункт.
– Посадочные огни включены.
Второй пилот проверяет или включает посадочные огни, если их вдруг забыли включить.
– Закрылки выпущены…
Один читает, второй проверяет. Формального подхода здесь быть не должно.
Чек-лист по эксплуатации самолета
Мы сделали такое долгое отступление, потому что в авиации куда проще понять, какова цена ошибки, мы видели с вами это достаточно много раз, хотя относительно ежедневно выполняемых рейсов вероятность авиакатастрофы минимальна как раз благодаря различным проверкам.
В IT чаще всего цена ошибки куда ниже, но и здесь они могут стоит компании огромных денег и ресурсов, поэтому важно помнить главное правило – цена ошибки тем ниже, чем раньше она была обнаружена. Это значит, что баг, найденный до релиза, можно исправить очень дешево, а вот если баг, особенно критический, попадет на пользователей, то потери компании возрастают в разы. В этом мы убедились и на примере истории с шаттлом – если бы тестирование выявило фатальные проблемы до старта,
