Exploratory Testing: Olfato e intuición amplificada

Fortalezas y debilidades de las Pruebas Exploratorias

Muchas veces se habla del Testing Exploratorio sin tener una verdadera conciencia de lo que se trata ni del modo en que se debe ejecutar. Los detractores de este tipo de verificaciones, opinan mostrando la práctica como informal, sin procedimiento y fuera de los cánones del Testing y por transferencia intentan establecer que no existe Calidad del Software.

Les doy la razón únicamente en que este tipo de pruebas del software no están en los cánones del Testing, puesto a que es una actividad extremadamente compleja de interpretar y realizar si no se tienen en cuenta los elementos de soporte que finalmente avalan la práctica.

Las pruebas exploratorias muestran sus resultados y garantías en base a los resultados y garantías de prácticas previas y del mismo modo, fallan sus resultados y garantías cuando prácticas que le anteceden son ejecutadas en forma endeble o imprecisa.

Para esta práctica son necesarios ciertos elementos que le anteceden:

  • Conciencia de que todo lo que se verifica está orientado a la detección de problemas que impidan satisfacer requisitos funcionales y no funcionales
  • Capacidad de análisis elevado para entendimiento cabal de requisitos en base a la observación y análisis de la evolución de los mismos
  • Abstracción para la elaboración de circuitos de pruebas de verificación y validación
  • Capacidad de ampliación de caminos de pruebas para mejora espontánea de la cobertura
  • Conocimiento y dominio del negocio al que pertenece el problema
  • Alta proactividad y gran capacidad comunicacional para generar ambiente colaborativo
  • Conocimiento cabal del proceso que rige para reconocer las fallas que se manifiestan en los resultados no deseados
  • Gran capacidad para definir y variar las estrategias, tácticas y técnicas de validación y verificación
  • Olfato e intuición amplificada

Hay que considerar que para el éxito de esta técnica se utilizarán las definiciones que se hacen a nivel de Historias de Usuario y/o Requerimiento,  para verificar mediante pruebas exploratorias (sin script), que el sistema esté haciendo lo que se solicita y se ampliará el grafo de pruebas para verificar que el sistema no haga lo que no debe hacer.
Es decir que básicamente la información disponible conforman nuestros Scripts de ejecución y también evidencia de funcionalidad.

Según este tipo de proceso de verificación y validación, las evidencias de funcionamiento se deben dar inicialmente en la fase de desarrollo y manifestarse en las diferentes integraciones de los sistemas, más no pretender que las pruebas exploratorias indiquen que las funciones del sistema funcionen correctamente, sino entender que el concepto es en si mismo, la detección de fallos y errores.

Advertisements

A mejor Testing, peor calidad de Software?

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.

    ¿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