Definición y diseño de pruebas

Apuntes:

Definición y Diseño de Pruebas

¿Qué hace un tester?

1. Encontrar problemas
   Si no encuentra problemas antes de que el producto sea entregado al cliente, entonces su testing es ineficiente.
2. Documentar problemas
   Si cuando encuentra problemas no sabe documentar y reproducir los pasos correctos su testing genera retrabajo y sube el costo.
3. Comunicar problemas
   Si como representante de la calidad del producto no sabe argumentar y proteger los intereses del negocio o los clientes, entonces su testing no agrega valor.

Platzi tiene un curso de Arquitectura de Información que se puede complentar muy bien con ésta clase.

En una de las clases mencionan el tener en cuenta el contexto. Ejemplo:

1. Tenemos una App de seguros de autos que tiene un botón para solicitar ayuda en calidad de emergencia.
2. Hay usuarios que van a tener internet por estar en x zona de la ciudad, pero otros no lo tendrán por estar en carretera, etc.
3. Necesitaremos cumplir los requerimientos, ofreciendo un botón para ejecutar una llamada rápidamente u otra solución alterna.

Les dejo el link de la clase por si quieren revisar con más detalle.
Este ejemplo empieza en el minuto 5.

Para especificar un caso de prueba es necesario al menos estos 4 detalles de información:

1.- Que queremos hacer con el nombre
2.- Una descripción que explique el caso de prueba
3.- Los pasos necesarios para ejecutarlo y en cada paso que esperamos que suceda.

Sin embargo, al momento de ejecutar y documentar el caso de prueba, necesitamos adicionar más información, como lo es: los resultados actuales y esperados, ya sea paso por paso o al finalizar toda la prueba. Todo dependerá del tipo de prueba ya que de acuerdo a ello, esta información podrá incrementar.

¿Cómo identificar si esto realizando un buen testing?

• Si no encuentras problemas antes de que el producto sea entregado al cliente, entonces tu testing es ineficiente.
• Si cuando encuentras problemas no sabes documentar y reproducir los pasos correctos su testing genera retrabajo y aumenta los costos.
• Si como representante de la calidad del producto no sabes argumentar y proteger los intereses del negocio o los clientes, entonces su testing no agrega valor.

Definición y diseño de pruebas
Que hace un tester?

1. Encontrar problemas
2. Documentar problemas
3. Comunicar problemas

Diseño de caso de prueba:

• Nombre
• Descripción
• Pasos
• Resultados esperados
• Resultados obtenidos

¿Que hace un tester?
1. Encontrar problemas
2. Documentar problemas
3. Comunicar problemas

Hice mi diseño de prueba aplicado a Didi
en observaciones agregue evidencias del error presentado, en este caso un screenshot

Estar pensando constantemente en el contexto me hace un mejor desarrollador.

Creo que también es importante agregar a la tabla el campo Precondiciones, las cuales describen las condiciones que se deben cumplir antes de la ejecución de cada caso de prueba.

Esto es algo básico para cada tester. Hay varias cosas necesarias que debemos comprender y estar seguros de para qué lo hacemos.

Tu obligación y por lo que vas a brillar es porque sabes Encontrar Problemas, Documentarlos y Comunicarlos. Es crucial documentar, diseñar y nuestros casos de prueba contengan la información necesaria para que se entienda el trabajo.

Para documentar usamos coda y loom video, es practico rapido y tiene una buena visibilidad

Trabajo del tester: Hacerse preguntas

Un ejemplo de la planilla de reporte de incidencias que cree en mi trabajo. Le agregué una sección de estadísticas que muestra un detalle gráfico del estado general de las incidencias.

Tres cosas que te harán brillar como tester:

1. Sabes encontrar problemas
2. Documentarlos de acuerdo a las metodologías establecidas
3. Comunicarlos bien
4. Siempre preguntarse en que otras circunstancias se puede probar el software y probar más escenarios posibles.

