«La calidad nunca es un accidente; siempre es el resultado de una intención elevada, un esfuerzo sincero, una dirección inteligente y una ejecución hábil»
Jhon Ruskin
¿Puedo decidir no invertir tantos recursos y tiempo en la calidad de un producto de software? ¿Se cumplirán las expectativas del cliente al planificar, diseñar y ejecutar tareas de pruebas con el único propósito de comprobar la calidad de nuestro producto?
Puede que no sea tan simple responder a estas dos interrogantes que quizás en algún momento os hayáis hecho mientras planificáis vuestro proyecto o peor aún cuando os enfrentáis a una fecha próxima de entrega y no habéis terminado el desarrollo.
La necesidad de hacer pruebas de software se hace palpable para garantizar la calidad del producto.

Si el desarrollo de un producto de software se encuentra en su etapa final, el proyecto se queda sin presupuesto y sin tiempo para poder entregar el producto en la fecha acordada con el cliente, entonces uno de los aspectos que podría sacrificarse serían las pruebas pendientes de culminar si previamente no se tomaron medidas para mitigar este problema.
¿Invertir o no invertir en la calidad?
El cliente, la organización o el jefe del proyecto llegados a este punto, podrían decidir no invertir recursos del proyecto y pasar por alto la necesidad de hacer pruebas.
Podría tratar de validar toda la funcionalidad del producto o aumentar el costo del proyecto al contratar especialistas de prueba externos. Tampoco sacrificarían el cumplimiento del tiempo de entrega porque el equipo de pruebas aún no ha terminado todas sus actividades de prueba en el proyecto.
Pero, ¿y si se hubiese previsto este escenario desde un inicio? ¿y si las actividades de pruebas se hubiesen planificado con antelación? ¿y si estas actividades se hubiesen iniciado desde etapas tempranas del desarrollo?

Probando todo lo que sea posible
Digamos que nos encontramos en una organización o somos parte de un cliente que es consciente de los riesgos que podrían enfrentar si no se invierte adecuadamente en la calidad del producto o en la calidad del proceso de desarrollo.
Probablemente, se incluyan probadores, especialistas de pruebas o incluso un administrador de pruebas al equipo de desarrollo como responsables de comprobar la calidad del producto final a través de la planificación, el diseño y la implementación de actividades de prueba.
No obstante, aunque este equipo ejecute todo el conjunto de pruebas disponible, identifique la mayor cantidad de defectos y certifique que el producto está listo para ser liberado, este podría no ser funcional al cliente, podría no cumplir con sus expectativas, podría no ser usable.

El proyecto, la organización o el propio cliente pueden decidir no invertir demasiados recursos en el proceso de pruebas. A fin de cuentas «si no hay Desarrolladores no hay un software desarrollado». Es aquí entonces donde el probador, el QA o el tester, pierde su capacidad de aportar valor al proyecto.
¿Y si nos enfocamos en lo que realmente necesitamos?
En ciertos casos, la necesidad de hacer pruebas se reflejará únicamente con unas pruebas exploratorias sencillas en producción, en otros se deberán ejecutar pruebas exhaustivas a distintos niveles. Sin embargo, en no pocos casos serán necesarios distintos tipos de pruebas tanto funcionales como no funcionales de seguridad, usabilidad o rendimiento.
Cada producto es diferente y cada cliente u organización tiene su propia filosofía de trabajo. Ejecutar pruebas generará en todos los casos una mayor confianza en la calidad del producto final, propiciará la toma de decisiones a la administración del proyecto. También calmará la incertidumbre sobre el proceso de desarrollo en sí y permitirá al usuario disfrutar de un producto adecuado a sus necesidades.
Gracias por leer nuestro artículo, si tienes algo más que aportar te leo en los comentarios 🙂
Síguenos en nuestras redes sociales para más contenido:

Deja una respuesta
Lo siento, debes estar conectado para publicar un comentario.