Código fomento

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 dos tipos de pruebas  caja blanca (o estructurales)
Se analiza la estructura interna del programa inspeccionando el códigocumple 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

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 conjuntoBig 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 complicadoIntegració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 problemasPrueba beta
Con el usuario final en su propio lugar de trabajo El desarrollador no está presente, pero será informado por el usuarioPrueba del sistema
Para verificar funcionalidad y rendimientoPrueba de recuperación
Se fuerza el fallo del software y se comprueba que la recuperación es satisfactoriaPrueba de seguridad
Se intenta verificar que el sistema está protegido contra accesos ilegalesPrueba de resistencia o estrés
Enfrenta al sistema con situaciones que demandan gran cantidad de recursos

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 relacionesDiagramas de paquetes
Reflejan la organización de paquetes y sus elementosDiagramas de despliegue
Especifica el hardware físico sobre el que el sistema se ejecutará y como el software se despliega en ese hardwareDiagramas de estructuras compuestas Diagramas de componentes Diagramas de comportamiento
Se centran en lo que debe suceder en el sistemaDiagramas de estado
Para analizar los cambios de estado de los objetosMuestra los estados, eventos, transiciones y actividades de los objetosDiagramas de actividad
Se utiliza para mostrar la secuencia de actividades Muestran el flujo detallando las decisiones que surgenDiagramas de casos de uso
Se utiliza para entender el uso del sistemaDiagramas de interacción Diagramas de secuenciaDiagrama resumen de interacción Diagrama de comunicación Diagrama de tiempo

Bad smells (malos olores) Duplicated code

Si sedetecta el mismo código en más de un lugar, se debe buscar la forma de extraerlo yunificarlo 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 Longparameter 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

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 

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