¿A mejor testing peor calidad de software?

En cuanto inicié la lectura pude ver un diagrama que me refrescó los conceptos que vengo gestando desde mis análisis de problemas.

Sucede que las metodologías, cualquiera sea, tienen ciertos elementos que si no sabemos tratar con cuidado, convierten todo un proceso en burdo y empantanado.

“¿Cómo sabe que su Software no está en un Espiral Muerto?”

Cuenta la cantidad de fallos, errores y defectos
Escucha a los Testers
Observa los tiempos de Integración
Escucha a los desarrolladores
Presta atención a la demanda de recursos
Recuerda y ten en cuenta ciertos puntos de control
- Usa una base de conocimiento de los fallos, errores y defectos entregados a producción
- Aplica técnicas de prevención de fallos
- Conoce el esfuerzo de implementación
- Conoce el esfuerzo del Testing
Evalúa fallos conocidos
- Los desarrolles pueden continuar con la tasa de fallos encontrados en su haber?
- Los Testers están encontrando los fallos más importantes?
- La Gerencia está tomando buenas decisiones al respecto de los fallos que son encontrados?
- Los fallos son utilizados para mejorar el proceso de desarrollo en general?
Evalúa los Requerimientos
- Asegúrate de que todo el mundo entiende que estamos construyendo, por que y para que
- Convierte los requerimientos implícitos en explícitos
- Permite y promueve que los interesados vean el software periódicamente durante la fase de desarrollo
- Escucha cuidadosamente y cuestiona las presunciones
Los defectos ponen a prueba las aplicaciones
- Define código estándar
- Define buenas prácticas de codificación
- Mantenga las revisiones para ver que las codificaciones siguen los estándares
- Toma ventaja de las revisiones de código como una oportunidad para compartir sugerencias y técnicas para las pruebas de error en el entorno de desarrollo
No permita que un problema se transforme en el problema de alguien más
- Mantén una cultura donde la idea viva sea la de la RESPONSABILIDAD
- No dejes de hacer hoy lo que podrías delegar en otra persona del equipo
- Si un problema tuyo no se convierte en un problema de alguien más, entonces no es un problema
- Ten en cuenta que el Software es quien sufrirá los resultados

Detecta los fallos en forma temprana
- Como están definidas las Pruebas de Unidad?
- Quien es el responsable de las Pruebas de Unidad?
- Se puede testear algunas partes del sistema en forma aislada?
- El esfuerzo de las Pruebas Unitarias está mejorando?
- Cuales herramientas está utilizando para ayudar al proceso de Pruebas Unitarias?
- El sistema es construido e integrado diariamente?
Planifica el tiempo para el Desarrollo, Testing y Correcciones de Defectos
- Incluye en la planificación de los desarrolladores el tiempo suficiente para realizar algunos tipos de pruebas durante la construcción de primera mano
- Considera en la planificación de los desarrolladores el tiempo suficiente y necesario para la corrección de los defectos detectados durante sus propias pruebas
- Presta atención a las alarmas de los desarrolladores al respecto de las presiones de tiempo que hacen que se salten etapas
Invierte en mayor medida en la prevención de los defectos
- No planifiques obtener mejora de calidad solo promoviendo la mejora del esfuerzo del “Testing Independiente” (grupo separado de los Desarrolladores)

Luego el artículo muestra la conversación entre dos personajes que podrían ser dos actores típicos de una Software Factory, un Responsable de Pruebas y Calidad y una Gerente de Área.

La conversación muestra con gran simpleza la evolución de la gráfica y va entrelazando los conceptos que indefectiblemente llevan a La Calidad o a la No Calidad del software.

Queda claro el concepto de que la Calidad Percibida es inversamente proporcional a la cantidad de defectos que se dejan pasar a los entornos operativos del cliente. Es decir que a más defectos del lado del cliente, menos calidad percibida y viceversa. De la misma manera a mayor cantidad de defectos detectados en las pruebas de sistemas, el número de defectos posibles a ser pasados al entorno operativo del cliente es menor. Esto quiere decir que hay etapas que deben ser respetadas a raja tabla aún a disconformidad de alguna de las partes, como una Líder de Proyecto, Responsable de Despliegue, Comercial o inclusive La Gerencia.

Una de esas etapas son las Pruebas de Sistemas. Este es el entorno operativo dentro de la organización, más cercano al entorno operativo del cliente y los resultados generados en este ambiente, se deben tomar indefectiblemente como referente directo de los resultados que se replicarán en los ambientes productivos y su consiguiente Calidad Percibida.

