La partición de equivalencias en las pruebas de software es una técnica de pruebas de caja negra que le ayuda a crear casos de prueba eficaces sin comprometer la cobertura de las pruebas.
En este artículo, veremos qué es la partición de clases de equivalencia, por qué es útil y exploraremos algunos de los procesos y enfoques que puede utilizar para desbloquear los beneficios de esta técnica.
Qué es la partición de clases de equivalencia
en pruebas de software?
Todos los programas informáticos tienen unas condiciones de entrada particulares. En el contexto de las pruebas de software, estas condiciones de entrada describen los valores o datos que un probador debe utilizar para verificar la calidad y funcionalidad de su software. Estas entradas pueden ser algo tan simple como un clic del ratón, hasta texto y números.
Una partición equivalente en las pruebas de software explora las distintas entradas necesarias para utilizar el software y las agrupa en clases de equivalencia, es decir, conjuntos de entradas que tendrán un efecto equivalente en el comportamiento del software.
Si sabes cómo se comportará cada grupo de entradas, no necesitas probar cada representante del grupo. Como tal, la partición de clases de equivalencia es una gran manera de ayudar a los probadores a reducir la frecuencia de las pruebas redundantes. En un mundo de desarrollo de software hipercompetitivo con plazos cada vez más ajustados, ahorrar tiempo y esfuerzo en el ciclo de vida de las pruebas de software (STLC) es crucial.
Por último, cabe señalar que la prueba de equivalencia es una técnica de prueba de caja negra. En pocas palabras, significa que los probadores no necesitan conocer el código interno o el funcionamiento interno del programa. Las pruebas se basan en entradas, salidas y comportamientos externos. Como tales, estas pruebas se centran en gran medida en el comportamiento del usuario mientras utiliza el programa.
1. La partición de la equivalencia de las pruebas de software en pocas palabras
La partición de equivalencias divide los datos de entrada de las pruebas de software en dos campos: entradas válidas y no válidas. Los valores dentro de cada partición deben hacer que el software muestre el mismo comportamiento. Por ejemplo:
- Si la condición de un valor de la partición A es verdadera, también deben serlo los demás valores de la partición A.
- Del mismo modo, si las condiciones de un valor de la partición A son falsas, los demás valores de la partición A también deben ser falsos.
En un contexto de pruebas, cada partición debe cubrirse al menos una vez. Lógicamente, esto significa que si una entrada de la Partición A falla, el resto de entradas también fallarán. Este proceso debería ahorrar tiempo, ya que en lugar de probar cada entrada que se encuentra en la Partición A, los probadores pueden probar sólo una y extrapolar el resultado basándose en sus puntos en común.
2. Por qué son importantes las pruebas de equivalencia de clase en las pruebas de software
Antes de entrar en las ventajas directas de las pruebas de clases de equivalencia en las pruebas de software, debemos definir por qué es importante este enfoque.
Todos los probadores entienden que las pruebas de software requieren compromisos. El tiempo y los presupuestos son limitados, lo que significa que los responsables de las pruebas deben aprovechar al máximo sus recursos. La partición de equivalencias en pruebas de software ayuda a los equipos a encontrar un equilibrio entre eficacia y fiabilidad en sus pruebas reduciendo el número de entradas.
Ventajas de la partición por equivalencia
en pruebas de software
Los equipos de pruebas se decantan por una partición equivalente en las pruebas de software por diversas razones. He aquí algunas de las más convincentes.
1. Eficacia
La gran ventaja de las pruebas de partición de equivalencia reside en su eficacia. Cuando los evaluadores utilizan la partición por equivalencia, pueden reducir el número de casos de prueba necesarios sin comprometer la cobertura de la prueba. Al seleccionar un caso de entrada de cada clase de equivalencia, los probadores pueden estar seguros de que comprenden cómo funciona su software con una variedad de entradas.
2. Simplicidad
Otra gran ventaja de la partición de equivalencia de las pruebas de software es su simplicidad. Desglosar un conjunto diverso de entradas en datos válidos y no válidos significa que la planificación de las pruebas es mucho más sencilla. Probar cada entrada individualmente requiere mucha documentación y coordinación. Reducirlo a un ejemplo representativo agiliza el proceso de prueba.
Cobertura mejorada
El uso de clases de equivalencia en las pruebas también permite utilizar el tiempo de prueba de forma más eficaz. Reducir las entradas de prueba en clases significa que puede probar más a fondo cada clase. Este enfoque global sería francamente imposible si se probara cada entrada por separado. La partición de equivalencias permite a los equipos ser minuciosos y probar datos válidos e inválidos, casos límite, valores límite, etc.
3. Reutilización
El tiempo inicial que se invierte en establecer cada clase de equivalencia en las pruebas de software se amortiza más adelante si se reutilizan estas clases para futuras pruebas de entrada. Aunque no todas las particiones serán relevantes para futuras pruebas, las que lo sean le ahorrarán mucho tiempo en futuros proyectos o incluso en situaciones de pruebas de regresión.
Inconvenientes de la partición por equivalencia
en pruebas de software
Aunque la partición por equivalencia ofrece algunas ventajas importantes, no es la solución ideal para todos los casos. Exploremos algunas de sus limitaciones.
1. Orden de entrada
En determinadas situaciones, el orden de entrada es una parte fundamental para probar la funcionalidad de una aplicación. Eso no es algo que se pueda reducir realmente utilizando la partición por equivalencia. Los encargados de las pruebas deben ser conscientes de estas situaciones y utilizar técnicas alternativas para proporcionar una buena cobertura.
2. Dependencias de entrada complejas
El software complejo con dependencias de entrada complejas es otra área en la que se ponen de manifiesto las limitaciones de la partición de equivalencias. Por ejemplo, programas informáticos que realizan cálculos a partir de diversas entradas. En este escenario, los probadores tendrían que utilizar diversas técnicas para reducir la explosión combinatoria y aumentar la probabilidad de aislar los defectos.
Enfoques alternativos para complementar la
limitaciones de las pruebas de equivalencia
Aunque las pruebas de partición de equivalencia son adecuadas para muchos escenarios de prueba, el software muy complejo con dependencias intrincadas entre los valores de entrada puede requerir enfoques complementarios adicionales.
Cuando se trata de escribir casos de prueba para software complejo, utilizar una combinación de estos enfoques es una idea sólida.
1. Pruebas por pares
La prueba por pares es una técnica de prueba de software que comprueba todas las combinaciones posibles de cada par de parámetros de entrada. Este enfoque garantiza que cada par de parámetros se pruebe conjuntamente al menos una vez.
2. Pruebas de tablas de decisión
Una tabla de decisiones ayuda a los probadores a trazar metódicamente diferentes combinaciones de entrada. Es una buena forma de garantizar una cobertura sistemática cuando existen dependencias complejas.
3. Pruebas de transición de estado
Este tipo de prueba mide cómo el software pasa de un estado a otro en respuesta a varias combinaciones de entrada.
4. Pruebas basadas en modelos
Este enfoque requiere crear un modelo basado en la lógica interna del software y utilizar una herramienta de automatización para crear casos de prueba basados en ese modelo. Esta técnica es experta en manejar la complejidad y garantizar una cobertura adecuada.
Ejemplos de pruebas de partición de clases de equivalencia
La mejor manera de entender la partición de equivalencias es ver cómo y dónde se puede utilizar una clase de equivalencia en las pruebas de software. He aquí algunos ejemplos que le ayudarán a visualizar mejor el concepto.
1. Ejemplo de prueba de partición de clases de equivalencia nº 1
Un formulario de pedido en línea es un buen ejemplo de clase de equivalencia en las pruebas de software.
Supongamos que está creando una aplicación para una tienda online de material de papelería. Existe una hoja de pedido típica para fardos de papel A4. A continuación se explica cómo utilizar las clases de equivalencia para probar esta forma.
Clases de equivalencia:
Las cantidades de papel A4 están dentro de un rango específico de, por ejemplo, 1 a 100. Entonces, las tres clases son:
- 1 a 100
- Números inferiores a 1
- Números por encima de 100.
Casos de prueba:
Deben ejecutarse tres casos de prueba, con los siguientes resultados esperados
- Cualquier número entre 1 y 100 = Pedido tramitado
- Números inferiores a 1 = mensaje de error
- Números superiores a 100 = mensaje de error
2. Ejemplo nº 2 de prueba de partición de equivalencia
Una clase de equivalencia en las pruebas de software puede tratar algo más que números. En este ejemplo, exploraremos cómo puede utilizar el mismo principio para verificar un portal de carga de archivos. Supongamos que necesita realizar pruebas para un sitio que requiere que los usuarios carguen documentos de identidad, pero sólo puede aceptar formatos específicos.
Clases de equivalencia:
- Los documentos compatibles son PDF y JPEG.
- Los documentos no compatibles son todos los demás formatos de documento
- Ningún documento
Casos de prueba:
- Prueba cargando PDF o JPEG = carga correcta
- Prueba cargando formato no soportado = mensaje de error
- Prueba sin carga de archivos = mensaje de error
Cómo realizar una partición de equivalencia
enfoque de las pruebas de software
Si desea utilizar clases de equivalencia en las pruebas, debe adoptar un enfoque estratégico. He aquí una útil guía paso a paso para aplicar la partición de equivalencias en las pruebas de software.
Paso nº 1: Identificar las variables de entrada
Cada programa responde a una serie de variables de entrada. En el caso del software complejo, estas variables pueden ser enormes. Por tanto, revisa los requisitos y especificaciones del software y señala todas las variables que influyen en su comportamiento.
Algunas de las entradas más obvias incluirán formularios de entrada de usuario. Sin embargo, debe considerar una gama más amplia de entradas para su lista. También puede tener en cuenta variables de entorno, llamadas a la API, cálculos internos, etc.
A continuación, debe comprender los distintos tipos de datos variables. Puede clasificar estas variables como enteras, booleanas, de cadena, etc., para definir las particiones adecuadas.
Por último, hay que explorar las restricciones de entrada. Por ejemplo, los caracteres permitidos, los formatos definidos y los valores mínimos y máximos.
Paso 2. Determinar particiones válidas y no válidas
Observe cada variable de entrada y empiece a dividirlas en resultados válidos e inválidos. Éstas serán sus clases de equivalencia en las pruebas.
1. Particiones válidas
Las particiones válidas pueden dividirse en dos clases.
Clases de equivalencia positiva:
Valores que espera que su software gestione correctamente. Por ejemplo, para un software que registra calificaciones porcentuales, cualquier cosa entre 0 y 100 es válida.
Clases de equivalencia negativas:
Esta categoría será para los valores que están fuera de los límites de la entrada esperada, pero que su software debe manejar con un mensaje de error. Por ejemplo, la entrada es 110 para un grado de porcentaje, lo que hace que el software devuelva un mensaje de error que dice: «Todos los valores deben ser de 0 a 100».
2. Particiones no válidas
Estas clases de equivalencia incluirán entradas que desencadenarán errores o comportamientos inesperados. En nuestro ejemplo anterior, eso podría incluir intentos de introducir A+ o B o entradas similares en la calificación porcentual. Aunque estas entradas podrían ser técnicamente correctas, están fuera de las expectativas numéricas.
#3. Redacción de casos de prueba eficaces
A continuación, debe diseñar casos de prueba que cubran cada partición de equivalencia al menos una vez. Como se ha mencionado anteriormente en el artículo, esto garantiza una cobertura de pruebas adecuada.
En primer lugar, debe seleccionar valores representativos dentro de cada partición de equivalencia que puedan abarcar tanto datos válidos como no válidos.
Consejos para escribir casos de prueba sólidos
- Piense en los valores límite: Asegúrate de que compruebas los límites de tus particiones. Mínimo, máximo, inclusivo, exclusivo, etc., ya que estas áreas son firmes candidatas a los errores. Por ejemplo, si sus expectativas de entrada están entre 0 y 100, compruebe si hay valores negativos, así como números como 101.
- Considere escenarios de prueba positivos y negativos para sus casos de prueba válidos e inválidos.
- Las pruebas combinadas son una buena idea. Utilice algunos enfoques diferentes, como se indica en nuestros enfoques alternativos, para complementar las limitaciones de la sección anterior sobre pruebas de equivalencia.
- Documente los motivos por los que los valores de entrada se han dividido en particiones específicas y describa claramente el comportamiento esperado de cada prueba.
- Siempre que sea posible, utilice herramientas visuales para aportar claridad y objetividad a sus casos de prueba mediante diagramas o tablas para trazar sus particiones.
#4. Programe y ejecute sus casos de prueba
Prioriza tus tareas en función de factores como:
- Qué zonas tienen más probabilidades de presentar defectos
- Qué escenarios tienen más probabilidades de provocar situaciones graves, como bloqueos o congelaciones.
A continuación, ejecute las pruebas y registre los resultados y los errores que se produzcan. Para programas complejos con muchas entradas, puede utilizar herramientas de RPA para imitar las acciones de los usuarios.
#5. Analizar los resultados
Agrupe los datos de las pruebas recopilados y analice los resultados. Algunos métodos que debes utilizar son
- Examine cada caso de prueba y compare los resultados reales con los esperados.
- Encuentre cualquier discrepancia e investigue y notifique cualquier error o defecto.
#6 Consejos adicionales
Aunque estos consejos no se aplicarán en todos los casos, resultarán útiles para las pruebas de software complejas.
- Las tablas de decisión son una excelente forma de visualizar las particiones de equivalencia y las distintas combinaciones de entrada que puede utilizar.
- Puede fusionar clases equivalentes si muestran un comportamiento casi idéntico, lo que optimiza aún más el proceso de prueba.
- Utilizar pruebas de valores límite para mejorar la detección de defectos
- Siempre que sea posible, automatice sus casos de prueba de partición de equivalencias
Partición de equivalencias y análisis de valores límite
La partición de equivalencia se basa en la suposición de que cada prueba dentro de una partición producirá el mismo resultado. Aunque eso es cierto en muchas situaciones, no siempre funciona. Por ejemplo, cualquier entrada que se haya añadido a una partición por error puede quedar sin comprobar, lo que reduciría la cobertura y podría provocar inestabilidad en el software.
La solución a este problema es la prueba del valor límite. Permite a los equipos de pruebas de software centrarse en las áreas que tienen más probabilidades de contener riesgos y probar el software sobre esa base. En resumen, propone que lo más probable es que los riesgos se produzcan en los bordes o límites de sus particiones de entrada. Por lo tanto, los probadores pueden escribir casos de prueba en los límites superior e inferior de las entradas, además de los otros casos de prueba de clase de equivalencia.
Partición de equivalencias y automatización con ZAPTEST
Las herramientas de automatización de pruebas de software, como ZAPTEST, pueden ayudar a los equipos a automatizar la partición de equivalencias tanto durante la creación como durante la ejecución de las pruebas.
Exploremos cómo ZAPTEST puede ayudarle a desbloquear los beneficios de este útil enfoque de pruebas de caja negra.
1. Selección de herramientas
Seleccionar la herramienta adecuada para el trabajo es importante. La mayoría de las herramientas de automatización de pruebas se especializan en pruebas web, móviles o de escritorio. ZAPTEST es capaz de realizar pruebas en diferentes plataformas y aplicaciones, lo que lo convierte en una opción sólida.
2. Escribir y ejecutar casos de prueba
ZAPTEST 1Script le permite explorar la interfaz de usuario para construir la automatización de pruebas. Además, también puede escanear maquetas de aplicaciones si se encuentra en una fase temprana de desarrollo. Utilizando la función Scan GUI, ZAPTEST escaneará todos los objetos de prueba y los añadirá a la lista de objetos.
A partir de aquí, puede añadir objetos al diagrama y construir los pasos de la prueba.
ZAPTEST le permite automatizar la redacción de los casos con una sencilla interfaz de arrastrar y soltar. No necesita conocimientos de programación para crear casos de prueba con ZAPTEST. Así que, desde aquí, puede seleccionar la operación relevante de un método desplegable y construir un caso de prueba basado en los valores de entrada necesarios para su interfaz. A continuación, puede crear casos de prueba para cada equivalencia y ejecutarlos. Incluso puede reutilizar casos de prueba y editarlos en el editor de pasos, lo que le ahorrará mucho tiempo.
3. Informes y gestión de casos de prueba
ZAPTEST permite ejecutar casos de prueba en paralelo, lo que ahorra un tiempo considerable. Esto puede ayudarle a ejecutar un gran número de particiones de equivalencia diferentes a la vez o a ejecutar determinados grupos de pruebas.
Los resultados son fáciles de recopilar gracias a los informes detallados de fallos/pasados, capturas de pantalla, registros de ejecución y métricas de rendimiento relacionadas con cada caso de prueba.
4. Mantenimiento de casos de prueba
También puede realizar un seguimiento y mantenimiento sencillos de sus casos de prueba gracias a las funciones de control de versiones de calidad. Además, los usuarios de ZAPTEST pueden clonar y reutilizar pruebas para alcanzar un nuevo nivel de eficacia.
ZAPTEST ofrece muchas más funcionalidades aparte de la automatización de casos de prueba. Con un conjunto de herramientas RPA, ZAPTEST ofrece funcionalidad 2 en 1, tendiendo un puente entre DevOps y BizOps en un futuro marcado por la hiperautomatización, donde todo lo que se pueda automatizar se automatizará.
Reflexiones finales
La partición de equivalencias es una solución elegante para situaciones en las que los probadores deben encontrar un equilibrio entre eficacia y precisión. Dado que algunos programas permiten una gama casi infinita de entradas, la partición de clases de equivalencia ayuda a los equipos a dividir los datos de las pruebas en trozos manejables y del tamaño de un bocado, cada uno de los cuales puede probarse a fondo.
