Teste de Software - Introdução

Teste de Software - Introdução

1. Verificação e Validação

   • Verificação e realizada pelo desenvolvedor, e a validação é feita pelo cliente.
   • Verificação Estática e Dinâmica
     • Estática: Não requer a execução ou mesmo a existência de um software.
       • Dinâmica: Se baseia na execução de um programa ou modelo (Delamaro et al., 2007).

2. Definição: Atividade desenvolvida com a finalidade de descobrir se o sistema faz o que deve fazer e o que não deve fazer.

3. Por quê testar?: O processo de desenvolvimento de um software expõem a equipe de desenvolvimento a inúmeras situaçãoes que podem levar o software a ter pouca qualidade

4. Qualidade: Conformidade com requisitos funcionais e de desempenho.

   • Como adquirir qualidade em um software?
     • A norma ISO 9126 define as seguintes características para qualidade: Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenabilidade e Portabilidade

5. Conceito de teste (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.
     • Custo de um Defeito: O custo de correção de um defeito tende a ser cada vez maior quanto mais tarde ele for descoberto (Myres, 2004).
   • Falha: É um desvio apresentado pelo software, é observado quando ele está sendo executado e apresenta um defeito.

6. Por quê investir em teste?:

   • 1. Há cada vez mais processos de negócio que apenas fazem sentido fundamentados nas T.I.
   • 2. Os sistemas estão se tornando cada vez mais complexos.

7. Contexto dos sistemas de software

   • Sistemas de Software estão cada vez parte do nosso dia a dia. (Ex. Sistemas de Banco)
     • A maioria das pessoas já teve alguma experiência com um software que não funcionou como esperado.
       • Softwares que não funcionam corretamente podem levar a muitos problemas, incluindo financeiro, tempo e reputação das empresas.

8. Benefícios de testar

   • 1. Testes rigorosos podem reduzir os riscos de ocorrência de problemas no ambiente operacional.
     • 2. O teste pode ser necessário para atender requisitos contratuais ou legais ou determinados padrões de mercado.
       • 3. Com a ajuda do teste é possível medir a qualidade do software .
         • 4. O resultado do teste pode representar confiança na qualidade do software.
           • 5. Um teste projetado adequadamente e cuja execução não encontra defeitos reduz o nível de riscos em um sistema.
             • 6. Testes devem ser integrados como uma das atividades de garantia de qualidade.

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 conter informações suficiente:
     • Aos interessados (Stakeholders)
       • Para a tomada de decisão sobre a distribuição do software ou sistema.
         • Para as próximas fases de desenvolvimento ou implantação nos clientes.

10. Quando o teste de software deve ser iniciado?

    • 1. O ideal é que a equipe de teste esteja envolvida desde o início do levantamento dos requisitos.
      • 2. Após os requisitos prontos, os analistas de teste devem avaliar para ver se tem alguma inconsistência.
        • 3. Fazendo a verificação de todas as documentação geradas.
          • 4. Não continue a implementação de novas características se já forem encontrados erros.
            • 5. Teste em várias maquinas, compiladores e sistemas operacionais (se possível).
              • "Teste e depois codifique" (Hetzel)
                • "Teste cedo e frequentemente" (Beizer)

11. Dicas para um bom teste:

    • 1. Comece cedo e esteja preparado.
      • 2. Escolha a técnica de teste que melhor atende às suas necessidades
        • O Processo de teste deve se adaptar ao processo de desenvolvimento.
        • 3. Revise, Revise e Revise
          • Garanta logo no inicio do projeto que os documentos de requisitos, estão corretos e sem ambiguidades
            • Esta garantia pode ser conseguida através da revisão de documentos.
          • 4. Priorize
            • Às vezes não é possível testar tudo de um software, porque ele possui muitas funcionalidades.
              • Então é importante criar alguma regra de prioridade para as funcionalidades a serem testadas (Ex. Análise de Risco).
            • 5. Meça
              • Às vezes é mais importante saber qual o custo e quão eficiente é a equipe de teste ao encontrar defeitos no sistema.
              • 6. Saiba quando parar de testar
                • 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.
                • 7. Preserve
                  • Organize os roteiros de teste e guarde-os com cuidado.
                  • 8. Comunique
                    • Assegure-se que a comunicação entre os membros das equipes de desenvolvimento e teste de software é clara e objetiva.
                    • 9. Seja simples
                      • Muitos gerentes de qualidade de software não sabem qual o melhor processo de teste e técnica que deverá ser utilizada num projeto.
                        • Uma forma fácil de escolher é garantir a simplicidade do processo, sem burocracia.