Test-Driven development (TDD) es una práctica de programación que implica el desarrollo de pequeñas piezas de código basándose en test cases escritos con anterioridad. ¿Y esto que quiere decir? Quiere decir que el desarrollador escribe los test cases antes de escribir el código.  El tipo de pruebas (test cases) que hace el desarrollador suelen ser unitarias y automatizadas. ¿Como funciona?:

1. Se selecciona un requisito.
2. El desarrollado escribe el test case o test cases para probar ese requisito.
3. Los ejecutan los test. Con el resultado de que todos los test cases fallarán (si el test no falla esto quiere decir que el requisito probablemente ya ha sido implementado o hemos escrito incorrectamente el test case)
4. Se implementa el código, de tal manera que haga que la prueba pase satisfactoriamente.
5. Una vez terminamos, se hace “refactoring”, para eliminar código duplicado.
6. Podríamos lanzar los test cases otra vez para verificar que no hemos roto nada durante el refactoring.

La idea principal de esta técnica de programación es que los requerimientos sean traducidos a pruebas, así cuando las pruebas pasen correctamente estaremos garantizando que los requerimientos se han implementado correctamente. La idea es escribir la menor cantidad de código posible. Una limitación de esta técnica que debemos considerar es que para hacer TDD es necesario que nuestros test cases estén automatizados.

¿Es TDD compatible con el testing tradicional? Por supuesto, no sólo es compatible sino que el hacer TDD no implica que no debamos hacer más testing. Una vez ha terminado el desarrollo usando TDD debemos realizar actividades tradicionales de testing: test de integración, test de sistemas, User Aceptance Test…todo depende de las necesidades de vuestra empresa.

Referencias: http://www.testdriven.com

Las “SLA” o “Service Level Agreement” es un documento contractual entre un cliente y una empresa que ofrece un servicio. Por tanto, las SLA tienen como misión identifican y definen las necesidades del cliente a la vez que controla sus expectativas de servicio en relación a la capacidad del proveedor, proporciona un marco de entendimiento entre ambos. En el mundo del testing, como en cualquier otro ámbito, debemos de establecer unas SLAs si trabajamos con proveedores en nuestro entorno de testing. Algunas caracteríticas que debe de incluir son:

• Identificar y definir las necesidades del cliente.
• Establecer un marco de trabajo.
• Simplificar situaciones complejas.
• Reducir conflictos entre areas.
• Fomentar el diálogo en caso de controversias.
• Eliminar expectativas poco realistas.

Esto no es, por supuesto, trivial y depende mucho de la empesa. La complejidad y la terminología por sí solo puede hacer que sea una tarea de enormes proporciones. Sin embargo, hay métodos para hacerlo mucho más manejable. El más común es usar una plantilla. En internet podréis encontrar cientos de ellas que se pueden usar como base y adaptarla a las necesidades de tu empresa. Lo que si se debe de tener en cuenta es que las SLA son una manera de medir la calidad de un servicio, por tanto debemos definir unas KPIs (Key Performance Indicators) que nos permitar cuantificar el servicio.

Una vez tenemos identificados los KPIs, podremos monitorizar el servicio y asociar este servicio a unos precios.

¿Cuales son los beneficios de las SLAs? Nos permite conseguir el nivel de calidad acordado, por tanto, conseguir un buen servicio.

En resumen, estos serían los puntos a seguir:

1. Definir los SLR (Service Level Requirements).
2. Identificar los KPIs.
3. Definir los niveles de servicio.
4. Asignar precios a los niveles de servicio anteriormente definidos.
5. Mejorar y mantener los niveles de servicio.

En alguna otra ocasión habíamos hablado sobre los “Smoke Test” y su importancia en las actividades diárias de un equipo de testing. En aquella ocasión surgió el termino “Sanity Testing” o “Sanity Check”.

En algunas ocasiones estos términos pueden ser confusos, así que vamos a intentar definir el término Sanity Test y en que ocasiones podemos realizar este tipo de actividad.

¿Que características principales tiene un Sanity Test?:

• Pequeña prueba de regresión que se centra en una o varias áreas de funcionalidad.
• Permite una rápida evaluación.
• Permite conocer el estado de nuestra aplicación y verificar que todo sigue funcionando correctamente después de algún pequeño cambio.
• Comprueban si se cumplen los requisitos o no.
• A diferencia de los smoke test, estas pruebas son más exhaustivas y más en detalle.
• Estas pruebas intentan evitar pérdida de tiempo y esfuerzo.

Estás son algunas características básicas, todo depende del sector y de la empresa.

Debido a que durante el desarrollo de cualquier producto software se identifican un gran número de defectos, en muchos casos de alta prioridad o prioridad crítica, un equipo para la revisión de defectos (Defects Review Team) es esencial en cualquier equipo de testing.

Un DRT (Defects Review Team) proporciona una rápida y eficiente respuesta a un defecto en cualquiera de nuestros entornos y garantiza una oportuna solución. El equipo estará integrado por los siguientes miembros:

• Responsable del equipo de desarrollo (Development team leader).
• Jefe de proyecto (Project manager).
• Responsable del equipo de pruebas (QA team lead).
• Cliente (Opcional). Es importante que el cliente forme parte de este equipo, aunque no siempre es posible su participación.

Plan de acción:

Lo primero que debemos hacer es establecer un plan de acción. Podemos establecer reuniones semanales para discutir los defectos más importantes…pero claro, una revisión semanal en algunos casos puede no ser suficiente, y una reunión diaria puede ser deficil de conseguir. ¿Que podríamos hacer? Podemos establecer como norma, una reunión semanal y después, cada miembro del equipo se debe comprometer a revisar diariamente los defectos. En caso de que sea necesario se pueden establecer reuniones ocasionales si fuese requerido.

