1. 4 Técnicas de teste
1.1. 4.1 Categorias de Técnicas de teste
1.1.1. 4.1.1 Escolhendo técnicas de teste
1.1.2. 4.1.2 Categorias de tecnicas de teste caracteristicas
1.2. 4.2 Técnicas de teste caixa-preta
1.2.1. 4.2.1 Particionamento de equivalencia
1.2.2. 4.2.2 Análise de valor limite
1.2.3. 4.2.3 Teste de tabela de decisão
1.2.4. 4.2.4 Teste de Transição de estado
1.2.5. 4.2.5 Teste de caso de uso
1.3. 4.3 Tecnica de teste de caixa branca
1.3.1. 4.3.1 teste de cobertura de instruções
1.3.2. 4.3.2 Teste de decisão e cobertura
1.3.3. 4.3.3 O valor da instrução e teste de decisão
1.4. 4.4 Técnicas de teste baseadas na experiência
1.4.1. 4.4.1 Suposição de erro
1.4.2. 4.4.2 Teste exploratório
1.4.3. 4.4.3 teste baseado em lista de verificação
2. 5 Gerenciamento de teste
2.1. 5.1 Organização de teste
2.1.1. 5.1.1 testes independentes
2.1.2. 5.1.2 Tarefas de um gerente de teste e um testador
2.2. 5.2 Planejamento e estimativa de testes
2.2.1. 5.2.1 Objetivo e conteudo de um plano de teste
2.2.2. 5.2.2 Estrategia e abordagem de teste
2.2.3. 5.2.3 Criterios de entrada e saida
2.2.4. 5.2.4 Cronograma e execução de testes
2.2.5. 5.2.5 Fatores que influenciamo esforço de teste
2.2.6. 5.2.6 tecnicas de estimativa de teste
2.3. 5.3 Monitoramento e controle de testes
2.3.1. 5.3.1 Metricas usadas no teste
2.3.2. 5.3.2 Finalidades, conteudo e publico alvo para relatórios de testes
2.4. 5.4 Gerenciamento de configurações
2.5. 5.5 Riscos e testes
2.5.1. 5.5.1 Definição de risco
2.5.2. 5.5.2 Riscso de produtos e projetos
2.5.3. 5.5.3 teste basedado risco e qualidade do produto
2.6. 5.6 Gerenciamento de defeitos
3. 6 Ferramenta de suporte ao teste
3.1. 6.1 Considerações sobre a ferramenta de teste
3.1.1. 6.1.1 Classificação das ferramentas de teste
3.1.2. 6.1.2 Beneficios e riscos da automação de testes
3.1.3. 6.1.3 Considerações especiais para execução e ferramentas de testes
3.2. 6.2 Uso eficaz de ferramentas
3.2.1. 6.2.1 Considerações para escolha das ferramentas
3.2.2. 6.2.2 Projeto piloto para introduzir uma ferramenta na Organização
3.2.3. 6.2.3 Fatores de sucesso para ferramentas
4. 1 Fundamentos de teste
4.1. 1.1 O que é teste
4.1.1. 1.1.1 Objetivos tipicos do teste
4.1.1.1. - Alguns objetivos de teste:
4.1.1.1.1. **Encontrar defeitos**: testamos para encontrar algo que não está funcionando corretamente.
4.1.1.1.2. **Evitar defeitos**: incluir praticas dentro do processo de desenvolvimento para evitar possiveis defeitos. Ter funcionalidades bem descritas e sem ambiguidades para o desenvolvedor ou QA, de maneira que não sobre espaços para interpretação de cada persona.
4.1.1.1.3. **Criar confiança sobre o nível de qualidade**: fazer o máximo de validações possível para cobrir a maior parte do sistema e assim criar confiança sobre a qualidade que temos no nosso software.
4.1.1.1.4. **Fornecer informações para tomada de decisão**: devemos poder fornecer informações sobre a confiabilidade do software, e evitar possiveis lançamentos de funcionalidades fora do momento. Essas informações podem ser métricas de quantos casos de teste falharam e se é pertinente fazer uma entrega de tal funcionalidade ou analisar melhor.
4.1.1.1.5. **Avaliar produtos de trabalho**: esse produtos são os artefatos gerados pelo desenvolvimento, sendo alguns deles especificação, requisitos, código, história de usuário, plano de teste, caso de teste e etc.
4.1.1.1.6. **Garantir cobertura necessários do objeto de teste**: precisamos garantir uma boa cobertura de testes nas funcionalidades mapeadas.
4.1.1.1.7. **Reduzir nível de risco**: fazer testes que cubram as funcionalidades para reduzir o risco de falhas quando entregue ao cliente final.
4.1.1.1.8. **Verificar conformidade com requisito**: montar testes para verificar se a funcionalidade desenvolvida atende aos requisitos pré definidos.
4.1.1.2. - Os objetivos podem variar dependendo do contexto do produto.
4.1.1.3. - Durante o teste um dos objetivos é encontrar a maior quantidade de falhas.
4.1.1.4. - Durante os testes de aceite deve ser validado se tudo está de acordo com o que foi pedido.
4.1.2. 1.1.2 Teste de depuração de código
4.1.2.1. - Teste = mostra as falhas e defeitos no software.
4.1.2.2. - Depuração de código = localiza, analisa e corrige os defeitos no código.
4.1.2.3. - Testes de confirmação validam se os defeitos foram corrigidos.
4.1.2.4. - Testadores fazem teste inicial e de confirmação, e os devs fazem depuração.
4.1.2.5. - No desenvolvimento ágil os testers podem estar envolvidos na depuração.
4.1.3. O que é teste?
4.1.3.1. - Planejamento
4.1.3.2. - Análise
4.1.3.3. - Modelagem
4.1.3.4. - Implementação
4.1.3.5. - Execução
4.1.3.6. - Relatórios (progresso e resultados)
4.1.4. O que não é teste
4.1.4.1. Apenas executar o software e verificar resultados.
4.1.4.2. Apenas verificar requisitos (se os sistema atende aos requisitos especificados).
4.2. 1.2 Por que o teste é necessário
4.2.1. 1.2.1 Contribuições do teste para sucesso
4.2.1.1. Teste contribuem para sistemas de maior qualidade pois detectam defeitos e esses podem ser removidos.
4.2.1.2. O teste avalia a qualidade de um sistema em diversos momentos do SDLC (ciclo de desenvolvimento de software), ajudando em decisões.
4.2.1.3. Os testes também podem ser necessários para atender a requisitos contratuais ou legais, ou normas regulatórias.
4.2.1.4. Testadores precisam entender as necessidade dos usuários e considerar isso dentro do ciclo de vida de desenvolvimento.
4.2.2. 1.2.2 Garantia de qualidade e teste
4.2.2.1. Teste e QA não são a mesma coisa. O teste é a forma de controle de qualidade (QC).
4.2.2.2. QC (quality control) é uma abordagem corretiva e orientada para o produto que se concentra nas atividades que apoiam a obtenção de níveis adequados de qualidade. O QC é feito para validar o produto.
4.2.2.3. Já o QA (quality assurance) é uma abordagem preventiva e orientada para o processo, se concetra na implementação e aprimoramento dos processos (se um bom processo for seguido corretamente, ele gerará um bom produto).
4.2.2.4. O QA é um processo que vai trazer mais qualidade, ele está diretamente ligada ao desenvolvimento com qualidade, então se eu implementar alguma etapa dentro do processo que vai trazer mais qualidade é QA.
4.2.2.5. Por exemplo se eu implementar uma ferramenta de validação de código como o Sonar que vai avaliar se o código está seguindo as boas práticas, então eu fiz uma implementação de QA. Ou se acrescento boas práticas de acessibilidade, coisas que se tornem processo da empresa, então tudo isso está sendo elaborado para melhoria de qualidade dos processos do meu projeto ou empresa.
4.2.2.6. O Quality Assurance é uma responsabilidade de todos em um projeto, o QA está ali para guiar pelo caminho da qualidade, enquanto os demais são responsaveis por acrescentar no seu dia a dia esses processo para a melhoria da qualidade.
4.2.2.7. Os resultados dos testes são usado por QA e QC.
4.2.2.8. No QC eles são usado para corrigir defeitos, já no QA eles fornecem feedback sobre a performace dos processos de desenvolvimento e teste. Ou seja são necessários esses feedbacks para entender onde a qualidade está sendo falha e precisa de melhorias.
4.2.3. 1.2.3 Erros, defeitos e falhas
4.2.3.1. - Erro
4.2.3.1.1. - O ser humano está sujeito a cometer um erro (engano).
4.2.3.1.2. - Esse problema ocorre no processo de desenvolvimento em sua maioria, por exemplo se ocorrer um entendimento errado da funcionalidade e ela for desenvolvida de maneira errônea pode gerar um defeito no código.
4.2.3.2. - Defeito
4.2.3.2.1. - Que produz um defeito (bug) no código ou documento.
4.2.3.2.2. - Quando é feito um desenvolvimento errôneo seguindo nosso exemplo e esse erro acaba sendo inserido no código, então é produzido um defeito no código (ainda seguindo o nosso exemplo). Que irá ocasionar uma falha.
4.2.3.3. - Falha
4.2.3.3.1. - Se um defeito é executado, o sistema falha.
4.2.3.3.2. - De acordo com nosso exemplo foi adicionado um defeito no código e isso ocasionou em uma falha quando foi para validação a demanda.
4.2.3.3.3. - Está só existe quando o defeito é executado.
4.2.3.4. **Erro** (entendimento errôneo sobre a funcionalidade) → **Defeito** (gerado por um desenvolvimento errado) → **Falha** (quando o defeito é executado então o sistema falha.)
4.2.3.5. O que causa?
4.2.3.5.1. - Pressão no prazo.
4.2.3.5.2. - Falta de conhecimento dos produtos, processos, ferramentas utilizadas e etc.
4.2.3.5.3. - Códigos complexos ou depreciados.
4.2.3.5.4. - Mudanças na tecnologia, sendo mudanças total para uma nova tecnologia ou atualizações em tecnologias já utilizadas.
4.2.3.5.5. - Infraestrutura complexa.
4.2.3.5.6. - Fatores emocionais.
4.2.3.6. Alguns defeitos sempre resultarão em falha se forem executados, enquanto outros só resultarão em falhas em circunstâncias específicas, e alguns podem nunca resultar em falha.
4.2.3.7. As falhas também podem ser causadas por condições ambientais (clima, campo eletromagnético, etc)
4.2.3.8. Já a causa raiz é o motivo fundamental para a ocorrência de um problema. São identificadas por meio da análise de causa raiz, realizada quando ocorre uma falha ou quando um defeito é identificado.
4.2.3.9. Quando analisamos e remediamos a causa raiz, é provável que outras falhas ou defeitos semelhantes sejam evitados futuramente.
4.3. 1.3 Sete principios de testes
4.3.1. 1. O teste mostra a presença, não a ausência de defeitos
4.3.1.1. 1. O teste pode mostrar presença de defeitos, mas não pode provar que eles não existem.
4.3.2. 2. Teste exaustivos são impossíveis
4.3.2.1. 1. Testar tudo não é viável.
4.3.3. 3. Testes antecipados economizam tempo e dinheiro
4.3.3.1. 1. A atividade de teste deve começar o mais breve possível no ciclo de desenvolvimento.
4.3.3.2. 2. Quando temos um bom conhecimento do sistema, sabemos onde buscar os defeitos a priori pois alguns componentes tendem a ser os mais defeituosos.
4.3.4. 4. Defeitos se agrupam
4.3.4.1. 1. Um número pequeno de funções contém a maioria dos defeitos.
4.3.5. 5. Os testes se degradam
4.3.5.1. 1. Pode ocorrer de um mesmo conjunto de teste que são repetidos várias vezes não encontrarem novos defeitos após um determinado momento. Os casos de teste necessitam ser frequentemente revisados e atualizados.
4.3.6. 6. Os testes dependem do contexto.
4.3.6.1. 1. Testes são realizados conforme o contexto.
4.3.7. 7. Falácia da ausência de defeitos
4.3.7.1. 1. Encontrar e consertar defeitos não ajuda se o sistema construído não atende às expectativas dos usuários.
4.3.7.2. 2. Não basta apenas termos um sistema que funcionam super bem se ele não está dentro do que o usuário necessita.
4.4. 1.4 Atividades de teste, Testware e Papéis no teste
4.4.1. 1.4.1 Atividades e Tarefas de Teste
4.4.1.1. Um processo de teste possui as seguintes principais atividades:
4.4.1.1.1. - Planejamento do Teste
4.4.1.1.2. - Análise do Teste
4.4.1.1.3. - Modelagem do Teste
4.4.1.1.4. - Implementação do Teste
4.4.1.1.5. - Execução do Teste
4.4.1.1.6. - Conclusão do Teste
4.4.1.2. Temos também monitoramento e controle do teste que não entrou na nossa sequência pois é uma atividade de teste que está presente durante TODO o processo de qualidade. **Todas essas atividade podem ocorrer em paralelo.** Monitoramento: Verificação contínua de todas as atividades de teste e comparação do progresso real com o o plano de teste. Controle: Tomada de ações necessárias para atender aos objetivos do teste. O progresso dessas atividades é comunicado aos stackholders por meio de relatórios. Decorar essa atividade é importante para a prova
4.4.2. 1.4.2 Processo de Teste no Contexto
4.4.2.1. As atividades de teste são parte integrante dos processos de desenvolvimento. Os testes são financiados pelos stackholders e seu objetivo final é ajudar a atender às necessidades de negócios deles. As atividades de teste precisam ser pensadas para atender as expectativas dos stackholders em relação ao produto.
4.4.2.2. Fatores do contexto que influenciam o teste
4.4.2.2.1. - Stackholders (necessidades, expectativas, requisitos, disposição para cooperar e etc).
4.4.2.2.2. - Membros da equipe (habilidades, conhecimento, nível de experiência, disponibilidade, necessidades de trainamento e etc).
4.4.2.2.3. - Domínio do negócio (criticidade do objeto de teste, riscos identificados, necessidades do mercado, normas legais específicas e etc).
4.4.2.2.4. - Fatores técnicos (tipo de software, arquitetura do produto, tecnologia usada e etc).
4.4.2.2.5. - Restrições do projeto (escopo, tempo, orçamento, recursos e etc).
4.4.2.2.6. - Fatores organizacionais (estrutura organizacional, políticas existentes, práticas utilizadas e etc).
4.4.2.2.7. - Ciclo de vida do desenvolvimento de software (práticas de engenharia, métodos de desenvolvimento e etc).
4.4.2.2.8. - Ferramentas (disponibilidade, usabilidade, conformidade e etc).
4.4.2.3. Todos esses fatores impactarão
4.4.2.3.1. - Estratégia de teste.
4.4.2.3.2. - Técnicas de teste usadas.
4.4.2.3.3. - Grau de automação de teste.
4.4.2.3.4. - Nível de cobertura necessária.
4.4.2.3.5. - Nível de detalhe da documentação de teste.
4.4.2.3.6. - Relatórios.
4.4.2.3.7. - Entre vários outros fatores que são impactados de acordo com o contexto.
4.4.3. 1.4.3 Testware
4.4.3.1. Testware são produtos de trabalho de saída de cada atividade de teste. Cada organização produz, molda, nomeia, organiza e gerencia seus produtos de trabalho de uma diferente. A gestão de configuração (ref 5.4) garante a consistência e a integridade dos produtos de trabalho.
4.4.3.2. Planejamento do teste
4.4.3.2.1. - Planos de Teste
4.4.3.2.2. - Cronograma de testes
4.4.3.2.3. - Registro de riscos
4.4.3.2.4. - Critérios de entrada e saída
4.4.3.3. Monitoramento e Controle
4.4.3.3.1. - Relatórios de progresso de testes
4.4.3.3.2. - Documentações de diretrizes de controle
4.4.3.3.3. - Informações sobre riscos
4.4.3.4. Análise
4.4.3.4.1. - Condições de Teste definidas e priorizadas
4.4.3.4.2. - Relatórios de Defeitos não corrigidos diretamente
4.4.3.5. Modelagem
4.4.3.5.1. - Casos de Teste
4.4.3.5.2. - Carta de Teste (utilizadas em testes exploratório, usamos a carta pois não tem casos de teste para guiar)
4.4.3.5.3. - Dados de Teste, cobertura e ambientes
4.4.3.6. Implementação
4.4.3.6.1. - Procedimentos de Teste (Passo a passo / Detalhamento)
4.4.3.6.2. - Scripts de Teste automatizados
4.4.3.6.3. - Conjuntos de Teste / Dados de Teste
4.4.3.6.4. - Cronograma de Execução
4.4.3.6.5. - Elementos do Ambiente de Teste (drivers, stubs, virtualização)
4.4.3.7. Execução
4.4.3.7.1. - Registros de Teste
4.4.3.7.2. - Relatório de Defeitos
4.4.3.8. Conclusão
4.4.3.8.1. - Relatórios de Teste
4.4.3.8.2. - Itens de ação / lições aprendidas documentadas para melhoria dos próximos projetos
4.4.4. 1.4.4 Rastreabilidade entre a base de teste e o testware
4.4.4.1. - Esses produtos tem bastante variação, porém temos alguns nomes que aparecem bastante:
4.4.4.1.1. - Analisar impacto das mudanças;
4.4.4.1.2. - Tornar teste auditavel;
4.4.4.1.3. - Melhorar compreensibilidade dos relatórios/progresso/resumo;
4.4.4.1.4. - Fornecer informações para avaliar a qualidade.
4.4.4.1.5. - Ferramentas de gerenciamento fornecem modelos de produtos de trabalho.
4.4.4.2. Rastreabilidade é o que consigo rastrear dentre os artefatos do meu projeto, o caso de teste foi gerado com base em alguma documentação ou especificação, sendo que na especificação eu posso ter dados linkados me levando até os casos de teste por exemplo. A rastreabilidade é conseguir a partir de uma informação localizar a origem dela.
4.4.4.2.1. Base de Teste ↔ Testware ↔ Resultados dos testes ↔ Defeitos
4.4.4.3. A rastreabilidade precisa dar suporte à avaliação da cobertura, que é um indicador muito importante.
4.4.4.3.1. - A rastreabilidade dos casos de teste aos requisitos pode verificar se os requisitos são cobertos pelos casos de teste. As vezes podemos ter casos de teste que não serão uteis, ou esteja faltando cobrir algum caminho com os casos de teste e tendo a rastreabilidade é possível ter esse controle.
4.4.4.3.2. - A rastreabilidade dos resultados dos testes aos riscos pode ser usada para avaliar o nível de risco residual em um objeto de teste.
4.4.4.3.3. - Uma boa rastreabilidade permite determinar o impacto das mudanças, facilita as auditorias de teste e ajuda a atender os critérios de governança de TI. Em casos de uma empresa que segue alguma norma ou é auditada por outra empresa, é possível por meio da rastreabilidade fornecer esse tipo de dado.
4.4.4.3.4. - Um ponto interessante é que a auditoria de teste também usufrui dessa rastreabilidade, podemos atentar a frequência que aquele caso de teste revela algum defeito ou dentre os defeitos críticos quais casos de teste costumam revela esses defeitos críticos.
4.4.4.3.5. - A boa rastreabilidade também torna o progresso de teste e os relatórios de conclusão mais compreensíveis.
4.4.4.3.6. - A rastreabilidade fornece informações para avaliar a qualidade do produto, a capacidade do processo e o progresso do projeto em relação aos objetivos de negócio.
4.4.4.3.7. - Podemos linkar todo tipo de dado para uma boa rastreabilidade, por exemplo requisitos, casos de teste, relatório, defeitos mapeados e etc.
4.4.5. 1.4.5 Papéis no Teste
4.4.5.1. Gerenciamento de Teste
4.4.5.1.1. - Responsabilidade geral pelo processo de teste, pela equipe de teste e pela liderança das atividades de teste.
4.4.5.1.2. - Atividades de planejamento, monitoramento e controle, e conclusão de testes.
4.4.5.1.3. - Papel de gerenciamento de testes varia de acordo com o contexto.
4.4.5.1.4. - No desenvolvimento ágil, algumas das tarefas de gerenciamento de testes podem ser realizadas pela equipe ágil, e as tarefas que abrangem várias equipes ou toda a organização podem ser executadas por gerentes de teste fora da equipe de desenvolvimento.
4.4.5.2. Testador
4.4.5.2.1. - Responsabilidade geral pelo aspecto de engenharia (técnico) do teste.
4.4.5.2.2. - Atividades de análise, modelagem. implementação e execução de teste.
4.4.5.2.3. - Executar os testes, avaliar os resultados e documentar os desvios dos resultados esperados.
4.4.5.2.4. - Automatizar os testes conforme necessário.
4.4.5.2.5. - Avaliar as características não funcionais, como efeciência de desempenho, confiabilidade, usabilidade, segurança, compatibilidade e portabilidade.
4.4.5.2.6. - Dependendo dos riscos relacionados ao produto e ao projeto, e o modelo de ciclo de vida selecionado, pessoas diferentes podem assumir o papel de testador em diferentes níveis de teste. De acordo com suas habilidades e visão do produto.
4.4.5.3. Pessoas diferentes podem assumir esses papéis em momentos diferentes. Por exemplo, o papel de gerenciamento de testes pode ser desempenhada por um Líder de Equipe, por um Gerente de Testes, por um Gerente de Desenvolvimento etc. Também é possível que uma pessoa assumo o papel de testador e gerenciamento de teste ao mesmo tempo.
4.4.6. Não existe um processo de testes universal, cada funcionalidade tem sua necessidade e maneira a ser testada.
4.4.7. Conjunto de atividades para maior probabilidade de atingir os objetivos.
4.4.8. Existem muitos fatores que englobam o processo de um teste, o processo ideal depende de muitos fatores e deve ser adaptado a uma determinada situação com base nesses fatores.
4.4.9. Processo de teste depende do contexto, é esse contexto que determina os fatores do processo a ser seguido.
4.5. 1.5 Habilidades Essenciais e Boas Práticas em Testes
4.5.1. 1.5.1 Dar Exemplos das Habilidades Genéricas Necessárias para Testar
4.5.1.1. Habilidades relevantes para os Testadores
4.5.1.1.1. - Conhecimento sobre testes.
4.5.1.1.2. - Meticulosidade, cuidado, curiosidade, atenção aos detalhes e ser metódico
4.5.1.1.3. - Boas habilidades de comunicação, ser um bom ouvinte, e trabalhar em equipe
4.5.1.1.4. - Pensamento analítico, pensamento crítico, criatividade para identificar possíveis caminhos e fluxos de erro que estão por vir.
4.5.1.1.5. - Conhecimento técnico é importante para automação e também testes efetivos.
4.5.1.1.6. - Conhecimento do domínio, ou seja conhecimento das regras de negócio para executar testes melhores.
4.5.1.2. Os testadores geralmente são os portadores de más notícias. É uma característica humana culpar o portador pelas más notícias. Isso torna as habilidades de comunicação cruciais para os testadores, saber reportar bem os problemas. O viés de confirmação pode dificultar o aceite de informações que discordem das crenças atuais, ou seja, negar que aquele bug é de fato um bug, os desenvolvedores costumam procurar o problema na forma como foi testado e se recusam a acreditar que o problema está no seu desenvolvimento. O teste pode ser considerado uma atividade destrutiva, trazendo uma crítica contra o produto e o autor, os defeitos devem ser comunicados de forma construtiva.
4.5.2. 1.5.2 Relembrar as Vantagens da Abordagem de Equipe Completa
4.5.2.1. - É uma prática do XP (Extreme Programming)
4.5.2.2. - Qualquer membro da equipe com o conhecimento e as habilidades necessárias pode executar qualquer tarefa.
4.5.2.3. - Todos são responsáveis pela qualidade, todos tem testes para fazer e garantir a qualidade final do produto.
4.5.2.4. - Membros da equipe compartilham o mesmo espaço de trabalho (físico ou virtual).
4.5.2.5. - Essa abordagem melhora a dinâmica e comunicação entre a equipe.
4.5.2.6. - Testadores trabalham em estreita colaboração com outros membros da equipe para garantir que os níveis de qualidade sejam alcançados.
4.5.2.7. - Isso inclui colaborar com representantes do negócio para ajudá-los a criar testes de aceite adequados e trabalhar com desenvolvedores para ajudar na estratégia de testes e decidir sobre abordagens de automação de testes.
4.5.2.8. - Assim, os testadores podem transferir o conhecimento sobre testes para outros membros da equipe e influenciar o desenvolvimento do produto.
4.5.2.9. - Dependendo do contexto, a abordagem de equipe completa nem sempre pode ser adequada. Por exemplo, em algumas situações, como em sistemas críticos, pode ser necessário um alto nível de independência dos testes. Quando um sistema é muito critico existe a necessidade da equipe apartada para uma imparcialidade maior nos testes.
4.5.3. 1.5.3 Distinguir os Benefícios e as Desvantagens de Independência dos Testes
4.5.3.1. - São testes realizados por alguém que não seja o autor do código. (Se eu desenvolvi, outra pessoa tem que testar.) Quando eu desenvolvo e eu mesmo faço os testes, o problema do viés de confirmação entra em ação e eu tenho convicção que fiz tudo certo, logo acabo testando de forma mais simples e rápida.
4.5.3.2. - Existem diferentes níveis de independência. Quanto mais distante a área de qualidade da área de desenvolvimento maior a independência.
4.5.3.2.1. - Sem independência:
4.5.3.2.2. - Alguma independência:
4.5.3.2.3. - Alta independência:
4.5.3.2.4. - Independência muito alta:
4.5.3.3. Aqui temos algumas vantagens da independência de testes
4.5.3.3.1. - Encontrar diferentes tipos de falhas em comparação a os desenvolvedores.
4.5.3.3.2. - São mais imparciais, pois não possuem premissas de ideias sobre o que testar e não possuem preconceitos ou apego emocional com o software.
4.5.3.3.3. - Um testador independente pode verificar, desafiar ou refutar as suposições feitas pelos stakeholders durante a especificação e a implementação do sistema.
4.5.3.4. Aqui temos algumas desvantagens da independência de testes
4.5.3.4.1. - Isolamento da equipe de desenvolvimento, levando a uma falta de colaboração, atrasos no fornecimento de feedback ou um relacionamento adverso.
4.5.3.4.2. - Os desenvolvedores podem perder o senso de responsabilidade pela qualidade.
4.5.3.4.3. - Testadores independentes podem ser vistos como gargalo ou culpados por atrasos na liberação. Principalmente em casos de cascata quando as demandas a serem testadas precisam chegar em conjunto para a atividade do teste seja iniciada.
4.5.3.4.4. - Testadores independentes podem não ter algumas informações importantes (p. ex. sobre o objeto de testes).
4.6. Palavras-chave do capítulo
4.6.1. cobertura, depuração, defeito, erro, falha, qualidade, garantia de qualidade, causa raiz, análise de teste, base de teste, caso de teste, conclusão do teste, condição de teste, controle de teste, dados de teste, projeto de teste, execução de teste, implementação de teste, monitoramento de teste, objeto de teste, objetivo de teste, planejamento de teste, procedimento de teste, resultado de teste, teste, testware, validação, verificação
5. 2 Ciclo de vida de desenvolvimento
5.1. 2.1 Modelos de ciclo de vida
5.1.1. 2.1.1 Impacto do Ciclo de Vida de Desenvolvimento de Software nos Testes
5.1.1.1. O teste deve ser adaptado ao SDLC. A escolha do SDLC tem impacto sobre
5.1.1.1.1. - O escopo e cronograma das atividades de teste;
5.1.1.1.2. - O nível de detalhamento da documentação de teste;
5.1.1.1.3. - A escolha das técnicas de teste e da abordagem de teste;
5.1.1.1.4. - A extensão da automação de testes;
5.1.1.1.5. - O papel e responsabilidade de um Testador;
5.1.1.2. Modelos sequenciais
5.1.1.2.1. - Testadores normalmente participam das revisões de requisitos, da análise de testes e do projeto de testes.
5.1.1.2.2. - Como código é criado em fases posteriores à criação dos requisitos, testes dinâmicos não podem ser executados no início do SDLC.
5.1.1.3. Modelo cascata
5.1.1.3.1. Análise → Design → Desenvolvimento → Testes → Entrega → Manutenção
5.1.1.3.2. Em modelo de cascata podemos fazer testes estáticos (revisão em sua maioria), ler as definições ou documentos que serão destinados ao desenvolvimento e procurar por inconsistências ou alguma ambiguidade que abra margem para um desenvolvimento errôneo.
5.1.1.4. Modelos iterativos e incrementais
5.1.1.4.1. - Em cada iteração, os testes estáticos e dinâmicos podem ser realizados em todos os níveis de teste.
5.1.1.4.2. - Feedback rápido e testes de regressão extensivos são necessários devido à entrega frequente de incrementos.
5.1.1.4.3. Identificar Objetivos → Analise de risco e performance → Desenvolvimento e teste → Revisão e avaliação
5.1.1.5. Desenvolvimento Ágil
5.1.1.5.1. - Mudanças podem ocorrer ao longo do projeto.
5.1.1.5.2. - Documentação leve para não impactar os testes, escrever casos de teste super detalhados pode cair em desuso por conta de alguma mudança de escopo.
5.1.1.5.3. - Ampla automação de testes para facilitar os testes de regressão.
5.1.1.5.4. - A maior parte dos testes manuais tende a ser feita usando técnicas de teste baseadas na experiência (que não exigem análise e projeto de teste prévio extensivo).
5.1.2. 2.1.2 Ciclos de vida de desenvolvimento de software e boas práticas de teste
5.1.2.1. Boas práticas de teste, independente do modelo de SDLC
5.1.2.1.1. - Diferentes níveis de teste têm objetivos de teste específicos e diferentes, evitando redundância.
5.1.2.1.2. - Para cada atividade de desenvolvimento, há uma atividade de teste correspondente.
5.1.2.1.3. - Diferentes níveis de teste têm objetivos de teste específicos e diferentes, evitando redundância.
5.1.2.1.4. - A análise e a modelagem do teste começam durante a fase de desenvolvimento correspondente do SDLC, princípio do teste antecipado.
5.1.2.1.5. - Os testadores estão envolvidos na revisão dos produtos de trabalho assim que os rascunhos dessa documentação estiverem disponíveis, de modo que esse teste antecipado e a detecção de defeitos possam apoiar a estratégia shift-left.
5.1.3. 2.1.3 Teste Como um Motivador para o Desenvolvimento de Software
5.1.3.1. O TDD, ATDD e BDD são abordagens de desenvolvimento semelhantes, em que os testes são definidos como um meio de direcionar o desenvolvimento.
5.1.3.2. Cada uma dessas abordagens implementa o princípio do teste antecipado e segue uma abordagem shift-left, pois os testes são definidos antes de o código ser escrito.
5.1.3.3. Elas dão suporte a um modelo de desenvolvimento iterativo.
5.1.3.4. Desenvolvimento Orientado por Testes (TDD - Test Driven Development)
5.1.3.4.1. - Direciona a codificação por meio de casos de teste.
5.1.3.4.2. - Os testes são escritos primeiro, depois o código é escrito para satisfazer os testes e, em seguida, os testes e o código são refatorados.
5.1.3.5. Desenvolvimento Orientado por Teste de Aceite (ATDD - Acceptance Test Driven Development)
5.1.3.5.1. - Deriva testes de critérios de aceite como parte do processo de desenho do sistema.
5.1.3.5.2. - Os testes são escritos antes que a parte do aplicativo relacionada seja desenvolvida para atender aos testes.
5.1.3.6. Desenvolvimento Orientado por Comportamento (BDD - Behavior Driven Development)
5.1.3.6.1. - Expressa o comportamento desejado com casos de teste escritos em uma forma simples de linguagem natural, que é fácil de entender pelos stakeholders - geralmente usando o formato Dado/Quando/Então
5.1.3.6.2. - Os casos de teste são então traduzidos automaticamente em testes executáveis.
5.1.3.6.3. - É desenvolvido através da conversa entre POs, devs e QAs para criar um fluxo de teste.
5.1.4. 2.1.4 Devops e Testes
5.1.4.1. Dev - Desenvolvimento
5.1.4.2. Ops - Operações (operations)
5.1.4.3. - DevOps é uma abordagem organizacional que visa criar sinergia, fazendo com que o desenvolvimento (incluindo os testes) e as operações trabalharem juntos.
5.1.4.4. - Exige uma mudança cultural na organização para preencher as lacunas entre o desenvolvimento (incluindo testes) e as operações.
5.1.4.5. - DevOps promove:
5.1.4.5.1. - Autonomia da equipe.
5.1.4.5.2. - Feedback rápido. Como a equipe mantém tudo em conjunto um código por exemplo sobe e já é disparado um teste automatizado para validar aquele código.
5.1.4.5.3. - Ferramentas integradas, essa ferramentas fazem parte do devops, elas servem para fazer deploy do código, fazer testes unitário e alguns testes E2E. Existem diversas ferramentas que fazem diferentes tipos de validações.
5.1.4.5.4. - Práticas técnicas como:
5.1.4.6. - Isso permite que as equipes criem, testem e liberem códigos de alta qualidade mais rapidamente por meio de um pipeline de entrega de DevOps.
5.1.4.7. Benefícios do DevOps para os testes
5.1.4.7.1. - Feedback rápido sobre a qualidade do código e se as alterações afetam negativamente o código existente;
5.1.4.7.2. - O CI promove uma abordagem shift-left nos testes, incentivando os desenvolvedores a enviar códigos de alta qualidade acompanhados de testes de componentes e análise estática;
5.1.4.7.3. - Promove processos automatizados, como CI/CD, que facilitam o estabelecimento de ambientes de testes estáveis;
5.1.4.7.4. - Aumenta a visão das características de qualidade não funcionais (ex: performance, confiabilidade);
5.1.4.7.5. - A automação por meio de um pipeline de entrega reduz a necessidade de testes manuais repetitivos;
5.1.4.7.6. - O risco na regressão é minimizado devido à escala e ao alcance dos testes de regressão automatizados;
5.1.4.8. Riscos e desafios do DevOps
5.1.4.8.1. - O pipeline de entrega de DevOps deve ser definido e estabelecido;
5.1.4.8.2. - As ferramentas de CI/CD devem ser introduzidas e mantidas, necessário ser feita uma manutenção regular e exige esforço do time;
5.1.4.8.3. - A automação de testes requer recursos adicionais e pode ser difícil de estabelecer e manter.
5.1.4.9. DevOps necessita de um alto nível de testes automatizados, porém testes manuais ainda são necessários (principalmente da perspectiva do usuário)
5.1.5. Descreve os tipos de atividades realizadas em cada estágio de um projeto de desenvolvimento de software e como as atividades se relacionam umas com as outras de forma lógica e cronológica. Há vários modelos de ciclo de vida de desenvolvimento de software, cada um dos quais requer abordagens diferentes para o teste.
5.1.6. Exemplo do modelo cascata
5.1.6.1. Análise → Design → Desenvolvimento → Testes → Entrega → Manutenção
5.1.7. Modelos de Ciclo de Vida de Desenvolvimento (SDLC)
5.1.7.1. - Sequencial (ex: modelo em cascata, modelo em V)
5.1.7.2. - Iterativo e incrementais (ex: espiral, modelos ágeis em geral)
5.1.8. Outras práticas
5.1.8.1. - XP
5.1.8.2. - TDD (**Test-Driven Development**)
5.1.8.3. - ATDD (**Acceptance Test-Driven Development**)
5.1.8.4. - BDD (**Behaviour-Driven Development**)
5.1.9. Independente do modelo de ciclo de vida escolhido, as atividades de teste devem começar nos estágios iniciais, principio de testar do inicio.
5.2. 2.2 Niveis de teste
5.2.1. 2.2.1 teste de componentes
5.2.2. 2.2.2 teste de integração
5.2.3. 2.2.3 Teste de Sistema
5.2.4. 2.2.4 Teste de aceite
5.3. 2.3 Tipos de teste
5.3.1. 2.3.1 Teste Funcional
5.3.2. 2.3.2 Teste não funcional
5.3.3. 2.3.3 Teste caixa-branca
5.3.4. 2.3.4 Teste relacionado a mudança
5.3.5. 2.3.5 Tipos de teste e Niveis de teste
5.4. 2.4 Teste de Manutenção
5.4.1. 2.4.1 Gatilhos para manutenção
5.4.2. 2.4.2 Análise de impacto para manutenção
6. 3 Teste estático
6.1. 3.1 Noções básicas
6.1.1. 3.1.1 Produtos de trabalho
6.1.2. 3.1.2 Beneficios
6.1.3. 3.1.3 Diferenças entre Estaticos e Dinâmicos
6.2. 3.2 Processo de revisão
6.2.1. 3.2.1 Processo revisão produto de trabalho
6.2.2. 3.2.2 Funções e responsabilidades revisão normal
6.2.3. 3.2.3 Tipos de revisão
6.2.4. 3.2.4 Aplicando tecnicas de revisão
6.2.5. 3.2.5 Fatores de sucesso para revisões