Ambysoft logo

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

by Scott W. Ambler

traducido al español por Carlos MÃndez

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:

  1. 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.
  2. 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.
  3. 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").
  4. Las pruebas construyen confianza. En "Extreme Programming Explained" 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.
  5. 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" .
  6. 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Ã.


Suggested Reading

Choose Your WoW! 2nd Edition This book, Choose Your WoW! A Disciplined Agile Approach to Optimizing Your Way of Working (WoW) – Second Edition, is an indispensable guide for agile coaches and practitioners. It overviews key aspects of the Disciplined Agile® (DA™) tool kit. Hundreds of organizations around the world have already benefited from DA, which is the only comprehensive tool kit available for guidance on building high-performance agile teams and optimizing your WoW. As a hybrid of the leading agile, lean, and traditional approaches, DA provides hundreds of strategies to help you make better decisions within your agile teams, balancing self-organization with the realities and constraints of your unique enterprise context.

Translations: