Vídeo

Na última Sexta-feira fui entrevistado pelo Daniel Wildt!

É sempre um prazer conversar com esse cara o qual me inspira desde que o conheci.

Na entrevista falamos sobre:

  • Questões relacionadas a minha mudança para a Noruega (trabalho e cultura)
  • Comunidades de prática (no Brasil e na Noruega)
  • Conteúdo (WordPress e Medium – Português e Inglês)
  • Meu primeiro livro – Testes end-to-end com Protractor

Não conseguiu assistir ao hangout ao vivo? Veja agora!

Espero que goste e tenha uma ótima semana!

Seriam os testes de UI flaky por natureza?

Quantas vezes você já ouviu que testes de UI (ou testes end to end) são flaky, frágeis, ou não confiáveis?

geek-and-poke

Pois é, há algum tempo estou realizando pesquisas à fim de escrever este post e hoje lhe trago algumas de minhas descobertas e também algumas dicas sobre tais flaky tests.

Porém, antes de começar trago uma sentença retirada do livro Entrega Contínua, de Jez Humble e David Farley, a qual considero conveniente:

“Ao seguir boas práticas e utilizar as ferramentas apropriadas, é possível reduzir drasticamente o custo da criação e manutenção de testes automatizados de aceitação ao ponto que que os benefícios claramente excedem os custos.”

Ok, agora podemos começar.

Conforme um artigo publicado no Google Testing Blog, até mesmo o Google sofre com testes flaky, seja por questões relacionadas a concorrência, por depender de comportamentos não definidos ou não determinísticos, por código frágil de terceiros, problemas de infra-estrutura, entre outros. Porém, algumas dicas interessantes deste mesmo artigo sugerem: ao encontrar testes flaky, coloque-os em quarentena para posterior investigação a fim de torná-los mais robustos e confiáveis; re-execute somente os testes que falharam para determinar se tais testes são mesmo flaky. Apesar de esta não ser uma solução perfeita, ao menos ajuda na diminuição de tempo investigando testes que podem ester falhando como falsos negativos, garantindo um feedback rápido após a execução dos testes.

Outro artigo relacionado, também do Google Testing Blog, demonstra questões relacionadas a testes de UI na teoria versus prática, do qual discordo em algumas questões, as quais irei explicar em breve. Neste, sugere-se que, em teoria, testes end to end são bons para: os desenvolvedores, pois a tarefa de escrevê-los fica a cargo de outros (normalmente dos testadores); os gerentes e tomadores de decisão, pois testes que simulam cenários reais dos usuários ajudam a determinar o impacto à estes em caso de falha; e para os testadores, pois estes se preocupam em não deixar bugs passarem, além de se preocuparem em não escrever testes que não verificam um comportamento do “mundo real”.

Neste mesmo artigo, na visão prática sobre testes end to end é que me fazem não concordar com alguns pontos, visto que tentam demonstrar as fragilidades de tais testes em um cenário onde outras bordagens poderiam ser tomadas a fim de melhor mitigar os problemas.

No exemplo citado no artigo, inicialmente os testes falham devido a uma falha real na aplicação, onde o sign in não está funcionando, e visto que a grande maioria dos cenários de testes dependem do sign in, esta grande maioria falha. Aqui o ponto é, crie testes independentes o quanto for possível. Neste caso, uma melhor abordagem, na minha opinião, seria um estágio anterior no pipeline onde somente um smoke test de testes de UI seria executado, e neste estaria o teste de sign in, porém, o feedback de tal suite de testes seria muito mais rápida e não comprometeria todo o restante ou a grande maioria dos testes. Além disso, havia realmente uma falha na aplicação, o sign in não estava funcionando.

Outro ponto do qual discordo quando “falam mal” dos testes end to end é demonstrado quando testes flaky são identificados somente na última bateria de testes, ou seja, até então realmente existiam problemas, sejam na aplicação, em uma aplicação de terceiros a qual a aplicação principal dependia, ou na infra-estrutura onde tal aplicação estava hospedada, ou seja, tais testes não estavam falhando à toa, ou ao menos não eram somente eles os culpados pelas falhas.

Porém alguns pontos interessantes a considerar são: encontrar a causa raiz de um teste end to end falhando não é tão simples; um teste falhando não beneficia o usuário final, até que o bug seja corrigido; e, testes end to end são lentos, quando comparados à testes de unidade, ou testes de integração.

