Проверьте то, что вы летите, то, что вы испытываете. [Принцип НАСА]

Question

Я просто наткнулся на принцип, который не могу понять.

Имеет ли «Испытывать то, что вы летите, летать, то, что вы проверяете» означает, что вы должны развиваться и проверить на реальную вещь все время ?

Думая об этом, заставь меня задуматься

1. Должны ли мы заранее подготовиться к условиям производства?
2. Должны ли мы запустить систему в первый день? (может не сообщать конечным пользователям)

Например,

1. Инструменты сборки, обеспечивающие получение журналов ошибок.
2. Убедитесь, что журналы ошибок могут быть проанализированы (инструменты статистики и / или использование хорошо Дизайн лог-уровня )
3. Убедитесь, что мы храним изменения, внесенные в систему. История изменений.
4. Убедитесь, что у нас есть короткий цикл обновления в случае ошибок.

Есть еще примеры? Это обеспечит низкий риск запуска новой системы?

Я немного растерялся. Вот и все.

_{(источник: nasa.gov )}

Answer 1

Это означает, что если вы не проверяете в точности то, что планируете запустить, вы не знаете, как будет вести себя делать запуск.

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

Кроме того, это означает, что к моменту запуска ваши внутренние потребности заставят вас определиться с необходимыми инструментами поддержки (ведение журнала и т. Д.).

Answer 2

Мантра НАСА сформулирована немного по-другому :

«Проверяй, как летишь, и летай, когда проверяешь»

С точки зрения программного обеспечения, я рассматриваю это как

• Выполнить тесты при максимально приближенном моделировании производственной среды
• Если эти тесты пройдены, вы можете развернуть эту тестовую статью в среде реального времени и использовать этот компонент только так, как вы тестировали

Answer 3

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

Другая мантра звучала так: «Мы не дома, мистер Кокап», что было смехом, учитывая, что он, похоже, поселился на постоянной основе.

Answer 4

Примером TWYF ​​было бы убедиться, что функциональное тестирование выполняется на конфигурации выпуска, а не (только) на конфигурации отладки - или как бы вы ни назвали эти вещи на своем сайте. Если единственными различиями между Release и Debug являются проверка утверждений или дополнительная запись в журнал, вы все равно не можете быть уверены, что программное обеспечение, протестированное в Debug, работает в Release из-за чего-то вроде проблемы с синхронизацией.

FWYT означает, что когда вы удовлетворены качеством кандидата на сборку релиза, вы отправляете сборку , вместо того, чтобы делать нового «мастера производства» и надеетесь, что конфигурация двух сборок была то же самое.

Answer 5

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

(По крайней мере, это было для Хаббла.)