Diseño de caso de prueba. Planilla base
Nombre: Que es lo queremos hacer?
Descripción: explicar de que se trata la prueba. Definición clara y detallada, tanto como se pueda, para tratar de reducir la cantidad de pasos.
Pasos: explicar cada uno y como los vamos a seguir. Se pueden enumerar en orden que deben seguirse.
Resultados esperados: Que esperamos que suceda? en cada paso.
Resultados actuales: lo que realmente sucede. En cada paso y en la prueba total.
Es fundamental documentar todo el proceso

++Para especificar un caso de prueba es necesario al menos estos 4 detalles de información:
++

1.- Que queremos hacer con el nombre
2.- Una descripción que explique el caso de prueba
3.- Los pasos necesarios para ejecutarlo y en cada paso que esperamos que suceda.

Sin embargo, al momento de ejecutar y documentar el caso de prueba, necesitamos adicionar más información, como lo es: los resultados actuales y esperados, ya sea paso por paso o al finalizar toda la prueba. Todo dependerá del tipo de prueba ya que de acuerdo a ello, esta información podrá incrementar.

Es muy similar a escribir la definición de un Caso de Uso. 😃

Definición y diseño de pruebas

• Encontrar problemas
• Documentar problemas
• Comunicar problemas

Casos de prueba:

• Nombre
• Descripción
• Pre requisitos (acrogeria este también)
• Pasos
• Resultados esperados
• Resultados actuales

