Para mí, Idiot Proofing solo significa asegurarse de que el usuario no pueda romper una pieza de software incluso si lo intenta. Por ejemplo, si un valor se lee desde un cuadro de texto y se convierte en un doble, si el software subyacente es a prueba de idiotas, no se romperá si el usuario escribe un valor no doble.

Recientemente escribí un cronograma de desarrollo y uno de los elementos se llamaba "UI a prueba de idiotas". Las personas con las que estoy construyendo este software fingieron en broma el término, pero puedo ver dónde este término realmente molestaría a las personas.

¿Cuál es una mejor manera de decir esto?

Si está incluyendo "UI a prueba de idiotas" como un elemento del programa, entonces solo está tratando de agregar calidad a su software. Cualquier sistema bien diseñado validará sus entradas y brindará una guía clara a los usuarios como algo natural, no es algo que se incluya en el cronograma como un elemento discreto (que luego está sujeto a eliminación cuando llega el inevitable crujido).

Alternativamente, si tiene que ser un elemento discreto (sé cómo piensan algunas organizaciones sobre la programación), la "IU a prueba de idiotas" debe cambiarse a "Biblioteca de validación de entrada" y pasar al principio del cronograma.

Validación de entrada de usuario. Pensé que sería un término profesional. Sin embargo, no veo nada malo con las pruebas idiotas si se usan en documentos internos.

Endurecerse es una buena palabra. Si alguien pregunta, dígales que el primer paso del software generalmente está escrito para escenarios ideales, y al igual que las herramientas de acero, el software debe ser "reforzado" para el uso diario de los clientes reales.

Robustificación es otra buena palabra para esto: está haciendo que el código sea robusto frente a los tipos de desafíos que los clientes reales enfrentarán.

Ambas palabras suenan geniales e industriales, no culpe a los usuarios ni a los programadores, y transmita el punto.

Por cierto, aquí está la vieja mascota de Metrowerks, Arnold, el tipo que solía ayudarnos a los programadores de Mac a endurecer y fortalecer nuestro código con un horno de tratamiento térmico, una fragua y un yunque y un pequeño martillo:

Programación defensiva

Es lo que me enseñaron. Cuando teníamos que cortar nuestros propios pedazos de madera.

Si quieres ser PC, llámalo programación "anticipatoria".

Cuando estaba aprendiendo, lo llamamos a prueba de balas .

Sin embargo, la mayoría de los otros eufemismos que he leído también se aplican.

¿Qué tal un sistema o interfaz de usuario "tolerante a fallas"

La "prueba de idiotas" debe consistir en ambos

• diseñando la interfaz de usuario para que sea fácil de usar y lleve al usuario a ingresar datos de la manera que los programadores esperan, y

• probar la interfaz de usuario para determinar si la interfaz puede romperse al ingresar valores de datos inesperados.

Ambos pasos pueden aparecer razonablemente en el cronograma de desarrollo donde el diseño es examinado por un experto en experiencia del usuario y donde el probador verifica el código entregado para garantizar que los datos no válidos se manejen correctamente (para lo que sea que "correctamente" signifique para su aplicación).

La prueba de idiotas implica mucho más que una simple validación de entrada. Ni siquiera incluiría tal cosa en su definición.

La validación de entrada es un proceso en el que desinfecta y valida los datos del usuario para eliminar valores ilegales / sin sentido. Esto siempre debe hacerse con cualquier información que provenga de fuera de su programa para eliminar lo obvio y protegerse de los ataques (por ejemplo, ataques de inyección SQL).

Consideraría que la prueba de idiotas es un conjunto de lógica para evitar que el usuario accidentalmente se cause un gran daño a sí mismo por otros medios legales.

Por ejemplo, rmrechazar el comando rm -rf /y cerrar variantes no tiene nada que ver con la validación o la corrección. Es un comando perfectamente válido. Desafortunadamente, es un comando que podría y puede borrar todos sus datos de todos sus discos en Unix / Linux. La prueba idiota de esto rechazaría este comando y sugeriría rm -rf --i-really-mean-this /, o si está en modo interactivo, que el usuario escriba una respuesta afirmativa después de una advertencia.

