Bug no Gmail

Estava desenvolvendo a funcionalidade de aplicação de tags para as menções no Vizir, e durante o desenvolvimento tomei como base do comportamento dessa funcionalidade,  a aplicação de labels do Gmail.

Durante o estudo do funcionamento da criação dos labels no Gmail, acabei encontrando um bug interessante, que mostra bem como nem sempre podemos cobrir todas as situações de erro, uma vez que elas são muitas.

Para quem não conhece essa funcionalidade do Gmail ou não usa o Gmail, segue uma breve explicação sobre ela:

Você quer aplicar um label (marcação) para um e-mail, por exemplo: todos os e-mails de promoções com o label “promoções”. O que essa funcionalidade faz, é exatamente prover uma maneira de aplicar labels aos seus e-mails.

Vamos direto em como reproduzir o bug:

1. Clique no checkbox ao lado do e-mail que você quer aplicar o label;
2. Clique no combo-box Labels;
3. Clique na opção Create new (um pop-up irá aparecer);
4. Digite o nome do seu label e clique no botão OK (“OK” para um botão de criação é estranho hein, poderíamos sugerir uma melhoria).

Pronto, viu o bug? Não?

Sem um screenshot fica difícil, neh. Segue abaixo uma imagem com cada passo feito, clique nela para visualizar numa resolução maior .

E agora viu o “danado”?

Se você nunca usou essa funcionalidade dessa maneira (tem como usar ela criando filtros pré-definidos), está descontado. Mas se você já usou deve/deveria ter reparado que faltou algo.

Quando você aplica um label na mensagem duas coisas acontecem:

• Uma mensagem aparece em cima da box dos e-mails, avisando que a “conversação” foi adicionada no label (The conversation has been added to “qualidadebr”.)
• O e-mail/conversação é marcado com o label.

O que faltou foi a segunda forma de notificação, o label não foi adicionado no e-mail (visualmente, se você atualizar a página irá visualizar o e-mail com o novo label). O interessante que esse bug só ocorre quando você aplica um novo label ao e-mail, se você for aplicar um label já existente, o bug não irá ocorrer.

Abaixo, o resultado esperado:

Pelas entranhas do bug

Com a explicação acima um bom desenvolvedor já iria descobrir o porquê do bug existir.

O que ocorre por de trás das câmeras quando você aplica um label ao e-mail, é que uma atualização via AJAX é feita em duas partes da página: no div da mensagem e no div dos labels.

O problema não é que a atualização não é feita no div dos labels, e sim que o elemento não é adicionado, provavelmente porque o novo label não foi adicionado na varíavel que contém os labels.

E como saber tudo isso?

Te contar que nem precisa entender muito de Javascript e HTML. Utilizando o formidável Firebug você já consegue observar esse comportamento. Difícil é entender o HTML gerado pelo javascript do Gmail (se estiver curioso em entender um pouco como o Gmail funciona esse artigo pode ser útil).

Como solucionar esse bug?

Eu passei pelo mesmo problema na implementação da funcionalidade de aplicação de tags nas menções no Vizir. A solução que encontrei foi dá um refresh na página, quando uma nova tag é inserida. Desta forma, o objeto que armazena os labels já é atualizado com o novo label.

Não deve ser a solução mais linda e elegante, talvez seja possível atualizar a lista de labels do combo-box, via Javascript. Mas como eu não sei fazer isso (preciso dá uma pesquisada se é possível e como fazer [canelada pra mim]),  e essa solução se comportou bem e foi eficiente para o problema que enfrentei. 🙂

Como esse bug escapou dos jardins do Google?

Sou usuário do Gmail desde 2007, e desde lá, só uso ele como cliente de e-mail, tanto para uso pessoal como profissional. E só no começo desse mês que encontrei esse bug.

Ou seja, acredito que este bug não se apresenta com tanta frequência, pois nem todos usuários utilizam esse recurso (diria até, que uma minoria utiliza). Além disso, o uso mais frequente dos labels, pelo menos o uso que mais faço e vejo as pessoas fazerem, é na criação dos filtros.

E a equipe de Teste de Software do Gmail, por que será que eles não encontraram esse bug?

