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?:
- Se selecciona un requisito.
- El desarrollado escribe el test case o test cases para probar ese requisito.
- 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)
- Se implementa el código, de tal manera que haga que la prueba pase satisfactoriamente.
- Una vez terminamos, se hace “refactoring”, para eliminar código duplicado.
- Podríamos lanzar los test cases otra vez para verificar que no hemos roto nada durante el refactoring.
Read more
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.
Read more
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?: Read more
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.
Read more
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.
Read more
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.
MoProSoft establece y emplea un patrón para definir cada proceso. El patrón de procesos es una agrupación esquemática de los elementos que configuran un proceso. Está formado por tres partes: Definición general del proceso, Prácticas y Guías de ajuste.
¿Para que sirve MoProSoft? Principalmente para mejorar la calidad del software desarrollado por la empresa. Pretende elevar la capacidad de las empresas para alcanzar niveles altos de calidad y aumentar asi su competitividad. Este modelo permite a las empresas mexicanas medir su nivel de madurez.
Existe también un herramiento llamada Kuali que ofrece la posibilidad de administrar proyectos basados en MoProSoft.
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.
Read more
TMM es la abreviación usada para Test Maturity Model. El TMM es un proceso de madurez del test que fue originalmente creado por el Illinois Institute of Technoloogy como guía para la mejora de procesos de testing y como complemento al CMM(i).
La estructura del TMM está basada en el CMM y en su fases, ya que consiste también en 5 niveles que reflejan el grado de madurez del test. Para cada nivel de madurez, hay definidas un número de procesos. Los cinco niveles del TMM ayudarán a una organización a determinar la madurez de sus procesos de test y a identificar los pasos a seguir para introducir las mejoras necesarias para lograr niveles mayores de madurez.
Los niveles de madurez son:
o Nivel 1 – Inicial: El test está sumido en un proceso caótico ó simplemente no hay test alguno.
o Nivel 2 – Definición: Se caracteriza por la utilización de técnicas básicas de test que identificarán si el software está de acuerdo con sus especificaciones. Estructuración del proceso de test, planificaciones y estrategias.
o Nivel 3 – Integración: Se caracteriza por el test está completamente integrado en el ciclo de vida del software y es reconocido a todos los niveles del modelo en V. El Plan de test está terminado, las estrategias han sido determinadas en función del previo análisis de riesgos basados en los requisitos.
o Nivel 4 – Gestión y Medición: El test es un proceso medido y cuantificado. La usabilidad es uno de los atributos de calidad utilizados en el test de software.
o Nivel 5 – Optimización, Prevención de defectos y control de calidad: Se caracteriza por mecanismos precisos para que el test pueda ser mejorado continuamente. En este nivel se utilizan procedimientos para seleccionar y evaluar herramientas de test.
Cada día los sistemas son más y más complejos, haciendo necesario que se tomen encuenta mejoras en la calidad de nuestros procesos para mejorar así la calidad final del producto. El modelo TMM nos proporcionará y proceso de desarrollo de software más eficiente y efectivo. Nuestro objetivo será a prevención y no en la detección.
En la web de la fundación TMM se puede encontrar muchísima documentación sobre el modelo TMM y algunos casos prácticos.
Referencias:
+ http://www.tmmifoundation.org/
Normalmente, el testing está considerado como parte del Ciclo de Vida de Desarrollo de cualquier aplicación (Requisitos, análisis & diseño, implementación, testing y deployment), pero el testing, a su vez, tiene su propio ciclo de vida. Dependiendo de la organización, este ciclo puede tener más o menos fases, pero acontinuación comentaré las fases que son siempre comunes.
A grandes rasgo, podemos decir que el ciclo de vida del Software Testing incluye las siguientes fases:
1. Planificación.
2. Análisis
3. Diseño
4. Ejecución
5. Ciclos
6. Pruebas Finales e Implementation
7. Producción
Read more
