Es raro encontrar un proyecto del que te enamores durante la entrevista y del que estés orgulloso cuando conquista nuevos mercados. Es mucho más agradable cuando la profesionalidad de los compañeros está en su mejor momento, y en su equipo se siente como en el seno de su familia. Tuve la suerte no solo de encontrar un proyecto de este tipo, sino también hace algún tiempo de comenzar a influir en el proceso de prueba en él. Le diré lo que se incluye en nuestra comprensión del proceso óptimo; cómo llegamos a los lanzamientos mensuales y cómo funcionan para nosotros; y cómo nos hemos adaptado a las condiciones de cuarentena.
Nuestro proyecto es un sistema de aprendizaje a distancia (LMS, Learning Management System), que es utilizado por más de 7 millones de personas en diferentes países del mundo. El sistema contiene más de 1000 páginas web y aproximadamente 10,000 casos de prueba.
Ahora, el proyecto emplea a unos 15 equipos de desarrollo, del lado del cliente en Noruega y del lado de Arcadia en Rusia. Me uní al proyecto hace 8 años como QA; Durante los últimos 2 años he trabajado como líder de QA, participando en la optimización del proceso de prueba.
Qué se incluye en el concepto de proceso óptimo
Nuestra tarea principal es satisfacer las necesidades de los usuarios finales, lo que incluye la creación de nuevas funciones y soporte del sistema. Se presta especial atención a la velocidad del sistema y la estabilidad del trabajo en condiciones de carga pesada.
El proceso de desarrollo debe permitir principalmente el logro sostenible de los objetivos comerciales, como completar el trabajo a tiempo y con un nivel de calidad acordado. Pero el proceso también debe ser cómodo para el equipo de desarrollo, de modo que todos los involucrados en el proceso estén satisfechos. En nuestros equipos, hemos establecido un proceso óptimo para nosotros, y aquí están los medios por los cuales esto se logra.
Proceso de desarrollo en general:
a) Un enfoque de desarrollo que satisfaga las necesidades del equipo
Trabajamos utilizando Scrum y sprints con una duración de 3 semanas. Antes del sprint, se realiza una presentación de sus objetivos y se forma un conjunto de requisitos para este sprint. Luego viene la planificación, en la que evaluamos todas las tareas y determinamos el conjunto de tareas que se incluirán en el sprint. Al final del sprint, se lleva a cabo una revisión de Sprint, donde demostramos todas las tareas completadas y anunciamos los objetivos alcanzados. Este enfoque es óptimo para nosotros: en un sprint logramos crear una cantidad suficiente de nuevas funciones y al mismo tiempo corregir y probar una cierta cantidad de errores de los usuarios finales: el 10% del tiempo del sprint se asigna a dichos errores.
Póngase en fila: líder de equipo, desarrolladores, probadores. La proporción de desarrolladores a probadores en nuestros equipos es de 3: 1. Esta relación hace posible lograr el objetivo del sprint de manera uniforme: no hay períodos en los que uno de los participantes del proceso esté inactivo: mientras los desarrolladores realizan cualquier cambio, los probadores crean o actualizan casos de prueba relacionados con este cambio; Cuando se completa el desarrollo, los evaluadores verifican los cambios y los desarrolladores pasan a las siguientes tareas en el sprint o ayudan con las pruebas (esto es necesario cuando se prueban cambios a gran escala).
El Product Owner establece metas y requisitos al comienzo de cada sprint y los acepta al final. Además, cada equipo tiene un Scrum Master para ayudar a resolver problemas emergentes.
Para que el equipo tenga la oportunidad de realizar diversas actividades que no están directamente relacionadas con las tareas del sprint, además de tener en cuenta diversos riesgos, el tiempo calculado para completar las tareas del sprint es el 80% del tiempo total de trabajo del equipo. Es decir, 2 horas al día durante un sprint regular se reservan para comunicaciones, diversas reuniones y seminarios, así como para corregir errores encontrados en el sprint.
b) Requisitos claros y buena planificación
Para asegurarnos de que la planificación no se demore y que el sprint no se convierta en un fracaso debido a detalles previamente desconocidos y laboriosos cambios adicionales agregados durante el sprint, intentamos incluir en el sprint solo cambios con requisitos suficientemente claros y precisos. Si el equipo no conoce el área del proyecto que se refiere a los cambios, o durante la planificación hay muchas preguntas que el Product Owner no puede responder, el equipo puede acelerar una tarea para estudiar esta área o una tarea de investigación, lo que da como resultado requisitos claros o incluso algún tipo de prototipo.
c) Retrospectivas
También es importante corregir errores. Esto se aplica tanto a los sprints como a los lanzamientos. Ocurre que no tenemos tiempo para algo, o tenemos que trabajar horas extras para cumplir con el plazo, por ejemplo, si es necesario realizar una prueba previa de una versión (y este es un costo adicional que la empresa quisiera evitar en el futuro). Por lo tanto, llevamos a cabo retrospectivas en las que discutimos lo que fue bueno y malo en el sprint o lanzamiento, y desarrollamos medidas para evitar tales errores en el futuro.
d) Apoyo a la gestión
A veces surgen preguntas o situaciones que no se pueden resolver a nivel de equipo; es necesario cambiar el proceso o involucrar a la gerencia de la empresa en la decisión. Es muy importante ver que quieren ayudarlo y están listos para brindarle apoyo en tal situación. En nuestra empresa, todo está bien con esto, esto se aplica tanto a Arcadia como a la gestión por parte del cliente. Se discuten todos los problemas y siempre se encuentra una solución que satisfaga a todas las partes.
e) Y, en mi opinión, lo fundamental es la buena comunicación. Y lo que tenemos en la empresa, para mí, es una de las principales ventajas del trabajo cómodo: la benevolencia, el deseo de compromiso.
Esto se aplica a todos: cada miembro del equipo, el Product Owner, el Scrum Master, la gerencia de la empresa y muchos otros participantes en el proceso. Todos están abiertos a preguntas y discusiones, los desarrolladores consultan con los probadores sobre los requisitos y juntos deciden cuál es la mejor manera (tanto desde el punto de vista del desarrollo como desde el punto de vista de las pruebas) para hacer tal o cual cambio. El Product Owner, a su vez, está en contacto constante con el equipo, resuelve rápidamente todos los problemas y siempre intenta alcanzar la mitad del camino para lograr los objetivos del sprint. El Scrum Master siempre está listo para ayudar: encuentre recursos adicionales (probadores / desarrolladores, si son necesarios para el sprint o para el lanzamiento) o sugiera la mejor manera de organizar el sprint a tiempo.
Proceso de prueba:
a) Estándares de garantía de calidad (directrices) relacionados con la redacción de casos de prueba.
En nuestro proyecto, los casos de prueba son la principal documentación detallada sobre la funcionalidad del sistema, por lo que se les presta mucha atención. Para cada cambio realizado por el equipo, se escribe un nuevo caso de prueba o se actualiza uno existente.
Anteriormente, cuando el sistema aún no era tan grande, los casos de prueba se escribían con bastante detalle, con varios pasos específicos, pero ahora este enfoque se ha vuelto inaceptable: lleva mucho tiempo actualizar dichos casos de prueba. Por lo tanto, nosotros (los líderes de QA) hemos desarrollado estándares, cuyo principal requisito es escribir scripts de prueba con los resultados esperados en lugar de pasos detallados en los casos de prueba.
b) Estándares de control de calidad relacionados con las pruebas en los sprints.
Los estándares de prueba de Sprint se han desarrollado para garantizar que cada equipo realice cambios de buena calidad.
Estos estándares se basan en la cobertura máxima de prueba, que incluye:
- Probar los cambios realizados por el equipo directamente (funcionalidad y, si es necesario, UI);
- Probar el sistema después de este cambio usando una lista de verificación: estas son verificaciones obligatorias, que incluyen probar la accesibilidad para personas con discapacidades, verificar las traducciones, verificar los datos existentes, probar con caracteres especiales, verificaciones de seguridad, probar cambios en una aplicación móvil y otras verificaciones ...
c) Estándares de control de calidad relacionados con las pruebas de liberación.
El proceso de liberación y los estándares utilizados en él se analizan con más detalle a continuación.
d) Uso de pruebas de regresión automatizadas.
La creación de pruebas automatizadas para las pruebas de regresión ha simplificado enormemente la vida de los equipos; ahora, si necesita verificar alguna área después de los cambios de comando, simplemente puede ejecutar pruebas automáticas de regresión para el área deseada del sistema (si esta área está cubierta por pruebas automáticas). Además, si alguna parte del sistema se ha roto debido a cambios en el equipo, las pruebas automáticas de regresión lo detectarán.
e) Asistencia mutua de probadores, asistencia de desarrolladores.
No tenemos muchos probadores (en promedio, 1 probador para 3 desarrolladores), además, de vez en cuando se distraen de las tareas de sprint para probar lanzamientos, y puede que no haya suficiente tiempo para todo.
En este caso, siempre hay alguien de los testers de otros equipos con menos carga de trabajo en este momento que puede ayudar. El líder de QA o Scrum Master ayuda a encontrar tal tester. Además, los desarrolladores pueden ayudar a probar los cambios en el sprint si ya se han escrito casos de prueba para ellos.
f) Comunicación entre probadores.
Para la comunicación, se usa un chat en Microsoft Teams, en el que todos pueden hacer preguntas y obtener respuestas rápidamente, mientras que el resto de probadores conocerán la información más reciente. También llevamos a cabo reuniones mensuales de control de calidad, en las que los evaluadores comparten entre sí las tareas actuales de su equipo y pueden discutir cualquier problema: el enfoque de las pruebas y / o la ubicación de los casos de prueba relacionados con un área desconocida para el evaluador; preguntas sobre el lanzamiento (composición del equipo de lanzamiento futuro, cambio de la línea de tiempo de prueba); verificaciones obligatorias adicionales agregadas después de perder un error crítico en la versión, etc.).
Los enfoques anteriores le permiten garantizar pruebas de buena calidad en un modo de funcionamiento silencioso.
:
Solíamos tener lanzamientos trimestrales . Con tal marco de tiempo, hubo muchos cambios que fueron realizados por los equipos para cada lanzamiento. Este volumen de cambio ciertamente requirió una regresión previa al lanzamiento, por lo que había un marco de tiempo separado para la regresión y todos los equipos estaban conectados a él. Esto usualmente tomó alrededor de 2 semanas, y tanto los evaluadores como los desarrolladores del equipo participaron en la regresión.
Después de algún tiempo, las pruebas automáticas comenzaron a usarse para la regresión en el proceso de prueba de versiones. No todas las pruebas de regresión se cubrieron con autotest, algunas se probaron manualmente. En general, esto redujo el tiempo de prueba de regresión, pero debido al tamaño del sistema, la regresión completa aún requería mucho tiempo.
Todo el ciclo de desarrollo se veía así:
Se hizo evidente que este enfoque de las versiones no es óptimo, es excesivamente laborioso y no permite una satisfacción rápida y flexible de las solicitudes de los usuarios finales. El enfoque del proceso de lanzamiento requería cambios y se decidió lanzarlo con más frecuencia, una vez al mes.
Cuando pasamos a las versiones mensuales , quedó claro que no había tiempo para ejecutar la regresión durante la fase de prueba de la versión, incluso con pruebas de regresión parcialmente automatizadas. Ahora, el período total de preparación para el lanzamiento toma solo 2 semanas. Por lo tanto, ahora la regresión se realiza en sprints y solo cuando es necesario (si los desarrolladores informan que se requiere una regresión de una determinada parte del sistema).
Pero dado que en la etapa de prueba de la versión es necesario verificar no solo la nueva funcionalidad, sino también el estado general del sistema, comenzamos a usar la estabilización en lugar de la regresión.
La estabilización incluye:
a) probar la nueva funcionalidad incluida en este lanzamiento por cada equipo;
b) La prueba de áreas críticas es una prueba de la funcionalidad básica de las áreas principales del sistema (que obviamente lleva mucho menos tiempo que un ciclo de regresión completo);
c) probar los errores encontrados en los cambios de equipo para esta versión.
El ciclo de desarrollo completo ahora se ve así:
Consideremos qué más se necesita para prepararse para el lanzamiento.
Cuando finaliza la estabilización y el paquete de lanzamiento es de buena calidad, antes de implementarlo en producción, la configuración se prueba en el entorno de preproducción. Por lo tanto, Operaciones practican la actualización del entorno y los evaluadores verifican la configuración con el paquete de versión actual antes de la versión real.
Podría pensar que 2 semanas de preparación para el lanzamiento es demasiado y queda poco tiempo para probar en el sprint. Pero por lo general, un evaluador tarda de 4 a 6 días en prepararse para un lanzamiento. Depende de:
- la complejidad y el alcance de la funcionalidad que su equipo va a lanzar,
- participación del probador en el equipo de lanzamiento del lanzamiento actual.
Todos los probadores del proyecto (incluido el equipo de lanzamiento) participan en las pruebas de estabilización; probar la configuración y el lanzamiento en sí solo lo realiza el equipo de lanzamiento.
El programa general de pruebas de lanzamiento se ve así:
dado que las áreas críticas y la configuración contienen pruebas constantes, hemos automatizado parcialmente estos casos de prueba. Esto ha reducido significativamente el tiempo de prueba en preparación para el lanzamiento, por lo que en el futuro planeamos expandir el uso de pruebas automáticas.
Desde el punto de vista de la organización de las pruebas, se selecciona un coordinador de QA (alguien de los líderes de QA) para cada versión. El plazo de entrega de la publicación se suele planificar más para un coordinador de garantía de calidad que para los probadores habituales, ya que el coordinador de garantía de calidad tiene más responsabilidades. Éstos incluyen:
- definir el equipo de lanzamiento y verificar la disponibilidad de todos sus miembros en el momento del lanzamiento;
- preparación de planes de prueba para el lanzamiento;
- lanzar autotests en la etapa de estabilización y prueba de configuración;
- coordinación del trabajo de los probadores durante las pruebas de lanzamiento;
- ayudar a los evaluadores a resolver todo tipo de problemas relacionados con el lanzamiento;
- control sobre la implementación de las pruebas y, si es necesario, la redistribución de la carga para ayudar a probar los equipos sobrecargados (estos pueden ser probadores de otros equipos que ya han completado las pruebas de lanzamiento, o desarrolladores del equipo, o el coordinador de QA mismo).
Y, por supuesto, ningún lanzamiento está completo sin problemas. Los resolvemos y desarrollamos un plan sobre cómo evitarlos en el futuro. Aquí hay algunos con los que nos hemos encontrado recientemente:
- : , - , , - .
: . - : pre-production . — .
: . - : , .
:
a) - ( , ),
b) ,
c) ,
d) , . , , .
Solución: en tales casos, intentamos tener tiempo para probar todo lo necesario para el lanzamiento, incluso si requiere la participación en el lanzamiento durante las 2 semanas o el trabajo de horas extra, ya que el lanzamiento es una tarea de mayor prioridad que las tareas de sprint.
Pero no importa qué problemas surjan, siempre podemos resolverlos con las fuerzas del equipo de lanzamiento o con la participación de personas competentes en un área en particular; lo principal es que este es siempre un trabajo en equipo bien coordinado que conduce a un buen resultado.
Trabajar en cuarentena: cómo garantizar el trabajo de los probadores
En nuestro proyecto, el trabajo desde la oficina es un requisito previo. Esto se hace para que se pueda encontrar a cualquier participante en el proceso durante las horas de trabajo; si de repente no responde en los chats, las personas que trabajan con él pueden informarle que algunos de sus colegas lo necesitan. Esto es relevante, porque algunos de los equipos están en Noruega y otros en San Petersburgo.
Durante la pandemia, cuando tanto Noruega como Rusia enviaron a la mayoría de la población al autoaislamiento, tuvimos que cambiar al trabajo remoto.
Seguimos trabajando como de costumbre: los equipos aún terminaron los sprints con buena productividad y los lanzamientos se lanzaron a tiempo.
La comunicación aún se mantuvo en un buen nivel - la aplicación Teams cubrió todas las necesidades: hubo conversaciones activas en el chat, las reuniones se llevaron a cabo sin problemas; si había alguna pregunta que necesitara ser discutida con urgencia, llamaron a cualquier participante del proyecto.
Desde el punto de vista de la organización de las pruebas, no hubo problemas: durante el horario comercial, todos los evaluadores respondieron en los chats y participaron rápidamente en la prueba de la versión. En caso de que necesitemos encontrar a alguien, pero no responde en el chat, hemos preparado una lista de números de teléfono móvil, pero nunca tuvimos que usarla.
El único problema que enfrentamos mientras estábamos en casa en un trabajo remoto: debido a las peculiaridades de la VPN, era imposible probar el sistema en un entorno de equipo desde teléfonos / tabletas. Pero este problema se superó gracias al director del proyecto y al servicio de TI, que encontraron una solución. Comenzamos a usar proxies cuando nos conectamos a una red doméstica, y ahora podemos probar en dispositivos móviles desde casa.
Ahora volvemos parcialmente al trabajo en la oficina, pero parte de la empresa sigue trabajando desde casa. E incluso estando en diferentes puntos de la ciudad, seguimos siendo una única empresa unida que sigue trabajando en tiempos tan difíciles, con unas condiciones de no trabajo en las que los niños y las mascotas exigen atención, Internet se ralentiza y desaparece periódicamente, las luces se apagan y hay tantas distracciones. factores que no entiendes en absoluto, ¿cómo te las arreglaste para volver a trabajar?
Pero juntos sobreviviremos a todo esto, y finalmente volviendo a una vida de oficina en toda regla, nos sonreiremos aún más ampliamente de lo habitual.
Conclusión
Resumiendo lo anterior, me gustaría señalar algunos puntos:
- , , . — .
- , , .
- , , , — . , .