Tenho duas especulações quanto a isso:

• Encontraram o bug, porém como a sua ocorrência não é tão frequente e sua presença não atrapalha muito o usuário, o bug ainda não foi corrigido (tá na fila no bugtracking deles, com prioridade baixa);
• Não encontraram, pois não tinham um caso de teste que cobria esse cenário.

A grande lição que podemos tirar com esse bug, é que um sistema pode muito bem ir para produção, ser super bem elogiado pelos usuários e mesmo assim conter dezenas de bugs (eu conheço uns 3 ou 4 só do Gmail rs). Se você for querer ser perfeccionista ao extremo, você nunca irá colocar um sistema em produção. Um sistema sem bugs não é algo comum, e esse fato é até justificável, é só olhar para as pessoas que desenvolvem e usam os sistemas, elas são perfeitas?

Fique por dentro das novidades, assine o feed do QualidadeBR.

Padronização de caso de teste. Pluralizado ou integrado?

A 23ª Mesa Redonda DFTestes foi sobre “Padronização de caso de teste. Pluralizado ou integrado?”. A discussão até o presente momento, teve 23 respostas e 8 participantes sendo eles: eu, Felipe Silva, Elias Nogueira, Edwagney Luz, Renata Eliza, Shmuel Gershon, Sarah Pimentel e Lucas Nadalete.

A mesa redonda começou bem fria, estava dando pinta que nem iria dar muita discussão, mas de repente, ela estourou. E vários comentários relacionados ao assuntos foram feitos, boas analogias e explicações foram feitas, mas até o momento não conseguimos saber o que é um caso de teste pluralizado e integrado. :s

A seguir, faço um resumo dessa excelente mesa redonda, que é altamente recomendável a sua leitura na íntegra, pois vários assuntos foram discutidos durante a mesa redonda, e como sempre faço o resumo focado no tema da discussão, alguns bons comentários sobre outros assuntos ficam de fora.

Padronização de caso de teste. Pluralizado ou integrado?

Até o momento desse post, ninguém conseguiu explicar o que seria um caso de teste pluralizado ou integrado. Tal terminologia, provavelmente deve ser bem específica, já que ninguém, tinha ouvido ela antes.

E falando em termos, o Edwagney fez um comentário bem pertinente:

Sinceramente, não vejo nenhum motivo para acrescentarmos mais conceitos como “Pluralizado ou Integrado”. Acho totalmente desnecessário!

Na minha opinião, realmente é desnecessário criar novos termos, principalmente, quando eles não são “auto explicativos”.

O Elias Nogueira fez uma interpretação que se não é a correta em relação aos termos é correta em se tratando de casos de teste:

Se eu interpretei bem o enunciado dessa mesa redonda, e seria interessante o outro desse tópico explicar, é a diferença entre o pluralizado e o integrado.
Pelo entendimento que tenho disso, creio que seria:

• Pluralizado: Casos de teste distintos. Esses seriam como: Inserir Cliente com sucesso, Inserir Produto com sucesso, Emitir NF, Calcular impostos, etc… Logo um Caso de Teste no cenário: “cada um no seu quadrado”. Cada um executa uma ação específica para o que ele realmente é proposto
• Integrado: Casos de Teste que “agrupam” todos os testes a fim de chegar a um objetivo comum. Seria como eu criar apenas um Caso de Teste para Emitir uma NF, sedo que tenho passos do cadastro do cliente, cadastro de produtos, calculo de impostos, etc…

Se for nessa linha de pensamento, e na minha linha purista, os Casos de Teste Pluralizados são os corretos, e não existe qualquer outra nomenclatura ou “agrupamento” de Casos de Teste. O que criamos quando temos uma linha parecida com o Integrado são Cenários de Teste.

Padronização de caso de teste. Detalhado ou resumido?

O Felipe Silva acabou sugerindo a questão “Padronização de caso de teste. Detalhado ou resumido?”, no lugar da questão tema da mesa redonda, por essa terminologia ser mais conhecida. A respeito da questão, o Felipe mesmo deu a sua opinião dizendo, subentendo que pluralizado seria um caso de teste mais resumido e o integrado um caso de teste detalhado:

Se eu entendi corretamente, pluralizado seria um caso teste escrito de forma genérica, que não contém detalhes específicos, e integrado seria aquele caso de teste com o máximo possível de step detalhados com toda informação específica, o famoso caso de testes “que até minha mãe conseguiria ler, executar e avaliar o resultado”.

Se for mesmo isso, prefiro o modelo básico (pluralizado), este é mais fácil de ser escrito e mantido, porém os detalhes que não estão escrito precisam estar na cabeça de quem executa, portanto exige que sejam executados por experts no projeto.

Já houve uma discussão sobre o tema no DFTestes.

Para mim, seguindo o entendimento do Felipe, a resposta para a pergunta depende do contexto em que se está testando. Como o Felipe disse, o genérico/pluralizado exige que o testador tenha domínio sobre as regras de negócio e a aplicação. Já o detalhado/integrado não exige um domínio sobre as regras de negócio e a aplicação por parte do testador.

Outros pontos interessantes, é em questão da manutenibilidade, estabilidade e velocidade. O caso de teste genérico/pluralizado tem maior manutenibilidade e estabilidade, pois como ele é mais a nível do que fazer e não como fazer, acaba sendo mais curto, portanto mais fácil de manter, e é menos “quebrável”, já que não entrar em detalhes de implementação (ex.: nome do campos). Já em questão de velocidade, mais uma vez o teste genérico/pluralizado leva vantagem, pelo mesmo motivo de que ele é mais fácil de manter.

Resumindo, se você é quem especifica os casos de testes e testa, ou você é um testador já experiente, então o mais indicado pode ser o caso de teste genérico/pluralizado. Agora se quem irá executar os testes não tem pleno conhecimentos das regras de negócio e da aplicação, ou ainda, os testes podem ser reutilizados num futuro (exemplo manutenções no software), o mais indicado pode ser o caso de teste detalhado/integrado.

O Elias Nogueira acredita que um bom caso de teste precisa ser detalhado, segundo ele:

Quanto a isso, ainda sou meio “purista” e creio que um bom Caso de Teste precisa ser detalhado. Precisa sim conter os passos como condições de uso e ser muito bem estruturado.

Existem sim várias formas de criar os Casos de Teste no Test Design, sendo o mais usual a de Heumman para criar os Casos de Teste a partir dos Casos de Uso.

O que define o grau de detalhamento são os tipos de teste para qual o(s) Caso(s) de Teste estão sendo escritos.
Quando vou escrever um Caso de Teste em nível Unitário, obviamente ele será diferente do de Sistema que estamos acostumados a criar. Escrever um Caso de Teste para algum cenário de Performance também é diferente de um Caso de Teste Aceitação.
Os Casos de Teste podem ter a entrada do seu processo os seguintes fatores:

• Requisitos de Negócio
• Interface com o Usuário
• Domínio de entradas

Com o detalhamento, a equipe vai saber de regras que nem o Analista de Requisitos/Sistema saberá mais depois de 1 semana… e pra onde vai o conhecimento dessas regras?
Outro ponto também é que com um Caso de Teste detalhado, qualquer um na tua equipe, ou qualquer um que entrar na equipe, poderá ter um conhecimento maior da aplicação na execução destes Casos de Teste.

Claro que, em nossa realidade isso muda constantemente. Eu trabalho hoje num “Fábrica”, e sou obrigado a escrever Casos de Teste detalhados para os Testadores, que as vezes nem conheço. Se eu não fizer isso, posso deixar aspectos importantes passar não pelo pouco detalhamento do Caso de Teste, e sim da interpretação do Testador.

Já na realidade de quem não trabalha em uma Fábrica, creio que o nível de detalhe não é alto pelo alto conhecimento da aplicação que estes profissionais já tem.

A respeito da opinião do Elias, eu não acho que seja uma questão de qual é o melhor detalhado ou genérico/resumido. Ambos tem os seus pontos positivos e negativos. O importante é que o profissional de teste saiba da existência dos dois, pois é ele quem irá decidir por optar um ou outro.

