Dicas Exame CBTS 2010

Caros candidatos à Certificação Brasileira de Teste de Software, o "resumão" abaixo foi elaborado pelo Jonathan Rodrigo, ele o utilizou como referência complementar na prova do ano passado.

Aproveite para ver também: Simulado - Certificacao CBTS

Erro: Falha humana, normalmente é classificada como erro uma linha de código.
FURPS: É um modelo metodológico (do RUP)
Estágios, fases ou níveis de testes: Unitário / Integração/Sistema / Aceite.
Principal objetivo do teste: Encontrar o maior número de defeitos.
Custo do Software: O custo do software é o valor do desenvolvimento+o valor da manutenção.
Automação: Na certificação quando se falar de automação, estarão se referenciando á todo o processo de teste, deste seu planejamento, elaboração dos casos de testes e sua entrega.
Risco: Não existe risco 0% e nem 100%, para ser realmente um risco ele estará entre 10% á 90%.
Risco: Possibilidade de falha x prejuízo causado pela falha.
"Uma das maneiras de reduzir os riscos do software é testá-lo adequadamente"
Fluxo de gerenciamento de riscos
 
Modelo V: É o modelo que mostra a integração das atividades de desenvolvimento e teste de software, seu principal objetivo é mostrar o paralelismo entre as atividades.
Regra 10 de Myers: Prega que quando mais cedo o defeito/erro ou falha for encontrado mais barato será o seu ajuste.
Rex Black
Bohem
Estratégia de teste: Para elaborar uma estratégia é necessário saber O Que iremos testar, Como estes teste irão ser realizados e Quando, em qual momento será executado os testes.
Definições:
  • O Que: Neste momento levantamos as características da qualidade que iremos dar atenção nos testes.
  • COMO: Quais técnicas de teste iremos utilizar para atender os testes referentes às características levantas.
  • QUANDO: Em qual Estagio/Fase ou Nível iremos realizar os teste.
Ambiente de teste: O livro define ambiente de teste todas as pessoas envolvidas, os hardwares e softwares que farão parte do projeto.
Plano de Teste: É onde todas as definições do projeto de teste devem constar, por exemplo: A definição do ambiente de teste.
Os apontamentos dos riscos mais críticos, pois cada projeto tem suas particularidades e é no plano de teste onde definimos as regras (escopo) do projeto.  
Preparação dos Volumes: Esta atividade é realizada na elaboração dos casos de teste.
Definição de Risco: Risco é a probabilidade de algo acontecer ou não trazendo benéficos ou malefícios ao projeto. (Chance de falhar x prejuízo causado).
Analise de risco: Na analise de risco é levado em conta a Probabilidade e a Criticidade, EX:
  • Se Probabilidade baixa e Criticidade alta = Risco Médio.
  • Se Probabilidade média e Criticidade baixa = Risco Baixo.
Testware: São todos os documentos que são gerados no projeto, obs.* todos estes documentos devem ser armazenados na ferramenta de GC
Mitigação: É a forma de controlamos um risco que ainda NÃO aconteceu, para que ele não venha se tornar uma realidade.
Contingência: Quando o Risco ACONTECEU, então Iniciamos o plano de contingência "Outra estratégia" resumindo o plano B.

Formas de Estabelecer um risco (QAI).
  • Intuição ou discernimento: Onde um técnico experiente usa sua intuição aliada com sua experiência e aponta um risco que se ocorrer ira custar muito caro seu concerto.
  • Consenso: A equipe entra em consenso referente á probabilidade de um risco acontecer.
  • Formula de Risco: O risco é calculado através de uma formula onde existem dados financeiros que permitem medir o custo da perda pela ocorrência do risco.
  • Estimativas de perdas anuais: É a combinação do consenso com a fórmula de risco.
Artefato de saída do Planejamento: O artefato de saída do planejamento é o PLANO de TESTE.

Quando é necessário criar mais de um plano de teste para um mesmo projeto?
Segue abaixo a exemplificação:



Só para lembrar "tudo que acontecer na definição estará dentro do PLANO DE TESTE".

Teste de Aceite

  • Responsável: Usuário
  • Objetivo: garantir que o que foi solicitado foi criado e se este funcionado corretamente.

Estar APTO ou FIT: Este termo é o mais utilizado para dizer que o software está pronto ou dentro das conformidades de aceite.

Para a fase do Aceite é necessário criar um plano de Aceite.

Gerenciamento de defeitos: Esta atividade é realizada no momento da execução dos testes, onde observamos quantos Bug´s estão sendo abertos/ Fechados.
Gestão de defeitos: É a melhoria continua, realizando prevenção dos defeitos, ele se inicia desde o inicio do projeto.

Baseline: Fotografia do momento atual do projeto.
Diferença de Baseline e GC:

Baseline é o projeto geral e GC é de doc á doc.

Releases: São oriundos das baselines, são utilizadas para entregas para o teste ou produção.

Alguns detalhes importantes na hora de reportar os Defeitos:
  • -Resumir: Reportar claramente, mas de forma resumida.
  • - Precisão: É um defeito ou poderia ser um erro do usuário EX: Erro de entendimento. Portanto, descrever realmente o que foi executado para que a falha fosse detectada. 
  • -Neutralizar: Reportar apenas os fatos, sem humor, sem emoções.
  • -Isolar:
  • - Generalizar: Procurar entender o problema de forma genérica.
  • - Reproduzir: Reproduzir um defeito ao menos duas vezes antes de reportá-lo
  • -impacto: Qual o impacto deste defeito para o cliente?
  • -Evidencie: Evidencie a existência do defeito encontrado
Relatórios IEEE
  • Log de teste
  • Relatório de incidentes
  • Relatório sumário
APT: para se ter o APT (Analise de ponto de teste) é necessário ter o APF(Analise de ponto de função). O APF mede somente o teste Unitário e de Integração.
O APT observa TAMANHO e ESFORÇO.
Se tiver muitas funcionalidades é pior para controlar.
Se tiver poucas ferramentas de gerenciamento é pior para controlar.
O que o APT analisa para seu calculo?
O APT analisa o Tamanho do sistema, avalia a estratégia e o nível de produtividade da equipe.

PTDF – Ponto de teste Dinâmico de uma funcionalidade
PF-Tamanho da função em ponto de função

Se a equipe é MAIS qualificada, MENOR será o QET
QET – Qualificação da equipe de teste
AT – Ambiente de Teste
HTP – Horas de teste primárias.

O QET varia de 0,7 á 2.0

Formula:
QET + AT = HTP

Referência: Base de conhecimento em teste de Software
Veja também: Simulado - Certificacao CBTS

QABI Consultoria e Oz InSite - Desenvolvimento Web
Compartilhar no Facebook:
Compartilhar no Linkedin:

4 comentários:

  1. Faltou citar o relatório de transmissão de itens de teste, nos relatórios da IEEE-829. Este tem por propósito:

    Para identificar os itens de teste que está sendo transmitido para o teste. Ele inclui a pessoa responsável por cada item, sua localização física, e seu status. Quaisquer variações das exigências do item atual e os projetos são registrados no presente relatório.

    ResponderExcluir
  2. Marcelo, muito boa as dicas.

    parabéns,

    André Leite

    ResponderExcluir
  3. Olá André/Luciano. Obrigado pela visita. Estamos preparando outras dicas referentes a prova da CBTS 2012, incluído MPS.BR.
    Abraços.

    ResponderExcluir

Indique ou comente o post. Obrigado pela visita!