Con el interés en la transformación digital y el auge del agilismo, han aparecido una gran variedad de roles en torno al desarrollo de software. Algunos son totalmente nuevos, y otros, como el SDET, evoluciones o híbridos de otros ya existentes.
Se dice que el SDET (Software Development Engineer in Test) no es, ni más ni menos, que lo que su nombre indica: un desarrollador de software que se dedica a las pruebas, o… un rol híbrido entre desarrollador y tester, o… un automatizador de pruebas o… ¿es algo más?
El mito
Si hacemos una búsqueda en internet, vamos a encontrar cientos de artículos teorizando sobre lo que debe ser un SDET. Aquí van algunos puntos comunes:
- Sabe automatizar. En Java, en Python, en Javascript, web, móvil, apis… cualquier plataforma en cualquier lenguaje.
- Sabe BDD, TDD, DDD, ATDD, XP, SOLID… y todas las demás siglas y palabros que se te ocurran. Y es capaz de implementarlas en cualquier equipo.
- Revisa código y detecta errores. Te escribe los test unitarios. También los corrige con una sola mano… ¡Y con la otra automatiza!
- Es un experto en servicios SOAP y REST. Usa Postman, y REST-assured, y Karate, y SoapUI, y JMeter. Porque saber usar 5 herramientas diferentes para hacer lo mismo aunque ni siquiera estén pensadas para ello es absolutamente necesario…
- ¡Hace pruebas de seguridad! Ya no harán falta esos carísimos departamentos de ciberseguridad.
- Hace pruebas de rendimiento. Nivel experto. Además las automatiza para después.
- Es un experto en diseño. Como si tuviera un máster, y además se sabe de memoria cada combinación de la paleta de colores del Material Design.
- Conoce el sistema al completo, no sólo la parte funcional, y está implicado en todo el ciclo del desarrollo de software. ¿Arquitectos, para qué?
- Hace pruebas de accesibilidad con los ojos cerrados.
- Monta entornos de pruebas, juegos de datos, pipelines, maneja bases de datos relacionales y no relacionales, crea reglas personalizadas de análisis estático de código… Y un largo etcétera. Por cierto, ¿he dicho ya que automatiza?
“En este post no hablamos de unicornios”
Cuando leemos todo esto, podemos intuir que son requisitos que no se ajustan a la realidad. No es posible ser un experto en todos los ámbitos, y sugerir esto lleva al error de pensar que contar con un “SDET”, si es que encuentras alguno como el descrito, va a tapar todos los agujeros que tiene un equipo.
Ahora que conocemos un poco más sobre los mitos que envuelven al rol y sobre lo que NO es, y antes de dar unos trazos sobre lo que sí es importante sobre un SDET, vamos a ponernos un poco en contexto.
¿Por qué SDET?
No vamos a hacer una disertación sobre el contexto actual en el ámbito del desarrollo de software, pero vamos a quedarnos con 3 puntos importantes:
- Se trabaja con agilidad y flexibilidad. O se intenta.
- Se buscan equipos multidisciplinares con profesionales capaces de trabajar de forma autosuficiente, pero en un marco de colaboración.
- Se busca automatizar procesos y optimizar recursos.
“Ya no vale con darle al botón y ver si se rompe”
Si tomamos estos 3 puntos de referencia y pensamos en la calidad, podemos ver que el rol clásico de testing empieza a quedarse un poco obsoleto.
Y pensaremos… bueno, quizás esto se soluciona si el tester sabe programar, ¿no? Hemos visto una tendencia en la que la “evolución” del tester ha sido adquirir conocimientos técnicos.
Empieza por automatizar, o incluso meterse a hacer alguna prueba de rendimiento, o de seguridad, o puede que incluso se aventure en github y se descargue el código del desarrollador para verlo y pueda aportar algo relevante.
Todo esto está muy bien, pero deja fuera un aspecto muy importante. El responsable de la calidad ya no es únicamente una persona, sino que es una responsabilidad del equipo, de principio a fin y en todas las iteraciones e incrementos del producto.
Entonces… ¿qué es lo que necesito en mi equipo?, ¿ya no me hace falta un tester?, ¿mejor que pruebe un desarrollador, o alguien de negocio?, ¿probamos todos porque la calidad depende de todo el equipo?
Pues… nada de esto. Vamos a ver lo que un SDET puede aportar a un equipo.
Ahora sí, ¿qué es un SDET?
Vamos a dejarnos de rodeos. Un SDET es un rol técnico orientado a pruebas, y además un facilitador que ayuda a su equipo a encontrar la estrategia y las herramientas adecuadas para entregar un desarrollo de calidad.
Y ahora pensaremos… vale, pero… ¿qué hace realmente?, ¿qué tiene que saber?, ¿¿¿automatiza o no???
Lo ideal para empezar a ejercer como SDET, y por poner un mínimo, sería que la persona tenga conocimientos en pruebas y también conocimiento técnico, por lo que podemos decir que es verdad que el rol es un híbrido entre desarrollador y tester. Pero también algo más.
No es importante ser un genio de la programación ni pensar en los casos de prueba más enrevesados, sino tener una visión global, tanto funcional como técnica, que nos permita definir una estrategia de calidad acorde al equipo.
Como hemos visto previamente, se asume que el SDET tiene que saber de prácticamente todos los ámbitos. En realidad, lo importante es tener una buena base de conocimientos y capacidad para adaptarse, aprender y divulgar.
“Sí, sí automatiza”
Vamos a ver unos cuantos ejemplos, en formato “problema –> solución que aporta el SDET”:
| PROBLEMA | SOLUCIÓN |
| 1. Los desarrolladores tienen interés por TDD (es en serio, les encanta hacer pruebas unitarias y no han podido dejar pasar la oportunidad de empezar por ellas) | Aprender y divulgar buenas prácticas para trabajar con TDD, hacer seguimiento y sesiones de trabajo conjuntas junto con los desarrolladores. |
| 2. El product owner ha escuchado por ahí que se usa mucho BDD y le interesa probar (y dedicará el tiempo que haga falta a escribir historias de usuario) | Divulgar las ventajas de BDD y dar pautas para escribir historias de usuario en Gherkin, crear un diccionario de pasos para automatizar. |
| 3. Se ha acordado que la cobertura de pruebas unitarias será del 70% y se evidenciará mediante un html | Investigar la mejor manera de generar el informe según lenguaje/tecnología y revisar que se cumplen los requisitos. |
| 4. Se sabe que en producción el tiempo ideal de respuesta de un servicio es de 200ms y se quiere asegurar que después de cada entrega se va a mantener | Proponer la ejecución temprana de pruebas de rendimiento y comparar si existen incrementos de tiempo después de cada entrega, realizando el mismo SDET pruebas sencillas de rendimiento. |
| 5. Se llega al acuerdo de que después de cada despliegue se lanzarán pruebas automáticas | Automatización de pruebas funcionales e implementación en pipeline de despliegue. |
Esto puede dar lugar a casos y casos diferentes, cambiando tecnologías, frameworks, metodologías, tipos de prueba… y puede ser tan sencillo o complejo como el equipo pueda concebir.
Un buen SDET tiene que tener una mentalidad abierta al cambio y a la mejora continua, y buscar activamente el refinamiento de los procesos de calidad de su equipo.
Recapitulando, el SDET aporta una visión global funcional y técnica, una Estrategia de Calidad viva, investiga y divulga temas de interés para el equipo y puede apoyar, dentro de su conocimiento, al resto de roles en sus tareas, ya que, en el fondo, tiene un poco de cada uno, y ellos un poco de él. ¡Y sí, de verdad, también automatiza!
Jesús Vivas
Santander Global Tech
