¿Qué deben probar los desarrolladores antes de enviar su trabajo a los evaluadores? [cerrado]

¿Existe una lista de verificación que el desarrollador debe revisar antes de pasar su trabajo a los evaluadores?

Además, ¿a qué condiciones / casos debe prestar atención el desarrollador?

¿Existe una lista de verificación que el desarrollador debe revisar antes de pasar su trabajo a los evaluadores?

Absolutamente. Idealmente, esta lista de verificación consta de dos elementos:

• Verifique que el ciclo continuo de integración se haya completado y
• Haga una entrada en un sistema de seguimiento de errores / características para los cambios que van a QA

La verdadera lista de verificación está oculta detrás de su estrategia de integración continua. Dado que esta lista se gestiona de forma centralizada y es totalmente automatizada, los desarrolladores individuales no pueden arrojar su código por encima del muro para "olvidarse" del control de calidad antes de enviar algo importante antes de enviar su trabajo al equipo de control de calidad. Sabes que los desarrolladores a menudo se vuelven "olvidadizos" bajo la presión del tiempo, ¿verdad?

El sistema de integración continua necesita ejecutar una compilación y ejecutar todas las pruebas unitarias y de integración. No hace falta decir que los desarrolladores deben poner a disposición nuevas pruebas unitarias para el sistema de integración continua a medida que desarrollan nuevas funciones y corrigen errores.

Los desarrolladores no deben tocar lo que sale del sistema de integración continua antes de entregarlo al control de calidad, ni siquiera para instalarlo y probarlo rápidamente. Si QA dice que la compilación no se instaló, debe corregir su ciclo de integración continua para asegurarse de que no escupe artefactos no instalables o que no funcionen.

El segundo paso es agradable (marcar un error corregido o una característica completa), por lo que los desarrolladores rara vez, si alguna vez, se olvidan de hacerlo.

Eso depende. Hay varias filosofías:

• Test Driven Development quiere que escriba Regresión / Prueba unitaria antes de comenzar a codificar.
• el codificador conoce las partes difíciles del código y puede probar en consecuencia
• un probador independiente puede encontrar errores en los que el desarrollador nunca pensó. Además, el probador podría estar más familiarizado con el área en la que realmente se utiliza el software, y también podría hacer alguna validación ("¿Está creando lo correcto?" En comparación con la verificación "¿Lo está haciendo bien?").

Por lo tanto, el nivel de prueba que realiza cada socio depende de su proyecto y su organización. Es importante estar de acuerdo en este nivel de antemano. Por supuesto, el código debe al menos compilarse y ejecutarse sin arrojar errores.

¿Hace lo que fue diseñado para hacer? ¿Lanza las excepciones apropiadas cuando se le da una entrada incorrecta? ¿Es utilizable? (eso se aplica tanto a las API como a las IU).

Su código debe estar, a su leal saber y entender, libre de errores antes de dárselo a los evaluadores. Debe hacer cualquier prueba que necesite para sentirse cómodo con la calidad de su propio código.

Todo lo que pueda de tal manera que el control de calidad no le responda y CC le dijo a su gerente que "claramente no probó este producto". Puede tener pruebas de unidad, integración, sistema y manual (es decir, usted) a su disposición. De lo contrario, solo estaría desperdiciando el tiempo del control de calidad.

Un tipo de control de calidad que trabajaba para mí pediría una "prueba" de que los desarrolladores habían probado la entrega. Esto podría ser resultados de xUnit, resultados de scripts o incluso una lista de verificación en papel. Baste decir que esto impidió que los desarrolladores simplemente le enviaran el resultado de la compilación.

Desde el punto de vista del probador, el mayor error de un desarrollador es proporcionar un código que no se compila.