Alexey Barantsev es probablemente una de las personas más famosas en las pruebas rusas: es conocido tanto por
software-testing.ru , como por
selenium2.ru , y por su participación en Selenium WebDriver, y no solo. Al mismo tiempo, también es uno de los más experimentados: en pruebas ya desde 1994. Y cuando se supo que hablaría en nuestra conferencia de Heisenbug con el
informe "Problemas en Selenium WebDriver", quisimos preguntarle a ese orador. Comenzamos con preguntas sobre cómo las pruebas en los años 90 diferían de las actuales, y luego pasamos a las realidades modernas.
- Entre los lectores de la entrevista puede haber personas que ni siquiera han nacido cuando ya comenzó a realizar la prueba. Dile, ¿cómo fue entonces todo diferente de nuestros días?- Si hablamos de algunos fundamentos de las pruebas (teoría, técnicas clave), entonces no hay cambios especiales. Pero al mismo tiempo, la automatización de pruebas, por supuesto, cambia constantemente. Aparecen y desaparecen nuevas tecnologías de desarrollo, y con ellas surgen o desaparecen las tecnologías y herramientas diseñadas para probar el software. ¿Cómo se puede comparar la prueba de lo que era entonces y lo que es ahora? De todos modos, para comparar, que es mejor: solía haber SOAP, ahora REST. Luego probamos los servicios web escritos usando SOAP, y ahora aquellos escritos usando REST. ¿Qué diferencia hace?
- Bueno, algunas tecnologías no solo "aparecieron y desaparecieron", sino que se convirtieron en una sin la cual ahora es difícil imaginar la industria: "¿Cómo pudimos vivir sin Git?"- Vivían normalmente sin Git. Hubo CVS, vivimos bien con él, luego hubo Subversion, luego Git. Todo esto no es tan interesante, pero lo que realmente cambió mucho es la velocidad. La velocidad de desarrollo, y con ella la velocidad de las pruebas. Ni siquiera se trata de iteraciones cortas, Agile, el enfoque para organizar las horas de trabajo. Es precisamente la velocidad del desarrollo del producto lo que ha cambiado.
Cuando comenzamos a trabajar, a mediados de los 90, teníamos proyectos que duraban seis meses, un año, dos años. Desarrollo y pruebas. Luego, estos proyectos comenzaron a disminuir a tres meses, dos. De hecho, en dos meses se desarrolló lo mismo que a principios de año. Y ahora, lo que sucede: la gente viene al hackathon, desarrolla un producto que funciona en un día, lo prueba y lo lanza. Está claro que esto sigue siendo un prototipo, pero no obstante, por un día. Era imposible imaginar esto.
¿Por qué está pasando esto? Por supuesto, las herramientas están evolucionando. Pero ni siquiera es una cuestión de herramientas, algunas aún escriben código en vi o emacs. Más importante aún, ya se ha escrito una gran cantidad de código listo; hay buenas bibliotecas que se han probado exhaustivamente. En algún lugar, aún necesita escribir una gran cantidad de su código, desarrollar algoritmos únicos, y todo aún lleva mucho tiempo allí. Pero en otras situaciones, puede tomar componentes listos, de ellos rápidamente, como de un diseñador, ensamblar el producto terminado. Y, en consecuencia, también es más fácil probarlo, porque ya lo estamos ensamblando a partir de componentes confiables y probados. Esto ha cambiado mucho.
¿Y qué ha cambiado en la visión del mundo de las personas, en cómo vemos las pruebas / desarrollo y qué esperamos de ellos?- En los años 90, tanto los desarrolladores como los evaluadores tenían más fe en los estándares. En realidad, Agile no surgió desde cero, sino solo por decepciones en todos estos estándares.
En primer lugar, surgió la idea de que los estándares nos salvarán del código de baja calidad: escribiremos todo de acuerdo con los estándares, y todo se integrará bien, funcionará. Tal vez esto sea incluso cierto, solo los estándares se están desarrollando muy lentamente y todo avanza rápidamente y se vuelve obsoleto antes de que se acepten los estándares.
En segundo lugar, había confianza en que sería posible dibujar diagramas formalmente de acuerdo con los diagramas UML, describir los requisitos de software y generar automáticamente el código fuente, y todo esto funcionaría, y ni siquiera sería necesario probarlo. Se suponía que pronto los desarrolladores dejarían de escribir código, en su lugar dibujarían diagramas UML y describirían condiciones en algún lenguaje de alto nivel. No despegó, no funcionó. Aunque en esa fiesta a la que acudí, se hicieron grandes apuestas sobre esto.
Ahora, probablemente ha comenzado algún tipo de nueva ola: brota inteligencia artificial de todas partes y de todos los lugares, y nuevamente surge esta idea de que pronto los desarrolladores no escribirán código. En cambio, se entrenarán algunos sistemas de inteligencia artificial, y todo funcionará por sí solo. En consecuencia, los evaluadores no tendrán que hacer nada. Los desarrolladores entrenarán inteligencia artificial, y él hará todo. Veamos cómo será. Tal vez funcione como la última vez.
- Pasemos a nuestro tiempo. Estás utilizando software-testing.ru. Para aquellos que no lo siguen activamente: ¿qué está pasando allí?- Publicamos mucho contenido, ahora la parte principal es el contenido traducido. Porque, francamente, en Rusia es muy difícil encontrar autores que escriban sobre las pruebas. No sé por qué sucedió: hubo un momento en que mucha gente escribió en ruso, y luego se les acabó el combustible o, por alguna razón, no había suficientes blogs y artículos en RuNet. Y en la parte de Internet en inglés, todo esto sigue floreciendo, hay muchos artículos escritos allí.
La comunicación se trasladó gradualmente a las salas de chat, es decir, las personas no escriben textos, sino que se comunican. Esto no quiere decir que estamos siguiendo esta tendencia con mucho cuidado. Participamos en chats, pero no intentamos liderar esta tendencia. Todavía estamos actuando a la antigua usanza, tratando de dar a las personas exactamente el contenido, y encontrarán un lugar para la comunicación.
- Ahora la gente también se está alejando de los mensajes de texto a los blogs de video, pero ¿existe tal cosa en las pruebas?- En las pruebas, esta tendencia es casi invisible. Hay literalmente uno o dos video bloggers, casos aislados.
- Hay una expresión "Si quieres entender algo de verdad, trata de explicárselo a los demás". Y cuando edita sistemáticamente los textos de otras personas, ¿comienza a comprender mejor el tema, incluidos los rincones, donde usted mismo no miraría? ¿Es útil para un probador ser editor también?- El trabajo editorial es bastante diferente del lector. La tarea del editor no es comprender lo que está escrito en el texto, sino más bien no perderse las fallas. Honestamente, esto no contribuye a una apariencia holística. Cuando seleccionamos material, lo veo más como lector: ¿es interesante leerlo o no? En este momento todavía no soy editor. Pero cuando miramos el texto traducido y nos preparamos para la publicación, en este caso como editor. De modo que durante la edición, durante la preparación para la publicación, se entiende algo: esto no sucede. Así que hay diferentes modos: uno es el editor, el otro es el lector.
- Pregunta indiscreta. Hay publicidad publicitaria en software-testing.ru, pero en el periodismo regular es difícil monetizar con ella: ¿es mejor en el caso de las pruebas o no compensa su trabajo y el sitio existe por amor al arte?- Sin ingresos publicitarios no compensa el trabajo en el sitio. Existe para crear una imagen, una imagen, para mantener nuestra presencia en la red. Y el centro de formación gana de nosotros.
- La siguiente pregunta es solo sobre entrenamiento. Usted ha estado enseñando a otros a realizar pruebas durante muchos años, pero ¿cómo afecta esto a la forma en que usted se evalúa?- Aquí el principio que mencionaste un poco antes funciona: mientras le explicas algo a alguien, tú mismo entenderás algo. Realmente ayuda a comprender mejor, comprender. Cuando cuenta un tema por primera vez, parece que todo está claro. Y luego ves tus conferencias, entiendes lo que puedes decir mejor, rehacer, aparecen algunas cosas nuevas. Después de eso, a veces escribo algunos artículos adicionales: primero prepara el material para el curso, y luego comprende que necesita agregar algo más para aclararlo. Y, por supuesto, es aún más interesante obtener algún tipo de retroalimentación. La gente también dice algo interesante. Se te hace algún tipo de pregunta repentina, y solo aquí entiendes que no entiendes. Y que no pensé en absoluto que debería pensar en ello. Esto es valioso
- Cuando enseñas a muchas personas, comienzas a notar algunos errores típicos de muchas personas. ¿Puedes formular algún "error de prueba típico" general?- Un error típico en general de cualquier persona es que la mayoría de las personas en TI intentan aprender todo de su propia experiencia, pasan por todos los rastrillos. Desde mi punto de vista, es más lógico moverse de una manera diferente: estudiar algo, y solo después de eso proceder con el trabajo.
En este sentido, soy una persona atípica. Cuando compro algunos electrodomésticos, primero me siento y leo las instrucciones. Por lo tanto, transferir mi propia experiencia psicológica a otras personas es bastante difícil para mí. Entiendo que sí, la mayoría de las personas no actúan así, primero van alrededor del rastrillo y luego comienzan a descubrir cómo evitar esto. Creo que esto está mal, y ellos creen que está bien.
- Ahora quiero preguntar sobre Selenium. ¿Cómo entran en la comunidad la comunidad de Selenium Driver y todo el ecosistema que la rodea? ¿Hay pasos y logros? Por ejemplo, "haga diez solicitudes de extracción y vaya al siguiente paso".- No existe un procedimiento estándar, ni regulaciones, ni criterios de selección específicos. Todo es completamente individual. Cuando ve que una persona ya está involucrada, gradualmente se le otorgan más derechos. Este proceso de inicio de sesión ocurre de manera diferente para todos. Alguien comienza a corregir errores y envía solicitudes de extracción. Y alguien comienza a responder a los usuarios en la lista de correo: tenemos una persona responsable de trabajar con los usuarios que ni siquiera tiene un solo compromiso con el código, pero en realidad tiene la lista de correo. Alguien está escribiendo documentación.
Esta es una tarea que también implica trabajar con el código fuente, pero, por supuesto, la mayoría de las personas perciben la participación en el proyecto específicamente con solicitudes de extracción.
Existe un problema de organización con las solicitudes de extracción relacionadas con el hecho de que no tenemos suficientes trabajadores, por lo que las solicitudes de extracción pueden mentir durante mucho tiempo y nadie las considera. Por lo tanto, debe ser persistente para ser notado. No solo necesita enviar una solicitud de extracción, sino que debe romperla. Aquellos que rompen este filtro luego logran ingresar gradualmente al proyecto.
- ¿Y a quién escribir para romper?- Sí, escribe a todos. En el chat IRC, pida evaluar la solicitud de extracción. En general, existen filtros no técnicos a través de los cuales una persona penetra gradualmente. Y si hiciste una solicitud de extracción y esperas hasta que te inviten al proyecto, entonces no, no lo harán.
- Intuitivamente, quiero suponer que si se está desarrollando una herramienta muy popular entre los probadores, entonces se ha probado mucho más a fondo que el proyecto de TI promedio. ¿El ejemplo de Selenium confirma esto o no?- No sé sobre el "proyecto promedio", pero Selenium realmente se prueba bastante a fondo. Hay muchas pruebas, las pruebas funcionan constantemente, constantemente encuentran errores, incluidos los errores de regresión, incluidos los errores de regresión en los navegadores. Regularmente escribo informes de errores a los desarrolladores del navegador.
Me parece que la situación con las pruebas es bastante próspera, aunque no puedo decir que las pruebas estén escritas de manera completamente sistemática: después de todo, también han crecido orgánicamente en los últimos veinte años. Si comienza a escribirlos desde cero, tome la especificación y la diseñe cuidadosamente, entonces, probablemente, sería mejor escribir muchas pruebas de una manera diferente. Pero hasta ahora no se pensaba sentarse y reescribir completamente alguna parte de las pruebas, las pruebas cultivadas orgánicamente están haciendo frente a su tarea.
- A menudo hay disputas sobre "qué navegador es mejor", y dado que les envía informes de errores, es interesante comparar desde el lado no estándar: ¿qué navegadores tienen la mejor respuesta a los informes de errores y cuáles son peores?- No quisiera ofender a nadie, así que no criticaré a nadie, pero puedo alabarlo. Los desarrolladores de Firefox reaccionan mejor. Son los más involucrados, los más activos en términos de trabajo con informes de errores. Lo cual, tal vez, solo coincide con su espíritu de código abierto.
Y lo más molesto no es la reacción de los equipos a los informes de errores. Esto es lo que las empresas que desarrollan navegadores de código cerrado (Microsoft, Apple) tienen un rastreador de errores cerrado. Es decir, cuando se encuentra con un error, no puede ver si alguien ya ha enviado dicho informe de error, ¿es un error conocido?
- Hace unos años dijiste que la tarea de Selenium es convertirse en un estándar web. Se convirtió, ¿y luego qué? ¿Cuál es el próximo gran hito?- Capture el mundo frente a las herramientas de automatización. Es decir, debemos asegurarnos de que todo este nuevo estándar sea compatible.
- Es decir, ¿convertirse en un módulo integrado para todas las otras nuevas herramientas de automatización de UI?- si. Es decir, pueden usar otros diez módulos más, pero todos deberían poder trabajar a través del protocolo estándar.
Dentro de Selenium existe la siguiente tarea importante, que se resolverá primero mediante algunas implementaciones de prototipos, y luego dentro del marco del estándar. El protocolo HTTP es básicamente unidireccional, es decir, un lado envía solicitudes, el otro las procesa y prácticamente no hay comentarios. Y esto no es muy bueno, y es precisamente aquí donde los competidores están señalando esto de manera muy activa, presionando este punto doloroso, porque me gustaría, en términos generales, tener devoluciones de llamada. Cuando se producen algunos eventos en el navegador, me gustaría recibir algunas notificaciones al respecto. Esto aún no está en la herramienta Selenium. Pero realmente queremos agregar esto. Entonces, tal vez, se producirán cambios cardinales, es posible un cambio de protocolo. Sin esto, será difícil. Necesitamos un protocolo bidireccional.
"Tú y Simon Stewart son los contribuyentes clave de Selenium, ¿verdad?"- Esto es cierto cuando se trata de la parte de Java.
"Que yo sepa, nunca te has conocido". Como sucedio Los desarrolladores de Selenium no tienen ningún "corporativo"?- "Fiestas corporativas" que tenemos en forma de reuniones en conferencias, pero por separado - no. Y en el caso de las conferencias, Simon incluso vino a Moscú el Heisenbug del año pasado, pero yo no estaba en Moscú en ese momento, así que no nos cruzamos.
Pero, francamente, ahora vivimos en un mundo que está bien, todavía nos comunicamos constantemente.
- La pregunta final, finalmente. ¿Cuál cree que será el futuro de las pruebas de automatización en general y de la interfaz de usuario en particular?- No me gusta hacer pronósticos, porque casi nunca se hacen realidad. Las pruebas están detrás del desarrollo con cierto retraso; Por lo tanto, los desarrolladores dictan la moda: se dividieron amigablemente en JS; en las pruebas también todos se metieron amigablemente en JS. Y necesitaremos mantenernos al día con los cambios. Y qué tendrán los desarrolladores, quién sabe.
Alexey actuará en el Heisenbug de Moscú del 6 al 7 de diciembre, y además de él, habrá docenas de otros oradores. En el sitio web de Heisenbug puede ver el programa completo y comprar un boleto.