Concrete Logo
Hamburger button

The Amazing Test Bash San Francisco

  • Blog
  • 19 de Novembro de 2018

Na última semana participei do Test Bash San Francisco, evento organizado pelo Ministry Of Testing. Pra quem não conhece, o Ministry é a maior comunidade de testes existente hoje no mundo. Fundada pela Rosie Sherry, ela conta com meetups em vários países (aqui no Brasil temos no RJ e em Recife) e o The Club, o Dojo e os Test Bash são conferências com palestrantes do mundo todo (aqui você encontra todos os Tests Bash que já aconteceram e resumos do que rolou).

O evento em SFO contou com palestras de diferentes temas dentro do assunto Qualidade de Software: Liderança, Mob Programming, Pirâmide de Testes, Cultura de QA, Automação, Serverless, Alexa, Gestão de Massa de Dados, Testes em Produção, Testes Subcutâneos, Poder de Modelos e Testes de Regressão.

Neste post, falo um pouco sobre esses assuntos abordados durante o evento. 🙂

Primeiro dia

O evento começou com a Elisabeth Hendrickson, autora do Explore It!, livro referência sobre testes exploratórios.

Na palestra Influence > Authority and Other Principles of Leadership (Influence is greater than Authority — o jogo com o símbolo foi proposital) ela explicou os princípios de liderança.

Também falou um pouco sobre como autoridade e liderança são duas coisas diferentes.  Isso porque autoridade está mais ligada a poder para fazer algo (seja por um decreto ou por reputação) e liderança é algo que está além do título que você possui. Por exemplo, você pode ser um desenvolvedor/tester dentro do seu time, mas se comporta e é reconhecido como um líder pelos seus pares.

Outro ponto que achei muito interessante foi quando ela disse para “ser gentil ao invés de ser legal”. Muitas vezes as pessoas acham que um bom líder é aquele cara gente boa, amigo de todo mundo, mas pelo contrário, um bom líder é aquele que concede os feedbacks tanto positivos, quanto negativos, sendo firme e gentil, mas falando e fazendo o que precisa ser feito.

Algumas outras características que ela citou foram:

  • Liderar pelo exemplo;
  • Fazer uma pequena coisa todos os dias;
  • Negociar acordos;
  • Dar voz as pessoas do seu time, criando espaços que os permitam ser protagonistas;
  • Feedback positivo é uma força mais poderosa para a mudança do que críticas;
  • Para resolver os problemas, primeiro os torne visíveis;
  • Seja gentil, não legal.

Fear is a lousy compass.

Por fim, esse é um outro ponto que vale muito a pena destacar: o medo é uma péssima bússola! Por um tempo fazer a gestão “por medo” pode até funcionar (aparentemente), mas isso não se sustenta. Seja um líder gentil e você vai ter muitos resultados positivos. Ah! E antes que eu me esqueça:

Don’t shave that yak!

Outra palestra interessante foi a da Jasmin Smith, Going undercover in the mob, na qual ela contou a experiência que teve ao participar de Mob Programming com o time dela (e a Jasmin não tinha background técnico).

Para quem não conhece, Mob Programming é uma prática de desenvolvimento em que todo o time (desenvolvimento, testes e produto) trabalha na mesma coisa ao mesmo tempo.

A Jasmine contou um pouco de sua experiência, como uma pessoa que não sabia programar, ao participar dessas sessões com o time. A partir daí ela aprendeu mais sobre todas as áreas do produto em que o time trabalhava, assim como conseguiu passar a sua visão como tester.

Pontos legais da palestra:

  • Mais diversidade: pessoas de backgrounds diferentes trabalhando juntas em um mesmo propósito agregam muito ao produto;
  • Mais empoderamento;
  • Síndrome do impostor: a Jasmine passou por algumas crises dessa síndrome por medo de não saber as coisas ou não aprender, mas o apoio de todo o time a ajudou seguir em frente;
  • Colaboração e aprendizado;
  • Empatia!

Esse vídeo aqui é bem legal e descreve um dia de Mob Programming:

Seguindo o evento, o desenvolvedor Adrian P. Dunston falou sobre Tester at the table and the tester in my head.

