Aula 8 - Plano de Teste.pptx

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? O corre 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. [email protected] 48- 991620209