DevOps: OK, pero ¿qué hacer? Cómo reducir el trabajo manual y lograr el resultado deseado

Entonces En 2018, en la Heisenbug (Conferencia de Pruebas de Moscú), Baruch Sadogursky (Defensor de Desarrolladores en JFrog) presentó una interesante nota clave, en la que habló sobre sus ideas básicas sobre dónde ir. En 2019, en el mismo Heisenbug, se realizó una secuela de su informe sobre CÓMO ir para lograr este objetivo. Por un lado, me gustaría apoyar la versión del movimiento de B. Sadogursky, que transmitió, pero en primer lugar todavía no lo sé, y en segundo lugar, me aventuraré a formular mi visión y describir mi camino personal basado en mi propia experiencia.

Dado

Para el contexto (es ficticio y cualquier coincidencia con casos reales es pura coincidencia), presentaremos a una empresa de proveedores de TI regionales con una unidad de desarrollo bastante grande. Dentro de esta unidad hay una función de prueba, que consiste en condicionalmente 30 personas de varios niveles de conocimiento y habilidades.

Empresa

La compañía presentada tiene varios productos que han estado en el lanzamiento durante mucho tiempo y la etapa inicial de su desarrollo se completó hace más de 7-8 años. Dado que la empresa es un proveedor, monitorea sus productos y los desarrolla regularmente, pero no los rehace desde cero. Esto significa que los productos contienen una gran cantidad de código heredado, soluciones tecnológicas y arquitectónicas "antiguas". No se consideraron las pruebas en estos productos en las etapas iniciales, antes de que su desarrollo se llevara a cabo según el principio de "más rápido, más rápido y en producción", pero hoy en día hay una gran cantidad de pruebas manuales, tanto de regresión como de prueba de nuevas funciones. Ideológicamente, el desarrollo de productos se lleva a cabo bajo la presión de las necesidades comerciales para que no haya tiempo para repensar las ideologías y refactorizar los productos mismos. Esto se hace solo en el momento en que todos entienden que esto no funcionará más allá de la palabra "completamente".

Además de los productos antiguos, la compañía está desarrollando soluciones completamente nuevas utilizando las últimas tecnologías y enfoques arquitectónicos. Pero aquí, no todo es fluido, ya que la presión general de las necesidades del negocio no disminuye. Las pruebas en tales proyectos ya están presentes en las primeras etapas de desarrollo, sin embargo, aún prevalecen las "soluciones manuales", que dan los resultados más rápidos y permiten a los desarrolladores escribir exclusivamente el código del producto sin pensar en cómo se probará.

Función de prueba

Ahora unas pocas palabras sobre la estructura: como dije, unas 30 personas son parte de la función de prueba. De estos, 17-19 es el enlace junior con experiencia en esta área de no más de 1 año. A menudo, se trata de personas sin educación técnica, pero con "ojos ardientes" y un gran deseo de trabajar en el campo de TI (por qué tienen este deseo es un tema aparte para el debate). Las 11-13 personas restantes son los gerentes superiores y medios: 3-4 personas representan a las personas mayores y 7-10 personas, el promedio. Toda la función de prueba se distribuye en 13-15 productos / proyectos diferentes con diferentes grados de participación, complejidad y participación.

Cultura

Esta es la última introducción.

Desafortunadamente, todavía hay algunos malentendidos sobre el valor que puede aportar la función de prueba. Esto se debe a que el resultado del trabajo en forma (por ejemplo) de una nueva característica es visible para todos, comprensible y prácticamente "tangible": cuando se implementa, la calidad general del producto aumenta y, al menos, no resulta vergonzoso para los productos de la compañía. Al mismo tiempo, existe un culto a los desarrolladores donde las siguientes afirmaciones son verdaderas: "El desarrollador es el jugador principal, y si no está allí, entonces el resto puede ser despedido", así como "Los desarrolladores son un recurso costoso y deberían escribir solo el código del producto y no distraerse con actividades sin importancia. ". Sobre la base de estas declaraciones, se ha formado una cierta "cultura" en esta empresa.

Declaración del problema.

Y como dicen, ¿cuál es el problema? ¿Por qué cambiar algo si todo funciona así? ¿Por qué mudarse a algún lugar si hay un modelo que funciona y esto genera dividendos?

