Introdução ao Teste de Software - Aula 1

Introdução ao Teste de Software - Aula 1

1. Teste é a atividade desenvolvida com a finalidade de descobrir se o sistema faz o que deve fazer e não faz o que não deve fazer.

2. Teste de software é o processo de execução de um produto para determinar se ele atingiu suas especificações e funcionou corretamente no ambiente para o qual foi projetado.

3. O seu objetivo é revelar falhas em um produto, para que as causas dessas falhas sejam identificadas e possam ser corrigidas pela equipe de desenvolvimento antes da entrega final.

4. Por quê testar? Atualmente o processo de desenvolvimento de um software expõem a equipe de desenvolvimento a inúmeras situações que podem levar um software a ter pouca qualidade.

   • Conceito de teste
     • No que se refere às definições da disciplina de teste, vale ressaltar que não existe um conjunto universal de definições relativas ao teste de software. Alguns conceitos são importantes para o entendimento e possíveis adaptações dos processos, fazendo parte da base para a disciplina de teste. Nesse contexto, é imprescindível entender o conceito de erro, defeito e falha.
       • *Erro: é uma ação humana que produz um resultado incorreto. *Defeito: A manifestação de um erro no software. Também conhecido como Bug. *Falha: É um desvio apresentado pelo software, aquilo que é observado quando ele está sendo executado e apresenta um defeito.

5. Por que investir em teste?

   • A necessidade de realizar testes existe desde sempre, mas há duas grandes razões que fazem com que essa necessidade se esteja mais evidente.

6. Custo de um DEFEITO

   • O custo da correção de um defeito tende a ser cada vez maior quanto mais tarde ele for descoberto.

7. Contexto dos sistemas de Software: *Sistemas de software tornam-se cada vez mais parte do nosso dia a dia, desde de aplicações comerciais (ex. Bancos) até produtos de consumo, por exemplo: carros. *A maioria das pessoas já teve alguma experiência com um software que não funcionou como esperado. *Software que não funcionam corretamente podem levar a muitos problemas, incluindo financeiro, tempo e reputação das empresas. Podendo inclusive, chegar a influenciar na integridade das pessoas.

8. O teste é importante? Por que?

   • Rigorosos testes em sistemas e documentações podem reduzir os riscos de ocorrência de problemas no ambiente operacional, e contribuir para a qualidade dos sistemas de software se os defeitos encontrados forem corrigidos antes de implantados em produção.

9. Quanto teste é suficiente?

   • Para decidir quanto teste é suficiente, deve-se levar em consideração o nível do risco: – Risco técnico, – Risco do negócio – Risco do projeto – Restrições do projeto como tempo e orçamento.
   • O teste deve prover informações suficientes: – aos interessados – stakeholders – para a tomada de decisão sobre a distribuição do software ou sistema – para as próximas fases do desenvolvimento ou implantação nos clientes

10. Quando o teste de software deve ser iniciado?

    • O ideal é que a equipe de teste esteja envolvida desde o início do levantamento dos requisitos. Após os requisitos prontos, os analistas de teste devem avaliar para ver se tem alguma inconsistência. E assim por diante, fazendo a verificação de todas as documentações geradas.

11. Dicas para um bom teste:

    • O processo de teste deve iniciar o quanto antes com a revisão dos requisitos e dos documentos de design. Isso pode diminuir bastante o custo do projeto final, evitando bugs futuros. – Além disso, preparar os roteiros de teste antes do software estar pronto pode economizar tempo valioso no final do projeto.
      • – Garanta logo no início do projeto que os documentos de requisitos estão corretos e sem ambiguidades; – Esta garantia pode ser conseguida através da revisão dos documentos; – Desta forma, provavelmente 65% dos defeitos na fase de desenvolvimento serão evitados; – Usar algum método de revisão é bastante importante, como um simples checklist sobre o que deverá ser revisado

12. – Uma forma de saber quando deve parar de testar é quando o custo para encontrar um novo defeito é maior que o risco que aquele defeito no sistema pode causar para o usuário final. – Além disso, pode-se definir um critério de parada dos testes, por exemplo, quando 90% dos scripts de teste tiverem sido executados. – Se nenhum critério tiver sido definido, os testadores irão testar até não encontrar mais defeitos e todos os bugs tiverem sido resolvidos