Proceso de Pruebas

Planificación (15% - 25%)
Esta etapa es muy importante en el proceso de pruebas ya que es donde el responsable del control de la calidad conoce el dominio y entiende el alcance del sistema que va a ser evaluado, de igual forma, conoce el proceso utilizado para su desarrollo, el entorno legal del producto, del mercado y de la competencia.
El plan de pruebas basado en los requerimientos del producto es desarrollado en esta etapa del proceso.
Ciclo de Pruebas (60%)
La etapa del ciclo de pruebas está basada principalmente en tres actividades que se detallan a continuación:
Diseño de las Pruebas
La actividad del diseño de pruebas es de mucha importancia y es pieza fundamental para lograr que la calidad de los productos llegue a ser el esperado.
Una prueba debe ser diseñada pensando en que tenga la mayor probabilidad de encontrar el mayor número de errores o utilizando una mejor definición el mayor número de no conformidades con la mínima cantidad de esfuerzo y tiempo. Para lograr esto hay dos enfoques, que a la hora de combinarlos permite lograr mayor efectividad, las pruebas de caja negra y las pruebas de caja blanca.
Las pruebas de caja negra(enfoque funcional), son pruebas que se hacen a través de la interfaz gráfica de usuario (GUI) para demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada, que se produce una salida correcta de la información y que la integridad de la información externa se mantiene.
Las pruebas de caja blanca, son las pruebas que se basan en los caminos lógicos del software, la estructura interna y la implementación del software en pruebas (prueba de unidad).
Configuración
Esta actividad del ciclo de pruebas es donde el responsable del aseguramiento de la calidad realiza la configuración del ambiente donde se van a ejecutar las pruebas y los datos que va a utilizar hasta obtener un ambiente de pruebas controlado. Por lo general es un ambiente similar al del usuario final e independiente al de desarrollo.
Ejecución
Esta etapa por lo general y basado en otros proyectos desarrollados, es recomendable que cada proceso de pruebas sea dividida en 5 iteraciones de pruebas con sus respectivas regresiones como mínimo.
Los responsables del aseguramiento de la calidad tienen la responsabilidad de ejecutar la mayor cantidad posible de iteraciones y regresiones de prueba hasta poder demostrar cuantitativamente que la cantidad de hallazgos en cada iteración presentan tendencia sostenida a la baja que permite concluir que se está logrando la estabilidad funcional del producto.

 

El encargado del aseguramiento de la calidad analiza los resultados y genera el reporte de pruebas donde se especifica los hallazgos encontrados. En este reporte se tiene que tener en cuenta que no todas los hallazgos son errores o no conformidades, ya que pueden depender de varios aspectos como, los datos de prueba que se estén utilizando, la ejecución de los pasos de la prueba, el ambiente de pruebas o la definición de los requerimientos.
Evaluación y Cierre (15% - 25%)
El proceso de prueba termina con la elaboración y presentación de conclusiones y recomendaciones tanto para el producto como para el proceso productivo.
Después de ejecutar las iteraciones propuestas de pruebas definidas en el plan de pruebas y/o haber logrado el criterio de cierre pactado, se llega a obtener la calidad deseada en el producto de software.
Liberación del producto
Desde un inicio la idea principal durante el proceso de pruebas es exponer el sistema a todas las situaciones posibles y así poder encontrar hasta el último error o no conformidad presente en el producto, sin embargo esto es imposible desde todos los puntos de vista humano, económico e incluso matemático.
Sobre esta premisa de imposibilidad para determinar el logro de la perfección, en este caso la estabilidad de una versión de un producto, es necesario buscar formas humanamente abordables y económicamente aceptables de encontrar los criterios para determinar el punto de cierre de pruebas, que debe quedar pactado desde el principio del proceso, en el plan de pruebas, en otras palaba, el alcance de las pruebas sobre el producto.

Las Pruebas en los Sistemas

Las pruebas que se realizan en los sistemas de información son un elemento crítico para la garantía de la calidad del producto y representa una visión final de los requerimientos, del diseño y de la codificación.

