En el mundo del testing de software, así como en el arte, a quienes nos motiva la excelencia, nos urge llenar nuestra caja de crayolas con la mayor cantidad y variedad de colores posible. Naturalmente, los colores primarios no pueden faltar, por tratarse de las herramientas básicas de nuestro kit; aquellas que por su relevancia resultan completamente imprescindibles, las que sí o sí deben estar presentes en toda caja de crayolas, por más newbie que seamos.

En nuestra labor como testers de software, nuestra caja de crayolas se compone del conjunto de habilidades y conocimientos que nos permiten desempeñarnos diariamente en cada proyecto que nos ha sido asignado. Cada conocimiento, ya se trate de un método, técnica o destreza, por ejemplo, vendría a representar un color, o sea, un elemento que le aportará valor al ejercicio de nuestra profesión y nos proporcionará mayor eficiencia.

Más allá de cada uno de los métodos específicos que sin duda enriquecerán ampliamente nuestras aptitudes y rendimiento, permitiéndonos diseñar casos de prueba, ejecutar pruebas exploratorias, realizar pruebas automatizadas y mucho más, resulta indispensable contar con una colección de principios esenciales que nos servirán de guía y serán de gran utilidad en nuestro afán por realizar nuestro trabajo con seriedad y dedicación.

Es importante resaltar que los principios que se listan aquí no emergieron de observaciones propias ni opiniones personales, sino que son el resultado de una exhaustiva investigación.

7 Principios esenciales del Testing de Software

1. La ejecución de pruebas demuestra la presencia de defectos

El testing nos permite demostrar la existencia de incidentes en un producto, no su ausencia. Tras el reporte de un incidente y su consecuente restauración, es posible reducir la probabilidad de que incidentes aún no descubiertos persistan en el sistema, pero la inexistencia absoluta de incidentes no sólo resulta imposible de comprobarse sino que además es una posibilidad sumamente improbable.

2. El testing exhaustivo no es posible

Exceptuando casos puntuales, probar cada combinación posible de datos y acciones en todas las funcionalidades de un software generalmente no es una opción viable, ya sea por cuestiones de tiempo, costos o recursos.

Por este motivo, al estructurar nuestras estrategias y diseñar los casos de pruebas, resulta muy conveniente considerar estos factores, para poder enfocarnos en ejecutar las verificaciones más significativas y que tengan mayor impacto.

3. Pruebas tempranas

Cuando el proceso de testing comienza en las etapas más tempranas del desarrollo de software, esta alianza resulta extremadamente beneficiosa, pues permite detectar incidentes en los albores del producto. El costo de reparación de estos incidentes sería significativamente más elevado si recién fueran detectados en fases posteriores.

4. Agrupación de defectos

Generalmente, hay ciertos módulos y funcionalidades que son más proclives a presentar incidencias (de mayor prioridad) en comparación al resto de las partes que conforman un producto. Este fundamento está relacionado con la Regla 80/20, que afirma que aproximadamente el conforme 80% de las consecuencias emergen del 20% de las causas.

En términos más precisos, esto podría traducirse de la siguiente manera: no todos los componentes de un software poseen el mismo nivel de relevancia, por lo que el enfoque más propicio en el momento de elaborar nuestra estrategia de pruebas es concentrar nuestros esfuerzos justamente en esas partes más cruciales, para detectar aquellos incidentes que puedan resultar más urgentes de resolver.

5. Paradoja del pesticida

Ejecutar los mismos tests en una misma parte estable de un sistema repetidas veces es una práctica que tiende a dificultar la detección de nuevos incidentes que aún no han sido descubiertos.

Por consiguiente, para aumentar las posibilidades de detección de incidentes, es imprescindible revisar y actualizar de manera constante nuestra estrategia de pruebas y asegurarnos de explorar las diversas partes que componen el producto con mayor profundidad.

6. El testing depende del contexto

La estrategia y el tipo de pruebas serán seleccionados en función del sistema y a los entornos que se pretenden verificar. Por ejemplo, un software médico no será probado de la misma forma que un sistema de e-commerce.

Los procedimientos estructurados, así como los casos diseñados, serán seleccionados teniendo en consideración todos y cada uno de estos factores.

7. Falacia de ausencia de incidentes

Supongamos que todos los incidentes detectados en un sistema dado son corregidos. A continuación, se realiza un nuevo ciclo de pruebas, tras el cual no se detecta la presencia de nuevos incidentes.

La ausencia de nuevos errores detectados no implica necesariamente que el software sea útil, ya que la utilidad del mismo no es indicada por este parámetro, sino por la satisfacción de las expectativas del cliente que el producto pueda brindar.

---

Conocer y aplicar estos principios nos ayuda a organizar nuestra estrategia de pruebas bajo una perspectiva innovadora y nos proporciona una visión privilegiada, que a su vez nos permitirá desempeñarnos con más precisión y eficacia.

Esperamos que estos fundamentos te sean de mucha utilidad. ¡Síguenos en LinkedIn, Twitter, Facebook, Instagram y YouTube para ser parte de nuestra comunidad y enterarte de otros generalidades del testing de software!

---

Otros contenidos relacionados

Cómo hacer visible el progreso de las pruebas de software

¿Cuáles son los factores de la calidad del software y cómo se prueban?

Mejores prácticas de testing para equipos ágiles: La Pirámide de Automatización

Beneficios de Shift Left Testing en el Ciclo de Desarrollo de Software

---