Pensando sobre testes

Testar não significa mais testar

Confuso? Podemos imaginar! O propósito dos testes costumava ser bastante claro - “Testar é o process de executar um programa com o intuito de encontrar erros” [Meyers79]. Isso muda com a adoção de práticas desenvolvimento Lean e Agile.

Engenharia simultânea exige que o trabalho seja paralelizado. Team dedicados e multifuncionais incentivam especialistas únicos a ampliar seus conhecimentos. Isto faz com que o propósito das atividades de desenvolvimento tradicionais – como testes – seja alterado.

A nível de código, práticas como Desenvolvimento Baseado em Testes - unitários - (TDD), confundem a divisão entre teste e design, conforme explicitado pela declaração do líder ágil Ward Cunninghamâ€:

“Codificação Test-First não é uma técnica de teste.”

Desenvolvimento Baseado em Testes de Aceitaçao difunde a distinção entre teste e análise de requisitos. No seu artigo da IEEE,“Teste e Requisitos, Requisitos e Teste: Uma fita de Möbius Martin e Melnik argumentam…

… para a escrita antecipada de testes de aceitação como uma técnica de engenharia de requisitos. Nós acreditamos que requisitos concretos se misturam com testes de aceitação de da mesma maneira que aos dois lados de uma fita de papel se tornam um lado em uma fita de Möbius. Em outras palavras, requisitos e testes se tornam indistinguíveis, de forma que consiga especificar o comportamento do sistema escrevendo testes e então verificando este comportamento ao executar os testes.

Esta confusão de limites é repleta de falácias. Adotando Desenvolvimento Baseado em Testes (unitários) como uma técnica de teste perde o objetivo e direciona a uma adoção superficial.
Da mesma forma, nós regularmente precisamos esclarecer a times de testes que eles não podem adotar Desenvolvimento Baseado em Testes de Aceitação sem o envolvimento de outros.

Testar não é mais testar.

Premissas de desafio sobre testes

Como mencionado anteriormente, dicussões sobre testes são repletas de suposições. Desafie-as! Para ficar claro, não estamos dizendo que essas suposições são falsas, mas deixa-las sem serem desafiadas vai limitar o pensamento e a habilidade de melhorar. Profundamente enraizado na cultura da Toyota há um pilar do caminho Toyota: “melhoria contínua”, ao desafiar tudo. Taiichi Ohno (um fundador do pensamento enxuto) disse:

Se você vai fazer Kaizen continuamente… Você deve assumir que as coisas são uma bagunça. Muitas pessoas assumes que as coisas estão bem da forma como estão. Kaizen se trata de mudanças nas coisas como são. Se assumir assumir que as coisas estão bem como estão, você não consegue usar Kaizen. Então mude algo!

Quais suposições? algumas das crenças com as quais esbarramos:

• Testes devem ser independentes e, portanto, separados do desenvolvimento;
  Testes não podem começar antes do código estar terminado;
  Testes seguem a sequeência de (1) desenho dos casos de teste, (2) execução dos casos de teste, (3) relatórios de casos de teste (uma cascata de testes);
• Deve haver um departamento de testes separado;
• Deve haver um gerente de testes
• Testes devem ser realizados no fim;
• Testes devem ser “bem planejados”
• Deve haver uma “estratégia de testes” e um “plano mestre de testes”;
• 100% de cobertura de testes é muito caro;
• 100% de testes automatizados é muito caro;
• Testes necessitam uma ferramenta sofisticada de gestão de testes
• Testes devem ser realizados pelos “testers”;

Deixar estas suposições incontestadas mantém o pensamento na caixa. Enquanto acreditar que “Testar somente pode começar depois que o código estiver finalizado”, você jamais irá considerar formas inovativas de testar antecipadamente. Mas assim que você se torna consciente das suas suposições, você pode questioná-las e perguntar: “existe alguma maneira de eu poder trabalhar de forma diferente para que o teste comece antes do código finalizar?”

Evite usar terminologias complexas de teste

Uma pergunta que gostamos de fazer a grandes grupos de produto é: “o que vocês precisam fazer antes de liberar o seu produto?”

Há muito tempo, aprendemos que precisamos de duas colunas: uma para atividades ‘normais’, e uma maior para atividades de testes. A primeira coluna é preenchida com itens como codificação, criando a documentação dos usuários, desenvolvendo hardware, precificação, e treinando pessoal de vendas. A segunda coluna inclui atividades de teste, níveis de teste, ou classificações de teste. Entradas comuns na segunda coluna são mostradas abaixo:

