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
 
    Home  |  Articles  |  Agility@Scale Blog  |  Books  |  IT Surveys  |  Podcasts  |  Contact Me  |  Mailing List  |  Site Map
Order now! 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é.

 

Otros Documentos de Interes:

 

The Object Primer 3rd Edition: Agile Model Driven Development (AMDD) with UML 2 Este documento fue tomado de la tercera edición de "The Object Primer", a ser publicado en el March de 2004.

 

Translations:


 Copyright © 2004-2009 Scott W. Ambler


 Agile Data (AD)  |  Agile Modeling (AM)  |  Agile Unified Process (AUP)  |  Enterprise Unified Process (EUP)  

Follow Scott W. Ambler on Twitter