CLASE UNO

 Principios Básicos  del proceso de pruebas

Objetivo 

Capacitar al lector para que reconozca, recuerde y memorice los conceptos relacionados con el proceso de pruebas, además estará en la capacidad de establecer, asociar, crear afirmaciones, clasificar y categorizar ejemplos sobre los conceptos del proceso de pruebas.

1.    Contexto del proceso de pruebas

1.1.                      Por qué son necesarias las pruebas.

·         Porque las pruebas permiten detectar fallas que pueden llegar a generar grandes pérdidas monetarias para una organización, entre más tiempo se demore en encontrar la falla, mayor será el costo.

·         Evitar el incumplimiento de plazos y contratos que generen malestar al cliente.

                                 a.      Causas de defectos en el software.

·         Un ser humano puede cometer un error en un documento o el código de una aplicación. En código el error introducido es un defecto que puede producir un fallo en el sistema de manera parcial o total.

                                 b.      Las pruebas y la calidad.

·         Sirve para medir la calidad del software en términos de defectos con lo que respecta a requisitos y características funcionales y no funcionales  definidos al inicio del proyecto.

·         Aportan fiabilidad a la calidad del software en caso de detectar pocos o ningún defecto.

·         Pasar una prueba diseñada correctamente reduce el riesgo de un proyecto. Sin embargo si una prueba detecta un defecto, esto aporta calidad la calidad del sistema de software.

·         Las pruebas deben hacer parte del proceso de calidad (mismo destalle que especificación de código y diseño por ejemplo).

1.2.                    ¿Cuántas pruebas son suficientes?

·         Para determinar un número se debe tener en cuenta los riesgos técnicos, tecnológicos, de seguridad y comerciales, limitaciones del proyecto como tiempo y presupuesto.

·         Las pruebas definidas servirán para informar debidamente a las partes interesadas sobre la toma de decisiones sobre la siguiente fase del proyecto o la entrega al cliente.

1.3.                     ¿Qué es Testing?

·         Un proceso de ejecución de pruebas para demostrar que un programa es libre de errores.

·         El proceso de recopilación de información mediante observaciones y compararlas con las expectativas.

·         Las pruebas de software es un proceso de ejecución de un programa con la intención de encontrar errores.

·         Es una investigación técnica y empírica de un producto, hecho en nombre de los interesados, con la intención de revelar información relacionada con la calidad de un producto o servicio.

·         Según IEEE: El proceso de funcionamiento de un sistema o componente bajo ciertas condiciones, observar o registrar los resultados, y hacer una evaluación de algún aspecto del sistema o componente.

1.4.                    Principios de las pruebas

·         Principio 1 – El Testing demuestra la presencia de errores.

Mediante el testing podemos demostrar la presencia de errores, pero no la ausencia de los mismos.  Incluso si no se detectan deficiencias, no es una prueba de la corrección.

Este principio se deriva de la teoría del proceso de la experimentación científica [Popper] y ha sido adoptado por los testers. La analogía utilizada en la ciencia es útil para explicar este principio, no importa la cantidad de cisnes blancos que vemos, no podemos decir ’todos los cisnes son blancos”. Sin embargo, tan pronto como vemos un cisne negro, podemos decir ’No todos los cisnes son blancos”. De la misma manera, sin embargo, que muchas pruebas se hayan ejecutado sin encontrar un error, no demuestra que “No hay errores”. Tan pronto como nos encontramos con un error, se ha mostrado ’Este código no está libre de errores”.

·         Principio 2 – El testing exhaustivo es imposible

Probar todas las combinaciones de entradas y condiciones es imposible (salvo en casos triviales). En vez de intentar probar todo, debemos enfocar las pruebas en base a riesgos y prioridades.

·         Principio 3 – Testing Temprano.

Las actividades de prueba deben comenzar tan pronto como sea posible en el software o el sistema. Las pruebas deben enfocarse en los objetivos definidos en el Test Plan

El objetivo principal de las pruebas estáticas es llevar a cabo las pruebas tan pronto como sea posible, encontrar y corregir defectos de forma más barata y prevenir los defectos que aparezcan en  etapas posteriores de este proyecto. Estas actividades nos ayudan a conocer al principio los defectos e identificar los posibles grupos. Recuerden que a partir de la definición de las pruebas, las pruebas no se inician hasta que el código ha sido terminado.

·         Principio 4 – Agrupamiento de defectos.

Un pequeño número de módulos contienen la mayoría de los defectos detectados durante las pruebas de pre-lanzamiento. Un fenómeno que los testers han observado es que muchos defectos tienden a agruparse. Esto puede suceder debido a un área del código es particularmente compleja y delicada, o porque el cambio de software y otros productos tiende a causar una reacción en cadena.

Igualmente, hay que tener en cuenta que este agrupamiento de defectos va cambiando en el tiempo, por eso es importante centrarse en los “puntos calientes”. los testers  suelen utilizar esta información al hacer su evaluación de riesgos para la planificación de las pruebas, y se centrarán en los conocidos “puntos calientes”. Como el ”hot spots” de los errores se limpia tenemos que posar nuestro enfoque en otros lugares.

