# UT3-A1. Investigación cooperativa. Diseño y Documentación de Pruebas

## Ficha de la actividad

### Grupo

> Edvin, Miguel, Mario y Aramis.

### 1. Técnicas de diseño de casos de prueba

1.1. **Casos de prueba**.

**Edvin:**

* ¿Qué son?
> Las pruebas de software son un conjunto de actividades que se realizan para identificar posibles fallos de funcionamiento, configuración o usabilidad de un programa. Es decir, un caso de prueba es un conjunto de pasos y resultados esperados que se crean a partir de los requisitos del software que se va a probar.

FUENTE: [Medium.com - ¿Qué son los casos de pruebas?](https://medium.com/grupo-carricay/qu%C3%A9-son-los-casos-de-pruebas-4893799b5b84)

* ¿Qué características tienen?
> Deben tener al menos un caso de prueba por cada requisito definido y tener en cuenta los elementos de diseño y el uso de todo tipo de datos de entrada/salida, además de cada comportamiento esperado.
Los casos de pruebas deben ser escritos de manera clara y compresibles, además de permitir que se ejecuten para revisar nuevas funcionalidades.

> Cuando un caso de prueba finaliza su estado podrá ser:
> - Pasado: si todos los pasos son correctos.
> - Fallado: si uno o varios pasos han sido erróneos.
> - Bloqueado: si un caso de prueba anterior bloquea las funciones de los posteriores casos de prueba.
> - N/A: si un caso de prueba definido ya no aplica al haber habido cambios en la funcionalidad o requisitos.

FUENTE: [Medium.com - ¿Qué son los casos de pruebas?](https://medium.com/grupo-carricay/qu%C3%A9-son-los-casos-de-pruebas-4893799b5b84)

* ¿Para qué se realizan?

> Los casos de prueba son una de las actividades más importantes y fundamentales en el desarrollo de un proyecto, ya que posibilita los procesos, métodos de trabajo y herramientas necesarias para garantizar la calidad de cualquier desarrollo.

>Sirven para detectar a tiempo cualquier error y garantizar que el producto cumple con todas las premisas establecidas.

>Un programa que ha pasado por unos buenos casos de pruebas, ofrece más seguridad y le da más valor al producto.

FUENTE: [Atsistemas.com - La importancia del testing de software y de la automatización de pruebas](https://www.atsistemas.com/es/blog/la-importancia-del-testing-de-software-y-de-la-automatizacin-de-pruebas)

**Aramis:**

* ¿Qué son?

>Es un conjunto de condiciones o variables bajo las cuales se determinará si una aplicación, un sistema de software o una característica o comportamiento de estos resulta o no aceptable.

* ¿Qué características tienen?

>**1. Solo prueba una cosa en un caso de prueba**

>**2. El caso de prueba debe tener un propósito exacto.**
El caso de prueba deber ser preciso, y debe poner a prueba algo exacto.

>**3. El caso de prueba debe estar escrito en un lenguaje claro y fácil de entender.**
Existe una lenguaje llamado Gherkin, el cual, es un lenguaje comprensible por humanos y por ordenadores, con el que vamos a describir las funcionalidades, definiendo el comportamiento del software.

>**4. El caso de prueba debe ser relativamente pequeño.**
Es indispensable que el caso de prueba sea relativamente pequeño y que sus pasos sean atomicos. Los casos de prueba largos se vuelven demasiado complicados y eso a su vez conduce a errores en la definición, implementación o ejecución.

>**5. El caso de prueba debe ser independiente.**
Cada caso debe ser autosuficiente y parametrizar todo lo que necesita para ejecutarse. El hecho de que sea independiente también le permite al desarrollador usar el caso de prueba para volver a realizar la prueba según sea necesario.

>**6. El caso de prueba no debe tener pasos o palabras innecesarias.**
Al leerse una caso de prueba no deben generarse confusiones, es por este motivo que debe tener las palabras necesarias y precisas.

>**7. El caso de prueba debe ser repetible.**
Esto permite ejecutar pruebas de regresión, repeticiones de correcciones e integración continua donde las pruebas se ejecutan cada vez que el código modificado se integra en el producto.

>**8. El caso de prueba debe usar terminología consistente e identificación de funcionalidad.**
Al nombrar o identificar una característica debe haber la misma terminología coherente dentro del caso de prueba y en todos los casos de prueba.

Fuente: [Caso de prueba- wikipedia.org](https://es.wikipedia.org/wiki/Caso_de_prueba)

**Miguel**

* ¿Qué son?
> Los casos de prueba son situaciones en las que se pone a prueba las características del producto y se observan los posibles fallos, siempre es interesante observar los casos más improbables para evitir errores.

FUENTE: [es.education-wiki.com - Técnicas de diseño de casos de prueba](https://es.education-wiki.com/9230606-test-case-design-techniques#:~:text=Los%20dise%C3%B1os%20de%20casos%20de,dise%C3%B1o%20basada%20en%20la%20experiencia.)

* ¿Qué características tienen?
Un buen caso de prueba tiene que tener las siguientes características:
> Tener una alta probabilidad de encontrar fallo, para esto el encargado de realizar la prueba debe imaginar el caso donde el producto podría tener algún fallo.

> Centrarse en fallos específicos y exactos, mientras más concreto sea el fallo más facil será de leer y corregir.

>El caso debe ser claramente legible y de facil entendimiento

> El caso debe ser relativamente pequeño, se hace redundancia en este tema debido a que lo complicado comienza durante el proceso de la prueba ya que mientras más se abarca más se extiende las pruebas y sus resultados, y se vuelve más dificil de resolver.

> Cada caso es independiente, esto quiere decir que ningún caso de prueba depende de otro para poder ejecutarse, son autosuficientes.

> Cada caso de prueba debe ser conciso y preciso para evitar la confusiones durante la lectura.

> El caso de prueba debe ser repetible, esto es debido a que cada vez que se modifica el código, las pruebas ya realizadas no deben dar error.

> El caso de prueba debe usar terminología consistente e identificación de funcionalidad, las pruebas deben usar las mismas terminologias durante las pruebas para evitar confusión.

FUENTE: [lsi.us.es - Características y Fases de la Prueba](http://www.lsi.us.es/docencia/get.php?id=361)

FUENTE: [github - Características de un buen caso de prueba](https://github.com/josemanuelep/Software-Testing-Fundamentals/blob/master/5.%20Caracter%C3%ADsticas%20de%20un%20buen%20caso%20de%20prueba.md)

* ¿Para qué se realizan?
> Como ya mencione en el primer apartado, este se usa para validar que el producto cumple con las características y requisitos deseados, obviamente cumpliendo con los casos de prueba y dando los resultados deseados.

1.2. Pruebas de **caja blanca**.

**Edvin:**

* ¿En qué consiste?

>La prueba de caja blanca es una técnica que evalúa el código y la estructura interna de un programa.

>Las pruebas de caja blanca implican observar la estructura del código.

>Cuando se conoce la estructura interna de un producto, se pueden realizar pruebas para garantizar que las operaciones internas se realizan de acuerdo con la especificación. Y todos los componentes internos se han ejecutado adecuadamente.

FUENTE: [Myservername.com - Prueba de caja blanca: una guía completa con técnicas, ejemplos y herramientas](https://es.myservername.com/white-box-testing-complete-guide-with-techniques)

* ¿Qué características tiene?

> - El evaluador debe conocer bastante bien los lenguajes de programación, ya que en las pruebas de caja blanca se analiza la estructura interna.
> - El evaluador debe detectar problemas de seguridad y prevenir ataques de piratas informáticos.
> - Analiza el funcionamiento interior de un programa o aplicación.

FUENTE: [Ebooksonline.es - ¿Qué es una prueba de caja BLANCA? Técnicas, muestras y tipos](https://ebooksonline.es/que-es-una-prueba-de-caja-blanca-tecnicas-muestras-y-tipos/)

* ¿Qué se pretende obtener con ellas?

>Asegurarse de:
> - Que se ejerciten por lo menos una vez todos los caminos independientes de cada módulo, programa o método.
> - Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.
> - Ejecuten todos los bucles en sus límites operacionales.
> - Ejerciten las estructuras internas de datos para asegurar su validez.

FUENTES: [Ecured.cu - Pruebas de caja blanca](https://www.ecured.cu/Pruebas_de_caja_blanca)

* **Nombra** técnicas que implementen este tipo de pruebas. Se pide nombrar, no detalles de dichas técnicas.

> - Cubierta de declaración: Esta técnica requiere que todas las declaraciones posibles en el código se prueben al menos una vez durante el proceso de prueba.
> - Cubierta de rama: Esta técnica comprueba todas las rutas posibles (if-else y otros bucles condicionales) para una aplicación de software.
> - Cubierta de condición
> - La cubierta de múltiples condiciones
> - La cubierta de ruta
> - La cubierta funcional

FUENTES: [Ecured.cu - Pruebas de caja blanca](https://www.ecured.cu/Pruebas_de_caja_blanca)

**Aramis:**

¿En qué consiste?
>La prueba de caja blanca consiste en probar el código del software para lo siguiente:
-Agujeros de seguridad internos
-Rutas rotas o mal estructuradas en los procesos de codificación
-Las entradas específicas fluyen a través del código
-Rendimiento esperado
-Funcionalidad de bucle condicional
-Pruebe cada enunciado, objeto y función individualmente

>La prueba se puede realizar a nivel de sistema, integración y unidad para el desarrollo de software. Verificar el flujo de trabajo de la aplicación es uno de los principales objetivos de las pruebas de caja blanca. Implica probar un conjunto de entradas predefinidas con salidas esperadas o requeridas, de modo que no tenga un error cuando resulte en una entrada en particular. Su objetivo es cerciorarse de que se devuelven los valores de salida adecuados.
>
¿Qué características tiene?
>Las pruebas de caja blanca deben cumplir con lo siguiente:

>-Garanticen que se ejerciten por lo menos una vez todos los caminos independientes de cada módulo, programa o método.
-Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.
>-Ejecuten todos los bucles en sus límites operacionales.
>-Ejerciten las estructuras internas de datos para asegurar su validez.

>Las pruebas de caja blanca son consideradas entre las más importantes que se aplican a los sistemas, con la que se obtienen como resultados la disminución en un gran porciento el número de errores existentes en el software y por ende una mayor calidad y confiabilidad en la codificación.

¿Qué se pretende obtener con ellas?
Nombra técnicas que implementen este tipo de pruebas. Se pide nombrar, no detalles de dichas técnicas.
>Las principales técnicas de diseño de pruebas de caja blanca son:
Pruebas de flujo de control
Pruebas de flujo de datos
Pruebas de bifurcación (branch testing)
Pruebas de caminos básicos

Fuentes: [Definición de una prueba de caja blanca - ebooksonline.es](https://ebooksonline.es/que-es-una-prueba-de-caja-blanca-tecnicas-muestras-y-tipos/)
[Características de una prueba de caja blanca- informatica-juridica.com](https://www.informatica-juridica.com/trabajos/procedimiento-realizar-pruebas-caja-blanca/)
[Técnicas de una prueba de caja blanca - es.wikipedia.org](https://es.wikipedia.org/wiki/Pruebas_de_caja_blanca)

**Miguel:**

* ¿En qué consiste?
> Es una técnica de prueba de software en la que se prueba la estructura interna, el diseño y la codificación del software para verificar el flujo de entrada y salida y para mejorar el diseño, la usabilidad y la seguridad.

FUENTE: [ebooksonline.es - que-es-una-prueba-de-caja-blanca-tecnicas-muestras-y-tipos](https://ebooksonline.es/que-es-una-prueba-de-caja-blanca-tecnicas-muestras-y-tipos/)

* ¿Qué características tiene?
> Garantiza que se ejecuta por lo menos una vez por todos los caminos independientes de cada módulo, programa o metodo. Como minimo la prueba debe ejecutarse una vez si no, no tendria sentido alguno la prueba.

> Se ejercitan todas las decisiones lógicas en las vertientes verdadera y falsa, por ejemplo si tuvieramos tres opciones A, B y C, donde A > B > C, si se diera la opcion de B > A sería falso y el resultado debería mostrarse.

> Se ejecutan todos los bucles en sus límites operacionales, simplemente quiere decir que se ejecutaran el número de operaciones que sean necesarias para que se obtenga el resultado de la prueba.

> Ejercitan las estructuras internas de datos para asegurar su validez.

* ¿Qué se pretende obtener con ellas?
> Se pretende indagar en la estructura interna del código, Su objetivo principal es probar la lógica del programa desde el punto de vista algorítmico.

FUENTE: [www.informatica-juridica.com - procedimiento-realizar-pruebas-caja-blanca](https://www.informatica-juridica.com/trabajos/procedimiento-realizar-pruebas-caja-blanca/#:~:text=4.2.1%20Caracter%C3%ADsticas%20de%20las%20pruebas%20de%20Caja%20Blanca.&text=Ejerciten%20todas%20las%20decisiones%20l%C3%B3gicas,datos%20para%20asegurar%20su%20validez.)

* **Nombra** técnicas que implementen este tipo de pruebas. Se pide nombrar, no detalles de dichas técnicas.

> De estructura de datos locales
> De Coberturo de Decisión
> De Cobertura de Condición
> De Cobertura de Condición/Decisión
> De Condición Múltiple
> De Cobertura de Caminos

FUENTE: [www.informatica-juridica.com - procedimiento-realizar-pruebas-caja-blanca](https://www.informatica-juridica.com/trabajos/procedimiento-realizar-pruebas-caja-blanca/#:~:text=4.2.1%20Caracter%C3%ADsticas%20de%20las%20pruebas%20de%20Caja%20Blanca.&text=Ejerciten%20todas%20las%20decisiones%20l%C3%B3gicas,datos%20para%20asegurar%20su%20validez.)

1.3. Pruebas de **caja negra**.

**Edvin:**

* ¿En qué consiste?

> Las Pruebas de Caja Negra, es una técnica de pruebas de software en la cual la funcionalidad se verifica sin tomar en cuenta la estructura interna de código, detalles de implementación o escenarios de ejecución internos en el software.

> En las pruebas de caja negra, nos enfocamos solamente en las entradas y salidas del sistema, sin preocuparnos en tener conocimiento de la estructura interna del programa de software. Para obtener el detalle de cuáles deben ser esas entradas y salidas, nos basamos en los requerimientos de software y especificaciones funcionales.

FUENTES: [Testingbaires.com - Pruebas de Caja Negra y un enfoque práctico](https://testingbaires.com/pruebas-caja-negra-enfoque-practico/)

* ¿Qué características tiene?

> - Solo se analiza la entrada y salida de un programa, por lo que es menos complejo que la prueba de caja blanca.
> - Lo suele hacer el mismo desarrollador, al mismo tiempo que va avanzando de etapa en el desarrollo del software, en cada etapa se realizan estas pruebas para garantizar la funcionalidad del mismo.
> - No hace falta conocer a fondo el lenguaje de programación usado en el programa, solo con saber los requerimientos de software y especificaciones funcionales se puede realizar.

FUENTE: [Howtotesting.com - Pruebas de Caja Negra](https://howtotesting.com/testing-funcional/pruebas-de-caja-negra/)

* ¿Qué se pretende obtener con ellas?

> Se obtiene una verificación de la funcionalidad del programa sin tener en cuenta la estructura interna de código, detalles de implementación o escenarios de ejecución internos en el software.

FUENTES: [Testingbaires.com - Pruebas de Caja Negra y un enfoque práctico](https://testingbaires.com/pruebas-caja-negra-enfoque-practico/)

* **Nombra** técnicas que implementen este tipo de pruebas. Se pide nombrar, no detalles de dichas técnicas.

> - Partición de equivalencias
> - Análisis de valores borde
> - Tablas de decisión
> - Transición entre estados
> - Pruebas de casos de uso

FUENTES: [Testingbaires.com - Pruebas de Caja Negra y un enfoque práctico](https://testingbaires.com/pruebas-caja-negra-enfoque-practico/)

**Aramis**:

¿En qué consiste?
>Esta prueba consiste en una técnica de pruebas de software en la cual la funcionalidad se verifica sin tomar en cuenta la estructura interna de código, detalles de implementación o escenarios de ejecución internos en el software.
>
>Fuente: [Definición de pruebas de caja negra- pmoinformatica.com](http://www.pmoinformatica.com/2017/02/pruebas-de-caja-negra-ejemplos.html)

¿Qué se pretende obtener con ellas?
>El objetivo final es pues, encontrar una serie de datos de
entrada cuya probabilidad de pertenecer al conjunto de entradas que causan dicho comportamiento erróneo sea lo más alto posible.

Fuente: [Objetivo de pruebas de caja negra](http://www.lsi.us.es/docencia/get.php?id=361)

Nombra técnicas que implementen este tipo de pruebas. Se pide nombrar, no detalles de dichas técnicas.
>Para desarrollar la prueba de caja negra existen varias técnicas, entre ellas están:
-Técnica de la Partición de Equivalencia
-Técnica del Análisis de Valores Límites
-Técnica de Grafos de Causa-Efecto

Fuente: [Técnicas de pruebas de caja negra](https://www.ecured.cu/Pruebas_de_caja_negra)

**Miguel:**

* ¿En qué consiste?
> Estas pruebas se basan en la especificación del programa a de ser probado para elaborar los casos de prueba, es decir el programa es elavorado primeramente y luego se realizan las pruebas.

* ¿Qué características tiene?

> Las características a nombrar deriban de las tecnicas a implmentar y a destacar las más importantes son:
> **Particiones de Equivalencia.**
> **1.-** Identificar las clases de equivalencia.
> * Las clases de equivalencia, representan estados validos y no validos para las condiciones de entrada de un programa, a parte de estos ultimos tambien se suelen representar los casos más extremos.
>
> **2.-** Identificar los casos de prueba.
> * El objeivo es minimizar el número de casos de prueba, y que a su vez cada caso contemple tantas condiciones como sean posibles.
>
> * **2.1** Asignar a cada clase de equivalencia un número único.
> * **2.2** Hasta que todas las clases de equivalencia hayan sido cubiertas por los casos de prueba,
se tratará de escribir un caso que cubra tantas clases válidas no incorporadas como sea
posible.
> * **2.3** Hasta que todas las clases de equivalencia no válidas hayan sido cubiertas por casos de
prueba, escribir un caso para cubrir una única clase no válida no cubierta.
>
>**Análisis de Valores Límite**
> 3.- En lugar de seleccionar cualquier caso de prueba de las clases válidas e inválidas, se
eligen los casos de prueba en los extremos.
> 4.- - En lugar de centrase sólo en el dominio de entrada, los casos de prueba se diseñan
también considerando el dominio de salida.
>
> **Pautas de desarrollo**
> * Si una condición de entrada especifica un rango de valores, se diseñarán casos de
prueba para los dos límites del rango, y otros dos casos para situaciones justo por debajo
y por encima de los extremos.
> * Si una condición de entrada especifica un número de valores, se diseñan dos casos de
prueba para los valores mínimo y máximo, además de otros dos casos de prueba para
valores justo por encima del máximo y justo por debajo del mínimo.
> * Aplicar las reglas anteriores a los datos de salida.
> * Si la entrada o salida de un programa es un conjunto ordenado, habrá que prestar
atención a los elementos primero y último del conjunto.

* ¿Qué se pretende obtener con ellas?
> Se pretende obtener verificaciones del software, sin tomar en cuenta la estructura del código.

FUENTE: [testingbaires.com - pruebas-caja-negra-enfoque-practico](https://testingbaires.com/pruebas-caja-negra-enfoque-practico/#:~:text=Las%20Pruebas%20de%20Caja%20Negra,ejecuci%C3%B3n%20internos%20en%20el%20software.)

* **Nombra** técnicas que implementen este tipo de pruebas. Se pide nombrar, no detalles de dichas técnicas.

> Particiones de Equivalencia.
> Análisis de Valores Límite.
> Métodos Basados en Grafos
> Pruebas de Comparación.
> Análisis Causa-Efecto.

FUENTE: [lsi.us.es - Pruebas de Caja Negra](http://www.lsi.us.es/docencia/get.php?id=361)
1.4. Cubrimiento o cobertura de las pruebas

**Edvin:**

* ¿En qué consiste?

> La cobertura es la cantidad de código (medida porcentualmente) que está siendo cubierto por las pruebas. Un ejemplo sería, si yo ejecuto las pruebas de una aplicación y hay alguna línea del código que nunca fue ejecutada en el contexto de las pruebas, eso significaría que dicha línea no está cubierta.

> Si un código consta de 100 líneas y solo 50 líneas están siendo ejecutadas al correr las pruebas, entonces la cobertura es del 50%.

FUENTES: [Nicopaez.gitbook.io - Cobertura de la prueba](https://nicopaez.gitbook.io/test-automation/cobertura)

* ¿Es siempre posible tener un cubrimiento del 100%?¿Por qué?

> No siempre es posible, depende de la aplicación, pero si es posible llegar al 100% en determinados proyectos, una cobertura del 100% significa que todo nuestro código está siendo cubierto por pruebas.

> Hay que tener en cuenta que las pruebas no esten contemplando algunas situaciones, o sea, que faltan pruebas o incluso podría ocurrir que las pruebas fueran deficientes.

> Hay veces que es mejor tener un cobertura del 60% de los métodos importantes y sus escenarios, en lugar de una cobertura del 100% de los escenarios no relevantes.

FUENTES: [Nicopaez.gitbook.io - Cobertura de la prueba](https://nicopaez.gitbook.io/test-automation/cobertura)

**Aramis**:

¿En qué consiste?
>Consiste en medir el grado en que el código fuente de un programa ha sido comprobado con pruebas de software. Sirve para determinar la calidad del test que se lleve a cabo y para determinar las partes críticas del código que no han sido comprobadas y las partes que ya lo fueron, además se puede utilizar como técnica de optimización dentro de un compilador optimizador para llevar a cabo una eliminación de código muerto, más específicamente sirve para detectar código inalcanzable
>
[Definición de cobertura de las pruebas - es.wikipedia.org](https://es.wikipedia.org/wiki/Cobertura_de_c%C3%B3digo)
>
¿Es siempre posible tener un cubrimiento del 100%?¿Por qué?
> No siempre es posible tener un cubrimiento del 100 %. Porque es muy caro lograrlo y los esfuerzos se centran en cubrir las líneas de código donde suele haber bugs.
>
Fuente: [Porcentaje del cubrimiento](https://nicopaez.gitbook.io/test-automation/cobertura)

**Miguel:**

* ¿En qué consiste?
> Es la cantidad de código (medida en porcentaje), que esta siendo cubierta por las pruebas. Por poner un ejemplo:
> Si mi código consta de 100 lineas y las pruebas solo abarcan hasta la linea 50, mi cobertura sería del 50%.
>
* ¿Es siempre posible tener un cubrimiento del 100%?¿Por qué?
Aunque tuvieramos un cubrimiento del 100% no significa que nuestro código este perfecto, solo quiere decir que esta cumpliendo las pruebas que le hemos implementado. Esto quiere decir que puede haber más pruebas y casos que no hayamos contemplado.

FUENTE: [nicopaez.gitbook - cobertura](https://nicopaez.gitbook.io/test-automation/cobertura#:~:text=%C2%BFQu%C3%A9%20es%20la%20cobertura%3F,dicha%20l%C3%ADnea%20no%20est%C3%A1%20cubierta.)

### 2. Etapas de pruebas

Las pruebas a realizar son diferentes en función de la etapa de desarrollo del software en la que nos encontremos y de la metodología utilizada. De forma general son las siguientes.

2.1. Pruebas de componentes o unitarias

**Edvin:**

* ¿En qué consisten?

> Las pruebas unitarias o unit testing son una forma de comprobar que un fragmento de código funciona correctamente. Es un procedimiento más de los que se llevan a cabo dentro de una metodología ágil de trabajo.

>Las pruebas unitarias consisten en aislar una parte del código y comprobar que funciona a la perfección. Son pequeños tests que validan el comportamiento de un objeto y la lógica.

FUENTES: [Yeeply.com - ¿Qué son las pruebas unitarias y cómo llevar una a cabo?](https://www.yeeply.com/blog/que-son-pruebas-unitarias/)

* ¿Cuándo se suelen ejecutar?

> El unit testing suele realizarse durante la fase de desarrollo de aplicaciones de software o móviles. Normalmente las llevan a cabo los desarrolladores, aunque en la práctica, también pueden realizarlas los responsables de QA.

FUENTES: [Yeeply.com - ¿Qué son las pruebas unitarias y cómo llevar una a cabo?](https://www.yeeply.com/blog/que-son-pruebas-unitarias/)

* ¿A qué componentes se les aplica?

> Se le aplica a un módulo de software que pruebe probarse aisladamente.

FUENTES: [Spain.girlsintech.org - ¿Qué técnicas de Testing software debemos usar?](https://spain.girlsintech.org/que-tecnicas-de-testing-software-debemos-usar/)

* ¿Qué técnicas se suelen utilizar?

> Desarrollo guiado por pruebas

> Se utilizan unas herramientas dedicadas a la realización de pruebas unitarias, usaras determinada herramienta depende del lenguaje de programación usado:
> - xUnit: se trata de una herramienta de pruebas unitarias para el framework .NET.
> - Junit: es un conjunto de bibliotecas para realizar pruebas unitarias de aplicaciones Java.
> - NUnit: inicialmente portado desde JUnit, NUnit 3 se ha reescrito por completo para dotarlo de nuevas características y soporte para una amplia gama de plataformas .NET.
> - PHPUnit: entorno de pruebas unitarias en el lenguaje de programación PHP.

FUENTES: [Yeeply.com - ¿Qué son las pruebas unitarias y cómo llevar una a cabo?](https://www.yeeply.com/blog/que-son-pruebas-unitarias/)

**Aramis**:

¿En qué consisten?
>Las pruebas unitarias consisten en aislar una parte del código y comprobar que funciona a la perfección. Son pequeños tests que validan el comportamiento de un objeto y la lógica.
>
¿Cuándo se suelen ejecutar?
>Se suelen ejecutar durante la fase de desarrollo de aplicaciones de software o móviles. Normalmente las llevan a cabo los desarrolladores, aunque en la práctica, también pueden realizarlas los responsables de QA.
Hay una especie de mito respecto a las pruebas unitarias. Algunos desarrolladores están convencidos de que son una pérdida de tiempo y las evitan buscando ahorrar tiempo.
Nada más alejado de la realidad.
Con ellas se detectan antes errores que, sin las pruebas unitarias, no se podrían detectar hasta fases más avanzadas como las pruebas de sistema, de integración e incluso en la beta.
Realizar pruebas unitarias con regularidad supone, al final, un ahorro de tiempo y dinero.

¿A qué componentes se les aplica?
> A los componentes más pequeños de cualquier aplicación
>
¿Qué técnicas se suelen utilizar?
>Según la profundidad de los niveles de prueba, las pruebas de componentes se pueden clasificar como
CTIS – Prueba de componentes en pequeño
CTIL – Prueba de componentes en grande

Fuentes: [Definición de pruebas de componentes](https://www.yeeply.com/blog/que-son-pruebas-unitarias/)
[Técnicas de pruebas de componentes](https://ebooksonline.es/que-es-una-prueba-de-componentes-tecnicas-casos-de-prueba-de-muestra/)

**Miguel:**
* ¿En qué consisten?
> El objetivo es comprobar que el módulo,entendido como una unidad funcional de un programa independiente, está correctamente codificado.

* ¿Cuándo se suelen ejecutar?
> La prueba de unidad es la primera fase de las pruebas dinámicas y se realizan sobre cada módulo del software de manera independiente.
>
* ¿A qué componentes se les aplica?
> Se les aplica a los modulos, se entiende como modulo a un componente del software que cumplen con una serie de características (Mencionadas en el siguiente apartado).

* ¿Qué técnicas se suelen utilizar?
> Debe ser un bloque básico de construcción de programas.
> Debe implementar una función independiente simple.
> Podrá ser probado al cien por cien por separado.
> No deberá tener más de 500 líneas de código.

FUENTE: [lsi.us.es - Pruebas Unitarias](http://www.lsi.us.es/docencia/get.php?id=361)

2.2. Pruebas de integración

**Edvin:**

* ¿En qué consisten?

> Pruebas integrales o pruebas de integración son aquellas que se realizan en el ámbito del desarrollo de software una vez que se han aprobado las pruebas unitarias y lo que prueban es que todos los elementos unitarios que componen el software, funcionan juntos correctamente probándolos en grupo. Se centra principalmente en probar la comunicación entre los componentes y sus comunicaciones ya sea hardware o software.

FUENTES: [Wikipedia.org - Prueba de integración](https://es.wikipedia.org/wiki/Prueba_de_integraci%C3%B3n)

* ¿Cuándo se suelen ejecutar?

> Despues de haber pasado las pruebas unitarias todos los modulos, para ver si conectando todos los módulos hay algún tipo de error.

* ¿A qué componentes se les aplica?

> A las interfaces entre grupos de componentes o subsistemas para asegurar que son llamados cuando es necesario y que los datos o mensajes que se transmiten son los requeridos.

> Se centra principalmente en probar la comunicación entre los componentes y sus comunicaciones ya sea hardware o software.

FUENTES: [Alarcos.esi.uclm.es - Pruebas de Integracion](https://alarcos.esi.uclm.es/ipsw/metrica3/metrica_3/guidances/guidelines/pruebas_integracion_31F5282A.html)

FUENTES: [Wikipedia.org - Prueba de integración](https://es.wikipedia.org/wiki/Prueba_de_integraci%C3%B3n)

* Pruebas de integración incrementales y no incrementales

> **Integración incremental**
> Se combina el siguiente componente que se debe probar con el conjunto de componentes que ya están probados y se va incrementando progresivamente el número de componentes a probar.
> Con el tipo de prueba incremental lo más probable es que los problemas que surjan al incorporar un nuevo componente o un grupo de componentes previamente probado, sean debidos a este último o a las interfaces entre éste y los otros componentes.

> **Integración no incremental**
> Se prueba cada componente por separado y posteriormente se integran todos de una vez realizando las pruebas pertinentes. Este tipo de integración se denomina también Big-Bang (gran explosión).

FUENTES: [Alarcos.esi.uclm.es - Pruebas de Integracion](https://alarcos.esi.uclm.es/ipsw/metrica3/metrica_3/guidances/guidelines/pruebas_integracion_31F5282A.html)

**Aramis**:

¿En qué consisten?
>Consisten en probar que todos los elementos unitarios que componen el software, funcionan juntos correctamente probándolos en grupo. Se centra principalmente en probar la comunicación entre los componentes y sus comunicaciones ya sea hardware o software.

¿Cuándo se suelen ejecutar?
>Se suelen ejecutar una vez que se han aprobado las pruebas unitarias.
>
¿A qué componentes se les aplica?
>Se les aplica a los siguientes componentes: Stubs, drivers, subsistemas, bases de datos, API’s, microservicios…
>
Pruebas de integración incrementales y no incrementales

>La prueba incremental es uno de los enfoques de la prueba de integración e incorpora sus conceptos fundamentales.En esta prueba, probamos cada módulo individualmente en la fase de prueba unitaria, y luego los módulos se integran de forma incremental y se prueban para garantizar una interfaz e interacción fluidas entre los módulos.
>En este enfoque, cada módulo se combina de forma incremental, es decir, uno por uno hasta que todos los módulos o componentes se agregan de manera lógica para realizar la aplicación requerida, en lugar de integrar todo el sistema a la vez y luego realizar pruebas en el producto final. Los módulos integrados se prueban como un grupo para garantizar una integración y un flujo de datos exitosos entre los módulos.

>Integración no incremental: Se prueba cada componente por separado y posteriormente se integran todos de una vez realizando las pruebas pertinentes. Este tipo de integración se denomina también Big-Bang (gran explosión).

Fuentes: [Definición de pruebas de integración incrementales - es.myservername.com](https://es.myservername.com/what-is-incremental-testing)
[Pruebas de integración - es.wikipedia.org](https://es.wikipedia.org/wiki/Prueba_de_integraci%C3%B3n)
[Objetivos de las pruebas de integración - oscarmoreno.com](https://oscarmoreno.com/pruebas-de-integracion/)
[Tipos de prueba de integración - alarcos.esi.uclm.es](https://alarcos.esi.uclm.es/ipsw/metrica3/metrica_3/guidances/guidelines/pruebas_integracion_31F5282A.html)

**Miguel:**
* ¿En qué consisten?
> El objetivo principal es ensamblar todos los módulos probados previamente.
> A pesar de que los modulos puedan funcionar bien por separado, es necesario probarlos conjuntamente, ya que un modulo puede tener un efecto inverso o inadvertido sobre otro.
* ¿Cuándo se suelen ejecutar?
> Por logica, las pruebas de integracion se realizan una ves las pruebas unitarias son aprobadas.

* ¿A qué componentes se les aplica?
> Se aplica a los modulos, hay dos formas de realizar estas pruebas, de forma no incremental (Conjunta) o incremental (Poco a poco).

* Pruebas de integración incrementales y no incrementales
>**No incremental:**
> * Las pruebas abarcan todo el programa, se ensemblan todos los modulos y se comprueban que funcionen de una vez. Este forma de comprobarlos es la más rápida, pero no por ella la más efectiva, ya que si algun modulo o varios dieran algun error, sería más dificial encontrarlo.
>
>**Incremental:**
> * Las pruebas se realizan de poco a poco, juntando lentamente los modulos, esta es la forma más lenta de realizar las pruebas pero tambien la más efectiva, que si hubiera algún tipo de error sería más fácil localizarlo. Dentro de esta rama para realizar las pruebas, se encuentran dos derivaciones: Integracion Incremental Ascendente y Integracion Incremental Descendente. (Para abreviar voy a utilizar IIA y IID).

>**Como funciona la IIA**
>1. Se combinan modulos de bajo nivel en grupos que realicen una subfuncion especifica.
>2. Se escribe un controlador (un programa de control de la prueba) para coordinar laentrada y salida de los casos de prueba.
>3. Se prueba el grupo
>4. Se eliminan los controladores y se combinan los grupos moviéndose hacia arriba por la estructura del programa.

>**Como funciona la IID**
>1. Se usa el módulo de control principal como controlador de la >prueba, creando resguardos (módulos que simulan el funcionamiento de los módulos que utiliza el que está probando) para todos los módulos directamente subordinados al módulo de control principal.
>2. Dependiendo del enfoque e integración elegido (es decir, primero-en-profundidad, o primero-en-anchura) se van sustituyendo uno a uno los resguardos subordinados por los módulos reales.
>3. Se llevan a cabo pruebas cada vez que se integra un nuevo módulo.
>4. Tras terminar cada conjunto de pruebas, se reemplaza otro resguardo con el módulo real.

FUENTE: [lsi.us.es - Pruebas de Integración](http://www.lsi.us.es/docencia/get.php?id=361)

2.3. Pruebas de validación o aceptación

**Edvin:**

* ¿En qué consisten?

> Las pruebas de validación son el proceso de revisión que verifica que el sistema de software producido cumple con las especificaciones y logra su cometido. Es normalmente una parte del proceso de pruebas de software de un proyecto, que también utiliza técnicas tales como evaluaciones, inspecciones y tutoriales. La validación es el proceso de comprobar que lo que se ha especificado es lo que el usuario realmente quería.

FUENTES: [Wikipedia.org - Pruebas de validación](https://es.wikipedia.org/wiki/Pruebas_de_validaci%C3%B3n)

* ¿Dónde y quién las realiza?

> Son definidas por el usuario del sistema y preparadas por el equipo de desarrollo, aunque la ejecución y aprobación final corresponden al usuario.

* ¿Qué se quiere conseguir con las mismas?

> Estas pruebas van dirigidas a comprobar que el sistema cumple los requisitos de funcionamiento esperado, recogidos en el catálogo de requisitos y en los criterios de aceptación del sistema de información, y conseguir así la aceptación final del sistema por parte del usuario.

FUENTES: [Manuel.cillero.es - Pruebas de Aceptación](https://manuel.cillero.es/doc/metodologia/metrica-3/tecnicas/pruebas/aceptacion/)

* Tipos:
* Prueba aceptación de contrato
* Prueba aceptación usuario
* Prueba de aceptación operativa
* Pruebas de campo (prueba alfa y prueba beta)

**Aramis**:

¿En qué consisten?
>Consisten en revisar que el sistema de software producido cumple con las especificaciones y logra su cometido. Es normalmente una parte del proceso de pruebas de software de un proyecto, que también utiliza técnicas tales como evaluaciones, inspecciones y tutoriales. La validación es el proceso de comprobar que lo que se ha especificado es lo que el usuario realmente quería.

¿Dónde y quién las realiza?
>Las realiza el usuario.
>
¿Qué se quiere conseguir con las mismas?
>Lo que se quiere conseguir es que el software cumpla con los requerimientos del usuario y funcione correctamente.
>
Tipos:
Prueba aceptación de contrato
Prueba aceptación usuario
Prueba de aceptación operativa
Pruebas de campo (prueba alfa y prueba beta)

>**Las pruebas alfa** son realizadas por el usuario con el desarrollador como observador en un entorno controlado (simulación de un entorno de producción).
>**Las pruebas beta** realizadas por el usuario en su entorno de trabajo y sin observadores.
>**Las pruebas de aceptación** de contrato se realizan verificando que la funcionalidad del sistema cumple con dichas regulaciones, tales como las definidas por el gobierno, las leyes o estándares de seguridad.
>
>**Pruebas de aceptación operacional**
Comprende la aceptación del nuevo sistema o funcionalidad por parte de los administradores, es decir el área de operaciones de organización de la informática
>
>Entre los aspectos a validar pueden incluirse:
-Pruebas de respaldo y recuperación.
-Recuperación ante desastres.
-Gestión de cuentas de usuario y control de acceso al sistema.
-Tareas de mantenimiento.
-Tareas de carga y migración de datos.
-Revisiones periódicas de vulnerabilidades de seguridad.

Fuentes:

[Tipos de pruebas de aceptación - pmoinformatica.com](http://www.pmoinformatica.com/2016/08/pruebas-aceptacion-software-istqb.html)

[Definición de pruebas de aceptación - es.wikipedia.org](https://es.wikipedia.org/wiki/Pruebas_de_validaci%C3%B3n)

**Miguel:**
* ¿En qué consisten?
> Consisten en la comprobacion final del producto, en el entorno en el que se va a explotar.
* ¿Dónde y quién las realiza?
>El mismo cliente (ayudado por personas del equipo) es el que realiza las pruebas, aportando casos para la comprobación del producto
* ¿Qué se quiere conseguir con las mismas?
> Que sea el mismo cliente el que decida si el producto final esta listo para su implementación.

* Tipos:
* Prueba aceptación de contrato
- Un contrato de software suele incluir cláusulas sobre el tiempo que tiene el cliente después de la entrega para notificar a la empresa de software los problemas que debe resolver como parte del acuerdo.
* Prueba aceptación usuario
- Participación activa del usuario, que debe ejecutar los casos de prueba ayudado por
miembros del equipo de pruebas.

* Prueba de aceptación operativa

- Están enfocadas a probar los requisitos de usuario, o mejor dicho a demostrar que no se
cumplen los requisitos, los criterios de aceptación o el contrato. Si no se consigue
demostrar esto el cliente deberá aceptar el producto
* Pruebas de campo (prueba alfa y prueba beta)

- Corresponden a la fase final del proceso de desarrollo de software, en el q se abre al público para recibir los primeros comentarios y críticas.

FUENTE: [lsi.us.es - Pruebas de Validación](http://www.lsi.us.es/docencia/get.php?id=361)
FUENTE: [digite.com - pruebas-de-aceptacion](https://www.digite.com/es/agile/pruebas-de-aceptacion/)

2.4. Pruebas del sistema

2.4. Pruebas del sistema

**Edvin:**

* ¿En qué consisten?
>Las pruebas del sistema consisten en ejercitar profundamente el sistema comprobando la integración del sistema de información globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica.
* ¿Cuándo se suelen ejecutar?
>Una vez que se han probado los componentes individuales y se han integrado, se prueba el sistema de forma global.

* ¿Qué se quiere obtener/validar?
>Se quiere comprobar el fuen funcionamiento de las interfaces entre subsistemas y de las comunicaciones
* Tipos:
* Prueba de recuperación
* Prueba de seguridad
* Prueba de resistencia

>>**Prueba de recuperación**
>Determina si un sistema puede recuperarse de fallas o no.
>Por ejemplo, un corte de electricidad, un fallo con la conexión con el servidor etc...

>**Prueba de seguridad**
>Verifican si el sistema está protegido contra ataques repentinos o deliberados de fuentes internas y externas.

>**Prueba de resistencia**
>La prueba de resistencia es un tipo de prueba no funcional que se realiza para verificar si el sistema de software puede soportar una gran carga esperada continuada durante un largo período de tiempo.

Fuentes:

[Manuelcillero.es - Tipos de prueba del sistema](https://manuel.cillero.es/doc/metodologia/metrica-3/tecnicas/pruebas/sistema/)

[Profile.es - Qué es el testing de software](https://profile.es/blog/que-es-el-testing-de-software/)

[Myservername.com - ¿Qué son las pruebas de resistencia en las pruebas de software?](https://es.myservername.com/what-is-endurance-testing-software-testing)

**Aramis**:

* ¿En qué consisten?
>Las pruebas del sistema consisten en ejercitar profundamente el sistema comprobando la integración del sistema de información globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica.
* ¿Cuándo se suelen ejecutar?
>Se ejecutan una vez que se han probado los componentes individuales y se han integrado.

* ¿Qué se quiere obtener/validar?
>Se quiere validar el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica.
* Tipos:
* Prueba de recuperación
* Prueba de seguridad
* Prueba de resistencia

>>**Prueba de recuperación**
>Consiste en verificar que los procesos de recuperación (manual o automática) restauran apropiadamente la Base de datos, aplicaciones y sistemas, y los llevan a un estado conocido o deseado. Los siguientes tipos de condiciones deben incluirse en la prueba:
· Interrupción de electricidad en el cliente.
· Interrupción de electricidad en el servidor
· Interrupción en la comunicación hacia el servidor (caídas de red)
· Interrupción en la comunicación con los controladores de disco.
· Ciclos incompletos (procesos de consultas interrumpidos, procesos de sincronización de datos interrumpidos)
· Llaves o apuntadores de base de datos inválidos
· Elementos corruptos o inválidos en la base de datos.

>**Prueba de seguridad**
>Es un tipo de prueba de software que revela vulnerabilidades, amenazas, riesgos en una aplicación de software y previene ataques maliciosos de intrusos. El propósito de las pruebas de seguridad es identificar todas las lagunas y debilidades potenciales en el sistema de software que podrían resultar en la pérdida de información, ingresos, reputación de los empleados o personas ajenas a la organización.
>
>**Prueba de resistencia**
>Las pruebas de resistencia evalúan el comportamiento del sistema cuando es sometido asituaciones anormales en demanda de recursos, frecuencia o volumen.
>Algunos ejemplos de las pruebas de resistencia que pueden
aplicarse a un sistema son : (1) evaluar el desempeño del sistema al someterlo a cantidades superiores a las normales de interrupciones por segundo; (2) elevar el volumen de datos
de entrada buscando evaluar el comportamiento de las funciones de entrada; (3) diseñar escenarios que necesiten niveles máximos de memoria.

Fuentes:

[Tipos de prueba del sistema - manuelcillero.es](https://manuel.cillero.es/doc/metodologia/metrica-3/tecnicas/pruebas/sistema/)

[Tipos de prueba del sistema - bloginegenieriaweb.blogspot.es](https://blogingenieriaweb.blogspot.com/2016/06/pruebas-de-recuperacion-y-tolerancia.html)

[Definición de pruebas del sistema - catarina.udlap.mx](http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/rueda_p_jo/capitulo4.pdf)

**Miguel:**
* ¿En qué consisten?
> El objetivo es ejercitar profundamente el sistema para verificar que se han integrado adecuadamente todos los elementos del sistema (hardware, otro software, etc.) y que realizan las funciones adecuadas.

* ¿Cuándo se suelen ejecutar?
> Se suelen ejecutar tras las pruebas alfa y beta.

* ¿Qué se quiere obtener/validar?
> 1. Se cumplen los requisitos funcionales establecidos.
> 2. El funcionamiento y rendimiento de las interfaces hardware, software y de usuario.
> 3. La adecuación de la documentación de usuario.
> 4. Rendimiento y respuesta en condiciones límite y de sobrecarga.
* Tipos:
* Prueba de recuperación
- Las pruebas de recuperación de desastres ayudan a garantizar que una organización podrá recuperar datos, aplicaciones críticas de negocio y continuar con su funcionamiento después de una interrupción de los servicios.
FUENTE: [searchdatacenter.techtarget.com - Prueba-de-recuperacion-de-desastres-DR](https://searchdatacenter.techtarget.com/es/definicion/Prueba-de-recuperacion-de-desastres-DR)

* Prueba de seguridad
- Es un tipo de prueba de software que revela vulnerabilidades, amenazas, riesgos en una aplicación de software y previene ataques maliciosos de intrusos.
FUENTE: [ebooksonline.es - que-es-una-prueba-de-seguridad](https://ebooksonline.es/que-es-una-prueba-de-seguridad-tipos-con-ejemplo/#:~:text=PRUEBA%20DE%20SEGURIDAD%20es%20un,previene%20ataques%20maliciosos%20de%20intrusos.)
* Prueba de resistencia
- Las pruebas de resistencia realizadas, evalúan el desempeño del sistema en casos anormales de uso, pero considerando al sistema como una aplicación local en la máquina del usuario. Lo anterior está basado en el hecho que el sistema se comporta como una aplicación local después de cargarse en el navegador del usuario.
FUENTE: [catarina.udlap.mx - Prueba de resistencia](http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/rueda_p_jo/capitulo4.pdf)

2.5. Pruebas de regresión

2.5. Pruebas de regresión

**Edvin**:

* ¿En qué consisten?

>Las pruebas de regresión se deben llevar a cabo cada vez que se hace un cambio en el sistema, tanto para corregir un error como para realizar una mejora. No es suficiente probar sólo los componentes modificados o añadidos, o las funciones que en ellos se realizan, sino que también es necesario controlar que las modificaciones no produzcan efectos negativos sobre el mismo u otros componentes.

>Normalmente, este tipo de pruebas implica la repetición de las pruebas que ya se han realizado previamente, con el fin de asegurar que no se introducen errores que puedan comprometer el funcionamiento de otros componentes que no han sido modificados y confirmar que el sistema funciona correctamente una vez realizados los cambios.

Fuentes:

[Manuelcillero.es - Pruebas de regresión](https://manuel.cillero.es/doc/metodologia/metrica-3/tecnicas/pruebas/regresion/)

**Aramis**:

* ¿En qué consisten?

>Las pruebas de regresión verifican que un conjunto de escenarios que funcionaron correctamente en el pasado, funcionen en el presente.

Fuente:

[Pruebas de regresión - programacionymas.com](https://programacionymas.com/blog/tipos-de-testing-en-desarrollo-de-software)

**Miguel:**
* ¿En qué consisten?

>La regresión consiste en la repetición selectiva de pruebas para detectar fallos introducidos
durante la modificación de un sistema o componente de un sistema. Se efectuarán para
comprobar que los cambios no han originado efectos adversos no intencionados o que se siguen
cumpliendo los requisitos especificados.

FUENTE: [lsi.us.es - Pruebas de Regresión](http://www.lsi.us.es/docencia/get.php?id=361)
### 3. Documentación para las pruebas

Durante las pruebas se generan un conjunto de documentos que son los siguientes:

3.1. Plan de pruebas

**Edvin**:

* ¿Qué describe e incluye?

>El plan de pruebas es un conjunto de casos de pruebas que se encarga de probar una funcionalidad completa de un producto o software en concreto.

>Debe de realizarse a partir de los requisitos aportados en el proyecto o en las historias de usuario, depende de la metodología que se utilice. Además, se deben de realizar a partir de las especificaciones, del diseño funcional, del prototipado y de los casos de uso, entre otra documentación que se pueda obtener dentro del proyecto.

>Un plan de pruebas es un elemento que debe de estar vivo a lo largo del proyecto, ya que se suelen añadir nuevas funcionalidades o requisitos y estos deben de ser cubiertos a lo largo de la vida del desarrollo del mismo.

>Funcionalidades de usuario final: cuando se agregan nuevos módulos, pantallas o flujos en las funcionalidades que son utilizadas por el cliente o se ven visualmente.

>Funcionalidades internas: son cambios internos que mantienen todos los elementos visuales de la misma manera, por lo tanto, el cliente final no observa ninguna modificación, pero al modificar componentes o flujos internos, como accesos a base de datos o a capas de lógica de negocio, deben de cubrirse con casos de pruebas dentro del plan de pruebas y cubrir toda la funcionalidad de este tipo.

>Cuando se ejecuta un plan de pruebas al completo, quiere decir que se han ejecutado todos los casos de prueba que estaba adjuntos al mismo y en base al resultado de ellos, nos da el resultado final de plan de pruebas, pudiendo dar el OK final a la funcionalidad, módulo o software que se ha probado o el KO, abriendo los defectos oportunos y esperando a que sean solucionados para volver a ejecutar los casos erróneos y dar el OK definitivo si todo funciona como debe de funcionar.

Fuentes:

[Qalover.com - Plan de pruebas](https://www.qalovers.com/2019/01/detallando-un-plan-de-pruebas.html)

**Aramis**:

* ¿Qué describe e incluye?

>Describe un conjunto de casos de pruebas que se encarga de probar una funcionalidad completa de un producto o software en concreto. Es una guía para la realización de las pruebas, con la ejecución de los casos de prueba y en base al resultado de los mismos, sabremos si el software cumple con las necesidades establecidas en el proyecto y cubre los estándares de calidad definidos.

>Hay dos tipos de modificaciones o ampliaciones dentro de un plan de pruebas, que han de incluirse para que se pueda cubrir toda la funcionalidad existente:
>
>Funcionalidades de usuario final: cuando se agregan nuevos módulos, pantallas o flujos en las funcionalidades que son utilizadas por el cliente o se ven visualmente.
>
>Funcionalidades internas: son cambios internos que mantienen todos los elementos visuales de la misma manera, por lo tanto, el cliente final no observa ninguna modificación, pero al modificar componentes o flujos internos, como accesos a base de datos o a capas de lógica de negocio, deben de cubrirse con casos de pruebas dentro del plan de pruebas y cubrir toda la funcionalidad de este tipo

Fuente: [Plan de pruebas - qalover.com](https://www.qalovers.com/2019/01/detallando-un-plan-de-pruebas.html)

**Miguel:**
* ¿Qué describe e incluye?

>El plan de pruebas es un producto formal que define los objetivos de la prueba de un sistema, establece y coordina una estrategia de trabajo, y provee del marco adecuado para elaborar una planificación paso a paso de las actividades de prueba.

FUENTE: [alarcos.esi.uclm.es - Plan de Pruebas](https://alarcos.esi.uclm.es/ipsw/metrica3/metrica_3/workproducts/plan_pruebas_A75C8154.html#:~:text=El%20plan%20de%20pruebas%20es%20un%20producto%20formal%20que%20define,de%20las%20actividades%20de%20prueba.)

3.2. Especificaciones de prueba

3.2.1. Documento de especificación del diseño de la prueba

**Edvin**:
* ¿Qué incluye?

>El documento de especificación del diseño de la prueba incluye las condiciones de la prueba, es decir los elementos de cobertura para el elemento de prueba, el enfoque de pruebas de forma detallada e identifica los casos de prueba de alto nivel asociados.

Fuentes:

[Globetesting.com - Documento de especificación del diseño de la prueba](https://www.globetesting.com/especificacion-de-diseno-de-prueba/)

**Aramis**:
* ¿Qué incluye?

> Incluye las condiciones de prueba (elementos de cobertura) para el elemento de prueba, el enfoque de pruebas de forma detallada e identifica los casos de prueba de alto nivel asociados. [IEEE 829]

Fuente:

[Documento de especificación del diseño de la prueba - globetesting.com](https://www.globetesting.com/especificacion-de-diseno-de-prueba/)

3.2.2. Documento de especificación de los casos de prueba

**Edvin**:
* ¿Qué incluye?

>El documento de especificación de casos de prueba describe un resumen detallado de los escenarios que se probarán, cómo se probarán, con qué frecuencia se probarán, etc., para una característica determinada.

Fuentes:

[Toolsqa.com - Documento de especificación de los casos de prueba](https://www.toolsqa.com/software-testing/test-case-specification/)

**Aramis**:
* ¿Qué incluye?

>El documento de especificación de casos de prueba describe un resumen detallado de los escenarios que se probarán, cómo se probarán, con qué frecuencia se probarán, etc., para una característica determinada.

Fuente:

[Documento de especificación de los casos de prueba - toolsqa.com](https://www.toolsqa.com/software-testing/test-case-specification/)

3.2.3. Documento de los procedimientos prueba

**Edvin**:

* ¿Qué incluye?

>El documento de procedimientos de casos de prueba incluye la secuencia de acciones para la ejecución de una prueba. También conocido como script de prueba o script de prueba manual.

Fuentes:
[Globetesting.com - Documento de los procedimientos prueba](https://www.globetesting.com/especificacion-de-procedimiento-de-prueba/)

**Aramis**:

* ¿Qué incluye?

> Incluye la secuencia de acciones para la ejecución de una prueba. También conocido como script de prueba o script de prueba manual. [IEEE 829]

Fuente:[Documento de los procedimientos prueba - globetesting.com](https://www.globetesting.com/especificacion-de-procedimiento-de-prueba/)

3.3. Informes de pruebas

**Edvin**:

* ¿Que incluyen?

>Los informes de pruebas debe incluir, el nombre del proyecto, todas las pruebas que ha recibido y todos los resultados de dichas pruebas

>Basicamente es un resumen de todo lo que se ha llevado a cabo en las pruebas.

**Aramis**:

* ¿Que incluyen?

> Debe incluir la siguiente información:
>
>Datos del proyecto o entrega que ha sido objeto de las verificaciones.
>
>Datos de las verificaciones realizadas, por ejemplo las fechas de realización de las pruebas, el objetivo de la revisión, etc.
>
>Resumen ejecutivo de los resultados, incluyendo una valoración final del conjunto de la prueba.
>
>Detalle de los resultados, donde pueda consultarse la descripción de los defectos y su localización exacta.

Fuente:

[Informe de pruebas - juntadeandalucia.es](https://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/39)