Confirmado próximo entrevistado, es Moises Boullosa que tiene un perfil que, creo, no he entrevistado en este canal. El próximo Lunes empezamos.

También tengo nueva entrevistada para el canal se llama Elena Torro y su entrevista será 31 de Marzo

Disponible nueva entrevista en la newsletter Entrevista en Diferido, ya teneís la de David Baselga.

https://open.substack.com/pub/entrevistasendiferido/p/entrevista-a-david-baselga?r=183x6z&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true

En breve, tenemos directo de Formadores En Tiempos Revueltos tenemos de invitado a Xurxodev
https://www.twitch.tv/cursosdedesarrollo

Publicada la entrevista a Diana Aceves en formato newsletter.

https://open.substack.com/pub/entrevistasendiferido/p/entrevista-a-diana-aceves?r=183x6z&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true

#entrevistaMoisesBoullosa

@moises_boullosa

Empezamos nueva entrevista, esta semana tenemos como entrevistado a Moises Boullosa que tiene un perfil que no ha pasado por el canal, lo mejor es que presente el mismo.

Pero antes....

¿Cómo te encuentras?

Y ahora...
¿Te podrías presentar en una palabras?

@moises_boullosa

Para empezar, unas cuantas preguntas cortas para conocerte mejor a ti y a tu entorno tecnológico.

¿Qué ordenador utilizas habitualmente?
¿Sistema operativo?
¿Qué lenguaje de programación usas?
¿Software imprescindible en todos tu equipo?
¿Cuál ha sido el mejor recurso que has conocido para tu trabajo?

Buenas!

Encantado de participar en esta entrevista en diferido!
Mi nombre completo es un poco largo asi que lo dejo en Moisés Boullosa, trabajo como Software Quality Engineer pero también me apasiona el desarrollo.
Empecé a programar a los 12 años con Macromedia Flash, haciendo animaciones y juegos y continue usándo Flash hasta segundo de la universidad y más o menos en ese año me pasé a hacer programillas con Java.

Me introduje en el mundo de la calidad del Software en las practicas de la universidad, buscando mi primer trabajo entré en el departamento de QA, el cuál para mi empresa en ese entonces también estaba empezando en Valencia. Entre las tareas que tenía, había automatización de pruebas web y me asignaron un programa web para crear las pruebas.
Me parecía un poco limitante así que propuse crear un framework de automatización, el cual fue bien y llegué a crearlo en Java, Javascript, C# y Python.
Además de esto en mi anterior y actual trabajo también llego a tocar cosas de DevOps y superficialmente UI

@moises_boullosa

Pregunta fija en la entrevista que cambia en función del perfil del entrevistado. En tu caso, me centro en calidad de software.

¿Qué añadirías?
¿Qué modificarías?
¿Qué eliminarías?
¿Qué dejarías igual?

@moises_boullosa

Trabajas en calidad de software, cuando leo ese termino imagino gente haciendo test y probando cosas, pero realmente no se si eso o no.

Por eso pregunto.

¿Para qué sirve un departamento de calidad de software?

@moises_boullosa

Hace un tiempo tuve un charla con un amigo desarrollador con varios años de experiencia que le pregunte porque no hacía testing en sus desarrollos y me respondía que era una perdida de tiempo.

¿Es una perdida de tiempo realizar testing?

Añadiría que las personas que hacen calidad del software tuviesen conocimientos medio-básico del sistema que testean.

Modificaría la relación y la comunicación que suele haber entre el equipo de desarrollo y el de calidad. Muchas veces hay roces o malos sentimientos, cuando en realidad deberían de cooperar por ambas partes por el bien del equipo y del producto. Cuando más problemas se han solucionado en los equipos que he trabajado ha sido contactando directamente con el desarrollador por mensajes privados, hablando del problema que he encontrado y dándole la información que he conseguido. Hay productos en los que no puede o no quieren comunicarse directamente entre los equipos y simplemente funcionan a base de tiquets

Eliminaría ciertas formaciones sobre la calidad del software, están un poco anticuadas y no hacen atractivo el sector, sobretodo las materias de la universidad. Entré en calidad porque fue el primer trabajo que encontré y al estar en un departamento que estaba empezando me permitió crecer, poder seguir desarrollando que es lo que me gusta y aprender de calidad del software lo cuál se me da bien al ser perfeccionista. Y terminé teniendo un perfil para el currículum que me valía más seguir en el sector que cambiarme, pero de todos modos ha llegado a gustarme.
Pero en la universidad cuando estudiaba las asignaturas relacionadas con calidad, me parecían un tostón la manera en la que estaba planteado.

