Testing Funcional

Testing orientado a probar qué hace el sistema, a entender sus funciones. Dichas funcionalidades a probar pueden hallarse en los 4 niveles de testing.

Las técnicas aquí utilizadas son las denominadas de "caja negra", las cuales definen los casos de prueba y las condiciones de test.

Puede ser realizado desde dos perspectivas:

* Basada en requerimientos (requirement-based). Usa la especificación funcional de requerimientos del sistema como base para el diseño de pruebas.
* Basada en el proceso de negocio (business-process-based). Usan el conocimiento del proceso de negocio. Parten de un escenario que se presenta en el día a día para comenzar el diseño de pruebas.

## Técnicas de testing funcional

### Partición de equivalencias

La partición de equivalencias (o de clases) puede ser aplicada en cualquier nivel de testing y generalmente es una buena técnica para comenzar. El enfoque de esta técnica es muy común por lo que muchos testers la practican informalmente, aunque no se den cuenta.

Consiste en dividir un conjunto de pruebas en grupos que puedan ser considerados iguales. Luego de formados los grupos la técnica requiere que se realice sólo una prueba por grupo.

Se puede asumir que todas las condiciones de una partición serán tratadas de la misma forma por el software. Entonces si una prueba funciona, se asume que todas las pruebas funcionarán. En el lado opuesto, si una prueba no funciona, se asume que ninguna lo hará.

Al momento de aplicar la técnica no solo se deben tener en cuenta las particiones que se encuentran en las especificaciones (válidas, entradas esperadas por el software), también se deben incluir las que no han sido especificadas (inválidas, entradas inesperadas por el software).Cabe aclarar que una partición inválida no significa una entrada que no pueda ser procesada por el software, sino que el mismo debería manejar (por ejemplo: a través de un error, remarcando los valores válidos, etc.).

### Análisis de valores límites

Se basa en la prueba de los límites entre particiones (chequeo de rangos). Los límites a probar son válidos (de particiones válidas) e inválidos (de particiones inválidas).

Para aplicar la técnica de análisis de valores límites, se deben tomar los valores mínimos y máximos de cada partición. De esta manera se obtienen dos pruebas de límites por partición. A excepción de las particiones inválidas que se encuentren por fuera de las válidas, aquellas que solo tengan una partición adyacente, en cuyo caso sólo se tomará un valor límite (adyacente a la partición válida).

Es importante dejar en claro que en caso de tener una partición válida con uno de los límites abierto (que no tiene máximo o mínimo) se debe buscar el último valor admitido por el software.

### Tablas de decisión

La tabla de decisión es una buena manera de lidiar con combinaciones de cosas. Proveen de manera sistemática una forma de plasmar las reglas de negocio más complejas, lo que es útil para desarrolladores y testers.

A la hora de hacer una tabla de decisión se vuelve complicado a medida que el número de combinaciones aumenta. Es importante seleccionar un conjunto pequeño de combinaciones, pero la forma de decidir qué combinaciones dejar y cuales sacar no se debe tomar a la ligera. Si no se tiene un método sistemático de selección, el conjunto de combinaciones puede no ser el ideal, lo que resultaría en un esfuerzo de testing ineficiente.

Las tablas de decisión ayudan a la selección de los casos de prueba más efectivos, además de encontrar problemas y ambigüedades en la especificación. Funciona muy bien en conjunto con la técnica de partición de equivalencias, formando combinaciones de particiones de equivalencias previamente exploradas.

### Transición de estados

Es usado para sistemas caracterizados por una máquina de estados finita. Lo que significa que el sistema puede estar en un determinado número de estados, y la transición de uno a otro está determinada por reglas. Cualquier sistema donde se obtiene una salida diferente, dependiendo de lo que haya pasado antes, es un sistema de estados finito.

Un diagrama de estados puede representarse desde varios puntos de vista (como puede ser un usuario, sistema u objeto). Los mismos tienen cuatro partes básicas:

* Estados que el software puede ocupar.
* Transiciones de un estado a otro.
* Eventos que causan la transición.
* La acción que resulta de la transición.

Es importante tener en cuenta que para un determinado estado, un evento puede causar sólo una acción, pero el mismo evento, desde un estado diferente puede causar como resultado una acción diferente.

Una de las ventajas de la técnica de transición de estados es que el diagrama puede ser tan detallado o abstracto como sea necesario. Donde una parte del sistema sea más importante, se puede profundizar más en los detalles del diagrama. Por el otro lado, donde una parte del sistema no sea importante, se puede tener un diagrama con mayor abstracción.

### Test de casos de uso

El test de casos de uso es una técnica que nos ayuda a identificar casos de prueba que ejecutan el sistema completo paso por paso de principio a fin.

Un caso de uso es una descripción de un uso particular del sistema realizado por un actor, y son una secuencia de pasos que describe las interacciones entre el actor y el sistema. Cada caso de uso describe las interacciones que el actor tiene con el sistema esperando realizar una tarea. Dichos actores son generalmente personas pero pueden ser otros sistemas.

Los casos de uso son definidos en términos del actor, no del sistema, describiendo lo que el actor hace y lo que ve, en vez de qué datos espera el sistema y qué información devuelve. Sirven como base para el desarrollo de casos de prueba a un nivel de sistema y aceptación. Pueden descubrir defectos de integración entre componentes, si los actores son interfaces.

Los casos de uso suelen describir procesos que tienden a ser más utilizados, de esta manera, los casos de prueba pueden encontrar defectos que saldrían a la luz en un uso diario del sistema.