Imagínate un proyecto en el que la calidad del código no es la mayor prioridad. ¿Qué es entonces?, te preguntarías. Los cinco primeros suelen ser:
- Características.
- Mercado.
- Competencia.
- Clientela.
- Ingresos.
El primer problema
Para los managers, todo lo anterior es prioritario hasta que sucede un error grave en producción. Lo que viene a continuación: pérdidas de ingresos, pérdidas de reputación, interrupciones prolongadas y una disminución significativa de la confianza.
En este punto, las empresas tienden a detenerse, mirar a su alrededor y pensar en esta brillante idea: “Contratemos un experto en Calidad de Software”. Aunque el concepto en sí no está mal, generalmente hay más que solucionar que solo un problema de personal.
El problema es que las empresas, que nunca han prestado mucha atención a la calidad de sus productos y se centran en los lanzamientos de nuevas funciones, asumen que contratar a una persona resolverá todos los problemas de calidad de la organización.
Mi experiencia en proyectos demuestra que un solo Tester no incrementará la calidad de su producto.
Cómo producir un buen software
Detengámonos aquí por un momento. ¿Qué es un producto de software? Generalizando, es un concepto: código y una combinación de marketing. Suponiendo que cuando una empresa desea publicitar y vender el producto, este debe ser bueno. No solo está bien promocionado, sino que también se basa en una buena codificación.
El código que se considera bueno cuando:
- Hace lo que debería.
- Sigue un estilo consistente.
- Es fácil de entender.
- Ha sido bien documentado.
- Puede probarse.
Como puede ver, el acto de probar es solo una pieza del rompecabezas.
Una buena codificación hace una buena aplicación. Es por eso que las empresas contratan a los mejores ingenieros de software, les pagan buenos salarios y se benefician de sus conocimientos.
No significa que cuando la empresa emplea buenos desarrolladores, su proyecto no necesita analistas de calidad; probablemente lo haga.
El mayor obstáculo para la calidad del proyecto no es la falta de QAs; es la falta de voluntad de aprender. El aprendizaje continuo requiere ciclos de retroalimentación, donde las pruebas juegan un papel clave.
El Tester
Un Tester, un Ingeniero de Calidad, un Especialista en Aseguramiento de la Calidad (QA: Quality Assurance) o como usted nombre el rol, pueden orientarlo en la dirección correcta. Enfatice las fallas en el proceso, discuta las malas prácticas y adopte algunos cambios positivos.Desafortunadamente, solo sucederá cuando permita la calidad en el proyecto. Cuando contrata solo a un QA Junior para ahorrar dinero y contar con resultados espectaculares, es posible que se sorprenda.
Me gusta este dicho:
«Si las buenas pruebas son caras, pruebe las malas» – Kinga Witko.
No hay que pensar únicamente en el salario del Tester (que, no debe diferir del Desarrollador; son un equipo); la buena calidad es cara porque lleva tiempo. La buena calidad del software ayuda a que el proyecto se ejecute en la dirección correcta y evite fallas importantes del sistema, pero es costoso.
¿Por qué?
Cuando la calidad es lo primero:
- Los desarrolladores dedican más tiempo a la codificación porque primero discuten las mejores soluciones.
- Hay pruebas unitarias junto al código de la aplicación. 💡 Quizás te interese leer el artículo: ¿Por qué la cobertura de pruebas unitarias es una parte importante de QA?
- Existe una infraestructura, en el pipeline de CI/CD, que permite realizar pruebas automatizadas antes de pasar a producción.
- Siempre hay posibilidad de mejora.
- Los desarrolladores trabajan a la par del QA para atrapar los errores obvios sobre la marcha y aprender unos de otros. 💡 Quizás te interese leer el artículo: ¿Por qué la ejecución aleatoria es una oportunidad para mejorar las Pruebas Unitarias?
- LOS EQUIPOS ESTIMAN las tareas, teniendo en cuenta la calidad y los riesgos.
- Los riesgos potenciales en los sistemas SE MINIMIZAN, no se dejan solos.
💡 Quizás te interese leer el artículo: Las cinco métricas de código para mejorar la calidad del software.
Conclusiones
Finalmente, la aplicación se prueba no solo mediante una prueba automática o manual, sino mediante el conjunto de diferentes escenarios de pruebas unitarias, funcionales y no funcionales. Las pruebas se revisan, ajustan y observan periódicamente.
Suena idílico, ¿verdad?
Entonces, cuando escucho “contratemos a un Tester para mejorar la calidad de nuestro producto”, comprendo y no comprendo al mismo tiempo. El Tester por si solo no es capaz de incrementar la calidad del proyecto de software, requiere que esta idea de Calidad esté interiorizada en todo el proyecto, pues la calidad es responsabilidad de todo el equipo.
La calidad lleva tiempo, Y ESO ESTÁ BIEN.
Fuentes
The Tester will not leverage the quality of your project por Kinga Witko.
Foto por Maxim Hopman en Unsplash.