Clase 2. Análisis de requerimientos y Condiciones de prueba

Clase 2. Análisis de requerimientos y Condiciones de prueba

By Heison Moreno

Utest para tomar experiencia:

​

https://www.utest.com/

​

By Heison Moreno

• ¿Para qué se prueban los sistemas?

• ¿Para qué sirve un lenguaje de programación?

• Diferencia entre pruebas estáticas y dinámicas.

• Cuáles son las fases del ciclo de vida del software.

• Cuáles son las fases del ciclo del testing.

• Qué es un ambiente de pruebas

• Qué hace un analista funcional, un programador, un tester.

• Diferencia entre backend y frontend.

​Esta clase forma parte de la fase ANÁLISIS DE REQUERIMIENTOS en el ciclo de vida del testing

​Recordemos lo que es un requerimiento

• ​Una especificación del sistema.

• Puede ser un caso de uso, historia de usuario

• Documento funcional

• Prototipo/wireframe

• FUNCIONAL Y NO FUNCIONAL​

  ​

​Nuestro insumo de trabajo son los requerimientos, de ellos derivamos nuestras pruebas

​

Casos de uso, documentos funcionales, prototipos/wireframes, etc.​ (Ejemplos en Trello)

Formato de requerimientos

​

Casos de uso

​

Documentos funcionales

​

Historia de usuario (ver siguiente lámina)...​

Formato de requerimientos "ágiles"

​

Las iniciativas: son conjuntos de epics que conducen hacia un objetivo común:

Ejemplo: reducir la pérdida de clientes que solicitan créditos.

​

Épicas: ​son grandes cantidades de trabajo que se pueden desglosar en un número de tareas más pequeñas (llamadas "historias").

Ejemplos: HU 1: Formato de solicitud básico / HU 2: Validar referencias personales / HU 3: Calificación. ​

​

​Las historias: también llamadas "historias de usuario", son breves requisitos o solicitudes escritas desde el punto de vista del usuario final.

​Las historias tienen TAREAS técnicas asociadas. ​

Formato de requerimientos: Historia de usuario

​

​

​Como usuario de Mercado Libre

Quiero usar diversos medios de pago a través de carrito de compras

Para poder ​comprar productos de manera fácil

Formato de requerimientos

​

​

Formato de requerimientos

​

​

Formato de requerimientos

​

​

Formato de requerimientos

​**Épica: onboarding

• *Historia

Como usuario de la app

Quiero validar mi foto

Para registrarme en la app ​

​

• Tareas: ​

1-. Integración con sistema de validación InVision

2-. Diseño de pantalla para captura de foto

3-. Creación de tabla para registro de imágenes​

Formato de requerimientos

​

​

​

Aprendamos a analizar requerimientos

​

-¿Es correcto el requerimiento?​ Consistente, claro, no ambiguo.

​​

-Entender los requerimientos, para ello, hacer un listado de preguntas para el analista funcional o a quien corresponda.

​

Ejemplo en: https://docs.google.com/document/d/1-VJhB6f5g02mebsT8LEy1osatVpJJO35PnEv9WrSk2w/edit?usp=sharing​O35PnEv9WrSk2w/edit?usp=sharing​

​​

​

​

​

​

​

​

​​

​

​

​

​

Analizar requerimientos implica:

​

​

• Pasos que hay que seguir para que la funcionalidad ocurra ¿Dónde se ingresa, qué se selecciona, dónde hay que hacer clic, es una o varias pantallas las que hay que recorrer? 

​

​

​​

​

​

​

​

Analizar requerimientos implica:

​

​

• Luego identifica los DATOS: ¿Hay que ingresar datos por teclado o seleccionarlos desde un combo box, check box, toggle, hacer solo clic en menús? 

​

• Si los datos son ingresados por el usuario, identifica qué tipo de dato es: numérico (entero o decimal), alfabético, alfanumérico, caracteres especiales. 

​

​​

​

​

​

​

Analizar requerimientos implica:

​

​Finalmente, identifica el manejo de errores, esto se refiere a si en el requerimiento o la documentación está especificado qué hará el sistema cuando se presente un error, este es un listado general de los errores más comunes: 

-Cuando no hay conexión o se corta en medio de una operación

-Cuando se le ingresan datos distintos a los que el campo espera

-Cuando el usuario intenta saltarse algún paso o tomar otro camino para realizar la misma funcionalidad

-Cuando se deja un campo en blanco, sin ingresar datos.​

​

​

​​

​

​

​

​

Analizar requerimientos implica:

​

aunque NO estén contemplado ese manejo de errores en los requerimientos, por ejemplo, no está escrito qué hará la app si en vez de un número en un campo que solicita un DNI, se ingresa una letra, tú DEBES identificar condiciones de test sobre esto, porque es probable que el usuario de la app por equivocación o de manera intencional haga eso y lo que un buen sistema debería hacer es mostrar un mensaje de error indicando al usuario lo que hizo mal, por ejemplo: “Usted ingresó un DNI inválido”.​

​

​

​​

​

​

​

​El análisis de requerimientos deriva en CONDICIONES DE PRUEBAS: ​

​

Las condiciones de prueba indican qué probar, cuáles son la validaciones a hacer, son los títulos de los futuros casos de pruebas.

Agilidad-Scrum

​

Historia: https://es.linkedin.com/pulse/historia-de-las-metodolog%C3%ADas-%C3%A1giles-en-contexto-dami-buonamico

​

Valores: https://www2.deloitte.com/es/es/pages/technology/articles/incomprension-valores-scrum.html

​

Manifiesto ágil: ​https://agilemanifesto.org/iso/es/manifesto.html

​

​

​​

​

​

​

Entornos complejos VUCA ​

​

​

​Fórmula: 3-5-3

​

3 Roles

5 Eventos

3 Artefactos​

​

Pilares: Transparencia-Inspección-Adaptación

​

​

Kanban​

​

​