Ingeniería de Pruebas

Introducción

En un proceso de pruebas formal, suelen confundirse con mucha facilidad, los niveles de pruebas con los tipos de prueba, y a pesar de que se encuentren íntimamente relacionadas, tienen connotaciones diferentes en el proceso. Para entender un poco más, vamos a partir del hecho de que las pruebas pueden ejecutarse en cualquier punto del proceso de desarrollo de software, y es aquí donde los niveles de prueba nos permiten entender con claridad los diferentes puntos o etapas en donde pueden ejecutarse ciertos tipos de prueba. Por lo anterior, es común que algunas personas se refieran a los niveles de pruebas o intenten clasificarlos como: pruebas de desarrollador, pruebas funcionales y pruebas de usuario final.

Desarrollo

Para poder hablar de la ingeniería de pruebas es necesario hacer referencia a tres términos que es común ver como algunas personas utilizan de manera indistinta,los términos Defecto, Falla y Error.

1. Error: Es una equivocación realizada por una persona al desarrollar una actividad de desarrollo de software.
2. Defecto: Se produce cuando una persona comete un error.
3. Falla: Es un desvió respecto del comportamiento esperado del sistema, puede producirse en cualquier etapa.

Notas:Defecto es una vista interna, lo ven los desarrolladores. Falla es una vista externa, la ven los usuarios.

Justificación

1. La realización de tareas de pruebas conlleva un costo asociado que puede inducir a tomar decisiones de no realizarlas.
2. No realizarlas también conlleva un costo asociado.

También es importante diferenciar entre dos conceptos, validación y verificación.

Muchas veces se confunde “verificación” con validación”. Barry W. Boehm (1979) puso en claro con pocas palabras la diferencia:

1. Validación: ¿Estamos construyendo el producto correcto? Se ocupa de controlar si el producto satisface los requerimientos del usuario
   
