Hola Abrimos las grabaciones de video de los informes de Heisenbug 2018 Piter. Y especialmente para Habr, hicimos una selección de los diez mejores informes en opinión de los visitantes de la conferencia, expertos en el campo de las pruebas. ¡El tema más "offtopic" de repente resultó ser el informe que más me gustó!
Los informes en la selección se clasifican en orden creciente. Pero esto no significa que los "más jóvenes" sean mucho peores: todos, con la excepción de los líderes, tienen aproximadamente la misma calificación de 4.27 a 4.52. Por lo tanto, como de costumbre, debe ver todo. Nos vemos bajo el corte!
Automatización empresarial con selenio y por qué tiene muy poco que ver con selenio
Ponente:
Michael PalotasUbicación: 10
Valoración: 4.3 ± 0.1
Presentación del informeLa parte superior se abre con una presentación del creador de Selenium Grid, Michael Palotas. Michael fue responsable de las pruebas en eBay, ideó nuevas prácticas de ingeniería y logró trabajar en Intel, Ericsson y otras compañías.
Michael no solo habla de la herramienta de automatización Selenium en sí. Señala acertadamente que Selenium es un "dolor menor" en la automatización y las pruebas, y ofrece muchos ejemplos prácticos de cómo la implementación de la herramienta se convirtió en trabajo en un proyecto a gran escala completo que necesita ser mantenido y administrado.
Michael revela los principales problemas que impiden que los equipos de desarrollo creen soluciones escalables y confiables utilizando Selenium, y muestra formas claras y rentables de lograr la automatización completa de las pruebas.
¿Hay pruebas automáticas en videojuegos móviles?
Ponente:
Dmitry Alekseev / Evgeny ShumakovUbicación: 9
Valoración: 4.3 ± 0.1
Presentación del informeEn el pasado Heisenbug, Philip Keks ya había tocado el tema de las pruebas automáticas en juegos móviles, pero en su caso, el juego era con un juego muy simple. En el informe, Dmitry y Eugene de Zeptolab no son nada simples: ¿jugaron Cut the Rope o King of Thieves? ¿Cómo agregarles autotests, si todos los jugadores tienen dispositivos diferentes, no hay marcos y cómo rastrear errores?
Un informe de Dmitry y Eugene demuestra que nada es imposible en el desarrollo y las pruebas. Los probadores de Zeptolab han encontrado una forma bastante complicada de abstraer las coordenadas y volcar las escenas gráficas haciendo clic en las pruebas en Appium. El informe es fácil de entender incluso para personas de otro campo, y muestra bien en qué etapas es posible ahorrar tiempo y esfuerzos de los desarrolladores en el desarrollo de juegos móviles.
JUnit, dame cinco! Portar código a extensiones JUnit 5
Ponente:
Dmitry TuchsUbicación: 8
Valoración: 4.3 ± 0.1
Presentación del informeDmitry Tuchs declara con confianza: JUnit se crea para cualquier prueba. Acaba de aparecer JUnit 5, que recibió una nueva base de código, arquitectura y API, pero la simplicidad y expresividad del marco no se vieron afectadas.
En el informe, Dmitry demuestra claramente no solo el proceso de migración de la versión anterior de JUnit (¡solo reemplaza las anotaciones!), Sino también los diversos estilos de prueba que JUnit 5 admite, y responde a la pregunta: ¿cuál es el punto de cambiar a un nuevo marco en general?
El informe es útil para todos los evaluadores de Java que participan en pruebas en proyectos web a gran escala, escriben una funcionalidad de estilo AAA (Organizar - Actuar - Afirmar, y una de A al final del informe ya no es necesaria), y desean crear API simples para que los principiantes puedan trabajar con recubrimientos de prueba.
Pruebas basadas en redes de Petri
Ponente:
Alexey RodionovUbicación: 7
Valoración: 4.35 ± 0.05
Presentación del informeImagine que sus pruebas no pueden encontrar errores que ocurren en condiciones inusuales, y crear más y más pruebas ya no es posible, ya que el tiempo de ejecución excede todos los límites posibles.
Que hacer Vaya al aparato matemático en busca de formas alternativas de desarrollar pruebas usando gráficos. El comité del programa lo llamó "Prueba 2.0".
Un informe completo y completo de código Ruby de Alexei Rodionov sobre cómo Toptal cambió de las pruebas convencionales a las pruebas basadas en modelos matemáticos, lo bueno y lo malo que se puede encontrar en el camino, y por qué debe prestar atención a las redes de Petri para optimizar las pruebas.
Cuando se necesita velocidad y escala: servidor de dispositivos iOS distribuidos
Ponente:
Nikolay AbalovUbicación: 6
Calificación: 4.4 ± 0.2
Presentación del informeLos desarrolladores de pruebas de IU pueden estar familiarizados con el tema de las ejecuciones de prueba en iOS. Nikolai cita a Badoo como ejemplo: cuando comenzó a preparar el informe, hubo 1200 pruebas de extremo a extremo. Cuando se completa - 1300. En la conferencia, el número de pruebas aumentó a 1400. Esto es 35-40 horas de tiempo de máquina en el simulador, o 1.5 horas de tiempo real.
En el informe, Nikolai cuenta cómo logró reducir el tiempo de prueba a 30 minutos yendo al servidor del dispositivo, y cómo esto hizo que la infraestructura y las pruebas fueran más fáciles de escalar y mantener. Nikolay habla sobre cómo "desenredar" un nodo de las pruebas y la infraestructura, y aprende cómo ejecutar procesos en paralelo usando el nuevo modelo de paralelización. Para este informe, creamos una
versión de texto sobre Habré, para que no solo se pueda ver, sino también leer.
Finalmente, un consejo medio cómico de Nikolai: si necesita reducir el tiempo para aprobar las pruebas, simplemente elimine la parte. ¡Y se reducirá el tiempo, y no habrá más pruebas poco confiables, y es fácil de escalar! Si necesita más en serio, vea el informe en sí.
Pruebas de configuración para desarrolladores de Java: experiencia práctica
Ponente:
Ruslan ChereminUbicación: 5
Valoración: 4.4 ± 0.1
Presentación del informeEn una conferencia previa de Heisenbug, Andrei Satarin habló sobre cómo cubrir las pruebas no solo con el código, sino también con la configuración. Ruslan Cheremin trabajó en un equipo con Andrei y se inspiró para usar este enfoque para sus propios fines.
Ruslan en una forma accesible cuenta lo que puede considerarse una configuración (¡todo!), Cómo deshacerse de la vergüenza de escribir pruebas de configuración y por qué esto es importante, útil y bastante simple. Gran presentación con ejemplos simples, muchas inserciones de código y una explicación fácil de lo que está sucediendo.
Los probadores como sus propios peores enemigos
Ponente:
Michael BoltonUbicación: 4
Valoración: 4.46 ± 0.07
Presentación del informeEl legendario Michael Bolton con la nota final que todo probador debería ver.
No hablará sobre métodos, herramientas, marcos y mucho más. Michael habla sobre la esencia misma del probador, su papel en el mundo de TI, la importancia de la profesión y la interacción con las personas, no con las aplicaciones. La prueba no se trata de pruebas. Las pruebas son sobre personas.
Michael revela los problemas de la profesión de evaluadores, sugiere cómo desarrollar habilidades profesionales, sociales y mentales que no solo aumentarán la efectividad de un especialista, sino también el respeto entre colegas. Muy alegre, sincero e importante informe.
¿Todavía estás cortando tu informe? ¡Entonces vamos a ti!
Ponente:
Artyom EroshenkoUbicación: 3
Calificación: 4.52 ± 0.06
Presentación del informeEl lema principal del informe es "¿Qué problema estamos resolviendo?". Artyom describe clara y claramente los cambios en la esperada versión de Allure 3 y explica por qué se necesitan nuevas características: visualización, nuevas herramientas, una sola configuración y mucho más.
El informe es simple, interesante e intuitivo y será útil tanto para aquellos que han estado sentados en Allure durante mucho tiempo y no están familiarizados con informes de este tipo.
Pruebas fuzzing: buscando errores en el compilador JIT y no solo
Ponente:
Maxim KazantsevLugar: 2
Valoración: 4.6 ± 0.1
Presentación del informeHay un problema Es posible que las personas no se den cuenta de que un error en la aplicación puede estar relacionado con el compilador, y la probabilidad de errores en el compilador en sí es difícil de predecir, y encontrar un error y solucionarlo es aún más difícil.
Si en algunos informes las colecciones abogaban por reducir el número de pruebas, entonces, en los compiladores de pruebas, su propia atmósfera y sus propias reglas. Maxim Kazantsev, de Azul Systems, explica en un informe de segundo lugar cómo simplificar la vida tanto para aquellos que trabajan con compiladores como en direcciones completamente diferentes mediante pruebas Fuzzing.
Es simple: si una prueba "buena" encuentra un error con una probabilidad de 10-6, entonces no encuentra un error con una probabilidad de 0.999999. Y cinco millones de pruebas NO encontrarán un error con una probabilidad de 0.9999995000000 ≈ 0.007. Entonces, ¡hay un error con una probabilidad de más del 99%!
Este es un tipo de prueba en el que se generan millones de pruebas aleatorias que pasan por todo el proyecto, sin pensar en todo lo que encuentran. Y, curiosamente, este método ayuda perfectamente a encontrar problemas en los que necesita velocidad y un alto grado de fiabilidad.
Hardcore, informe de alta calidad con ejemplos de código. Asegúrese de buscar al menos debido a una forma interesante y no estándar de buscar (¡y encontrar!) Problemas en el código.
Pruebas hasta el final: patrones de diseño de interfaz sensible e inteligente
Ponente:
Vitaliy FridmanUbicación: 1
Valoración: 4.72 ± 0.06
Presentación del informeY aquí está el líder de nuestra breve lista, que, curiosamente, no se trata de probar en absoluto. ¡Vitaliy Fridman, conocido entre los diseñadores y desarrolladores web, habló ante un público atípico aquí y lo conquistó!
Vitaly pasa sistemáticamente por todas las etapas de UX y habla en detalle sobre los componentes de la interfaz y los problemas que están asociados con ellos y que pueden usarse en las pruebas. Esto incluye la implementación de "carruseles" en varios países, y consejos para crear comparaciones realmente convenientes de las características de los bienes (y no como siempre), y una lista de verificación útil para crear un "acordeón". Muchos espectadores dijeron: "Sí, no se trata de pruebas, pero fue increíble". Que tengas una linda vista!
Y para aquellos que no son pocas docenas, les damos un enlace a la
lista de reproducción , donde hay otras actuaciones con Heisenbug 2018 Piter.
Si está interesado en los informes, preste atención: Heisenbug 2018 Moscú se llevará a cabo del 6 al 7 de diciembre, a lo que acudirá el desarrollador de Selenium WebDriver Alexei Barantsev, que ha estado probando desde 1994.
La información más actualizada sobre el programa siempre se puede ver en el sitio web de la conferencia , y allí puede comprar boletos (cuyo precio aumenta gradualmente).