Bem, vou falar aqui de algo que sempre me ajudou em meu trabalho. Conversando com meus colegas, para alguns deles é algo totalmente novo, para outros, apenas uma forma de organização (eu concordo com ambas opiniões). Diagramas de Caso de Teste... E isso existe? Bem, para a minha necessidade, sim. E comecei a elaborá-lo quando me tornei o Analista de Testes de uma equipe de desenvolvimento. Analisando cada Caso de Uso do sistema, percebi que seriam gerados em torno de 6 a 8 Casos de Teste por Caso de Uso (!!!!!), devido à complexidade. Como não havia um processo de testes definido, senti a necessidade de organizar e procurar facilitar rapidamente todo o meu trabalho, pois entrei na equipe que estava com mais de 2 anos de desenvolvimento... e o sistema era enorme!
Inspirei-me nos Diagramas de Caso de Uso e nos Diagramas de Atividades para elaborar esse diagrama e creio que possa ajudar vocês a terem um ‘norte' quando forem testar o sistema e os Cenários. Ele ajuda também na organização quando forem testar sistemas grande, com muitas de Regras de Negócio e Fluxos complexos.
A notação utilizada é a da UML (Diagrama de Caso de Uso).
Coloquei aqui de uma forma mais didática e explicativa (Diagrama de Caso de Uso adaptado) para que vocês pudessem entender como foi que eu cheguei nessa organização.
Espero que gostem!
Bem, o Diagrama de Caso de Teste tem por objetivo, auxiliar na visualização do Cenário como um todo do ponto de vista do Analista de Testes e o Testador. Ele testa um Cenário com suas principais funcionalidades e suas integrações.
Notação:
* Atores
* Casos de Teste
* Relacionamento entre estes elementos
Estes relacionamentos podem ser:
* Associações entre Atores e Casos de Teste
* Generalizações, extends, includes entre os Casos de Teste
Os Casos de Teste podem estar opcionalmente estar envolvidos por um ou mais retângulos (herdado dos Diagramas de Casos de Uso), onde representam os limites do Cenário.
Em maiores detalhes:
![]() |
Um Ator é representado por um boneco e um rótulo com o nome do Ator. Um Ator, na situação em questão, o Analista de Teste ou o Testador que pode ser um usuário humano ou um sistema computacional. |
|
Um |
o Ajudam a descrever Casos de Teste
o Entre um Ator e um Caso de Teste
* Associação
![]()
Define uma funcionalidade do sistema do ponto de vista do usuário.
o Entre Casos de Testes
Include
Um relacionamento include de um Caso de Teste A para um Caso de Teste B, indica que B é essencial para o comportamento de A. Pode ser dito também que B é_parte_de A.
Extend
Um relacionamento "extendido" de um Caso de Teste B para um Caso de Teste A, indica que o Caso de Teste B pode ser acrescentado para descrever o comportamento de A (é facultativo). A extensão é inserida em um ponto de extensão do Caso de Teste A.
Ponto de extensão em um Caso de Teste é uma indicação de que outros Casos de Teste poderão ser "adicionados" a ele. Quando o Caso de Teste for invocado, ele verificará se suas extensões devem ou não ser invocadas.
Quando se especifica B extends A, a semântica é:
• Dois Casos de Teste são definidos: A e A é "extendido" por B;
• B é uma variação de A. Contém eventos adicionais, para certas condições;
• Tem que ser especificado onde B é inserido em A.
o Generalização ou Especialização (é_um)
* O Caso de Teste B é_um Caso de Teste A (A é uma generalização de B, ou B é uma especialização de A).
* Um relacionamento entre um Caso de Teste genérico para um mais específico, que herda todas as características de seu pai.
* Limites do Cenário: representado por um retângulo envolvendo os Casos de Teste que compõem o Cenário.
* Nome do Cenário: Localizado dentro do retângulo.
Caixa de Expedição de Documentos – Exemplo Básico 1
![]()
Cadastro de Clientes – Exemplo Básico 2
![]()
Comentários
Oi Ricardo, tudo bom?
Achei mto bom o seu artigo. Eu tb criei um template para realização dos casos de teste com base no livro "A Practitioner's Guide to Software Test Design". Acredito ser um doc amplo, pq com o mesmo doc eu consigo criar os casos de teste, fazer uma prévia, ou seja, um passo-a-passo para repassar aos desenvolvedores para que entendam, por exemplo, a melhoria solicitada e também utilizo para os testes de aceite. Este doc não é definitivo, estou sempre estudando uma forma melhor para aprimorá-lo. Conto com a sua opinião! Obrigada!
Cenário de Sucesso
A: Ator
S: Sistema
Nível de Complexidade
Resposta
Oi Ricardo, tudo bom?
Claro que pode copiar! Agradeço a sua observação e o template fica a disposição para quem tiver interesse!
Abraços!
Resposta
Cris, obrigado pelo seu elogio! Bacana demais essa troca de informações!!! Desculpa a demora na resposta... Bem, no template que você colocou, e no que eu entendí, é mais um "resumo" do Caso de Uso para a elaboração dos Casos de Teste. Eu particularmente só acrescentaria um campo de Resultado Esperado funcionando como um (Fluxo Básico..."o Caminho Feliz"). Mas de resto tá bacana por demais...posso copiar? kkkkkkk.......
Abraços!!!!
Ricardo Franco Custodio
IBM Certified SOA Associate [2008]
IBM Certified Specialist – Software Quality
IBM Certified Solution Designer - Rational Unified Process
desenvolvedor.ricardo@gmail.com
Parabéns pelo Post
Bom dia!
Estou encarregada de propor um novo modelo de Caso de Teste para a empresa onde trabalho. O modelo antigo era exatamente uma cópia do Caso de Uso com botões onde o usuário poderia assinalar se tal funcionalidade estava ou não atendendo o proposto. O que não ajudava em nada.
Durante várias pesquisas realizadas, e até alguns modelos que comecei a propor, cheguei a uma conclusão: eu estava testando para criar os meus Casos de Teste e não criando meus Casos de Teste para Testar.
Nossas aplicações são muito grandes, com muitas regras de negócio, algumas que impedem que 1 Caso de Teste seja utilizado mais de uma vez sem que seja analisado na aplicação se tal entrada já foi realizada. Pensei até em utilizar checklists ou mesmo roteiros de validação em vez de Caso de Teste (estes são mais resumidos e não traz os ingredientes (entradas e saídas), somente a receita rsrs).
Gostaria de saber se vocês utilizam Caso de Teste como descritos nas bibliografias: Entradas e saídas para todos campos? Como tem sido a manutenção (em relação a tempo)? Esta utilização realmente traz resultados?
Desde já, muito obrigada pela atenção!
Aguardo retorno.
Resposta ao questionamento acima!
Leidiane, muito obrigado pelo elogio e pelo questionamento. 100% válido!
Respondendo....
Gostaria de saber se vocês utilizam Caso de Teste como descritos nas bibliografias: Entradas e saídas para todos campos? Como tem sido a manutenção (em relação a tempo)? Esta utilização realmente traz resultados?
Na empresa onde hoje estou trabalhando, os Casos de Teste tem sim, Entradas e Saídas (Inputs e Outputs). Baseado e montado praticamente como um Caso de Uso. Com o Fluxo Básico, Fluxo Alternativo, Fluxo de Exceção, Regras de Negócio do Cenário e Regras de Usabilidade. A solução e a estratégia que a equipe encontrou para testar foi essa, porque cada tela do sistema tem um bocado de Regras de Negócio então ficava inviável aquela solução de 'esse botão faz isso, aquele botão faz aquilo, o resultado esperado....' e daí testar a aplicação. E fora que o cenário descrito no Caso de Uso, nós dividimos em vários 'sub-cenários'.... Se quiseres e se puderes mande um email pra mim para que possamos trocar experiências e ajudar-nos.
Mais uma vez obrigado.
Abraços!
Ricardo Franco Custodio
IBM Certified Specialist – Software Quality
IBM Certified Solution Designer - Rational Unified Process
desenvolvedor.ricardo@gmail.com
ricardo@instructor.net
Interessante...
A gente usa aqui algo parecido, mas o diagrama é dividido por funcionalidade (que é uma demanda do negócio), que na verdade, é só uma maneira do próprio analista de testes se organizar na hora de criar o caso de teste.
Isso ajuda com o entendimento do negócio, pois nosso sistema já está em vigor há mais de 3 anos e manter-se-á por mais um bom tempo. A Matriz de Rastreabilidade foi feita no início mas não teve manutenção, o que a torna descartável. Hoje não temos tempo hábil para voltar a utilizá-la e o diagrama no estilo desse de casos de teste tem atendido nossas necessidades básicas, que são:
- Entendimento do negócio - que é muito complexo;
- Auxílio no desenvolvimento dos casos de teste;
- Auxílio e orientação na criação da massa de dados para o ambiente de testes;
- Análise de riscos - visão de outras funcionalidades que necessitarão fazer Smoke Testing
quanto ao tempo, no nosso caso é justificável, pois enquanto criamos o Diagrama de Funcionalidades e Roteiros de Teste por demanda, é o mesmo tempo (até menor) que o desenvolvedor demora para entregar a demanda desenvolvida.
Ainda estamos avaliando questão de eficácia e eficiência em relação ao processo anterior, até então, tivemos resultados satisfatórios.
att.
Luiz Gustavo Schroeder Vieira, CTFL, FCE
http://testavo.blogspot.com
Olá Ricardo! Achei bem
Olá Ricardo!
Achei bem válida a criação de uma forma de apresentar e explicar melhor o funcionamento dos Casos de Teste. Se ele te ajuda no dia-a-dia isto é ótimo.
Tenho algumas perguntas referente a ele:
Abraços!
Elias Nogueira
CSTE - Certified Software Tester
http://sembugs.blogspot.com
Resposta ao questionamento acima!
Legal! Achei bacana demais seus questionamentos. Porque muita coisa se encaixa (ou se encaixou) no meu dia-a-dia. E fora que eu sou um leitor assíduo do sem-bugs...Elias, me sinto honrado! rsrsrsrs...
Quantas pessoas realmente utilizam estes documento que tu estás apresentando?
Bem, até o momento como foi algo que organizei (não inventei), apresentei pros colegas de empresa por volta de uns 8 meses atrás e como existiam 4 equipes de teste, 3 deles estão utilizando até hoje. 1 deles não usou pois os sistemas por eles testado eram pequenos (contracheque online, folha de ponto on line, etc...) e acharam por bem não utilizar.
Elas tiveram alguma dificuldade inicial na aplicação deste diagrama?
A dificuldade inicial encontrada foi em organizar os casos de teste no que tange a relacionamentos. Antes, os casos de testes não estavam bem relacionados entre si, e com isso tiveram de 'arrumar a casa' primeiramente para depois começar a utilizar o diagrama. Assim como eu também tive de fazer o mesmo. Até porque se eu não tivesse na empresa amanhã, a organização estaria ok e o próximo Analista não teria dificuldade em entender os testes, o que testar e o que alterar em suas evoluções. Depois do 'parto' o entendimento do que testar e como testar facilitou consideravelmente. (ainda bem....rsrs)
Como elas tem feito quando tu possui um sistema com diversos módulos?
Bem, essa é exatamente a minha situação. Eu hoje trabalho em cima de um sistema onde existem vários módulos e eles se relacionam entre si. O primeiro diagrama que fiz, ficou enorme e não resolvia a vida dos testadores. A solução que encontrei foi a de dividir em sub-diagramas explicitando cada relacionamento. Aí sim, resolveu a minha vida e a deles também.
Os documentos padrão para a organização de Casos de Teste, como os
descritos na Norma IEEE 829 e até mesmo a Matriz de Rastreabilidade,
que faz a mesma coisa de uma forma mas eficaz (ao meu ver) foram
extintos ou este diagrama é mais um documento dentro do seu projeto?
Entenda: minha idéia não é revolucionar ou algo parecido o que já existe de eficaz (ou não) no universo do teste / qualidade. O que coloquei aqui foi apenas uma 'forma de organização' que encontrei sem ao menos mexer ou violar o que existe na norma 829. Certamente a Matriz de Rastreabilidade faz a mesma coisa e (a meu ver) não é tão eficaz assim em sistemas complexos pela dificuldade de manutenção. Eu particularmente, acho que para minha necessidade (como coloquei no artigo) resolve tranquilamente! Sim, como não existia processo de testes, obviamente a Matriz de Rastreabilidade não existia também e quando foram implantar acharam complicado devido à complexidade enorme do sistema. Na época, um sistema super-hiper complexo como do Detran (por exemplo) teria de ter uma Matriz de Rastreabilidade senão tudo ia por água abaixo rapidamente, então com eu estava responsável por alguns 'módulos' eu desenvolví esse diagrama (organização) e deu certo. E partindo desse princípio, resolví compartilhar algo que foi bom pra mim e que talvez poderá ser bom para outras pessoas. Não há como agradar a todo mundo.
O tempo que tu desprende para criar este documento é justificado pelo rápido aprendizado do que deverá ser testado no sistema?
Com certeza. Foi como expliquei: os primeiros poderão ser demorados para criar devido aos relacionamentos. Mas depois, [torcendo o nariz ou não devido à preferência pela Matriz de Rastreabilidade], resolve a vida dos testadores. Até hoje não tive nenhuma reclamação da documentação em si.
Abração!!!
Ricardo Franco Custodio
IBM Certified Specialist – Software Quality
IBM Certified Solution Designer - Rational Unified Process
desenvolvedor.ricardo@gmail.com
ricardo@instructor.net