Pontos e Dicas para Exame CBTS 2010

Pontos e Dicas para Exame CBTS 2010

Caros candidatos a Certificação Brasileira de Teste de Software, abaixo esta o material que criei em meus estudos para a prova de certificação CBTS do Ano passado, creio que não terá muitas mudanças, porém não deixe de estudar as referências complementares, que em breve irei postar para todos os interessados.

 Se sugir alguma dúvida sobre algum assunto  da prova de certificação, entre em contato com o Portal da Qualidade para que possamos na medida do possivel sanar todas as dúvidas.

Observação: Para um bom entendimento do assunto sugiro que se faça a leitura pelo menos 2x do livro "Base de conhecimento em teste de Software" e exercite bastante...

  O portal da Qualidade deseja um otimo estudo a todos!!!!!

 

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”

Dicas- Na prova elimine sempre as duas primeiras erras.

 

     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 formula 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:

 

 

Exemplo de teste de Aceite com uma empresa fazendo o papel do Cliente.

 

 

 Quando as funcionalidades, Sigmas e interconexões apontar riscos e ou ambientes diferentes. 

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 esta 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.

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

Diferença de Baseline e GC

 

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

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 que o APT analisa para seu calculo?

E 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

PTF - ?

 

Se a equipe é MAIS qualificada, MENOR será o  QET

O QET varia de 0,7 á 2.0

Formula

QET + AT = HTP

QET – Qualificação da equipe de teste

AT – Ambiente de Teste

HTP – Horas de teste primárias.

O APT observa TAMANHO e ESFORÇO.

Se tiver muitas funcionalidades é pior para controlar

Se tiver poucas ferramentas de gerenciamento é pior para controlar.

 

Referencia: Base de conhecimento em teste de Software

 

Autor

 Jonathan Rodrigo da Silva Santos - CBTS, MPT