Programadores haciendo pruebas

Me pregunto qué tan típico es que los programadores cambien de opinión y realicen pruebas en el trabajo del otro. Suponga que el equipo quiere adoptar un enfoque de "responsabilidad compartida" para mover las tareas de ser formalizadas a su liberación.

1. ¿Es una buena idea que los programadores trabajen como prueba de software siempre que no escriban una función?

2. ¿Esto sucede a menudo?

3. ¿Hasta qué punto un programador puede "probar" su propio trabajo?

Incluso con TDD y pruebas unitarias, ¿no existe la necesidad de un aparato de prueba de software en el proceso de desarrollo?

1. Hacer que el programador pruebe sus características puede ser una mezcla. Por un lado, el programador puede estar "demasiado familiarizado" con el bloque de código y simplemente probar parámetros de tipo pasa / falla bien conocidos. Por otro lado, si ese programador que está "demasiado familiarizado" con su código es diligente en hacer que la función funcione, tendrá más conocimiento sobre casos marginales que podrían causar problemas, ya que conocen el funcionamiento interno de la función y las posibles lagunas. dentro de ella.

2. Creo que esto sucede la mayoría de las veces. Creo que la mayoría de las tiendas de programación están en equipos pequeños, o bajo mucha presión para hacer las cosas. Esto no les brinda el lujo de un QA / Tester dedicado en su grupo, por lo que todos tienen que sacar su parte. Todavía hay un buen número de tiendas de "vaqueros solitarios" donde cada desarrollador es esencialmente responsable del ciclo de vida completo de su aplicación. Ese es el caso para mí.

3. Volveré al número 1 por esto. Creo que un programador es capaz de probar su propio trabajo, fuera del modelo TDD, ya que tienen un conocimiento profundo de cómo funciona su función. Deben tener cuidado de "dar un paso atrás" y poder cubrir problemas específicos y amplios con el código (como "digitación gorda" en un campo de entrada de texto, ¿qué sucede?), Pero se puede hacer.

Los desarrolladores que prueban el código de los demás no deben hacerse en lugar de probar por un especialista en control de calidad enfocado, pero sería genial ademása prueba por un probador enfocado. Los desarrolladores son expertos en pensar cómo hacer que el producto funcione. Los probadores son las únicas personas en el equipo (BA, PM, desarrolladores, etc.) que se centran en descubrir cómo podría fallar el producto. Es una mentalidad muy diferente. Piensa en tu trabajo de "tiempo de inactividad", por ejemplo, cuando esbozas proyectos en tu cabeza mientras te duchas. ¿Piensas, "Oh, apuesto a que esta sería una buena manera de abordar esa característica!" o piensas, "¡Oye, debería ver si puedo hacer que ese código falle si hago ESTO!" El trabajo no solo ocurre en la oficina, y los desarrolladores probablemente no estarán trabajando en romper el código en su "tiempo libre". Los probadores también deben acumular una amplia variedad de conocimientos sobre herramientas y técnicas de prueba y experiencia para elegir entre ellos que los desarrolladores no tienen,

Al mismo tiempo, la experiencia interdisciplinaria es algo muy bueno, y siempre es beneficioso trabajar con el código de otro desarrollador. Hacer que los desarrolladores se esfuercen más en las pruebas antes de que una persona específica de control de calidad / pruebas revise el código probablemente dará como resultado un código de mejor calidad, lo que probablemente dará como resultado un cambio de prueba más rápido, una mejor cobertura de prueba e incluso puede reducir (pero no eliminar) la cantidad de probadores dedicados que se necesitan.

Si realmente tiene que hacer concesiones debido a la baja disponibilidad de personal o si el conjunto de habilidades para el control de calidad es excepcionalmente malo en el lugar donde se encuentra, esta configuración sería mejor que nada, pero el objetivo debería ser conseguir un probador real antes de que el equipo crezca demasiado.

Nunca he visto un mal método de prueba.

¿Deben los programadores probar su propio código? Si obviamente.

¿Deberían otras personas probar su código? Si obviamente.

¿La prueba de cobertura es una buena idea? Si.

¿Está bien probar Montecarlo? Si.

Podemos tener lo que consideramos una configuración bastante buena para las pruebas, y luego una nueva persona hace algunas pruebas. ¿Adivina qué? Encuentran problemas que no se encontraron antes.