Portanto, neste segundo artigo sugere-se seguir a tão falada pirâmide dos testes, sugestão a qual concordo plenamente, como forma de “fugir” dos testes flaky, visto que testes de unidade e de integração, além de proverem um feedback mais rápido após mudanças na aplicação, também facilitam em encontrar os problemas, uma vez que tais testes exercitam um escopo menor da aplicação quando comparados com testes end to end, os quais exercitam a aplicação como um todo.

Porém, existem maneiras para criar testes end to end mais rápidos e robustos, tais como a execução de testes em paralelo e a utilização de boas práticas de desenvolvimento de testes. Só não podemos nos enganar e achar que não haverão testes frágeis, cabe a nós identificá-los e trabalhar para melhorá-los.

Já neste artigo, chamado Front-End Testing Done Right, gostaria de levantar alguns pontos interessantes:

Primeiro: Muitos programadores não consideram a criação de testes automatizados como de sua responsabilidade. Neste contexto, sempre lembro de uma frase de Klaus Wuestefeld, na qual ele diz que: “Testar software manualmente, no século 21, é antiético, como um cirurgião operar sem lavar as mãos.” Ou seja, é responsabilidade ética do desenvolvedor criar testes automatizados.

Segundo: Se escrever testes automatizados parece difícil para os desenvolvedores algo está errado, ou eles não sabem como utilizar o framework de testes, ou este está escrito de forma incorreta. Aqui a mensagem é: “Todos temos que aprender. O tempo todo. É assim que é.”

Terceiro: “Um teste não confiável não é um teste.” E neste caso o melhor a fazer é deletá-lo (vale lembrar a possibilidade de colocá-lo em quarentena para torná-lo robusto).

Quarto: Conforme já comentado, considere a execução de testes em paralelo para diminuir o tempo de feedback da execução dos teste.

Quinto: identifique testes não determinísticos e encontre maneiras de testá-los de forma confiável, tal como: caso um teste dependa de determinados dados na aplicação para que seja executado, garanta que rotinas de escrita no banco de dados, por exemplo, sejam executadas, assim, tais dados estarão lá quando os testes forem executados. Ou então utilize alguma outra forma de injeção de dados na aplicação, mas faça isso.

Sexto: Aguarde pelo correto estado da aplicação, ou seja, em vez de colocar waits ou sleeps em seus testes, utilize validações de que tais elementos estão realmente disponíveis antes de tentar interagir com eles ou fazer verificações.

Sétimo: Identifique elementos por IDs sempre que possível e utilize Page Objects. IDs devem ser únicos e garantem que seus testes estão interagindo com os elementos corretos, portanto, sempre que um ID estiver disponível para um elemento o qual um teste precisa interagir ou fazer uma verificação, não hesite em utilizá-lo. E utilize Page Objects para fins de respeitar o princípio DRY (Don’t repeat yourself), este garante facilidade de manutenção dos testes.

Oitavo: Não teste tudo através da UI. Conforme já comentado a respeito da pirâmide dos testes, identifique qual a melhor camada para testar diferentes funcionalidades da aplicação, às vezes um teste de unidade já é o suficiente para testar determinada funcionalidade e evita a criação de testes flaky.

Nono: Testes devem poder ser executados independente de ambiente. Procure escrever testes que possam ser executados em ambiente local de desenvolvimento, ambiente de QA e até mesmo em ambiente de produção, se possível, isso diminui a incidência de testes flaky em um ambiente e confiáveis em outro.

Por fim, deixo uma mensagem final misturada com a mensagem final deste outro artigo, chamado Why System tests can’t replace Unit tests. Teste end to end e testes de unidade não existem pela mesma razão, apesar de ambos existirem para prover feedback rápido após mudanças na aplicação. Estes na verdade complementam um ao outro, portanto, se preocupe em escrevem ambos, e na medida certa. Enquanto testes de unidade lhe ajudarão com feedback em segundos e fácil debug quando problemas forem encontrados, testes de UI reduzirão drasticamente o tempo e a necessidade da execução de testes manuais, os quais estão sujeitos ao erro humano.

Como leituras complementares sugiro os seguintes posts:

The Forgotten Layer of the Test Automation Pyramid

Introducing the Software Testing Cupcake (Anti-Pattern)

Se você gostou deste post, compartilhe, curta, ou deixa um comentário!

Até a próxima! E bons testes!!

Simulando dispositivos móveis com o Protractor

