pair testing

Conceptos de pruebas del software

Monkey testing o testeo a lo loco

monkey-tablet
Consiste en hacer pruebas sin un objetivo concreto. Son pruebas realizadas de forma aleatoria. Los datos se introducen de forma aleatoria en el sistema.

Muchas veces se realiza este tipo de test en una primera instancia cuando se va a probar el software para ver si tiene un mínimo de consistencia.

Uno de los problemas de este tipo de pruebas es que cuando se detecta un error muchas veces es difícil de reproducirlo.

No se utilizan casos de pruebas ni escenarios de pruebas. Este test es un poco anárquico.

Los monkey testers tienen que ser personas con buenos conocimientos técnicos e intuición. Deberían ser programadores o personas que han programado.

Muchas veces se opta por este tipo de testing cuando hay deadlines o entregas apretadas. El testing de una aplicación no debería basarse solamente en esta técnica.

Pair testing o testeo en paralelo

pair testing
Esta técnica consiste en que dos tester se ponen de acuerdo para testear una aplicación y entre ellos van intercambiando ideas para realizar una prueba en profuncidad de la aplicación.

Una de las ventajas que tiene este tipo de test es que es ameno y en ocasiones genera más casos de prueba de una forma rápida y eficaz.

En ocasiones se colocan dos personas, una con más experiencia y otra con menos para de esa manera que le sirva de entrenamiento a la segunda.

Este tipo de estrategia genera coordinación, motivación y fomenta el trabajo en equipo.

Herramientas de automatización de testing/pruebas

javatest
La automatización de pruebas es uno de los objetivos de cualquier programador. No tener que probar un software o que la prueba sea automática hace que nos olvidemos de una de las más tediosas y aburridas fases del desarrollo (las pruebas).

Muchas herramientas de testeo automáticas nos permiten generar datos de prueba, instalar el producto, interaccionar con el interfaz de usuario, registrar problemas o errores, etc.

Antes de decantarnos por alguna herramienta de automatización de test de software deberíamos estudiar la capacidad para generar datos de prueba de la misma, la independencia de plataforma (no siempre vamos a desarrollar para la misma plataforma), la capacidad de programar las pruebas con un lenguaje de programación potente, cómo se registran o notifican los errores, cómo maneja el control de versiones, posibilidad de realización de test de forma desatendida, etc.

Algunas herramientas de este tipo son Rational Robot de IBM, Coded UI de Microsoft, Selenium (open source), Jmeter de Apache, Load Runner de HP, etc.

Testeo de abajo a arriba o bottom up testing

bottom_up_testing

En el testeo desde abajo o bottom up el objetivo es testear los módulos por separado para una vez realizado esto testear el sistema completo.

Teniendo en cuenta la imagen lo primero que se testeará son los módulos 4, 5, 6 y 7 de forma individualizada utilizando drivers de testing o programas que lo único que hacen es llamar a esos módulos.

Una vez testeado de forma individual los módulos terminales o hoja se testearán los módulos 2 y 3 y sus combinaciones 2-4, 2-5, 3-6 y 3-7.

Por último se testeará el 1-2 y 1-3.

Cuando se detecte un error habrá que registrar si ha fallado el módulo en cuestión o el interfaz entre un módulo y otro.

Dynamic testing, test dinámico o monitorización de rendimiento

En el dynamic testing o test de rendimiento, más que los fallos del software lo que se va a analizar y monitorizar son parámetros como el uso de CPU, tiempo de respuesta, uso de la memoria o rendimiento general.

Los test de rendimiento se pueden realizar a varias niveles. Se pueden probar y monitorizar ciertos módulos o funcionalidades, todo el sistema, la integración con otros sistemas, etc.

Failover testing o testing frente a fallos

network_not_available

El failover testing o testing frente a fallos intenta conocer cómo va a actuar un software concreto frente a fallos (no del propio software) no predecibles como cortes de luz, fallos de conectividad, falta de recursos (memoria, procesador, disco duro,…), etc.

Este tipo de test es muy importante para softwares productivos básicos en diferentes sectores como las telecomunicaciones, las plataformas de transacciones financieras o aplicaciones financieras y bancarias.

Hay que tener en cuenta que un error en el software puede repercutir en costes graves para la compañía por lo tanto es necesario tener previsto estos sucesos.

Además es preciso tener en cuenta la probabilidad de que un fallo imprevisto ocurra y la forma de recuperación del sistema a un estado operativo.

Gorilla testing

gorilla

Consiste en que tanto los desarrolladores como los tester se pongan de acuerdo para realizar pruebas exhaustivas a una parte o módulo de un software.

El objetivo de este tipo de pruebas es determinar la robustez del sistema o de parte de él.

En ocasiones no viene mal que tanto los tester como los programadores trabajen de forma conjunta (pair programming). De esa manera, los tester no son vistos como los chicos malos de la película que lo único que hacen es dar más trabajo a los programadores muchas veces con cambios caprichosos.

Pruebas de caja gris

cajagris

Todos los programadores hemos oido hablar de pruebas de caja blanca y pruebas de caja negra pero también existen las pruebas de caja gris en las cuales los tester tienen información más bién limitada de la funcionalidad interna de los programas.

Los tester de caja gris normalmente no tienen el código ni los documentos de desarrollo sino que tienen cierta información que les permite testear el software en profundidad.

Muchas veces previo petición los grey testers podrán acceder a las partes del código, base de datos, etc que necesiten o incluso a la documentación técnica.

Entre las ventajas del grey testing está el que combina los beneficios del test de caja blanca y el test de caja negra. Muchas veces los tester necesitan acceder a partes del código o de las bases de datos para detallar errores o probar ciertos aspectos del software más en profundidad.

Los grey testers serán profesionales independientes de los desarrolladores.

Test de rendimiento o performance testing

performance-testing

El objetivo del performance testing o test de rendimiento es determinar si un sistema funcionará de forma estable y con tiempos de respuesta aceptables bajo distintas cargas de trabajo.

En las pruebas se medirán aspectos de calidad del sistema como escalabilidad, uso de recursos y fiabilidad.

Algunas técnicas del performance testing son los test de carga en los que se mide la respuesta del sistema para varias cargas de trabajo, los test de estrés en los que se intenta buscar la máxima capacidad de trabajo del sistema, test de diluvio en los que se medirá fallos del sistema durante una carga de trabajo sostenida o también los test de picos o spike testing en los que de manera puntual se incrementan el número de peticiones o de usuarios en el sistema y se observan las consecuencias.

Quality assurance o garantía de calidad

qapassed

Siempre que se habla de testing/pruebas del software sale a relucir el término QA o garantía de calidad del software. Un software se entiende que es de calidad cuando cumple los requisitos para los que fué diseñado y las espectativas del usuario.

La calidad de un software se evalua durante todo el proceso de desarrollo del software (ciclo de vida).

Algunos criterios para establecer la calidad del software serían por ejemplo la eficiencia, la flexibilidad, la interoperabilidad, la facilidad de mantenimiento, la fiabilidad del mismo, la usabilidad, etc.

Testing temprano

El objetivo del testing temprano es mejorar la calidad de las aplicaciones detectando los errores en fases tempranas del ciclo de desarrollo. De esa manera se limita el impacto que tendrían sobre el proyecto global en fases más tardías.

¿Cómo se realiza este testing temprano?

Es importante la verificación de los requisitos del sistema puesto que si se cometen imprecisiones en la definición los problemas que se pueden ocasionar más tarde serían graves.

En las fases de análisis y diseño hay que revisar si alguno de los requisitos no ha sido tenido en cuenta o lo que es lo mismo, si se ha malinterpretado.

Si se tiene en cuenta el testing temprano, el impacto de cualquier error en una fase posterior será mucho menor dado que un error en una fase mas tardía tiene mejor arreglo y es menos costoso.

Verificación a la entrega del software

entrega software

Cuando se entrega un software, o antes de la entrega se deberían de realizar una serie de pruebas. Como mínimo se exige que se realicen dos tipos de pruebas, las pruebas técnicas y las pruebas funcionales.

En las pruebas técnicas se verificará que las normativas técnicas se cumplen y no van a contar con la presencia del usuario final. Se busca en el código la calidad, la claridad, mantenibilidad y el rendimiento.

Por otro lado, en las pruebas funcionales el objetivo es que los programas estén libres de errores. Antes realizarse con el usuario final (si es que se llegan a realizar) habría que realizarlas de forma cuidadosa puesto que los errores percibidos por el usuario final restan confianza sobre la aplicación al mismo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>