Las pruebas de software son un proceso crucial que contribuye a garantizar la calidad y el buen funcionamiento de un producto de software. Se trata de un conjunto de actividades que buscan evaluar y verificar que el software cumpla con los requisitos establecidos, las necesidades de los usuarios y los niveles de riesgo aceptables para el negocio.

El proceso de pruebas de software se divide en 7 áreas de proceso y es un proceso continuo que se debe realizar a lo largo del ciclo de vida del desarrollo del software.  A continuación se proporciona una breve descripción de cada área, sus objetivos y sus actividades más significativas.

Planeación

Objetivo: Definir el enfoque general de las pruebas para alcanzar los objetivos del proyecto.

Actividades:

• Establecer los objetivos de las pruebas.
• Definir la estrategia y tácticas de prueba que se utilizarán.
• Identificar los recursos necesarios para las pruebas.
• Crear un cronograma para las actividades de prueba.

Análisis

Objetivo: Comprender a fondo los requisitos del software, el contexto del producto y los riesgos potenciales.

Actividades:

• Analizar los requisitos y especificaciones del software.
• Evaluar el contexto del producto y del negocio.
• Identificar los riesgos asociados al producto y al proyecto.
• Definir las métricas de cobertura de pruebas que se utilizarán.

Diseño

Objetivo: Crear casos de prueba detallados, datos de prueba y definir el entorno de prueba.

Actividades:

• Diseñar casos de prueba que cubran todos los requisitos y funcionalidades del software.
• Crear datos de prueba realistas para cada caso de prueba.
• Definir la infraestructura y los entornos de prueba necesarios.

Implementación

Objetivo: Desarrollar los scripts de prueba, integrar las suites de prueba y preparar el entorno de prueba.

Actividades:

• Desarrollar scripts de prueba automatizados o manuales.
• Integrar las suites de prueba en la herramienta de gestión de pruebas elegida.
• Definir planes de ejecución de pruebas.
• Crear datos de prueba específicos para cada caso de prueba.
• Implementar la infraestructura y los entornos de prueba definidos en la fase de diseño.

Ejecución

Objetivo: Ejecutar los casos de prueba, registrar los resultados y reportar las anomalías encontradas.

Actividades:

• Ejecutar los casos de prueba de acuerdo al plan definido.
• Registrar los resultados de las pruebas de forma detallada.
• Identificar y reportar las anomalías encontradas durante las pruebas.
• Comunicar los resultados de las pruebas a las partes interesadas.

Monitoreo y Control

Objetivo: Evaluar continuamente el proceso de pruebas y tomar acciones correctivas cuando sea necesario.

Actividades:

• Monitorizar el progreso de la ejecución de las pruebas.
• Analizar los resultados de las pruebas para identificar tendencias y patrones.
• Implementar acciones correctivas para mejorar el proceso de pruebas.
• Ajustar el plan de pruebas según sea necesario.

Cierre

Objetivo: Finalizar el proceso de pruebas de manera formal, documentar las lecciones aprendidas y archivar los artefactos de prueba.

Actividades:

• Realizar una retrospectiva del proceso de pruebas para identificar las fortalezas y áreas de mejora.
• Documentar las lecciones aprendidas durante el proceso de pruebas.
• Archivar los artefactos de prueba, como planes de prueba, casos de prueba, scripts de prueba y reportes de resultados.

En resumen

Las áreas de proceso del proceso de pruebas de software trabajan en conjunto para contribuir a garantizar que el software cumpla con los requisitos, sea de alta calidad, satisfaga las necesidades de los usuarios y disminuya el riesgo para el negocio. Cada área tiene un papel crucial en el proceso general de pruebas y contribuye al éxito del proyecto.

Es muy frecuente entre los profesionistas en tecnología utilizar los términos error, bug, y falla para describir un resultado inesperado durante la ejecución de un programa o para referirse a la causa que genera dicho resultado. Sin embargo, error, bug, y falla no son lo mismo. Comprender las diferencias entre estos conceptos y usarlos adecuadamente simplifica y estandariza la comunicación.

Conceptos

El glosario de la Junta Internacional de Aptitudes de Pruebas de Software (ISTQB, por sus siglas en inglés) define los términos de la siguiente manera:

La ISTQB señala que las palabras defecto, problema y falta son sinónimos de bug y que es preferible el uso de la palabra defecto sobre los otros términos a pesar de que el término bug es más utilizado.

De manera similar, la palabra equivocación es sinónimo de error, y error es el término preferido.

El siguiente enunciado es de utilidad para entender, tanto la diferencia como la relación, que existe entre los términos error, defecto y falla.

Una persona comete un error e introduce un defecto en el código del programa. Si durante la ejecución del programa, se ejecuta la línea de código con el defecto, el programa funciona de manera inesperada, es decir, el defecto causa una falla.

Ejemplo

Un programador tiene la tarea de implementar un programa que controle el acceso a un sitio web permitiendo el acceso sólo a usuarios de 18 o más años de edad.

El programa solicita al usuario introducir su edad y si ésta es de 18 o más, le da la bienvenida al sitio web, si no, se le niega el acceso por ser menor de edad.

El programador implementa el software y decide probarlo utilizando los siguientes casos de prueba:

Los resultados de sus pruebas se muestran a continuación:

Como se observa en los resultados, el programa autoriza correctamente el acceso al sitio web, cuando se introduce la edad de 18 años. Sin embargo falla en los otros dos casos. En el caso en el que la edad es de 17 años el programa debió de negar el acceso al sitio pero el acceso fue autorizado y en el caso en el que la edad es de 19 años el programa debió permitir el acceso pero lo negó.

