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:
- Camino básico. Que se ejecute por lo menos una vez cada instrucción del programa.
- Condiciones. Garantizar que todas las condiciones se comprueban como verdaderas y falsas.
- 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