TESTER

PRUEBAS DE SOFTWARE "TESTING"

También conocidas como (Testing).- son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementación, calidad, o usabilidad de un programa de ordenador o videojuego. Básicamente es una fase en el desarrollo de software consistente en probar las aplicaciones construidas.

Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema.

TIPOS DE PRUEBAS

PRUEBAS DE VALIDACIÓN

Las pruebas de validación en la ingeniería de software son el proceso de revisión que el sistema de software producido cumple con las especificaciones y que cumple su cometido. Es normalmente una parte del proceso de pruebas de software de un proyecto, que también utiliza técnicas tales como evaluaciones, inspecciones, y tutoriales. La validación es el proceso de comprobar lo que se ha especificado es lo que el usuario realmente quería.

Las pruebas de validación empiezan tras la culminación de las pruebas de integración, cuándo se han ejercitado los componentes individuales. Se han terminado de ensamblar el software como paquete y se ha descubierto y corregido los errores de interfaz.

Tipos de pruebas de  validación

·   Pruebas de aceptación: desarrolladas por el cliente.

·  Pruebas alfa realizadas por el usuario con el desarrollador como observador en un entorno controlado (simulación de un entorno de producción).

· Pruebas beta: realizadas por el usuario en su entorno de trabajo y sin

   observadores.

Características de las pruebas de validación.

·        Se usan la mismas técnicas, pero con otro objetivo.

·        No hay programas de prueba, sino sólo el código final de la aplicación.

·        Se prueba el programa completo.

·        Uno o varios casos de prueba por cada requisito o caso de uso especificado.

·        Se prueba también rendimiento, capacidad, etc.

·        Pruebas alfa (desarrolladores) y beta (usuarios).

PRUEBAS DE INTEGRACIÓN

Pruebas integrales o pruebas de integración son aquellas que se realizan en el ámbito del desarrollo de software una vez que se han aprobado las pruebas unitarias. Únicamente se refieren a la prueba o pruebas de todos los elementos unitarios que componen un proceso, hecha en conjunto, de una sola vez.

Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos.

Las pruebas de integración (algunas veces llamadas integración y testeo I&t) es la fase del testeo de software en la cual módulos individuales de software son combinados y testeados como un grupo. Son las pruebas posteriores a las pruebas unitarias y preceden el testeo de sistema.

PRUEBAS FUNCIONALES

Una prueba funcional es una prueba basada en la ejecución, revisión y retroalimentación de las funcionalidades previamente diseñadas para el software. Las pruebas funcionales se hacen mediante el diseño de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el paquete informático.

Las pruebas funcionales están desarrolladas bajo la perspectiva del usuario, confirmando que el sistema hace lo que los usuarios esperan que haga. Un error funcional en su aplicación puede tener consecuencias catastróficas, desde la pérdida de credibilidad de sus clientes, hasta grandes pérdidas económicas.

Los consultores de pruebas funcionales de Testhouse tienen amplia experiencia en multitud de mercados a nivel global, adaptándose a todo tipo de metodologías de desarrollo y habiendo realizado pruebas funcionales en aplicaciones críticas de empresas líderes en el sector de finanzas, telecomunicaciones y media, entre otros.

PRUEBAS DE RECORRIDO

Incluye indagación y observación del flujo de transacciones dentro de procesos representativos desde el punto en que las transacciones son iniciadas hasta el punto en el que son reportadas en el mayor general. Recorremos los controles que hemos identificado para determinar que han sido diseñados e implantados eficazmente. El recorrido incluye el examen de los flujos de la documentación e información desde una perspectiva tanto manual como automatizada. Su objetivo es confirmar nuestra comprensión del flujo de las transacciones representativas, la exactitud de la información que hemos obtenido acerca de los controles preventivos y/o de detección relevantes sobre el flujo de transacciones, si los controles han sido diseñados eficazmente para prevenir o detectar y corregir aseveraciones equívocas materiales en forma oportuna, si lo los controles han sido implantados y la idoneidad de nuestra documentación.

PRUEBA UNITARIA

En programación, una prueba unitaria es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Luego, con las pruebas de integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión.

La idea es escribir casos de prueba para cada función no trivial o método en el módulo de forma que cada caso sea independiente del resto.

Característica de la prueba unitaria.

·Automatizable: no debería requerirse una intervención manual. Esto es especialmente útil para integración continúa

·   Completas: deben cubrir la mayor cantidad de código.

· Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil para integración continua.

·  Independientes: la ejecución de una prueba no debe afectar a la ejecución de

   otra.

·  Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc.

· Aunque estos requisitos no tienen que ser cumplidos al pie de la letra, se recomienda seguirlos o de lo contrario las pruebas pierden parte de su función.

PRUEBAS DE CAJA BLANCA.

