Mind the gap!

Alex Todorov

Fundador y responsable de QA en Kiwi TCMS

No hay duda de que la tecnología está cambiando el mundo. En las últimas dos décadas, he sido testigo de la adopción generalizada de Linux y el código abierto, el cambio a cargas de trabajo virtualizadas -> computación en la nube -> contenedores y la proliferación de al menos una docena de lenguajes de programación diferentes. Luego vinieron las redes sociales masivas con millones y miles de millones de usuarios. Luego, Internet de las cosas y dispositivos inteligentes en todas partes, criptomonedas y redes blockchain por todas partes, y recientemente la explosión del aprendizaje automático e inteligencia artificial. ¡La próxima frontera es probablemente el espacio! O más bien debería decir que, para algunos equipos con los que estoy en contacto, probar hardware y software en el espacio ya es parte de su negocio diario.

Todos estos sistemas se están volviendo más grandes y/o más complejos y requieren cada vez más pruebas. Los requisitos para las pruebas también se vuelven más complejos: "shift-left" (mover hacia la izquierda), escribir más automatización, crear tus propias herramientas personalizadas, probar problemas de seguridad, realizar pruebas y monitoreo junto con DevOps, etc.

Los límites para las pruebas se vuelven cada vez más borrosos: ¿es un problema de software o de hardware? ¿Debo probar mi propio producto o toda la pila en la que depende? ¿Cómo manejo los servicios de terceros? ¿Cuántos y cuáles lenguajes de programación, herramientas y marcos de prueba debo conocer? ¿Cuánto debo entender sobre Linux, DevOps, arquitectura de software y hardware, algoritmos de criptografía, etc., etc.?

Nosotros, los testers, somos afortunados de estar en medio de todo esto; sin embargo, tenemos un problema. Un número relativamente pequeño de individuos son los que realmente están "migrando hacia la izquierda", trabajando al mismo nivel que los desarrolladores, escribiendo todo tipo de pruebas y gestionando su propia infraestructura como código, haciendo pruebas en producción, creando sus propias herramientas de prueba, etc. El año pasado, en la conferencia Test Automation Days, Bas Dijkstra compartió su visión sobre el tema "¿Realmente necesitamos un ingeniero de automatización de pruebas?". Resulta que necesitamos múltiples ingenieros para cubrir todos los requisitos de las pruebas en la actualidad. Aún así, todo el tiempo veo a personas que parecen tener una comprensión menos completa de toda esta tecnología. Son aquellos que parecen estar "migrando hacia la derecha", que luchan con los lenguajes de programación y carecen de fluidez diaria con las herramientas del oficio en toda la pila tecnológica.

Contratar ingenieros de pruebas para cualquier producto complejo, lo que yo clasificaría como "un producto de infraestructura", se ha vuelto imposible. En los últimos dos años, he hablado con equipos en los campos de la cadena de bloques y la criptografía que no podían encontrar ingenieros de pruebas. No es el entorno más difícil, pero requiere un cierto nivel de comprensión de los principios básicos y cierta familiaridad con lenguajes de programación de bajo nivel.

Que un tester posea un conocimiento profundo y una comprensión de los principios fundamentales de cómo funciona la informática moderna es una habilidad muy preciada. Sin embargo, es raro encontrarla incluso entre los desarrolladores, por lo que recurrimos a soluciones técnicas: nuevos lenguajes y marcos cuando los antiguos no funcionan, soluciones sin código o con código bajo, asistentes de inteligencia artificial, más reuniones y, por supuesto, más automatización. Esto solo sirve para oscurecer el problema real y ocultarlo bajo capas de abstracción. No ayuda al tester individual a superar sus limitaciones y adquirir el conocimiento que le falta.

Existen muchas razones por las que enfrentamos los desafíos mencionados anteriormente; es un tema complejo con múltiples ángulos. Una razón es que hay muchas personas que se vieron obligadas a alejarse de otros trabajos tradicionales para mejorar su calidad de vida. ¿Qué paga mejor? TI. ¿Cuál es la forma más fácil de entrar en TI? ¡Pruebas! Esto es especialmente visible en Europa del Este y en los Balcanes, pero mis experiencias de viaje me llevan a creer que es una tendencia en todas partes. Entonces, ¿cómo resolvemos esto? ¿Cómo ayudamos a los testers a aprender lo que no saben?

Aparte de usar mi plataforma para plantear estas preguntas e intentar inspirar a otros a atreverse en el mundo de la automatización de pruebas, mi humilde contribución es organizar talleres prácticos en diversas conferencias y enseñar habilidades básicas prácticas, como trabajar con Linux y git, programar en Python, comprender los árboles de sintaxis abstracta y cómo funcionan las herramientas de análisis estático en el desarrollo y las pruebas. En mi opinión, entender la complejidad del mundo tecnológico actual implica adquirir habilidades fundamentales y aplicar el método de ingeniería en cada paso del camino.

En QA&TEST Embedded (organizada por la empresa SQS y celebrada en Bilbao), presentaré un tema llamativo sobre pruebas de caja negra con hardware del mundo real. Además del aspecto exploratorio de las cajas y el elemento de diversión en la presentación, tocaré un tema interesante: los sesgos psicológicos que dificultan que nosotros, las personas, trabajemos en el mundo tecnológico. Mi charla y mi hardware se inspiraron parcialmente en la presentación de Andrew Brown sobre habilidades de razonamiento dentro de las pruebas de software hace algunos años. 

Noticias Relacionadas: