Alexey Barantsev é provavelmente uma das pessoas mais famosas nos testes na Rússia: ele é conhecido tanto pelo
software-testing.ru , como pelo
selenium2.ru , e pela participação no Selenium WebDriver, e não apenas. Ao mesmo tempo, ele também é um dos mais experientes: em testes já desde 1994. E quando se soube que ele falaria em nossa conferência Heisenbug com o
relatório "Problemas no Selenium WebDriver", queríamos perguntar a um palestrante. Começamos com perguntas sobre como os testes nos anos 90 diferiam de hoje e depois passamos para as realidades modernas.
- Entre os leitores da entrevista, pode haver pessoas que nem nasceram quando você já começou a testar. Diga, como então tudo era diferente dos nossos dias?- Se falamos sobre alguns fundamentos de testes (teoria, técnicas principais), então não há mudanças especiais. Mas, ao mesmo tempo, a automação de testes está mudando constantemente. Novas tecnologias de desenvolvimento aparecem e desaparecem e, com elas, as tecnologias e ferramentas projetadas para testar software surgem ou desaparecem. Como comparar o teste do que era na época e do que é agora? Enfim, para comparar, o que é melhor - costumava haver SOAP, agora REST. Em seguida, testamos serviços da Web escritos usando SOAP e agora aqueles escritos usando REST. Que diferença isso faz?
- Bem, algumas tecnologias não apenas "apareceram e desapareceram", mas se tornaram uma sem a qual agora é difícil imaginar a indústria: "Como vivemos sem o Git?"- Eles viviam normalmente sem o Git. Havia CVS, vivíamos bem com isso, depois havia Subversion, depois Git. Tudo isso não é tão interessante, mas o que realmente mudou muito é a velocidade. A velocidade do desenvolvimento e, com ela, a velocidade dos testes. Não se trata apenas de iterações curtas, Agile, a abordagem para organizar o horário de trabalho. É precisamente a velocidade do desenvolvimento do produto que mudou.
Quando começamos a trabalhar, em meados dos anos 90, tínhamos projetos que duravam seis meses, um ano, dois anos. Desenvolvimento e teste. Então esses projetos começaram a cair para três meses, dois. De fato, em dois meses a mesma coisa foi desenvolvida como no início de um ano. E agora o que acontece: as pessoas vêm ao hackathon, desenvolvem um produto em funcionamento em um dia, testam e lançam. É claro que este ainda é um protótipo, mas mesmo assim, por um dia. Era impossível imaginar isso.
Por que isso está acontecendo? Obviamente, as ferramentas estão evoluindo. Mas não é nem uma questão de ferramentas, algumas ainda escrevem código no vi ou no emacs. Mais importante, muitos códigos prontos já foram gravados; existem boas bibliotecas que foram exaustivamente testadas. Em algum lugar, você ainda precisa escrever muito do seu código, desenvolver algoritmos exclusivos e tudo ainda leva muito tempo lá. Mas em outras situações, você pode pegar componentes prontos, a partir deles rapidamente, como de um designer, montar o produto acabado. E, consequentemente, também é mais fácil testá-lo, porque já o estamos montando a partir de componentes testados e confiáveis. Isso mudou muito.
- E o que mudou na visão de mundo das pessoas - na maneira como encaramos os testes / desenvolvimento e o que esperamos delas?- Nos anos 90, desenvolvedores e testadores tinham mais fé nos padrões. Na verdade, o Agile não surgiu do zero, mas apenas por causa de decepções em todos esses padrões.
Primeiro, havia uma idéia de que os padrões nos salvariam de código de baixa qualidade: escreveremos tudo de acordo com os padrões e tudo se integrará bem ao trabalho. Talvez isso seja verdade, apenas os padrões estão sendo desenvolvidos muito lentamente, e tudo rapidamente corre para a frente e se torna obsoleto antes que os padrões sejam aceitos.
Em segundo lugar, havia confiança de que seria possível desenhar diagramas formalmente de acordo com diagramas UML, descrever requisitos de software e gerar automaticamente o código fonte, e tudo isso funcionaria e nem seria necessário testar. Supunha-se que em breve os desenvolvedores parariam de escrever código, em vez disso, desenhariam diagramas UML e descreveriam condições em alguma linguagem de alto nível. Não decolou, não deu certo. Embora naquela festa em que eu joguei, apostas muito grandes foram feitas sobre isso.
Agora, algum tipo de nova onda provavelmente começou: a inteligência artificial brota de todos os lugares e de todos os lugares, e novamente surge a ideia de que em breve os desenvolvedores não escreverão código. Em vez disso, alguns sistemas de inteligência artificial serão treinados e tudo funcionará por si só. Consequentemente, os testadores não terão que fazer nada. Os desenvolvedores treinam inteligência artificial e ele fará tudo. Vamos ver como será. Talvez funcione como da última vez.
- Vamos para o nosso tempo. Você está usando software-testing.ru. Para quem não o segue ativamente: o que está acontecendo lá?- Publicamos muito conteúdo, agora a parte principal é o conteúdo traduzido. Porque, francamente, na Rússia é muito difícil encontrar autores escrevendo sobre testes. Não sei por que aconteceu: houve um momento em que muita gente escreveu em russo e o combustível acabou ou, por algum motivo, não havia blogs e artigos suficientes no RuNet. E na parte em inglês da Internet, tudo isso ainda está florescendo, há muitos artigos escritos lá.
A comunicação mudou gradualmente para as salas de bate-papo, ou seja, as pessoas não escrevem textos, mas se comunicam. Isso não quer dizer que estamos seguindo essa tendência com muito cuidado. Participamos de bate-papos, mas não tentamos liderar essa tendência. Ainda estamos agindo à moda antiga, tentando dar às pessoas exatamente o conteúdo, e elas encontrarão um lugar para a comunicação.
- Agora as pessoas também estão se afastando dos textos para os blogs de vídeo - mas existe algo nos testes?- Nos testes, essa tendência é quase invisível. Existem literalmente um ou dois blogueiros em vídeo, casos isolados.
- Existe uma expressão "Se você quer entender algo de verdade - tente explicar para outras pessoas". E quando você edita sistematicamente os textos de outras pessoas, começa a entender melhor o tópico, incluindo os cantos, onde você mesmo não procuraria? É útil para um testador ser um editor também?- O trabalho editorial é bem diferente do leitor. A tarefa do editor não é entender o que está escrito no texto, mas não perder as falhas. Honestamente, isso não contribui para uma aparência holística. Quando selecionamos o material, eu o olho mais como um leitor: é interessante ler ou não. Neste momento ainda não sou editor. Mas quando olhamos para o texto traduzido e nos preparamos para a publicação, nesse caso, como editor. Para que durante a edição, durante a preparação para publicação, algo seja entendido - isso não acontece. Portanto, existem modos diferentes: um modo é o editor, o outro é o leitor.
- pergunta indiscreta. Existe publicidade em banner no software-testing.ru, mas no jornalismo comum é difícil monetizar com isso - é melhor no caso de testes ou não compensa o seu trabalho e o site existe por amor à arte?- Nenhuma receita de publicidade não compensa o trabalho no site. Existe para criar uma imagem, uma imagem, a fim de manter nossa presença na rede. E o centro de treinamento ganha de nós.
- A próxima pergunta é apenas sobre treinamento. Você ensina outras pessoas a testar há muitos anos, mas como isso afeta a maneira como você se vê?- Aqui o princípio que você mencionou um pouco antes funciona: enquanto você explica algo a alguém, você mesmo entenderá algo. Isso realmente ajuda a entender, entender. Quando você conta um tópico pela primeira vez, parece que tudo está claro. E então você assiste suas palestras, entende o que pode dizer melhor e refaz, algumas coisas novas aparecem. Depois disso, às vezes escrevo alguns artigos adicionais: primeiro você prepara o material para o curso e depois entende que precisa adicionar mais alguma coisa para torná-lo mais claro. E, claro, é ainda mais interessante receber algum tipo de feedback. As pessoas também estão dizendo algo interessante. Você recebe algum tipo de pergunta repentina, e somente aqui você entende que não entende. E que eu não achava que deveria pensar sobre isso. Isso é valioso.
- Quando você ensina muitas pessoas, começa a perceber alguns erros típicos de muitas pessoas. Você pode formular alguns "erros típicos do testador" em geral?- Um erro típico em geral de qualquer pessoa é que a maioria das pessoas em TI tenta aprender tudo com sua própria experiência, passar por todas as tarefas. Do meu ponto de vista, é mais lógico mudar de maneira diferente: estudar alguma coisa e só depois prosseguir com o trabalho.
A este respeito, sou uma pessoa atípica. Quando compro alguns eletrodomésticos, primeiro me sento e leio as instruções. Portanto, transferir minha própria experiência psicológica para outras pessoas é bastante difícil para mim. Eu entendo que sim, a maioria das pessoas não age assim, elas dão a volta primeiro e depois começam a descobrir como evitar isso. Eu acredito que isso está errado, e eles acreditam que está certo.
- Agora eu quero perguntar sobre o Selenium. Como a comunidade do Selenium Driver e todo o ecossistema ao seu redor entram na comunidade? Existem etapas e realizações? Por exemplo, "faça dez solicitações de recebimento e vá para a próxima etapa".- Não há procedimento padrão, regulamentos ou critérios de seleção específicos. Tudo é completamente individual. Quando você vê que uma pessoa já está envolvida, ela recebe gradualmente mais direitos. Esse processo de login acontece de maneira diferente para todos. Alguém começa a corrigir bugs e envia solicitações pull. E alguém começa a responder aos usuários da lista de discussão: temos uma pessoa responsável por trabalhar com usuários que não têm um único commit no código, mas na verdade ele mantém a lista de discussão. Alguém está escrevendo documentação -
essa é uma tarefa que também envolve trabalhar com o código-fonte, mas, é claro, a maioria das pessoas percebe a participação no projeto especificamente com solicitações de recebimento.
Há um problema organizacional com solicitações pull relacionadas ao fato de não termos funcionários suficientes, portanto, as solicitações pull podem permanecer por um período muito longo e ninguém as considera. Portanto, você deve ser persistente para ser notado. Você não precisa apenas enviar uma solicitação de recebimento, é necessário quebrá-la. Aqueles que quebram esse filtro conseguem, gradualmente, entrar no projeto.
- E para quem escrever para romper?- Sim, escreva para todos. No bate-papo do IRC, peça para avaliar a solicitação de recebimento. Em geral, existem filtros não técnicos através dos quais uma pessoa penetra gradualmente. E se você fez uma solicitação pull e aguarde até ser convidado para o projeto, não, eles não serão.
- Quero intuitivamente supor que, se uma ferramenta muito popular entre os testadores estiver sendo desenvolvida, ela mesma foi testada com muito mais profundidade do que o projeto de TI médio. O exemplo do Selenium confirma isso ou não?- Eu não sei sobre o "projeto médio", mas o Selenium é realmente testado completamente. Existem muitos testes, os testes estão funcionando constantemente, eles estão constantemente encontrando erros, incluindo erros de regressão, incluindo erros de regressão nos navegadores. Escrevo regularmente relatórios de erros para desenvolvedores de navegadores.
Parece-me que a situação com os testes é bastante próspera, embora eu não possa dizer que os testes sejam escritos em toda parte de forma completamente sistemática: afinal, eles também cresceram organicamente nos últimos vinte anos. Se você começar a escrevê-los do zero, pegue a especificação e projete-a com cuidado; provavelmente, seria melhor escrever muitos testes de uma maneira diferente. Mas até agora não se pensou em sentar e reescrever completamente parte dos testes, os testes cultivados organicamente estão lidando com sua tarefa.
- Freqüentemente há disputas sobre "qual navegador é melhor" e, como você envia relatórios de erros, é interessante comparar do lado não-padrão: quais navegadores têm a melhor resposta aos relatórios de erros e quais são piores?- Eu não gostaria de ofender ninguém, então não vou criticar ninguém, mas posso elogiá-lo. Os desenvolvedores do Firefox reagem melhor. Eles são os mais envolvidos, os mais ativos em termos de trabalho com relatórios de erros. O que talvez corresponda ao espírito de código aberto.
E o mais irritante não é a reação das equipes aos relatórios de erros. É isso que as empresas que desenvolvem navegadores de código fechado (Microsoft, Apple) possuem um rastreador de erros fechado. Ou seja, ao encontrar um bug, você não pode ver se alguém já enviou um relatório de bug, esse é um bug conhecido.
- Há alguns anos, você disse que a tarefa do Selenium é se tornar um padrão da web. Ele se tornou e depois o que? Qual é o próximo grande marco?- Capture o mundo em face das ferramentas de automação. Ou seja, precisamos garantir que todo esse novo padrão seja suportado.
- Ou seja, tornar-se um módulo interno para todas as outras novas ferramentas de automação da interface do usuário?Sim. Ou seja, eles podem usar mais dez outros módulos, mas todos devem poder trabalhar com o protocolo padrão.
Dentro do Selenium, há a seguinte tarefa importante, que será resolvida primeiro por algumas implementações de protótipos e depois dentro da estrutura do padrão. O protocolo HTTP é basicamente unidirecional, ou seja, um lado envia solicitações, o outro as processa e praticamente não há feedback. E isso não é muito bom, e é precisamente aqui que os concorrentes estão apontando muito ativamente isso, pressionando esse ponto dolorido, porque eu gostaria, grosso modo, de ter retornos de chamada. Quando alguns eventos ocorrem no navegador, eu gostaria de receber algumas notificações sobre isso. Isso ainda não está na ferramenta Selenium. Mas nós realmente queremos adicionar isso. Então, talvez, mudanças cardeais ocorram, uma mudança de protocolo é possível. Sem isso, será difícil. Precisamos de um protocolo de mão dupla.
"Você e Simon Stewart são os principais colaboradores da Selenium, certo?"- Isso é verdade quando se trata da parte Java.
"Até onde eu sei, você nunca conheceu." Como isso aconteceu? Os desenvolvedores de selênio não têm nenhum "corporativo"?- “Partes corporativas” que temos sob a forma de reuniões em conferências, mas separadamente - não. E, no caso de conferências, Simon chegou a Moscou no ano passado, Heisenbug, mas eu não estava em Moscou naquele momento, então não nos cruzamos.
Mas, francamente, agora vivemos em um mundo tão bom que ainda nos comunicamos constantemente.
- A pergunta final, finalmente. O que você acha que será o futuro dos testes de automação em geral e da interface do usuário em particular?- Não gosto de fazer previsões, porque quase nunca se tornam realidade. Os testes estão atrasados no desenvolvimento, com algum atraso; Portanto, os desenvolvedores ditam a moda: eles foram divididos de maneira amigável em JS - nos testes também, todos foram divididos em JS. E precisaremos acompanhar as mudanças. E o que os desenvolvedores terão - quem sabe.
Alexey se apresentará no Moscow Heisenbug de 6 a 7 de dezembro - e além dele, haverá dezenas de outros palestrantes. No site da Heisenbug, você pode ver o programa completo e comprar um ingresso.