A Renata Eliza deu a sua explicação sobre o caso de teste Step by Step (o famoso passo a passo), que seria o detalhado e o cenário de teste, que seria o mais resumido:

Acredito que as distinções dos Casos de Teste teriam mais sentido se fossem do tipo:
– Casos de Teste Step by Step: quando o objetivo é cercar, através de casos de teste detalhados todas as possibilidades de um determinado documento da especificação. Como por exemplo, o Caso de Uso.
– Cenários de Teste: que dá uma ideia mais generalizada do que deve ser testado naquele determinado cenário. Mais voltado para profissionais experientes, que têm a visão do que realmente precisam fazer.

O Edwagney falou sobre caso de teste detalhado, fazendo importantes considerações que nos podem levar a escolher ele:

Também não acho interessante que sejam elaborados apenas casos de teste detalhados. Isso depende muito da empresa que está usando o processo e como ela deseja documentar isso. Para uma empresa que existe grande rotatividade de profissionais, talvez seja interessante um maior nível de detalhe, entretanto, outra que tem uma política de manter seu grupo e treinar novos profissionais, o detalhamento fará um efeito contrário. Ao invés de ajudar, vai atrapalhar, pois o grupo é coeso e experiente, e não necessita de um alto nível de detalhamento para que o caso seja executado com qualidade e dê o resultado que se espera. Digo isso porque já trabalhei com esses dois tipos de empresas.

Nas consultorias que faço e nas empresas que eu trabalhei com isso, quando elegemos um caso de teste passivo de automatização, onde chegamos a um nível de detalhamento que seja possível sua automatização. Para os que não é possível a automatização, o nível de detalhamento segue sempre o bom senso e a forma de trabalhar da empresa

Coloco também uma outra variável para incrementar a questão, depende também do ramo de atuação da empresa. Se ela for especialista demais e seus profissionais idem, ao detalharmos os casos demais, ninguém usa e o processo cai todo por água abaixo. Um exemplo muito bom é a área de Telecom. É uma área tão específica e tão especialista, que para uma pessoa conseguir executar um tipo de teste, tem que ter uma série de requisitos básicos, que se formos colocar todas essas informações em um caso de teste, seria gasto tanto tempo que se tornaria inviável. E quando a pessoa já está devidamente treinada, ela não usa os casos detalhados, pois eles, ao invés de ajudar, travam a produtividade. Isso em caso de teste manual.

O Edwagney ainda deu uma excelente e bem didática explicação sobre a “cadeia”  dos casos de testes:

Faço a comparação com uma peça teatral, onde o nome da peça, seria a suíte de testes; os cenários, naturalmente os cenários do teste; as cenas, os casos de teste; e os atos dos atores a sequencia de execução cada cena ou caso de teste.

A Sarah Pimentel deu a sua opinião sobre a questão dizendo:

Entre um caso com mais detalhes e outros com menos, pra mim a resposta é como a da maioria das mesas redondas que temos: depende 😛

Se temos um caso de teste detalhado demais, e temos a política de capturar telas que comprovam a execução de cada passo, começa a ser um trabalho enfadonho, especialmente os testes de regressão que executamos inúmeras vezes.

Se temos um caso de teste genérico demais, corremos o risco de o testador não entender bem o step ou não verificar todos os pontos que o autor imaginou que ele verificaria.

Pra mim, assim como um documento de requisitos, o caso de testes está bom quando especifica tudo e não deixa brechas para interpretações. Se algo precisa ser verificado, deve estar explicitamente detalhado em algum passo. Se algo não precisa de tanta atenção (pode ser o caso de alinhamento de labels, nomes de campos que mudaram para outros similares, cores, posicionamento de objetos)… Não precisa estar descrito. Não que esses itens não devam ser testados, mas tem aplicações nas quais isso é um fator importante e outras em que não. Então depende do teu objetivo.

Para casos de teste que exigem uma busca um pouco mais complexa de dados, por exemplo, bastaria eu dizer que eu preciso de “um contrato de manutenção de hardware válido para atendimento físico com SLA de 48h” ou eu colocaria na pré-condição uma query que trouxesse esses tipos de contrato para o testador? Pouparia bastante tempo se ela já estivesse lá. E essa é uma decisão, pra mim, similar a de cima. Se vamos ganhar tempo e acuracidade, opto por detalhar. Se vamos burocratizar e onerar a manutenção e a execução, opto por generalizar.