Aún cuando se incremente el Esfuerzo Independiente que suponen las pruebas de sistemas, hay otras etapas previas conocidas como el “Esfuerzo del Testing del Desarrollo”, que no deben ser omitidas, pues aún estando más lejos del entorno operativo de producción, son la garantía inicial de que el producto construido cumplirá con los requisitos. Directamente estas garantías iniciales impactan en los costos de la organización.



	Luego de altas persistencias de fallos, defectos y errores en los sucesivos ciclos de Testing para distintos proyectos y alguna cantidad de detecciones en los clientes, los reclamos con tonos elevados no se hicieron esperar. Hubo así entre dicho entre los Responsables de Despliegues, ataques entre Testers y Desarrolladores, Administradores de Pruebas y Responsables de Desarrollo y finalmente La Gerencia. Luego de planteos fuera de lugar y experiencias que nos pusieron en límites de tolerancias entre las personas, quise analizar por que estamos fracasando tan enfáticamente en lo que a calidad de los productos de software se refiere. Tengo mis anotaciones frescas en mi cuaderno de proyectos y en mi mente mucho más, sin embargo, luego de leer un poco de blogs que frecuento, encontré una referencia a un artículo muy interesante. El título expresa simplemente lo siguiente: *“¿A mejor Testing, peor calidad de Software?”*. Automáticamente me llamó la atención esta suerte de contradicción y abrí el PDF directamente desde la WEB.
	En cuanto inicié la lectura pude ver un diagrama que me refrescó los conceptos que vengo gestando desde mis análisis de problemas. Sucede que las metodologías, cualquiera sea, tienen ciertos elementos que si no sabemos tratar con cuidado, convierten todo un proceso en burdo y empantanado. Observé otra pregunta reveladora: “¿Cómo sabe que su Software no está en un Espiral Muerto?” A este respecto en el artículo se dan ciertas sugerencias como: Cuenta la cantidad de fallos, errores y defectos Escucha a los Testers Observa los tiempos de Integración Escucha a los desarrolladores Presta atención a la demanda de recursos Recuerda y ten en cuenta ciertos puntos de control Usa una base de conocimiento de los fallos, errores y defectos entregados a producción Aplica técnicas de prevención de fallos Conoce el esfuerzo de implementación Conoce el esfuerzo del Testing Evalúa fallos conocidos Los desarrolles pueden continuar con la tasa de fallos encontrados en su haber? Los Testers están encontrando los fallos más importantes? La Gerencia está tomando buenas decisiones al respecto de los fallos que son encontrados? Los fallos son utilizados para mejorar el proceso de desarrollo en general? Evalúa los Requerimientos Asegúrate de que todo el mundo entiende que estamos construyendo, por que y para que Convierte los requerimientos implícitos en explícitos Permite y promueve que los interesados vean el software periódicamente durante la fase de desarrollo Escucha cuidadosamente y cuestiona las presunciones Los defectos ponen a prueba las aplicaciones Define código estándar Define buenas prácticas de codificación Mantenga las revisiones para ver que las codificaciones siguen los estándares Toma ventaja de las revisiones de código como una oportunidad para compartir sugerencias y técnicas para las pruebas de error en el entorno de desarrollo No permita que un problema se transforme en el problema de alguien más Mantén una cultura donde la idea viva sea la de la RESPONSABILIDAD No dejes de hacer hoy lo que podrías delegar en otra persona del equipo Si un problema tuyo no se convierte en un problema de alguien más, entonces no es un problema Ten en cuenta que el Software es quien sufrirá los resultados Detecta los fallos en forma temprana Como están definidas las Pruebas de Unidad? Quien es el responsable de las Pruebas de Unidad? Se puede testear algunas partes del sistema en forma aislada? El esfuerzo de las Pruebas Unitarias está mejorando? Cuales herramientas está utilizando para ayudar al proceso de Pruebas Unitarias? El sistema es construido e integrado diariamente? Planifica el tiempo para el Desarrollo, Testing y Correcciones de Defectos Incluye en la planificación de los desarrolladores el tiempo suficiente para realizar algunos tipos de pruebas durante la construcción de primera mano Considera en la planificación de los desarrolladores el tiempo suficiente y necesario para la corrección de los defectos detectados durante sus propias pruebas Presta atención a las alarmas de los desarrolladores al respecto de las presiones de tiempo que hacen que se salten etapas Invierte en mayor medida en la prevención de los defectos No planifiques obtener mejora de calidad solo promoviendo la mejora del esfuerzo del “Testing Independiente” (grupo separado de los Desarrolladores) Luego el artículo muestra la conversación entre dos personajes que podrían ser dos actores típicos de una Software Factory, un Responsable de Pruebas y Calidad y una Gerente de Área. La conversación muestra con gran simpleza la evolución de la gráfica y va entrelazando los conceptos que indefectiblemente llevan a La Calidad o a la No Calidad del software. Queda claro el concepto de que la Calidad Percibida es inversamente proporcional a la cantidad de defectos que se dejan pasar a los entornos operativos del cliente. Es decir que a más defectos del lado del cliente, menos calidad percibida y viceversa. De la misma manera a mayor cantidad de defectos detectados en las pruebas de sistemas, el número de defectos posibles a ser pasados al entorno operativo del cliente es menor. Esto quiere decir que hay etapas que deben ser respetadas a raja tabla aún a disconformidad de alguna de las partes, como una Líder de Proyecto, Responsable de Despliegue, Comercial o inclusive La Gerencia. Una de esas etapas son las Pruebas de Sistemas. Este es el entorno operativo dentro de la organización, más cercano al entorno operativo del cliente y los resultados generados en este ambiente, se deben tomar indefectiblemente como referente directo de los resultados que se replicarán en los ambientes productivos y su consiguiente Calidad Percibida. Aún cuando se incremente el Esfuerzo Independiente que suponen las pruebas de sistemas, hay otras etapas previas conocidas como el “Esfuerzo del Testing del Desarrollo”, que no deben ser omitidas, pues aún estando más lejos del entorno operativo de producción, son la garantía inicial de que el producto construido cumplirá con los requisitos. Directamente estas garantías iniciales impactan en los costos de la organización. Javier Santillán