2. Verificación: ¿Estamos construyendo correctamente el producto? implica controlar que el producto conforma su especificación inicial.
   
   En la Validación el resultado final del desarrollo software se debe ajustar a lo que el usuario quería (sus necesidades). En la mayoría de las ocasiones el producto desarrollado no cumple con la ideas del cliente, normalmente porque a éste suele faltarle capacidad técnica de expresión.
   En la Verificación el código que estamos construyendo debe estar en armonía con la especificación que hemos tomado del usuario. El resultado final del desarrollo software debe concordar con la especificación (requisitos) del sistema, por lo que debemos asegurarnos que el desarrollo final coincida con dicha especificación
   Un sistema puede pasar la validación, sin embargo, no pasa la verificación. Cumple con la especificación del usuario, con lo que él quería, cubre sus necesidades pero internamente puede adolecer de graves detalles como: un precario diseño en la base de datos; uso de un excesivo e innecesario número de líneas de código, por desconocer las potencialidades del lenguaje de desarrollo o de técnicas avanzadas de programación como la POO y uso incorrecto en la BD de instrucciones propias del lenguaje de desarrollo, en lugar de las sentencias adecuadas de SQL.
   
   
   
   Los objetivos de las pruebas son:
   
   • Menores costos.
   • Menores tiempos de desarrollo.
   • Mayor satisfacción del cliente.
   
   
   
   
   En las pruebas de sistema existen siete principios fundamentales que son:
   
   

   Principio 1

   
   "Las pruebas revelan la presencia de bugs, no la ausencia de ellos"
   
   Probar reduce la probabilidad de que existan bugs pero nunca se puede asegurar que no quede ninguno oculto.
   Además, cada tipo de pruebas que realicemos (de sistema, de integración, añadir auditorías de código…) son más efectivas para detectar un tipo de bug.
   
   

   Principio 2

   
   "Es imposible probarlo todo"
   
   El flujo de control de un sistema software no trivial como los que acostumbramos a utilizar en el día a día contiene miles de decisiones.
   Estas decisiones se pueden combinar entre ellas para dar lugar a una infinidad de posibles caminos. De entrada, probar todos los caminos es un problema inabordable.
   Y eso si no tenemos en cuenta la prueba de requisitos no funcionales, como el rendimiento de un sistema ante una exigente carga de usuarios, o requisitos específicos de seguridad (por ejemplo, en un sistema bancario) para protegerse de usuarios malintencionados.
   Todo esto hace necesaria una estrategia de pruebas (un plan) y priorizar a partir de una gestión de riesgos de calidad y de proyecto, y como reza el siguiente principio…
   
   

   Principio 3

   
   "Cuanto antes se comience a probar…mejor"
   
   Corregir un bug con una revisión en la fase de captura de requisitos o en una prueba unitaria tiene un coste mucho menor a lo que costará corregir este bug cuando se detecte en una prueba de sistema, o peor aún, en una prueba de aceptación por el cliente.
   
   

   Principio 4

   
   "Las aglomeración de defectos. ¡Los bugs siempre van en pandilla!"
   
   Entender esto es muy importante para plantear una buena estrategia de pruebas: los bugs suelen ir en grupo. Se concentran en determinados puntos de un sistema software, no manteniendo una distribución uniforme a lo largo del mismo.
   Conclusión: si encuentras un bug en un componente, es muy probable que hayan más. Con lo que una posible estrategia sería centrarse en mejorar las pruebas de aquellos componentes para los que se han reportado un número mayor de bugs, para ser más eficaces a la hora de cazarlos en fases tempranas.
   
   

   Principio 5

   
   "La paradoja del pesticida"
   
   O la necesidad de ajustar continuamente tu plan de pruebas… porque según este principio un plan de pruebas va perdiendo efectividad conforme se ejecuta sucesivas veces. Con lo que cada vez tenderá a encontrar menos bugs… ¡lo que no significa que no hayan! (vuelve a leer el primer principio). Se habla de paradoja del pesticida ya que estos matabichos usualmente sirven para un tipo de bichos, pero una vez no queda ninguno del tipo específico que mata el pesticida… ¡nadie te dice que no hayan otros bichos campando a sus anchas!.
   
   

   Principio 6

   
   "Las pruebas se deben adaptar a necesidades específicas"
   
   Esto viene a enlazar con lo que he comentado antes. Si tu producto se centra en el ámbito de la seguridad deberás adaptar tus casos de prueba para intentar forzar situaciones o posibles escenarios no amistosos. Si quieres probar una intranet donde los servicios más vitales son los de imputación de horas y el de vacaciones, es lógico centrarse en estos servicios y no invertir tiempo en otros componentes infrautilizados.
   Además, hay que tener en cuenta que los recursos en los proyectos son siempre escasos, con lo que en el inicio del proyecto hay que preguntarse… qué estrategia debemos seguir para encontrar y corregir lo antes posible los bugs en las funcionalidades de mayor valor para nuestros usuarios.
   
   

   Principio 7

   
   "La falacia de la ausencia de errores"
   
   Para terminar, nos encontramos con la satisfacción del usuario y con el hecho de que los usuarios elijan tu software para resolver sus necesidades.Que hayas corregido muchos bugs no significa que finalmente tu software sea un éxito. En ocasiones hay que primar un buen time to market, para luego corregir los problemas de calidad que quedaron por el camino. Y esto si se hace de manera consciente y con una buena estrategia, a priori, no debe ser un problema.
   
   
   
   

   Conclusión

   
   
   La Importancia que tienen las pruebas del software de calidad del mismo son de gran utilidad para ver las fallas que presenta el sistema y poder analizar las futuras fallas además de esto también sirven para que cuando entreguemos nuestro software ya finalizado este software este culminado , tenga altos estándares de calidad y esté listo para entregar.
   
   Los Productos Software, sistemas y/o aplicaciones son creadas, desarrolladas e implementadas por seres humanos y por ende en cualquiera de sus etapas de creación se puede presentar una equivocación, al generarse esa “Equivocación” se puede conllevar a un defecto en el software, por ejemplo mala digitación, distracción al codificar, mala elaboración de un documento entre otras. Si no se ha identificado ese defecto y el software o la aplicación se ejecuta, hay un alto riesgo de que la aplicación no haga lo que debería hacer o el objeto para lo cual fue creada, es decir se genera un fallo o desperfecto, lo que podría generar una catástrofe , es importante conocer que los fallos también se pueden presentar por situaciones del entorno, como la radiación, descarga eléctrica, contaminación, inundaciones, Húmeda, Fuego, etc.
   
   Los Ingenieros de sistemas entonces deben estar en la capacidad de conocer y aplicar las diferentes normas, procesos y procedimientos para garantizar la calidad de los productos software, aplicando las pruebas de calidad de software necesarias para que con ellas se pueda ayudar a reducir los riesgos en las aplicaciones, logrando que se identifiquen los defectos antes de que se ejecuten, así de forma proactiva tomar decisiones que permitan hacer las actividades necesarias para mejorar las condiciones del software y ofertar un producto que satisfaga las necesidades del cliente.​
   
   

   Referencias:

   
   
   Mentor,I. (2013). Prubas de Dostware. agosto 27, 2017, de it-Mentor Sitio web: http://materias.fi.uba.ar/7548/PruebasSoftware.pdf
   
   Oriente,J. (2013). Los siete principios de las pruebas software. agosto 27, 2017, de JOR Sitio web: http://joaquinoriente.com/2013/07/20/los-siete-principios-de-las-pruebas-software/