CTFL - Resumo do Capítulo 1 do Syllabus

Como falei anteriormente no post de Apresentação estou me preparando para obter a certificação CTFL e uma das fontes de estudo é o Syllabus, que pode ser baixado no site do BSTQB (www.bstqb.org.br), se você tiver com preguiça de ir lá procurar, pode baixar aqui. 

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

Apresentação

Motivado pela movimentação que está sendo feita atualmente em um grupo do google ao qual participo: o teste-software-ce@googlegroups.com, decidi colocar em prática uma ideia antiga de usar um blog como incentivo para os meus estudos.

Pretendo com esse blog, continuar os meus estudos visando a obtenção da Certifação de Teste CTFL - Certified Tester Foundation Level, para isso vou postar resumos dos capítulos do Syllabus.

Também pretendo falar de assuntos ligados à area de Teste e Qualidade de Software de um modo geral, novidades, eventos, cursos, etc.

Quanto ao nome PRA QUE TESTAR?, foi o nome que mais me chamou a atenção dentre as diversas sugestões que levantei junto com alguns colegas de trabalho. Quem nunca ouviu essa expressão ? Aposto como um amigo seu DEV já lhe fez uma pergunta como essa!