Este é um post bem curto, mas acredito que será útil se você escreve testes automatizados utilizando o framework Protractor, e tem a necessidade de criar testes para aplicações que rodam em dispositivos móveis, tais como smartphones.

Ao criar scripts de teste, algumas vezes não basta somente redimensionar a janela do navegador para simular um dispositivo móvel. Esta abordagem pode não funcionar, por exemplo, se a aplicação que você está testando possui uma versão web específica para mobile, diferente de uma aplicação apenas responsiva.

Abaixo irei lhe mostrar o que adicionar no arquivo de configuração do Protractor, para simular um dispositivo Google Nexus 5, por exemplo:

Com esta única e simples configuração, você poderá então rodar seus testes simulando um dispositivo móvel real.

Espero que tenha gostado.

E por hoje é só pessoal!

Livro – Testes end-to-end com Protractor

Olá!

Ontem lancei através do Leanpub meu primeiro livro: Testes end-to-end com Protractor, o qual traz uma coleção de aprendizados sobre testes end-to-end automatizados com o framework Protractor.

O livro ainda não está completo, mas resolvi o lançar assim mesmo, para poder receber feedback dos leitores mais interessados e então ir aprimorando o mesmo.

Por enquanto o livro conta com quatro capítulos: introdução, boas práticas, Page Objects e helpers, porém, os seguintes capítulos estão por vir, sendo que o 5º já foi iniciado: node modules úteis, testes na nuvem, integração contínua, testes de revisão visual, testes em dispositivos móveis, ECMAScript 2015, configurações avançadas, ações e verificações, expected conditions, processo criativo na criação de testes e2e e dicas úteis.

Visto que o livro está em processo de criação, pode ser que existam erros de Português, portanto, ERRATAS são bem vindas.

Além disso, logo pretendo lançar o mesmo livro em sua versão em Inglês (tradução já iniciada).

Peço que me ajudem a divulgar o livro e aos que vierem a adquirir, estou empolgado em receber seu feedback!

Tenham uma ótima semana!

Os testadores devem escrever testes de aceitação automatizados…

…se os desenvolvedores não escrevem testes de unidade e de integração/APIs?

gestão-empreendedora

A ideia deste post veio de algumas experiências que tive ao longo da carreira, onde testadores e desenvolvedores trabalhavam em “silos” ao invés de trabalharem juntos em busca do desenvolvimento de softwares de qualidade.

Nesse contexto, se esperava dos integrantes do “time de testes” que estes não só realizassem testes manuais, mas também que escrevessem scripts de testes de aceitação automatizados, para garantir um bom conjunto de testes de regressão, os quais auxiliariam em um menor tempo de feedback após alterações na aplicação.

Por outro lado, e principalmente devido a esta divisão dos times em “silos”, os desenvolvedores pouco se preocupavam com a escrita de testes de unidade e testes de integração/APIs, e muito menos com a utilização de práticas, tais como o desenvolvimento guiado por testes (também conhecido como TDD), prática esta, que ajuda em um melhor design da aplicação. Para eles, testar era coisa do “time de testes/QA”.

Atualmente, vivemos uma bela transformação no que diz respeito à evolução das práticas de desenvolvimento de software, onde cada vez mais empresas e profissionais estão engajados na cultura de desenvolvimento de software de forma ágil e enxuta.

O primeiro valor do Manifesto Ágil diz: valorizar indivíduos e interações mais que processos e ferramentas.

Além disso, destaco também alguns dos princípios por trás deste manifesto. São eles:

  • Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
  • Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e suporte necessário e confie neles para fazer o trabalho.
  • O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através da conversa face a face.
  • Contínua atenção à excelência técnica e bom design aumenta a agilidade.
  • As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.

Se pararmos para analisar cada um destes itens com relação ao contexto que estou lhes trazendo, é possível perceber algumas questões que não fazem nenhum sentido nos dias de hoje, como por exemplo, a separação de times em silos, a desconfiança entre times, e a não partilha de conhecimentos.

Profissionais com foco em qualidade e teste de software devem ser capazes de ajudar a disseminar a cultura e o valor por trás dos testes automatizados, em todas as suas camadas (veja a pirâmide dos testes), assim, obtendo maior engajamento por parte dos desenvolvedores para a colocar tais atividades em prática, em conjunto.