• Testes unitários
• Testes funcionais
• Testes de estresse
• Testes de interoperabilidade
• Testes de carga
• Testes de instalação
• Testes “monkey” (aleatório)
• Testes de documentação
• Testes modulares
• Testes sistêmicos
• Testes de estabilidade
• Testes de compatibilidade
• Testes de tráfego
• Testes de segurança
• Testes exploratórios
• Testes de aceitação
• Testes do desenvolvedor
• Testes de integração
• Testes de regressão
• Testes de confiabilidade
• Testes de performance
• Testes de capcidade
• Testes de usabilidade
  8 Testes de aceitação do usuário{: .two_columns .box_top_bottom}

Mantenha a classificação dos testes simples

Terminologias diretas ao ponto inspiram comportamentos inteligentes. Por exemplo, testes voltados para tecnologia que apoiam o time são normalmente executados por programadores durante a codificação, enquanto testes voltados para clientes que criticam o produto são geralmente executados por uma pessoa que não seja o autor original e são executados logo após a implementação de alguma funcionalidade do usuário.

Dois grupos:

• Teste do desenvolvedor
• Teste voltado ao cliente

Teste do desenvolvedor – este são normalmente criados pela pessoa que está implementando. Seu propósito é verificar se o código está fazendo o que o programador quer. Se o código passar no teste, significa que o sistema faz o que era esperado por ele - mas isto não significa, necessariamente, que o sistema faz o que era esperado pelo cliente.

Teste voltados ao cliente –Estes testam se os requisitos são cumpridos. São frequentemente implementados eexecutados por uma pessoa diferente daquela que escreveu o código. Neste agrupamento, os testes não funcionais são classificados como testes voltados ao cliente, pois requisitos não funcionais para sistemas de grande porte são comumente explícitos e os mais importantes.

Não separe desenvolvimento de testes

Bill Hetzel, o organizador da primeira conferência sobre teste de software, definiu no seu The Complete Guide to Software Testingseis princípios de testes. O sexto princípio–independencência de testes–é um tema comum em toda a história dos testes de software. Glenfor Meyers, autor to primeiro livro de testes de software, destacou a independências de testes no Software Reliability:

Tests deveriam sempre ser realizados por uma pessoa externa, que é, de alguma forma, desconectado pelo programa e projeto… Testes de sistema deveriam sempre ser realizados por um grupo independente como um departamento separado de garantia da qualidade (QA).

Por que a separação é importante? Alguns argumentos frequentemente usados:

• Programação é construtivo, enquanto testes são destrutivos - logo, programadores não podem testar.
• Se programadores testam o seu próprio código, então eles irão alterar o teste de acordo com a sua implementação.
• Quando os testes são realizados pelo mesmo grupo que realizou a implementação, então o grupo pode cumprir o prazo ao “pular” os testes.

Os dois primeiros argumentos assumem equipes unicamente especializadas ao invés de equipes multifuncionais. O último argumento sugere uma correção rápida para um problema muito maior de atalhos que destroem a qualidade, quando pressionando os desenvolvedores.

Nestes argumentos, independência de testes é equiparada com a separação de testes com desenvolvimento. No entanto, [Hetzel] (http://www.amazon.com/Complete-Guide-Software-Testing/dp/0471565679) esclarece o princípio:

O requisito é uma independência de espírito a ser alcançada, não necessariamente que um grupo separado execute os testes.

Este ponto é reiterado em Agile Testing onde os autores também apontam a subotimização criada pela separação dos testes:

Times frequentemente confundem “independentes” com “separar”. Se a estrutura reportada, orçamentos, e processos são mantidos em áreas funcionais discretas, uma divisão entre programadores e analistas de teste é inevitável. Tempo é desperdiçado com reuniões duplicadas, programadores e analistas de teste não compartilham objetivos em comum e compartilhamento de informações é inexistente.

Independência de testes não significa “testers” independentes.

Como conseguir a independência do teste em * espírito * sem separar o teste? * Escrevendo testes antes de implementar o código *. O teste não pode ser influenciado pela implementação, porque ainda não existe. Desta forma, o desenvolvimento orientado para testes alcança o * espírito * da independência sem separação de departamentos.

Testadores e programadores trabalham juntos

Separar o teste do desenvolvimento geralmente leva a um conflito entre programadores e testadores. Testadores - caçando bugs - tente provar que parte do programa está com defeito. Programadores - com seu ego em seu código - defendem a si mesmos, seu código e o programa. Provavelmente todos que estiveram no papel de um testador em um departamento de teste passaram por isso.

Em uma equipe de Scrum, os testadores não são mais testadores, mas sim membros da equipe - com testes como sua * especialização primária *. “Programadores” são * qualquer * membros da equipe que podem codificar. Cada membro da equipe tem uma meta compartilhada e é mantido - como uma equipe - responsável por essa meta. Os membros da equipe com diferentes especializações primárias têm que cooperar para atingir esse objetivo.
 

Educar e orientar os testes

Boas habilidades de teste vêm com prática e tempo deliberados. Infelizmente, especialmente em grandes organizações, as habilidades de teste não são respeitadas. “Todo mundo pode fazer isso” é a crença deles, então eles o colocam em offshore para uma empresa que pega pessoas aleatoriamente da rua e as designa para testar. Pessoas aleatórias contratadas para * bater * em um aplicativo rotineiramente vêem seu trabalho como um estágio temporário que precisam passar antes de avançar para um “emprego de verdade”. Eles não se incomodam com a falta de profundidade das suas habilidades com testes e assim contribuem para a falsa crença de que o teste é trivial.

Os testadores que não se importam em aprender novas habilidades e crescer profissionalmente contribuem para a percepção de que o teste é um trabalho pouco qualificado. [[CG09]] (http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468)

Cair na armadilha do “teste é trivial” é caro. Apoie o domínio do teste, fornecendo material de autoestudo, educação e coaching. Listamos algumas literaturas de habilidades de testes gerais na seção de leitura recomendada.

É claro, fornecer educação e coaching nos testes também é importante para os ambientes tradicionais. Em equipes multifuncionais, isso se torna ainda mais relevante à medida que os testadores às vezes se sentem marginalizados. Não ter uma organização funcional de teste pode afetar o sentimento de progressão na carreira e seu interesse em testes. E isso é exacerbado se toda a educação e treinamento estiverem relacionados a práticas de desenvolvimento ou gestão. Alta rotatividade em testes durante uma transição ágil não é incomum.

Eles dividiram sua organização de teste … No entanto, eles colocaram os testadores nas unidades de desenvolvimento sem nenhum treinamento; Em três meses, todos os testadores tinham desistido porque não entendiam o novo papel. [[CG09]] (http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468)

Da mesma forma, em uma transição ágil com a qual trabalhamos, muitos testadores saíram para diferentes produtos porque sentiram que perderam sua identidade e não sabiam como trabalhar em uma equipe Scrum. Evite isso desenvolvendo a experiência em testes da equipe.

Crie uma comunidade de testes

Educação e coaching não são as únicas maneiras de aumentar o conhecimento. Discussão aberta e compartilhamento de experiências. Um dos propósitos de uma unidade funcional - um departamento de teste - é permitir esse aprendizado. Sem isso, outros meios de discussão e compartilhamento de experiências são necessários. Por exemplo, estabelecendo uma Comunidade de Prática para teste. As pessoas interessadas em testar - não apenas aquelas com testes como especialização principal - encontram-se de vez em quando para aprender umas com as outras ou discutir através de uma lista de discussão ou wiki.

Os gerentes de teste podem desempenhar um papel importante nessa comunidade. Eles podem usar seus conhecimentos em testes e gerenciamento e se tornar coordenadores de CoP - de acordo com o princípio lean dos professoresgerentes.

Em vez de manter os testadores separados … [pense sobre] uma comunidade de testadores. Forneça uma organização de aprendizado para ajudar seus testadores … compartilhe ideias e ajude uns aos outros. Se o gerente de QA se tornar um líder prático na organização, essa pessoa será capaz de ensinar as habilidades que os testadores precisam para se tornarem mais fortes e mais capazes de lidar com o ambiente em constante mudança. [CG09]

Não tenha equipes de automação de teste separadas

Aconselhamos as organizações a investirem na automação de testes e criarem uma rede de segurança de testes de regressão em torno de seus códigos legados, para que possam gradualmente sair da confusão. Eles escutam e criam uma equipe separada de automação de testes.

Às vezes, a equipe de automação de testes tenta resolver * todos os problemas mundiais * com seus testwares, e o esforço produz apenas muito papel. Mas, às vezes, encontramos uma equipe de automação de testes mais pragmática que realmente cria testware, como uma estrutura de automação. Eles são lançados a cada dois meses e todos ficam impressionados com os resultados.

O que acontece depois? Nova funcionalidade é implementada. Interfaces mudam e os testes automatizados falham. As equipes de desenvolvimento estão chateadas e informam à equipe de automação de testes para corrigir os testes. Ou as equipes de desenvolvimento comentam os testes porque não os entendem. Ou, o testware é entregue às equipes de desenvolvimento que descobrem que ele é inutilizável ou incompreensível e o ignora. Ou … nós experimentamos uma dúzia de cenários diferentes nas organizações. Isso nunca funcionou.

Por quê? A suposição de que é a * criação * * do testware * é a parte difícil e a mais importante. Mas outros aspectos importantes são subestimados:

• Criar testware requer profundo conhecimento do produto.
• Manutenção e evolução é mais esforço do que a criação inicial.
• Os insights obtidos durante a criação de testware talvez sejam mais importantes do que o próprio testware.
• Criar testware sem * usar * leva a testes complexos e inutilizáveis.

Considerando esses aspectos, uma equipe de automação separada causa complexidade adicional, os desperdícios de handoff e dispersão de conhecimento. Não admira que tantas vezes falhar.

A automação de testes deve ser responsabilidade das equipes de desenvolvimento multifuncionais - assim como o teste também é responsabilidade deles.

Não há atalho para aprender como automatizar; uma equipe de automação separada é uma * solução rápida * - e prejudicial a longo prazo.

Equipe de features como equipe de automação de testes

Uma equipe de automação de testes separada tem muitas desvantagens, mas também algumas vantagens. Eles podem criar a estrutura de teste inicial, produzir material de treinamento e apoiar as equipes.

Como obter esses benefícios sem os inconvenientes?

Uma equipe de features pode assumir temporariamente o papel da equipe de automação de testes. Vantagens:

• Eles têm uma compreensão profunda do sistema.
• Eles podem ter uma pequena feature para que a automação seja concreta e realista.
• O aprendizado criado durante o teste -automação não será perdido.
• Há visibilidade na automação de testes à medida que os itens vão no Backlog do Produto.

Todos os testes passam - pare e conserte

Testes falharam?

Pare e conserte!

“E seus testes automatizados?” Perguntamos aos grupos de produtos quando os visitamos. Às vezes eles respondem: “Temos 800 testes automatizados, dos quais 200 estão falhando agora.” Esta é uma fila enorme e causa uma completa falta de transparência no desenvolvimento. Quando os testes automatizados falharem, corrija-os imediatamente.

Tenha tolerância zero em defeitos abertos

Por que as pessoas insistem em criar defeitos? Eles gastam esforços para inserir um defeito, depois precisam procurá-lo, priorizá-lo e, por fim, corrigi-lo. Não criar o bug em primeiro lugar seria muito menos trabalho.

Nós acreditamos que é possível escrever * código livre de bugs *. * Não * acreditamos que seja fácil ou comum. Ainda assim, foque na prevenção de defeitos.

“Tolerância zero em defeitos abertos” é uma diretriz usada por um de nossos clientes. Se eles encontrarem um defeito, eles consertam o mais rápido possível. Isso evita:

• esforço gasto no rastreamento de muitos defeitos
• esforço gasto em priorização
• atrasar o aprendizado que acontece ao consertar um defeito
• gastando tempo extra na correção porque os desenvolvedores não se lembram mais do código

Atrasar a fixação de erros é uma falsa economia, já que eles precisam ser consertados de qualquer maneira e o custo será maior. Mover bugs de fila para fila é enganar a si mesmo - eles ainda estão lá!

Conclusão

O teste não é o que costumava ser. As barreiras entre o teste e a programação precisam ser demolidas. Testes e programação são dois lados da mesma atividade feita pelas mesmas pessoas. O objetivo dos testes muda de encontrar defeitos para preveni-los, escrevendo as especificações como testes; e desde a verificação da implementação até a condução do projeto. Essa perspectiva fundamentalmente diferente leva a mudanças vitais na forma como as pessoas trabalham - e trabalham juntas.

Leituras recomendadas

• Agile Testing , por Lisa Crispin e Janet Gregory. Uma ótima visão do papel do teste no desenvolvimento ágil. Ele aborda os desafios que as organizações enfrentam ao adotar o desenvolvimento ágil e também descreve o papel concreto do teste durante a iteração.
• Lessons Learned in Software Testing , por Cem Kaner, James Bach, and Bret Pettichord. Este livro descreve as lições aprendidas com décadas de experiência em testes e também introduz a escola de pensamento baseada em contexto em testes de software.
• Agile Testing Directions , by Brian Marick. Uma série de posts em que Brian Marick apresenta os quadrantes de testes ágeis.