Cualquier cosa que sea destructiva para el sistema debe ser a prueba de idiotas. Cualquier cosa que pueda causar vergüenza potencial también podría ser un candidato (por ejemplo, "¿está seguro de que desea enviar este correo electrónico sin un archivo adjunto a pesar de que mencionó uno en su texto?" Y "¿Está seguro de que desea enviar este correo electrónico al toda la empresa? ")

La prueba de idiotas es una colaboración entre QA (tratando de ser el mejor idiota) y Desarrollo (tratando de anticipar todos estos escenarios y diseñar a su alrededor).

En cuanto a un sinónimo más amigable , ¿puedo sugerir "análisis destructivo de ruta de código" o "permitir comentarios de los usuarios para operaciones críticas". Como sea que lo llames, deberías comenzarlo lo antes posible en el proceso de diseño.

"Sanity Checking" tiende a funcionar bastante bien con bastante frecuencia ...

Llámelo "agregar Poka-yugos a la interfaz de usuario". http://en.wikipedia.org/wiki/Poka_yoke

"Manejo de errores" o "validación de entrada" serían otros términos que usaría para lo que usted describe. Bulletproof sería otro término que podría ver que se usa en algunos círculos, ya que la idea aquí es hacer que el software sea lo suficientemente robusto como para manejar casi cualquier cosa. Rock solid sería otra frase de argot que podría imaginar a alguien que quiera usar aquí también.

"Prueba de peor escenario". Porque, como desarrolladores, todos sabemos que si se puede hacer, se hará . Por lo tanto, solo tiene que estar preparado para manejar el peor de los casos con su software.

Las medidas de seguridad no son solo una forma de proteger a los usuarios contra las invasiones cibernéticas externas, sino también contra ellos mismos. Vivimos en un mundo imperfecto con usuarios imperfectos.

Chapado en oro es el término cortés (y muy positivo) que utilizo cuando hablo de mejorar la experiencia de la interfaz de usuario final de alguna manera (GUI u otra).

La prueba de idiotas, como usted dice, es la mayor parte de ese proceso, junto con las mejoras de diseño o flujo de trabajo (piense en el reconocimiento de comentarios del usuario final).

La idea aquí es que puede usar ese término libremente en el entorno de trabajo y es visto como un proceso valioso (una vez completado) tanto por la administración como por los usuarios, a pesar de que puede llevar algo de tiempo (y por lo tanto generalmente cuesta algo de dinero).

muchos otros términos relacionados con este proceso (a menudo al final del ciclo) hacen que suene así:

• implica que los usuarios (a menudo la administración ;-) son tontos
• es difícil de lograr
• tiene poco patrimonio neto

Al asociar el oro con el proceso (el metal generalmente equivale a "valor" en lugar de "costo"), he visto que el proceso cambia de gasto a inversión en la mentalidad de algunos gerentes.

Es como decir abiertamente que hasta que esto se haga, esa pieza de acero torpe aún no es una joyería. Pero una vez que está plateado ... entonces es valioso.

La mayoría de las veces se usa en relación con los procesos de fabricación, pero creo que un muy buen ajuste es Poka-Yoke :

"[poka yo-ke] es un término japonés que significa" protección contra fallas "o" prueba de errores "

Originalmente se describió como baka-yugo, pero como esto significa "a prueba de tontos" (o "a prueba de idiotas") el nombre se cambió al poka-yugo más suave.

En términos más generales, el término puede referirse a cualquier restricción de configuración de comportamiento diseñada en un producto para evitar la operación incorrecta por parte del usuario ".

Un término común en las tiendas más grandes también es Garantía de calidad (QA) .

Es un término general, vago a propósito, que puede moldear según su propio significado específico dentro de su ciclo de lanzamiento.

Lo llamamos prueba humana. Todos somos idiotas