Todos los días en el campo de TI hay más y más tareas nuevas, incluso en el campo de las pruebas. Si antes un probador necesitaba simplemente probar de acuerdo con los requisitos (o sin ellos), ahora debe comprender primero cómo se puede probar, qué tecnologías se necesitan para esto, qué se puede automatizar y cómo incluir un ciclo de lanzamiento en toda esta desgracia y etc. ¿Quién debería responder estas preguntas? ¿Quién se comunicará con el cliente y aclarará los requisitos? ¿Quién creará los enfoques y la arquitectura de prueba, los requisitos?
Trabajando como líder y coordinador de pruebas en proyectos para grandes empresas y resolviendo todos estos problemas en el transcurso de tres años, me di cuenta de que es importante atraer a una persona que responda la pregunta principal: "¿Cómo realizar las pruebas?"
Realicé una pequeña investigación y descubrí que ese rol ya existe, y se llama Test Solution Architect (TSA), pero pocas personas lo saben. Y la descripción de las vacantes de TSA en los sitios web de los empleadores sorprende con su lista de deberes y habilidades, pero creo que esto es más probable debido a la falta de comprensión de quién es la TSA.
Basado en mi experiencia en esta dirección, decidí mostrar con el ejemplo de uno de los proyectos reales quién es TSA y cuándo es necesario.
Breve descripción del proyecto
El objetivo del proyecto era reemplazar una base de datos con otra, más precisamente, Cassandra y su apéndice en forma de FilloDB fueron reemplazados por SnowFlake, en el proceso comercial de un flujo diario, horario e incluso minuto a minuto de entrega y procesamiento de datos. Hubo más de 50 flujos de este tipo, y según lo planeado por los arquitectos, se suponía que esto resolvería una gran cantidad de problemas relacionados con el rendimiento, la pérdida de datos, los costos de mantenimiento y la compra de licencias adicionales para Cassandra, etc. Pero cuáles de estas expectativas se cumplieron y cuáles no, este es el tema de otro artículo.
¿Qué roles de prueba estaban en el proyecto?
Históricamente, las siguientes funciones se han distinguido en las pruebas: un probador manual o un probador funcional, una herramienta de automatización de pruebas (la que escribe el código y las pruebas) y un gerente de pruebas (el que resuelve todos los demás problemas). Nuestro proyecto no fue la excepción. El proyecto involucró:
- 1 líder de prueba o líder de prueba
- 40 probadores manuales que trabajaron con equipos scrum (7 equipos)
- 2 desarrolladores (esto es más bien una excepción, porque a los desarrolladores no les gusta trabajar en tareas de automatización) y 2 pruebas de automatización
- 2 probadores que hicieron pruebas de estrés
- 1 probador funcional para probar productos que fue desarrollado por desarrolladores y pruebas de automatización
Prueba manual
El objetivo principal de los probadores funcionales era probar la aplicación y decir si cumple con los requisitos del cliente. Para esto, los evaluadores usualmente:
- Crea planes de prueba.
- Crea una estrategia de prueba.
- Cree casos de prueba con pasos programados (con el resultado esperado y actual).
- Realice casos de prueba y concluya sobre la calidad de la aplicación.
No teníamos requisitos del cliente ni descripciones del sistema. Solo existía el sistema antiguo y el nuevo y el deseo: "Hacer que funcione, pero con una nueva base". Por lo tanto, solo podríamos usar el enfoque de igual a igual: comparar los resultados de los sistemas antiguos y nuevos. Todo se complicó por el hecho de que trabajamos con un sistema de producción y datos actualizados diariamente. Desafortunadamente, no pudimos iniciar nuestro sistema al mismo tiempo que el sistema de producción, y lo iniciamos más tarde, y esto llevó al hecho de que los datos en los sistemas antiguo y nuevo eran diferentes.
En esta etapa, comenzaron a surgir preguntas:
- ¿Cómo concluir que nuestro sistema funcionó correctamente si, debido a un cambio de tiempo, obtenemos resultados diferentes de los que obtuvimos en el sistema anterior?
- ¿Podemos alejarnos de la producción de datos y trabajar en datos estables? Cuales son los riesgos?
- Y si, sin embargo, llegamos a datos estables, ¿cómo demostrar que nuestro sistema funcionará correctamente con datos actualizados diariamente?
Esta es solo la punta del iceberg de la lista de preguntas similares que surgieron en el proyecto durante las pruebas funcionales / manuales.
Prueba de automatización
Los ingenieros de automatización de pruebas (y los desarrolladores) tenían el objetivo de escribir aplicaciones que pudieran probar y / o facilitar automáticamente el trabajo de los probadores funcionales:
- autocomprobaciones que se integrarían con CI / CD;
- aplicaciones que ayudaron a probar probadores funcionales;
- y otros desarrollos necesarios para las necesidades internas del proyecto.
En el proyecto, todas las aplicaciones que se desarrollaron para la prueba deberían haber sido un producto separado que obedeciera todas las reglas de desarrollo y como resultado se hubiera entregado al cliente. Y, en consecuencia, surgieron preguntas:
- ¿Quién junto con el cliente desarrollará requisitos no funcionales para probar aplicaciones? El Arquitecto de soluciones dijo que este no es su trabajo, ya que Las SA trabajan con la aplicación que ordenó el cliente.
- ¿Quién desarrollará los requisitos de funcionalidad para probar aplicaciones? Hay requisitos obvios, pero hay requisitos no obvios. Por ejemplo, ¿necesitamos almacenar los registros de nuestras aplicaciones y analizarlos?
- ¿Quién resolverá el entorno para las aplicaciones con el cliente y solucionará estos requisitos? Por ejemplo, específicamente en este proyecto hubo una restricción en spark 1.4, y esto se descubrió solo después de crear la aplicación.
Y esto también está lejos de todos los problemas que surgen en el proyecto en términos de automatización de pruebas.
Test Leader, también conocido como Test Lead
Test Lead debe organizar los procesos de prueba en el proyecto. Sus funciones incluían la distribución de tareas, mantener reuniones internas con probadores, organizar el trabajo con el cliente (conocer detalles, revisar los resultados), etc. Es decir, se centró en el proceso actual y en la resolución de problemas / tareas diarias, y no en resolver las tareas del enfoque, la estrategia y la arquitectura de prueba.
Si hablamos de Test Lead técnico, estaba a cargo de soluciones técnicas: organizar el desarrollo de aplicaciones para pruebas como un proceso de creación de un producto de software separado que obedece todas las reglas de desarrollo, por ejemplo, crear pruebas unitarias, integrarse con procesos de CI / CD y etc.
En nuestro proyecto, estos roles fueron desempeñados por dos personas, y cada horario se veía así:
En ambos casos, Test Lead está ocupado trabajando en la estrategia de prueba ya elegida, pero nadie es responsable de elegir la estrategia en sí, justificando esta elección al cliente, adaptándola a los cambios y otros problemas. Por ejemplo:
- Desarrollo de un plan con el cliente para ingresar a la etapa de pruebas de aceptación por parte del cliente (UAT).
- Estudiar los requisitos con el cliente cuando se considera que la funcionalidad se puede transferir a la UAT.
- Estudie con el cliente los supuestos de las pruebas en diferentes tipos de entornos (un punto muy delicado). Como generalmente el entorno de prueba no corresponde a la producción, todas las preguntas relacionadas con las pruebas en otro entorno deben resolverse con el cliente.
- Estudie con el cliente una discrepancia aceptable de métricas en varios tipos de pruebas. Por ejemplo, ¿qué resultado espera ver un cliente durante las pruebas de rendimiento? Tal vez sea suficiente para él que el sistema no funcione peor.
- Recopilar todas las métricas posibles en números, por ejemplo, las discrepancias de datos para esta tabla no se permiten en más del 10%, o el script no debe ejecutarse más de ocho horas.
¿Qué está mal aquí?
Las preguntas anteriores generalmente se colocan sobre los hombros de Test Lead, pero hay un enfoque defectuoso:
- No se les enseñan los procesos en los que Test Lead debe resolver todos estos problemas con el cliente. Muy a menudo, un líder de pruebas experimentado comprende esto y, tal vez, incluso sabe cómo, pero lo más probable es que una parte tan importante como el objetivo del negocio o mejoras específicas permanezca fuera del alcance de su comprensión. En consecuencia, se pueden establecer prioridades incorrectas.
- Test Lead generalmente ingresa a un proyecto cuando el desarrollo ya está en marcha o apenas comienza, es decir se enfrenta a las condiciones de que ya hay algunos acuerdos o incluso que todo ya se ha solucionado. Es una suerte que SA sea una persona suficientemente experimentada y competente y vaya a realizar pruebas; ayudará a adaptar los acuerdos iniciales con el cliente a las necesidades de las pruebas. En otro caso, el plomo tiene que reinventar la rueda.
Y estos no son todos los problemas que recaen en Test Lead cuando no hay TSA.
Entonces, ¿quién es esta TSA y por qué se necesita?
Test Solution Architect es una persona que considera la tarea desde el punto de vista del negocio, la información y la tecnología, coordina y desarrolla los requisitos con el cliente, elabora una hoja de ruta con plazos y desarrolla soluciones a nivel de interfaz.
Los proyectos ahora dictan otras condiciones. Los proyectos se han vuelto más grandes, más complicados en términos técnicos y de proceso, y pueden abarcar varias industrias y tecnologías. Las pruebas se han convertido no solo en un servicio, sino también en un proveedor (desarrollador) de software para el cliente. Por lo tanto, en las pruebas existe la necesidad de resaltar un papel similar. Además, esta persona debe ingresar al proyecto junto con SA, que participa en la aplicación de producción, y comenzar a trabajar en todos los temas al mismo tiempo.
Específicamente, en nuestro proyecto, el papel de TSA fue desempeñado por Test Lead, que se unió al proyecto 3 meses después del inicio del desarrollo, y esto implicó una gran cantidad de trabajo adicional para armonizar los requisitos y los entornos, descubriendo la visión de los resultados finales de la prueba del cliente. Como resultado, el proyecto no cumplió con los plazos durante la mayor parte de su vida, y los clientes no estaban contentos con los suministros y el resultado de la prueba. No porque el trabajo se realizó mal, sino porque el resultado producido por el equipo no cumplió con las expectativas del cliente.
¿Cuándo no se necesita TSA?
Está claro que ese papel no es necesario en todos los proyectos. A continuación, propongo la forma más sencilla de determinar la necesidad de TSA en un proyecto, dependiendo de cómo el cliente vea el enfoque de prueba.
El primer tipo de proyecto: el cliente proporciona la configuración de los procesos de prueba a discreción de la empresa que contrató.En este caso, la TSA ingresa al proyecto desde el momento en que comienza a trabajar en él, junto con SA, desarrolla requisitos de prueba, desarrolla un esquema de prueba de alto nivel, decide qué se automatizará / desarrollará como aplicaciones separadas, determina los requisitos para estas aplicaciones y, por supuesto, coordina con el cliente, prioriza los objetivos del proyecto de acuerdo con las expectativas del negocio.
El segundo tipo de proyecto: el cliente tiene su propia comprensión de las pruebas, una imagen clara y procesos optimizados.En este caso, es posible que no se necesite TSA; las pruebas solo se requieren para adaptarse a la imagen existente del mundo y respaldarla. Pero si la comprensión es superficial, entonces la TSA necesita no solo realizar todas esas acciones como para el primer tipo de proyectos, sino también demostrarle al cliente que todo esto es necesario.
El tercer tipo de proyecto: el cliente no necesita los servicios de TSA.Las razones pueden ser diferentes:
- Un proyecto pequeño y de corto plazo con funcionalidad simple.
- El cliente tiene su propia TSA.
- El cliente se negó a probar, etc.
Habilidades TSA
La práctica del arquitecto de soluciones se ha aplicado con éxito en el desarrollo durante mucho tiempo. Sobre la base de esta experiencia exitosa, y también teniendo en cuenta el volumen y la complejidad de los proyectos, problemas que exceden el área de responsabilidad de Test Lead, podemos decir que destacar el papel de TSA es un desarrollo natural de los eventos. Además, la TSA debe estar capacitada en los mismos procesos, técnicas y enfoques que la SA.
En resumen, en mi opinión, la TSA debería tener:
- Con conocimientos técnicos, tanto en general como en el área de dominio donde trabaja, para conocer los problemas de esta área, errores típicos, problemas y formas de verificarlos.
- Buenas habilidades de comunicación, ser capaz de llamar la atención del cliente sobre problemas de prueba, resolver requisitos de prueba, enfoques de prueba, informes de prueba y muchos problemas relacionados, como el entorno de prueba.
- Habilidades de liderazgo y ser proactivo porque Las pruebas a menudo intentan irse para más tarde.
- Buen conocimiento de las pruebas en general, documentación de pruebas, procesos de pruebas, informes de pruebas, enfoques, etc.
- Buen conocimiento de las reglas de desarrollo de software: políticas de versión, políticas de versiones, comprender procesos de CI / CD, etc.
Con base en lo anterior, TSA debe tener el mismo conocimiento que SA, pero centrarse en las tareas de proporcionar al cliente un producto de calidad. El trabajo de la TSA se complica por el hecho de que a menudo es necesario cambiar la opinión del cliente sobre las pruebas como exclusivamente sobre la cocina interna del proyecto.
Fue precisamente el conocimiento que recibí en la escuela Solution Architect lo que me permitió restaurar la confianza del cliente en el proyecto que se describió anteriormente, resolver muchos problemas de prueba y completar con éxito la entrega de toda la funcionalidad casi a tiempo, así como establecer procesos y firmar contratos para trabajos futuros.
Conclusión
La industria de TI se está desarrollando, aparecen nuevas tareas (desafíos si lo desea) y, en el caso de las pruebas, la posición destacada de la TSA se ha vuelto urgente. Naturalmente, todo depende del proyecto, pero en los proyectos donde se necesita una CST, debe involucrarse en el trabajo en la etapa inicial, esto evitará problemas en el futuro y ayudará al desarrollo del proyecto.