Nuestro plan de acción:

1. Todos los miembros del DRT deben de ser notificados, por ejemplo via email, de todos los defectos de prioridad alta y crítica.
2. Semanalmente se discuten los defectos más importantes. Los defectos ya existentes se revisan para asegurarnos que el defecto no está duplicado.
3. Si el defecto es válido, se introduce en nuestro DTS (Defect Tracking System) como “OPEN” (más tarde serán asignados por el responsable de desarrollo).
4. Se revisan los defectos críticos que deberían haber sido arreglados y que aún no están solucionados. Se analizan las causas y se establece un plan de acción, ¿como podemos arreglar lo antes posible?.
5. Haremos análisis a largo plazo…¿Que acciones debemos tomar para que defectos así no vuelvan a repetirse?.
6. Debemos de establecer timelines en la resolución de defectos a corto plazo.

El Plan de pruebas describe la estrategia, recursos y planificación de nuestras pruebas. Esta estrategia incluye la definición del tipo de pruebas a realizar para cada iteración, la cobertura y objetivos…en definitiva, el test plan representa el proceso de pruebas. Es importante detallar lo que está dentro del “scope” de las pruebas y lo que no se testeará.

La función principal del Test Plan es ayudarnos en la realización de las pruebas…por ello debe al menos incluir:

• Definir objetivos de las pruebas.
• Definir de los elementos que se van a probar.
• Enfoque o estrategia que se usará.
• Recursos y planificación necesarios.

Adjunto una plantilla que he obtenido de la “IEEE” que os puede servir como ejemplo. A partir de ella podreís crear vuestra propia plantilla que se adapte a las necesidades de vuestra empresa.

Test Plan Template

¿Es bueno tu proceso de testing? Esta es una pregunta muy fácil de hacer y muy dificil de contestar. Las pruebas de software amenudo consumen mucho tiempo y dinero. Muchas organizaciones se han dado cuenta que mejorando sus procesos de pruebas pueden solucionar estos problemas. Sin embargo, en la practica resulta mucho más dificil saber que medidas tomar para mejorar y controlar el proceso.

El modelo TPI está basado en las mejores prácticas de la industria relativas a la mejora del proceso de pruebas. El modelo incluye guías prácticas para evaluar el nivel de madurez de prueba de una organización así como los pasos para mejorar el proceso.

El modelo se compone de 20 Áreas Clave, que constituyen la base para mejorar y estructurar el proceso de Test. Esta es la lista completa:

-Test strategy
-Life-cycle model
-Moment of involvement
-Estimating and planning
-Test specification techniques
-Static test techniques
-Metrics
-Test automation
-Test environment
-Office environment
-Commitment and motivation
-Testing functions and training
-Scope of methodology
-Communication
-Reporting
-Defect management
-Testware management
-Test process management
-Evaluation
-Low-level testing

Niveles de Madurez
Los requisitos para cada nivel están definidos en forma de Checkpoints, que son preguntas que necesitan ser respondidas afirmativamente para poder calificar a dicho nivel. A partir de las listas de verificación se puede evaluar un proceso de pruebas y se puede determinar para cada Área Clave el Nivel alcanzado. A medida que se considera mejorada cada Área Clave, los checkpoints son acumulables.

Para poder clasificar para el nivel B, el proceso de pruebas necesita responder afirmativamente tanto a los Puntos de Verificación del nivel B como del nivel A.

Matriz de madurez
Cada área con diferentes niveles de madurez. Los niveles de todas las Áreas Clave están integrados en una Matriz de Madurez. Por consiguiente, los niveles de madurez indican el estado de cada área clave.

La matriz de madurez viene determinada por una escala que va del 1 al 13:

- Controlada (1 al 5)

- Eficiente (6 al 10)

- Optimizada (11 al 13)

El modelo TPI ofrece el soporte necesario para mejorar el proceso de test a través de la obtención de rápida manera, se considera el modelo como una herramienta de estructuración de acciones de mejora del proceso de test.

Referencias:
“Test Process Improvement, a practical step-by-step guide to structured testing”

Addison-Wesley, ISBN 0 201 59624 5

MoProSoft es un modelo de procesos para la industria de software en Mexico. Desarrollado por iniciativa de la Secretaria de Economia y con el apoyo de empresarios y academicos mexicanos. Fomenta la estandarizacion a traves de buenas practica en al gestion y desarrollo de software.

Referencia:
Podeis encontrar mas informacion sobre este modelo en:

http://www.enterate.unam.mx/Articulos/2006/marzo/moprosoft.htm

James Bach es uno de los Gurus sobre Rapid Testing, realiza multiples seminarios y conferencias alrededor del mundo (junto con Michael Bolton) sobre este tema. Os recomiendo la asistencia a alguno de estos seminarios si teneis la oportunidad, sino, hay un libro introductorio a esta materia que es de muy facil lectura que se titula “Introducction to Rapid Software Testing” escrito por Chris Brown, Gary Cobb, Robert Culbertson en el 2002.

Los test dinámicos los usaremos para realizar un gran variedad de pruebas, desde test funcionales, de rendimiento, stress…son muy importantes, ya que si la planificación, diseño, desarrollo y ejecución de los test dinámicos no se hace correctamente, el proceso de testing será ineficiente. Los test dinamicos no sólo son ejecutados por el equipo de testing, debería de ser también parte de los test unitarios y de integración del equipo de desarrollo.

Referencias
+ “Rapid Testing”, By Robert Culbertson, Chris Brown, Gary Cobb. Published by Prentice Hall. ISBN-10: 0-13-091294-8; ISBN-13