De uma forma bem irreverente (os slides dele formavam uma história em quadrinhos), o Adrian contou um pouco sobre o tester que existe na cabeça dele e que o ajuda a pensar na qualidade dos produtos que está desenvolvendo. Os slides dele já estão disponíveis.

Lições deixadas nessa palestra:

  • Computação é sobre humanos e suas relações (por isso nossos usuários devem estar no centro das atenções e não somente as tecnologias com as quais trabalhamos);
  • Repetição é importante para alcançar a maestria;
  • Faça acordos;
  • Saiba argumentar (não é sobre ganhar uma discussão, mas sim conseguir construir um argumento);
  • Promova seu trabalho e a partir disso dissemine a cultura de qualidade para todo o seu time!

Climbing to the top of the mobile testing pyramid foi a palestra do Rick Clymer, na qual ele comentou sobre (como o próprio título diz) pirâmide de testes para aplicações mobile.

A palestra foi sobre a experiência dele na implementação da pirâmide de testes para mobile. Uma grande preocupação que acaba acontecendo nesse cenário é o que devemos testar em emuladores e o que deve ser testado nos devices reais (e como priorizar esses devices dada a enorme variação de marcas X, modelos Y, versões de sistema).

Esse post do Elemental Selenium fala um pouco sobre o assunto: The Mobile Testing Pyramid.

Lembrando que nem só de front-end é feita uma aplicação mobile, é importante cobrir a base da pirâmide com testes de unidade e nas APIs. Nas camadas acima, você começa a investir em testes instrumentados, comportamento em emuladores e em devices reais.

Acreditem se quiser, mas isso tudo foi realmente no primeiro dia!

A palestra seguinte foi do Paul Grizzaffi: Extra! Extra! Automation Declared Software!

Ele tem um blog bem legal sobre automação: Responsible Automation.

O recado principal do Paul foi código de automação de testes deve ser tratado como código de produção. É importante criar uma estrutura sustentável, usar boas práticas, criar uma arquitetura escalável e tantas outras característica que levamos em consideração quando estamos criando código de produção. Muitas pessoas iniciam na automação de testes simplesmente porque precisam automatizar e acabam não investindo tanto nos fundamentos programação, boas práticas de desenvolvimento, arquitetura etc.

Os times, muitas vezes, só se preocupam com o resultado do teste executado e não com a infraestrutura dos testes.

Como lição dessa palestra fica que precisamos tratar código de testes como o código da aplicação e não apenas estar interessado se o resultado foi pass/fail. Criar uma arquitetura focada em manutenibilidade, fazer review do código, documentar bem e ter em mente que o código de teste também vai ter uma vida longa e você vai precisar voltar nele para dar manutenção. 😀

Angela Riggs falou sobre Creating a Culture of Quality Assurance.

Sabemos que deixar a responsabilidade da qualidade de um produto na mão de um único papel não funciona, por isso é importante que todas as pessoas envolvidas entendam o que é qualidade para aquele produto e que juntas trabalhem para alcançá-la.

Qualidade está ligada a mindset e cultura, mais do que a ferramentas e processos ou ao papel do tester/QA.

Durante a palestra ela contou a experiência de criar essa Cultura de Qualidade na Vacasa, empresa na qual ela é QA Engineer. Seguem alguns tópicos importantes que valem destaque.

Desafios para criar essa cultura:

  • Gestão de Mudanças;
  • Onboarding (de novas pessoas na empresa e de novos membros nos times);
  • Mudanças são difíceis e emocionais;
  • Feedback;
  • Incluir sempre os “porquês” em relação as tomadas de decisão.

You’re creating a Culture that everyone supports, but make sure that the culture supports everyone.

Praticando a cultura (qualidade é responsabilidade de todos):

  • Gestão;
  • Produto;
  • Desenvolvimento;
  • Testes.

A great culture of quality is flexible, with the ability to meet changing requirements.

Benefícios dessa cultura:

  • Colaboração;
  • Comunicação;
  • Conhecimento compartilhado;
  • Qualidade;
  • Confiança.

A culture of quality is a culture of empowerment and trust.

