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
