Como desarrollador de software, ¿alguna vez has sido culpable de ‘jugar’ las pruebas de software?

No, nunca he “probado” las pruebas de software. (Eso anularía el propósito de las pruebas). Cuando las pruebas han estado involucradas, y vi la oportunidad de más pruebas, escribiría y / o recomendaría algunas.

Hay cosas que me he metido debajo del cable sin pruebas, pero solo cosas inocuas.

Por ejemplo :
Una vez cometí una clase C # que seleccionaría aleatoriamente una cadena con un mensaje de error para agregar al texto de los archivos de registro. Todos los resultados fueron citas de error relacionadas con la tecnología de una variedad de fuentes. Fue una especie de diversión, durante una tarde de beber, relajarme leyendo a través de los archivos de registro para descubrir por qué algo no funcionaba durante las pruebas y, confié el código y comencé a importar y agregar regularmente resultados de esa clase a mensajes de error de código de producción y registro.

Nadie se dio cuenta por un tiempo, y luego un día alguien se echó a reír. No recuerdo qué fue, pero … aparentemente captó una de las citas, y tenía un significado adecuado para el mensaje de error. ( Aunque cualquier cita que se haya agregado se seleccionó al azar, finalmente alguien notó lo que había hecho, habiendo tenido el efecto deseado para entretener ) .

Oh seguro

Pero para mí nunca se trata del próximo ciclo de pruebas. Se trata de la próxima versión.

Soy un gran admirador de “no tengas miedo de romper mierda”.

Las pruebas de regresión de software están ahí por una razón. Te dicen si has roto la mierda.

Si siempre se esfuerza por alcanzar la perfección para que nada se rompa, las pruebas de regresión son inútiles. Si nunca falla, ¿es porque eres perfecto o porque la prueba no es lo suficientemente buena? Obviamente, sin embargo, las pruebas de regresión son útiles. Porque incluso los desarrolladores más bien intencionados ocasionalmente rompen mierda.

Y tratar de golpearlos en la cabeza y regañarlos con gorras de tonto y anuncios de altavoces dirigidos a la vergüenza no hará nada más que frenar su entusiasmo.

Y adivina qué, a veces la mierda rota ni siquiera es tu software. A veces pasas meses persiguiendo un problema solo para descubrir que alguien en otro lugar ha roto una mierda al estilo “silencioso pero mortal”. Desarrollador integrado lucha contra elusivos problemas de corrupción de FFS | EE Times

Y adivina qué, a veces la mierda rota ni siquiera es software. A veces pasas meses persiguiendo un problema solo para descubrir que alguien en otro lugar ha roto la mierda al estilo “estos no son los droides que estás buscando”. La raíz de la causa raíz del sistema misterioso se restablece | EE Times

Entonces. ¡No tengas miedo de romper mierda! Es probable que de todos modos pases una buena parte de tu carrera persiguiendo mierda rota de otras personas. Con el objetivo de producir un software perfecto a la perfección, todo el tiempo perfecto es un objetivo inalcanzable para cualquier persona viva, humana o no.

Depende de lo que quieras decir.

¿Realmente juegas el sistema para escabullir código no probado por la puerta? Para mí, al menos, no, casi todo lo contrario. Si sé que el código se va a probar mucho, en un apuro, es más probable que sea vago allí. Es mucho mejor detectar problemas internos que hacer que un cliente llame al respecto.

¿Hay momentos en los que seguiré trabajando mientras se prueba otro código? Seguro. No siempre, porque es mucho trabajo coordinar las pruebas y el desarrollo en paralelo.

Conocí a algunos desarrolladores que no querían que descubrieran sus errores, pero nunca entendí realmente la motivación. La reparación del software después de su lanzamiento se vuelve bastante perjudicial y desperdicia mucha buena voluntad. Por eso es importante la coordinación. Hay momentos en los que debe adoptar un enfoque cuestionable, pero no mantener a todos informados es lo que lo convierte en una molestia en un desastre.

No estoy seguro de cómo responder esto. Si la pregunta es si revisé el código que sentí que no se probó lo suficiente (incluso cuando lo revisé), entonces la respuesta es sí.

Si realmente se trata de pruebas de juegos, entonces la respuesta es no.

De hecho, trato de ser muy explícito sobre cuándo estoy cortando esquinas. Iré a mi jefe y le diré: “Aquí hay una pieza que podría necesitar más atención, pero creo que esta otra cosa es más importante para trabajar en este momento. ¿Qué piensas?” A veces presento errores para mí mismo, así puedo recordar seguir el asunto más tarde. A menudo, esos errores se despriorizan explícitamente.

No tengo interés en jugar las pruebas. De hecho, uso las pruebas fallidas como una forma de lista de “tareas pendientes”: dicen exactamente lo que debe hacer para activar un error, por lo que son mejores que las notas. Mi software tiene un par de pruebas fallidas todo el tiempo. No estoy seguro de si así es como debería funcionar este proceso, pero así es como lo uso.