·         Principio 5 – La paradoja del pesticida

Si las pruebas se repiten una y otra vez, con el tiempo el mismo conjunto de casos de prueba ya no encuentran nuevos errores. Todas las técnicas de prueba se dirigen a un conjunto diferente de bugs. Si los programadores responden a las pruebas y la información de los errores mediante la reducción o eliminación de tales errores, se deduce que como su software  mejora, la eficacia de las pruebas anteriores se daña, es decir, las pruebas se desgastan y tendrán que aprender, crear y utilizar nuevas pruebas basadas en las nuevas técnicas para captar nuevos errores.

Para superar esta ”paradoja de plaguicidas”, los casos de prueba deben ser examinadas y revisadas periódicamente. Se llama la “paradoja de plaguicidas”, después de que el fenómeno de la agricultura, donde los insectos como el picudo del algodón construye la tolerancia a los pesticidas, provocando la elección de pesticidas cada vez más potentes seguido de insectos cada vez más potentes.

Pruebas nuevas y diferentes deben ser escritas para ejercitar las distintas partes del software o el sistema para encontrar potencialmente más defectos. Como el ”hot spots” de los errores se va limpiando, tenemos que posar nuestro enfoque en otros lugares, a la siguiente serie de riesgos. Con el tiempo, nuestro enfoque puede cambiar de encontrar errores de codificación, a mirar los requisitos y documentos de diseño, y en busca de mejoras en los procesos para que podamos prevenir los defectos en el producto.

·         Principio 6 – El testing es dependiente del contexto.

Las pruebas se realizan de manera diferente en diferentes contextos. Por ejemplo, la seguridad del software será testeada de forma diferente en un sitio de comercio electrónico que uno donde se comparten fotografiás.

No todos los sistemas de software llevan el mismo nivel de riesgo y no todos los problemas tienen el mismo impacto cuando se producen. Algunos de los problemas que encontramos en el uso de software son bastante triviales, pero otros pueden ser costosos y perjudiciales - provocando pérdida de reputación, de dinero, tiempo o de negocios - e incluso puede resultar en lesiones o la muerte.

A continuación se detallan algunos ejemplos de fallos de media por KLOC que confirman que las pruebas son dependientes del contexto:

3 a 10 fallas por cada mil líneas de código (KLOC) típico de software comercial

1 a 3 fallos por KLOC típico de software industrial

0,01 fallos por KLOC para el código de lanzamiento de la NASA.

·         Principio 7 – Falacia sobre la ausencia de errores

Si construimos un sistema y, al hacerlo, encontramos y corregir defectos, no quiere decir que lo convierte en un buen sistema.  Encontrar y corregir defectos no sirve de nada si el sistema integrado no se puede utilizar y no satisfacer las necesidades de los usuarios y sus expectativas. Las personas y organizaciones que compran y utilizan software como ayuda en su día a día  no están interesadas ​​en los defectos o el número de defectos, salvo que sean directamente afectados por la inestabilidad del software. La gente que usa software está más interesada ​​en que la aplicación los apoye en la realización de sus tareas de manera eficiente y eficaz. Por eso revisiones en las primeras etapas (requisitos y diseño) son una parte importante de las pruebas y si los verdaderos usuarios del sistema no han estado involucrados en el proceso de prueba en algún momento, entonces es probable que no obtengan lo que realmente quieren, por ejemplo las páginas web puede parecer libre de errores, pero si han sido diseñados de una manera que no es compatible con los procesos de negocio del sistema no se podrán utilizar.

1.5.                     Proceso de pruebas

                                 a.      Planeación y control.

·         La planificación es la actividad de definir los objetivos de las pruebas y la especificación de las pruebas con vista a cumplir los objetivos y estrategias del proyecto en general

·         El control de las pruebas es comparar el progreso real con el plan previsto o especificado en el documento de plan de pruebas, entregando e informando acerca de las desviaciones con respecto a lo planificado.

                                 b.      Análisis y diseño.

·         Es la actividad durante la cual los objetivos de las pruebas generales se transforman en casos de prueba y planes de prueba tangibles.

·         Se revisan las bases de las pruebas, evalúan la estabilidad de las pruebas, identificar y priorizar las condiciones de las pruebas, diseñar y priorizar los casos de prueba.

·         Diseñar la configuración del entorno, infraestructura y herramientas de pruebas.

·         Crear trazabilidad bidireccional entre las pruebas y los casos de pruebas.

                                  c.      Implementación y ejecución

·         Se explican los procedimientos o guiones de prueba mediante la ejecución ordenada de los casos de prueba, así como cualquier otra información.

                                 d.      Evaluación de criterios de éxito y reporte de resultados.

·         Evalúa la ejecución de pruebas contra los objetivos definidos.

·         Crear un resumen de evidencia de pruebas para las partes interesadas.

                                 e.      Cierre de actividades.

Es la actividad donde se recopilan los datos de las actividades de pruebas finalizadas para consolidar productos, soportes de pruebas, los hechos y las cifras que evidenciarán o permitirán medir la calidad del software.