fundamentos del proceso de pruebas.

 pruebas de software.

   Es una actividad realizada para probar la calidad del producto y mejorarla. consiste en llevar a cabo la verificación dinámica de un componente, programa o sistemas, mediante el uso de herramientas. 

 conceptos del proceso de prueba.

 Defecto.

Un defecto de software, es el resultado de un fallo o deficiencia durante el proceso de creación de programas de ordenador o computadora u otro dispositivo. Por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa.

Error.

Es una equivocación cometida por un desarrollado. Algunos ejemplos de errores son: un error de tipeo, una mal interpretación de un requerimiento o de la funcionalidad de un método, una acción humana que conduce a un resultado incorrecto. Por ejemplo: Divisiones entre cero. Es una tipo de manifestación del defecto en el sistema que se ejecuta.

Falla.

Puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los más evidentes se dan en la etapa de desarrollo y programación. Es la incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados.

dato de prueba.

elementos admitidos en Derecho, que pueden tomarse en consideración para probar y fundamentar, así como para negar la existencia o determinar la falsedad.

validación. 

garantiza la corrección y precisión de todos los valores de datos de la aplicación y puede diseñarse utilizando distintos enfoques: código de interfaz de usuario código de aplicación o restricciones de bases de datos.

Verificación.

La verificación del software es el proceso a través del cual se analiza y revisa que el software satisfaga los objetivos propuestos al inicio del desarrollo.
Validación:
El proceso de evaluación de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos marcados por el usuario.

Principios de proceso de pruebas.

• La prueba puede ser usada para mostrar la presencia de errores, pero nunca su ausencia.
• La principal dificultad del proceso de prueba es decidir cuándo parar.
• Evitar casos de pruebas no planificados, no reusables y triviales a menos que el programa sea verdaderamente sencillo.
• Una parte necesaria de un caso de pruebas es la definición del resultado esperado.
• Los casos de pruebas tienen que ser escritos no solo para condiciones de entrada válidas y esperadas sino también para condiciones no válidas e inesperadas.
• El número de errores sin descubrir es directamente proporcional al número de errores descubiertos.

Las pruebas y el proceso de desarrollo de software

• . Seleccionar qué es lo que debe medir la prueba, es decir, cuál es su objetivo, para qué exactamente se hace la prueba.

• Decidir cómo se va a realizar la prueba, es decir, qué clase de prueba se va a utilizar para medir la calidad y qué clase de elementos de prueba se deben usar.

• Desarrollar los casos de prueba. Un caso de prueba es un conjunto de datos o situaciones de prueba que se utilizarán para ejecutar la unidad que se prueba o para revelar algo sobre el atributo de calidad que se está midiendo.

• Determinar cuáles deberían ser los resultados esperados de los casos de prueba y crear el documento que los contenga.

• Ejecutar los casos de prueba.

Participantes en el proceso de pruebas: actores y roles.

El Analista

El analista es alguien que es responsable de entender las necesidades del cliente, y asegurarse de que la solución que está siendo desarrollada se ajusta a esas necesidades.

El Arquitecto de Software

El papel del arquitecto de software es traducir los requisitos, tal como se define por el analista, en una solución técnica. Él puede crear un diseño técnico, o simplemente algunos bocetos a mano alzada, de cómo el sistema va a estar estructurado. En cualquier caso, es la responsabilidad del arquitecto a pensar en el sistema antes de que se desarrolle. Si se hace bien, durante la fase de diseño que se abordarán correctamente todos los problemas que se enfrenten en el desarrollo de la solución.

arquitecto de sistemas

un arquitecto del sistema es responsable del hardware. Muchas aplicaciones ejecutan completamente en un único servidor. Muchos otros sin embargo se ejecutan en grupos de servidores, con servidores dedicados de bases de datos, servidores web y balanceadores de carga. Un arquitecto del sistema tiene en cuenta los requisitos de rendimiento y disponibilidad, el número de usuarios / visitantes, etc. 

El Desarrollador de Software

Un programador es aquella persona que escribe, depura y mantiene el código fuente de un programa informático, es decir, el conjunto de instrucciones que ejecuta el hardware de una computadora, para realizar una tarea determinada.

El Diseñador Gráfico

es una profesión cuya actividad consiste en proyectar comunicaciones visuales destinadas a transmitir mensajes específicos a grupos sociales, con objetivos determinados.

El Administrador de Código

Si varios de los desarrolladores están trabajando en conjunto, el código que escriben debe integrarse en algún momento, independientemente del sistema de control de versiones utilizado.

Además, cuando haya terminado, el proyecto debe ser implementado. La implementación del proyecto significa tomar el código y despegarlo en el servidor. Aunque usualmente no hay una persona manejando esto, es importante identificar dicho rol.

El Administrador de Código