¿Que muestran las Pruebas?

Objetivos de las Pruebas

• Descubrir un error
• Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar errores 
• Una buena prueba tiene éxito si descubre un error
  

Principios de las Pruebas

• A todas las pruebas se les debería poder hacer un seguimiento hasta los requerimientos del cliente
• Las pruebas deberían planificarse antes de que empiecen, es decir, cuando los requerimientos estén completos 
• Las pruebas deberían empezar de lo individual a lo general: Módulos Individuales, Grupos de Módulos integrados y Sistema Total
• Las pruebas deberían ser elaboradas y ejecutadas por personal independiente al de desarrollo

Validación y Verificación

Validar y verificar un sistema o producto de software es el proceso de control que asegura que el software cumple con las especificaciones y satisface las necesidades del usuario.

Muchas veces se puede pensar que estos conceptos son lo mismo o simplemente no vemos cúal es la diferencia entre ellos, según Boehm en 1979:

• Validación: ¿Estamos construyendo el producto correcto?
• Verificación: ¿Estamos construyendo correctamente el producto?

En otras palabras, validación tiene como objetivo asegurar que el producto cumpla con las expectativas del cliente y verificación es comprobar que el software este desarrollado de acuerdo con sus especificaciones, es decir, que cumpla con los requerimientos funcionales y no funcionales definidos en la etapa de planificación del proyecto.

Cuando se desarrolla un sistema, siempre tiene un propósito, por ejemplo, un sistema de facturación, un control de inventarios, un sistema contable, etc., por esta razón es que se necesita un proceso que garantice la seguridad de que efectivamente cuando se desarrolle un sistema contable, éste va a cumplir con ese propósito y no realice el control de inventarios.

Un sistema de software debe estar sujeto a V&V en cada una de las etapas de su desarrollo. Por lo tanto, la V&V comienza con las revisiones de los requisitos, y continúa a través de las revisiones del diseño y del código hasta la prueba (o testing) del producto.

Definiciones en el Tema de la Calidad

Calidad es un tema que tiene una gran variedad de conceptos importantes que las compañías deberían conocer para establecer los procesos adecuados según sus necesidades. Algunos de estos conceptos se describen a continuación:

Calidad de Software
Según R. S. Pressman la calidad del software es la “concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos con los estándares de desarrollo, documentos y las características implícitas que se espera de todo software desarrollado profesionalmente”, el estándar ISO 8402 (UNE 66-001-92) se refiere a la calidad de software como “el conjunto de características de una entidad que le confieren su aptitud para satisfacer las necesidades expresadas y las implícitas”.

Aseguramiento de Calidad
El aseguramiento de la calidad del software es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza en que el producto (software) satisfará los requisitos dados. Es importante mencionar que el diseño del aseguramiento de la calidad se realiza antes de comenzar a desarrollarla.

Control de la Calidad
El control de la calidad del software son las técnicas y actividades de carácter operativo, utilizadas para satisfacer los requisitos relativos a la calidad, centrados en dos objetivos fundamentales:

• Mantener bajo control un proceso.
• Eliminar las causas de los efectos en las diferentes fases del ciclo de vida. 

En términos más generales podemos decir que son las actividades para evaluar la calidad de los productos desarrollados.

Sistemas de Calidad
El sistema de calidad es la estructura organizativa, procedimientos, procesos y recursos necesarios para implantar la gestión de calidad. El sistema de calidad se debe adecuar a los objetivos de calidad de la empresa, donde el responsable de fijar la política de calidad y las decisiones relativas a iniciar, desarrollar, implantar y actualizar el sistema de calidad es la dirección de la empresa.

Certificación de la Calidad
Un sistema de certificación de calidad permite una valoración independiente que debe demostrar que la organización es capaz de desarrollar productos y servicios de calidad.
Los pilares básicos de la certificación de calidad son tres:

• Una metodología adecuada.
• Un medio de valoración de la metodología. 
• La metodología utilizada y el medio de valoración de la metodología deben estar reconocidos ampliamente por la industria.
  