Dejaría igual el que siguiese habiendo departamento de calidad, porque hace falta

Pues yo también me imaginaba eso y no me apetecía, también depende de la empresa, del cargo y de los conocimientos de la persona. En mi anterior empresa, una consultora, habían personas que sólo hacían testeo manual y automático y en caja negra. Muchas veces sólo teníamos acceso a producción, en algun caso maravilloso tenían un entorno de preproducción.
Para una situación así no hace falta un perfil con muchos conocimientos de programación, ya que el framework facilitaba los pasos de automatización.

Ese puesto si sería mas que nada hacer tests y probar cosas, sería Quality Assurance (QA).

Por otro lado mi puesto se supone que era lo mismo, pero al ser al principio, no gustarme la aplicación que habían elegido y tener conocimientos de programación creé el framework interno que usaban, que sería un puesto de "Software development engineer in test" que entraría dentro de la parte de calidad.
Además con otro compañero de trabajo configuramos el Jenkins y maquinas virtuales de Google cloud para que al ejecutar pruebas se levantaran maquinas virtuales en el país que necesitacemos usando Selenium para correr varios hilos de pruebas por cada máquina.
Esto serían cosas básicas de Devops

Creé un código para que las pruebas generasen reportes responsive con HTML, CSS y Javascript. De esta manera el resultado era más visual para los clientes.
Esto serían cosas básicas de UI.

Y mi compañero (y amigo de la universidad), creó una base de datos, una API y un bot de telegram que se conectaba a la API para poder recuperar los reportes incluso desde el telegram (también estaban en el Jenkins, pero esto te daba la posibilidad de que cualquiera puediese recibir o enviar los reportes desde el movil). Además de un comando en el telegram para enviar el reporte al cliente por correo.

En mi empresa actual además tengo que hacer más cosas de DevOps, actualmente me estoy peleando con crear un cluster de una máquina con red IPV6 que se conecte a otro dualstack de IPV4 e IPV6 para poder ejecutar pruebas en un entorno de solo IPV6. Además que ahora al tener acceso al código algunas veces cuando encuentro un error busco el lugar exacto del código donde está el error. Viendo el stacktrace, el fallo o buscando en los commits recientes que hayan podido introducir el fallo. Y si es algo rápido y dentro de mis conocimientos lo intento solucionar y sino informo al desarrollador encargado de esa sección.

Además existen las pruebas de rendimiento que también he llegado a hacer, simulando miles de usuarios conectados a la aplicación a la vez y ver los tiempos de respuesta, para saber qué carga soporta el sistema y si realmente está preparado para el uso que se le puede dar.

Y pruebas de seguridad, eso ya es otro agujero de conejo que no he llegado a entrar, pero tiene sustancia.

Y todas estas tareas podrían entrar más en un puestode Quality Engineer (QE), además de a veces tener que revisar documentación, eso si es un tostón.

Un desarrollador muchas veces sólo se ocupa de una parte del producto y como mucho llega a probar que lo que hace funcione.
Pero no prueba todos los casos de uso de lo que programa, la aplicación entera, no prueba a ejecutarla en diferentes partes del mundo, en diferentes dispositivos, navegadores, redes, con mayor cantidad de usuarios, si soporta ataques, la experiencia del usuario.

Respondiendo también a la otra pregunta, todos cometemos errores, incluso aun la IA al programar (probablemente en el futuro sea más fiable). Un desarrollador puede olvidarse quitar una asignación booleana de prueba, cubrir una condición, no crear un algoritmo eficiente en una situación escalable, no saber que Internet explorer no soporta X caracteristica, que para recuperar Y variable en Z sistema operativo se necesita un comando o caracter diferente, que la librería de interfaz gráfica de terceros que usa no soporta bien cuando escribes ciertos carácteres o cuando se muestra en un móvil nuevo que acaba de salir, o que lo que ha hecho ha roto algo que ha desarrollado otro en otra sección, etc.

Mientras más grande y más tiempo lleve la aplicación más casos como estos se van a dar por probabilidad de que fallen las personas al desarrollar. Y más usuarios habrán con más casos por cubrirm

Por lo que un departamento de calidad sirve para asegurar que el producto es de calidad, para aplicaciones pequeñas de pocos usuarios hace falta también, pero darte cuenta puede ser más difícil.
Pero para una aplicación como toca, si quieres hacer algo realmente bien y que no sufran los usuarios (y la economía de la empresa), nunca es una perdida de tiempo realizar un departamento de calidad ni hacer testing (eso si bien hecho).

Para añadir, existiendo la IA de aquí a unos años que sea más fiable la pregunta será, es una pérdida de tiempo realizar desarrollo?
El desarrollo terminará siendo llevado mayormente por IA y lo que hará falta será un departamento de calidad con personas para comprobar que ño que está hecho está bien.

Llegar a un punto que la IA lo haga tan bien que ni querramos testear productos grandes que haya hecho, lo veo más lejos. Siempre estará el "y si hay algo mal?"

@moises_boullosa

En la primera respuestas has indicado que has desarrollado un framework para automatización porque lo que había era muy limitante.

¿Cuál son esas limitaciones que te encontrabas?

Hay varias herramientas para esas tareas y algunas son Software libre

¿Por que no apoyar una de esas herramientas para configurarla a tus gustos en vez de crear una framework propio?

@moises_boullosa

La siguiente pregunta es de un lector de la entrevista.

Hola Moisés
Soy programador y desde hace mucho abogo por los departamentos/roles de QA en mis proyectos, pero la realidad es que siempre sois vistos como innecesarios o como los "porculeros" que vais tirando por tierra los desarrollos porque no cumplen los estándares 😊

¿Cómo se lleva eso de ser el "poli malo"?

Entiendo que las reuniones con los diferentes equipos de desarrollo deben ser muchas veces un tanto desagradables, ¿no?

P.D. Os necesitamos y os queremos QA 😘

Muchas de esas herramientas usan como base Selenium, Protractor o alguna libreria por el estilo, y ponen la capa del framework por encima sin dar acceso a la base, crean sus propias funciones (las que creen que son necesarias) y métodos de llamadas.

Y suele pasar que no dan soporte a todos los navegadores, al menos los mas usados (cuando las librerias base si), que les faltan funciones útiles (que tal vez si no conoces las librerias bases no sabes de lo que te estas perdiendo) y no te dan acceso a los objetos de la libreria base para que las uses si quieres.

En el caso del framework o aplicación con la que empecé, creo que fue Ghost Inspector, no estoy seguro. Pero creabas las pruebas desde una web, tenias tus pasos predefinidos y la mayoría de las veces tenia que usar la opción del paso predefinido de usar código de Javascript para hacer comprobaciones de estado.
Aun asi ese no será muy conocido, pero Cypress es bastante conocido y usado y también tiene sus problemas, (que cuando yo hice el framework interno Cypress daba soporte sólo a Chrome). No da soporte a aplicaciones nativas de móviles y si quieres hacer comprobaciones complejas es un lio de promesas y faltan algunas funcionalidades que las librerias bases proveen.
Lo único que me gusta de Cypress es Cypress Cloud.

Al final crear una aplicación cuando ya hay otras puede sonar a reinventar la rueda, pero a veces pasa que las aplicaciones que hay no dan las funcionalidades que necesitas y las que las dan tienen restricciones que o molestan o tal vez no te permiten realizar acciones especificas para tu caso.
Cuando hice el framework interno muchas de los frameworks que habian tenian muchas carencias que para una situación general como era una consultora, que recibes clientes con diferentes requisitos, no valen. Ahora siguen habiendo carencias o problemas como estos de Cypress, y me sigue pareciendo mejor usar las librerias base aunque te tengas que hacer un framework, que usar una aplicación con capas restrictivas , métodos de llamada complejas y falta de funcionalidades.

Al menos si realmente quieres hacer tests que cubran variedad de casos, si lo que quieres son smoke tests, Cypress o alguna otra están genial.

Mensaje 1/2

Esto es a lo que me referia que modificaría, yo personalmente no lo he vivido, ya que en mi primera empresa era una consultora y no teniamos comunicación con el equipo de desarrollo del cliente. Y en mi empresa actual son todos profesionales con experiencia y no llegan a ocurrir estas situaciones.

La respuesta fácil a que el departamento de calidad sea visto como "porculeros" que tiran por tierra los desarrollos porque no cumplen los estándares, es obvia, los desarrollos deberían de cumplir los estándares.

