Un caso de prueba conjunto entradas, condiciones ejecución y resultados esperados. Para llevar a cabo un caso de prueba tenemos seleccionar unos valores de entrada y conocer el comportamiento que tendría que tener el sistema ante esos valores. Hay dos tipos de pruebas:

• Caja blanca (o estructurales): Se analiza la estructura interna del programa inspeccionando el código. Cumple: Todas las sentencias se ejecutan al menos una vez. Todas las condiciones se ejecutan en su parte verdadera y en su parte falsa. Los bucles se ejecutan en sus límites. Todas las estructuras de datos se usan para asegurar su validez.
• Caja negra (o de comportamiento): Sólo se comprueba la funcionalidad, es decir, si la salida es adecuada en función de los datos de entrada, sin fijarse en el funcionamiento interno.

Tipos de Pruebas

• Prueba de unidad: Se centra en cada unidad de software, en cada módulo del código fuente. Aquí es donde se utilizan las pruebas de caja blanca y de caja negra.
• Prueba de integración: A partir de los módulos probados individualmente, se prueba el funcionamiento conjunto.
  • Big bang: Consiste en ser estrictos en el orden de probar primero todos los módulos por separado antes de pasar al conjunto. Con este enfoque los errores se acumulan y suele ser más complicado.
  • Integración incremental: Se van incorporando módulos poco a poco y probando su integración. Los errores son más fáciles de localizar así.
• Prueba de validación: En el entorno real de trabajo y con intervención del usuario final. Se basa en determinar si se cumplen los requisitos y se usan para ello pruebas de caja negra.
  • Prueba alfa: Con el usuario final en el lugar de desarrollo. El desarrollador observa y registra los errores y problemas.
  • Prueba beta: Con el usuario final en su propio lugar de trabajo. El desarrollador no está presente, pero será informado por el usuario.
• Prueba del sistema: Para verificar funcionalidad y rendimiento.
• Prueba de recuperación: Se fuerza el fallo del software y se comprueba que la recuperación es satisfactoria.
• Prueba de seguridad: Se intenta verificar que el sistema está protegido contra accesos ilegales.
• Prueba de resistencia o estrés: Enfrenta al sistema con situaciones que demandan gran cantidad de recursos.

UML (Lenguaje Unificado de Modelado)

UML es un lenguaje basado en diagramas para representar modelos de la realidad siguiendo el paradigma de la orientación a objetos. UML define 13 tipos de diagramas divididos en tres categorías:

• Diagramas de estructura: Se centran en los elementos que deben existir en el modelo.
  • Diagramas de clases: Muestran las clases del sistema y relaciones entre ellas.
  • Diagramas de objetos: Representan objetos y sus relaciones.
  • Diagramas de paquetes: Reflejan la organización de paquetes y sus elementos.
  • Diagramas de despliegue: Especifica el hardware físico sobre el que el sistema se ejecutará y como el software se despliega en ese hardware.
  • Diagramas de estructuras compuestas
  • Diagramas de componentes
• Diagramas de comportamiento: Se centran en lo que debe suceder en el sistema.
  • Diagramas de estado: Para analizar los cambios de estado de los objetos. Muestra los estados, eventos, transiciones y actividades de los objetos.
  • Diagramas de actividad: Se utiliza para mostrar la secuencia de actividades. Muestran el flujo detallando las decisiones que surgen.
  • Diagramas de casos de uso: Se utiliza para entender el uso del sistema.
  • Diagramas de interacción:
    • Diagramas de secuencia
    • Diagrama resumen de interacción
    • Diagrama de comunicación
    • Diagrama de tiempo

Bad Smells (Malos Olores) en el Código

• Duplicated code: Si se detecta el mismo código en más de un lugar, se debe buscar la forma de extraerlo y unificarlo.
• Long method: Un método largo normalmente se puede descomponer en otros más pequeños.
• Large class: Una clase debe asumir un conjunto pequeño de responsabilidades.
• Long parameter list: Una lista larga de parámetros puede estar señalando problemas de encapsulación o, al menos, la necesidad de crear una clase de objetos a partir de varios de esos parámetros.
• Divergent change: El desarrollador modifica una clase frecuentemente y por motivos distintos. Quizá convenga eliminar la clase.
• Shotgun surgery: Cuando los cambios realizados en una clase, obligan a modificaciones adicionales para compatibilizar esos cambios.
• Feature envy: Cuando un método usa más elementos de otra clase que de la suya propia. La solución será pasar el método a esa otra clase.
• Data class: Clases que sólo tienen atributos y sus getters y setters. Habrá que reconsiderarlas puesto que no tienen comportamiento.
• Refused bequest: Subclases que sólo usan una mínima parte de la superclase. Puede indicar que la jerarquía de clases no es correcta.

Control de Versiones

• Exclusiva: Para poder realizar un cambio es necesario comunicar al repositorio el elemento que se desea modificar y el sistema se encargará de impedir que otro usuario pueda modificar dicho elemento. Una vez hecha la modificación, ésta se comparte con el resto de colaboradores. Si se ha terminado de modificar un elemento entonces se libera ese elemento para que otros lo puedan modificar. Este modo de funcionamiento es el que usa por ejemplo SourceSafe.
• Colaborativa: Cada usuario modifica la copia local y cuando el usuario decide compartir los cambios el sistema automáticamente intenta combinar las diversas modificaciones. El principal problema es la posible aparición de conflictos que deban ser solucionados manualmente o las posibles inconsistencias que surjan al modificar el mismo fichero.

Tipos de Repositorios

• Centralizados: Repositorio centralizado de todo el código, del cual es responsable un único usuario. Se facilitan las tareas administrativas a cambio de reducir flexibilidad, pues todas las decisiones fuertes necesitan la aprobación del responsable. Algunos ejemplos son CVS.
• Distribuidos: Cada usuario tiene su propio repositorio. Los distintos repositorios pueden intercambiar y mezclar revisiones entre ellos. Es frecuente el uso de un repositorio, que está normalmente disponible, que sirve de punto de sincronización de los distintos repositorios locales. Git.