¿Que es Quality Engineering?

La ingeniería de calidad se centra en garantizar que los productos de software sean confiables, funcionales y cumplan con las expectativas del usuario. En un mundo cada vez más dependiente de la tecnología, la calidad del software es esencial.

¿Porque es necesario aplicar Quality Engineering?

En palabras simples genera confianza de un producto, genera valor.

El acto de no abordar adecuadamente la calidad en el desarrollo de software puede tener consecuencias negativas. Puede llevar a una serie de problemas, como:

• Errores Costosos: La corrección de errores en etapas avanzadas del desarrollo puede ser costosa y retrasar el lanzamiento.
• Daño a la Reputación: Los usuarios experimentan frustración y pérdida de confianza si encuentran problemas en una aplicación.
• Pérdida de Negocios: Los errores graves pueden llevar a la pérdida de clientes y oportunidades de negocio.
• Inseguridad de Datos: La falta de seguridad en el software puede exponer datos sensibles de los usuarios.

La palabra “Testing” podemos entenderla como una acción.
Mientras que Quality Engineering (QE) es la ciencia, la metodología, aquella serie de pasos necesarios para aplicarla efectivamente.

A detalle

Existen principios para realizar las pruebas a un producto o software, son las siguientes:

1. Las pruebas muestra la presencia de defectos, no su ausencia.
2. Las pruebas exhaustivas es impracticable.
3. Las pruebas en etapa temprana ahorra recursos.
4. Los defectos se agrupan.
5. La Paradoja del Pesticida.
6. Las pruebas son dependientes del contexto.
7. La ausencia de errores es una falacia.

Las pruebas muestra la presencia de defectos, no su ausencia

"Testing shows the presence of defects, not their absence“

Este principio nos recuerda que las pruebas tienen una función crítica: revelar la existencia de defectos en el software. Sin embargo, es crucial entender que, sin importar cuántas pruebas realicemos y cuántos defectos encontremos, no podemos afirmar con certeza que no haya más defectos ocultos.

Las pruebas exhaustivas es impracticable

"Exhaustive Testing is impossible"

En este punto lo que significa probar todas las combinaciones posibles de entradas y condiciones previas, generalmente no es factible ni eficiente. Si consideramos todas las variables y combinaciones posibles, la cantidad de pruebas necesarias sería astronómica y requeriría un tiempo y recursos infinitos.

Las pruebas en etapa temprana ahorra recursos

"Early Testing saves time and money"

La idea central es que identificar y abordar defectos en las etapas iniciales del desarrollo no solo reduce la carga de las correcciones posteriores, sino que también ahorra tiempo y recursos valiosos como el monetario.

Los defectos se agrupan

"Defects Cluster Together"

Esto significa que es más probable encontrar múltiples defectos en un componente o módulo específico en lugar de encontrar defectos en todos los componentes de manera uniforme.

La Paradoja del Pesticida

"Beware of Pesticide Paradox"

La Paradoja del Pesticida se refiere al hecho de que, si se repiten las mismas pruebas una y otra vez sin cambios, con el tiempo, esas pruebas dejarán de ser efectivas para encontrar nuevos defectos.

Las pruebas son dependientes del contexto

"Testing is context dependent“

No existe una única metodología de pruebas que sea aplicable universalmente. En cambio, las decisiones de pruebas deben basarse en las características específicas del proyecto, los objetivos, los recursos disponibles y las necesidades

La ausencia de errores es una falacia

"Absence-of-Error is a fallacy“

Este principio pone de relieve la importancia de comprender y validar los requisitos y expectativas del usuario final. El testing no debe limitarse a la búsqueda de defectos técnicos, sino que debe centrarse en garantizar que el software satisfaga las necesidades y deseos del usuario.