ISTQB – Cap 1 – Fundamentos del Testing – II

Siguiendo con la secuencia de entradas (Cap1-Parte I) sobre la certificación ISTQB, les dejo la parte II del capitulo 1.

Principios del Testing

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.

Proceso fundamental del Testing

Planificación y Control

La Planificación de las pruebas es la actividad de verificar que se entienden las metas y los objetivos del cliente, las partes interesadas (stakeholders), el proyecto, y los riesgos de las pruebas que se pretende abordar. Esto nos dará lo que comúnmente se conoce como la misión de las pruebas o la asignación de las pruebas. Basado en este entendimiento, que establece las metas y objetivos de la prueba en sí, podemos obtener un enfoque de las pruebas.

El Control de las pruebas es la actividad permanente de comparar el progreso real contra el plan, y comunicar el estado actual de las pruebas, incluyendo las desviaciones del plan. Se trata de tomar las medidas necesarias para cumplir la misión y los objetivos del proyecto.

Análisis y Diseño

Tiene como tareas principales la revisión de la base de pruebas (tales como los requerimientos del producto, la arquitectura, las especificaciones de diseño e interfaces), la verificación de las especificaciones para el software bajo pruebas; evaluar la testeabilidad de los requisitos y el sistema; Identificar y priorizar las condiciones de prueba; Identificar los datos necesarios de prueba; Diseño y priorización de los casos de las pruebas ; Diseño del entorno de prueba e identificación de cualquier infraestructura necesaria y las herramientas.

Aplicación  y Ejecución

La aplicación de las pruebas tiene las siguientes tareas principales:
 • Desarrollar y dar prioridad a nuestros casos de prueba, utilizando las técnicas que veremos en sesiones posteriores.
• También se escriben las instrucciones para la realización de las pruebas (procedimientos de prueba), así como crear los datos de prueba para ellos. Opcionalmente, es posible que necesitemos automatizar algunas pruebas utilizando arneses de prueba y scripts de prueba automatizados.
• Creación de conjuntos de pruebas de los casos de prueba para la ejecución de la prueba eficientemente. Un conjunto de pruebas es una colección lógica de casos de prueba que, naturalmente, trabajan juntos. Los conjuntos de pruebas a menudo comparten datos y un alto nivel común de un conjunto de objetivos. También vamos a establecer un calendario de ejecución de las pruebas.
• Implementar y verificar el ambiente. Nos aseguramos de que el entorno de pruebas se ha configurado correctamente, posiblemente, incluso la realización de pruebas específicas sobre el mismo.

Por otro lado, ejecución de las pruebas tiene las siguientes tareas principales:

• Ejecutar los bancos de pruebas y casos de prueba individuales, siguiendo nuestros procedimientos de pruebas. Podemos hacerlo manualmente o mediante el uso de herramientas de prueba de ejecución, de acuerdo con la secuencia prevista, la ejecución de la mayoría más importantes en primer lugar.
• Registrar el resultado de la ejecución de pruebas y registrar la identidad y las versiones del software en las herramientas de pruebas. Debemos saber exactamente lo que en las pruebas se utilizó contra la versión del software, tenemos que informar defectos con versiones específicas, y el registro de las pruebas para un registro de auditoría.
• Comparar los resultados reales (lo que pasó cuando nos encontramos con las pruebas) con los resultados esperados (lo que habíamos anticipado que ocurriría).

Cierre de Pruebas

Se recolecta la información de las actividades de prueba completadas para consolidar.  Se verifican los entregables y que los defectos hayan sido corregidos. Se evaluá como resultaron las actividades de testing y se analizan las lecciones aprendidas.

Psicología en el proceso de Pruebas

El éxito de las pruebas esta influenciado por factores psicológicos, es importante tener objetivos claros, un balance entre testear uno mismo y las pruebas las realice alguien independiente, tener buenos canales de comunicación.

La persepción durante el ciclo de desarrollo del software es que el desarrollador construye y el tester destruye, pero ambas actividades son constructivas, ya que si bien llevan a cabo distintos caminos, al final, ambos buscan lograr la calidad del software.

La relación entre el desarrollador y tester normalmente no es una tarea fácil debido a que:

• Los Tester  suelen señalar los problemas con el software. Son considerados siempre como portadores  malas noticias (Es como decirle a una madre que su bebé es feo).  Los fallos durante las pruebas pueden ser percibidos como una crítica contra el producto y en contra del autor.
• Los desarrolladores tienden a pensar que su código es impecable. Hay un afecto emocional donde los desarrolladores no quieren encontrar defectos.
• Los testers son percibidos como los culpables de retrasar el proyecto buscando fallas en el sistema.

Por esto tenemos que aprender a lidiar con los defectos de forma constructiva:

• Aceptar y esperar errores / defectos
• Los errores son naturales – hagamos un plan para ellos
• Centrarse en el problema a resolver – no en la búsqueda de los culpables
• Aprender de los errores / defectos

Es importante que colaboran juntos: trabajar hacia una meta común.Para poder trabajar de la mejor manera como equipo los resultados se deben comunicar de manera objetiva, no subjetiva. Si hay errores, defectos o fallos se comunican de una manera constructiva, los malos sentimientos entre los testers y los analistas, diseñadores y desarrolladores se pueden evitar. Por lo general, el caso es que alguien se molesta con la otra persona, especialmente cuando están bajo presión de tiempo.

Sin embargo, hay varias maneras de mejorar la comunicación y las relaciones entre los testers y otros:
Comunicar los resultados en el producto de forma neutral, los hechos se centran de manera que no se critique a la persona que lo creó, por ejemplo, escribir informes de incidentes y hechos objetivos y resultados de la revisión.
Comience con colaborar en lugar de batallar (recordar que el objetivo común de todos es  mejorar la calidad del sistema).
Trate de entender cómo siente la otra persona y por qué reacciona como lo hace.
Confirme que la otra persona ha entendido lo que ha dicho, y viceversa.
Sea cortés y servicial, colaborativo con sus colegas.
Explique que al saber de esto ahora podemos trabajar alrededor de ella o arreglarlo para que el sistema de entrega es mejor para el cliente.

Para cerrar, lo importante del CAP 1 es tener claro los siguientes puntos:

• Porque es necesario el testing, basandose en ejemplos y evidencias.
• Poder dar ejemplos del impacto negativo de los defectos o bugs para las personas, companias, y el contexto.
• Poder contrastar un defecto con sus síntomas.
• Poder definir como el testing encaja y da soporte a la calidad del software.
• Tener claros los conceptos de Bug, Falla, error, calidad, riesgo, software, testing y testing exhaustivo.
• Poder definir los objetivos comunes del testing.
• Poder definir como el testing encuentra defectos, provee los niveles de confianza sobre el producto y previene los defectos.
• Poder definir y explicar los principios del testing.
• Tener claros los conceptos de código, debugging, desarrollo de software, requerimientos, revisiones, casos de prueba, objetivos del testing.
• Reconocer el proceso fundamental del testing.
• Reconocer las actividades principales de cada una de las etapas del proceso fundamental del testing.
• Tener claros los conceptos de Criterio de Aceptación, testing de regresión, Precondición de Pruebas, Cobertura de Pruebas, Datos de Prueba, Ejecución de Pruebas, registro de pruebas, Plan de Pruebas, Estrategia de Pruebas, reporte de pruebas.
• Poder explicar la psicología del testing y como las personas influyen en el éxito del testing.
• Poder fundamentar la importancia de los objetivos claros y la buena comunicación.
• Poder definir las diferencias entre lo que piensa un desarrollado y un tester.