Experiências de Elisabeth Hendrickson: Time Ágil e Criação de um Simulador Waterfall
Introdução
Como podemos como QAs, melhorar nossa performance na área de teste de software? Como funciona um time Ágil? O QA tem sua eficiência mensurada através da quantidade de bugs encontrados? Após ler e meditar em alguns artigos, encontrei algumas respostas para essas perguntas, e reafirmo que somos mais que “caçadores de bugs”. Somos aqueles que irão contribuir para o desenvolvimento de software através da perspectiva de qualidade.
Na primeira síntese, compilei dois artigos nos quais a autora nos conta sobre o processo de desenvolvimento de um simulador, e na segunda síntese ela discorre sobre sua experiência em um time Ágil. Confira abaixo como são abordados esses assuntos.
Sweet Spot e Elements of Engagement (Ponto Certo e Elementos de Engajamento)
Elisabeth Hendrickson estava a criar um simulador de desenvolvimento de software. Ponderava que, uma boa simulação, permitiria uma rica possibilidade de resultados complexos. Seria envolvente, ainda que o simulador tivesse apenas alguns botões para girar ou pressionar e provavelmente capturaria a atenção do jogador. O faria ficar preso por horas e ainda se sentir como se não tivesse visto tudo o que o simulador proporcionava.
Em um dos seus jogos favoritos, The Sims, qualquer jogador poderia experimentar emoções, viver uma vida e uma história como se fosse real. Mas, pensando em sua mecânica de jogo, apesar de parecer complexo, o The Sims era simples. A forma como os personagens se comportavam, definiam e afetavam suas histórias dentro do jogo. Como a simplicidade do The Sims, a simulação de desenvolvimento do software Curious Duck (jogo no qual Elisabeth trabalhava), possuia três mecânicas simples: trabalho, trabalhadores e filas. Essas três mecânicas permitiam a modelagem de cenários variados.
Num dos cenários iniciais da simulação, havia o envolvimento do programador, que trabalhava e entregava o código; o testador que pegava o código, encontrava bugs e reportava ao programador. O cenário terminava quando o Software já não demonstrava problemas conhecidos.
Quando Elisabeth comparava a simulação ao cenário descrito, ocorria um loop com dois trabalhadores. Cada trabalhador possuia duas filas contendo uma caixa de entrada e uma de saída em cada fila. A caixa de saída do testador se tornava a caixa de entrada do programador e vice-versa, estando assim, conectados. Parecia simples porém, não era. O programador e testador eram duas pessoas diferentes, e tinham tarefas diferentes.
Em termos de código, era fácil representar isso. Mas, como ela iria determinar quantos bugs o testador iria encontrar? Existiriam muitos fatores que afetariam esse cenário, por exemplo: Quanto tempo e quão habilidoso seria o testador? O quanto entenderia de sistema e como seria o ambiente de teste? O quanto o programador entenderia o sistema e o código existente? O programador havia testado seu código antes de enviá-lo? Os requisitos eram claros?
Na tentativa de simplificar a simulação, Elisabeth pensou que eliminando o máximo de complexidade possível , ou seja, tornando o jogo menos complexo que o mundo real, mas mantendo a variação, o jogo se tornaria mais interessante. E foi assim, que ela chegou a duas características de trabalho: tamanho e confiabilidade. Ela tinha em mente que quanto menos confiável fosse o trabalho, maior seria a probabilidade de bugs, e que maiores mudanças poderiam introduzir provavelmente maior quantidade de bugs.
Após essas mudanças, ela executou a simulação novamente e observou que o programador terminava uma tarefa e o testador realizava os testes no código. O testador encontrava muitos, milhares de bugs, fazendo com que a carga de atividades do programador só aumentasse, ocasionando um loop infinito de trabalho. Em cada correção entregue, eram encontrados outros e outros bugs.
Ela tomou a decisão de realizar os ajustes nos números atribuídos a confiabilidade, custo e probabilidade, o que fez com que a quantidade de trabalho que a correção de um bug apresentava, diminuísse ao longo do tempo atingindo um equilíbrio no jogo.
Na execução da simulação seguinte, o testador encontrava menos bugs a cada ciclo de trabalho e após alguns ciclos, o software não demonstrou problemas conhecidos. O cenário acabou porém, aos olhos de Elisabeth, sua simulação havia se tornado chata, sem a possibilidade de prender a atenção dos jogadores. A lição aprendida por Elisabeth foi que: O motivo para o longo tempo de desenvolvimento de um jogo é o ajuste da mecânica para que ele seja jogável, encontrando o ponto ideal entre a estabilidade e o caos.
Após essa simulação, que Elisabeth, descreveu como “chata”, ela se reuniu com seu amigo Davis Frank, para fazer com que o jogo ficasse mais divertido. Tinham planejado adaptar a simulação em um jogo de tabuleiro. Davis decidiu adicionar um objetivo ao jogador: Entregar uma versão sem bugs num tempo limitado, que foi definido para 7 rodadas.
Ele escolheu o personagem programador e Elisabeth, o testador. Jogaram no estilo Calvinball ( jogo criado por Calvin e Hobbes, onde as regras são criadas a medida que o jogo avança), mas sentiram que faltava algo: não havia um ponto, em que era necessário uma tomada de decisão, e sem escolha não poderia haver estratégia. Foi então, que ajustaram as regras para que houvessem três possibilidades: avançar, retroceder ou escolher o jogador.
Elisabeth e Davis jogaram novamente, mas ainda sentiam que faltava algo. Ainda que tivessem uma escolha, essa escolha se tornava ilusória, pois sendo o objetivo do jogo lançar um software, havia apenas uma escolha a ser feita em relação a resultados indeterminados: seguir em frente. Era necessário uma razão para escolher algo diferente. Deveria haver uma troca, pois uma escolha na vida real que dá impulso a um recurso que não está pronto, eleva o risco do projeto. Como ainda não havia na simulação um cliente que reclamaria da baixa qualidade na mecânica do jogo, havia um risco difícil de definir.
Decidiram em conjunto, que o testador teria uma cota de bugs, e ambos o programador-testador só poderiam vencer se o software fosse enviado, tornando uma troca mais realista. Tinham-se três elementos principais que tornavam o cenário mais interessante: um objetivo, ponto de decisão e compensação. O resultado? Não foi o ideal, porque para satisfazer o seu gerenciamento, o testador precisava atingir sua cota de bugs. Mas quanto mais bugs o testador encontrava, menos provável era que o lançamento seria feito a tempo, ou seja, não haveria vitória.
A medida que o jogo ia fluindo, perceberam que se parecia mais e mais com a vida real. O simulador parecia com grupos ou empresas no mundo real que independente do controle de qualidade, mediam a eficiência do testador contando bugs. Como o objetivo maior da simulação era ajudar o time em relação à tomada de decisão, esse cenário com certeza ajudaria líderes no futuro a entender que: medir os testadores em relação à quantidade de bugs encontrados é uma péssima ideia.
Foi criada uma versão digital do jogo por Elisabeth para que ela e Davis pudessem jogar, e este novo modelo de jogo foi uma enorme evolução, proporcionando a escolha do número de rodadas do jogo, probabilidade de três resultados possíveis e a cota do testador. Também foi implementado o cenário programador-testador do ponto de vista do programador, adicionaram clientes e usuários finais a simulação, para que os feedbacks fossem dados sobre a qualidade e as consequências reais das escolhas que diminuem ou elevam o risco. Se quiserem conferir, há um vídeo no qual Elisabeth explica sobre o simulador de desenvolvimento de software.
Nas linhas escritas acima, podemos extrair dois pontos de vista distintos. O primeiro é o ponto de vista de Elisabeth, que considera o desenvolvimento de um jogo complexo, pois muitos fatores devem ser levados em consideração e o compara com o dia a dia de um testador. Depois de algumas tentativas e erros, houve sucesso na criação do simulador, e até criou-se uma versão digital no fim.
O segundo ponto de vista é sobre o cenário relatado, no qual primeiro se desenvolve o código e depois é entregue ao testador para realização dos testes, ela o associa ao Modelo tradicional, e menciona que o viu em algumas companhias. Também temos acompanhando esse cenário descrito por Elisabeth em muitas empresas nas quais as fases são realizadas sequencialmente: requisitos, design, desenvolvimento, testes, implantação, sendo que o QA atua apenas na penúltima fase, a de testes. Para algumas empresas, alguns profissionais QAs, ainda tem sua eficiência mensurada pela quantidade de bugs encontrados.
No jogo ela fala que quanto mais bugs se encontrava, mais difícil seria entregar o software no prazo, o que demonstrava que isso não era algo bom. Ocorre a mesma coisa no mundo real, porque quanto mais bugs se encontram, mais retrabalho ocorre para o desenvolvedor, o que pode gerar uma entrega com atrasos ou de menor qualidade, uma vez que o desenvolvedor tentará acelerar o processo de correção de bugs, podendo não entregar o software com qualidade. Uma forma de mitigar isso, é o QA já se posicionar para revisar os documentos de Requisitos, revisar as telas de UX/UI, desenvolver scripts de testes automatizados e produzir a documentação para que sejam realizados testes assertivos na fase de testes, contribuindo desde as primeiras fases, estando ele no modelo tradicional ou não.
A eficiência do QA está na qualidade do trabalho que ele entrega, o quanto ele entende de riscos, cenários de testes e código. O quanto ele sabe se posicionar diante de um problema em potencial e sabe a diferença de uma falha para um risco. O quanto ele entende onde o bug foi gerado (causa raiz do bug) ou não. Pensando dessa forma, o QA se torna uma figura essencial no projeto e processo de desenvolvimento de software.
The Two Sides of Software Testing: Checking and Exploring (Os dois lados do Teste de Software: Explorando e Verificando)
Há muitos anos, Elisabeth em uma conversa por um corredor de uma conferência com uma gerente de testes, por nome Francine, discutiam sobre suas diferentes abordagens para testes. Francine afirmava que não começaria os testes até que fosse produzido um documento de requisitos em detalhes. Na época, Elisabeth trabalhava para um fornecedor de software no Vale do Silício que fazia aplicativos. Pensava que se esperasse por especificações antes de começar a testar, esperaria para sempre, e provavelmente seria demitida por não contribuir para o projeto ativamente. Sem concordância, cada uma partiu em direções opostas.
Essa conversa, representou um debate familiar na comunidade de testes: O “bom teste” envolveria a execução sistemática de testes com scripts a partir de requisitos? Ou os testes devem explorar os riscos através de uma abordagem investigativa? As respostas dividiram historicamente a comunidade de testes, com acusações de cada lado de práticas que elevam o risco e reduzem a qualidade. No passado, Elisabeth estava a favor de usar testes exploratórios.
Sua perspectiva mudou quando passou a trabalhar com times ágeis, que valorizam os testes em todas as suas formas. Então, esse debate se tornou inútil.
As equipes ágeis com as quais Elisabeth trabalhava, tinham espaços para uma conversa sobre requisitos. A conversa acontecia quando o time estava pronto para implementar a história e então seriam capturados os detalhes sobre os critérios de aceitação e as expectativas do cliente. A verificação de que a história criada fazia o que o proprietário do produto queria que fosse feito, era realizado antes de chamá-la de pronta (“done”). Então quando Elisabeth pensava na conversa com Francine, o que ela havia dito fazia sentido. Suas palavras “Até que me digam o que o software deve fazer, não posso realizar os testes”, diziam que se deveria saber o que o proprietário do produto esperava, antes de implementar a história escolhida.
Algumas equipes ágeis capturavam os resultados dessas discussões com exemplos concretos como Gherkin (Dado que/Quando/Então) num estilo popularizado pela comunidade desenvolvimento como Behavior-Driven Development (BDD), associados a ferramentas como Cucumber. Quando critérios de aceitação são capturados na forma de exemplos concretos, como expectativas como essas, eles se parecem com scripts de teste.
Nas equipes ágeis também eram realizados testes de regressão, para verificar se as expectativas ainda estavam sendo atendidas. Como era valorizado o rápido feedback, os testes precisavam ser executados numa frequência alta, automatizados para manter a carga dos testes de regressão num nível que pudesse ser gerenciado. A abordagem da Francine então, de acordo com Elisabeth, colocava os testes na linha de frente ao invés de ao final do ciclo. Resultado: os testes tornavam-se uma expressão dos requisitos e especificavam o comportamento esperado do sistema.
A verificação da história do usuário em relação as expectativas, não dizia que todo cenário havia sido coberto. Sempre haveria o risco de alguma condição não ter sido antecipada, resultando num mau comportamento do software. Então, era onde entravam os testes exploratórios baseados em sessão, definidos por James e Jon Bach, que a apresentavam uma maneira estruturada de investigar o sistema. Usavam ainda, como testadores habilidosos, técnicas de design de teste, e habilidades risco ou analíticas a fim de encontrar algum risco ou vulnerabilidade. E conforme os testes progrediam, as configurações, permissões e dados eram variados. Cada pequena surpresa era investigada detalhadamente.
As abordagens do ágil enfatizavam a produção de recursos concluídos durante cada sprint, pelo menos mensalmente e antes de uma história ser dada como pronta (“done”), ela precisava ser testada. Segundo Elisabeth, considerando sua abordagem na conversa com Francine que enfatizava a exploração do software, e a abordagem da Francine que enfatizava a verificação do software, ela percebeu que ambas estavam certas. Para uma história ser declarada como pronta (“done”), ela precisa ser verificada e explorada para que o lançamento do software alcance uma alta qualidade.
É interessante como funciona o time Ágil. Elisabeth fala que é um time que dá valor a todos os tipos de testes e é o que eu vejo hoje sendo implantado em várias empresas. Nesse time, o papel do QA é muito importante. O QA participa da reunião de refinamento com o PO e o desenvolvedor, colabora com os testes no design, colabora sob a perspectiva de desenvolvimento, pareando com os desenvolvedores, levanta riscos, auxilia e mentora a equipe como um todo. O QA é um profissional muito mais completo, pois ele entende de técnicas de testes, funcionais e não funcionais, testes exploratórios, testes de desempenho, testes de unidade e integração, testes automatizados. Isso faz com que a cobertura de testes do software seja maior, que cada vez menos bugs sejam encontrados e que o projeto alcance a qualidade no mais alto nível.
Sobre o autor
Fundadora e presidente da Quality Tree Software, Inc., Elisabeth Hendrickson escreveu a primeira linha de código em 1980 e algum tempo depois, ela encontrou seu primeiro bug. A partir disso, Elisabeth ocupou cargos variados como testadora, desenvolvedora, gerente e diretora de engenharia de qualidade em várias empresas que vão desde pequenas startups até multinacionais. Membro da comunidade ágil desde 2003, Elisabeth atuou no conselho de administração da Agile Alliance e é co-organizadora do programa Agile Alliance Functional Testing Tools. Agora ela divide seu tempo entre ensinar, falar, escrever e trabalhar em equipes ágeis com programadores contagiados por testes que valorizam sua obsessão por testes. Elisabeth bloga em testobsessed.com e pode ser encontrada no Twitter como @testobsessed.
Agradecimentos
Aos revisores Gabriel Santos e Cristiane Jacques pela contribuição e sugestões que tornou possível a publicação desse trabalho otimizado e fluido.
Ao Júlio de Lima, meu mentor, que fez com que tudo que eu aprendi até hoje em testes de software, tornasse possível a escrita desse trabalho.
A minha família, que sempre me apoia e incentiva no meu crescimento pessoal e profissional.
Referências
Artigo 1 — Escrito em 3 de Maio de 2021
https://www.curiousduck.io/chaos/
https://www.ea.com/pt-pt/games/the-sims
Artigo 2 — Escrito em 18 de Maio de 2021
https://www.curiousduck.io/elements-of-engagement/
https://calvinandhobbes.fandom.com/wiki/Calvinball
https://www.youtube.com/watch?v=dRtxz-VOIrE
Artigo 3 — Escrito em 21 de Maio de 2011
https://www.stickyminds.com/users/elisabeth-hendrickson
https://agiletestingdays.com/blog/125-awesome-testers-you-should-keep-your-eye-on-always/
https://www.spiceworks.com/tech/devops/articles/devops-vs-agile/queda-diferenças-em-metodologias de desenvolvimento de software/
https://www.satisfice.com/download/session-based-test-management
