Cuando QA-Testing comienza a perder “Valor” en la organización?

Como ejemplo contemporaneo podríamos tomar la idea de que una gran cantidad de equipos de desarrollo, actualmente están intentando migrar hacia las metodologías Agiles y en una importante medida, el área QA queda en “off-side”.
Sin cambios significativos en sus principios de funcionalmiento, intentan adaptar sus prácticas para seguir prestando su servicios tradicionales, y queda en evidencia que antiguas formas de hacer las cosas pierden su sentido.
Así mientras el equipo de desarrollo migra sus prácticas en base a nuevos principios, nos encontramos con equipos QA-Tester bastante desalineados con el nuevo esquema general y cada día que pasa, alejándose más de la posibilidad de brindar “valor” a la organización.
Lo interesante de este fenómeno, es que los cambios suelen llevar varios años y al mismo tiempo, QA parece ser el más resistido. Por que?

 

Posiblemente por que Agile prescinde de prácticas orientadas al “control exhaustivo”, minimiza el uso de métricas, achica los ciclos de Ingeniería a porciones donde la prueba-error-corrección son más frecuente y así la medición del error ya no es tan importante.

El “QA tradicional” se encuentra en un brete y debe necesariamente comenzar una evolución que lamentablemente no se está manifestando, en infinidad de casos, solo por que no se escucha a los involucrados que hace ya un buen rato, han notado los síntomas del cambio.

Advertisements

Generando circulos virtuosos en QA

 

 

 

Tanto la estrategia de gestión de los negocios como la estrategia técnica para el aseguramiento de la calidad del software comparten una “talón de Aquiles” que puede ser diferenciado en los siguientes dos enfoques:

 

 

 

Circulo vicioso

El primero se centra en estrategias de ejecución de pruebas funcionales, tratando de asegurar que la ejecución de todos los juegos de pruebas programados (incluídos los automatizados) cumplan con las espectativas, es decir con los planes. Este método usualmente deja sin cobertura algunos tipos de defectos y problemas de integración mayores, los cuales el equipo debe solucionar una vez que el producto está en el campo.

Este tipo de estrategias suelen carecer de una medición apropiada y buenas definiciones de calidad u objetivos bien establecidos, como también de proyectos de automatización y performance que sustenten una arquitectura general de la calidad esperada. El mayor foco es en la ejecución de pruebas y no tanto en una cultura orientada a la calidad.

Los equipos así conformados, fomentan un círculo vicioso donde prefieren confrontar con los problemas a medida que ellos se presentan, en lugar de anticiparlos y gestionarlos estratégicamente y por lo general el desorden prima hasta tal punto que no les permiten un aprendizaje y evolución continuo.

Círculo virtuoso

El segundo enfoque está orientado a la formación de equipos conformados por personas con muy altas habilidades en el pensamiento de los sistemas, antes de plantearse cualquier plan y quienes pueden ser facultadas en pos de objetivos estratégicos que son apoyados por una gestión que favorece al agregado continuo de valor y la promueven en toda la red organizacional.

Estos equipos así conformados, fomentan un círculo virtuoso donde es más fácil generar devoluciones proponiendo metodos de pruebas con técnicas emergentes e innovadoras que son diseñadas y aplicadas en los proyectos actuales, sin esperar a un futuro cercano, medio o lejano.

Empleados Vs Colaboradores

Ahora bien, la ejecución exitosa o el fracaso de los proyectos debe ser pagada y así es con cualquiera de los enfoques mencionados antes. La diferencia quizás radica en que las organizaciones que tienden al primer enfoque, solo consiguen conformar equipos de trabajadores técnicos del día a día y no pensadores de los sistemas.

En su contraparte, las organizaciones que facultan a su personal, dejan de tener simples empleados y forman a fuertes colaboradores estratégicos.

En ambos enfoques, el éxito o el fracaso ha dejado de ser un hecho atribuíble a los equipos para pasar a ser responsabilidad neta de las personas que están en posiciones gestión. Este concepto apunta a que ya no es admisible una razón que se apoye en que los proyectos fallan por una pobre ejecución de las operaciones, sino más bien por una carencia en importante en la estratficación.

Esto quiere decir, que lo que debe primar hoy en día en las organizaciones, aún si sus proyectos eventualmente fracazan, es la sistemática re-evaluación de la visión y los valores que defienden los tomadores-de-decisiones de una organización, para que así los equipos de desarrollo busquen defender esos mismo valores y compartan una visión correcta.

 

Inspirado en Empowering a QA Culture

¿Que hace un SQA?

Es responsable de asegurar la calidad de los productos generados en el proyecto y del proceso utilizado. Para asegurar la calidad debe revisar la calidad de los entregables de planificación del proyecto y los entregables de valoración del proyecto. Además revisa el nivel de apego al modelo de proceso de desarrollo de software y a los planes de Verificación, Gestión de Proyecto y Gestión de Calidad, documentando las desviaciones encontradas.

Debe conocer los conceptos y técnicas de Gestión de Calidad del Software. Debe identificar las propiedades de calidad que deben cumplir los productos del proyecto.

Centralizar y revisar las entregas que se realizan durante el ciclo de vida del proyecto.

Realiza las Revisiones Técnicas Formales con los responsables de los productos a revisar.

El Responsable de SQA debe:

  • Asegurarse de que se desarrollen prototipos para probar y eliminar riesgos técnicos que hagan fracasar el proyecto así como también disminuir la calidad del mismo

  • Asegurarse de que se realicen estudios de factibilidad

  • Realizar mediciones para comprobar la calidad del proyecto

  • Asegurarse de que se realice la actividad de implementación y se haga según los estándares de calidad propuestos

  • Evitar el desperdicio de esfuerzo en conjunto con el Administrador y el Arquitecto

  • Registrar las métricas de aceptación tomando en cuenta el Documento de Validación con el Cliente.

Perfil del rol

  • Debe conocer los requerimientos del sistema.

  • Debe conocer los estándares o lineamientos del proyecto para asegurar la calidad.

Actividades que son responsabilidad del rol

  • Planificar la Calidad

  • Revisión Técnica Formal (RTF)

  • Revisar las Entregas

  • Revisar el Ajuste al Proceso

  • Evaluar la Calidad de los Productos

  • Realizar el Informe Final de Calidad

Entregables que son responsabilidad del rol

  • Plan de Calidad

  • Informe de RTF

  • Entrega Semanal de SQA

  • Informe de Revisión de SQA

  • Informe Final de Calidad

Actividades en las que está involucrado el rol

  • Relevar los Requerimientos

  • Especificar los Requerimientos

  • Priorizar los Requerimientos

  • Validar los Requerimientos

  • Validar con Prototipo

  • Definir el Alcance del Sistema

  • Definir la Línea Base del Proyecto

  • Planificar el Proyecto

  • Describir la Versión

  • Planificar la Transición

  • Seguimiento de Satisfacción del Cliente

  • Gestión de Riesgos

  • Registrar Esfuerzo

  • Auto estudio

  • Reunión de Equipo

  • Preparar Cierre del Proyecto

  • Reunión Conmemorativa


Obtenido de MUM