Buenas tardes, mi nombre es Alexander Ulanov, soy ingeniero de pruebas en Odnoklassniki. En este artículo, me gustaría hablar sobre uno de los proyectos en los que participé. Te advertiré de inmediato: en el artículo no encontrarás ningún descubrimiento o enfoque complejo de la metodología de prueba. Sin embargo, el proceso de desarrollo y prueba descrito en el artículo puede ser interesante o incluso útil para alguien.
Episodio 1: Miedo y asco en OTRS

OTRS es un sistema de procesamiento de solicitudes que permite que las organizaciones involucradas en el soporte técnico de cualquier proyecto trabajen juntas para resolver los problemas de los usuarios. El sistema está escrito en Perl y fue respaldado por los desarrolladores hasta noviembre de 2017.
Fue el sistema OTRS que utilizamos durante muchos años para procesar todas las llamadas de los usuarios. La decisión de usar OTRS se tomó hace muchos años. Luego hubo una tarea simple: encontrar una solución preparada y adaptarla rápidamente a nuestros objetivos. Y fue terrible, explicaré por qué:
- utilizamos una versión personalizada del sistema OTRS para nuestras necesidades y, por lo tanto, actualizarlo (hasta el otoño de 2017) fue, por decirlo suavemente, difícil;
- Con el tiempo, comenzamos a comprender que el sistema descansa sobre su carga de "techo" y deja de hacer frente a la cantidad de aplicaciones que provienen de nuestros usuarios;
- El sistema OTRS se integró en la infraestructura general de tal manera que dependía completamente de las actualizaciones de la red social OK.ru. Lo que hizo posible actualizar OTRS solo una vez a la semana;
- un personal de 90 personas de apoyo podría responder a las quejas solo en unas pocas horas;
- La prueba de cada actualización del sistema desde nuestro lado se convirtió en una pesadilla, porque Incluso los cambios más pequeños podrían romper el sistema en cualquiera de los nodos. Cuando se trataba de agregar nuevas funcionalidades, el proceso de desarrollo y prueba se convirtió en semanas de depuración del sistema;
- OTRS en sí está escrito en Perl. Un lenguaje que prácticamente no se utilizó en los proyectos de OK.ru, que impuso problemas adicionales;
- y, tal vez, el principal problema es el CORREO! OTRS manejó las quejas en forma de correo electrónico. ¡Y esto es en 2016-2017! Por lo tanto, toneladas de configuraciones, características de trabajar con servicios de correo y largas esperas de respuestas para los usuarios, que son inevitables al comunicarse con el soporte por correo.
Episodio 2: Lo que queríamos obtener
La idea de una salida completa de OTRS comenzó a desarrollarse en la empresa desde 2015. Tarea clave: deshacerse del uso del correo y proporcionar la capacidad de responder rápida y oportunamente a los usuarios sin un aumento múltiple en el número de personal de soporte. La solución más obvia es un servicio de soporte en línea.
Además, nadie quería gastar recursos en un sistema completamente nuevo. Es más lógico utilizar sus servicios internos, cuyo funcionamiento ya tiene experiencia y cobertura de prueba. Además de un requisito puramente técnico: poder hacer actualizaciones al nuevo sistema en cualquier momento y no depender de otros equipos. Lo que nos prometió flexibilidad en el desarrollo y las pruebas.
Alrededor del mismo período, OK.ru vio una modernización global del sistema de mensajería. Fue sobre la base de los nuevos mensajes que se decidió implementar el nuevo sistema de soporte en línea (en lo sucesivo, "oSupp").
Episodio 3: Planificación