Son realizadas directamente en el código y normalmente son hechos por el programador del software, un ejemplo de este tipo de prueba es la prueba de unidad (unit testing). Sin embargo, las pruebas de caja negra son hechos de manera funcional, donde el probador no tiene contacto directo con el código del programa, así lo programa es tenido como una caja negra donde al pasar valores de entrada para esta caja y ella retorna valores de salida. Muchas veces estos tipos de pruebas son hechos por un equipo específico de probadores, los cuales utilizan la especificación de requisitos del cliente para crear un plan de casos de prueba.

PRUEBAS DE REGRESIÓN

Se denominan Pruebas de regresión a cualquier tipo de pruebas de software que intentan descubrir las causas de nuevos errores (Bugs), carencias de funcionalidad, o divergencias funcionales con respecto al comportamiento esperado del software, inducidos por cambios recientemente realizados en partes de la aplicación que anteriormente al citado cambio no eran propensas a este tipo de error. Esto implica que el error tratado se reproduce como consecuencia inesperada del citado cambio en el programa.

Este tipo de cambio puede ser debido a prácticas no adecuadas de control de versiones, falta de consideración acerca del ámbito o contexto de producción final y extensibilidad del error que fue corregido (fragilidad de la corrección), o simplemente una consecuencia del rediseño de la aplicación.

Por lo tanto, en la mayoría de las situaciones del desarrollo de software se considera una buena práctica que cuando se localiza y corrige un bug, se grabe una prueba que exponga el bug y se vuelvan a probar regularmente después de los cambios subsiguientes que experimente el programa.

Existen herramientas de software que permiten detectar este tipo de errores de manera parcial o totalmente automatizada, la práctica habitual en programación extrema es que este tipo de pruebas se ejecuten en cada uno de los pasos del ciclo de vida del desarrollo del software.

Tipos de regresión

Clasificación de ámbito

·        Local - los cambios introducen nuevos errores.

·        Desenmascarada - los cambios revelan errores previos.

·   Remota - Los cambios vinculan algunas partes del programa (módulo) e introducen errores en ella.

Clasificación temporal

· Nueva característica - los cambios realizados con respecto a nuevas funcionalidades en la versión introducen errores en otras novedades en la misma versión del software.

·  Característica preexistente - los cambios realizados con respecto a nuevas funcionalidades introducen errores en funcionalidad existente de previas versiones.

PRUEBAS DE PRESTACIONES

A veces es importante el tiempo de respuesta, u otros parámetros de gasto. Típicamente nos puede preocupar cuánto tiempo le lleva al sistema procesar tantos datos, o cuánta memoria consume, o cuánto espacio en disco utiliza, o cuántos datos transfiere por un canal de comunicaciones, o Para todos estos parámetros suele ser importante conocer cómo evolucionan al variar la dimensión del problema (por ejemplo, al duplicarse el volumen de datos de entrada).

PRUEBAS DE SISTEMA

Al final del desarrollo del software se incorpora otros elementos (hardware, personas, información) y se realiza una serie de pruebas de integración del sistema y de validación.

Estas pruebas están más allá del proceso del software y no las realizan únicamente los ingenieros del software. Sin embargo los pasos dados durante el diseño y la prueba mejoraran en gran medida la probabilidad de tener éxito y la integración del software del sistema mayor.

El software ya validado se integra con el resto del sistema donde algunos

Tipos de pruebas a considerar son:

Rendimiento: determinan los tiempos de respuesta, el espacio que ocupa el módulo en disco o en memoria, el flujo de datos que genera a través de un canal de comunicaciones, etc.

Resistencia: determinan hasta donde puede soportar el programa determinadas condiciones extremas.

Robustez: determinan la capacidad del programa para soportar entradas incorrectas.

Seguridad: se determinan los niveles de permiso de usuarios, las operaciones de acceso al sistema y acceso a datos la prueba comprueba que los mecanismos de protección integrados en el sistema realmente lo protejan de irrupciones inapropiadas

Usabilidad: se determina la calidad de la experiencia de un usuario en la forma en la que éste interactúa con el sistema, se considera la facilidad de uso y el grado de satisfacción del usuario.

Instalación: se determinan las operaciones de arranque y actualización del software.

Desempeño: está diseñada para probar el desempeño del software en tiempo de ejecución en tiempo de contexto de un sistema integrado. La prueba de desempeño se aplica en todos los pasos del proceso de la prueba, incluso a nivel de la unidad, el desempeño de un módulo individual debe evaluarse mientras se realizan las pruebas.

PRUEBAS DE CAJA NEGRA.

En teoría de sistemas y física, se denomina caja negra a aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesará su forma de interactuar con el medio que le rodea (en ocasiones, otros elementos que también podrían ser cajas negras) entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento.

PRUEBAS DE ACEPTACIÓN

Cuando se construye software a la medida para un cliente, se llevan a cabo una serie de pruebas de aceptación para permitir que el cliente valide y verifique todos los requisitos. Estas pruebas las realiza el usuario final en lugar del responsable del desarrollo del sistema.