top of page

Early Testing: Aliado estratégico en las pruebas de software

Actualizado: 26 jun 2021

Las pruebas tempranas o Early Testing establece que las pruebas de software deben comenzar lo antes posible en el ciclo de vida del desarrollo de software, sin embargo, ¿Qué significa esto y porqué es importante su uso en los proyectos de software?



Si estás involucrado/a en los procesos de creación de software, entonces es probable que hayas escuchado hablar del ciclo de vida de desarrollo de software o (SDLC por sus siglas en inglés). En síntesis, es un esquema de pasos secuenciales que muestra las etapas necesarias para la elaboración de un software.


Al evaluar el ciclo de vida del desarrollo de software, podemos visualizar que existe un apartado destinado para implementar pruebas de calidad de software, también conocido como la etapa de "testing".


Si nos preguntaran: ¿En qué etapa del SDLC debemos aplicar pruebas de calidad de software? La respuesta pareciera obvia para muchos ingenieros y analistas, debemos responder: "En la etapa de <<testing>> porque es claro, está ahí descrito, ese es el mejor momento"...sólo que no lo es.


Muchos tienden al error de determinar que las pruebas de calidad de software inician en la fase "destinada" para ello en el SDLC, sin embargo el principio de "Early Testing" difiere de esta posición.


El "Early Testing" o "Pruebas tempranas" es uno de los 7 principios de las pruebas de calidad de software y establece :


Las pruebas deben comenzar lo antes posible en el Ciclo de vida del desarrollo de software, de módo que cualquier defecto en los requisitos o la fase de diseño se capture en las primeras etapas.

Este marco de pensamiento es de mucha importancia para la correcta implementación de los procesos de calidad de software para cualquier proyecto. Detectar defectos lo más temprano posible tiene influencia directa sobre distintos aspectos del proyecto, tales como: calidad, presupuesto, tiempo e incluso la reputación del proyecto de cara al usuario final.


Veamos una situación cotidiana, donde el early testing no es aplicado:


Nos pasan un requerimiento para aplicarle pruebas de software, sin embargo dicho requerimiento tiene las siguientes características :

  1. No cuenta con una documentación técnica muy detallada

  2. Ya está desarrollado por el developer y se encuentra en ambiente de pruebas

  3. Tiene un tiempo de entrega bastante corto

  4. Es un requerimiento que toca un sistema con el que no estas relacionado

Dadas las características anteriores y el tiempo en el que se ha decidido involucrar al analista o ingeniero de calidad en el SDLC, se desprenden las siguientes consecuencias en relación al proceso de calidad de software para este requerimiento:

  1. Se dificulta dar una estimación realista como consecuencia de la falta de conocimiento.

  2. Es altamente probable que la cobertura de las pruebas en relación al requerimiento no sean lo suficientemente profundas

  3. Se extenderá el tiempo de prueba o realizaremos overtime con el objetivo de poder cumplir a tiempo la asignación

Entonces, ¿Qué tán temprano debemos iniciar las pruebas de calidad de software?


Respuesta: Desde el levantamiento de los requerimientos.


Al involucrarse desde el levantamiento del requerimiento el analista/ingeniero de calidad tiene la facilidad de conocer la necesidad del usuario de primera mano, entender las limitaciones de los requerimientos, obtener información que le permita ir desarrollando su plan de pruebas mucho antes de que el desarrollo inicie y dependiendo de la experiencia del analista, podría colaborar con sugerencias que permitan evitar defectos desde la concepción del requerimiento.


Las pruebas tempranas (early testing) y las metodologias de proyectos


Algo importante a tener en cuenta es que la implementacion de las pruebas tempranas es independiente de la metodologia de gestion de proyecto o desarrollo que se utilice, por poner unos ejemplos puntuales:


1. Cascada:

Como comente al principio del post, no esperes el tiempo de verificación, involucrate en las reuniones de evaluación de requerimientos desde la fase de requisitos y aporta tu perspectiva de calidad al proyecto.


2. Scrum

Participa en todas las ceremonias de creación y refinamiento de historias de usuarios, y por participar me refiero a que lo hagas de manera activa y no pasiva, si participas de la ceremonia y no obtuviste o generaste nueva información tu participación fue pasiva. Por otro lado, cuando te adelantas a futuros escenarios que pudieran representar problemas para lo que espera u obvia el usuario final tu participacion se considera activa.


Aprovecha cada ocasión para traer tu experiencia sobre la mesa de manera productiva para el equipo de trabajo y siempre mantente inquisitivo sobre qué tan "probables" son los requerimientos.


Personalmente tengo la siguiente filosofía

<<Los buenos analistas detectan defectos, los mejores ayudan a prevenirlos>>

La implementación de este principio nos ayuda a convertirnos en profesionales del aseguramiento de la calidad de software con criterio proactivo en la evaluación de requerimientos, y a su vez, nos ayuda a impulsar a nuestro equipo de trabajo a migrar de la mentalidad de detección a la mentalidad de prevención estrategica.

Entradas Recientes

Ver todo

Kommentarer


bottom of page