¿Los programadores son malos probadores?

36

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".

jhsowter
fuente
17
@jshowter Los programadores son peores cuando prueban su propio código, mientras que son brillantes cuando prueban el código de otros. Los probadores (buenos probadores) son ellos mismos programadores a su manera (ya que necesitan comprender la lógica de programación y su funcionalidad) con la excepción de que no escriben demasiado código. Creo que esto tiene más que ver con la psicología, ya que siempre dudo en encontrar dudas en mi propio trabajo, por muy malo que sea.
Ubermensch
66
@Ubermensch, no estoy de acuerdo con que los desarrolladores sean brillantes evaluadores del código de otros por defecto. Algunos desarrolladores lo son, debido a que han practicado las pruebas durante un tiempo. Requiere una mentalidad diferente y un tipo diferente de motivación también, lo cual no es del todo obvio para los desarrolladores en general. Muchos desarrolladores tienden a centrarse en la parte de codificación, y disfrutan más de ella, y pueden no apreciar o incluso darse cuenta de la importancia de otras actividades dentro del SDLC completo.
Péter Török
1
@jshowter Si buscas datos concretos / datos de investigación, no puedo encontrar uno. La mayor parte de la literatura se relaciona con el desarrollo ágil y no pudo encontrar uno que coincida con su caso particular. Puedes probar en Google Scholar o Scirus.
Ubermensch
3
¡No somos malos evaluadores! ¡Funcionó en mi PC! ;-)
Joris Timmermans
2
@MadKeithV ¡Ja! Este es mi avatar de JIRA (rastreador de problemas);)
yannis

Respuestas:

39

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.
vaughandroid
fuente
44
Tenga en cuenta que el pensamiento lógico de los programadores puede ser perjudicial para ser un buen probador. ¿Cuántas veces has visto a un programador reaccionar con "pero eso es imposible!" cuando se enfrenta a un error encontrado? Solo para descubrir que se habían perdido algo serio en su razonamiento que hizo que el error fuera "imposible".
Joris Timmermans
2
@CraigYoung: está claro que es un pensamiento lógico defectuoso, pero eso es muy común (los sistemas son complejos). La cuestión es que en las pruebas no debe utilizar el pensamiento lógico para eliminar las pruebas "innecesarias", y parece difícil para los desarrolladores evitar ese tipo de pensamiento.
Joris Timmermans
3
+1 Una respuesta excelente y equilibrada. También explica por qué la combinación entre la unidad automatizada y las pruebas de integración escritas por programadores junto con las pruebas de sistema realizadas por QA es la mejor combinación.
Danny Varod
1
+1 para "la mentalidad es fundamentalmente diferente". Estos son roles diferentes después de todo, con conjuntos de habilidades relacionadas (pero diferentes).
joshin4colours
3
@MadKeithV El pensamiento lógico es vital en las pruebas y también lo es eliminar las pruebas innecesarias. ¿Estás pensando en las pruebas de caja negra versus caja blanca? En las pruebas de caja negra, diseña pruebas de los requisitos sin conocimiento de la implementación. Para verificar suposiciones defectuosas, lógica errónea, etc. Los desarrolladores de IMHO son buenos en esto, siempre que no conozcan la implementación. En particular, si escribieron el código y cometieron errores, son inevitablemente propensos a cometer los mismos errores en las pruebas. Las pruebas del sistema deben ser pruebas de caja negra.
MarkJ
19

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

Amy
fuente
1
Mis dos centavos. Los desarrolladores generalmente prueban solo los últimos cambios, la última corrección, la última característica, lo hicieron (de lo que hice) y, en algunos casos, ellos (nosotros) estamos un poco ciegos o perezosos para probar otra característica.
Andrea Girardi
11

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.

Wyatt Barnett
fuente
3
Ejemplo adicional para su primer punto: nuestros usuarios tienden a copiar desde MS Word, que inserta cosas extrañas como em-dash y comillas inteligentes, que a veces rompen incluso las bibliotecas que no escribimos. Ninguno de nosotros está siquiera en Word, por lo que el caso de uso apenas se nos pasa por la cabeza, y mucho menos se hace una prueba.
Izkata
1

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.

tdammers
fuente
1

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.

Morothar
fuente
1

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.

AngeloBad
fuente
0

¿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í.

JB King
fuente
Gracias por preguntar eso. Actualicé mi pregunta para decir lo que considero que es la prueba. Básicamente, las pruebas son cosas que suceden después de que el software se ha construido e implementado, no durante el desarrollo (como las pruebas unitarias) o como parte de una metodología de desarrollo (como la revisión por pares).
jhsowter
0

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.

Kevin Cline
fuente
Por mucho que defiendo la escritura de pruebas de unidad e integración, no veo cómo TDD (o escribir las pruebas primero) soluciona esto. Si escribe los principales escenarios de éxito antes del código, probablemente no encontrará la mayoría de los errores. Tienes que pensar en todas las cosas que pueden salir mal. Tener un código escrito, puede ayudarlo a encontrar algunos de estos, ya que puede repasar las ramas y los métodos que llama para ver qué puede romperlos.
Danny Varod
Además, muchos de los errores que descubrí que los desarrolladores habían perdido estaban relacionados con el orden de las llamadas API. Algo que la mayoría de las pruebas unitarias no cubren, especialmente si no sabe cómo se podrían llamar otros métodos que puedan afectar al que está probando (y que aún no se ha implementado).
Danny Varod
@Danny: con TDD, solo debes escribir ramas o métodos en respuesta a una prueba fallida, y solo escribes el código necesario para aprobar la prueba fallida.
Kevin Cline
Conozco la metodología de TDD, simplemente no estoy de acuerdo con las conclusiones.
Danny Varod
0

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.

HLGEM
fuente