Terminei de ler o primeiro capítulo e trago agora pra vocês o resumo dele(ficou um pouco extenso mas tá valendo, prometo enxugar mais no próximo capítulo)
1.1 Porque é necessário Testar? (K2)
1.1.1 Contexto dos sistemas de software
- Sistemas de software se tornam
cada vez mais parte do nosso dia-a-dia. Muitas pessoas já tiveram alguma
experiência com um software que não funcionou como deveria, esses tipos de
software podem levar a muitos problemas, incluindo financeiro, atingindo a
reputação de empresas, podendo chegar a influenciar na integridade das pessoas.
1.1.2 Causas dos defeitos do software
- O ser humano está sujeito a cometer um erro (engano), que
produz um defeito (dano, bug), no código, em um software ou sistema ou em um documento;
- Se o defeito for executado, o sistema causa uma falha;
- Defeitos ocorrem por falha humana e também por pressão no prazo, mudanças de tecnologia, etc.
- O ERRO produz um DEFEITO que se executado gera uma FALHA
1.1.3 Função do teste no desenvolvimento, manutenção e
operação de software
- Rigorosos testes em sistemas e documentações:
- podem reduzir
os riscos de problemas em ambiente operacional;
- contribui para
a qualidade dos sistemas, quando os defeitos são encontrados e corrigidos antes de entrar em produção;
1.1.4 Teste e Qualidade (K2)
- Com a ajuda do
teste é possível medir a qualidade do software em termos de:
- Defeitos encontrados,
- Por
características;
- Requisitos
funcionais (ou não-funcionais) do software (confiabilidade, usabilidade, eficiência e manutenibilidade).
- O resultado da execução dos testes pode
representar confiança na qualidade do software caso sejam encontrados poucos ou nenhum defeito.
- Um teste projetado adequadamente e cuja
execução não encontra defeitos reduz o nível de riscos em um sistema.
- Por outro lado,
quando os testes encontram defeitos, a qualidade do sistema aumenta quando estes são corrigidos.
- Projetos anteriores devem prover lições
aprendidas.
- Testes devem ser integrados como uma das
atividades de garantia da qualidade (ex: juntamente aos padrões de desenvolvimento, treinamento e análise
de defeitos).
1.1.5 Quanto teste é suficiente? (K2)
- Para decidir quanto teste é necessário devemos levar em
consideração:
- Nível do risco,
incluindo risco técnico, do negócio e do projeto;
- Restrições como
tempo e orçamento;
- O teste deve prover informações suficientes para tomada de
decisão, para as próximas fases do desenvolvimento ou implantação nos
clientes.
1.2 O que é teste? (K2)
- Teste não é só na fase de execução;
- A execução é somente uma parte do teste, não contempla todas
as atividades do teste;
- Existem atividades antes e depois da execução, por
exemplo:
- Planejamento e
controle;
- Escolha das condições de teste;
- Modelagem dos casos de teste;
- Checagem dos resultados;
- Avaliação do critério de conclusão;
- Geração de relatórios sobre o processo de
teste e sobre sistema alvo;
- E encerramento ou conclusão (após a
finalização de uma fase de teste).
- Revisão de
documento e análise estática também fazem parte do teste;
- Objetivos do teste
- Encontrar
defeitos;
- Ganhar
confiança sobre o nível de qualidade;
- Servir para tomada de decisões;
- Prevenir
defeitos.
- Teste antecipado pode prevenir defeitos que poderiam estar
no código;
- Revisão de documentos também previne defeitos no código
- O principal objetivo do teste:
- Em
desenvolvimento(componente, integração e de sistemas) é causar o maior número de falhas, para que os defeitos possam ser
identificados e resolvidos;
- de Aceite:
confirmar se o sistema está de acordo com o que foi especificado nos requisitos;
- em alguns casos,
pode ser avaliada a qualidade(não com a intenção de encontrar defeitos) com o intuito de obter informações sobre
os riscos;
- durante os
testes operacionais, podem ser avaliadas características como confiabilidade e disponibilidade
- Depurar é diferente de Testar;
- Teste serve para demonstrar falhas causadas por defeitos;
- Depuração é uma atividade do desenvolvimento que vai
identificar o defeito, fazer a correção e checar se foi corrigido corretamente.
- O testador ainda faz
um novo teste(confirmação) para certificar que a falha foi corrigida.
1.3 Os sete Princípios do Teste (K2)
- Princípio 1 – Teste
demonstra a presença de defeitos
- Teste pode demonstrar a presença de defeitos,
mas não pode provar que eles não existem.
- O Teste reduz a probabilidade que os defeitos
permaneçam em um software, se não for encontrado nenhum defeito, mesmo assim
não prova que ele esteja perfeito.
- Princípio 2 - Teste exaustivo é impossível
-Testar tudo é
impossível(inviável), devemos considerar riscos e prioridades;
- Princípio 3 – Teste
antecipado
- Começar as
atividades bem antes e com objetivos definidos
- Princípio 4 –
Agrupamento de defeitos
- a maioria dos
defeitos ou falhas operacionais estão agrupados em um número pequeno de módulos
- Princípio 5 – Paradoxo do Pesticida
- Testes viciados
do mesmo conjunto de Casos de Teste podem não encontrar mais defeitos
- Revisar e
escrever novos Casos de Teste
- Princípio 6 – Teste depende do contexto
- Teste de
Software de controlador de voo é diferente de teste de software de comércio eletrônico
- Princípio 7 – A ilusão da ausência de erros
- Encontrar e
corrigir defeitos não ajuda se o sistema não atende a necessidade dos usuários
1.4 Fundamentos do Processo de Teste (K1)
1.4.1 Planejamento e Controle do teste (K1)
- Planejamento -
definir objetivos e atividades de forma a alcançá-los
- Controle - conferir
se o que foi planejado está sendo feito, caso contrário, tomada de ações serão necessárias para isso.
1.4.2 Análise e modelagem do Teste (K1)
- Revisar a base de
testes(requisitos, nível de risco, arquitetura, modelagem, interfaces);
- Avaliar a
testabilidade dos requisitos do sistema
- Identificar e
priorizar condições e requisitos de teste
- Projetar e
Priorizar Casos de Teste
- Identificar
necessidade de dados para teste
- Planejar a
preparação do ambiente, infraestrutura e ferramentas
1.4.3 Implementação e execução de teste (K1)
- Finalizar, implementar e priorizar os casos de teste
- Desenvolver e priorizar os procedimentos de teste, criar
dados de teste;
- Criar suítes de teste;
- Verificar ambiente
- Verificar rastreabilidade entre a base de teste e os casos
de teste;
- Executar teste manual ou utilizando ferramentas;
- Registrar os resultados da execução;
- Reportar discrepâncias como incidentes
- Reexecutar os testes onde houve discrepâncias
1.4.4 Atividades de encerramento de teste (K1)
- Coletar e consolidar dados quando um projeto de teste é
completado
- Checar se as entregas planejadas foram entregues;
- Fechar relatórios de incidentes
- Documentar o aceite do sistema;
- Finalizar e entregar o testware*
- Analisar lições aprendidas.
Testware: Artefatos produzidos durante o teste
(Procedimentos, arquivos, ambiente, resultados esperados,...)
1.5 A Psicologia do Teste (K2)
- A forma de pensar enquanto está se analisando e
desenvolvendo é diferente quando se está testando, quando se está testando essa
forma de pensar é mais independente porque é feita por um profissional treinado
e com recursos de teste;
- Níveis de independência representam um forma eficiente de
encontrar defeitos e falhas e podem ser definidas dessa forma:
- Teste
de quem desenvolveu o software (baixo nível de independência)
- Teste
feito por outro desenvolvedor
- Teste
feito por uma pessoa de outro grupo dentro da organização
- Teste
feito por outra organização
- Pessoas e projetos são direcionados por objetivos, por
isso é importante que objetivos estejam claros;
- Teste é visto como uma atividade destrutiva;
- Encontrar falhas requer curiosidade, pessimismo
profissional, olhar crítico, atenção ao detalhe, comunicação eficiente com a
equipe;
- Reportar falhas de forma construtiva evita constrangimento
- Equipe de teste deve ter boa relação com as demais
equipes;
- Formas de melhorar a comunicação da equipe:
- Maior espírito de colaboração;
- Reportando falhas de forma
neutra, objetiva e sem criticar o desenvolvedor;
- Confirmar o entendimento do
desenvolvedor com relação ao que foi relatado