O Lucas deu a sua opinião contando um pouco da sua experiência:

Na empresa onde trabalho temos situações onde as especificações dos Casos de Teste tendem a ser mais detalhadas quando dispomos de um prazo aceitável, escopo e especificação de Caso de Uso bem definidos e o profissional responsável por automatizar ou executar manualmente os testes não possui muita experiência a respeito do ambiente e negócio; já por outro lado, também nos deparamos com situações onde os Casos de Teste tendem a ser definidos de uma forma bem mais genérica, sem muitos detalhes (step-by-step), com uma descrição mínima do Caso de Teste, das entradas e das saídas esperadas. Este segundo ocorre principalmente quando há um cronograma bem mais enxuto que o esperado e o testador é alguém que conhece muito bem as regras de negócio do produto/projeto alvo.Em outras palavras, a forma como os Casos de Teste são especificados, varia e bastante. Sou extremamente a favor de se trabalhar com Casos de Teste Padronizados, mas se analisarmos com calma nem sempre as variáveis envolvidas são favoráveis, tais como: cronograma, artefatos (especificação de caso de uso, requisitos, …), ambiente, experiência do testador (técnica e negócio), automatizado/manual, enfim; e por serem elementos variáveis, os mesmos tendem a impactar na forma como os Casos de Teste são definidos, quando realmente são definidos.

Como exemplo, quando o testador tem pleno conhecimento do contexto de negócio, e o script de teste tende a ser automatizado, os Casos de Teste aqui na empresa são especificados genericamente, e o detalhamento (step-by-step) do teste fica por conta do script. Apesar de não ser a melhor prática, principalmente do ponto de vista de manutenibilidade, isso nos possibilita trabalhar a especificação dos Casos de Teste, automatização dos scripts, execução dos testes e gestão de defeitos, dentro do prazo esperado para as entregas/implantações.

Cuidado com o que você chama de caso de teste

O Elias fez um comentário bem pertinente sobre o que chamamos de caso de teste:

Uma outra coisa que não posso deixar de comentar: os que até hoje tratam em alguns lugares o Caso de Teste como sendo um passo. Aquelas planilhas em Excel gigantes, onde um profissional fala que tem 5.000 Casos de Teste, que na verdade são passos.
Isso pra mim é a pior coisa que um profissional pode fazer, além das empresas que vendem a atividade de criação de Casos de Teste por quantidade.

Sobre o assunto, o Lucas fez o seguinte comentário:

A respeito das famosas planilhas Excel, é extremamente importante não confundir um “caso de teste” por mais genérico que seja, com uma linha em uma planilha eletrônica que na realidade representa um simples “passo”. Já me deparei com situações onde a própria equipe de desenvolvimento gera uma planilha dessas com os testes executados por eles mesmos, e ao realizarem a entrega repassam o artefato como quem diz: “aqui estão as entregas e estes são os testes executados, só refazer”, ou seja, totalmente sem fundamento. Diante de uma simples “verificação” é possível evidenciar vários fluxos (alternativos ou de exceção) que não foram contemplados, bem como validações efetuadas incorretamente.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Quando documentar não é preciso?

O tema da última Mesa Redonda DFTestes de 2009 foi “Quando documentar não é preciso?”, e teve 18 respostas e 7 participantes: eu, Felipe Silva, Milton Vopato, Sarah Pimentel, Rodrigo Almeida de Oliveira, Marcelo Andrade e o Eduardo Gomes.

A discussão foi bem produtiva, e ao longo dela novas dúvidas e assuntos foram abordados sobre documentação em geral. No próximo parágrafo começa o resumo da sétima mesa redonda, e mais uma vez, fica o convite para ler toda a discussão, caso o tema seja de seu interesse. 😉

Quando documentar não é preciso?

O Felipe Silva iniciou uma lista dos momentos que é preciso documentar, e depois eu adicionei dois itens a mesma:

