La parte dificil de construir sofware es la especificación

La parte difícil de construir software es la
especificación, el diseño y la verificación de esa
trama conceptual, no la tarea de representarla y
testear la representación.

Esta elegante definición la pude ver en apuntes que suelo revisar sobre los distintos aspectos de la Ingeniería del Software y me dió que pensar.

En la mayoría de las oportunidades en que hemos tenido reuniones de equipo para hablar de nuestras fortalezas y debilidades en base al éxito o al fracaso de algún proyecto reciente, se nos hizo notar que nuestro equipo debe preponderar en la intensión de hacer ingeniería.
Son incontable las veces en que se describió mentalmente el proceso existente, en esas reuniones. Pero en cada una de las oportunidades en que se presenta

Quien estima mejor?

Tu estimación del proyecto por quien ha sido realizada?

Developer / Project Manager / Project Tracker / Testing Team / Quality Assurance team.

Según los roles serán las estimaciones. Pero esto no debería ser así o es lo más lógico?

Algo de Testing Automatizado

Objetivos del Testing Automatizado

  • Tests should improve quality

  • Tests should help us understand the system under test

  • Tests should reduce risk

  • Tests should be easy to run

  • Tests should require minimal maintenance as the system evolves

  • Tests should be executed as part of the build process if possible

     

    Tipos básicos de Testing donde se puede automatizar

    • Unit tests

    • Customer Test

    • GUI Testing

     

    Que tener en cuenta para iniciarse en los Procesos Automatizados de Pruebas

    ¿Cuales son los objetivos de nuestro Testing Automatizado?  Estos deben estar alineados con todos los objetivos de Calidad. Algunos factores que afectarían a nuestros objetivos:

    Deseamos automatizar las pruebas regresivas?

    Deseamos realizar Integración Continua en nuestro Proceso de Desarrollo?

    Estamos buscando resolver un ítem específico de Aseguramiento de Calidad?

    Comencemos a Organizarnos

    Elegir una estrategia

    Escojamos un Tipo Básico de Testing al que nos queremos aproximar con la automatización. Debería ser una combinación de aproximaciones basadas en:

    • Objetivos
    • Tipo de sistema que queremos Testear:
      • Testabilidad. Definir la capacidad del sistema a soportar automatización de pruebas
      • Nivel de automatización actual. Si la base es cero podría ser el peor escenario
    • Podemos modificar el Proceso de Desarrollo y los Requisitos del Sistema para lograr una aproximación al nuevo Ciclo de Vida que exigen las pruebas automatizadas?
    • Con solo la automatización de pruebas resolvemos algún problema o debemos tener en cuenta otros ítmes?
    • Seleccionemos un tipo de Testing Automatizado: Unitario, Integración , Requerimientos, etc.

    Seleccionemos las herramientas basándonos en

    • Estrategia seleccionada
    • Orientación del Testing Automatizado (Aceptación del Cliente, de Componente, GUI)
    • Open Source o Comercial?
    • La aplicación seleccionada se adapta a nuestra aplicación o debemos hacer adaptaciones de la aplicación a la herramienta?
    • Definamos cuales son nuestros costos

    Dos puntos son necesarios para facilitar el mantenimiento

    • Definamos las expectativas de la Gestión de las pruebas
    • Definamos los estándares o patterns para implementar las pruebas automáticas.

    Por ejemplo usemos Palabra Clave como patrón que puede utilizarse para reducir los costos de mantenimiento al utilizar la interfaz de usuario basada en la automatización. Algunos de los enfoques de benefician directamente con el trabajo de control de calidad.

    El enfoque que realizamos afectan a las acciones 

    • Los desarrolladores serán responsables de crear y mantener las Unidades de Pruebas Automatizadas, aunque puede ayudar a QA y su criterio será fundamental
    • SQA puede crear los otros tres tipos de pruebas automatizadas, como siempre lo mejor es integrar directamente en el proceso de desarrollo
    • Debemos asegurarnos de que el Testing Automatizado es realmente parte del proceso y se complementa con el Testing No Automatizado

    Revisemos el Plan de Pruebas Automatizadas

    En todos los casos se debe hacer revisiones de la efectividad del proceso y buscar la forma de mejorarlo. Las siguientes cuestiones podrían ayudarnos:

    • Son lentas las automatizaciones?
    • Son difíciles de mantener?
    • Disminuyen la velocidad del Proceso de Desarrollo?
    • Son eficaces en el logro de nuestros objetivos de calidad?

    Estas pruebas tienen como principales objetivos comprobar que el código se comporta de la manera esperada y prevenir la aparición de errores inesperados al modificar o refactorizar el código. También, en algunos casos como en el desarrollo dirigido por pruebas, las pruebas unitarias ayudan a obtener el diseño del código. Las ventajas de realizar este tipo de pruebas son: código más depurado, mayor seguridad a la hora de refactorizar y mayor velocidad de desarrollo, aparte de obtener código de mayor calidad asegurando que nada se ha roto cuando cambiamos la lógica interna del software.

    Actualmente las pruebas unitarias se desarrollan con herramientas tipo jUnit [3] y objetos mock [4]. Las herramientas tipo jUnit se aplican para comprobar que el estado de un objeto, los valores retornados por los métodos, excepciones lanzadas, etc, son los esperados. Los objetos ficticios o mocks, en cambio, permiten aislar el código a probar de las dependencias con otras clases colaboradoras mediante el desarrollo de clases ficticias que simulan el comportamiento de estas clases colaboradoras. Esto permite centrar la prueba sólo en el código que se desea probar.

    Aquí introduzco conceptos de Testing Driven Development (TDD) tomados de un blog amigo WebTrun:

    SlideShare | View | Upload your own

    Las organizaciones son tan eficientes como sus procesos

    El diseño de un flujo de trabajo no es solamente un medio de documentar procesos, sino que es la guía de trabajo para el ambiente operativo.

    Es necesario diseñar con consenso de las partes, los flujos de trabajo para los procesos de negocio que acompañen el ciclo de vida completo de las interacciones Cliente-Organización-Usuarios.

    No se puede pretender eficiencia de los procesos cuando se ingresan cambios sin tener en cuenta el impacto global y particular en las distintas PA y las personas que interactúan en ellas. O solamente pensando en un resultado puntual que sirve a un propósito de corta data.

    Finalmente, hay que entender el por que de hecho de que la mayoría de las empresas tomaron conciencia de lo imprescindible de contar con una herramienta que coordine el trabajo y permita compartir actividades, información y recursos en un ambiente simple de operar y monitorear.

    Cronograma de proyectos, agendas de trabajo, dependiencias y criterios de completitud

    Resulta importante no hacer recortes en las actividades que tienen relación con el aseguramiento de calidad y las fechas de entrega no pueden poner en riesgo el aseguramiento de calidad, y los esfuerzos correctivos deben realizarse durante el proyecto y no al final cuando es prácticamente imposible.

    Esto implica que debe plantearse una estrategia que sea sostenida durante todo el ciclo de vida del proyecto y que se apliquen las tácticas adecuadas para evitar desplazamientos que pongan en riesgo tanto la fecha de entrega como la calidad en si.

    Es fácil observar que las agendas particulares que genera el cronograma del proyecto, tienen fuerte dependencias con otros integrantes del equipo y no es aceptable romper esas dependencias sin considerar los impactos de esas rupturas (básicamente cambio en la agenda de algún integrante). Este tipo de ruptura implica una falta al compromiso con el recurso dependiente y principalmente con la actividad planificada, lo cual quiere decir que alguien deberá realizar mayores esfuerzos para lograr cumplir con los elementos satisfactores que darán completitud a la actividad.

    Es cierto que la mayoría de las veces no son intencionales tales incumplimientos, sobre todo en algunas personas con roles específicos, que reciben pedidos en carácter de urgente. Sin embargo, si existe una planificación y se crea una agenda personal que incluye actividades con dependencias hacia otras actividades de otros recursos (agenda global), todo esto debería anteponerse a la fuerte necesidad de responder a las necesidades instantáneas de los superiores del organigrama.

    De no ser posible, debe consensuarse con los involucrados y modificar las condiciones de cumplimiento y aceptación (negociación), pero esto idealmente, no debería ser una constante hacia adentro, que implosione, sino que es mucho más saludable sostener un carácter de cumplimiento con las actividades con dependencias y el carácter negociador con los que generan nuevos pedidos en forma constante.

    En definitiva si permanecemos en la actitud de modificar nuestras actividades rompiendo dependencias sin negociar, vamos en contra de los principios de Completitud, que pertenecen a los axiomas del aseguramiento de calidad. ¿No es completitud la palabra más utilizada por los superiores de la organización a la hora de una refriega por incumplimiento?

    Ahora que estamos obligados a trabajar con agendas visibles para La Gerencia y el resto de los integrantes de la compañía, logremos que no se nos vuelva en contra y aprendamos a manejar todos los elementos que implica llevar una “agenda de compromisos”. Que cada ítem que ingresamos deje de ser un elemento de reclamo y acusaciones constantes.

    Mi rol, mi evolución, mis quedos, mi dejos

     

    Como Responsable SQA y QAC, sostengo mi crecimiento permanente basándome en la vida misma de los proyectos, en las interdependencias profesionales y en la relevancia de nuestras soluciones para el usuario. 

    La formación de un proceso particular y nuestra adaptación no ha sido fácil. Principalmente nos ha sido imposible automatizar las pruebas para un entorno de desarrollo basado en la API de Lotus Note, de IBM y todo lo que pueda existir para automatizar pruebas a cualquier nivel nos resultó bastante costoso, en lo que a tiempo y esfuerzo se refiere.

    Es así que me he puesto en la tarea de mejorar todos los procesos intrínsecos, previos a cualquier desarrollo.

    La estrategia global implicó lograr alertar fallos utilizando un símil  AMFE en los requerimientos, también en fases de Análisis y Diseño. Posteriormente establecer una cadena de revisiones para las soluciones técnicas propuestas, mas estudios de viabilidad y factibilidad de Despliegues de Productos, tratando de detectar y minimizar cualquier merma de la calidad que impacten en los eslabones finales de la cadena de producción.

    Como estrategia para pruebas, generamos la cantidad de ambientes de Testing que fueran necesarios, basándonos primariamente en los ciclos que dimos de alta en el cronograma del proyecto.

    Nuestra táctica implica la formación de una alta cantidad ciclos con una gran cantidad de Pruebas de Integración, que no son coincidentes con Versiones Candidatas del producto, sino que en cada integración nos vamos acercando a dichas versiones. Al lograr integrar todos los componentes que conforman un módulo testeable a nivel de pruebas funcionales, versionamos el producto y ejecutamos el ciclo funcional correspondiente.

    Esto esta lejos de ser una Integración Continua, pero es la aproximación mínima que he podido idear para que la mayoría de los defectos se detecten con bastante antelación.

    Conformamos un equipo chico de desarrollo, con un Responsable que hace las gestiones de seguimiento de avances de los componentes y determina en base al cronograma, el hito de integración de componentes, del mismo modo la conformación de los módulos y notificaciones al LP y SQA, de los módulos que están disponibles para pruebas de funcionales.

    La envergadura del equipo exige que los mismos desarrolladores ejecuten los ciclos de pruebas integradoras y lo hacen bajo un esquema de revisiones cruzadas. SQA asigna también un equipo de Testeadores que ejecutan pruebas integrales ayudando a acelerar el proceso.

    Previo a esto, sin duda alguna tuvimos que elevar el Skill de los Desarrolladores de esta tecnología tan particular, en lo que respecta a técnicas de pruebas y detección de fallos.

    Todos los fallos, defectos y errores son registrados y puestos a consideración de SQA y el LP quienes en un solo lote hacen las derivaciones para resoluciones, en base a la severidad y prioridad determinada en un análisis exhaustivo.

    Este accionar nos ha llevado rápidamente a una disminución significativa de fallos detectados en ciclos de pruebas funcionales de versiones candidatas y a una desaparición del 100% de fallos del tipo Invalidante y del 80% de fallos del tipo Grave.

    Las actividades de Despliegue en si mejoraron y garantizaron mejores funcionamiento cuando se comenzó a utilizar el elemento "Pruebas de Campo" y finalmente nuestro equipo de Soporte cuenta con una gran biblioteca de fallos detectados los cuales alimentan su base de conocimientos a cerca de como se podría presentar un fallo y como se orienta a su rápida resolución.

    Poco a poco trataré de mostrar los procesos aunque no pueda dar demasiados detalles, lo haré genérico.

    Powered By Blogger