Conceptos en Pruebas y validación de software
Pruebas funcionales
Definición
Están orientadas al comportamiento externo en las pruebas de caja negra[3]. Son las encargadas de demostrar si el software comple o no con sus especificaciones. Las pruebas funcionales las escribe el cliente con ayuda del tester[1] por tal motivo estas pruebas se realizan desde el punto de vista del cliente, ingresando entradas y examinando las salidas generalmente sin considerar su estructura interna. La especificación de estas pruebas puede ser analizada para derivar casos de prueba[2].
Ejemplo
El cliente requiere que el software en la sección de Blog, cualquier usuario sin importar si está registrado pueda escribir comentarios en el post, sin embargo si es necesario que se especifique el correo de quien escriba el comentario.Prueba funcional: Se está ingresando al post en la parte inferior del artículo se visualiza una sección de comentarios donde están dos entradas de texto y un botón de comentar. Una de las entradas debe esta indicando que es para ingresar el correo electrónico y la otra para el comentario. Ya se ingreso un correo no válido y un texto cualquiera en el otro campo y se dio click en comentar pero arrojó un mensaje indicando que no es un correo válido, se volvió a ingresar un correo correcto y la pagina quedo en blanco y luego cargó todo nuevamente y ya veo que el comentario que escribí esta en la parte final de otros comentarios antes realizado, puedo visualizar el correo electrónico que ingrese y el timestamp del comentario.
Pruebas no funcionales
Definición
Están orientadas al comportamiento externo del software y en la mayoría de los casos utilizan técnicas de diseño de pruebas de caja negra. Estas pruebas permite corroborar aspectos no funcionales del software como la usabilidad, calidad, seguridad; que son importantes ya que pueden comprometer el funcionamiento básico del sistema en determinadas situaciones [4].Ejemplo
Se requiere que el sistema capaz de soportar alta concurrencia de usuarios a la hora del diligenciamiento y envío del formulario para solicitud de crédito.
Prueba funcional: Se creó un script capaz de ingresar a aplicativo web, llenar el formulario y enviarlo, el script está diseñado para representar a 30.000 usuario ingresando, diligenciado y enviado el formulario. Se corre el script y el reporte de dicho script muestra que solos 10.000 de los hilos fueron satisfactorios es decir solo 10.000 usuarios pudieron completar el envío del formulario los otros la página web ya no respondía.
Pruebas Estructurales
Definición
También denominadas pruebas de caja blanca o caja de cristal o caja transparente, estas pruebas se derivan a partir del conocimiento de la estructura e implementación del software [5]. Estas pruebas permiten verificar el funcionamiento lógico y detalles de la arquitectura[6].Ejemplo
Se está haciendo la prueba al módulo de búsqueda de posts del blog, este realiza la búsqueda a la en la base de datos teniendo en cuenta la frase de búsqueda la cual se hace tanto en titulo del post, como en el contenido del mismo, se identifica que primero se hace la búsqueda de la frase en el título y se guardan los resultados en una variable en forma de arreglo o array luego se realiza la búsqueda de la frase en el contenido de los post y se guardan los resultados en una variable en forma de arreglo, luego hace una combinación de los dos arreglos en uno solo siendo este nuevo arreglo los resultados de la búsqueda.
Se identifica que la búsqueda se puede mejorar en un solo query a la base de datos realzando el query con la busqueda por titulo y contenido al mismo tiempo.
Botton-Up
Definición
En una metodología donde se reúnen diferentes sistemas para conformar un todo. Los elementos individuales son especificados con gran detalle, denominados componentes, los cuales se van uniendo unos con otros para formar un sistema final o un todo. Se comienza con los elementos mas básicos y específicos, se continua formando un nivel mayor de componentes hasta llegar el punto de tener el sistema de alto nivel.Top-Down
Definición
Esta metodología toma la totalidad del sistema de software como una entidad y lo descompone para conseguir más de un componente y a su vez estos componentes pueden ser divididos en sub componentes. Este proceso continúa funcionando hasta llegar al nivel más bajo del sistema en la
jerarquía Top-Down.
Prueba de pareto
Es un principio denominado la regla del 80/20, el cual dice:“El 80% de los fallos de un software es generado por un 20% del código de dicho software, mientras que el 80% genera tan solo un 20% de los fallos”[8]
Durante la fase de pruebas se puede llegar a notar un patrón donde muchos de los errores reportados están relacionados con módulos dentro del sistema, por tal motivo acá es donde se da la aplicación de dicho principio.
Pruebas Estáticas
Es un tipo de técnica de pruebas que no ejecutan el software, no ejecutan código pero realizan el análisis estático del código, realiza revisiones de los documentos del proyecto, como puede ser especificaciones de diseño, requisitos casos de pruebas, etc [8].Análisis estático: Su objetivo es detectar defectos en el código fuente y en los modelos del software. Ayudan a la detección temprana de defectos, ya sea por aspectos sospechosos del código o del diseño.
Revisiones: Permiten la detección y corrección temprana de posibles defectos. Existen varios tipos de revisiones como pueden ser: Revisión informal, Revisión guiada, Revision tecnica, Inspeccion.
Pruebas Dinámicas
Es un tipo de técnica de pruebas que se realizan ejecutando la aplicación y son las usadas para el diseño de los casos de pruebas, en este tipo de técnicas encontramos las pruebas de Caja blanca y Caja negra las cuales ayudarán a definir los casos de prueba para tener la mayor probabilidad de encontrar los errores[8]. Este tipo de técnicas deben ejecutarse después de las pruebas estáticas[10].
Artefactos
Matriz de pruebas y plan de riesgos
Estos dos artefactos serán de ayuda para que al ejecutar los casos de pruebas se pueda dictaminar si el caso funciona adecuadamente y establecerlo como conforme o no conforme. Dependiendo de la matriz que se utilice las métricas están acorde a esta y a una clasificación y tendrán un nivel o puntuación.El plan de pruebas sera una guia para que el equipo de desarrollo realice las optimizaciones de las herramientas, técnicas y conocimiento.[3]
Bibliografía
[1] Canós, J. H., & Letelier, M. C. P. P. (2012). Metodologías ágiles en el desarrollo de software.
[2] Esmite, I., Farías, M., Farías, N., & Pérez, B. (2007). Automatización y gestión de las pruebas funcionales usando herramientas open source. In XIII Congreso Argentino de Ciencias de la Computación.
[3] Mera Paz, J. A. (2016). Análisis del proceso de pruebas de calidad de software.
[4] Berlanga Fuentes, J. (2012). Altair-T: Sistema de detección y gestión de amenazas sobre activos.
[5] Sommerville, I. (2005). Ingeniería del software. Pearson Educación.
[6] Pressman, R. S., & Troya, J. M. (1988). Ingeniería del software.
[7] Cristiá, M. (2009). Introducción al testing de software. Recuperado el, 14.
[8] Sánchez Peño, J. M. (2015). Pruebas de Software. Fundamentos y Técnicas.
[9] Soares, G. (2011). Software Testing and its Relationship to the Context of the Product Las Pruebas del Software y su Relación con el Contexto del Producto. REVISTA ANTIOQUEÑA DE LAS CIENCIAS COMPUTACIONALES Y LA INGENIERÍA DE SOFTWARE, 15.
[10] de Abadia, M. E. V. (2010). Procedimientos para prueba de software. Publicaciones Icesi, (18).