The Amazing Test Bash San Francisco ❤ — Day 1
Na última semana eu participei do Test Bash San Francisco, um evento que é organizado pelo Ministry Of Testing.
Pra quem não conhece, o Ministry é a maior comunidade de testes existente hoje no mundo, ela foi fundada pela Rosie Sherry, e conta com Meetups em vários países (aqui no Brasil temos no RJ e Recife), o The Club, o Dojo e os Test Bash que são conferências com palestrantes do mundo todo (nesse link você encontra todos os Test 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.
Vamos ver nesse post um pouco sobre esses assuntos abordados no evento :)
Primeiro Dia
O evento começou com a Elisabeth Hendrickson, que é autora do Explore It! o livro referência sobre testes exploratórios.
A palestra dela teve o título: “Influence > Authority and Other Principles of Leadership” (Influence is greater than Authority — o jogo com o símbolo foi proposital) onde ela falou sobre princípios de liderança.
Nessa palestra ela falou um pouco sobre como autoridade e liderança são duas coisas diferentes. Autoridade está mais ligada a poder pra fazer algo (seja por um decreto ou por reputação), liderança é algo que está além do título que você tem. Você pode ser um desenvolvedor/tester dentro do seu time que se comporta e é reconhecido como um líder pelos seus pares.
Outro ponto que eu achei muito interessante foi sobre "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ê 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", onde ela contou a experiência que teve ao participar de Mob Programming com o time dela (ah, e a Jasmin não tinha nenhum background técnico!).
Pra quem não conhece, Mob Programming é uma prática de desenvolvimento onde todo time (desenvolvimento, testes e produto) trabalha na mesma coisa, ao mesmo tempo!
A Jasmine contou um pouco da experiência dela, como pessoa que não sabia programar, ao participar dessas sessões com o time. A partir dessas sessões ela aprendeu mais sobre todas as áreas do produto em que o time dela trabalha e também conseguiu passar para o time a visão dela como tester.
Pontos legais sobre a palestra:
- + diversidade: pessoas de backgrounds diferentes trabalhando juntas para o mesmo propósito agregam muito ao produto!
- + empoderamento;
- síndrome do impostor: a Jasmine passou por algumas crises dessa síndrome com medo de não saber as coisas ou não aprender, mas o apoio de todo time a ajudou a ir em frente;
- colaboração e aprendizado;
- empatia!
Esse vídeo aqui é bem legal e descreve um dia de Mob Programming:
Seguindo o evento, o Adrian P. Dunston que é desenvolvedor, contou um pouco 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 ele está desenvolvendo.
Os slides dele já estão disponíveis: https://goo.gl/Lg6zeo
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 e sim conseguir construir um argumento);
- Promova seu trabalho e a partir disso dissemine a cultura de qualidade para todo seu time!
Climbing to the Top of the Mobile Testing Pyramid" foi a palestra do Rick Clymer onde ele contou um pouco 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 pra 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 X versões de sistema).
Esse post do Elemental Selenium fala um pouco sobre esse 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 quiserem, mas isso tudo foi realmente no primeiro dia!
A próxima palestra foi do Paul Grizzaffi: Extra! Extra! Automation Declared Software!
Ele tem um blog bem legal sobre automação: Responsible Automation.
O recado principal que o Paul quis passar é que 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 e 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: 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. :D
A Angela Riggs falou sobre "Creating a Culture of Quality Assurance" (os slides estão disponíveis já).
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 juntas trabalhem para alcançá-la.
Qualidade está ligada a mindset e cultura mais do que a ferramentas e processos ou ao papel de tester/QA.
Durante a palestra ela contou a experiência de criar essa Cultura de Qualidade na Vacasa onde ela é QA Engineer. Seguem alguns tópicos que ela falou durante a palestra.
Desafios para criar essa cultura:
- Gestão de Mudanças;
- Onboarding (de novas pessoas na empresa e de novos membros em 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 “Backend 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 numa 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.
Para a parte de testes de UI, a vantagem é poder rodar testes em paralelo de forma simples.
Pra 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 (pra quem não sabe, o Richard é o BossBoss do MoT e é quem faz a interface com a gente que organiza os meetups pelo mundo) falarem sobre "Power Of Models".
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.
O Richard costuma usar Visual Thinking nas suas palestras e isso é incrível, no final da palestra ele fez o desafio pra que começássemos a usar e eu estou me arriscando em alguns desenhos:
Conclusão do Day 1:
Eu sai do evento me sentido o Caco nesse gif:
OH MY GOD!!
Muito conteúdo, palestrantes que eu sempre tive como referência ali na minha frente compartilhando conhecimento e 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.
tl;dr
A ideia era fazer um post sobre só todo o evento, mas acabou que realmente eu tenho muito pra compartilhar, então esse aqui foi sobre o primeiro dia e logo logo sai o resumo do segundo dia :)
Thank you for reading!
E aí, o que vocês acharam desse resumo? Já tinham ouvido falar desses temas? Já fazem isso na sua empresa? Deixe seu comentário aqui e vamos trocar ideias :D