Estas preguntas pueden surgir lógicamente en una persona que paga por todo el desarrollo. Pero hay esas 3-4 personas en la función de prueba que se consideran subestimadas, que vieron el primer informe de B. Sadogursky y no solo que ven el lado opuesto de la situación y les gustaría cambiar lo que está sucediendo para mejor y, por lo tanto, resolver algunos problemas "enfermos".

A continuación, pura fantasía y sugerencias basadas en materiales de varios autores y especialistas en el campo de TI.

Solución (posible)

Comencemos por definir metas y objetivos en el marco del cambio. Omitiremos conscientemente el lado mercantil y no lo plantearemos, este es un tema separado para el holivar, especialmente porque jugó un papel importante en la situación actual de esta empresa.

Dibujamos una imagen del futuro. ¿Por qué nos esforzamos?

En primer lugar, queremos en poco tiempo obtener un conjunto de productos de alta calidad (!) Que generen ganancias bastante altas. Debe comprender que "rentable" no significa "calidad".

¿Qué debemos hacer para lograr el objetivo? En primer lugar, propongo considerar el camino desde el punto de vista de la tecnología y no del comercio. Para lograr el objetivo, es necesario centrarse en el hecho de que los productos deben satisfacer las necesidades de los usuarios finales, a la vez que tienen bajos costos tanto para el desarrollo de nuevas funciones como para el mantenimiento de los que ya están en producción. Es decir, durante el desarrollo, debemos: a) comprender claramente el vector de movimiento, b) hacer que los productos sean lo suficientemente confiables para que no haya problemas con su funcionamiento, en términos simples, asegurarnos de que no haya errores cuando el usuario esté trabajando con el producto. En base a esto, deberíamos tener la denominada Política de cero errores para todos los productos, es decir, nuestras pruebas, como proceso, deberían darnos una garantía de la ausencia de errores de producción.

El segundo aspecto es el enfoque en el resultado final de todo el proceso de desarrollo, lo que nos permitirá no desarrollar lo que el usuario no puede usar o no puede entender CÓMO usarlo. Solo mencionamos la segunda parte de pasada, porque el tema es muy extenso, pero no funcionará sin tocarlo.

Por lo tanto, nuestro objetivo es: " Rápido, eficiente y por dinero razonable " (a bajo costo, lo más probable es que no pueda hacerlo de inmediato).

Ahora intentemos correlacionar lo que se dio con el propósito previsto.

Rápido Sí, es posible, pero ponemos en peligro la calidad: los procesos de garantía de calidad manual existentes podrán proporcionar suficiente velocidad de ejecución solo en productos pequeños con historias de usuario simples. Además, el perfil de la empresa es el desarrollo de soluciones bastante complejas para automatizar los procesos comerciales. Conclusión: "rápido" no funciona, ya que el trabajo manual a priori en grandes volúmenes perderá con cualquier solución automatizada.

Céntrate en el resultado . Es posible, pero requiere que los participantes generen el valor de una inmersión suficientemente profunda en el área temática y un gran tiempo dedicado a transmitir este valor al ejecutor final. Al mismo tiempo, los artistas intérpretes o ejecutantes son desarrolladores que, como parte de una de las declaraciones, deben pasar el máximo tiempo escribiendo código sin distraerse con el entorno.

De todo esto se deduce que para resolver el problema principal, es necesario involucrar no solo a expertos en control de calidad, sino también a desarrolladores en el proceso de prueba. Al mismo tiempo, para aumentar la velocidad de entrega del valor, es necesario considerar más cuidadosamente los procesos de automatización de la entrega y la automatización de la verificación de lo que se entrega.

¿Qué hay que hacer para resolver el problema principal?

En mi opinión, según la experiencia, requiere:

1. Sumerja más a los desarrolladores en los objetivos del producto de su producto;
   
2. Para convencer a las empresas de que los costos de automatización son importantes y proporcionar más beneficios económicos para todos los costos económicos.
   
3. Es aconsejable automatizar todo lo que se puede automatizar, para excluir al máximo el trabajo manual del proceso de entrega de valor.
   
4. Implemente la Política Zero Bug, sin la cual los usuarios enfrentarán problemas que repelen nuestros productos. Por cierto, un ejemplo exitoso de "DoDo" sugiere que esto es bastante factible.
   

¿Qué debemos hacer para convencer a los participantes de la necesidad de cambiar actitudes y visiones del mundo?

Desarrolladores

Cómo argumentar: ¿por qué necesitan hacer algo más además de su programación de código funcional favorita? Propongo centrarme directamente en los problemas que surgen con tal organización. Hay varios de ellos:

1. Desarrollando lo que nadie necesitará. En mi humilde opinión, este es uno de los primeros problemas. Los desarrolladores están haciendo algo, manteniendo la confianza de que lo están haciendo bien, pero al final obtienen el resultado incorrecto que el usuario final quería. Por qué Porque las tareas y los problemas no les son transmitidos por aquellos que finalmente usan el producto, sino por gerentes o clientes que posteriormente no usan estos productos. ¿Por qué está pasando esto? Todas las personas tienen diferentes puntos de vista. Si el desarrollador no se planteó una tarea puramente técnica, sino funcional, con una descripción del resultado en la salida (e incluso mejor, con una descripción del problema que esta tarea debería resolver), entonces habría una mayor comprensión del resultado y, como resultado, el número de casos de desarrollo de algo innecesaria se reduciría. Sí, esta es una verdad bien conocida, pero el problema aún no desaparece, debe resolverse con el negocio, justificando de una manera ligeramente diferente la formulación de tareas para el desarrollo. Acerca de cómo transmitir esto a la empresa, más allá.
   
2. La necesidad de cambiar entre contextos. A menudo, en el proceso de desarrollo con la presencia de pruebas manuales, los resultados de las pruebas llegan tarde, como resultado, el desarrollador tiene que distraerse resolviendo los problemas que aparecen como resultado de las pruebas. ¿Qué impide que los desarrolladores verifiquen después de la implementación su propio resultado? Hay dos puntos El primero es la falta de conocimiento y habilidades en el campo del aseguramiento de la calidad. El segundo: los desarrolladores a menudo piensan que este no es su trabajo y, como resultado, no quieren hacerlo. En uno de los primeros podcasts de RadioQA, hay un problema completo sobre el desarrollo sin probadores, que describe con suficiente detalle este efecto y las razones de esta "reticencia".
   

¿Cómo ayudarán las pruebas a los desarrolladores o cómo ayudarlos a resolver los problemas indicados?

1. Obtenga más información sobre el área temática o el propósito de las tareas a resolver. ¿Cuáles son las preguntas típicas que hace un desarrollador cuando presenta una tarea? “¿Cómo hacer esto?” “¿Y qué hay que hacer aquí?” “¿Y cómo hacer esto a pesar de que solo se sabe esto?” “¿Y cómo afectará esto a esa función?” Todas estas preguntas están destinadas a aclarar la implementación de la tarea , y No entender la variabilidad de esta tarea. ¿Qué hace un probador cuando se familiariza con una nueva descripción de una nueva función? También hace preguntas, pero de una manera ligeramente diferente: "¿Qué pasaría si?" "¿Por qué debería ser así?" "¿Qué debo obtener al final?" "¿Qué tengo al principio?" "¿Cómo debería estar relacionado? con eso? Es decir, casi todas las preguntas tienen como objetivo identificar exactamente el escenario del usuario y comprender el resultado de esta función.
   
   Que es importante Al hacer no solo preguntas aclaratorias (cómo implementar), sino también preguntas destinadas a comprender el resultado final, puede obtener más información sobre la tarea, hacer que los métodos esperados no solo sean familiares, sino también más simples y efectivos. En un escenario positivo, esto ayudará a no escribir código adicional o crear exactamente lo que el usuario final requiere, que es lo que necesitamos.
   
   Alguien preguntará: "¿Por qué debería, como desarrollador, estar interesado o debería pensar en ello?" Responderemos para no desarrollarnos "en la mesa". Los resultados de una encuesta de desarrolladores en mi entorno muestran cuán desmotivante es cuando haces algo, pero no lo liberes (ponlo en un estante).
   
2. Otra pregunta: "¿Por qué yo, como desarrollador, necesito hacer pruebas si tenemos probadores?" O "¿Por qué necesito desarrollar algún código adicional que no cumpla con las tareas establecidas del producto?" . Aquí puedes ofrecer algo más. Las pruebas automatizadas son esencialmente el mismo código que obedece las mismas leyes de programación con un ligero matiz. Cuando un desarrollador trabaja dentro del marco de un producto grande, se ve obligado a obedecer las reglas y tecnologías de desarrollo seleccionadas dentro del producto, y escribir en el lenguaje en el que está escrito este producto para usar los marcos utilizados en este producto. No es necesario hacer esto al escribir una prueba: nadie lo obliga a usar el mismo lenguaje o los mismos enfoques: al implementar pruebas automatizadas, puede probar fácilmente un idioma completamente nuevo y adquirir experiencia con él.
   
   Hay una regla simple a la que se adhieren los desarrolladores al escribir el código del producto: la optimización máxima de lo que está haciendo, el consumo óptimo de recursos, el rendimiento óptimo, (preferiblemente) la reutilización máxima, etc. Al desarrollar pruebas automatizadas, también hay reglas, hay plantillas, hay marcos, pero son diferentes. Su tarea es permitirles hacer el código de prueba lo más rápido posible, lo que funcionará ... Simplemente funcionará.
   
   La optimización y la velocidad de ejecución en las pruebas automáticas son puntos secundarios y no se recuerdan de inmediato. Entonces, si de repente quieres probar con Kotlin, Java o cualquier otro idioma, pero el proyecto está escrito en un idioma completamente diferente al que deseas (por ejemplo, en C #), puedes cambiarlo al deseado desarrollando pruebas automáticas.
   
3. “¿Cómo hago la prueba? No entiendo nada de esto. Solo soy un desarrollador ". Aquí, los probadores acudirán al rescate, o mejor dicho, ingenieros de control de calidad que conocen todas las tecnologías en las que está escrito el producto principal. Gracias a su conocimiento, pueden ayudar a educar a los desarrolladores sobre cómo y qué probar, cómo seleccionar los datos correctos, qué debe hacer el generador de datos para minimizar los riesgos por su tipo y a qué no debe prestarle atención. En ese tándem, los evaluadores aprovechan al máximo sus conocimientos y los desarrolladores no realizan trabajos innecesarios e innecesarios.
   
4. “Pero, ¿qué pasa con la velocidad? ¡Ella está sufriendo! Sí, ella sufrirá en las primeras etapas del desarrollo del proyecto, y sí, por supuesto, desde el principio, sumergirse en la automatización total es costoso. ¿Qué hacer para que los costos sean óptimos? Como mínimo, debemos entender claramente cómo y qué automatizar. Y también tiene sentido no cerrar irreflexivamente todo con pruebas y esforzarse por obtener una cobertura del 100% del código, sino hacerlo según el modelo de riesgo. Los ingenieros de control de calidad harán lo mismo.
   
5. "Velocidad! Queremos obtener entregas lo suficientemente rápidas. ¡También queremos que se nos confíe y nuestros productos estaban libres de errores! ” Aquí propongo cambiar el enfoque del desarrollo. Si solía estar de moda ejecutar todo en modo de depuración localmente, ahora a menudo para aplicaciones serias se necesita algo de infraestructura para funcionar. Aquí es donde todas las nuevas tendencias sobre dockereization y la implementación de varios stands son adecuadas. Otra cosa es importante: incluso en la primera etapa de desarrollo, debe pensar cómo se entregará a los puestos de trabajo, es decir, no solo desplegar todo a mano, sino configurar un proceso de implementación automatizado. ¿Qué nos dará? Cuando llegue el momento de la entrega a la producción, será suficiente para nosotros cambiar solo el punto de cálculo y no configurar todo el proceso desde cero. ¿Qué le dará esto al desarrollador? Más confianza en que está haciendo todo bien, porque los scripts de entrega se han verificado durante más de una ronda y no debería haber ningún problema en el lanzamiento con esto.
   

Negocios

¿Pero qué hay de los negocios? ¿Por qué debería estar interesado en esta transformación? ¿Por qué tiene sentido que invierta en este enfoque? Construyendo la explicación, seguiré el mismo camino. ¿Qué problemas tiene este negocio ahora, qué problemas tiene que resolver cuando trabaja en el campo de TI y cuando desarrolla productos de alta tecnología? Nuevamente, confiaré aquí precisamente en mi opinión:

1. "¿Qué puede no ser el más adecuado para el negocio?" A menudo, el desarrollo olvida que el producto no solo debe desarrollarse, sino también venderse, para lo cual se necesita una gama suficientemente grande de medidas, incluida la preparación para su entrada en el mercado. Hacer esto después de que se desarrolle el producto es un fracaso garantizado, razón por la cual la mayor parte del trabajo en la preparación de canales de venta y promoción de un nuevo producto comienza casi en el mismo momento en que comienza el desarrollo.
   
   “¿Qué sucede si el desarrollo se retrasa para la fecha de lanzamiento? ¿O el desarrollo traerá al mercado un producto de calidad insuficiente? ” Habrá pérdidas. Y no solo material, sino también reputacional. Es importante que las empresas se aseguren de que para cuando comiencen las ventas, el producto no solo estará listo, sino que también tendrá la calidad adecuada. Si hay etapas manuales de prueba en el proceso de desarrollo, inevitablemente será necesario reprogramar las fechas límite o tener en cuenta los riesgos de interrupciones en estas etapas. Es posible predecir el factor humano, pero es difícil y (mi opinión) no es menos costoso.
   
2. “¿Qué más le importa a la empresa?” Por supuesto, le preocupan las inversiones de capital en desarrollo. Pero las inversiones de capital, en su mayor parte, aunque voluminosas, se realizan en la etapa inicial, es decir. Antes del lanzamiento, o al menos antes del lanzamiento, los costos no se compensan con las ventas. Junto con las inversiones de capital, también hay gastos operativos, que comienzan a contribuir en la etapa operativa y es importante tratar de minimizarlos tanto como sea posible.
   
   "¿Por qué la automatización es bastante cara (en términos de gastos de capital) en este caso gana con respecto al enfoque manual?" Mi opinión es un factor obvio. La automatización es el mismo desarrollo. , . , , , , . , . ¿Por qué es esto importante? . , , « , , , » , , .
   
3. — . , . , , . , .
   
   ? , - . . , , , . , , , , , . , .
   

Supongamos que una empresa está de acuerdo con la necesidad de cambios en el proceso y está lista para "comprarlo todo de una vez". ¿Cuánto costará y qué gastos deberían incluirse?

1. , , , , . : X Y , , , X Z , Z < Y. : , , ( ) .
   
2. — QA-. , «» . , QA- , , , . : , , , , , .
   — , . . , , , , , , , , , . .
   
3. — . , , . , , , , . , QA-. , . , , «» — , , , . , , .
   
4. , , — (, , - ). . , . , , , , , (), .
   

Es imposible decir que este camino es definitivamente más rentable con respecto a una solución manual, pero toda su ventaja se revela en los deltas de los gastos operativos y la satisfacción del usuario final. Podemos comparar esto con la compra de un automóvil costoso pero confiable que no requiere gastos, excepto gasolina y mantenimiento regular, y la compra de un automóvil usado viejo. Sí, el precio de uno nuevo es más alto al principio, pero los costos operativos son más bajos y la comodidad y la "sensación de calma" son más altos. Con uno usado al inicio, los costos son bajos, pero durante la operación, los costos aumentan y después de un corto tiempo se pueden comparar con el costo de la compra inicial.

Adelante No olvide nuestro contexto y recuerde la composición de la función de prueba.

Probadores

¿Qué pasará con la función de prueba existente? Si volvemos a ver la composición de esta función, con un 90% de certeza podemos decir que el 60% de los empleados de toda la estructura no serán útiles en la nueva forma de la función, pero hay varios PERO.

Si recuerdas que mencionamos productos nuevos y viejos de nuestra empresa. La transición de nuevos productos al modelo de entrega descrito por mí será relativamente fácil, ya que aún no están en el lanzamiento o simplemente lo dejaron. Al mismo tiempo, los productos que han estado en funcionamiento durante mucho tiempo no permiten aplicar inmediatamente tales conceptos. Esto no significa que deba poner fin a ellos, hay algo que cambiar, pero no será rápido: mover el proceso del suelo para obtener procesos de entrega más confiables y rápidos.

Es por eso que la capa de la función de prueba "manual" no dejará de existir de la noche a la mañana, para esto tendrá que hacer un gran esfuerzo. Parte de los probadores "manuales" tendrán tiempo para convertirse en ingenieros de automatización o ingenieros de control de calidad. Es bastante obvio que durante este proceso de transición, el enlace intermedio y superior asumirá la función de apoyo: son los candidatos más probables para la integración en nuevos conceptos en los diferentes niveles de mañana. Un equipo de alto nivel con experiencia y conocimiento, también familiarizado con los conceptos de automatización y pruebas ShiftLeft, está listo para desempeñar el papel de ingenieros de control de calidad mañana, el enlace intermedio tomará algún tiempo, pero también podrán integrarse rápidamente en los roles de un ingeniero de control de calidad o ingeniero de automatización.

Definitivamente, aún no he respondido ninguna pregunta en este amplio tema. Estos son los que aún no entiendo. Esperando sus comentarios.