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

Scott W. Ambler + Associates
 
     Home  |  Articles  |  Books  |  IT Surveys  |  Podcasts  |  Contact Us  |  Announcements  |  Site Map
Recently reviewed 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

Disciplined Agile Delivery This book, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise describes the Disciplined Agile Delivery (DAD) process decision framework. The DAD framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and provides the foundation for scaling agile. This book is particularly important for anyone who wants to understand how agile works from end-to-end within an enterprise setting. Data professionals will find it interesting because it shows how agile modeling and agile database techniques fit into the overall solution delivery process. Enterprise professionals will find it interesting beause it explicitly promotes the idea that disciplined agile teams should be enterprise aware and therefore work closely with enterprise teams. Existing agile developers will find it interesting because it shows how to extend Scrum-based and Kanban-based strategies to provide a coherent, end-to-end streamlined delivery process.

Translations:



Disciplined Agile Delivery: The Foundation for Scaling Agile Agile Modeling: Practices for Scaling Agile Agile Data: Practices for Scaling Agile EnterpriseUP: Agility at Scale AgileUP: Towards Disciplined Agile DeliveryAmbysoft Inc. Software Development Practices Advisor Scott Ambler + Associates Follow @scottwambler on Twitter!


Copyright 2004-2012 Scott W. Ambler

This site owned by Ambysoft Inc.