APLICACIÓN DE PRUEBAS DEL SISTEMA.

Las pruebas de sistema buscan discrepancias entre el programa y sus objetivos o requerimientos, enfocándose en los errores hechos durante la transición del proceso al diseñar la especificación funcional. Esto hace a las pruebas de sistema un proceso vital de pruebas, ya que en términos del producto, número de errores hechos, y severidad de esos errores, es un paso en el ciclo de desarrollo generalmente propenso a la mayoría de los errores. 

Las pruebas de sistema no son procesos para probar las funciones del sistema o del programa completo, porque ésta sería redundante con el proceso de las pruebas funcionales. Las pruebas del sistema tienen un propósito particular: para comparar el sistema o el programa con sus objetivos originales (Requerimientos funcionales y no funcionales). Dado este propósito, se presentan dos implicaciones 

1. Las pruebas de sistema no se limitan a los sistemas. Si el producto es un programa, la prueba del sistema es el proceso de procurar demostrar cómo el programa, en su totalidad, no resuelve sus objetivos o requerimientos.
2. Las pruebas de sistema, por definición, son imposibles si no están los requerimientos por escrito, mensurables para el producto.

Las pruebas de sistema tienen como objetivo ejercitar profundamente el sistema comprobando la integración del sistema de información globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica.

Son pruebas de integración del sistema de información completo, y permiten probar el sistema en su conjunto y con otros sistemas con los que se relaciona para verificar que las especificaciones funcionales y técnicas se cumplen. Dan una visión muy similar a su comportamiento en el entorno de producción.

CONTEXTO DE LA APLICACIÓN DE PRUEBAS.

Para aplicar estas técnicas siempre en necesario modelar cierto tipo de pruebas (tests) específicas, las pruebas son actividades en las cuales un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluación de algún aspecto.

CONTROL DE CALIDAD DE SOFTWARE.

Control de calidad implica vigilar el proceso de desarrollo de software para asegurar que se siguen los procedimientos y los estándares de garantía de calidad, en el proceso de control de calidad se comprueba que las entregas cumplan con los estándares definidos. Consiste en revisar que al final el producto cumpla los requerimientos del cliente.

El control de calidad del software abarca todo el proceso de desarrollo: supervisar y mejorar el proceso, asegurar que se siguen los procedimientos acordados, que se alcanza el nivel de calidad deseado y que se localizan y resuelven los problemas.

Al aplicar control de calidad en el desarrollo de un proyecto de software se solucionan problemas:

• En la empresa y usuario en particular.
• En la calidad en general.
• En la administración del proyecto del software.
• En cada una de las fases del ciclo de vida del sistema.

CORRECCIÓN 

Es la capacidad de los productos software para realizar con exactitud las tareas expresadas en su especificación. 

EFICACIA.

La eficacia del software está dada por el grado en que se cumplieron los objetivos previstos en su diseño. Usualmente se recurre a una forma de planificación como el marco lógico, en la cual se establece la jerarquía de objetivos: general, inmediatos, específicos, metas y actividades

VERIFICACIÓN.

La verificación se enfoca más al proceso de evaluación del sistema o de los componentes, permite determinar si los productos de una determinada fase del desarrollo satisfacen las condiciones impuestas en el inicio de la misma. Responde la pregunta ¿Estamos construyendo el producto correctamente?, entonces el software debería ajustarse a sus especificaciones iniciales.

VALIDACIÓN.

La validación también es una evaluación del sistema o componentes, pero solo se efectúa en el transcurso o al final del proceso del desarrollo para determinar si cumple con lo especificado. Responde la pregunta ¿Estamos construyendo el producto correcto?, entonces el software debería hacer lo que el cliente realmente quiere que haga.

TIPOS DE PRUEBAS.

Varias pruebas juntas con un fin especifico constituyen un caso de pruebas donde un conjunto de entradas, condiciones de ejecución y resultados esperados son desarrollados para un objetivo particular.


Las pruebas deben centrarse en dos objetivos:

Probar si el software no hace lo que debe hacer.
Probar si el software hace lo que no debe hacer, es decir, si provoca efectos secundarios.


Se clasifican en 2 grandes grupos:

Inspecciones de Software: analizan y comprueban las representaciones del sistema (los diagramas de diseño, el código fuente del programa). Se aplica a todas las etapas del proceso de desarrollo y se complementan con algún tipo de análisis automático del texto fuente y documentos asociados. Son técnicas de verificación y validación estáticas, no requieren que el sistema se ejecute.

Pruebas de Software: consisten en comparar datos teóricos con los resultados del software utilizando series de datos de prueba, se examinan los resultados del software y su comportamiento operacional para comprobar que se desempeñe conforme a lo requerido. Es una técnica dinámica de la verificación y validación ya que requiere disponer de un prototipo ejecutable del sistema.


Lo que buscamos descubrir con ambos tipos de pruebas son:

Defectos (bug): un defecto en el software como, por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa.

Fallos (failure): La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados.

ATENDIENDO A LA FORMA DE REALIZACIÓN.

Prueba unitaria:

Es una forma de probar el correcto funcionamiento de un módulo de código.

Prueba funcional

