Pruebe lo que vuela, vuele lo que prueba. [Principio de NASA]

Question

Acabo de tropezar con un principio que no puedo entender.

¿Se "Prueba de lo que vuela, vuela lo que se prueba" quiere decir que usted debe desarrollar y comprueban la cosa real todo el tiempo?

Pensando en esto, que me pregunte

1. ¿Hay que prepararse para las condiciones de producción de antemano?
2. ¿Deberíamos lanzar el sistema el primer día? (Puede ser no informar a los usuarios finales)

Por ejemplo,

1. herramientas de construcción para asegurar registros de errores pueden ser recuperados.
2. Asegurar registros de errores pueden ser analizados (herramientas estadísticas y/o el uso de buena Log Level Design)
3. asegurar almacenamos los cambios realizados en el sistema. Historial de cambios
4. Aseguramos de tener un breve ciclo de actualización en caso de errores.

¿Hay más ejemplos? Eso asegurará un lanzamiento de bajo riesgo de un nuevo sistema?

Estoy un poco confundido. Eso es todo.

Nasa http://ecsv.gsfc.nasa.gov/ecsv_emd/GIFS/nasa_logo.gif

Answer 1

Mi último proyecto tenía el lema "Vendemos teléfonos, no simuladores", para recordar a fondo que siempre debemos probar nuestro código en el hardware de destino.En realidad, solo los codificadores que disfrutaron ensuciarse las manos con el hardware en realidad harían esto y las versiones de producción diaria invariablemente fallarían la mitad del tiempo. A veces, esto podría retrasar todo el proyecto mientras los probadores de producción intentaban llegar al fondo del problema.

El otro mantra era "no estamos en casa del Sr. Cockup", lo cual fue una risa, dado que parecía haber tomado la residencia permanente.

Answer 2

Esto significa que si usted no prueba exactamente lo que va a poner en marcha, uno no sabe cómo lo que hace lanzamiento se comportará.

Un principio similar también se expresa como "dogfooding" o "comer su propio dogfood". Suponiendo que su producto es algo que la gente de su empresa usaría, hágalos usar su producto mucho antes de lanzarlo. Es probable que sean una fuente mucho mejor de errores de usabilidad, errores de corrupción de datos, etc. que un equipo de control de calidad que tiene tareas muy específicas y podría no llegar a todos los casos de esquina que hacen los usuarios reales.

Además, significa que en el momento de su lanzamiento, sus necesidades internas le habrán forzado a determinar qué herramientas de soporte necesita (registro, etc.).

Answer 3

Un ejemplo de TWYF ​​sería asegurarse de que las pruebas funcionales se realicen en la configuración de la Versión, no (solo) la configuración de Depuración, o lo que sea que elija para llamar esas cosas en su sitio. Si las únicas diferencias entre Release y Debug son la verificación de afirmación o el registro adicional, aún no puede estar seguro de que el software probado en Debug funcione en Release, debido a algo así como un problema de tiempo.

FWYT significa que cuando usted está satisfecho con la calidad de una versión candidata de construcción, que barco que construir, en lugar de hacer un nuevo "maestro de producción" y con la esperanza de que la configuración de los dos construye era el mismo.

Answer 4

Pensé que el lema de la NASA era. No pruebe lo que vuela, pero documente el procedimiento de prueba y pruebe que los documentos coinciden con el procedimiento.
Y cuando la cantidad de documentos de prueba es mayor que el peso del vehículo, está listo para volar.

(al menos lo era para el Hubble.)

Answer 5

El mantra de la NASA es wordedslightly differently:

"Prueba como volar, y volar mientras pone a prueba"

Desde una perspectiva del software, trato esto como

• Ejecute pruebas en como c perder una simulación del entorno de producción como sea posible
• Si se superan estas pruebas, entonces se puede desplegar ese artículo de prueba en el entorno en vivo, y sólo funcionará ese componente en la forma en que usted probó