¿Los desarrolladores de software depuran su propio código?

Los ingenieros de software reales depuran su código. Si está trabajando en un entorno en el que “arroja el código por encima del muro” al control de calidad, su objetivo y aspiración debe ser frustrar el control de calidad porque no pueden encontrar nada sobre lo que hacer informes de errores. Si trabaja en un entorno TDD / BDD / QA integrado, debe asegurarse de que todo pase todas las pruebas posibles antes de que salga de sus manos.

En ninguna empresa se espera que un equipo de control de calidad depure el código del equipo de ingeniería, aunque las personas excepcionalmente buenas de control de calidad a menudo se depuran ellos mismos.

Es responsabilidad del desarrollador entregar no solo código, sino también código y múltiples tipos de pruebas que aseguran que el código funcione como se diseñó (por ejemplo, pruebas unitarias, pruebas de integración y, a menudo, pruebas de integración, humo y rendimiento).

El control de calidad generalmente es responsable de la validación final, de intentar romper el sistema final de varias maneras y de sistemas de prueba amplios y de extremo a extremo que prueban sistemas completos entregados por uno o más equipos.

Si el control de calidad encuentra problemas, el procedimiento típico es informar los errores y que el equipo de ingeniería asuma la tarea de depurar / solucionar el problema.

El equipo de control de calidad descubre si el código funciona, pero el programador generalmente descubre por qué no funciona . (La mayoría del código debería funcionar para cuando se entregue a QA, pero la mayoría de los jefes quieren que el software se escriba en un horario, y no puede producir X líneas de código depurado por día a menos que X sea extremadamente pequeño para el idioma. Por lo tanto, casi todo el código tiene algunos errores, incluso cuando se lanzó. [Windows XP, que ya no es compatible, todavía tiene algunos errores].

¿Los desarrolladores de software depuran su propio código?

¿O dejan que el equipo de control de calidad depure su código?

Eso depende del tipo de configuración de control de calidad que tenga: en las oficinas en las que he trabajado, la gente de control de calidad realiza pruebas a nivel de usuario (tanto automáticas como manuales), y no son desarrolladores ni están involucrados en trabajar en el código. Los desarrolladores hacen la depuración.

Eso no quiere decir que la gente de control de calidad no sea completamente técnica: nuestro producto es una aplicación comercial grande, con una base de datos compleja. Algunas personas de QA conocen una cantidad razonable de SQL y, a veces, investigarán problemas a nivel de base de datos; no es necesario que lo hagan, pero siempre se agradece cuando hay más detalles técnicos en los informes. Sin embargo, no tocan el código del producto ni solucionan los problemas, eso es puramente trabajo del desarrollador.

He oído hablar de otras configuraciones donde “QA” significa algo más como “desarrollador de prueba”, y esas personas están involucradas en las pruebas de nivel de código.

¡Por supuesto que depuramos nuestro propio código! Después de todo, nadie conoce el código que acaba de escribir, y por qué lo escribió de esa manera, mejor que usted.
El trabajo del equipo de control de calidad es probar el código, y en la mayoría de los casos no son desarrolladores, por lo que no tendrían idea de cómo depurar y solucionar problemas.

No conozco la experiencia de nadie más, pero en todas partes donde trabajé, el trabajo de QA es después de la revisión y prueba de hechos. Ejecute pruebas de regresión, verifique los estándares de codificación, verifique la documentación con los estándares, quizás pruebe los procedimientos de instalación, quizás haga algunas pruebas serias para el usuario. Si las cosas no funcionan, se devuelve al desarrollo para la depuración y otras correcciones.

Por otro lado, hay muchos casos en los que el desarrollo puede dividirse en desarrolladores y desarrolladores de prueba, particularmente para sistemas grandes y complicados, donde muchas piezas individuales tienen que jugar muy bien juntas (las pruebas de integración son un juego completamente diferente a las pruebas unitarias, como es la prueba operativa).

El control de calidad no depura el código. QA ni siquiera debería mirar el código, ya que los llevará a hacer casos de prueba para la implementación, en lugar de la funcionalidad.

Los desarrolladores de software no solo deberían depurar el código, sino que deberían ser los que escriban las pruebas unitarias.