slider-1

slider text 1 Centro de Desarrollo:

Centro de Desarrollo:

SCRUMstudy353_386

slider text 2 Centro de entrenamiento Autorizado VMEdu:

Centro de entrenamiento Autorizado VMEdu:

slider-3

slider text 3 Programa de Innovación

Programa de Innovación

CASOS DE PRUEBA

 

cool cartoon 52625791 CASOS DE PRUEBA

Durante mi experiencia en el campo de desarrollo de software, una de las herramientas más útiles que he podido experimentar para ayudar a esclarecer el alcance de cualquier proyecto son los casos de prueba. Existen muchas maneras de levantar requerimientos, diferentes documentos como Casos de Uso, Historias de Usuario, diagramas, etc, pero al final, todos deben de una u otra manera aterrizar en un documento que indique lo que se va a probar, para aceptar el software, y esos son los casos de prueba.

En una ocasión,  para un proyecto, que llevaba ya aproximadamente tres años sin culminarse, donde no había ningún documento para especificar el alcance, salvo una hoja con varios puntos, para un sistema inmenso, algo como ” el sistema debe tener a, b c, … etc. “, y recién ingresé como consultor,  nos tocó proponer utilizar casos de prueba para poder delimitar el alcance, el cliente aceptó; tomó aproximadamente un año adicional pero se logró terminar.

Sin irnos de manera estricta a alguna metodología en especial, en términos simples, un buen documento de casos de prueba debe tener lo siguiente:

1. Identificación: Preferiblemente un nombre que indique a que funcionalidad o grupo de funcionalidades se refiere el caso de prueba.
2. Cada escenario o caso de prueba debe tener una identificación, en este caso preferiblemente un número o código, para poder identificar en herramientas de manejo de incidentes cuando existe un problema con el escenario, por ejemplo “Fallo en el login, cuando te equivocas tres veces se inactiva la cuenta … o son 4″, es más fácil ” Falló el caso de prueba de ingreso #35
3. Cada caso o escenario debe tener una descripción de los pasos o campos que se llenan que sea única, y un resultado esperado, para el cual el caso es satisfactorio.
4. Recuerden que también hay que incluir escenarios negativos, es decir, debemos probar cuando las cosas salen mal que el sistema reaccione como es esperado.

Saludos

 

 CASOS DE PRUEBA

Acerca

No comments yet. You should be kind and add one!

Leave a Comment

Allowed tags: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>