O documento discute os princípios e práticas de garantia de qualidade de software, incluindo a definição de qualidade, as atividades de garantia de qualidade de software, e por que a prevenção de erros é importante. Também descreve o processo de teste de software, incluindo planejamento, análise, execução e avaliação. Finalmente, apresenta sete princípios-chave de teste de software.

1. Garantia de Qualidade(QualityAssurance)

2. O que é Qualidade? “Qualidade é o grau no qual um conjunto de características inerentes satisfaz aos requisitos” NBR ISO 9000:2005

3. Software QualityAssurance (SQA) Software QualityAssurance(SQA) compõe o conjunto de “atividades sistemáticas fornecendo evidências para o uso pretendido para o produto total de software". (LEWIS, 2004, p. 18) Esse tipo de ação é orientada a prevenção.

4. Porquê prevenção? Defeito encontrado nos requisitos: Se uma falha nos requisitos do sofware é encontrada e corrigida, sua correção é relativamente simples: atualizar a especificação de requisitos.

5. Porquê prevenção? Se o mesmo erro é encontrado fase de implantação, as correções tardias envolvem: Report de erros pelo cliente; Avaliação do erro pela equipe de desenvolvimento; Correção do erro Re-envio do pacote de desenvolvimento ao cliente; Nova validação pelo cliente; E correções em ciclos se mais erros relacionados forem encontrados.

6. Software QualityAssurance (SQA) Envolve todo o processo de desenvolvimento de software Realizando as devidas monitorações e melhorias de processos pertinentes Assegurando que os padrões, procedimentos acordados estejam sendo seguidos Garantindo que problemas sejam encontrados e ações corretivas sejam tomadas. Teste de software é umas das atividades de QualityAssurance (Garantia de Qualidade).

7. Testes de Software Ajudam a medir a qualidade do software baseando-se nos defeitos(bugs) encontrados. Reduzem o nível de risco* de um sistema como um todo *Risco: um fator que pode resultar em futuras consequências negativas; usualmente expressado como impacto e probabilidade de ocorrer. Contribuem para o cumprimento de itens contratuais ou requisitos legais acordados com o cliente Como? Encontrando e corrigindo defeitos ANTES do sistema ser implantado em ambiente operacional.

8. Processo de Testes *satifaz requisitos para entrega?

9. Planejamento e Controle Nesta etapa é especificada qual estratégia de testes será adotada: Identificar objetivos do teste Definir quais atividades e teste serão realizadas Definir quais técnicas serão aplicadas Determinar qual o critério de saída: quando as atividades de teste devem ser encerradas?

10. Análise e Design Testes são projetados utilizando-se as técnicas selecionadas. Revisar os documentos e artefatos recebidos Levantar dados para teste Projetar test-cases, definir checklists e/ou qualquer outro artefato* *Com a finalidade de descobrir e eliminar problemas antes da etapa de desenvolvimento do software

12. Os 7 Princípios-chave Os testes mostram a presença de defeitos, não sua ausência Testes exaustivos são impossíveis Teste o mais cedo quanto possível Defect Clustering The pesticide paradox Test is Context Dependent Absence of Errors Fallacy

13. 1. Os testes mostram a presença de defeitos, não sua ausência Nós testamos para encontrar falhas/defeitos Quando encontramos defeitos hoje, a probabilidades de encontrarmos defeitos futuros não descobertos no sistema diminui A probabilidade de existência de mais erros em uma seção de um programa é proporcional ao número de erros já encontrados naquele programa Um bom teste tem uma alta probabilidade de detectar erros ainda não descobertos

14. 2. Testes exaustivos não são possível É absolutamente inviável testar tudo* *Ou testar todas as combinações de entrada e saída, incluindo as pré-condições Isto exigiram um número astronômico de test cases, ou simulações Geralmente os testes são priorizados de acordo com uma abordagem baseada em riscos ou prioridades

15. 3. Os testes devem começar tão cedo quanto possível As atividades de teste devem ser iniciadas quanto mais cedo possível no ciclo de desenvolvimento As atividades devem ser focadas em objetivos definidos dentro de uma estratégia de testes

16. 4. Defeitos tendem a se agrupar Os defeitos não são distribuídos uniformemente no sistema, geralmente se encontram agrupados Em outras palavras, a maioria dos defeitos encontrados durante os testes são geralmente confinados a uma pequena parte do sistema Estes dados servem de base para a priorização dos testes: Por Criticidade

17. 5. O paradoxo do pesticida Se os mesmos testes são repetidos continuamente, eles tendem a perder sua eficácia Para evitar, novos Test Cases devem ser desenvolvidos usando novas combinações de dados e novas técnicas que capturem outros defeitos

18. 6. Testes são dependentes de contexto Testes são feitos de forma diferente em diferentes contextos Os testes devem ser aplicados baseando-se nos riscos inerentes ao uso e no ambiente da aplicação Todo software deve ter critérios de saída que devem ser decididos individualmente Exemplo: Sistemas de segurança requerem testes diferentes de sistemas de e-commerce

19. 7. O fato de falhas não existirem, não significa um sistema utilizável (usefull) Encontrar falhas e reparar não garante que os sistema como um todo garanta as expectativas do usuário e suas necessidades O envolvimento mais cedo do usuário no processo de desenvolvimento e o uso de protótipos são métodos preventivos

20. ISTQB – International Standards TestingQualityBoard www.testexpert.com.br QAI – QualityAssurance Global Institute Livro: Software Testing Foundations: A Study Guide for the Certified Tester Exam, 2nd Edition Andreas Spillner; Tilo Linz; Hans Schaefer Fonte: