Pruebas de software

Pruebas de software

 

Isis Yasmin Lozano Chicas^a, Danny Noel Ramírez Flores^b

Ernesto Antonio Araujo Pleitez^c

a Estudiante de Ingeniería en Sistemas en la UNAH

yazz_lochi@hotmail.com

b Estudiante de Ingeniería en Sistemas en la UNAH

dnramirezf@gmail.com

c Estudiante de Ingeniería en Sistemas en la UNAH

ernesto.araujo92@gmail.com

Resumen.

Hoy en día la dificultad que presenta la elaboración de un software web exige que se realicen procesos de prueba durante el desarrollo de aplicaciones web para lograr una plena satisfacción por parte del cliente. Estas pruebas forman parte del abanico de pruebas disponibles para los diferentes productos de software. Las necesidades que son inherentes a las aplicaciones web son las que conllevan a un par de agregados a las pruebas de software comunes.

.

Abstract. Today the difficulty of developing a web software requires testing processes are carried out during the development of web applications to achieve full satisfaction for the customer. These tests are part of the range of tests available for different software products. The needs that are inherent in the web applications are leading to a couple of additions to common software testing.

Palabras Claves. Software, pruebas, testing, seguridad, caja negra, caja blanca.

Pruebas de software

Las pruebas de software (en inglés software testing) son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Es una actividad más en el proceso de control de calidad.

Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento de dicho proceso de desarrollo. Existen distintos modelos de desarrollo de software, así como modelos de pruebas. A cada uno corresponde un nivel distinto de involucramiento en las actividades de desarrollo.

Principalmente se debe verificar que se cumplan con las especificaciones planteadas desde un inicio por el analista o el propio cliente, y/o eliminar los posibles errores que se hayan cometido en cualquier etapa del desarrollo.

Hoy en día es, en muchos aspectos, una de las etapas críticas dentro del ciclo de vida del software. Existen, de hecho, diferentes metodologías para llevar a cabo las pruebas de calidad de manera óptima, y que tienen en cuenta la complejidad de trabajar con diferentes lenguajes de programación, sistemas operativos, arquitecturas hardware, etc. Debido a esto último, el proceso de “testing” debe basarse en metodologías o métricas generales que revisen los aspectos fundamentales del sistema, desde el seguimiento de errores, automatización de pruebas unitarias, etc. (Fiestas, 2014)

Las pruebas de software son las investigaciones empíricas y técnicas cuyo fin es proporcionar información objetiva e independiente sobre la calidad del producto. Esta actividad forma parte del proceso de control de calidad global. Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software y dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento del proceso de desarrollo.

Para conseguirlo, en realidad no existen las "mejores prácticas" como tal, debido a que cada práctica puede ser ideal para una situación pero completamente inútil o incluso perjudicial en otra, por lo que las actividades de testeo, técnicas, documentación, enfoques y demás elementos que condicionarán las pruebas a realizar deben ser seleccionados y utilizados de la manera más eficiente según contexto del proyecto.

Necesidad de realizar pruebas.

La labor de desarrollar software en una empresa trae consigo la necesidad de asegurar que el trabajo realizado se acerca (en lo posible) a la perfección en cuanto calidad y desarrollo seguro. Esto redunda en la satisfacción del equipo que logra los objetivos, así como también  por parte del cliente que obtiene el mayor beneficio de un producto finalizado.

Además, como toda buena inversión, ahorra tiempo a largo plazo. Si trasladamos por ejemplo los conceptos al entorno móvil, para asegurar el correcto funcionamiento de las aplicaciones en cada tipo de terminal y sistema operativo, el equipo de pruebas debe realizar diversos test a diferentes niveles.

Siguiendo el proceso de desarrollo software, tras la realización del análisis, diseño y en algún punto del desarrollo de la aplicación debe iniciarse la etapa de pruebas. Para esto es necesario un ambiente aislado del de desarrollo y el de producción, es decir, debería simularse la ejecución de la aplicación en un entorno idéntico a donde se va a ejecutar. Esto incluye la mayor muestra posible de sistemas "estándar" de usuario, en el caso de que se trate de una aplicación destinada al público en general, donde es imposible simular todos los escenarios.

Equipos de pruebas

Un aspecto importante para todas las empresas debe ser el tener un buen equipo de “testers” que cuenten con las herramientas necesarias para realizar las labores de pruebas de una manera eficiente, o bien un conjunto reducido de testers experimentados que lleven la búsqueda de fallos con la metodología con la que están habituados trabajar y en el menor tiempo posible.

Una práctica común (más informal pero bastante difundida) es distribuir una versión beta y que sean los propios usuarios quienes encuentren los fallos y los reporten. Aunque, los betatesters, pueden pasar por alto test importantes como "pruebas de estrés", "test unitarios", etc. que detectan fallos a nivel modular, o que no puedan comunicar de forma efectiva los problemas y/o fallas encontrados.

Una recomendación importante es que los desarrolladores de una aplicación no pueden ser a su vez testers de esa aplicación. Ser juez y parte hace que se pierda objetividad debido a la presunción de que su desarrollo es totalmente fiable, a la consideración de que determinados elementos no son relevantes a verificar, etc. (Fiestas, Jhoatan).

Por ello es necesario que el equipo que realiza las pruebas se encuentre totalmente desligado del equipo de programación. En este sentido, surge también una alternativa bastante interesante que es la realización de testeo cruzado entre equipos de trabajo, es decir, un equipo de desarrollo se encarga de realizar las pruebas sobre el software creado por otro equipo y viceversa. Aunque según disponibilidad de personal, siempre será mejor un equipo especializado en realizar estas labores.

Tipos de pruebas

Existen una gran variedad de pruebas, el uso de una u otra depende del caso específico de la aplicación entre ellas tenemos:

·         Pruebas de Compatibilidad: Son las pruebas que se realizarán en un software o aplicación determinado y que comprobarán que tu desarrollo es compatible con todos los navegadores de Internet y todos los sistemas convenientes. Estas pruebas son realmente importantes para que tu producto llegue a todos los usuarios que deberían de llegar y que todo el mundo pueda utilizarlo con lo que disponga en su equipo informático.

·         Pruebas de regresión: Se evalúa el correcto funcionamiento del software desarrollado frente a evoluciones o cambios funcionales. El propósito de éstas es asegurar que los casos de prueba que ya habían sido probados y fueron exitosos permanezcan así. Se recomienda que este tipo de pruebas sean automatizadas para reducir el tiempo y esfuerzo en su ejecución.

·         Pruebas de Integración: Es el nivel de pruebas posterior a las pruebas modulares de los componentes de un sistema. Se centra principalmente en probar la comunicación entre los componentes de un mismo sistema, comunicación entre sistemas o entre hardware y software.  

·         Pruebas de revisión de código.

·         Pruebas de penetración: El objetivo de estos tests de penetración, que perciben el sistema de forma transparente, es simular el comportamiento de un intruso malicioso que contase con permisos de acceso e información precisa acerca del sistema.  

·         Las pruebas de caja blanca (también conocidas como pruebas de caja de cristal o pruebas estructurales) se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al código fuente. El testeador escoge distintos valores de entrada para examinar cada uno de los posibles flujos de ejecución del programa y cerciorarse de que se devuelven los valores de salida adecuados.

·         Pruebas de caja negra: En pruebas de software, conociendo una función específica para la que fue diseñado el producto, se pueden diseñar pruebas que demuestren que dicha función está bien realizada. Dichas pruebas son llevadas a cabo sobre la interfaz del software, es decir, de la función, actuando sobre ella como una caja negra, proporcionando unas entradas y estudiando las salidas para ver si concuerdan con las esperadas.

Tanto si opta por una revisión de código o por una prueba de penetración, ellas solo valen la pena si usted corrige las vulnerabilidades encontradas por el proceso. Ambas revisiones solo proporcionan una instantánea de la seguridad de una aplicación en un punto en el tiempo.

Solucionar problemas a nivel de código puede reducir el número de defectos de diseño y codificación relacionados con la seguridad que quedan hasta la versión de lanzamiento, mejorando así la seguridad general de la aplicación dramáticamente. Además, una revisión del código puede descubrir fallas en la lógica de la aplicación, que es algo contra lo que un firewall de aplicación web no puede proteger. Con acceso al código fuente, los revisores pueden examinar exactamente cómo fluyen los datos a través de la aplicación, y cómo determinados tipos de datos, como números de tarjetas de crédito y otros datos personales, se procesan y se protegen; por ejemplo, cuándo y cómo los datos sensibles se cifran y descifran. La principal desventaja de una revisión de código es que es una manera prolongada y costosa de encontrar fallas de seguridad en todas las aplicaciones web, excepto las más básicas.