• Necessitar arquivar evidências;
• Arquivar banco de conhecimentos (todos aqueles que servem como consulta para quaisquer tarefas);
• O contrato obrigar;
• Alta rotatividade na equipe;
• Disseminar o conhecimento (nesse caso há outras alternativas também (como reuniões, trabalhar em par), mas a documentação é a forma menos volátil).

Uma segunda lista foi iniciada pelo Felipe Silva, com todos os documento que são necessários em qualquer projeto de testes e aqueles que podem vir a ser úteis em casos separados, e depois adicionei alguns itens:

• Documentos necessários em qualquer projeto:
  • Casos de Testes;
  • Registro de bugs;
  • Relatórios.
• Necessários? Vocês usam? Independente se usam, acham bom ter?
  • Cenários de Testes;
  • Plano de Testes;
  • Estratégia de Testes;
  • Especificação de Projeto de Teste;
  • Especificação de Procedimento de Teste;;
  • Relatório de Sumário de Teste;
  • Relatório de Incidente de Teste;
  • Log de Teste.
• Outros:
  • Plano de automação de testes;
  • Estratégia de automação;
  • Relatório de Encaminhamento de Item de Teste.

Eu entendo que documentar serve para os seguintes fins (pensando em documentação de Teste de Software):

• Ajuda o entendimento do sistema, quando você cria a documentação de Teste de Software, você entende melhor o sistema, e ainda abstrai as informações para o mundo de Teste de Software;
• Compartilhamento de conhecimento com a equipe, se fizer todos os meus testes de forma exploratória como que uma outra pessoa poderá realizar os mesmos testes?
• Transmitir informações para os stakeholders do projeto;
• Gerar uma base histórica, que poderá auxiliar em futuros projetos.

E tudo depende da sua realidade, por exemplo: se o cliente não exige documentação de Teste de Software, você tem conhecimento do sistema sob teste e o prazo é curto. Você pode testar só de forma exploratória, sem documentar os seus testes, e poderá até mesmo passar os defeitos diretamente para os desenvolvedores (informalmente).

Lógico que o exemplo citado acima, não é muito correto e bem extremo. Só que nessas situações você precisa fazer escolhas, e entre garantir a qualidade do sistema sob teste ou garantir que todas as atividades do Teste de Software sejam cumpridas, eu fico com garantir a qualidade do sistema sob teste.

Eu não vejo nenhum problema em documentar, com tanto que essa documentação tenha alguma finalidade, documentar por documentar, é perda de tempo, e por consequência, perda de dinheiro.

Para o Milton Vopato:

A documentação dos testes é fundamental, para melhoria continua e além disso, pensando no dia a dia, para segurança da própria equipe de teste, pois é uma evidência de cobertura dos scenarios propostos.

A Sarah Pimentel compartilhou um pouco da sua experiência com documentação:

Já estive em um projeto de consultoria de testes, onde o nosso papel era analisar requisitos e casos de uso e gerar documentação para realização de testes por uma outra equipe.

Documentos gerados:

• Casos de teste (obvio :))
• Roteiro de testes (em que ordem devem ser executados os testes gerados)
• Massa de dados (listagem de dados necessários para a execução dos testes)
• Matriz de rastreabilidade de testes (o caso de teste gerado refere-se a que/quais caso de uso entregues pelo cliente)
• Registro de desvios (gaps encontrados na documentação enviada)

Em um outro projeto o trabalho foi configurar uma ferramenta (no caso, Quality Center), gerar casos de teste para a aplicação, treinar a equipe de testadores (inclusive para fazer atualizações posteriores no teste).

E já trabalhei em projetos com um MONTE de documentação também. Isso pra dizer que “tudo é relativo” 🙂 O que importa é gerar o que vai ser útil e o que você consegue manter. Não adianta produzir toda a documentação do RUP se você não consegue mantê-la alinhada entre si e se o próprio time não a consulta.

O Rodrigo Almeida expôs a sua opinião dizendo:

Na minha opinião, documentar só por documentar não se justifica. Toda atividade num processo precisa gerar valor. Se não é só pedágio!

Existe um mínimo que é obrigatório no nosso processo hoje: O caso de teste e/ou uma evidência de teste e um relatório de painel de bordo das homologações.

