Skip to content

Commit

Permalink
Merge pull request #53 from ucudal/feature/testing
Browse files Browse the repository at this point in the history
Feature/testing
  • Loading branch information
fmachadopiriz committed Jun 16, 2024
2 parents adae119 + 80fc001 commit 2876a6d
Show file tree
Hide file tree
Showing 9 changed files with 370 additions and 15 deletions.
5 changes: 4 additions & 1 deletion .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -483,4 +483,7 @@ $RECYCLE.BIN/
*.swp

# Mac OS
.DS_Store
.DS_Store

# Temporary HTML file used to crear content for another MD file
temp.html
112 changes: 112 additions & 0 deletions 1_Contenido/1_3__Calidad.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,115 @@
# 1 Contenido

## 1.3 Calidad

Además de esta página te recomendamos leer sobre [conceptos de calidad de
software](/4_Conceptos/4_Calidad_de_software.md).

El propósito de esta sección en el documento del proyecto es documentar aspectos
relacionados con las pruebas, en particular, la estrategia de pruebas contenida
en el plan de pruebas y los casos de prueba y sus resultados.

El contenido de esta página está basado en [Disciplined Agile®
Delivery](https://www.pmi.org/disciplined-agile/process/introduction-to-dad)
—DAD— del [Project Management Institute](https://www.pmi.org), en particular en
la documentación sobre el [desarrollo de la estrategia de
pruebas](https://dabrowser.pmi.org/#item:272).

### Estrategia de pruebas

Definir una estrategia de pruebas implica tomar decisiones relacionadas,
entre otros, con los siguientes temas:

* El nivel de detalle de las pruebas
* Los enfoques de prueba
* Cómo se van a probar los requerimientos no-funcionales
* Los ambientes de prueba
* Los tipos de pruebas
* Las fuentes de datos de pruebas
* La estrategia de automatización —o no— de las pruebas
* Cómo se informan y gestionan los defectos encontrados

La estrategia de pruebas se define en la etapa de inicio del proyecto y se
documenta en el plan de pruebas usando [esta
plantilla](/3_Plantillas/3_8_Plan_de_pruebas.md), o en la herramienta de
automatización de pruebas [Azure Test
Plans](https://learn.microsoft.com/en-us/azure/devops/test/?view=azure-devops)
disponible como parte de la suscripción a [Azure Devops
Services](https://azure.microsoft.com/es-es/products/devops) a la que tienen
acceso con la cuenta de estudiante @correo.ucu.edu.uy; pueden utilizar otra
herramienta si lo acuerdan con su tutor[^1].

### Plan de pruebas

El plan de pruebas especifica cómo va a ser probada la aplicación y es el
resultado de la [estrategia de pruebas](#estrategia-de-pruebas) definida.

Debe incluir al menos los elementos obligatorios de la [plantilla de plan de
pruebas](/3_Plantillas/3_8_Plan_de_pruebas.md); si fuera necesario puede incluir
otros elementos opcionales de esa plantilla.

El plan de pruebas es parte de la primera entrega del proyecto.

### Enfoques de pruebas

Para cada elemento a probar —funcionalidades, interfaces con otros productos o
servicios, integración con otros productos o servicios— es necesario elegir uno
o más [enfoques de pruebas](/4_Conceptos/4_Enfoques_de_pruebas.md).

### Tipos de pruebas

Para cada combinación de elemento a probar y enfoque de pruebas es necesario
elegir uno o más [tipos de pruebas](/4_Conceptos/4_Tipos_de_pruebas.md).

### Datos de prueba

Cada caso de prueba requiere un conjunto de datos de prueba, aunque el mismo
conjunto de pruebas puede ser usado en varios casos de prueba. El conjunto de
datos de prueba puede ser generado automáticamente o puede ser creado a partir
de datos existentes anonimizados.

Los datos de prueba deberían estar bajo control de configuración, al igual que
los casos de prueba.

### Casos de prueba

Los casos de prueba describen cómo se realizan las pruebas, con qué datos, en
qué situación inicial de la aplicación, y cuál es el resultado correcto
esperado.

Para documentar los casos de prueba puedes usar [esta
plantilla](/3_Plantillas/3_4_Casos_de_prueba_de_usuario_final.md), o puedes usar
la herramienta [Azure Test
Plans](https://learn.microsoft.com/en-us/azure/devops/test/?view=azure-devops)
antes mencionada. Los casos de prueba se van generando luego de definida la
estrategia de pruebas en la etapa de inicio a medida que van creando [casos de
uso](/4_Conceptos/4_Caso_de_uso_del_producto.md), requerimientos funcionales y
no-funcionales, código, etc. a probar.

Los casos de prueba deben estar bajo control de configuración, al igual que los
datos de prueba.

### Resultados de las pruebas

El resultado de la ejecución de los casos de prueba debe ser registrado cada vez
que se ejecuta, tanto si fue exitoso como si no lo fue; en este último caso,
además, es necesario registrar el defecto en una herramienta de tiques para que
sea correctamente priorizado y gestionado.

### Automatización de las pruebas

Las pruebas pueden estar automatizadas, para poder repetirlas a lo largo del
proyecto. Los casos de prueba automatizados deben estar bajo control de
configuración.

Pueden usar la herramienta de automatización de pruebas [Azure Test
Plans](https://learn.microsoft.com/en-us/azure/devops/test/?view=azure-devops)
disponible como parte de la suscripción a [Azure Devops
Services](https://azure.microsoft.com/es-es/products/devops) a la que tienen
acceso con la cuenta de estudiante @correo.ucu.edu.uy.

[^1]: Ten en cuenta la seguridad y privacidad de la información que almacenes en
estos repositorios; si tienes un acuerdo de confidencialidad con el cliente,
deberías usar las herramientas recomendadas. También deberás considerar que
otras herramientas pueden tener costos asociados o limitar la cantidad de
usuarios o de archivos en las versiones gratuitas.
18 changes: 14 additions & 4 deletions 1_Contenido/1_4__Gestion.md
Original file line number Diff line number Diff line change
Expand Up @@ -315,6 +315,9 @@ Los productos esperados de esta etapa para cada dimensión son los siguientes:
* **Aseguramiento de la calidad**. Completen la sección de resultado esperado de
cada caso de uso, y asegúrense de que es verificable.

Definan también la estrategia de pruebas tal como se indica en la [sección de
calidad](1_3__Calidad.md#estrategia-de-pruebas).

Pueden usar la rúbrica de la primera entrega para evaluar lo que hayan
avanzado del producto que van a entregar, teniendo en cuenta que hay otras
etapas por completar antes de esa entrega. No es necesario que entreguen esta
Expand Down Expand Up @@ -366,6 +369,11 @@ Los objetivos de esta etapa son:
Pueden usar [historias de usuario](/4_Conceptos/4_Historia_de_usuario.md) para
especificar los requerimientos.

* Actualizar el [plan de pruebas](/3_Plantillas/3_8_Plan_de_pruebas.md) y
agregar los [casos de
prueba](/3_Plantillas/3_4_Casos_de_prueba_de_usuario_final.md) en aquellos
casos que sea posible.

* Definir la arquitectura detallada y las tecnologías que vas a utilizar.

* Implementar la mínima cantidad de requerimientos —puede ser uno— que permita
Expand Down Expand Up @@ -398,7 +406,10 @@ Los productos esperados de esta etapa para cada dimensión son los siguientes:
que hayan escogido para validar la arquitectura. Incluyan instrucciones para
que su tutor pueda ejecutar la solución en un ambiente de desarrollo.

* **Aseguramiento de la calidad**. Pruebas de unidad para el código entregado.
* **Aseguramiento de la calidad**. Los [casos de
prueba](/3_Plantillas/3_4_Casos_de_prueba_de_usuario_final.md) en los casos en
que sea posible y pruebas de unidad para el código entregado si fuera parte de
la estrategia de pruebas.

* **UX/UI**. Maquetas para la interfaz de usuario del o de los casos de uso
elegidos para validar la arquitectura.
Expand Down Expand Up @@ -483,9 +494,8 @@ Los productos esperados de esta etapa para cada dimensión son los siguientes:
* **Aseguramiento de la calidad**. Las pruebas de unidad para el código
entregado.

Casos de prueba de usuario final para los casos de uso del producto incluidos
en esta fase. Datos de prueba para esos casos de prueba. Resultados de esas
pruebas.
Casos de prueba para los casos de uso del producto incluidos en esta fase.
Datos de prueba para esos casos de prueba. Resultados de esas pruebas.

En caso de que corresponda, pruebas de carga para mostrar el funcionamiento
correcto de la arquitectura.
Expand Down
4 changes: 0 additions & 4 deletions 1_Contenido/1__Contenido.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,10 +12,6 @@ Acá va lo que veníamos poniendo en el documento de notas de arquitectura y dis

## 1.3 [Calidad](./1_Contenido/1_3__Calidad.md)

### 1.3.1 Casos de prueba

### 1.3.2 Resultados de las pruebas

## 1.4 [Gestión](./1_Contenido/1_4_Gestión.md)

Acá van los aspectos metodológicos, de procesos de ingeniería de software, de
Expand Down
23 changes: 17 additions & 6 deletions 3_Plantillas/3_4_Casos_de_prueba_de_usuario_final.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,16 +2,27 @@

## 3.4 Casos de prueba de usuario final

Esta es la plantilla para documentar los casos de prueba de usuario final. El
producto a probar es la aplicación desplegada en un ambiente de prueba. Aunque
la redacción de la plantilla asume una prueba manual, esta plantilla puede ser
utilizada también para escribir el guión de una prueba automatizada.
Esta es la plantilla para documentar los casos de prueba. El producto a probar
es la aplicación desplegada en un ambiente de prueba. Aunque la redacción puede
implicar una [prueba de aceptación de usuario
final](/4_Conceptos/4_Tipos_de_pruebas.md), esta plantilla también puede ser
utilizada también para escribir el guión de otros tipos de pruebas.

Los casos de prueba de usuario final están agrupados en esta plantilla por
módulos. En este contexto un módulo puede ser un [caso de uso del
Los casos de prueba están agrupados en esta plantilla por módulos. En este
contexto un módulo puede ser un [caso de uso del
producto](/4_Conceptos/4_Caso_de_uso_del_producto.md) o una
[épica](/4_Conceptos/4_Epica.md).

En lugar de esta plantilla pueden utilizar la herramienta de automatización de
pruebas [Azure Test
Plans](https://learn.microsoft.com/en-us/azure/devops/test/?view=azure-devops)
disponible como parte de la suscripción a [Azure Devops
Services](https://azure.microsoft.com/es-es/products/devops) a la que tienen
acceso con la cuenta de estudiante @correo.ucu.edu.uy

<!-- TODO: Revisar si es aplicable a todos los tipos de pruebas y adaptarlo para que
lo sea. -->

<table>
<tr>
<td style="color:#0969DA">
Expand Down
148 changes: 148 additions & 0 deletions 3_Plantillas/3_8_Plan_de_pruebas.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,148 @@
# 3 Plantillas

## 3.8 Plan de pruebas

Esta es la plantilla para el plan de pruebas. Las entradas obligatorias de la
plantilla están marcadas <span style="color:#0969DA;font-weight:
bold;">así</span> y las demás entradas y el texto a completar en el color
normal.

<table>
<tr>
<td style="color:#0969DA" valign="top">
<b>Alcance</b>
</td>
<td>
Describe qué es lo que se está probando del proyecto, por ejemplo,
las funcionalidades de un producto, las interfaces con otros
productos o servicios, o la integración con otros productos o
servicios.
<br>
<br>
A cada uno de los elementos que se van a probar nos referiremos como
un componente de las pruebas.
</td>
</tr>
<tr>
<td style="color:#0969DA" valign="top">
<b>Estrategia</b>
</td>
<td>
Describe en qué consisten las pruebas a realizar. Para cada <a
href="/4_Conceptos/4_Epica.md">épica</a> —o grupo de
funcionalidades—, especifica los
<a href="/4_Conceptos/4_Enfoques_de_pruebas.md">enfoques</a> de las
pruebas, los <a href="/4_Conceptos/4_Tipos_de_pruebas.md">tipos</a>
de pruebas, y la automatización —o no— de las pruebas, que garantiza
que estos grupos de funcionalidades sean probados adecuadamente.
Especifica las principales actividades, técnicas y herramientas que
se utilizan para probar lo que se haya incluido en el alcance.
<br>
<br>
La estrategia se debe describir con suficiente detalle como para
permitir la identificación de las principales tareas de prueba y la
estimación del tiempo necesario para realizar cada una.
<br>
<br>
De aquí se derivan luego los casos de prueba que se documentan en
<a href=
"/3_Plantillas/3_4_Casos_de_prueba_de_usuario_final.md">esta</a>
plantilla, o que se cargan en la herramienta de automatización
de pruebas <a
href="https://learn.microsoft.com/en-us/azure/devops/test/?view=azure-devops">
Azure Test Plans</a> disponible como parte de la suscripción a
<a href=ref="https://azure.microsoft.com/es-es/products/devops">Azure
Devops Services</a> a la que tienen acceso con la cuenta de
estudiante@correo.ucu.edu.uy.
</td>
</tr>
<tr>
<td style="color:#0969DA" valign="top">
<b>Ambientes</b>
</td>
<td>
Describe los ambientes que serán usados para las pruebas. Puede
haber uno o más de un ambiente para diferentes estrategias de
prueba.
</td>
</tr>
<tr>
<td valign="top">
Calendario
</td>
<td>
Define cuándo se completan los diferentes casos de pruebas.
</td>
</tr>
<tr>
<td style="color:#0969DA" valign="top">
<b>Reporte de problemas</b>
</td>
<td>
Indica qué ocurre cuando se encuentran errores en alguna de las
pruebas, por ejemplo, cómo y dónde se crean los tiques para que se
corrijan esos errores, cómo se priorizan los tiques, etc.
</td>
</tr>
<tr>
<td valign="top">
<b>Funcionalidades a probar</b>
</td>
<td>
Identifica todas las funcionalidades del software que se van a
probar. Es opcional en la medida de que sea redundante con lo
indicado en la sección de alcance.
</td>
</tr>
<tr>
<td valign="top">
<b>Funcionalidades fuera de alcance de las pruebas</b>
</td>
<td>
Identifica todas las funcionalidades que no se van a probar y las
razones para ello.
</td>
</tr>
<tr>
<td valign="top">
<b>Roles y responsabilidades</b>
</td>
<td>
Especifica los miembros del equipo o del cliente que participan en
las pruebas y cuáles serán sus funciones. Identifica las personas
responsables de gestionar, diseñar, preparar, ejecutar y resolver
las actividades de prueba, así como los problemas relacionados.
También identifica los responsables de proporcionar los ambientes de
prueba.
</td>
</tr>
<tr>
<td valign="top">
<b>Dependencias</b>
</td>
<td>
Identifica limitaciones importantes en las pruebas, como la
disponibilidad de elementos de prueba, disponibilidad de recursos de
prueba y plazos.
</td>
</tr>
<tr>
<td valign="top">
<b>Riesgos y suposiciones</b>
</td>
<td>
Identifica los supuestos de alto riesgo del plan de pruebas y
especifica planes de contingencia para cada uno.
</td>
</tr>
<tr>
<td valign="top">
<b>Herramientas</b>
</td>
<td>
Enumera las herramientas de automatización que va a utilizar y
también la herramienta de tiques de errores.
</td>
</tr>
</table>

10 changes: 10 additions & 0 deletions 4_Conceptos/4_Calidad_de_software.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
# 4 Conceptos

## Calidad de software

El contenido de esta página no necesariamente está basado en las últimas
versiones de las fuentes utilizadas en su redacción original; se aceptan
[contribuciones](/CONTRIBUTING.md).

TODO: Incluir a continuación el documento de calidad del grupo de trabajo en
ingeniería de software
Loading

0 comments on commit 2876a6d

Please sign in to comment.