Pruebas Selene

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 5

4.

1 Diseño de casos de prueba


¿Qué es un caso de prueba?

Para nadie es un secreto que el inmenso mundo del desarrollo de software ha


tomado un auge inimaginable y que a medida que avanza, los niveles de
complejidad e interoperabilidad de los sistemas informáticos, programas y
aplicaciones incrementan y con ellos, las posibilidades de defectos de
esos productos. Es por eso, que los proveedores de software están poniendo
más atención a los temas de las pruebas de software antes de lanzar sus
productos al mercado. ¿Sabes que son las pruebas de software? Si no sabes, no
te preocupes, presta toda tu atención porque este tema es muy interesante.

Las pruebas de software (Software Testing) comprenden el conjunto de


actividades que se realizan para identificar posibles
fallos de funcionamiento, configuración o usabilidad de un programa o aplicación,
por medio de pruebas sobre el comportamiento del mismo.

Ahora que ya tienes bien claro qué son las pruebas de software. Te hablaré sobre
un elemento súper importante que te ayudará a verificar al detalle si tu software
cumple con cada uno de los requerimientos establecidos. Estoy
hablando de los casos de prueba. ¿Sabes que son los casos de prueba? Bueno, si
tienes tus dudas o tu respuesta fue negativa, no te desanimes, ahora te explico.

Según Wikipedia, un caso de prueba o test case es un conjunto de condiciones o


variables bajo las cuales un analista determinará si una aplicación, un sistema de
software (software system), o una característica de éstos es parcial o
completamente satisfactoria. Es decir, un caso de prueba es un conjunto de
pasos y resultados esperados que se crean a partir de
los requisitos del software que se va a probar.

Entonces, para cubrir el software más a fondo y con más detalle,


debe crearse al menos un caso de prueba por cada requisito definido y tener en
cuenta, todos los elementos de diseño, el uso de
todo tipo de datos de entrada/salida y cada comportamiento esperado.

Para lograr que el ciclo de prueba sea fluido y eficiente, los casos de


pruebas deben ser escritos de manera clara y compresibles. Además
de permitir que se ejecuten para revisar nuevas funcionalidades.

Cuando un caso de prueba finaliza su estado podrá ser:


Pasado: si todos los pasos a ejecutar han sido correctos.

Fallado: si uno o varios pasos han sido erróneos.

Bloqueado: si un caso de prueba anterior bloquea las funciones de los posteriores


casos de prueba.

N/A: si un caso de prueba definido ya no aplica al haber habido cambios en la


funcionalidad o requisitos.

Ahora que lograste adquirir nuevos conocimientos sobre los casos de prueba, te
detallo algunos pasos que debes tener en cuenta.

Entonces, lo que tienes que hacer es:

1. Identificar los requerimientos a probar y nombrar o numerar los casos de prueba


por cada requisito (establecer un identificador para cada caso de prueba).

2. Realizar un matriz de trazabilidad para vincular los requerimientos y los casos de


prueba entre sí.

3. Escribir una descripción general breve del caso de prueba, que permita a


cualquier persona sin conocimientos previos, comprender de qué trata el caso de
prueba.

4. Conocer cuál es la configuración o los prerrequisitos (los datos, el hardware, el


software, etc.) a tener en cuenta para poder ejecutar la prueba.

5. Definir la prioridad de ejecución de cada caso de prueba (alta, media o baja).

6. Describir los pasos necesarios para poder realizar cada caso de prueba.

7. Describir el resultado esperado y evidenciar el resultado obtenido (si la ejecución


fue exitosa o no).
Como pudiste apreciar, crear, estructurar y ejecutar un caso de prueba es bastante
sencillo, siempre y cuando se cuente con la información necesaria para su correcta
elaboración.

Propósitos de los casos de prueba

 Con el propósito de comprobar que todos los requisitos de una aplicación son
revisados, debe haber al menos un caso de prueba para cada requisito a menos
que un requisito tenga requisitos secundarios. En ese caso, cada requisito
secundario deberá tener por lo menos un caso de prueba. Algunas metodologías
como RUP recomiendan el crear por lo menos dos casos de prueba para cada
requisito. Uno de ellos debe realizar la prueba positiva de los requisitos y el otro
debe realizar la prueba negativa.
Si la aplicación es creada sin requisitos formales, entonces los casos de prueba se
escriben basados en la operación normal de programas de una clase similar.
Lo que caracteriza un escrito formal de caso de prueba es que hay una entrada
conocida y una salida esperada, los cuales son formulados antes de que se
ejecute la prueba. La entrada conocida debe probar una precondición y la salida
esperada debe probar una postcondición.

Tipos de prueba y su descripción


Pruebas estáticas
Son el tipo de pruebas que se realizan sin ejecutar el código de la aplicación.
Puede referirse a la revisión de documentos, ya que no se hace una ejecución de
código. Esto se debe a que se pueden realizar "pruebas de escritorio" con el
objetivo de seguir los flujos de la aplicación.
Pruebas dinámicas
Todas aquellas pruebas que para su ejecución requieren la ejecución de la
aplicación.
Las pruebas dinámicas permiten el uso de técnicas de caja negra y caja blanca
con mayor amplitud. Debido a la naturaleza dinámica de la ejecución de pruebas
es posible medir con mayor precisión el comportamiento de la aplicación
desarrollada.

Describa 3 Ejemplos

Valor límite
Para comprobar los valores en cualquiera de las restricciones laterales. Uno de
estos se relaciona con pruebas positivas, el otro con negativas. Es mejor aislarlos
para no perderse. Estas pruebas son una indicación de que posee un diseño de
prueba, que puede ver a continuación.
Por ejemplo, encontró la información en la documentación de que la contraseña
debe contener al menos 6 y no más de 60 caracteres. Así que debes averiguar
qué sucede si escribes 5, 6, 60 y 61 caracteres. No te olvides de un caso cuando
el campo está vacío.
Si la documentación no describe dichas restricciones, puede ofrecérselas usted
mismo, ¡discutiendo con el equipo!

Integración
Compruebe las conexiones entre las diferentes partes del programa. Este no es
exactamente el tipo de casos de prueba, sino el nivel de prueba. Pero tales
pruebas son necesarias. Debe describirlos, especialmente si su sistema consta de
al menos dos módulos.
Puede escribir casos de prueba para verificar el aspecto de los datos ingresados
en otra parte del software.
Por ejemplo, si tiene un pago para un cierto tipo de funcionalidad. Entonces,
definitivamente debe asegurarse de que esa funcionalidad esté disponible
después del pago. Después de todo, es probable que los desarrolladores hayan
implementado estas partes por separado, y pueden surgir problemas cuando
integran esas partes.

Prueba de localización
Verifique todos los elementos de la interfaz de usuario en diferentes idiomas y sus
ubicaciones (si existe un soporte para idiomas con diferentes reglas de escritura y
lectura).
Por ejemplo, si su software es compatible con uno de los lugares donde se ubica
la IU de derecha a izquierda, debe prestar atención al trabajo de la Lista
desplegable, las casillas de verificación, la activación / desactivación de
elementos, etc.

Pruebas escritas para comprobar la GUI. Puede describir la aparición de consejos


en las teclas de acceso rápido del programa, errores, etc.
Si tiene suficiente tiempo, puede escribir casos de prueba que lo ayudarán con las
pruebas multiplataforma, especialmente si el programa depende de las
plataformas.
Si tiene un gran software que admite varios idiomas, cree un capítulo aparte para
el caso de prueba de localización.

También podría gustarte