Resolución de issues
Manejo con el cliente
Un issue
Se detectó que en el proceso del desarrollo tenemos un problema o error y no está funcionando correctamente. Por ejemplo, en ocasiones nos encontramos pulgas que pueden ser de usabilidad que inclusive requieren volver a la etapa de diseño que pueden ser sencillas, desde que el usuario no entiende el nombre de un botón o más compleja que no usa toda una funcionalidad.
El Cliente
El cliente se involucra cuando sea necesario, por ejemplo algún cambio en el diseño original, como parte de la comunicación o siendo notificado de la aparición de un issue, en cuál ciclo se dió y conociendo que estamos atendiendo la situación.
Solución
Hot fix: se denomina al procedimiento usual con una pulga, cuando el equipo o varios miembros del equipo se van a enfocar en reproducirla, resolverla, probarla y subir el arreglo a producción tan rápido como sea posible.
Si la “pulga” puede ser administrada y solucionada, se pone en producción con otros cambios (que no sea un hotfix). Ir a producción siempre es un riesgo y se va cuando los cambios lo ameriten y se libera en un próximo release.
La decisión tomada debe quedar debidamente documentada y nos aseguramos nos permita seguir con el ciclo del desarrollo.
Mis funciones como QA
Como ingeniero encargado de mantener el aseguramiento de la calidad de su proyecto, una vez identificado un issue (problema) el procedimiento es ejecutar diferentes escenarios y documentar los pasos necesarios para reproducir el issue. Al documentar el issue se crea un work item en la herramienta de seguimiento de issue con el fin de poder asignarlo a los desarrolladores.
Dependiendo de la gravedad del error encontrado, el administrador del proyecto o PM (Project Manager) puede reunirse con el desarrollador encargado para revisar las posibles áreas de afectación que involucraría el software al realizar los cambios. Cuando un desarrollador da por terminada una tarea coloca sus cambios en un pull request para que el líder de desarrollo realice una revisión de código de los commit y con esto determinar si es aprobada o denegada la tarea asignada.
Para aprobar la solución efectuada por el desarrollador, creó diferentes escenarios en los que se puedan probar los features, con el fin de encontrar posibles errores que el desarrollador no identificó.
En síntesis: detectó un error, se lo comunicó al desarrollador quien debe priorizar la solución, de manera que el pull request sea breve y directo. El desarrollador debe acompañarme en la evaluación de la mayor cantidad de escenarios posibles para evitar encontrar errores en momentos posteriores a la liberación y pasar por el proceso de pruebas nuevamente.