El Código es importante y debe ser tratado como tal, el código necesita ser gestionado. Si varios de los desarrolladores están trabajando en conjunto, el código que escriben debe integrarse en algún momento, independientemente del sistema de control de versiones utilizado.

Además, cuando haya terminado, el proyecto debe ser implementado. La implementación del proyecto significa tomar el código y desplegar lo en el servidor. Aunque usualmente no hay una persona manejando esto, es importante identificar dicho rol.

El Capacitador

Cuando un proyecto se haya completado, los usuarios pueden necesitar ser capacitados, en particular si en el proyecto se desarrollado una aplicación.

No es común capacitar a los usuarios de un sitio web, pero a menudo hay un back-end que los administradores tendrán que ser aprender a usar.

El Capacitador relaciona las soluciones que se han creado con el usuario final.

Descripción de las fases:

• Especificación de Requisitos.

• Descripción: En esta fase se identificarán las necesidades de negocio de clientes y usuarios del sistema y se realizará la definición de las características que deberá cumplir el producto software a desarrollar. Para ello, durante esta fase será fundamental interactuar con los usuarios finales y así concretar los requisitos del sistema. El catálogo completo de requisitos del sistema a desarrollar se especificará en el documento de Especificación de Requisitos. En él se incluirán tanto los requisitos generales del sistema, como requisitos específicos (funcionales, no funcionales, de integración, y restricciones técnicas).
  A partir de los requisitos generales definidos en el documento de Especificación de Requisitos se elaborará el Plan de Pruebas de Aceptación, el cuál servirá de guía a los usuarios finales en la realización de las pruebas que verifiquen los requisitos funcionales solicitados, en cuyo caso se aceptará el sistema. Conviene resaltar que el Equipo de Testing generará el Plan de Pruebas de Aceptación como parte de la ejecución del servicio Testing Temprano - Requisitos.
• Entregables:
  • Especificación de Requisitos de Sistema
  • Plan de Pruebas de Aceptación
• Análisis.
  • Descripción: En esta fase se se realizará en primer lugar, la definición del modelo de la estructura interna del sistema software y de sus relaciones con otros sistemas, y por otro, la elaboración del modelo de clases y descripción de los diagramas de secuencia y diagramas de flujo de trabajo mediante el modelo de casos de uso. Esta información se recogerá en el documento de Análisis del Sistema.
    Además, en esta fase deberá comenzarse la elaboración del Plan de Pruebas Funcionales a partir de la documentación ya generada (Especificación de Requisitos y Análisis del Sistema). El Plan de Pruebas Funcionales tienen como guía los requerimientos establecidos por el cliente, y se busca analizar si los satisfacen, tanto en los requerimientos positivos (qué se deseaba que hiciera) como las limitaciones (qué se deseaba que no hiciera). El Plan de Pruebas Funcionales deberá contener, al menos, la siguiente información:
    • Definición de los casos de pruebas: identificador único, descripción, prerequisitos, pasos a seguir para la ejecución del caso de prueba y el resultado esperado.
    • Matriz de trazabilidad de casos de pruebas y requisitos funcionales, con el objetivo de verificar que se han definido los casos de pruebas necesarios para ofrecer cobertura a todos los requisitos funcionales y de integración definidos.
    • Definición de la estrategia a seguir para la ejecución del Plan de Pruebas Funcionales definido.
  • Para más información a cerca de como elaborar el Plan de Pruebas Funcionales se recomienda consultar la pauta diseño y ejecución de pruebas funcionales. 
  • Entregables:
    • Análisis del Sistema
    • plan de migracion  y carga inicial (si aplica)
    • Plan de Pruebas Funcionales

• Diseño.
  • Descripción: En esta fase se detallan los principios técnicos del sistema a partir de los modelos funcionales diseñados en la fase anterior. Se realiza el diseño de los componentes software del sistema especificando las necesidades de infraestructura tecnológica, arquitectura software y estándares de desarrollo según  madeja.
    En esta fase de elabora el documento de Diseño del Sistema y los siguientes planes de pruebas:
    • Plan de Pruebas Unitarias. El Plan de Pruebas Unitarias debe recoger el conjunto de pruebas que el Equipo de Proyecto deberá realizar para comprobar el correcto funcionamiento de cada componente de código por separado. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. El Plan de Pruebas Unitarias deberá recoger tantas pruebas como componentes se vayan a probar, especificando para cada uno de ellos los datos de entrada y la salida esperada. Se trata de un documento interno de trabajo que el Equipo de Proyecto deberá elaborar para posteriormente llevar a cabo la implementación en la herramienta correspondiente (por ejemplo, JUnit).
    • Plan de Pruebas de Integración. El Plan de Pruebas de Integración debe recoger el conjunto de pruebas que el Equipo de Proyecto deberá realizar para verificar la correcta integración entre todos los componentes/módulos del sistema. Se deberán definir los casos de pruebas que comprueben la integración entre los módulos del sistema, especificando la relación de los componentes a probar, así como lo datos de entrada y la salida esperada. Se trata de un documento interno de trabajo que el Equipo de Proyecto deberá elaborar para posteriormente llevar a cabo la implementación de las pruebas en la herramienta correspondiente (por ejemplo, JUnit).
      Para más información, se recomienda consultar la pauta Diseño y ejecución de pruebas de componentes de código
    • Plan de Pruebas Funcionales (actualización). Se realizará la actualización del Plan de Pruebas Funcionales a partir de la información generada en la fase de Diseño.
  • Entregables:
    • Diseño del Sistema
    • Plan de Pruebas Unitarias
    • Plan de Pruebas de Integración
    • Plan de Pruebas Funcionales
    • Prototipos