E profissionais com foco em desenvolvimento de aplicações devem ser capazes de ajudar profissionais de QA com relação a práticas de código limpo, padrões, revisões, e utilização de ferramentas que ajudam nestas atividades, para que estes possam desenvolver scripts de testes de aceitação mais robustos e de fácil manutenção.

Também, quando falo da cultura de desenvolvimento de software de forma enxuta, me refiro, principalmente, a questão da eliminação de desperdícios, onde o quanto antes descobrirmos problemas na aplicação, menos estaremos desperdiçando tempo e recursos. Portanto, profissionais com diferentes focos, devem trabalhar juntos e se ajudar, para que no fim, além de entregarem aplicações de excelente qualidade, também se sintam satisfeitos, parte de um time, confiáveis e sintam que fazem a diferença.

Não vou responder a pergunta inicial deste post: Os testadores devem escrever testes de aceitação automatizados se os desenvolvedores não escrevem testes de unidade e de integração/APIs? Minha ideia com este post é que você, que está lendo, reflita, e então encontre você mesmo a resposta.

Aguardo teu feedback e tenha uma ótima semana!

=D

Congresso Nacional de Qualidade de Software

Entre os dias 25 e 31 de Julho de 2016 acontecerá o CNQSCongresso Nacional de Qualidade de Software, conferência on-line, na qual profissionais de tecnologia irão compartilhar seu conhecimento com a comunidade com assuntos atuais e para todos os gostos.

CNQS_transp

Não deixe de se inscrever, as vagas são limitadas!

Porquê integração contínua é tão importante?

Integração contínua, ou CI, é uma prática de desenvolvimento de software onde o código é continuamente integrado (ao menos uma vez por dia, por desenvolvedor), e de forma automatizada. CI também diz respeito a verificar se o novo código que você escreveu quebrou ou não o que já estava funcionando, uma vez que testes automatizados e outras tarefas automatizadas (tais como verificações de sintaxe) são executadas quando integrando o código.

CI

Utilizar tal abordagem permite que times de desenvolvimento de software tenham feedback rápido sobre as mudanças que estão fazendo em uma aplicação específica, além de ser uma maneira mais barata para correção de problemas quando estes são encontrados, visto que o código modificado ainda está fresco na memória dos desenvolvedores.

CI também é uma das práticas da disciplina de programação eXtrema, criada por Kent Beck e Ron Jeffries, em 1997. Após utilizarem CI (e outras práticas da XP) e terem bons resultados nos projetos nos quais trabalhavam, eles decidiram escrever a respeito, como uma forma de compartilhar tal conhecimento com o resto do mundo, para então, termos melhores softwares. Software que importa!

Um dos pontos cruciais ao utilizar CI é sobre a diminuição de conflitos quando integrando código. Uma vez que o código é frequentemente integrado (de um ramos específico para o ramo principal), ele tem menos chances de quebrar o que já existia. E mesmo que ele quebre algo que já funcionava, é mais fácil de resolver.

Outra questão importante  quando se fala de CI é que tal prática precisa ser suportada por uma suite de testes automatizados (não apenas testes de unidade, mas também testes de integração, e ainda melhor, se possível, por testes end-to-end). Portanto, se você já está fazendo testes automatizados e ainda não está fazendo CI, te recomendo começar a pensar nisso como seu próximo passo.

Além disso, para ser competitivo no mercado, é muito bom quando você pode lançar novas funcionalidades que importam aos usuários mais rápido que seus concorrentes. Com isso, você tem vantagem competitiva e melhor time to market. Portanto, CI lhe permite praticar também outra tarefa muito importante nos dias de hoje, chamada entrega contínua.

Se você ficou interessado no assunto, recomendo que leia este artigo do Martin Fowler, onde ele explica integração contínua de maneira muito mais detalhada, e também melhor do que eu. =D

Espero que tenha gostado do post e aguardo teu feedback.

Testes de aceitação automatizados: por onde começar?

A ideia deste post é compartilhar uma dica a qual creio ser importante quando se fala da escrita de testes de aceitação automatizados.

caminho feliz

Enquanto lia o capítulo sobre a implantação de estratégias de testes do livro Continuous Delivery, de Jez Humble e David Farley, passei por um sub-capítulo que fala de testes voltados a perspectiva de negócio e os quais suportam o processo de desenvolvimento de software.