Gestión de la Calidad
Según la ISO 9000 la gestión de la calidad es el conjunto de actividades de la función general de la dirección que determina la calidad, los objetivos y las responsabilidades y se implanta por medios tales como la planificación de la calidad, el control de la calidad, el aseguramiento de la calidad y la mejora de la calidad, en el marco del sistemas de calidad.

Factores que determinan la Calidad del Software

Los factores que determinan la calidad se clasifican en tres grupos:

• Operaciones del Producto: características operativas:
• Corrección (Hace lo que se le pide?): El grado en que una aplicación satisface sus especificaciones y consigue los objetivos encomendados por el cliente. 
• Fiabilidad (Lo hace de forma fiable todo el tiempo?): El grado que se puede esperar de una aplicación lleve a cabo las operaciones especificas y con la precisión requerida. 
• Eficiencia (Qué recurso hardware y software necesito?): La cantidad de recursos hardware y software que necesita una aplicación para realizar las operaciones con los tiempos de respuesta adecuados.
• Integridad (Puedo controlar su uso?): El grado con que puede controlarse el acceso al software o a los datos a personal no autorizado.
• Facilidad de Uso (Es fácil y cómodo de manejar?): El esfuerzo requerido para aprender el manejo de una aplicación, trabajar con ella, introducir datos y conseguir resultados.

• Revisión del Producto: capacidad para soportar cambios:
• Facilidad de Mantenimiento (Puedo localizar los fallos?): El esfuerzo requerido para localizar y reparar errores. 
• Flexibilidad (Puedo añadir nuevas opciones?): El esfuerzo requerido para modificar una aplicación en funcionamiento. 
• Facilidad de Prueba (Puedo probar todas las opciones?): El esfuerzo requerido para probar una aplicación de forma que cumpla con lo especificado en los requisitos.
  

• Transición del Producto: adaptabilidad a nuevos productos:
• Portabilidad (Podré usarlo en otra máquina?): El esfuerzo requerido para transferir la aplicación a otro hardware o sistema operativo.
• Reusabilidad (Podré utilizar alguna parte del software en otra aplicación?): Grado en que partes de una aplicación pueden utilizarse en otras aplicaciones. 
• Interoperabilidad (Podrá comunicarse con otras aplicaciones o sistemas informáticos?): El esfuerzo necesario para comunicar la aplicación con otras aplicaciones o sistemas informáticos.
  

Conociendo estas definiciones se puede saber cuál va ser la técnica que va ser utilizada por la empresa, para cumplir con sus objetivos.

Ciclo de Vida de una Pulga (Bug)

Normalmente cuando se desarrollan productos de software, es común que esos productos en las etapas de desarrollo tengan muchos errores o no conformidades por parte de los clientes ya que no cumplen con los requerimientos o hubo un cambio de último momento.

Cuando esto sucede se tiene que realizar el reporte del error o no conformidad (pulga) encontrado para que realicen su corrección. A partir de este momento la pulga inicia un proceso de seguimiento hasta que sea corregido y cumpla con los requerimientos y expectativas del cliente.

Este proceso es el siguiente y se le llama ciclo de vida de una pulga:

1. Cuando se ingresa por primera vez un error o solicitud de un nuevo requerimiento, la tarea tiene estado Open.

2. Cuando el desarrollador corrige o implementa la tarea que se le fue asignada, ella entra en estado de resolved y puede ser por los siguientes puntos que llega a ese estado:

a. Arreglado (Fixed), Resuelto por diseño, No reproducible, No arreglado (No Fixed).

3. Después de que la tarea es revisada por el responsable de la calidad del software, esta entra en estado de cerrado y por los mismos motivos por los que fue resuelto. En el caso de que la tarea no esté funcionando correctamente, el estado que se le asigna es de Re-Open y vuelve a utilizar el mismo proceso hasta llegar al estado cerrado.

4. Algunas veces por correcciones nuevas o requerimientos nuevos, hay tareas que después de cerrados pueden entrar en estado re-open, hay que tener cuidado con este tipo de situación porque no deberían pasar si se tiene un buen proceso de calidad implementado.