7 principios de las pruebas de calidad de software
!Hola!
En este
artículo les hablaré sobre los siete principios de pruebas de software según la
ISTQB (International Software Testing Qualifications Board). Conocer estos principios
es de suma importancia, ya que nos ayudan a disponer de una mejor distribución de
tiempo y esfuerzo, además, contribuyen en la obtención de resultados óptimos centrándonos
en alcanzar los objetivos de las pruebas de software permitiéndonos diseñar una
mejor estrategia de pruebas.
De manera
detallada los siete principios de prueba son:
1- Las pruebas de software demuestran
la existencia de defectos no su ausencia.
Al realizar pruebas rebelamos los defectos que en cierto punto fueron ignorados inconscientemente o fueron generados por un error y, si se da el caso contrario, es decir, no se encontraron defectos, no significa que no existan, puede que las pruebas efectuadas sobre el producto no lograran alcanzar dichos defectos.
2- No se puede probar todo.
Es imposible ejecutar pruebas exhaustivas, no es factible probarlo todo con todas las combinaciones válidas e inválidas de los datos de pruebas. Como probadores buscamos alcanzar la cantidad óptima de pruebas basándonos en el análisis de riesgo del proyecto o en la prioridad.
Realizar pruebas exhaustivas precisa de tiempo y esfuerzo que terminan siendo inefectivos, además las pruebas deben adaptarse al cronograma del proyecto, por ello es recomendable utilizar técnicas que nos permitan obtener datos de prueba que cubran un grupo mayor, algunas de estas técnicas podrían ser las tablas de decisión, la partición de equivalencia o el análisis de valores límites.
3- Las pruebas se realizan desde el inicio
Si te preguntaran en qué fase del ciclo de vida de desarrollo de
software se deben realizar las pruebas tomando en cuenta la siguiente imagen:
¿Cuál sería tu respuesta?.
Si tu respuesta es “Las pruebas deben ejecutarse en la fase de prueba”, permite decirte que no es adecuado pensar de esta manera, según este principio los correcto es ejecutar las pruebas desde el inicio hasta el final, es decir, se realizan pruebas de software en todas las etapas del ciclo de vida de desarrollo de software.
Ejecutar pruebas desde el principio ahorra tiempo, dinero y esfuerzo, la detección temprana de defecto permite reducir el riesgo de que aumenten los costos, mientras más lejos se llega con un defecto más costoso será repararlo.
4- Los defectos se agrupan.
En ocasiones puede darse el caso de que la mayoría de los defectos se encuentren en una pequeña cantidad de módulos, cumpliéndose así el principio de Pareto que dice “el 80% de los problemas se encuentran en el 20% de los módulos”.
Esto puede darse cuando se trata de una sección que ha sufrido varios cambios, su nivel de complejidad de desarrollo es alto o quizás a la falibilidad humana (todos cometemos errores), también puede deberse a la vinculación de sistemas, es decir, al intentar integra un sistema con otro.
Es importante localizar la causa raíz de los defectos para disminuir el riesgo de que estos aumenten, mientras más defectos encontremos y reparemos habrá mayor probabilidad de entregar un producto de calidad.
5- Los casos de prueba se deben actualizar.
Para entender este principio hablemos de la paradoja del pesticida “Si siempre aplicamos el mismo pesticida una y otra vez en la misma área llegará un punto en que este no tendrá ningún efecto sobre ella”, ahora llevemos esta paradoja a las pruebas de software, si aplicamos el mismo set de casos de prueba una y otra vez a un producto no seremos capases de encontrar nuevos defectos.
Para evitar caer en esta paradoja lo recomendable es actualizar frecuentemente los casos de prueba, agregar nuevos y descartar esos casos que ya no nos permiten encontrar defectos, las mejoras constantes permitirá alcanzar un mayor nivel de calidad.
6- Las pruebas se realizan de acuerdo con el sistema que se está desarrollando.
Las pruebas de software se planifican de acuerdo con el contexto, no es lo mismo efectuar pruebas para una aplicación móvil destinada a la reproducción de videos, que ejecutar pruebas en el sistema de gestión de un hospital, claramente el nivel de riesgo en estos ejemplos es distinto, y este es un factor primordial a la hora de definir nuestra estrategia de pruebas.
Además del riesgo, la metodología de desarrollo a utilizar también es un factor determínate a la hora de planificar las pruebas, en un proyecto que utiliza una metodología ágil, como por ejemplo scrum no se realizan las pruebas de la misma forma que en uno que implementa una metodología tradicional como el modelo en cascada.
Es importante tomar este principio en cuanta a la hora de estimar el tiempo que tomara ejecutar las pruebas de software, este debe adaptarse al cronograma del proyecto.
7- Es imposible la ausencia de errores.
Si bien el objetivo de las pruebas de software es encontrar defectos, no se puede probar todo, por lo que entregar un producto sin defectos es prácticamente imposible ¡ojo! Esto no quiere decir que no se debe trabajar para encontrar y reparar la mayor cantidad de defectos posible de manera que se pueda entregar un producto que cumpla con lo que el cliente pido y con lo que este necesita.
Recuerda las pruebas no se tratan solo de encontrar errores, sino también de asegurarse de que el producto final entregado cumpla con las expectativas del usuario en la mayor medida posible. A demás debemos buscar que los sistemas que desarrollemos este por encima o como mínimo a la par de otros productos similares, pero nunca por debajo, como probadores buscamos siempre entregar el artículo de mejor calidad.
Seguir estos principios nos permitirá mejorar la calidad de los servicios que bridamos, y como consecuencia aumentar el nivel de confianza que tienen nuestros clientes con y hacia nosotros.
Esto es todo por hoy, espero que este artículo te haya servido ya sea
que estés empezando o seas un experto en el área, te invito a compartirlo con
tus amigos y colegas, si tienes alguna pregunta u observación sobre el tema no
dudes en dejarlo en la sección de comentarios.
Si deseas revisar los principios originales, puedes leer el libro
(Foundation
Level Syllabus) que
puedes encontrar en la página del ISTQB.ORG
¡Gracias por leer!
¡Sígueme en Linkedin https://www.linkedin.com/in/betania-jimenez-7b6b02167/!
No entiendo nada pero me agrada la iniciativa
ResponderBorrarSi tienes alguna pregunta sobre el tema será un placer darle respuesta
Borrarexcelente muy bueno, me gusta como explica detalladamente.
ResponderBorrarGracias, me alegra que te haya gustado
BorrarTe agradecería mucho mas, si subiera una parte hablando sobre el ciclo de vida del desarrollo del software en específico, please.
ResponderBorrarAquí está su pedido: https://bettyscode.blogspot.com/2022/02/ciclo-de-vida-de-desarrollo-de-software.html
BorrarEspero te sea de utilidad 😊
Gracias, me ah gustado mucho tu contenido.
ResponderBorrar