¿Los programadores son malos probadores?

Sé que esto se parece mucho a otras preguntas que ya se han hecho, pero en realidad es un poco diferente. En general, se considera que los programadores no son buenos para realizar la función de probar una aplicación. Por ejemplo:

Joel on Software - Cinco razones principales (incorrectas) por las que no tiene probadores (énfasis mío)

Ni siquiera piense en tratar de decirles a los graduados universitarios de CS que pueden venir a trabajar para usted, pero "todos tienen que pasar un tiempo en el control de calidad por un tiempo antes de pasar al código". He visto mucho de esto. Los programadores no son buenos evaluadores , y perderás a un buen programador, que es mucho más difícil de reemplazar.

Y en esta pregunta , una de las respuestas más populares dice (nuevamente, mi énfasis):

Los desarrolladores pueden ser probadores, pero no deberían serlo. Los desarrolladores tienden a evitar involuntariamente / inconscientemente usar la aplicación de una manera que pueda romperla. Eso es porque lo escribieron y lo prueban principalmente en la forma en que debería usarse.

¿Entonces la pregunta es si los programadores son malos en las pruebas? ¿Qué evidencia o argumentos hay para apoyar esta conclusión? ¿Los programadores solo son malos para probar su propio código? ¿Hay alguna evidencia que sugiera que los programadores son realmente buenos en las pruebas?

¿Qué quiero decir con "prueba"? No me refiero a pruebas unitarias ni a nada que se considere parte de la metodología utilizada por el equipo de software para escribir software. Me refiero a algún tipo de método de garantía de calidad que se utiliza después de que el código se haya creado y desplegado en lo que ese equipo de software llamaría el "entorno de prueba".

La pregunta parece ser específicamente sobre Pruebas del sistema , así que a eso me refiero a lo largo de esta respuesta.

Creo que hay que hacer una distinción importante entre ser una mala persona para elegir realizar las pruebas y ser realmente malo en las pruebas.

Por qué los programadores son malos en las pruebas:

• Si ha escrito el código, (debería) haber pensado en todas las formas posibles en que las cosas podrían salir mal, y haber tratado con ellas.
• Si encontrar un error particularmente molesto significa que tienes que ir y solucionarlo, en una base de código de la que podrías estar harto, eso no ayudará a tu motivación.

Por qué los programadores son buenos en las pruebas:

• Los programadores tienden a ser pensadores lógicos y buenos para trabajar de manera sistemática.
• Los programadores experimentados serán muy buenos para identificar rápidamente los casos límite y, por lo tanto, elaborar pruebas útiles. (Si hay un proceso de prueba formalizado, la mayoría de estos casos ya deberían haber sido identificados y probados antes de las pruebas de los sistemas).
• Los programadores son bastante buenos para asegurarse de que toda la información útil vaya a un informe de error.

Por qué los programadores son malos evaluadores:

• Los programadores son más caros que los probadores (en la gran mayoría de los casos).
• La mentalidad es fundamentalmente diferente: "Construir un producto (funcional)" frente a "Esto no va a salir por la puerta con ningún error (desconocido)".
• Los probadores suelen ser más eficientes, es decir, realizar más pruebas en el mismo período de tiempo.
• Los programadores se especializan en programación. Los profesionales de control de calidad se especializan en pruebas.

Creo que los programadores son malos probando su propio código .

Nos gusta creer que nuestro código funciona perfectamente de acuerdo con los requisitos y probarlo como tal. En mi lugar, probamos nuestro propio código, luego probamos el código de los demás antes de lanzarlo al ciclo de prueba real y se detectaron muchos más errores de esa manera que simplemente probando nuestro propio código

Los programadores son definitivamente las personas adecuadas para probar algunas partes del sistema, en lugares donde son los únicos que podrían hacerlo de manera efectiva.

Un lugar en el que los programadores tienden a ser muy malos en las pruebas es todo el bit "usa la interfaz de usuario como un usuario normal": no son usuarios normales y no se comportan como ellos. Por ejemplo:

• Los programadores tienden a ser muy buenos para obtener entradas de texto correctas. Un problema bastante común que veo es espacios iniciales o especialmente finales. La mayoría de la gente no los parece, pero los buenos programadores son probablemente religiosos acerca de hacer que sus cadenas sean la cadena correcta sin espacios extraños.
• Los programadores tienden a ser tecladistas, aprovechando las pestañas y otros atajos para acelerar el trabajo. Los usuarios normales tienden a agarrar el mouse entre los campos.
• Los programadores tienden a comprender lo que el sistema les dice en lugar de ignorar los mensajes de error y simplemente hacer clic en Aceptar.

Entonces, los usuarios normales hacen muchas cosas que los programadores no hacen. No puedes confiar completamente en el equipo de desarrollo para UAT.

A nivel técnico (pruebas unitarias, pruebas de integración, pruebas de regresión), los programadores son probablemente las únicas personas calificadas para ser probadores, porque este tipo de pruebas son automatizables y, por lo tanto, deben automatizarse, lo cual es algo que requiere programación.

Pero no creo que sea de eso de lo que estás hablando, y estoy bastante seguro de que tampoco es lo que Joel Spolsky quiere decir: es la parte que queda, la prueba manual práctica real: convertir un documento de requisitos y especificaciones funcionales en un script de prueba y luego ejecutando meticulosamente este script contra el producto terminado.