• Construcción.
  • Descripción: Es la fase central del método. madeja aporta recomendaciones específicas desde el punto de vista metodológico para el desarrollo del software. En concreto, el Subsistema Desarrollo de efectúa sugerencias en lo que respecta a aspectos clave como son la gestión de la configuración, guías de estilo de codificación, etc. Además de la construcción de todos los componentes software, se deberá elaborar la documentación necesaria para asegurar la correcta instalación, explotación, instalación y uso del sistema.
  • Entregables:
    • Manual de Usuario
    • Manual de Instalación
    • Manual de Actualización
    • Manual de Administración
    • Manual de Integración
    • Manual de Explotación
    • Soporte
• Pruebas.
  • Descripción:Esta fase se llevará a cabo la ejecución de los distintos planes de pruebas definidos en fases anteriores. Será necesario conseguir el objetivo que persigue cada tipo de prueba, evitando arrastrar errores que debieron solucionarse en pruebas precedentes. Por tanto, en esta fase se llevarán a cabo las siguientes acciones:
    • Ejecución de las pruebas de código: Un alto porcentaje de estas pruebas pruebas se podrán automatizar en herramientas, tales como Checkstyle, PMD, Findbugs.
    • Ejecución del Plan de Pruebas Unitarias: Para la ejecución del Plan de Pruebas Unitarias se deberá utilizar una herramienta que automatice el proceso de ejecución de dichas pruebas, por ejemplo, JUnit. El Equipo de Proyecto deberá entregar los ficheros fuentes que implementen las pruebas JUnit y los ficheros de recursos asociados (properties, xml de config,etc.) de forma que puedan ser ejecutadas las pruebas posteriormente durante el proceso de revisión de la entrega.
    • Ejecución del Plan de Pruebas de Integración: Para automatizar las pruebas de integración se pueden emplear las mismas herramientas que para las pruebas unitarias (por ejemplo, JUnit), pero los casos de pruebas por regla general serán más largos y la verificación de resultados puede requerir más de una comprobación.
    • Ejecución de las Pruebas Funcionales: Se deberán ejecutar cada uno de los casos de pruebas funcionales siguiendo la estrategia definida. Como resultado de la ejecución del plan de pruebas el Equipo de Proyecto deberá entregar un informe en el que se indique el resultado obtenido de la ejecución de cada caso de prueba.
  • Entregables:
    • Implementación de Pruebas Unitarias
    • Implementación de Pruebas de Integración
    • Informe Pruebas Funcionales
    • Además de las pruebas que el Equipo de Proyecto deberá realizar antes de formalizar la entrega software, posteriormente, durante la revisión de la entrega, la Oficina de Testing ejecutará un conjunto de pruebas que aseguren la calidad del software desarrollado. Para ello se ha definido un conjunto de verificaciones las cuáles están contempladas en el Subsistema de Verificación de madeja. Como resultado de las pruebas realizadas, en base a los criterios establecidos, se obtendrán los siguientes informes resultado.
      • Informe de revisión de la entrega software
      • Informe de revisión del testing temprano
      • Informe de revisión de verificación y ajustes en entornos
      • Informe completo del resumen de las pruebas realizadas
• Despliegue.
  • Descripción: El despliegue deberá tener en cuenta tanto los aspectos técnicos (componente de software/hardware) como los humanos: formación, gestión del cambio, etc.

Responsabilidades:

• Seleccionar las herramientas que ofrezcan soporte adecuado a la creación y evolución de sistemas.
• Facilitar los recursos necesarios para desarrollar un sistema de información.

Objetivos

• Establecer una metodología para llevar acabo el proceso de desarrollo y evolución de un sistema de información.
• Generar el código que implementa el funcionamiento de los componentes del sistema y comprobar su corrección de forma individual.
• Garantizar la calidad del sistema a lo largo del ciclo de vida completo, incluido el mantenimiento.