Проверьте то, что вы летите, то, что вы испытываете. [Принцип НАСА]
Я просто наткнулся на принцип, который не могу понять.
Означает ли "Испытай то, что ты летишь, лети, что ты проверяешь", что ты должен все время развиваться и проверять на реальные вещи?
Думая об этом, заставь меня задуматься
- Должны ли мы заранее подготовиться к условиям производства?
- Должны ли мы запустить систему в первый день? (может не сообщать конечным пользователям)
Например,
- Инструменты сборки, чтобы гарантировать, что журналы ошибок могут быть восстановлены.
- Убедитесь, что журналы ошибок могут быть проанализированы (инструменты статистики и / или использование хорошего дизайна уровня журнала)
- Убедитесь, что мы храним изменения, внесенные в систему. История изменений.
- Убедитесь, что у нас есть короткий цикл обновления в случае ошибок.
Есть еще примеры? Это обеспечит низкий риск запуска новой системы?
Я немного смущен. Это все.
5 ответов
В моем последнем проекте была мантра "Мы продаем телефоны, а не симуляторы", чтобы понять, что мы всегда должны тестировать наш код на целевом оборудовании. На самом деле это могли делать только те программисты, которым нравилось запачкать руки на аппаратном обеспечении, и ежедневные производственные сборки неизменно терпели неудачу примерно в половине случаев. Иногда это задерживало весь проект, в то время как тестировщики работали над решением проблемы.
Другая мантра звучала так: "Мы не дома, мистер Кокуп", что было смехом, учитывая, что он, похоже, поселился на постоянной основе.
Это означает, что если вы не проверяете, что именно вы планируете запустить, вы не знаете, как будет вести себя запуск.
Аналогичный принцип также выражается как "собачий корм" или "есть свой собачий корм". Предполагая, что ваш продукт - это то, что люди вашей компании будут использовать, заставьте его использовать ваш продукт задолго до того, как вы запустите его. Скорее всего, они будут гораздо лучшим источником ошибок юзабилити, искажений данных и т. Д., Чем команда QA, которая имеет очень специфические задачи и может не попасть во все ключевые случаи, которые делают реальные пользователи.
Кроме того, это означает, что к моменту запуска ваши внутренние потребности заставят вас решить, какие инструменты поддержки вам нужны (ведение журнала и т. Д.).
Примером TWYF было бы убедиться, что функциональное тестирование выполняется на конфигурации выпуска, а не (только) на конфигурации отладки - или как бы вы ни назвали эти вещи на своем сайте. Если единственными отличиями между Release и Debug являются проверка утверждений или дополнительная запись в журнал, вы все равно не можете быть уверены, что программное обеспечение, протестированное в Debug, работает в Release из-за какой-то проблемы с синхронизацией.
FWYT означает, что когда вы удовлетворены качеством кандидата на сборку релиза, вы отправляете эту сборку, а не выполняете новый "мастер-выпуск" и надеетесь, что конфигурация двух сборок была одинаковой.
Мантра НАСА сформулирована несколько иначе:
"Тестируй, как летишь, и летай, как проверяешь"
С точки зрения программного обеспечения, я отношусь к этому как
- Выполните тесты в максимально приближенном к моделированию производственной среде
- Если эти тесты пройдены, вы можете развернуть эту тестовую статью в реальной среде, и вы будете работать с этим компонентом только так, как вы тестировали
Я думал, что девиз Насы был. Не проверяйте то, что вы летите, но документируйте процедуру тестирования и проверяйте документы на соответствие процедуре.
А когда масса тестовых документов больше, чем масса автомобиля - он готов к полету.
(По крайней мере, это было для Хаббла.)