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: 

    • Unit. 
    • Integration. 
    • Functional/Non-functional. 
    • Load. 
    • Concurrency. 
    • System acceptance and validation.
    • Production installation. 
    • Regression.  

The purpose of test cases is not only to design them, but also to be able to create automatic test cases. At this point we emphasise that with TAST (Test Automation System Tool) we can create a good test strategy and guarantee good quality 


Teams of test specialists usually carry out the so-called black box test cases. In these test cases, through inputs, results are obtained, without it being necessary for the test specialists to know or understand how the application or system behaves. 


A test case consists of: 

  1. Name of the test case.

  1. General description of the test case. 

  1. The step-by-step of the execution, including a detailed description of the step and the expected outcome of each step. 

In addition, a test case may have:  

  1. Pre-conditions: Conditions that must be met before the test case can be executed.  

  1. Data: Set of data necessary to be able to execute the test case on the application or system under test (SUT).


In any automatic test case, there are four stages to be defined: 



After receiving all the information related to the system requirements, which may be functional and technical, these are reflected in the macro-architecture. We see the different modules, the different parts that make up the system, the technologies that interact between the different modules, etc. and we make a global definition. We then go on to design the test case, describing each step and the result we expect from each one. 


Mapping is the phase that is linked to automation. It is the moment when each of the steps and modules of the design is associated to the test system. The values that make it possible to connect to the system we want to test are validated and the data that allows this execution to be carried out are added.

Therefore, it is the first moment in which it is necessary to have the system to be tested, installed and accessible.


In this phase, the test case is executed. The execution can be manual or automatic. Within the automatic execution, there are two typesattended (on demand) or unattended (at night, on weekends, or at times when the test team is not present).  


Debugging is the phase of the test case where results are verified and validated, and evidence are obtained. It checks whether the actual result (result of the execution) is the expected result and documents are generated to “attest” to the result. 


It is very important to present evidence to know if the result has been correct or not, and to be able to establish where the error has occurred. The errors fall can fall into two types: 


  1. Test case error: This is the case where the design or the mapping of the test case is incorrect and it is necessary to adjust the design according to the requirements or to adjust the mapping, correctly associating the failed steps.
  2. Error of the software under test: This is the case where the application or system under test does not behave as expected, and therefore the defect, bug or issue needs to be reported to the development team for correction, presenting evidence of the problem.


If you need help with your testing strategy or you don’t know how to start automating it, contact SIPSA.