No livro, os autores fazem referência ao quadrante dos testes, pela primeira vez citado por Brian Marick, no qual existem atividades de teste tanto da perspectiva de negócios, como voltados à tecnologia, e atividades de testes que suportam o processo de desenvolvimento, como atividades que criticam o projeto.

quadrante dos testes

Os testes de aceitação automatizados ficam no quadrante voltado ao negócio e que suportam o projeto, como já mencionado. Este é o quadrante foco deste post.

Quando se fala de testes de aceitação automatizados neste contexto, podemos pensar em diferentes cenários de testes: os caminhos felizes (happy paths) e os caminhos alternativos (alternate paths).

Os cenários de caminho feliz são basicamente aqueles que exercitam a aplicação  para completar com sucesso algum tipo de transação, como por exemplo, um login bem sucedido, a finalização de uma compra em um sistema de e-commerce ou a criação de uma nova conta no sistema.

Já os cenários de caminho alternativo são aqueles que exercitam a aplicação para os casos em que o usuário, por exemplo, não deve conseguir completar uma ação, tais como um login com usuário e/ou senha inválida, uma compra com um cartão de crédito roubado, a submissão de um formulário sem o preenchimento de algum ou todos os campos obrigatórios, etc.

Agora que já temos alguns fundamentos básicos, segue minha dica de por onde começar, quando se está iniciando na escrita de testes de aceitação automatizados. Comece pelos cenários de caminho feliz! =D

Digo isso com base no que é proposto pelo próprio livro, visto que criando tais testes, você garante que as funcionalidades principais de sua aplicação estão funcionando após alterações, tais como: adição de novas funcionalidades, correções de bugs ou refatorações. O imporatnte é no mínimo garantir que o usuário final conseguirá percorrer este caminho feliz sem problemas. Caso não haja cobertura em uma funcionalidade de compra com sucesso, em um sistema de e-commerce, por exemplo, isso pode acarretar em prejuízo financeiro. Pense nisso!

Como uma dica extra, testes automatizados de aceitação do cenário feliz podem ser utilizados para a criação de uma suite de smoke test, para um rápido feedback após alterações na aplicação, garantindo que o mais importante está ok, podendo a suite de testes de regressão ser executada em um momento posterior no pipeline de integração contínua, visto que tais testes tem um maior custo com relação ao seu tempo de execução, quando comparados a uma suite de smoke test. Caso após uma alteração na aplicação o smoke test falhe, não há a necessidade de perder tempo executando toda a suite de testes de regressão.

Depois de uma boa base de testes do caminho feliz, daí então comece a pensar nos cenários dos caminhos alternativos.

Abaixo seguem alguns links de conteúdos interessantes, também sobre testes de aceitação automatizados:

Teste de aceitação automatizados – série de contradições em teste de software (#TalkingAboutTesting)

Testes automatizados? Por onde eu começo?

Teste de aceitação e suas boas práticas

5 boas práticas para se aplicar em testes de aceitação

Espero que tenham gostado e aguardo seu feedback nos comentários.

O que testar e o que não testar com o Visual Review?

Aprenda um pouco sobre testes de revisão visual com algumas dicas sobre o que testar e o que não testar com o Visual Review.

VisualReview

Caso ainda não conheça a ferramenta, recomendo ler antes este post, no qual explico o básico.

Ok, agora que você já sabe do que se tratam testes de revisão visual, vamos à algumas dicas:

  • Analise seus testes e2e antes de adicionar passos de revisão visual à eles.
  • Procure entender quais testes são mais adequados para este tipo de abordagem. Os testes de revisão visual existem para lhe poupar tempo, portanto, se em todos os testes sempre existe diferença visual, algo está errado na escolha dos testes que estão utilizando este approach.
  • Se o layout de uma determinada tela ainda está em fase de experimentação, não utilize revisão visual à esta.
  • Adicione passos de revisão visual à telas da aplicação que já são estáveis e as quais não há previsão de serem alteradas em um futuro próximo.
  • Adicione passos de revisão visual à telas que não possuem elementos dinâmicos, tais como anúncios, data e hora, e outros.
  • Também não recomendo utilizar tais testes em telas que possuem gifs animados ou videos auto-executáveis, visto que a cada execução haverão diferenças, mesmo que a aplicação não esteja “quebrada” visualmente.

Ficou curioso, veja aqui o que mais já escrevi sobre o assunto.

Está utilizando o Visual Review e tam mais alguma dica? Deixe um comentário.

Veja também este post em sua versão em Inglês no Medium.

=D