O documento discute planos de teste de software, incluindo porque são importantes, o que deve ser testado, casos de uso e requisitos, métricas e estatísticas de teste.

1. Plano de Teste
Prof. Alexandre Lisbôa da Silva

2. Porque fazer um plano de Teste
Garantir a qualidade do software desenvolvido é primordial para
conseguir o sucesso de qualquer projeto. Testá-lo
adequadamente virou uma obrigação.

3. O que Testar?
Uma das primeiras perguntas que
devem ser respondidas para iniciar a
montagem de um plano de testes, é
o que testar?

4. Software está OK!
Parece óbvio e a resposta é
realmente essa: devemos testar as
funcionalidades que compõem o
escopo do software que está
sendo desenvolvido para minimizar
os erros.

5. Escopo?
Agora você pode perguntar, onde
está descrito esse escopo?
Pode estar na proposta do projeto,
na especificação funcional e, em
muitos projetos, nos casos de uso.

6. Selecione os Requisitos!
Os casos de uso descrevem requisitos, identificam o valor que o
cliente espera obter da funcionalidade, e representam a forma
como o sistema será utilizado.
Permite identificar todos os caminhos que o usuário pode percorrer
para conseguir o que deseja e se podem ocorrer problemas.
Mostram ao cliente o que esperar do software, ao desenvolvedor o
que codificar, e ao testador ou certificador o que validar para
garantir a qualidade dos entregáveis.

7. Certificação
Os casos de uso ajudam na certificação e validação dos requisitos
implementados. Simplificando e sistematizando o processo de teste
do software, permitindo um ganho de produtividade e ajudando na garantia
de que todo o escopo vai ser abrangido pelo teste.
Existem várias normas e Certificações que tratam sobre teste em software e
em sistemas:
IEEE 829 (Standard for Software and System Test Documentation);
ISO/IEC 29119 (Software Testing Standart) ;
ISTQB (International Software Testing Qualifications Board).

8. ISTQB – www.istqb.org

9. BSTQB - https://bstqb.org.br/

10. Plano de TESTE x Caso de TESTE
O Plano de Teste é um documento com uma abordagem sistemática para o teste de
sistemas como hardware ou software. Ele geralmente consiste numa modelagem detalhada
do fluxo de trabalho durante o processo.
O plano de teste é um dos oito documentos descritos na IEEE 829, uma norma que especifica a
forma e o conjunto de artefatos no teste de software. De acordo com ela, a estrutura do plano
de teste consiste de uma série de seções :
O documento começa com um identificador do documento de plano de teste, seguido do
escopo, abordagem, recursos e cronograma das atividades de teste que se destina.
Ele identifica, entre outros, itens de teste, recursos a serem testados, tarefas de teste, executor
de cada tarefa, grau de independência do testador, o ambiente de teste, as técnicas de projeto
de teste e critérios de entrada e de saída a serem usados, as razões de sua escolha, e os
eventuais riscos que exigem planos de contingência. É um registro do processo de
planejamento de teste.

11. Plano de Teste
O plano de teste é um dos documentos produzidos na condução de um
projeto. Ele funciona como:
 Um ‘integrador’ entre diversas atividades de testes no projeto;
 Mecanismo de comunicação para os stakeholders (i.e. a equipe de testes e
outros interessados);
 Guia para execução e controle das atividades de testes.

12. Responsável pelo Plano de Teste
Pode ser elaborado pelo gerente de projeto ou gerente de testes, visa planejar as
atividades a serem realizadas, definir os métodos a serem empregados, planejar a
capacidade necessária, estabelecer métricas e formas de acompanhamento do
processo. Nesse sentido, deve conter:
 Introdução com identificação do projeto (definições, abreviações, referências), definição de escopo
e objetivos;
 Conjunto de requisitos a serem testados;
 Tipos de testes a serem realizados e ferramentas utilizadas;
 Recursos utilizados nos testes;
 Cronograma de atividades (e definição de marcos de projeto).
https://www.devmedia.com.br/plano-de-teste-um-mapa-essencial-para-teste-de-software/13824

13. Plano de Teste deve definir
1. Os itens a serem testados: o escopo e objetivos do plano devem ser
estabelecidos no início do projeto.
2. Atividades e recursos a serem empregados: as estratégias de testes e recursos
utilizados devem ser definidos, bem como toda e qualquer restrição imposta
sobre as atividades e/ou recursos.
3. Os tipos de testes a serem realizados e ferramentas empregadas: os tipos de
testes e a ordem cronológica de sua ocorrência são estabelecidos no plano.
4. Critérios para avaliar os resultados obtidos: métricas devem ser definidas para
acompanhar os resultados alcançados.
https://www.devmedia.com.br/plano-de-teste-um-mapa-essencial-para-teste-de-software/13824

