viernes, 11 de octubre de 2013

Diagnóstico en la etapa de Testing



Realicemos una vista un poco más técnica del área de testing, conceptos, sus tipos de pruebas, y el impacto del diagnóstico en el proceso de producción, repasaremos los puntos más importantes de cada tipo así como algunos datos importantes que se tienen que considerar al realizar el análisis de un sistema o aplicación.

Un diagnóstico, es cuando se realiza un análisis sobre una situación tomando como base una  tendencia. Esta es una gran herramienta para el proceso de un producto pues permite ahorrar costos al momento de realizar la tarea de cumplimiento de los estándares y atributos de calidad.

Es un elemento crítico para la garantía de calidad del software dado que se optimizan las pruebas realizadas que representan una revisión final de las especificaciones, del diseño y de la codificación.

En la fase de pruebas se refiere a realizar una evaluación general  del  resultado obtenido y verificar si se cumplió o no con lo que se esperaba, pero para poder generar un buen diagnóstico es necesario conocer si se refiere a un defecto, error o fallo:
  • Defecto. Es el resultado de una mala definición de datos o pasos de un procesamiento.
  • Error. Equivocación cometida por un desarrollador. Por ejemplo divisiones entre cero.
  • Fallo. Proveniente del defecto, es la consecuencia del comportamiento incorrecto de un proceso.



“El nivel de conocimiento del tester sobre un negocio debe ser similar al del usuario que utilizará el sistema”. Cada error que se encuentre significa un éxito para la calidad del sistema.

Existen diferentes metodologías de pruebas que ayudan a una entrega de mayor calidad en el producto. Por ejemplo, caja blanca y caja negra.


Diagnóstico de Caja Blanca

Para poder generar un buen diagnóstico de caja blanca es necesario tener un conocimiento amplio sobre la interacción interna con la que cuenta la aplicación, como por ejemplo:
  • Conocimiento de base de datos, tablas, procedimientos.
  • Conocer el diagrama entidad relación.
  • Lenguaje de programación (acceso al código fuente).
  • Uso de Web Services (es una tecnología que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones).
  • Conocimiento de cómo está desarrollado el sistema internamente.


Esta clase de análisis requiere mayor inversión y quizá de herramientas para llevarse a cabo, pero el resultado es igualmente más provechoso y con mayores ventajas, dado que el resultado será preciso y en la gran mayoría de los casos, contundente.

Las pruebas de este tipo se pueden clasificar según sus objetivos en tres tipos:
  1. Camino básico. Que se ejecute por lo menos una vez cada instrucción del programa.
  2. Condiciones. Garantizar que todas las condiciones se comprueban como verdaderas y falsas.
  3. Bucles. Que se ejecuten los bucles, probando el caso general y los casos extremos. 
Unos consejos de validación de este tipo de pruebas serian:
  • Validar todas las cadenas vacías, en la base de datos.
  • Verificar componentes de fechas para evitar que al detectar que se encuentre vacía no genere error.
  • Generar un timed out mayor a cualquier proceso que pueda tener el sistema, esto para evitar que el tiempo de respuesta de algún módulo sea mayor al tiempo de sesión del sistema.
  • Antes de que se realice la entrega final del sistema , reiniciar todos los identity de la base de datos.


Diagnóstico de Caja Negra

El diagnóstico de caja negra (se lleva a cabo sobre la interfaz del software, obviando el comportamiento interno y la estructura del programa), es cuando se realiza superficialmente, sin entrar detalladamente en la razón de la posible falla o malfuncionamiento, dado que no se conoce el funcionamiento interno del producto ni los componentes que lo conforman, esta forma de diagnóstico puede ser bastante subjetiva por lo mismo, dado que podría incluso tratarse de un defecto de usuario y no del producto.

Es esencial en esta tipo de análisis que la persona o el grupo de personas que se encargan de realizarlo, conozcan a plenitud el comportamiento y/o resultado esperado, pues de lo contrario el riesgo de pasar por alto un defecto es latente, así como de entorpecer el trabajo de producción al reportar un diagnóstico equivocado o que los encamina lejos del verdadero origen de la falla.
















Los casos de prueba de la caja negra pretenden demostrar que, las funciones del software son operativas, la entrada se acepta de forma correcta, se produce una salida correcta y la integridad de la información externa se mantiene

Además pretenden encontrar tipos de errores como funciones incorrectas o ausentes, errores en la interfaz, errores en estructuras de datos o en accesos a bases de datos externas, errores de rendimiento, errores de inicialización y de terminación.

Para realizar un buen diagnóstico de caja negra es necesario conocer el negocio y las especificaciones concretas que el cliente definió en la fase de análisis.


Herramientas para el diagnóstico


  • La principal herramienta para un buen diagnóstico es tener un conocimiento sobre el flujo del negocio del sistema que se está evaluando.
  • La metodología es de gran ayuda, dado que nos muestra los pasos a seguir y evita caer en errores por desatención o por omisión.
  • La documentación es  muy importante, dado que con ella estamos seguros de saber que hace el producto y como debe hacerlo, un ejemplo son los casos de prueba funcionales.
  • El estar en comunicación constante con todas las áreas del proceso, así como involucrarte en cada una, otorga una perspectiva más amplia al encontrarse con un defecto.
  • El administrador de tareas hace una función de herramienta de diagnóstico cuando se utiliza para revisar un proceso (tiempo de proceso, recursos utilizados, etc).


¿Qué hacer para realizar un buen diagnóstico?

Principalmente, saber las especificaciones del proceso que estas analizando, teniendo las mismas por escrito, además del conocimiento del flujo de operación, (que hace y que se espera como resultado), así como las partes que lo conforman.

Saber utilizar cada unas de las herramientas que tengas a disposición, así como realizar una buena observación, teniendo en cuenta siempre que un diagnóstico no se realiza para justificar, se hace para orientar.

Se deben considerar los aspectos relevantes y profundizar en ellos de forma que ayude a localizar el origen del defecto por parte del desarrollador.

No tener ningún prejuicio, es posible que basemos el diagnóstico en la experiencia, pero siempre con base en hechos, porque cada defecto es único y si se basa en suposiciones, puede darse el caso de que este tenga un origen diferente y por ello requiera de una mayor inversión de tiempo.


Acerca de los Autores

El siguiente blog fue realizado por Karla Ortiz y Moisés Rivas

Karla Ortiz es ingeniera en tecnologías de la información egresada de la Universidad Tecnológica de Jalisco con más de 3 años de experiencia en el área de pruebas y Moisés Rivas es un ingeniero en computación egresado de la Universidad de Guadalajara con más de 3 años de experiencia en el área de pruebas. Actualmente los dos colaboran con Dawcons como técnicos de pruebas de los sistemas hechos a la medida.

No hay comentarios:

Publicar un comentario