Ser un buen probador requiere cualidades que son en su mayoría ortogonales a las que hacen un buen programador. Hay un poco de superposición: debe poder pensar analíticamente, necesita cierta afinidad con las computadoras en general, pero aparte de eso, las habilidades de un probador son muy diferentes. Eso en sí mismo no significa que pueda tener ambos conjuntos de habilidades, y de hecho, es probable que algunas personas lo tengan. Sin embargo, para ser un programador realmente bueno se requiere cierta pereza (el deseo de automatizar sus tareas), mientras que un probador realmente bueno necesita persistencia (verifique las inconsistencias en los tres mil campos de formulario) y, como consecuencia, incluso aquellos programadores que tiene lo que se necesita para ser un probador, por lo general aborrece la idea.

Y luego está el sesgo selectivo: un programador que ya está involucrado en un proyecto, aunque solo sea marginalmente, ya tiene algún conocimiento interno sobre la base de código, y tendrá dificultades para abordarlo con la mente en blanco, desde la perspectiva del usuario final . Ni siquiera tiene que ser explícito, como en "Sé que este botón funciona, así que solo notaré 'pasar'"; puede ser mucho más sutil, y esos efectos sutiles pueden llevar a que se pierdan casos críticos críticos en las pruebas.

Desde mi experiencia, sí, los programadores son malos evaluadores. Demasiado a menudo he visto a otros y a mí mismo decir "¡Eh, pero lo probé antes de registrarme!" cuando se enfrenta a un probador que reproduce el error delante de usted.

¿Por qué? Bueno, no estoy seguro de por qué, pero tal vez es porque queremos ver las cosas funcionando. O simplemente queremos dejar de probar esta o aquella característica ya.

De todos modos, las pruebas no son una habilidad que aprendimos y no trabajamos como programadores porque somos buenos para romper funciones. Además, es posible que no tengamos idea de cómo hacer una planificación de prueba adecuada o de todas las demás cosas que hace QA. Ya no estamos calificados para hacer el trabajo de un probador que un probador está calificado para implementar su nueva tubería de renderizado 3D.

Como en la pregunta, las pruebas no significan nada automatizado, sino realmente pruebas mediante el uso del programa.

Hay varios niveles de prueba. La prueba de "bajo nivel" puede y debe ser realizada por los desarrolladores. Creo que en la unidad de prueba.

Por otro lado, las pruebas de "alto nivel" son totalmente otra cosa. En general, creo que los desarrolladores son malos probadores, no porque pierdan habilidades, sino porque es muy difícil cambiar la forma de pensar y la forma de trabajar en poco tiempo.

Solía ​​probar mis códigos lo más rápido posible, pero después de al menos 10 minutos realizados por un probador, surge algo para considerar un error o una mejora. Esto significa que probar algo que creas es un trabajo difícil. Usted sabe dónde hacer clic, sabe cuándo hacer clic, conoce la lógica de negocios, probablemente sabe cómo se conservan los datos. Eres un dios que nunca caerás.

¿A qué tipo de prueba te refieres? Si te refieres a pruebas exhaustivas exhaustivas, entonces podría ver algunas razones para decir que sí, aunque sospecharía que la mayoría de las personas serían pobres en esta categoría si se consideran todas las combinaciones posibles de entradas como un requisito para tales pruebas.

Puedo reconocer que el desarrollador que diseña el software puede tener visión de túnel cuando se trata de lo que el código debe manejar e ignorar algunos posibles casos límite que simplemente no se han considerado. Por ejemplo, si construyo un formulario web que toma un número, n, y luego imprime de 1 a n en la pantalla, puedo pasar por alto algunos casos especiales como si no se ingresa nada o algo que no es un número natural como e o pi . Lo que se supone que debe hacer el programa en estos casos puede ser cuestionable.

Test Driven Development sería un ejemplo de una metodología de desarrollo que pone las pruebas en una luz diferente que puede dar otra visión aquí.

Los programadores son pruebas que definen bien cuando definen las pruebas antes de escribir el código. Con la práctica, se ponen aún mejor.

Sin embargo, al definir las pruebas para el código que han escrito, no les va muy bien. Tendrán los mismos puntos ciegos en las pruebas que tenían al escribir el código.

Usar programadores para hacer pruebas manuales es una tontería. Las pruebas manuales son bastante tontas por sí mismas; hacer que los programadores lo hagan es extremadamente tonto. Es costoso y ahuyenta a los programadores competentes.

Un tipo de prueba en el que particularmente he visto fallar los desarrolladores es probar si se ha cumplido el requisito. Lo que los desarrolladores piensan que significa algo en un requisito y lo que los evaluadores piensan que significa a menudo son dos cosas completamente diferentes.

Puedo pensar en uno recientemente donde se le pidió al desarrollador que hiciera una exportación delta y el desarrollador pensó que eso significaba obtener registros que no se habían enviado una vez y los evaluadores pensaron que significaba obtener nuevos registros y cualquier cambio. Tuvieron que volver al cliente para averiguar quién estaba en lo correcto. Lo revisé en código e hice la misma suposición que el desarrollador hizo sobre el requisito. Porque lógicamente si quisieras incluir actualizaciones, las hubieras mencionado. Y generalmente soy bueno para detectar esas cosas ambiguas porque solía estar en el lado del usuario.

Por lo tanto, otros desarrolladores que realizan las pruebas tenderían a hacer muchas de las mismas suposiciones porque también harían ciertas suposiciones como "bueno, habrían tenido más detalles si se refieren a X vice Y porque hay muchos detalles que responder antes de que yo pueda hacer Pero los redactores de requisitos no piensan de esa manera. Por lo tanto, alguien que piense más como redactores de requisitos debe probar las suposiciones del desarrollador y alguien que no sea desarrollador es la mejor persona para ver si hay un problema.