A penúltima palestra do dia foi do Glenn Buckholz sobre How to Test Serverless Cloud Applications. Serverless é um assunto que anda na “boca do povo” então o Glen trouxe uma visão sobre como ficam os testes nesse contexto.

Tá, mas o que é Serverless?

Segundo Martin Fowler, em seu artigo Serverless Architectures:

Serverless são projetos de aplicativos que incorporam serviços Back-end as a Service (BaaS) de terceiros e/ou que incluem execução de código personalizado em contêineres efêmeros gerenciados em uma plataforma Funcations as a Service (FaaS). Ao usar essas ideias e outras relacionadas, como single-page applications, essas arquiteturas removem grande parte da necessidade de um componente tradicional de servidor sempre ativo. As arquiteturas sem servidor podem se beneficiar de um custo operacional, complexidade e lead time de engenharia significativamente reduzidos, a um custo de maior dependência de dependências de fornecedores e serviços de suporte comparativamente imaturos.

Bem, o acesso ao front-end e os testes no mesmo continuam da forma tradicional (você sempre vai poder acessar uma url e executar ações a partir dali), mas e quanto aos outros tipos de teste? Ou existem novos tipos de teste para se fazer em uma arquitetura serverless?

Como você não faz a gestão da infraestrutura nesse tipo de arquitetura, existe uma fase de Testes Locais para ter um feedback rápido se suas funções estão funcionando.

A parte de testes unitários continua a mesma (mais rápidos e mais baratos), mas no caso de serverless é necessário ter um forte investimento em testes de integração.

Função AWS Lambda com testes

Para a parte de testes de UI, a vantagem é poder rodar testes em paralelo de forma simples.

Para quem quiser ler mais um pouco sobre testes em serverless, indico esses posts aqui.

Terminando o primeiro dia de evento, foi a vez do Dan Ashby e do Richard Bradshaw falarem sobre Power of Models (para quem não sabe, o Richard é o BossBoss do MoT. É quem faz a interface com a gente que organiza os meetups pelo mundo).

Nessa apresentação eles mostraram como modelos podem ajudar na representação da Estratégia de Testes e na colaboração de outras pessoas a partir desses modelos. Nós usamos modelos o tempo todo para estruturar nossas ideias.

Modeling helps us communicate with others.
Modeling helps us collaborate and solve problems.
Modeling helps us consider different issues and challenge our current level of thinking.
Modeling can provide visual aids to allow us to recall and remember things to help us with the previous three aspects.

Nesse exemplo ele usa Visual Task Analysis para mostrar um fluxo de teste, representado a partir de cada passo, em que camada da aplicação ele é chamado. A partir desse modelo é possível pensar em quais testes fazer em cada camada pensando na melhor estratégia/cobertura.

Nessa outra imagem temos um exemplo de representação de Estratégia de Testes (muito melhor que um documento com texto corrido).

No topo estão representadas as Influências: Contexto, Restrições e Aspirações; em verde, as Abordagens de Teste (automação, exploratório etc); em vermelho, como vai ser a execução dos testes; na lateral, qual o processo de Continuous Testing; e, por fim, a Qualidade Percebida dessa estratégia.

Richard costuma usar Visual Thinking em suas palestras e isso é incrível. Ao final, ele fez o desafio para que começássemos a usar e eu estou me arriscando em alguns desenhos:

Conclusão do Day 1

Saí do evento me sentido o Caco nesse gif.

OH, MY GOD!

Muito conteúdo e palestrantes que eu sempre tive como referência ali na minha frente, compartilhando conhecimento. O que mais me chamou atenção foi o quanto o evento é DIVERSO!

Esse primeiro dia me deu vários insights de coisas que já fazemos na Concrete e podemos melhorar, assim como coisas que podemos experimentar e adotar.

A ideia era fazer um post único sobre todo o evento, mas acabou que realmente tenho muito para compartilhar, então este aqui foi sobre o primeiro dia. Logo logo sai o resumo do segundo. 🙂

Thank you for reading!

E aí, o que vocês acharam deste resumo? Já tinham ouvido falar desses temas? Já fazem isso na sua empresa? Deixe seu comentário aqui e vamos trocar ideias. 😀