Metodo de Pruebas Orientada a Objetos para el Ciclo de Vida Completo

Ronin

Services

Training

Publications

Downloads

Careers

Metodo de Pruebas Orientada a Objetos para el Ciclo de Vida Completo (FLOOT)

Documento Técnico de Ronin International,Inc

Por Scott W. Ambler, Consultor Senior, Ronin International, Inc.
Traducido al español por

La metodología de Pruebas Orientada a Objetos para el Ciclo de Vida Completo(en ingles "Full Life-Cycle Object-Oriented Testing", FLOOT) es una colección de técnicas para verificar y validar software orientado a objetos. El ciclo de vida FLOOT, que se puede ver en la Figura 1 , indica una amplia variedad de técnicas (descritas en la Tabla 1 ) que estan disponibles en todos los aspectos del desarrollo de software. La lista de técnicas no pretende ser completa – por el contrario su objetivo es hacer explícito el hecho de que usted cuenta con un amplio rango de opciones disponibles . Es importante entender que aunque el metódo FLOOT es presentado como una colección de fases secuenciales no necesariamente tiene que ser así: las técnicas de FLOOT pueden ser aplicadas también con procesos agiles/evolutivos. La razón por la que presento FLOOT de una forma “traditional” es para volver explicito el hecho de que en realidad usted puede realizar pruebas en todos los aspectos del desarrollo de software no solamente durante la codificación.

Figura 1. El Ciclo de Vida FLOOT.

Tabla 1. Técnicas de Prueba.

Técnica FLOOT	Descripción
Prueba de Caja-Negra	La prueba verifica que el ítem que se esta probando, cuando se dan las entradas apropiadas produce los resultados esperados.
Prueba de Valores-Frontera	Es la prueba de situaciones extremas o inusuales que el ítem debe ser capaz de manejar.
Prueba de Clases	Es el acto de asegurar que una clase y todas sus instancias cumplen con el comportamiento definido .
Prueba de Integración de Clases	Es el acto de asegurar que las clases, y sus instancias, conforman un software que cumple con el comportamiento definido.
Revisión de Código	Una forma de revisión técnica en la que el entregable que se revisa en el código fuente.
Prueba de Componente	Es el acto de validar que un componente funciona tal como esta definido.
Prueba de Cubrimiento	Es el acto de asegurar que toda línea de código es ejercita al menos una vez.
Revisión de Diseño	Una revisión técnica en la cual se inspecciona un modelo de diseño.
Prueba de Regresión de Herencia	Es el acto de ejecutar casos de prueba de las súper clases, tanto de forma directa como indirecta, en una subclase especifica.
Prueba de Integración	Consiste en realizar pruebas para verificar que un gran conjunto de partes del software funcionan juntas.
Prueba de Método	Consiste en realizar pruebas para verificar que un método (función miembro) funciona tal como esta definido.
Revisión de Modelos	Un tipo de inspección, que puede ser desde un revisión técnica formal hasta un recorrido informal , realizado por personas diferentes a las que estuvieron directamente involucradas en el desarrollo del modelo.
Prueba de Caminos	Es el acto de asegurar que todos los caminos lógicos en el código se ejercitan al menos una vez.
Revisión de Prototipos	Es un proceso mediante el cual los usuarios trabajan a través de una colección de casos de uso, utilizando un prototipo como si fuera el sistema real. El objetivo principal es probar si el diseño del prototipo satisface las necesidades de esos usuarios.
Demostrar con el código	La mejor forma de determinar si un modelo realmente refleja lo que se necesita, o lo que se debe construir, es construyendo software basado en el modelo para mostrar que el modelo esta bien
Prueba de Regresión	El acto de asegurar que los comportamientos previamente probados todavía trabajan como se espera luego que se han realizado cambios a la aplicación.
Prueba de Stress	El acto de asegurar que el sistema funciona como se espera bajo grandes volúmenes de transacciones, usuarios, carga y demás.
Revisión Técnica	Una técnica de aseguramiento de la calidad en la cual el diseño de tu aplicación es revisado de forma exhaustiva por un grupo de tus compañeros. Una revisión típicamente se enfoca en la precisión, calidad, facilidad de uso y completitud. A este proceso usualmente se le llama recorrido, inspección, o revisión de compañeros.
Prueba de Escenarios de Uso	Una técnica de prueba en la cual una o mas personas validan un modelo siguiendo la lógica de los escenarios de uso.
Prueba de Interfaz de Usuario	Consiste en probar la interfaz de usuario para garantizar que cumple los estándares y requerimientos definidos. Usualmente se refiere a la prueba de interfaz de usuario gráfica.
Prueba de Caja-Blanca	Consiste en realizar pruebas para verificar que líneas especificas de código funcionan tal como esta definido. También se le conoce como prueba de caja-transparente.

Quisiera compartir algunas de mis filosofías personales con respecto a las pruebas:

El objetivo es encontrar defectos. El propósito principal de las pruebas es validar la correción de aquello que se cualquier artefacto que se este probando. En otras palabras, las pruebas exitosas encuentran defectos.
Se pueden validar todos los artefactos. Tal como veremos en este capitulo, se pueden probar todos los artefactos no solamente el código fuente. Como mínimo usted puede revisar los modelos y documentos y por lo tanto encontrar y corregir los defectos antes que lleguen al código.
Probar frecuentemente y temprano. El potencial para el costo del cambio de aumentar exponencialmente lo motiva a probar tan temprano como sea posible (ver articulo "cost of change").
Las pruebas construyen confianza. En "" Kent Beck realiza una observación interesante de que cuando usted tiene un suite completa de pruebas ( una suite de pruebas es una colección de pruebas), y usted la ejecuta tan frecuentemente como sea posible, entonces eso le da el coraje para avanzar. Muchas personas temen realizar cambios al código porque temen dañarlo, pero como una suite completa de pruebas si se daña algo, se sabe que se detectará y entonces se corrige.
Probar contra el riesgo de un artefacto. Entre mas riesgos es algo, mas es necesario que sea revisado y probado. En otras palabras, se debe invertir un gran esfuerzo en probar un sistema de control de trafico aereo pero no mucho menos que para probar una aplicación “Hello World” .
Una prueba vale mil opiniones. Usted puede decirme que su aplicación funciona, pero mientras no me muestre los resultados de las pruebas, no te creeré.

Este documento fue tomado de la tercera edición de "The Object Primer", a ser publicado en el March de 2004.

Otros Documentos de Interes:

Analizando la curva del costo del cambio (explica porque FLOOT es tan importante)
FLOOT fue presentado por primera vez en "Building Object Applications That Work", evoluciono en "Process Patterns", y una vez mas en "The Object Primer".

Ronin International,Inc esta muy interesada en trabajar con organizaciones a nivel mundial

Original English Version