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.
QualidadeBR 