En las primeras etapas de desarrollo de oSupp y como resultado de numerosas reuniones, vimos una serie de problemas. La principal es que es imposible cambiar de inmediato todo el trabajo de OTRS a oSupp a la vez:
- era necesario evaluar completamente cómo el nuevo sistema hace frente a la carga técnica (recuerde, estamos hablando de procesar 10-12 mil quejas por día);
- Era necesario capacitar a los empleados para trabajar en el nuevo sistema;
- Era necesario realizar pruebas A / B tanto en los usuarios como en los empleados de soporte y evaluar cómo enfrentarán la carga;
- limitación técnica: la mensajería OK.ru nunca ha funcionado con usuarios no autorizados. Y en el trabajo de soporte, la comunicación con usuarios no autorizados es casi un tercio de las miles de quejas;
- Para probar el sistema, debe crear un entorno que sea lo más similar posible a uno real, pero sin acceso a usuarios activos.
Decidimos que la mejor manera es implementar e implementar oSupp en tres etapas:
- Desarrollo de prototipos y pruebas.
- Implementando oSupp para procesar llamadas de usuarios autorizados de OK.ru.
- Cobertura total de todas las llamadas con el nuevo sistema oSupp.
Episodio 4: Pruebas y puesta en servicio
Para probar el prototipo, se creó un entorno de prueba con la capacidad de generar llamadas de usuarios de prueba y la capacidad de conectar oSupp al entorno de prueba OK.ru. Cabe señalar aquí que el nuevo sistema fue diseñado de tal manera que nada cambió por parte del usuario hasta el momento de la comunicación directa con el operador. La conocida sección de "Ayuda" se ha mantenido, la tipificación reconocible de los temas en el sitio y las preguntas frecuentes se han conservado.
Hasta este punto, nada ha cambiado en términos de pruebas. Todos los planes de prueba y la cobertura por autotest no cambiaron. U - conveniencia!

Después de que el usuario encontró el tema de la apelación y completó los campos requeridos, el mensaje cayó en el sistema oSupp, y el usuario conversó con uno de los empleados de soporte directamente en la sección Mensajes. El diálogo comenzó instantáneamente cuando había un operador libre en el sistema. De lo contrario, también se creó el chat y el usuario recibió un primer mensaje automático "El operador se comunicará con usted en breve".

Nuevamente, un mínimo de cambios en el proceso de prueba. Este es un chat regular, y para él no fue necesario elaborar nuevos planes de prueba. U - conveniencia!
Pero para garantizar el trabajo de los empleados, el sistema se creó desde cero. Lo que se necesitaba era un sistema rápido que permitiera el trabajo simultáneo para varias docenas de empleados en línea y que pudiera procesar miles de llamadas por día.

El desarrollo y las pruebas fueron iterativos. Aproximadamente una vez a la semana agregamos nuevos módulos funcionales al sistema, lo que nos permitió no guardar tareas y cubrir gradualmente el sistema con pruebas. Recopilé casos de texto para probar, al tiempo que resaltaba los que podían automatizarse. El proceso de desarrollo de un prototipo completamente funcional nos llevó unos cinco meses.
Como resultado, obtuvimos un servicio web donde un operador operador podía iniciar sesión y aceptar solicitudes de los usuarios para su procesamiento. Para un grupo de empleados de apoyo, realizamos pruebas A / B varias veces para comprender en esta etapa lo convenientes y comprensibles que son para trabajar en el nuevo sistema. Fue una experiencia gratificante. Pudimos probar el sistema oSupp en la carga creada artificialmente de nuestro entorno de prueba. Sin embargo, esto no garantiza que en el mundo real no tengamos problemas.
En febrero de 2017, comenzamos a introducir un nuevo sistema en el entorno del producto. Como escribí anteriormente, al contactar al servicio de atención al cliente, el usuario debe seleccionar el tema de contacto. Para las primeras pruebas del sistema en usuarios reales, seleccionamos varios temas para los cuales la carga era mínima. El sistema funcionó de esta forma durante aproximadamente una semana. Las pruebas A / B no fueron necesarias para los usuarios, ya que prácticamente no hubo cambios en la funcionalidad del portal. En el lado de oSupp, los tres operadores en línea manejaron la carga. Rápidamente rastreamos problemas que podrían solucionarse de inmediato, como El nuevo sistema oSupp ya no estaba vinculado a las actualizaciones del portal principal. Ahora podríamos actualizar el sistema y solucionar problemas cuando quisiéramos. U - conveniencia!
Poco a poco, aumentamos la cantidad de temas procesados a través del nuevo sistema. Con una implementación tan fluida, no solo pudimos controlar la carga, sino que también capacitamos gradualmente al personal de soporte para trabajar con el nuevo sistema sin la necesidad de distraerlos del resto del trabajo. A mediados del verano de 2017, el servicio en línea transfirió alrededor del 35% de las solicitudes a procesamiento. Ya un tercio de nuestro personal ha trabajado a través de oSupp. El sistema estaba cubierto con documentación, planes de prueba y las autocomprobaciones mínimas necesarias, que se iniciaron cuando se actualizó el sistema. Para diciembre de 2017, transferimos todas las aplicaciones de usuarios autorizados en línea.
El siguiente paso importante es proporcionar soporte en línea para los usuarios que experimentan problemas de autenticación. Se trata de aquellos que olvidaron la contraseña, fueron pirateados, bloqueados o simplemente usuarios con llamadas no estándar. El problema técnico clave en esta etapa: el sistema de mensajería OK.ru ha sido diseñado históricamente para la correspondencia de la forma "Usuario correcto (operador de soporte en nuestro caso) - Usuario correcto". Pero necesitábamos asegurar el trabajo de la situación "usuario OK (operador) - usuario no autorizado".
El equipo de soporte comenzó a trabajar estrechamente con el equipo de mensajes de OK.ru. Como resultado, se inventaron soluciones que permitieron directamente en la pantalla de inicio de sesión de OK.ru recibir chat en línea con un operador de servicio de soporte. Al mismo tiempo, el sistema oSupp ya existente y comisionado no requería cambios. Y la nueva esencia del chat en línea funcionó en el motor de mensajería OK.ru modificado. U - conveniencia!

Comenzamos a implementar esta decisión a principios de 2018. En términos de pruebas, tampoco hubo dificultades especiales, ya que Tal chat tenía un conjunto mínimo de funcionalidades. En primer lugar, lanzamos soporte para quejas de usuarios no autorizados de la web. Por el momento, se está implementando el soporte para tales quejas de las aplicaciones móviles.
Episodio 5: Resumen
Desde el estado del prototipo hasta un servicio totalmente operativo, oSupp se mudó al verano de 2018. A partir de marzo de 2019, el 60% de las solicitudes se procesan a través del soporte en línea. El personal no fue cambiado. 90 empleados del servicio de asistencia en línea cubren alrededor de 6,000 quejas de usuarios diariamente. Durante la actividad máxima en el portal, esperar una respuesta del operador toma hasta 10 minutos. Bajo carga de trabajo normal, los operadores responden dentro de 1-2 minutos. Gracias al cambio a la comunicación en línea en vivo, la restauración exitosa del acceso de los usuarios al perfil ha crecido en un 15%.
Ahora tenemos el 100% de nuestro propio producto, somos libres de modificarlo como en cualquier momento. El equipo ya no depende de las actualizaciones del portal OK.ru. El nuevo sistema de procesamiento de aplicaciones está escrito en Java, que implementa muchos servicios OK.ru. El proceso de prueba del sistema oSupp está completamente cubierto por casos de prueba, y con actualizaciones está asegurado por pruebas automáticas.
Debo señalar que no hemos abandonado completamente OTRS. El sistema de soporte fuera de línea se congeló a mediados de 2017 y ahora está desempeñando el papel de un seguro. Hay llamadas de usuarios sin escrúpulos a quienes les gusta enviar correo no deseado al servicio de soporte. OTRS también procesa llamadas que, por razones específicas, los usuarios no pueden procesarse en línea. Ahora, los planes de nuestro equipo incluyen la implementación de procesamiento de llamadas desde aplicaciones móviles y la implementación del sistema chatbot.

Sin embargo, nuestro objetivo principal se logró: nos estamos alejando del uso del correo. Ahora, para resolver problemas, nuestros usuarios reciben respuestas rápidas y oportunas.
Nuestro principal logro: el usuario ha reducido significativamente el tiempo de espera para recibir una respuesta y recibir ayuda.