PRUEBA DEL SOFTWARE: MÁS QUE UNA FASE EN EL CICLO DE VIDA

INTRODUCCION

Este escrito nos habla básicamente de la forma como los probadores de software deben realizar las

distantes pruebas, a través de las cuatro fases que son Modelar el entorno del software, Seleccionar

escenarios de prueba, Ejecutar y evaluar los escenarios y Medir el progreso de las pruebas, con el

objetivo principal de que el software salga con los errores menores posibles, lo que conlleva en cada

etapa a realizar los correctivos necesarios y las pruebas necesarias.

RESUMEN

Los testers deben tener en cuenta siempre las 4 fases y en cada una determinar los problemas para

así pasar a la siguiente, tomando en cuenta la teoría de grafos, la lógica y algoritmia. En la parte de

modelación del entorno del software el probador debe tener en cuenta las interfaces humanas en

este caso la interfaz gráfica de usuario de esta manera determinar cuál debe ser la prueba

determinante en esta interfaz. En la interfaz de software es importante que el probador revise como

el sistema operativo interactúa con los datos, las librerías. En la interfaz de sistema de archivos el

tester debe verificar si el software está escribiendo datos en archivos externos. En la de

comunicación, que a través de protocolos el probador revisa que se permita la comunicación del

software con los dispositivos físicos en cuanto a que un usuario elimine un archivo de otro usuario

y que pasa con este archivo si es vuelto a consultar. Si un dispositivo se reinicia en un proceso de

comunicación y el software es capaz de sobre ponerse a este incidente etc. etc.

Ante lo anterior el probador debe verificar las entradas correctas con las variables de entrada

determinadas y adecuadas ya que el programa puede que acepte múltiples variables como entrada.

En los escenarios de prueba hay que saber que solo un conjunto de estos se puede utilizar ya que

es costoso y quita mucho tiempo, en este caso el probador ejecuta cada línea de código dos veces

y que cubre las entradas, estos dos son los criterios mínimos pero normalmente se escoge los que

cumple con cobertura. Aun así el software sigue saliendo con errores ya que el código sigue un

número infinito de caminos por lo cual es necesario escoger el más conveniente, como dicen los

usuarios y profesionales de calidad es mejor evaluar los escenarios de uso típico donde se asegura

que el software cumpla con lo que se requirió y donde están los errores más frecuentes. En los

caminos de ejecución se podría decir que se deben seleccionar casos de prueba en los cuales cada

sentencia se ejecute al menos una vez, y las estructuras de control se evalúen en cada uno de sus

caminos, un caso de prueba donde se evalúen errores sembrados. Criterios de entrada, elegir casos

de prueba par entradas físicas, pruebas en las interfaces de entrada menús, ventanas, botones

donde estos se recorran. Es necesario que los probadores usen criterios que reporten resultados.

Cuando ya se tienen los casos de prueba los probadores deben automatizar estos ya que son muy

intensivos, esto quiere decir que es necesario automatizar todo el proceso tanto el de las posibles

entradas y salidas. En cuanto a los escenarios es más complicado porque estos no se pueden

automatizar y deben simular casi con exactitud el software como si estuviera en un ambiente real.

Podemos entonces ver los dos enfoques de las pruebas: la formalización que tiene que ver

netamente con las especificaciones lo cual reduce significativamente el tiempo en encontrar

anomalías no especificadas como errores. Código de prueba embebido el sencillo que el probador

puede tener acceso a través de un API o un depurador y el más complejo donde se tratan multiplex

soluciones a un problema. Luego de las pruebas con éxito los desarrolladores realizan una nueva

versión donde los errores encontrados se eliminan, características y funcionalidades nuevas así

evitando realizar pruebas de regresión que acarrearía costos altos y no se podrían utilizar pruebas

ya realizadas en la fase anterior.

Finalmente para medir el progreso de las pruebas es contar con varias cosas, es decir el progreso

con el cual se han ejecutado las pruebas, (código cubierto, No de veces que se ha ejecutado la

aplicación con éxito, número de entradas aplicadas etc. etc.). Estos valores no dicen mucho ya que

en muchas ocasiones los probadores alteran estos para dar respuesta. Con las preguntas correctas

acerca de las pruebas realizadas, es posible cuantificar la cantidad de errores y de que estos sean

descubiertos por los usuarios y se podrían acercar al problema de forma estructural y funcional.

Según Jeffrey Voas, el número de líneas de código no determina la dificultad la prueba, es decir si el

producto tiene la capacidad de prueba será más fácil encontrar los errores, con este concepto es

posible acercarnos más a la realización de un producto con menos errores.

La fiabilidad está en una etapa de poca demostración, sin embargo salvo en dominios de aplicación

específicos y estudios de casos exitosos han demostrado con los modelos de fiabilidad son posibles.

CONCLUSION

Sin lugar a duda los procesos o procedimientos de prueba nos llevan a lograr con éxito en un gran

porcentaje, un software de muy alta calidad con muy baja tasa de errores, tomando con seriedad

estas cuatro etapas o fases de prueba que son vitales y que además determinan si se debe continuar

o no con la siguiente etapa con el objetivo de corregir el máximo de anomalías, también el papel del

probador es de suma importancia y que el aplique los criterios necesarios y sea transparente en

todos los niveles de las pruebas y que además esta labor se haga en conjunto con el o los

desarrolladores.

GLOSARIO

Graphical User Interface GUI : La interfaz gráfica de usuario, conocida también como GUI (del inglés

graphical user interface), es un programa informático que actúa de interfaz de usuario, utilizando

un conjunto de imágenes y objetos gráficos para representar la información y acciones disponibles

en la interfaz. Su principal uso, consiste en proporcionar un entorno visual sencillo para permitir la

comunicación con el sistema operativo de una máquina o computador.

Application Programming Interfaces: La interfaz de programación de aplicaciones, abreviada como

API1 (del inglés: Application Programming Interface), es el conjunto de subrutinas, funciones y

procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta biblioteca

para ser utilizado por otro software como una capa de abstracción.

Son usadas generalmente en las bibliotecas de programación.

Boundary Value Partitioning: Análisis del valor de Límites y Equivalencia de partición, se explica con

un simple ejemplo: Análisis de valores en la frontera y la equivalencia de particionamiento ambos

prueban las estrategias de diseño en caso de pruebas de caja negra.

Kleene: Es un teorema de lógica que que usa la (v) como clausula u operador lógico.