Quando fazemos um projeto aí temos também o Plano de Testes.

Para o Marcelo Andrade, não é necessário documentar quando o documento:

1. Não seja de fato útil, mas precise ser feito apenas por que o processo assim determina;
2. Não é mantido atualizado (de certa forma, uma consequência do item 1);
3. Não é compreendido pelas pessoas para quem ele foi escrito (outra consequência do item 1).

O Marcelo ainda comentou sobre documentos difíceis de serem compreendidos e compartilhou o link para um bom artigo sobre documentação:

Se sua equipe de desenvolvimento gera documentos difíceis de entender, que não atendam ao seu propósito, que estejam sempre muito defasados e não sejam efetivamente utilizados, isso não é valorizar a documentação. Longe disso. Valorizar a documentação é dar real importância aos documentos gerados, fazendo com que eles agreguem valor ao cliente e sejam usados de fato para apoiar o trabalho da equipe.

Volto a indicar este esclarecedor artigo do InfoQ sobre o assunto:

http://www.infoq.com/br/news/2009/08/agile-documentation

Outro link bem legal sobre documentação ágil, é esse abaixo, de um vídeo que o Vinícius Teles fez sobre documentação ágil:

http://blog.improveit.com.br/articles/2008/08/01/documenta%C3%A7%C3%A3o-%C3%81gil

O Eduardo Gomes compartilhou a sua opinião dizendo:

A necessidade de documentação é sempre motivo de debate e gera argumentações apaixonadas, tanto a favor como contra. Quando falamos da documentação dos testes, essa discussão fica ainda mais acalorada, pois muita gente entende que a documentação do sistema já é um “trabalho jogado fora”, quanto mais documentar os testes. É uma visão característica dos desenvolvedores, que estão preocupados em construir as soluções e veem na documentação um entrave ao seu trabalho. E em muitos casos isso é realmente o que acontece.

Mas se observarmos os modelos de maturidade de software, percebemos que a documentação é peça chave no esforço pela melhoria de processos e para a qualidade dos produtos. Sem uma documentação, automatizada ou não, dificilmente conseguimos atingir níveis satisfatórios de maturidade nos processos. Prefiro enxergar a documentação como um investimento e não como um trabalho jogado fora.

Quanto à documentação de testes, utilizamos atualmente, 04 artefatos básicos:

• Plano de Testes (Escopo, riscos, estratégia, ambiente, intervenientes, aprovações, etc);
• Roteiros de Testes (Casos de teste, massa de teste relacionada, especificidades do teste etc);
• Relatórios de Testes (Resultados da execução dos testes, evidências, gestão dos defeitos etc);
• Relatório Final (Resumo dos testes, pareceres, validações etc).

Esse conjunto completo de artefatos é aplicado somente sobre projetos, que possuem um escopo maior de teste e também outros artefatos relacionados ao desenvolvimento, que servem de insumo para a construção da documentação de teste. Em intervenções menores, somente os relatórios de testes são exigidos, principalmente para evidenciar os testes realizados, na maioria dos casos pelos próprios desenvolvedores. Mas tudo isso faz parte de uma estratégia de melhoria dos nossos processos, que deve alcançar níveis mais elevados de maturidade em breve.

Como tornar a documentação do Teste de Software eficaz?

O Felipe Silva acredita que:

As documentações devem ser efetivas, e sou favor de casos de testes diretos e objetivos – sem steps desnecessários à validação, sei que muitos vão discordar de mim, mas assim que é legal (gerar discussões).

Devemos sempre gerar apenas documentações que serão lidas, digo isso porque já vi casos onde são gerados vários artefatos só pra ficar no repositório (o contrato obriga) e no pior dos casos o próprio processo de testes da organização que diz que tal artefato – que não serve pra nada – deve ser gerado só para mostrar para o cliente, e piora, pois o sistema muda por alguma solicitação de mudança ou versão de requerimento nova e o tal artefato fica do mesmo jeito, nem quem escreve se importa em atualizá-lo pois sabe que ninguém irá usá-lo como base pra nada.