El programador inspecciona el código y detecta un defecto en la línea 3. La condición utiliza el operador menor o igual que (<=), es decir, verifica que la edad sea de 18 años o menos. En lugar de utilizar el operador <=, debería utilizar el operador mayor o igual que (>=) para que la condición verifique que la edad sea de 18 años o más. El programador introdujo por error el defecto en la condición.

Una vez que el programador identificó y corrigió el defecto que causó la falla, el programador prueba nuevamente el programa utilizando los mismos casos de prueba y verifica que funciona adecuadamente.

Cabe destacar que los defectos no son la única fuente de fallas en el software, otros factores como cambios inesperados en librerías o sistemas de los que se depende también resultan en fallas.

Resúmen

Los términos error, defecto, y falla no son lo mismo y utilizarlos adecuadamente nos ayuda a tener una comunicación eficaz.

La relación entre probar y depurar es tan estrecha que frecuentemente estos términos se utilizan como sinónimos, sin embargo, no lo son. En este artículo primero presentamos las definiciones de probar y depurar y posteriormente exploramos la relación que existe entre las fallas, las pruebas y el proceso de depuración.

Con base en el glosario de la Junta Internacional de Aptitudes de Pruebas de Software (ISTQB, por sus siglas en inglés) podemos definir los términos de la siguiente manera:

Es preferible utilizar los términos formales probar y depurar en lugar de los anglicismos testear y  debuggear respectivamente.

Como muestran las definiciones anteriores los propósitos de probar y depurar son diferentes. Mientras los propósitos de probar son evaluar si el producto cumple con sus requisitos, es apto para su propósito y detectar defectos, los propósitos de depurar son comprender las causas de las fallas y reparar los defectos.

Relación entre fallas, pruebas y proceso de depuración

Una falla tiene lugar cuando durante la ejecución del software, en un escenario determinado, existe una desviación del comportamiento esperado del sistema.

Cuando una falla ocurre, ésta generalmente se reporta al equipo de desarrollo y los programadores inician el proceso de depuración con el fin de comprender la causa de la falla y de ser necesario reparar el defecto que la ocasiona.

Si la falla se presenta durante la ejecución de un escenario definido con antelación y con claridad, por ejemplo, como parte de una prueba, la reproducción y el análisis de la falla generalmente es sencillo. Sin embargo, si la falla se presenta durante la ejecución de un escenario que queda definido sólo por las condiciones del sistema en el momento en el que ocurre la falla, por ejemplo, cuando un usuario experimenta una falla al utilizar una función del software de una manera particular, la reproducción y el análisis de la falla generalmente es complejo.

De manera general el proceso de depuración consiste en los siguientes pasos:

• Analizar la falla
• Determinar si existe un defecto
• Reparar el defecto
  

La figura 2 ejemplifica las relaciones entre la ejecución de un escenario, la falla y el proceso de depuración.

En este ejemplo se considera que el escenario está definido en un caso de prueba, es decir, cada guión dentro de la caja titulada “Ejecución de un escenario” corresponde a una ejecución del caso de prueba.

Los guiones verdes representan una ejecución del caso de prueba en la que no ocurrió ninguna falla. El guión rojo simboliza una ejecución en la que la ejecución del caso de prueba falló y es en ese momento en el que se inicia el proceso de depuración.

Analizar la falla

Analizar la falla consiste en comprender con claridad el escenario que detona la falla con la intención de poder reproducirlo repetidamente, representado por los guiones amarillos en la figura, brindando al programador la posibilidad de utilizar métodos para probar diferentes hipótesis que le permitan determinar la causa de la falla.

Determinar si existe un defecto

No todas las fallas se deben a defectos, algunas fallas ocurren debido a factores externos fuera de nuestro control, por ejemplo, fallas debidas a que alguna dependencia del sistema no está disponible. En esos casos es probable que no haya ningún defecto que reparar. Sin embargo, si el programador determina que existe un defecto, entonces procede a reparar el defecto.

Reparar el defecto

En la mayoría de los casos es responsabilidad del programador determinar la fuente del defecto y realizar las actividades necesarias para repararlo. Cabe destacar que no todas las fallas se deben a defectos en el producto de software, algunas fallas tienen lugar debido a defectos en otros artefactos relacionados como son: requisitos, casos de prueba, o documentación entre otros.

Una vez que se completa la reparación del defecto, el proceso de depuración concluye.

Para el ejemplo mostrado en la figura 2 suponemos que sí existe un defecto y que éste se encuentra en el producto de software y el programador lo repara. El programador ejecuta el caso de prueba para verificar que su reparación fue exitosa y con esto concluye el proceso de depuración.

Como se aprecia en el ejemplo, el poder reproducir el escenario que detonó la falla, es decir la prueba, repetidamente es fundamental para el proceso de depuración ya que habilita al programador para probar diversas hipótesis, y al final permite probar que la reparación fue exitosa.

Conclusión

Los términos probar y depurar se refieren a actividades con propósitos diferentes. Mientras los propósitos de probar son evaluar si el producto cumple con sus requisitos, es apto para su propósito y detectar defectos, los propósitos de depurar son comprender las causas de las fallas y reparar los defectos.

Durante la depuración se ejecutan pruebas de manera iterativa con el fin de explorar diferentes hipótesis que permitan determinar la causa de la falla. Si la causa de la falla se debe a un defecto, el defecto se repara. Para confirmar que la reparación fue exitosa se ejecuta el mismo escenario en el que ocurrió la falla originalmente y se comprueba que ya no ocurra.