![](

Les comparto el Archivo de Google Sheets

¿Qué hace un tester?

1. Encontrar problemas
2. Documentar problemas
3. Comunicar problemas

Si no encuentras problemas antes de que el producto sea entregado el cliente, entonces su testing es ineficiente.

Si cuando encuentras problemas, no sabes documentar y reproducir los pasos correctos, el testing genera retrabajo y sube el costo.

Si como representate de la calidad del producto no sabes argumentar y proteger los intereses del negocio o los clientes, entonces el testing no agrega valor.

Quizá me perdí de algo, la pregunta es:

¿Por qué el siguiente enlace en está lección?

https://platzi.com/clases/angular/

¿Que hace un tester?

1. Encontrar problemas
2. Documentar problemas
3. Comunicar problemas

Si un tester no encuentra problemas antes de que el producto sea entregado al cliente, entonces su testing es ineficiente.

Si cuando encuentra problemas no sabe documentar y reproducir los pasos correctos su testing genera retrabajo y sube el costo.

Si como representante de la calidad del producto no sabe argumentar y proteger los intereses del negocio o los clientes, entonces su testing no agrega valor.

El caso de prueba es el punto mas importante para documentar y revisar en conjunto las condiciones y 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

.

Elementos básicos contenidos en un caso de prueba

• Nombre del caso de prueba (lo que vamos a probar)
• Descripción detallada de lo que queremos lograr
• Pasos de prueba: El paso a paso detallado con el cual podemos desarrollar la prueba.
• Resultados esperados: Lo que esperamos que suceda (que funcione)
• Resultados actuales: Lo que realmente sucede. Es algo como el meme de expectativa vs realidad, pero esta es la cruda realidad.

Apuntes :

1. Si en la prueba no se encuentran bugs el trabajo es ineficiente
2. Si se documenta bien el error encontrado evitara retrabajo
3. Aprender a comunicar bien ,argumentando y protegiendo los intereses del negocio

¿Que debe contener un caso de prueba?

• Nombre del caso de prueba
• Descripción del caso (que debe hacer o pasar)
  -Pasos (pasos a seguir al hacer el caso de prueba )
  -Resultados esperados (que se espera que pase al realizar los pasos)
  -Resultados actuales (lo que se obtuvo al realizar la prueba)

El buen tester siempre se debe hacer preguntas

Esta es una de las clases más importantes de este curso.

Definicion y diseño de pruebas

Que hace un tester?
-Encontrar problemas.
-Documentar problemas.
-Comunicar problemas

Si cuando encuentras un problema no lo sabes documentar, no ayuda mucho, es mejor hacer las cosas bien desde el principio, asi todos van a entender y empatizar con el problema que estoy escribiendo.

La ejecucion de pruebas debe ser clara para todos.

ES CRUCIAL DOCUMENTAR Y DISEÑAR BIEN, UN TESTER DEBE DE BRILLAR POR HACER PREGUNTAS

No. Prueba No. de bug Descripción de la prueba. Datos de prueba Tipo de prueba Fecha de la prueba. Resultado Esperado Resultado Obtenido ¿Prueba aprobada? OBSERVACIONES
SI NO

Que debe de contener un caso de prueba?
Nombre: Que pretendo hacer
Descripcion: De que se trata la prueba
Pasos: Que pasos debo seguir
Resultado esperado: Que espero ver
Resultado actual: Que veo

Me falta alguna columna de la data de prueba

¿Qué hace un tester?

1. Encontrar problemas
2. Documentar problemas
3. Comunicar problemas

(https://drive.google.com/file/d/1CWj2FXhUBOH5lfBjGLg9thWoPEZwOFb-/view?usp=sharing)

realice este ejercicio sobre esta clase pero no se si este bien.

https://www.loadview-testing.com/es/blog/tipos-de-pruebas-de-software-diferencias-y-ejemplos/

Que buena clase!!!

¿Qué hace un tester?

Encontrar problemas

Documentar problemas

Comunicar problemas

Si cuando encuentra problemas no sabe documentar y reproducir los pasos correctos su testing genera retrabajo y sube el costo

Si como representate de la calidad del producto no sabe argumentar y proteger los intereses del negocioo los clientes, entonces su testing no agregar valor

¿Qué debe de contener un caso de prueba?
Debe tener:

nombre: corta descripcion de lo que se va a realizar

descripción: Explicación de que se trata la prueba

pasos: Cada uno de los pasos de la prueba

resultados esperados

resultados actuales

En resultados actuales, Como se puede hacer para crear un documento que tenga varias ejecuciones de casos de pruebas, ya que cuando se encuentran errores, se deben solucionar, y se deben volver a ejecutar. ¿Hay una buena practica para solucionar esto y seguirlo manejando en un documento vivo como excel? Supongamos que el caso de prueba tiene 10 ejecuciones, y cada ejecución tuvo resultados diferentes y se realizaron en tiempos diferentes. ¿Hay que crear un columna por cada ejecución?

Muy buen detalle el del Caso de Prueba!

Esto es algo básico para cada tester. Hay varias cosas necesarias que debemos comprender y estar seguros de para qué lo hacemos.

Tu obligación y por lo que vas a brillar es porque sabes ** Encontrar Problemas, Documentarlos y Comunicarlos**. Es crucial documentar, diseñar y nuestros casos de prueba contengan la información necesaria para que se entienda el trabajo.

En mi trabajo usaba códigos para identificar los casos de pruebas, aunque me gustaría saber como definir bien, también se adjuntaba la fecha y el estado critico del caso de prueba, si era un estado bajo, medio o alto.

Si no encuentro problemas antes de que el producto sea entregado
Investigar acerca del software

• cuando encuentras un problema no lo sabes documentar y reproducir los pasos
• desde el principio debes encontrar el problema y saber documentar

Es importante documentar bien diseñar bien

• los caso de prueba se deben entender

Muy buena informacion.

Es importante cuestionar y cuestionarnos todo el tiempo, conocer el proceso, el proyecto y estar seguros de nuestras capacidades y habilidades.
Lo más importante es apuntar a los objetivos principales de la gerencia

Control de Calidad, a través de estándares y normativas
Control de Garantía de Calidad.
Normativas señaladas por la Dirección Técnica.
Formatos de Expedición de Producto Acabado y devoluciones de Cliente.

Yo realizo los testcases del paso a paso que se va a realizar en el sistema si tengo pasos de verificación los incluyo en otro archivo de excel haciendo énfasis que es un proceso manual del usuario donde solo probare al sistema

Me queda la duda de en que etapas se utilizan los casos de prueba.

Yo prefiero usar Trello para gestionar mis pruebas

Es cierto que la documentación y comunicación de el sistema que estamos desarrollando es importantísimo, ya que yo me pongo en el lugar del cliente y quiero que el manual o la documentación en caso de software sea lo mas clara posible

• MODULO

• PANTALLA

• PRECONDICIONES

• PRUEBA

• RESULTADO

• FECHA PRUEBA

• FUNCIONARIO

• #BUG / OK

Test Plan:
A document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning.