May 25
Debido a que durante el desarrollo de cualquier producto software se identifican un gran número de defectos, en muchos casos de alta prioridad o prioridad crítica, un equipo para la revisión de defectos (Defects Review Team) es esencial en cualquier equipo de testing.
Un DRT (Defects Review Team) proporciona una rápida y eficiente respuesta a un defecto en cualquiera de nuestros entornos y garantiza una oportuna solución. El equipo estará integrado por los siguientes miembros:
- Responsable del equipo de desarrollo (Development team leader).
- Jefe de proyecto (Project manager).
- Responsable del equipo de pruebas (QA team lead).
- Cliente (Opcional). Es importante que el cliente forme parte de este equipo, aunque no siempre es posible su participación.
Cualquiera que haya sido programador probablemente ha recibido defectos mal reportados. Defectos que no dicen nada ( “No funciona!”); que no tiene sentido; que no dan suficiente información; que dan información errónea. Defectos que resultan ser error del usuario, problemas que son culpa de otro componente del programa; o que resultan ser un problema de red.
Lo que en principio puede parecer una afirmación bastante lógica no siempre es así. En muchas ocasiones son los propios desarrolladores o jefes de proyectos los que, “alegremente”, cierran defectos que no han sido verificados por testing. Un defecto marcado como “Arreglado” (Fixed-Ready to test), debe de ser siempre verificado por el equipo de testing. Si el defecto es “rechazado” por no ser considerado un defecto, el tester deberá de pedir más información sobre el defecto para así realmente verificar que no se trata de un defecto y estar de acuerdo con la decisión. Si el defecto es rechazado por ser considerado “duplicado”, el tester deberá verificar que efectivamente el defecto existe y que efectivamente está duplicado. En muchos proyectos los desarrolladores tienden a esconder los defectos refugiándose en que el defecto está duplicado.
