Búsqueda de soluciones para problemas "simples" de peso sustancial

Posted on 10 octubre 2008. Filed under: Uncategorized |

Gestionando el equipo de pruebas para una de los Ciclos de Pruebas de Funcionalidad de hoy, se pusieron en evidencia ciertos problemas de peso sustancial.

En una situación especial el día de hoy tuve que desafectar a un Tester, reasignar los Script de pruebas y dejar mi gestión para asistir al nuevo probador en la ejecución de la prueba. Esto provocó una reacción un poco violenta del desafectado quien me hizo comentarios un poco fuera de lugar. Tuve la oportunidad de conversar con esa persona y plantearle nuevos puntos de vista, al menos para él.

Al finalizar el Testing y generar los reportes de estado de las pruebas, también tuve una charla similar con la Líder de Proyecto, quien expresó que debemos hacer algo para evitar tantos errores en Desarrollo y Testing. Sin embargo quedó claro que en Testing se van a encontrar los defectos de las implementaciones y de los requisitos, ya sea directa o indirectamente, mientras que lo que hay que mejorar son elementos de la Calidad del Proceso.

Mi forma de gestionar a partir de charlas anteriores con La Gerencia es un poco diferente y apunta a “limpiar los cuerpos de los Incidentes reportados”, dejando en esa sección solo los elementos de requisitos y análisis y separando los defectos del incidente en comentarios asociados. De esta manera se cumple con el pedido de esclarecer los Casos. 

Dada la situación hago el siguiente análisis

Los incidentes son dados de alta mostrando el problema, el cual en su mayoría no se entienden y tampoco especifican el modo correcto de funcionamiento.

Esto se evidencia por comentarios de los mismos desarrolladores quienes expresan que “quizás el mayor error que se comente es que no rechazan lo que no entienden o cuando ven que la información no les alcanza”. Significa que de algún modo adquieren el conocimiento básico para poder seguir y quizás es la causa por la cual las estimaciones se duplican, triplican o más. También podría ser la causa por la cual no se dan soluciones completas y en los primeros pasos de verificación ya se pueden detectar fallos.

Considerando el carácter escueto y hasta ausente de la documentación de referencia que indique como es la funcionalidad esperada, resulta grave no contar con las Pautas de funcionamiento normal, modos de fallos y modos de comprobación indicados en los mismos incidentes, con el criterio del que más sabe del asunto.

El impacto es directo también en Testing dado que sin importar quienes son los involucrados, deben lidiar con la información escasa y dispersa en el incidente, desde el entendimiento del problema, el requisito si es que existiere y hasta la misma evidencia de solución.

Así mismo no hay sección que indique como probar ni que resultado esperar y el Tester en el peor de los casos debe “inventar una secuencia de pruebas” que podría no tener la mayor ni la mejor cobertura.

Quiero decir que los Incidentes deberían darse de alta teniendo en cuenta los siguientes puntos:

  1. Identificar claramente el Problema
    • Asunto claro que identifique unívocamente el problema
    • Descripción que indique con claridad y precisión el modo de ocurrencia
      Descripción debe identificar el modo genérico y no expresarse con un ejemplo
  2. Secuencia de pasos para reproducción del problema o reconocimiento del mismo
    Aquí puede materializarse el problema mostrando un ejemplo que puede incluir también capturas de pantallas, diagramas, prototipos, maquetas u otros elementos de valor agregado
  3. Identificar impactos directos e indirectos
    • Relacionados a la funcionalidad que contiene el problema
    • Relacionados a otras funcionalidades adyacentes o dependientes
    • Ampliación de criterios por parte de Desarrolladores luego de evaluar y estudiar el incidente y las evidencias de solución son directas para establecer un modo de verificación. Es decir que solo importa como evidencia para el Testing, el “como lo verifico” o “como lo pruebo”.

Ya sabemos que si SQA pudiera definir criterios de calidad y Testing en forma anticipada, los resultados podrían ser mejores pero no es una situación que de mayor velocidad al proceso.
En la mayoría de las situaciones, el criterio SQA ha sido discutido vehementemente y en base a posturas de limitaciones técnicas. Aún cuando la postura de SQA normalmente es del tipo “negocio” y apunta al “diseño” de la solución, sin pretender establecer tantos criterios técnicos.
También en la mayoría de las situaciones SQA no cuenta con el tiempo de convivencia necesario con el problema para determinar los criterios de calidad y Testing. Esto se evidencia en la característica del “Testing de fuerza bruta”.

En conversaciones finales con la Líder de Proyecto, coincidimos que muchas veces se pone en evidencia clara la falta de auto motivación para ejecutar la tarea particular que implica el Testing y que dada la situación actual del proceso de Testing, se necesita de mucha proactividad la cual tampoco está presente y se prefiere decir “no se entiende y esto así como está es una porquería”. Si todos sostenemos esta peculiar postura de negatividad entonces estaríamos siempre rechazando elementos que provienen de otros y son nuestra entrada de trabajo.

La mejora de estos aspectos personales no implica dejar de lado el hecho real de que debamos mejorar la identificación del problema, los criterios de calidad, de diseño, de Testing unitario y de integración como el estilo de pruebas funcionales y sus reportes.

Liked it here?
Why not try sites on the blogroll...

A %d blogueros les gusta esto: