Equipo QA – El recurso oculto

¿Que es lo primero que viene a mente cuando mencionamos Ingeniero QA o Tester?

Hay quienes piensan y asumen que las actividades típicas del Tester, las puede llevar a cabo cualquiera y esto se piensa independientemente de la metodología utilizada.

La razón puede estar fundada en el concepto erróneo de que cualquier persona puede determinar si una aplicación funciona o no, con solo seguir un plan de ejecución de pruebas predefinidas, lo cual es bastante típico en Waterfall.

También se asume que el aseguramiento de calidad es solo cumplir con actividades formales de Testing, aplicadas a distintas áreas de procesos en su debido tiempo.
Sin embargo con este pensamiento se deja de lado la especialización, enfoque, razonamiento y experiencia de los profesionales del QA-Testing y su importante aporte dinámico para el aprendizaje continuo durante todo el ciclo de vida de un proyecto de software.

La vereda más transitada

En metodologías tradicionales de desarrollo de software se tiene especial cuidado con la planificación detallada de las pruebas, de modo tal que esta sea acorde a la definición detallada de los requerimientos y a la planificación detallada de todo el proyecto. En base a un aprendizaje inducido por la documentación de como debería funcionar el sistema, se ejecutarán respectivos ciclos de pruebas de sistemas para verificar la completitud y correctitud del sistema en base a tales requisitos.

Como contrapartida se supone un Plan de Pruebas rígido, con muy baja adaptabilidad al cambios de requerimientos y a aparición de nuevos requisitos. También está la cuestión del enorme esfuerzo de mantenimiento del plan, la pérdida de tiempo en el circuito comunicaciones y la aplicación de responsabilidades a personas y/o grupos de personas “encargadas de tal artefacto”.

En la vereda del frente

Las metodologías Agiles presuponen una planificación estratégica del Testing en el orden de ser ampliamente adaptativa, acorde a la velocidad de cambios en los requerimientos del sistema e inclusive a la creación de nuevos requisitos para una misma iteración.  Este solo hecho presupone una total participación de los miembros QA-Testing al inicio de los proyectos, no desde el punto de vista de la inspección-auditoría, sino desde el punto de vista de “recorrer un camino” como equipo, hacia el verdadero aseguramiento de la calidad.

En estos dos enfoques diametralmente distintos, la participación del QA-Testing cambia de un rol de “full-Auditoria” para la detección de fallos y asignación de responsabilidades a “full-partner” del resto de los miembros del equipo para la generación de valor inmediato y motor de orientación a proyectos exitosos.
Esta concepción permite revalorizar los roles QA debido al uso potenciado de los mismos, aportando un valor más estratégico para las necesidades de los negocios que atienden los sistemas que se construyen.

Los Testers encuentran en Agile su máxima posibilidad de expansión, con actividades operativas que ayudan a los desarrolladores a promover la generación de soluciones más eficientes y en instancias cercanas al inicio del desarrollo, e inclusive previas.
A su vez como miembros del equipo QA podrían ser fuentes de información constante referido al comportamiento del sistema en construcción, permitiendo adelantarnos a cambios en los requerimientos, requerimientos mal concebidos o desarrollados en modo no deseado, promover mejoras y una lista larga de etcs. que en definitiva orientan a traves de todo el ciclo de vida del proyecto e inclusive supera las fronteras ayudando en el training a clientes y acercando el conocimiento a las áreas de soporte.

En ambas veredas

Esta revalorización del QA-Testing no debe ser abarrotada detrás de las metodologías Agiles, ya que el concepto puede ser aplicado a cualquier proceso de desarrollo. De hecho, las metodologías Agiles no han planteado este paradigma ni es algo que les pertenece, aún cuando se utilice la terminología “Testing Agile” y se explique algo similar a todo lo que digo.

La evolución de SQA-Testing

Aún cuando muchos “pseudoagilístas” consideran a un Tester como un recurso de menos rango y hasta despreciable para la organización por no generar aporte productivo, “los del palo del SQA-Testing”  nos damos cuenta de la evolución por la misma adaptación que debimos sufrir acorde a la velocidad de respuesta que requieren los procesos de desarrollos actuales.

Asumamos que un cambio de paradigma QA es posible aún dentro de procesos tradicionales. Aún así, el cambio no puede gestarse por si solo, debe surgir de un cambio en el paradígma organizacional.

Fuentes de inspiración:
Testers: The hidden resource

Advertisements

10 Mejores Prácticas para la Generación de Software

La rapidez con que se construye un edificio es sorprendente, pero detrás de esa aparente facilidad están los siglos de experiencia de la industria de la construcción, y si quisiéremos aplicar los mismos parámetros a los proyectos de software, la desproporción será abismal. A casi tres décadas el desarrollo de software sigue buscando la manera adecuada de desarrollarse para hacerlo más rápido y sin errores.
Anteriormente las pruebas de software se consideraban sólo una actividad que realizaba el programador para encontrar fallas en sus productos; con el paso de los años se ha determinado la importancia que tienen para garantizar el tiempo, el costo y la calidad del producto, de tal forma que actualmente son un proceso cuyo propósito principal es evaluar en todo momento la generación del software respecto de los requerimientos establecidos al inicio.

La tendencia consiste en iniciar las pruebas en etapas tempranas dentro del proyecto, y capacitar a especialistas responsables de esta actividad. El primer punto quiere decir que actualmente es una práctica casi generalizada que las especificaciones de pruebas se realicen al mismo tiempo que el diseño de software; la propuesta es iniciar el análisis del testware junto con el análisis del software. Esto habla de pruebas preventivas que ofrecen ventajas como las siguientes:

a) Se identifica qué se quiere y cuáles son los resultados esperados (criterios de aceptación)
b) Ejecutar las pruebas tan pronto como el software está listo, si fuera posible en integraciones de betas para testing, no solo para descubrir errores, sino evitarlos.

El segundo punto habla de crear conciencia sobre la importancia de las pruebas y tener un equipo de personas dedicadas a esta actividad que puedan integrarse a un proyecto donde todos y cada uno sean responsables de su calidad.

Entonces se puede decir que los objetivos actuales de las pruebas no sólo tienen que ver con corregir errores, sino con prevenirlos influyendo y controlando el diseño y desarrollo del software. Las pruebas deben ser empleadas como modelos de los requerimientos de software que se ha de construir; por tanto, en las especificaciones de software deben incluirse especificaciones de pruebas; ambas deberán revisarse en conjunto, y en esta revisión deberá participar un especialista en pruebas.

La disciplina de pruebas ha evolucionado en una práctica de especialización que puede ser ofrecida como un servicio hacia clientes internos y externos, garantizado que tanto la metodología como las herramientas automatizadas son aprovechadas eficientemente para alinear el desarrollo a las expectativas del cliente.

Se debe reconocer que las pruebas son una especie de administradores de riesgos; al igual que en los problemas de combinatorias complejas, se puede definir cuál debe considerarse buen resultado, aunque no necesariamente sea el mejor resultado; con esto quiero decir que las pruebas sólo deben obtener un producto práctico con la calidad y funcionalidad requeridas.

A continuación se sugieren 10 mejores prácticas para la generación de software:

1. Hacer una evaluación del trabajo de cada integrante del equipo. Concienciar al equipo de la importancia que tienen las pruebas y el valor que tienen para cada miembro del equipo y así generar cooperación y coordinación entre los miembros del mismo.
2. Establecer un plan maestro integrado. Establecer claramente las funciones y responsabilidades de los equipos de desarrollo y pruebas
3. Considerar las pruebas preventivas como parte de las especificaciones de trabajo. Diseñar previamente los escenarios de prueba, dentro del desarrollo de software, y realizar revisiones para asegurarse de que lo que se está construyendo cumple con los requerimientos solicitados.
4. Usar las pruebas como puntos de control y progreso. Realizar pruebas y revisiones formales para verificar y demostrar que todos los productos claves del proyecto han sido realmente terminados.
5. Inventario de los objetivos de pruebas y diseño para factibilidad. Revisar la factibilidad en la realización de las pruebas.
6. Probar pronto y frecuentemente. Hay que probar lo antes y más frecuentemente posible; esto permitirá detectar los problemas tan pronto surjan, de esta manera el desarrollador será más eficiente en las correcciones.
7. Diseñar y desarrollar el testware como el software. Esto implica planear, analizar, diseñar, supervisar, controlar los cambios, administración; en suma, desarrollar el testware con la misma disciplina con que se desarrolla el software.
8. Proporcionar una herramienta integrada de pruebas, evaluación y de soporte de infraestructura. Proporcionar herramientas que incluyan: Base de datos o repositorio, Administración de pruebas, que permita documentar, ejecutar y clasificar pruebas, Soporte automático, Simuladores, Analizadores de software, Manejadores de pruebas, Herramientas de captura y repetición (playback) y utilerías.
9. Medir el costo, el alcance, los resultados y la efectividad de las pruebas y evaluación. Coleccionar información que permita conocer el costo, los resultados y los beneficios así como el alcance.
10. Entrenar y administrar al equipo. Proporcionar el liderazgo y administración al equipo con el fin de que sepa lo que se espera de él para que se tomen las pruebas seriamente. Definir los criterios de “mejores prácticas”.

La razón principal para implementar esta práctica, es que finalmente todo el tiempo perdido, se convierte en costos que afecta los resultados de un proyecto, pues generalmente se usa más del tiempo planeado para las pruebas. Para los administradores de proyectos, la correcta administración es la que lleva a obtener buenos resultados.

Publicado por por Elsa Ramírez, Directora de Tecnología y Calidad para Praxis el 6 de marzo de 2008 en http://www.sg.com.mx

¡No existe el vamos a probar!

Las TIC y Software Factory de Argentina y Latinoamérica en general, comenzaron a entrar en la burbuja ascendente donde los servicios son requeridos desde todo el mundo, principalmente por la calidad de los profesionales, el carácter innovador y por supuesto los menores costos operativos.
Es por este motivo que se habrán enterado de la gran escalada de organizaciones que están en proceso de certificaciones y/o evaluaciones CMMI, ISO entre otras o que bien ya certificaron. Sin embargo estas evaluaciones y certificaciones no garantizan la productividad, solo un aspecto de la misma.
Las necesidades de actualización del sector son muchas y permanente, pero el movimiento agilísta se ha tornado más que interesante por que ofrece beneficios directos a aquellos que aprenden a manejar sus conceptos, re definir sus estructuras organizacionales o al menos en ciertas áreas operativas, integrar herramientas de apoyo y principalmente modificar sus paradigmas de gestión.
Los beneficios del agilísmo bien pueden ser utilizados por cualquier tipo de organización pues apunta a duplicar, triplicar, o más, la velocidad productiva. Sin embargo las metodologías Ágiles son muy difundidas en el mercado SSI (Servicios Informáticos y Software) principalmente por que las metodologías de gestión tradicionales no dieron hasta ahora respuestas a la velocidad que el mercado actual requiere.
Pero es en extremo importante el aporte de gestores en metodologías tradicionales, principalmente por el cúmulo en años y proyectos que los mismos de seguro, tienen.
Muchos intentan separar a la gente, dividiéndolas en Agilístas y Tradicionalistas pero yo creo que hay que apuntar a unirlas y tamizar los atributos de valor que le brindan ambos tipos de experiencia al mercado SSI y TIC.
Jornadas Ágiles de actualización profesional, serían bien utilizadas por gerentes de sistemas, líderes de equipos, desarrolladores y probadores de software y otros líderes de áreas transversales como Marketing y Ventas, por mencionar algunas. Esto es así por que tal como te menciono líneas arriba, se trata de un paradigma que necesariamente para ser exitoso implica un compromiso de áreas sensibles de una organización y la adaptación tanto de los modelos Ágiles a los Procesos Organizacionales como de las organizaciones a los modelos, y sin eso … ¡mejor olvidarlo!. ¡No existe el vamos a probar!
Notarán quizás que las jornadas Ágiles en Buenos Aires ofrecen la participación en seminarios de actualización, prácticas y certificaciones profesionales (en solo dos días??? muy poco serio) las cuales son dictadas por referentes de primer nivel en el mundo.
No estoy de acuerdo en que a Córdoba se deban traer tales exponentes, ni ofrecer certificaciones profesionales sacadas de la galera, debido a que existen exponentes locales que ya están haciendo este tipo de difusiones y también podrían aportar un buen servicio.
Si me interesan prácticas, talleres, seminarios, cursos y las pagaría. De hecho preferiría variedad a solo una o dos ópticas.
Hay que entender que Latinoamérica en general se encuentra en pañales en lo que se refiere a este tipo de movimientos y aún cuando pudiera existir gente certificada (por ejemplo Scrum Masters) no existen profesionales con experiencia, por el solo hecho de que la experiencia la están haciendo ahora mismo. Allí veo la veta.

Saludos,
Javo.