Oi Abrimos as gravações em vídeo dos relatórios Heisenbug 2018 Piter. E especialmente para a Habr, selecionamos os dez melhores relatórios na opinião dos visitantes da conferência - especialistas na área de testes. De repente, o mais "offtopic" acabou sendo o relatório mais apreciado!
Os relatórios na seleção são classificados em ordem crescente. Mas isso não significa que os “mais jovens” sejam muito piores: todos, com exceção dos líderes, têm aproximadamente a mesma pontuação de 4,27 a 4,52. Portanto, como sempre, você precisa assistir a tudo. Encontre-me sob o corte!
Enterprise Automation with Selenium e por que tem muito pouco a ver com Selenium
Palestrante:
Michael PalotasLocalização: 10
Classificação: 4,3 ± 0,1
Apresentação do relatórioA parte superior abre com uma apresentação do criador do Selenium Grid, Michael Palotas. Michael foi responsável pelos testes no eBay, criou novas práticas de engenharia e conseguiu trabalhar na Intel, Ericsson e outras empresas.
Michael não está falando apenas da ferramenta de automação Selenium. Ele observa, com razão, que o Selenium é uma “dor menor” em automação e teste e fornece muitos exemplos práticos de como a implementação da ferramenta se transformou em trabalho em um projeto de grande escala e completo que precisa ser mantido e gerenciado.
Michael revela os principais problemas que impedem as equipes de desenvolvimento de criar soluções escaláveis e confiáveis usando o Selenium, e mostra maneiras claras e econômicas de obter automação de teste completa.
Existe teste automático nos jogos para celular?
Palestrante:
Dmitry Alekseev / Evgeny ShumakovLocalização: 9
Classificação: 4,3 ± 0,1
Apresentação do relatórioNo passado, Heisenbugs, Philip Keks já havia abordado o tópico de autoteste em jogos para celular, mas no seu caso, o jogo era com uma jogabilidade muito simples. No relatório, Dmitry e Eugene, do Zeptolab, não são nada simples: eles jogaram Cut the Rope ou King of Thieves? Como adicionar autotestes a eles, se todos os jogadores têm dispositivos diferentes, não há estruturas e como rastrear bugs?
Um relatório de Dmitry e Eugene demonstra que nada é impossível no desenvolvimento e teste. Os testadores do Zeptolab criaram uma maneira bastante complicada de abstrair as coordenadas e o despejo de cenas gráficas, usando o Testium usando o Appium. O relatório é fácil de entender, mesmo para pessoas de um campo diferente, e mostra bem em que estágios é possível economizar tempo e esforços dos desenvolvedores no desenvolvimento de jogos para dispositivos móveis.
JUnit, me dê cinco! Portando código para extensões JUnit 5
Palestrante:
Dmitry TuchsLocalização: 8
Classificação: 4,3 ± 0,1
Apresentação do relatórioDmitry Tuchs declara com confiança: JUnit é criado para todos os testes. Acabou de aparecer o JUnit 5, que recebeu uma nova base de código, arquitetura e API, mas a simplicidade e expressividade da estrutura não foram afetadas.
No relatório, Dmitry demonstra claramente não apenas o processo de migração da versão anterior do JUnit (apenas substituindo anotações!), Mas também os vários estilos de teste que o JUnit 5 suporta e responde à pergunta - qual é o sentido de mudar para uma nova estrutura em geral.
O relatório é útil para todos os testadores Java que se envolvem em testes em projetos da Web em larga escala, escrevem funcionalidades no estilo AAA (não é mais necessário Organizar - Atuar - Assertar e um de A no final do relatório) e desejam criar APIs simples para que iniciantes possam trabalhar com revestimentos de teste.
Testes baseados em redes de Petri
Palestrante:
Alexey RodionovLocalização: 7
Classificação: 4,35 ± 0,05
Apresentação do relatórioImagine que seus testes não são capazes de encontrar erros que ocorrem em condições incomuns e criar mais e mais testes não é mais possível, pois o tempo de execução excede todos os limites possíveis.
O que fazer Vá para o aparato matemático em busca de maneiras alternativas de desenvolver testes usando gráficos. O comitê do programa chamou de "Testing 2.0".
Um relatório completo e hardcore de Alexei Rodionov, com código Ruby, sobre como Toptal passou de testes convencionais para testes baseados em modelos matemáticos, o que de bom e o ruim pode ser encontrado ao longo do caminho e por que você deve prestar atenção às redes de Petri para otimizar os testes.
Quando a velocidade e o dimensionamento são necessários: servidor de dispositivos iOS distribuídos
Palestrante:
Nikolay AbalovLocalização: 6
Classificação: 4.4 ± 0.2
Apresentação do relatórioOs desenvolvedores de teste de interface do usuário podem estar familiarizados com o problema das execuções de teste no iOS. Nikolai cita o Badoo como exemplo - quando ele começou a preparar o relatório, havia 1200 testes de ponta a ponta. Quando concluído - 1300. Na conferência, o número de testes aumentou para 1400. São 35-40 horas de tempo de máquina no simulador ou 1,5 horas de tempo real.
No relatório, Nikolai conta como ele conseguiu reduzir o tempo de teste para 30 minutos indo ao servidor do dispositivo e como isso tornou a infraestrutura e os testes mais fáceis de escalar e manter. Nikolay fala sobre como "desembaraçar" um nó dos testes e da infraestrutura e aprender como executar processos em paralelo usando o novo modelo de paralelização. Para este relatório, fizemos uma
versão em
texto no Habré, para que você possa não apenas vê-lo, mas também lê-lo.
Finalmente - um conselho meio cômico de Nikolai: se você precisar reduzir o tempo para passar nos testes - basta excluir a peça. E o tempo será reduzido e não haverá mais testes não confiáveis, e é fácil de escalar! Se você precisar mais a sério - consulte o próprio relatório.
Teste de configuração para desenvolvedores Java: experiência prática
Palestrante:
Ruslan ChereminLocalização: 5
Classificação: 4.4 ± 0.1
Apresentação do relatórioEm uma conferência anterior da Heisenbug, Andrei Satarin falou sobre como cobrir testes não apenas com código, mas também com configuração. Ruslan Cheremin trabalhou em equipe com Andrei e foi inspirado a usar essa abordagem para seus próprios propósitos.
Ruslan de uma forma acessível mostra o que pode ser considerado uma configuração (tudo!), Como se livrar do constrangimento de escrever testes de configuração e por que isso é importante, útil e bastante simples. Ótima apresentação com exemplos simples, muitas inserções de código e uma explicação fácil do que está acontecendo.
Testadores como seus piores inimigos
Palestrante:
Michael BoltonLocalização: 4
Classificação: 4.46 ± 0.07
Apresentação do relatórioO lendário Michael Bolton com a palestra final que todo testador deve assistir.
Ele não falará sobre métodos, ferramentas, estruturas e muito mais. Michael fala sobre a essência do testador, seu papel no mundo da TI, o significado da profissão e a interação com as pessoas, não com os aplicativos. Testar não é sobre testes. Testar é sobre pessoas.
Michael revela os problemas da profissão de testador, sugere como desenvolver habilidades profissionais, sociais e mentais que não apenas aumentarão a eficácia de um especialista, mas também o respeito entre os colegas. Relatório muito entusiasmado, sincero e importante.
Você ainda está vendo seu relatório? Então vamos até você!
Palestrante:
Artyom EroshenkoLocalização: 3
Classificação: 4.52 ± 0.06
Apresentação do relatórioO principal slogan do relatório é "Que problema estamos resolvendo?". Artyom descreve de maneira clara e clara as mudanças na tão esperada versão do Allure 3 e explica por que novos recursos são necessários - visualização, novas ferramentas, uma única configuração e muito mais.
O relatório é simples, interessante e intuitivo e será útil para aqueles que estão no Allure há muito tempo e não estão familiarizados com relatórios desse tipo.
Teste confuso: procurando bugs no compilador JIT e não apenas
Palestrante:
Maxim KazantsevLocal: 2
Classificação: 4.6 ± 0.1
Apresentação do relatórioHá um problema. As pessoas podem não perceber que um bug no aplicativo pode estar relacionado ao compilador, e a probabilidade de erros no próprio compilador é difícil de prever, e encontrar um bug e corrigi-lo é ainda mais difícil.
Se em alguns relatórios as coleções defendiam a redução do número de testes, então nos testadores os compiladores tinham sua própria atmosfera e suas próprias regras. Maxim Kazantsev, da Azul Systems, fala em um segundo lugar sobre como simplificar a vida de quem trabalha com compiladores e em direções completamente diferentes usando o teste do Fuzzing.
É simples: se um teste "bom" encontrar um bug com uma probabilidade de 10 a 6, ele não encontrará um bug com uma probabilidade de 0,999999. E cinco milhões de testes NÃO encontrarão um erro com uma probabilidade de 0,9999995000000 ≈ 0,007. Portanto, há um erro com uma probabilidade superior a 99%!
Esse é um tipo de teste no qual milhões de testes aleatórios são gerados que passam por todo o projeto, verificando sem pensar tudo o que eles encontram. E, curiosamente, esse método ajuda perfeitamente a encontrar problemas nos quais você precisa de velocidade e alto grau de confiabilidade.
Relatório incondicional e de alta qualidade com exemplos de código. Procure pelo menos por causa de uma maneira não padrão e interessante de procurar (e encontrar!) Problemas no código.
Testando até o fim: padrões de design de interface responsivos inteligentes
Palestrante:
Vitaliy FridmanLocalização: 1
Classificação: 4,72 ± 0,06
Apresentação do relatórioE aqui está o líder da nossa lista curta, que, por incrível que pareça, não é sobre testes. Vitaliy Fridman, conhecido entre os web designers e desenvolvedores da web, falou com um público atípico aqui e conquistou-o!
Vitaly passa sistematicamente por todos os estágios do UX e fala em detalhes sobre os componentes da interface e os problemas que estão associados a eles e podem ser usados nos testes. Isso inclui a implementação de "carrosséis" em vários países, e dicas para criar comparações realmente convenientes das características dos produtos (e não como sempre), e uma lista de verificação útil para criar um "acordeão". Muitos espectadores disseram: "Sim, não se trata de testes, mas foi incrível". Tenha uma bela vista!
E para aqueles que não são poucas dezenas, damos um link para a
lista de reprodução , onde há outras apresentações com o Heisenbug 2018 Piter.
Se você estiver interessado nos relatórios, preste atenção: o Heisenbug 2018 Moscou será realizado de 6 a 7 de dezembro, para o qual o desenvolvedor do Selenium WebDriver Alexei Barantsev, que está testando desde 1994, chegará.
As informações mais atualizadas sobre o programa sempre podem ser vistas no site da conferência e você pode comprar ingressos (cujo preço está aumentando gradualmente).