Es una prueba basada en la ejecución, revisión y retro alimentación de las funcionalidades previamente diseñadas para el software.

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.

Pruebas de validación
Son el proceso de revisión que el sistema de software producido cumple con las especificaciones y que cumple su cometido.

Cajas blancas

Es un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo.

Caja negra

Ejercitan los requisitos funcionales desde el exterior del módulo.

Prueba de Arquitectura y Aplicaciones
La arquitectura cliente/servidor representa un importante desafío para quienes prueban el software.

Pruebas de funcionalidad de la aplicación:

La aplicación se prueba de manera independiente.

Pruebas de servidor:

Se prueban funciones de coordinación y manejo de datos del servidor. También se considera el desempeño del servidor (tiempo de respuesta y procesamiento de los datos).

Pruebas de base de datos:

Se prueba la exactitud e integridad de los datos almacenados en el servidor.

Pruebas de transacción:

Se crea una serie de pruebas para asegurar que cada clase de transacciones se procesa de acuerdo con sus requisitos.

Pruebas de comunicaciones de red:
Con estas pruebas se verifica que la comunicación entre los nodos de la red ocurre de manera correcta y que el paso de mensajes, transacciones y el tráfico de la red relacionado se realiza sin errores.

ATENDIENDO AL MOMENTO DE REALIZACIÓN.

Prueba del sistema:

Verifica que cada elemento encaja de forma adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total.

Prueba de seguridad:

Verificar los mecanismos de protección.

Prueba de resistencia:

Enfrenta a los programas a situaciones anormales.

Prueba de rendimiento:

Prueba el rendimiento del software en tiempo de ejecución.

Prueba de instalación:

Se centra en asegurar que el sistema software desarrollado se puede instalar en diferentes configuraciones hardware y software y bajo condiciones excepciones.

Pruebas de regresión:

Las pruebas de regresión son una estrategia de prueba en la cual las pruebas que se han ejecutado anteriormente se vuelven a realizar en la nueva versión modificada, para asegurar la calidad después de añadir la nueva funcionalidad.

              

IMPLANTACIÓN DEL SISTEMA O PUESTA A PUNTO.

DETERMINACION DEL PERIODO DE TRANSICION O EJECUCION EN PARALELO

Durante este período de ejecución inmediato en el entrenamiento se reducen a Crear las condiciones más favorables para conseguir la forma competitiva óptima. Si el período de competición es prolongado, que incluye no una, sino varias Competiciones, surge además la dificultad de asegurar la conservación de esta Forma competitiva óptima. En el supuesto que se celebre más de una competición en este período, algunos de los aspectos de la preparación físico-técnica y técnico-táctica pueden sufrir considerables modificaciones debido a la necesidad de adaptarse a las condiciones específicas de cada competición. No son aconsejables las re estructuraciones de la planificación en este período por cuanto provocarían la pérdida de la forma competitiva.

DETERMINACIÓN DE NECESIDADES DE RECURSOS ADICIONALES

En este se muestran todo lo que debe contener el sistema dependiendo de las necesidades del usuario dando un servicio correcto.

EQUIPOS:

ES muy necesario un equipo ya que con este vamos a trabajar y donde se va desarrollar el sistema.
Estos a su vez automatizan los procesos operativos, suministran una plataforma de información necesaria para la toma de decisiones y, lo más importante, su implantación logra ventajas competitivas o reducir la ventaja de los rivales.
Interactúan entre sí con el fin de apoyar las actividades de una empresa o negocio.

CONSUMIBLES:

Estos se describen como los clientes que son los que compran y usan el sistema.
También hace referencia al esfuerzo colaborativo para construir economías basadas en productos de la localidad, empresa y país.

INSTALACIONES:

En si las instalaciones son el conjunto de redes y equipos fijos que permiten el suministro y operación de los servicios que ayudan a los sistemas a cumplir las funciones para las que han sido diseñados

PRUEBA DE CARGA O REPETICIÓN DE PRUEBAS DEL SISTEMA CON DATOS REALES:

La prueba de sistemas no aprueba el software en sí, sino la integración de cada módulo en el sistema. También busca las discrepancias entre el sistema y su objetivo original, especificación de y documentación del sistema. La preocupación principal es la compatibilidad de los módulos individuales.

PRUEBA DE ACEPTACIÓN O VISTO BUENO DEL CLIENTE .

Estas pruebas las realiza el cliente. Son básicamente pruebas funcionales, sobre el sistema completo, y buscan una cobertura de la especificación de requisitos y del manual del usuario. Estas pruebas no se realizan durante el desarrollo, pues sería impresentable al cliente; sino que se realizan sobre el producto terminado e integrado o pudiera ser una versión del producto o una interacción funcionad pactada previamente con el cliente. Una prueba de aceptación puede ir desde un informal caso de prueba hasta la ejecución sistemática de una serie de pruebas bien planificadas. De hecho, las pruebas de aceptación pueden tener lugar a lo largo de semanas o meses, descubriendo así errores latentes o escondidos que pueden ir degradando el funcionamiento del sistema. Estas pruebas son muy importantes, ya que definen el paso nuevas fases del proyecto como el despliegue y mantenimiento.