Aquellos que revisan el código necesitan tener una amplia experiencia en desarrollo de aplicaciones y pericia en seguridad, pero no pueden ser los mismos que escribieron el código original. Tener un equipo tan dedicado es solo económico para las grandes empresas, que están desarrollando constantemente sus propias aplicaciones. Las herramientas de análisis automatizado de código fuente de las aplicaciones pueden acortar el tiempo para revisar aplicaciones grandes y complejas. Si bien ellas pueden identificar los problemas en los cuales los analistas necesitan concentrarse, no pueden probar la adherencia a la política de seguridad o identificar puertas traseras en una aplicación de la misma forma que una revisión de código manual.

una prueba de penetración se basa en su cobertura no solo de la aplicación, sino también del entorno en el que opera. Puede poner a prueba la resistencia de la red y la aplicación, así como los controles y procesos en torno a ellos. Una prueba de penetración completa puede incluir controles físicos de seguridad, la resistencia de los empleados a la ingeniería social, las conexiones inalámbricas y cualquier otro método de acceso posible a las aplicaciones.

Pruebas en Aplicaciones web

Estas pruebas son una actividad a través de la que un sistema se ejecuta sobre unas condiciones o requerimientos específicos. Los resultados obtenidos a partir de estos procesos son observados, registrados y evaluados por los especialistas en desarrollo software.

Una prueba se enfoca sobre la lógica interna del programa y sobre las funciones externas. Con estas pruebas se desvelan posibles errores cometidos en la elaboración del producto. Un buen proceso de prueba es aquel que tiene una alta probabilidad de encontrar un error no descubierto hasta entonces.

Los objetivos de la fase de pruebas son los siguientes:

·         Encontrar y documentar defectos que pueda tener el producto web.

·         Validar que funciona para lo que ha sido diseñado.

·         Verificar requisitos que debe de cumplir el Software.

·         Validar interacción e integración de los componentes.

·         Asegurar que los defectos encontrados se han corregido antes de la entrega al cliente.

Las pruebas que realiza las empresas de desarrollo web se clasifican en dos grandes grupos: pruebas de caja negra y pruebas de caja blanca.

Caja negra: con esta prueba se demuestra el correcto funcionamiento de los interfaces del proyecto web.

Caja blanca: se demuestra el funcionamiento interno del módulo se adapta a las especificaciones y que los componentes internos funcionan correctamente; es decir; se ponen a prueba todos los caminos lógicos de la programación.

En cuanto a la realización de las pruebas se basan en testeos a diferentes niveles, se necesita probar si cada unidad funciona correctamente, luego es necesario probar si los distintos módulos encajan entre sí y por último pruebas al proyecto web globales.

Los principios básicos de las pruebas son:

1. La prueba es usada para verificar la presencia de errores, nunca su ausencia.

2. La dificultad del proceso de prueba es la decisión de cuando un producto está completamente testeado.

3. Evitar casos no planificados, no reutilizables o triviales.

4. Definición de los resultados esperados para cada prueba.

5. Se deben de tener en cuenta tanto entradas y salidas válidas como los casos inesperados.

6. Las salidas deben de ser las deseadas o controladas. Se empiezan por las funciones más sencillas y se avanza hasta las más complejas.

8. A excepción de las pruebas de unidad e integración, el proyecto web será testeado por personal del equipo de proyecto.

Con base en estos principios se definen los siguientes tipos de pruebas:

·         Pruebas de Unidad: Se prueban todos los caminos de control importantes con el fin de descubrir fallos en las funciones o módulos.

·         Pruebas de Integración: A partir de la funcionalidad del producto web se construye una estructura de programa que este de acuerdo con el contenido.

·         Pruebas del Sistema: Verifica que cada elemento encaja de forma adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total. La prueba del sistema está constituida por una serie de pruebas diferentes cuyo propósito primordial es ejercitar profundamente el sistema.

·         Pruebas de regresión: Se ejecutan sobre las nuevas versiones realizadas sobre los módulos.

·         Pruebas de Seguridad: Verificación de los mecanismos de protección incorporados.

·         Pruebas carga: Realizadas cargas de datos que se asemejan a la realidad para testeos reales.

·         Pruebas de Volumen: Encontrar debilidades en el sistema al momento de manejar grandes volúmenes de datos durante prolongados períodos de tiempo, el objetivo principal es determinar si la plataforma de integración se degrada o deja de funcionar al manejar grandes volúmenes de datos.

Se deben hacer revisiones precisas de la forma en que se despliegan las páginas del sitio y ver si cumplen con los Términos de Referencia en estos temas y, además, si cumplen con los estándares mínimos definidos y la normativa vigente.

Las acciones de prueba sugeridas para realizar en esta etapa son las siguientes:

Verificación de Contenidos:

    es una prueba básica para revisar si el Sitio Web desarrollado incluye todos los contenidos que se han especificado en los Términos de Referencia o los que se hayan definido en el marco del plan de desarrollo. Se puede hacer en forma manual o automática, de acuerdo a las siguientes orientaciones:

Sistema Manual:

        se refiere a hacer una revisión manual de los contenidos del Sitio Web a través de la navegación de sus páginas. Para ello se recomienda primero construir un índice de contenidos y luego verificar la existencia de cada uno de los ítems que contiene, a través de hacer un recorrido exhaustivo del sitio. Los elementos que deben probarse obligatoriamente son:

·         Verificación de ortografía y redacción

·         Verificación de enlaces principales

·         Verificación de imágenes en páginas

·         Verificación de existencia de archivos adjuntos

·         Verificación de Lista de Chequeo de Accesibilidad

Sistema Automático:

        especialmente orientado a la verificación y detección de enlaces rotos, lo cual se puede hacer utilizando sistemas basados en Internet o, bien, software especializado.

Sistemas Basados en Internet:

        se recomienda usar el servicio de validación de enlaces del W3C Check Link

Software:

        se recomienda bajar y usar desde su computador el software gratuito para verificación de enlaces: Xenu. De igual manera, los actuales softwares de creación de sitios Web permiten manejar en forma controlada los enlaces internos; un error común de este tipo es que una foto se vea normalmente en el computador de desarrollo, pero no en el Sitio Web, Esto ocurre porque es referida en forma absoluta desde una ubicación en un disco duro local o en red, en lugar de un directorio de imágenes del Sitio Web.

                Se recomienda hacer estas pruebas en ambientes controlados diferentes a los usados para el desarrollo (diferentes redes y computadores), para que los resultados sean confiables.

Verificación de Meta Tags:

    los meta tags son marcas en lenguaje HTML que van en la parte superior de cada página, a través de las cuales se entrega a los sistemas de indexación y búsqueda (como Google, Bing y Yahoo! otros), la información mínima que se debe tener en cuenta para hacer una correcta indexación del contenido que incluye. Los meta tags son elementos que obedecen a un estándar definido por el World Wide Web Consortium (http://www.w3c.org) por lo que su uso está regulado. Para verificar que dichas marcas cumplen con los elementos mínimos requeridos por los buscadores, existen herramientas en Internet que permiten hacer tal prueba y ofrecen recomendaciones para mejorar la información ingresada en dicha área.

Verificación de Estándares:

    aunque los Sitios Web pueden ser construidos a partir de diferentes lenguajes, todos deben cumplir ciertas normas de organización de su código fuente (sintaxis), que permitan su visualización por software equivalente en diferentes plataformas. Dicha sintaxis está estandarizada y puede ser probada a través de herramientas públicas que están disponibles en Internet. Las más importantes son:

Validación de HTML:

    la realiza el World Wide Web Consortium  a través de un validador en linea de codigo HTML, permite validar URL y documentos específicos vía upload, esta herramienta indica si el código usado en la página es correcto. Como resultado entrega un reporte con los eventuales errores para ayudar a su reparación.

Validación de CSS:

    La realiza el World Wide Web Consortium  a través de un validador en línea de hojas de estilo (CSS), permite validar CSS vía URL y upload, esta herramienta indica si el archivo CSS cumple con la sintaxis estándar y por lo tanto podrá ser visualizada correctamente en todos los sistemas.

Validación Mobile Checker (preparación para dispositivos móviles):

    La realiza el World Wide Web Consortium  a través de una herramienta de verificación que permite establecer el estado de preparación del sitio para ser visualizado en dispositivos móviles, Mobile Checker, su objetivo es ayudar a los desarrolladores a identificar errores y deficiencias en sus sitios web que debe ser corregidas para resolver los problemas de interoperabilidad y usabilidad que dificultan el acceso a la Web desde dispositivos móviles.

Verificaciones de Interfaces:

    mediante esta prueba se revisan aspectos gráficos del Sitio Web, para determinar si su despliegue en las páginas es correcto. Dentro de los elementos más importantes a ser verificados, se incluyen los siguientes:

Plug-ins necesarios:

        cuando se utilicen elementos audiovisuales o interactivos que requieran de algún software incrustado para funcionar (plug-ins), se debe ofrecer un enlace para que los usuarios que no lo tengan instalado, puedan bajarlo y hacer el proceso de instalación. En el caso del uso de la tecnología Flash, las últimas actualizaciones del producto permiten que el software pueda ser bajado en forma automática por los programas visualizadores, si se cuenta con la codificación adecuada. Por lo anterior, es necesario hacer la prueba desde un computador que carezca de dicho software, para comprobar que efectivamente hace dicha operación.

Consistencia de la Diagramación:

        cada una de las páginas del sitio debe tener elementos consistentes, con el fin de ofrecer al usuario una experiencia similar en cualquier área del Sitio Web; por nombrar sólo tres aspectos, lo anterior implica que los menús deben aparecer siempre en el mismo lugar; que los listados deben estar diseñados de similar manera en todo el sitio y que los colores y formas de uso de las interfaces deben ser similares a lo largo de las páginas.

Ancho de la Diagramación:

        si la diagramación del sitio se ha realizado para un ancho determinado (por ejemplo, 800 pixeles de ancho), en esta etapa se debe probar si ello se cumple. Asimismo, se debe probar en una pantalla configurada con una menor dimensión (por ejemplo 640 x 480 pixeles), cuál es el área visible del sitio y cómo afecta eso a la navegación por el mismo. Otra prueba del mismo estilo, se refiere a usar un programa visualizador orientado sólo a texto como Lynx, para obtener visiones alternativas de la manera en que los usuarios están accediendo a la información que se les ofrece.

Diagramación vs. Navegadores (Browsers):

       aunque la codificación en los lenguajes soportados por los programas visualizadores (browsers) puede apegarse a los estándares, no todos muestran de la misma manera los Sitios Web. Dado esto, es necesario revisar el sitio en diferentes tipos de programas, especialmente contemplando los mas usados. Las pruebas deberían hacerse al menos en Google Chrome, Microsoft Internet Explorer, Opera y Mozilla Firefox, ya que con ellos se cubrirá un amplio espectro. Lo que se debe revisar en este caso es el despliegue de todos los elementos que se muestran en la pantalla, para asegurar de que aparecen en las posiciones que se les han asignado en el diseño.

Diagramación vs. Sistema Operativo:

        tal como se explicó en el caso anterior, los diferentes sistemas operativos pueden establecer diferencias en la forma en que se muestran los Sitios Web. Por ello, es importante conocer cuáles son los sistemas operativos utilizados por la audiencia a la que se desea llegar y revisar el despliegue del sitio en ellos. Hay que recordar que, además de Microsoft Windows, los usuarios pueden estar visualizando el sitio desde computadores equipados con Apple Macintosh o diferentes versiones del sistema operativos Unix.

Imágenes Sin Atributo ALT:

        para cumplir con las normas de accesibilidad es necesario que todas las imágenes que se usen en un Sitio Web, tengan una descripción utilizando el atributo ALT (para texto alterno) del lenguaje HTML. Para comprobarlo, basta situar el mouse sobre una imagen, para que se despliegue una leyenda en texto en una etiqueta amarilla que flota sobre la foto; si eso no ocurre, el atributo no está siendo usado y debe ser corregido e incluido.

Conclusiones

·         Las pruebas de software son mecanismos necesarios para el desarrollo y entrega de un proyecto de software

·         Existe una gran cantidad de pruebas de software el uso de una u otra dependerá de la aplicación a revisar y del entorno de esta.

·         Las pruebas para aplicaciones web son levemente diferentes que las del resto de productos software, ya que se implementan en ambientes más diversos, por lo que se deben incluir pruebas en los entornos mas variados.

Agradecimientos

                A nuestros catedráticos de la universidad nacional autónoma de Honduras.

Referencias

chile.gob. (s.f.). http://www.guiadigital.gob.cl. Obtenido de http://www.guiadigital.gob.cl/articulo/pruebas-de-interfaces-y-contenidos: http://www.guiadigital.gob.cl/articulo/pruebas-de-interfaces-y-contenidos

Cobb, M. (marzo de 2014). http://searchdatacenter.techtarget.com. Obtenido de http://searchdatacenter.techtarget.com/es/respuesta/Pruebas-de-seguridad-para-aplicaciones-web-Prueba-de-penetracion-o-revision-de-codigo

Fiestas, J. (03 de 09 de 2014). http://blog.elevenpaths.com. Obtenido de http://blog.elevenpaths.com: http://blog.elevenpaths.com/2014/09/qa-pruebas-para-asegurar-la-calidad-del.html

Medina, E. (19 de 04 de 2003). https://senastage.blackboard.com. Obtenido de https://senastage.blackboard.com: https://senastage.blackboard.com/bbcswebdav/courses/150752/Pruebas%20del%20Software_T%C3%A9cnicas.pdf