14. Plano de TESTE x Caso de TESTE
Caso de Teste é um conjunto de condições usadas para teste de software.
Ele pode ser elaborado para identificar defeitos na estrutura interna do software,
através de situações que exercitem adequadamente todas as estruturas utilizadas na
codificação; ou ainda, garantir que os requisitos do software que foi construído sejam
plenamente atendidos. Podemos utilizar a ferramenta de casos de uso para criar e
rastrear um caso de teste, facilitando assim identificação de possíveis falhas.
No caso de teste deve conter precondições de execução, ações e valores de entrada,
resultados esperados e pós-condições de execução desenvolvidas para um
determinado objetivo ou condição de teste, tais como para exercitar o caminho de um
determinado programa ou verificar o atendimento a um requisito especifico.

15. MODELO
https://www.alvarofpinheiro.eti.br/

16. TestLink
https://sourceforge.net/projects/testlink/

17. TestLink – Criação de Projetos

18. Testlink - Criando plano de Teste

19. Reporte de Incidentes
(bugs)
Descreve os bugs encontrados juntamente com os passos para reproduzir.
Nele devem constar o escopo (o que realmente deveria ter ocorrido), e impacto
que o mesmo causa.
QUANDO ELE OCORRE?
Ocorre quando uma ou mais das opções abaixo for verdadeira:
• O software NÃO faz algo que a especificação diz que ele deveria fazer;
• O software FAZ algo que a especificação diz que ele NÃO deveria fazer;
• O software faz algo que a especificação não menciona;
• O software NÃO faz algo que a especificação NÃO menciona, mas deveria mencionar;
• O software é difícil de usar, entender, ou na visão do testador pode ser visto pelo usuário final como não
estando correto.
“O objetivo do Teste de Software é encontrar bugs,
encontrá-los o mais cedo possível e garantir que os
bugs sejam corrigidos”
(Patton, 2005)

20. Um pouco de História!

21. Métricas de Software
Avaliar a qualidade de um software é um mistério. Muitos profissionais
de TI ficam frustrados sobre como definir e medir a qualidade das
aplicações.
Não surpreendentemente, essas dificuldades resultam de um foco
incorreto sobre o processo pelo qual o software é construído. Achamos
que podemos definir essas atividades e medi-los com precisão para
que as pessoas possam ver e focar nas atividades necessárias para criar,
melhorar e gerenciar o software.
Para isso definimos as Métricas para qualidade de Software.

22. 5 pontos básicos de medição:
1. Alcance: deve ser capaz de lidar com várias tecnologias. A maioria dos
aplicativos modernos contém vários idiomas e sistemas que são ligados entre si de
forma complexa.
2. Profundidade: deve ser capaz de gerar mapas completos e detalhados da
arquitetura do aplicativo do Graphical User Interface (GUI), ferramenta de captura,
processamento e análise de imagem, para o banco de dados. Sem essa detalhada
arquitetura, seria impossível obter contextualização da aplicação.
3. Tornar o conhecimento explícito de engenharia de software: deve ser capaz de
verificar a aplicação inteira contra centenas de padrões de implementação que
codificam as melhores práticas de engenharia.

23. 5 pontos básicos de medição:
4. Métricas acionáveis: as métricas de qualidade não devem apenas
informar, mas também orientar sobre como realizar a melhoria da
qualidade do software, mostrando o que fazer primeiro, como fazê-
lo, próximos passos etc.
5. Automatização: finalmente, deve ser capaz de realizar todos os
pontos descritos acima de forma automatizada. Nenhum
profissional ou equipe pode fazer essa tarefa, muito menos fazê-la
em um curto espaço de tempo.

24. Estatísticas de Teste
Para verificar a qualidade dos casos de teste criados existem técnicas de
análise estatística, análise de mutação, análise estática, análise de fluxo
e análise dinâmica.
A técnica de análise estatística utiliza a métrica de cobertura dos testes,
que determinam o percentual de abrangência dos casos de teste ao
executar o programa no momento do teste.
Na técnica de mutação são gerados programas mutantes, onde neles
são introduzidos diferentes defeitos, com a intenção de verificar se os
casos de teste executados conseguem detectar tais falhas previamente
conhecidas.
Saiba mais Teste de Software

25. Quais partes compõem um produto de
software?
É importante salientar a percepção do momento que o produto está pronto a
ser entregue, frisando que não é apenas um código que será entregue,
inúmeras partes de apoio irão juntas. Uma vez que todas estas partes são vistas
ou utilizadas pelo cliente, elas necessitam ser testadas também:
 Arquivos de Ajuda;
 Manual do Usuário;
 Amostras e Exemplos;
 Informações de suporte ao produto;
 Mensagens de erro;
 Configuração e instalação;
 Ícones e arte;
 Arquivo de Readme (Leia-me);

26. Bom estudo!
Acesse os Hiperlinks espalhados pelo conteúdo
 Detalhes de contato
Prof. Alexandre.lisboa@fmpsc.edu.br
48- 991620209