Una señal de que la calidad está mejorando es cuando el porcentaje de problemas encontrados en las pruebas que no son realmente errores se acerca al 100%.

Hay un gran y creciente movimiento de desarrollo llamado Test Driven Development o TDD. No pretendo ser un experto y realmente he tenido problemas para entender este método de forma predeterminada, pero lo esencial es que el desarrollador primero escribe una prueba fallida y luego escribe el código para pasar esa prueba.

El concepto tiene muchas fortalezas. Una es que tienes un gran conjunto de pruebas. Otra es que, dado que esto se hace en muchos pequeños incrementos, usted sabe de inmediato si rompe algo. Una de las cosas que he visto con este método y otros "mandatos" de probar todo es que no se consigue que los desarrolladores se pongan en funciones adicionales porque son geniales o ingeniosos. Siempre hay un costo para una función y muchas veces un desarrollador no ve ni siente ese costo. Con TDD lo hacen, ya que escribe un caso de prueba antes de escribir el código.

También hay extensiones en esta teoría que llevan la escritura de la prueba a la fuente de requisitos donde el experto en negocios escribe un conjunto de pruebas funcionales que componen la especificación y luego los desarrolladores desarrollan ese conjunto de casos de prueba.

Entonces, con TDD, el desarrollador escribe muchas pruebas, algunos abogan por una relación de 1: 1 para las líneas de código de prueba a las líneas de código.

Cambiando esto: creo que hay un gran valor para reclutar al menos algunas personas para el equipo que sean mejores en las pruebas que en la codificación. Es un conjunto de habilidades que es diferente del desarrollo y creo, incluso con TDD y otras prácticas ágiles, que alguien con buen ojo para las pruebas es invaluable para la calidad del producto.

Tan fácil de preguntar: ¿deberían los probadores estar codificando tanto como los codificadores están probando?

OMI: sí, debería haber al menos un poco de mezcla. Tener una perspectiva en el otro extremo de la producción de un producto lo mantiene bien redondeado y puede generar nuevas ideas.

Creo que es responsabilidad de un programador hacer una cantidad decente de diligencia debida antes de registrar un código y firmarlo, esto significa:

• Redacción de exhaustivas pruebas unitarias.
• Probar ese código en un escenario de uso real e intentar romperlo, es decir, interactuar con él como se usaría en la producción.

...

• Luego, otro programador debería revisar ese código y las pruebas unitarias.

• Luego, un probador dedicado / persona de control de calidad debe probar ese código.

No creo que haya ninguna excusa para no hacer los primeros 3. Y no creo que haya ninguna excusa para no hacer el último paso, pero tener un probador dedicado prueba cada código es costoso y las compañías más pequeñas (piense al menos) que este es un lujo que no pueden permitirse.

Personalmente, no creo que alguna prueba específica deba quedar fuera de la ecuación. Creo que necesita encontrar personas que al menos no estén desarrollando el mismo producto (o tal vez un módulo grande), lo que permitiría probar a otros programadores, siempre y cuando realmente no tengan idea de cuál es la implementación. Creo que lo más importante es que, lo hagan o no, los desarrolladores deberían poder funcionar como probadores, y los probadores deberían poder funcionar como desarrolladores. Tener bases de conocimiento y familiaridades hace que el desarrollo, las pruebas y la comunicación entre ambos sean mucho más fáciles.

1. Sí, aunque no "funcionan como pruebas de software". Escribir exámenes es parte del trabajo de un programador. Además, escribir buenas pruebas es una habilidad. No poder probar adecuadamente sus propias características no es una falla en las pruebas, es un indicador de falta de habilidad *.

2. Ciertamente lo espero.

3. Si bien un programador puede probar completamente su trabajo, puede haber valor en un proceso de control de calidad externo. Sin embargo, rara vez he encontrado que ese sea el caso.

El objetivo de la prueba es triple:

1. Para impulsar el desarrollo
2. Para gestionar el cambio
3. Para proporcionar confianza

Las pruebas de desarrollador pueden y deben servir para todos estos propósitos. Si las pruebas de desarrollador son suficientes para ellos, no hay necesidad de más pruebas.

* La programación en pareja hace que sea aún más difícil escribir pruebas tan malas porque nunca estás probando tus propias características.