Ese problema tiene varios fallos:

Por un lado el administrativo:
Hay un tiempo correcto planificado para la validación, verificación y corrección en caso de que se tuviese que hacer?
Una buena planificación de entrega debe incluir un tiempo adecuado para poder comprobar que la versión a entregar está en buen estado, y que si hay errores haya tiempo para solucionarlos, de esta manera se puede cumplir la fecha de entrega.
No se puede poner una fecha de entrega que sea la misma en la que se empiecen las comprobaciones, o que no incluya el tiempo para que terminen las comprobaciones y dejar un tiempo prudente para que se solucionen los problemas que puedan haber.
La planificación se hizo bien?
Se debe planificar la cantidad correcta de trabajo para los desarrolladores para asegurar que lleguen a tiempo, y en las reuniones semanales o de sprints se debe comprobar que va todo de acuerdo a lo planificado, sino modificar la carga de trabajo para que el tiempo de desarrollo no se coma el tiempo planificado para la comprobación y la corrección
Los estándares son correctos?
Algunas veces si no da tiempo a la fecha de entrega y es algo prioritario hay que valorar la urgencia y riesgo de los errores encontrados. A veces hay pequeños errores de casos muy espeficos que puede que el usuario no se encuentre y no sean graves, si realmente es prioritario cumplir la fecha de entrega por algun motivo superior el estandar puede ser dejar pasar esos errores y agregarlos al siguiente Sprint.

Si todo esto está correcto, que en muchas empresas no depende del departamento de calidad, temo decirle a los que dicen que les tiran por tierra sus desarrollos que su trabajo no cumple los estándares. Si alguien fabrica un juguete para bebes, que se rompe fácil dejando una parte afilada, no creo que se vaya a quejar al departamento de calidad de por qué no le deja entregar ese producto, si el producto no cumple el estándar de calidad definido no debería de salir al público ya que como poco terminará dañando la imagen del producto y la empresa haciendola perder dinero. Y ya si el producto puede tener riesgo para las vidas, arriesgas la salud de los usuarios.

Mensaje 2/2

Y esto de llamar "porculeros", que "tiran por tierra los desarrollos" o "poli malo" lleva al siguiente fallo, el humano o psicológico y la cultura de la empresa.
En muchas empresas, sobretodo las pequeñas, hay miembros de la parte administrativa y/o del equipo de desarrolladores sin experiencia (no me refiero a programando sino al mundo de producción de software). Y piensan del departamento de calidad como una posición inferior, cuando son todos compañeros al mismo nivel y tienen el mismo objetivo, sacar un buen producto.
Y también entra el juego el ego de las personas, a veces el desarrollador no le gusta que le digan que ha cometido un error y se molesta y culpa al de calidad, si el error está ahí no es culpa del que lo ha encontrado, esa persona sólo hace su trabajo de comprobar que está todo bien. Y el desarrollador tampoco se debe tomar a mal el haber cometido un error, todos cometemos errores y por eso está el departamento de calidad. ¿Quién comprueba al departamento de calidad? Ahí también se cometen errores, se pueden crean pruebas que no son eficientes, redundantes, pueden faltar otras, las mismas pruebas pueden tener errores de programación.
Pero el producto final no son las pruebas, al final no importan los errores ni quien los haga, importa que el producto que le llega al usuario no tenga errores, o al menos los mínimos posibles.

Por otra parte los del departamento de calidad también tienen que tener tacto al notificar los errores, también puede llegar a haber ego allí y resaltar con más enfásis del que hace falta que se ha encontrado un error. Hay que tener respeto tanto al notificar los errores encontrados como al recibir las notificaciones de tus errores, los del departamento de calidad también viene bien que tengan don de gente.

En una cultura de producto correcta no hay "poli malo", el desarrollador hace su trabajo de crear la funcionalidad, el del departamento de calidad hace el suyo de comprobar si todo está bien. Si encuentra un error lo reporta y el desarrollador lo arregla. No tiene por qué ser una pelea.

En mi actual producto en nigún momento me siento como el "poli malo" ni que haya mala relación con los de desarrollo, nos veo como un equipo que marca en la misma meta.

@moises_boullosa

Ves mucho código de otra gente y no te he preguntado...

¿Cómo es la calidad del código que ves habitualmente?