Eu vejo que esse é um grande desafio. Acho que o primeiro passo a fazer é listar quais documentos que estão sendo gerados pela equipe, e responder as seguintes questões (deve ter outras):

• Qual o objetivo desse documento?
• O documento está otimizado? (tem apenas os tópicos adequados para o projeto)
• Alguma sugestão de melhoria para o documento?
• Há alguma dificuldade em manter o documento? (ex.: mudanças de requisitos constantes)
• Há alguma ferramenta que possa auxiliar a criação do documento?
• O tempo levado para a criação do documento é o esperado?
• O documento está armazenado em um local seguro e acessível?
• As pessoas estão seguindo algum padrão para a criação do documento?
• Quais são as pessoas que irão utilizar esse documento? A linguagem está adequada com esse público?

Um segundo passo é tornar a documentação “viva”, ou seja, automatização dos testes, sempre que possível e viável. 🙂

O Eduardo Gomes acredita que:

Qualquer documentação deve ser a mais simples possível, mas que permita o registro das informações que a organização considera imprescindíveis. E nessa análise cada organização deve definir sua documentação básica, mas deve também explicitar a seus colaboradores os objetivos a serem alcançados e as estratégias utilizadas, para que consiga da equipe o comprometimento e a motivação necessários. Sem isso, vai ser realmente “trabalho jogado fora”.

Durante a discussão a Sarah Pimentel colocou três novas questões para esquentar o debate.

Eu posso ao invés de criar test cases, basear meus testes nos requisitos ou user stories?

A própria Sarah respondeu dizendo que:

Essa é uma abordagem estranha pra mim. Me sinto mais confortável com a idéia da criação de uma documentação criada para o propósito de teste. Mas considerando que no caso de uso, requisito ou user story tem todos os fluxos (pode-se assegurar isso com revisões da equipe de teste), é uma documentação que poderia servir como base para testes…

Na minha opinião deixar de criar os casos de teste é um pouco perigoso nesses casos, e quando eu digo criar um caso de teste, pode ser tanto um manual (no Test Link), ou um automatizado (no JUnit, por exemplo).

Mas não vejo problemas em basear os testes nos requisitos, até porque eles são a fonte principal, quando escrevemos testes de aceitação, por exemplo. E as user stories dão uma visão geral da funcionalidade, mas só com ela como base, fica difícil explorar a árvore de possibilidades da funcionalidade, geralmente é preciso ter algum outro documento para apoiar ou conversar diretamente com o desenvolvedor.

E se ao invés de requisitos, documentarmos apenas os testes? Colocarmos as solicitações do cliente não como requisitos mas como cenários de teste? Perderíamos alguma coisa?

O pessoal que pratica BDD (Behavior Driven Development), costuma comentar que é possível utilizá-lo para detalhar os requisitos funcionais. Neste caso você já estaria documentando e escrevendo um teste (e a sintaxe do teste é bem fácil de entender, e há ferramentas, como o Cucumber, que até permitem escrever em português).

Acho que não iremos perder, mas corremos o risco de detalhar muito cedo as coisas. E nem sempre isso é possível, pois o cliente também poderá consultar os requisitos, futuramente, e se estiver em uma linguagem muito técnica, ele poderá ter dificuldade de entender.

Em uma abordagem TDD, como fica a criação de documentação de teste? Ela se torna dispensável em alguns pontos? Passa a ser apenas o Unit Test?

Eu vejo que a documentação passa a ser “viva”, pode ser executada a qualquer momento, e o desenvolvedor terá um rápido feedback se a funcionalidade que ele está desenvolvendo está ou não de acordo com a documentação criada (testes).

Em relação ao documentos gerados, normalmente, por uma equipe de Teste, acho que eles continuar existindo (até porque só estamos documentando os casos de testes de forma automatizada), principalmente, se houver uma equipe de Teste de Software no projeto. E ainda haverão os testes manuais, que necessitarão ser documentados, da forma tradicional. E a própria equipe de Teste de Software, pode deixar de criar um caso de teste no Test Link e automatizá-lo no Selenium, por exemplo, e mesmo assim, a equipe não está deixando de documentar.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

Fique por dentro das novidades, assine o feed do QualidadeBR.