Un caso de prueba es una secuencia de ejecución detallada que nos ayuda a validar paso a paso una funcionalidad o un requerimiento sobre un sistema, donde podemos comprobar si el resultado obtenido coincide con el resultado esperado. En el caso de no coincidir estos resultados, nos ayuda a buscar donde se ha producido el error y corregirlo. 

 

Hay diferentes tipologías de Casos de Pruebas. Las más importantes son: 

La finalidad de los casos de prueba no sólo es poder diseñarlos, sino poder crear casos de pruebas automáticos.  En este punto destacamos, que con TAST (Test Automation System Tool) podremos hacer una buena estrategia de pruebas y garantizar una buena calidad. 

 

Qué es un caso de prueba

Los equipos de especialistas de pruebas normalmente llevan a cabo, los casos de prueba llamados caja negra. En los que a través de unos inputs de entrada, se obtienen unos resultados, sin que sea necesario que los especialistas de prueba conozcan o entiendan cómo se comporta la aplicación o el sistema. 

 

Un caso de prueba (TC) consta de: 

  1. Nombre del TC. 
  1. Descripción general del TC. 
  1. El paso a paso de la ejecución, que incluye una descripción detallada del paso y el resultado que esperamos de cada uno de ellos   

Además, un caso de prueba puede tener:  

  1. Pre-condiciones: Condiciones que deben cumplirse para poder ejecutar el TC.  
  1. Datos: Conjunto de datos necesarios para poder ejecutar el TC en la aplicación o el sistema bajo prueba (SUT).  

 

 

En todo caso de prueba automático hay cuatro etapas que definir: 

 

Diseño

Después de recibir toda la información relativa a los requisitos del sistema, que podrán ser funcionales y técnicos, estos quedan reflejados en la macroarquitectura. Vemos los distintos módulos, las distintas partes que conforman el sistema, cuáles son las tecnologías que interactúan entre los diferentes módulos, etc. y hacemos una definición global. Posteriormente pasamos a diseñar el TC, describiendo cada paso y el resultado que esperamos de cada uno. 

Mapeo

El mapeo es la fase que está ligada a la automatización. Es el momento en el que se asocia cada uno de los pasos y módulos del diseño al sistema de prueba. Se validan los valores que hace posible la conexión con el sistema que queremos probar y se añaden los datos que permiten que se haga esa ejecución.  

Por tanto, es el primer momento en el que es necesario tener el sistema a probar, instalado y accesible.  

Ejecución

En esta fase se ejecuta el TC. La ejecución puede ser manual o automática. Dentro de la ejecución automática, hay dos tipos:  atendida (bajo demanda) o desatendida (por la noche, en fin de semana, o en momentos donde el equipo de prueba no esté presente).  

Depurado

El depurado es la fase del TC en el que se verifican y validan los resultados y se obtienen las evidencias. Se comprueba si el resultado actual (resultado de la ejecución) es el resultado esperado y se generan los documentos para dar “fe” del resultado. 

 

Es muy importante presentar evidencias para saber si el resultado ha sido correcto o no, y poder establecer dónde se ha producido el error. Puede ser de dos tipos: 

 

  1. Error del caso de prueba:
    Es el caso en el que el diseño o el mapeo son incorrectos y es necesario ajustar el diseño de acuerdo con los requisitos o ajustar el mapeo, asociando correctamente los pasos fallidos. 
  2. Error del software bajo prueba:
    Es el caso en el que la aplicación o el sistema bajo prueba no se comporta conforme a lo esperado, y, por tanto, hay que reportar el defecto, bug o incidencia al equipo de desarrollo para que lo corrijan, presentando las evidencias del problema. 

 

Si necesitas ayuda con la estrategia de pruebas o no sabes como empezar a automatizarlas, contacta con SIPSA sin ningún tipo de compromiso.