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

Comentários

  1. Ana Joslin19 de maio de 2010 às 16:11

    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. André Leite1 de junho de 2010 às 14:54

    Marcelo, muito boa as dicas.

    parabéns,

    André Leite

    ResponderExcluir
  3. Unknown31 de janeiro de 2012 às 22:09

    Ótimas dicas!!!

    ResponderExcluir
  4. Marcelo Lourenço6 de fevereiro de 2012 às 21:44

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

    ResponderExcluir

Postar um comentário

Indique ou comente o post. Obrigado pela visita!

Postagens mais visitadas deste blog

Teste de Caixa-Preta

O Teste de Caixa-Preta ou Teste Funcional, também é usado na engenharia, no problema de identificação de sistemas, e advém do fato de que ao analisar o comportamento de um objeto, ignora-se totalmente sua construção interna. Nesse tipo de teste, uma determinada função g() que não aceita valores negativos, mas não possui tratamento adequado de exceção, poderia ser testada para cem mil valores diferentes no intervalo [0...10 6 ], sem que fosse detectado algum defeito. O teste de caixa-preta é baseado nos requisitos funcionais do software. Como não há conhecimento sobre a operação interna do programa, o avaliador se concentra nas funções que o software deve desempenhar. A partir da especificação são determinadas as saídas esperadas para certos conjuntos de entrada de dados. Esse tipo de teste reflete, de certa forma, a óptica do usuário, que está interessado em se servir do programa sem considerar os detalhes de sua construção. Comparando a outros tipos de teste, este é relativament
Leia mais

Teste de Estresse

É realizado para submeter o software a situações extremas. Basicamente, o teste de estresse baseia-se em testar os limites do software e avaliar seu comportamento. Assim, avalia-se até quando o software pode ser exigido e quais as falhas (se existirem) decorrentes do teste. Os testes de estresse são fundamentais em aplicações em que a eficiência seja uma característica importante. Por exemplo:  servidores de arquivos e servidores web, que devem atender a solicitações de um grande número de clientes;  aplicações industriais, tais como o controle de uma refinaria de petróleo;  jogos de computador, que precisam de um desempenho aceitável para serem viáveis comercialmente. Vamos considerar como exemplo a implementação de um servidor web utilizado em e-commerce. Ao estabelecer os requisitos do sistema, fixou-se um máximo de 5000 transações por minuto para uma determinada plataforma de execução. Um teste de estresse pode, então, ser feito para responder a várias perguntas:  o si
Leia mais

Teste de Caixa-Branca

Também conhecido como teste estrutural. É aquele em que o analista tem total acesso à estrutura interna da entidade sendo analisada e permite, por exemplo, que o analista escolha partes específicas de um componente para serem testadas. O fato de conhecer o código do programa permite que o avaliador projete testes mais precisos. Por exemplo, se a definição de uma função g() , para um determinado programa, afirma que ela não aceita valores negativos, um avaliador poderia provocar uma chamada fun(-1) e descobrir que um tratamento de exceções não está corretamente implementado. Esses testes são projetados em função da estrutura do componente e podem permitir verificação mais precisa de comportamento do produto. Ele permite ao avaliador concentrar a atenção nos pontos mais importantes ou “perigosos” do código, de uma maneira mais precisa do que no caso do teste caixa-preta. Tais pontos podem até ser identificados durante o desenvolvimento e cobertos com o uso de assertivas e testes.
Leia mais

Plano de Teste - Padrão IEEE 829-1998

O ideal seria que sempre houvesse uma equipe destinada a realizar testes de software, produzindo os relatórios necessários para que os problemas possam ser estudados e resolvidos. Mas nem todas as empresas possuem estrutura que suporte ter uma equipe que siga todas as instruções para a realização de testes. Nestes casos, uma boa saída é nomear alguém da empresa que não esteja envolvido na produção do sistema para realizar os testes. Claro que nestes casos as empresas devem definir quais os principais testes devem ser realizados de forma a atingir as partes mais críticas do sistema. Os erros encontrados devem ser documentados com informações suficientes que ajudem na reprodução do erro, facilitando assim a solução do problema. A documentação do erro deve ser definida pela empresa. É importante manter um histórico de falhas encontradas, pois assim, ao final do projeto, pode ser feito um estudo e obter um aprendizado em cima dos erros que foram encontrados. Uma atividade de testes
Leia mais

Teste de Integração

Quando todos os componentes de um software foram testados, surge uma pergunta: quando estiverem integrados, continuarão funcionando? O teste de componentes individuais antecede o teste de integração. Contribui para assegurar a correção de componentes individuais, mas não é capaz de garantir que as dependências funcionais entre componentes estejam perfeitamente implementadas. Para isso é preciso uma abordagem diferente. Com relação a integração de componentes, existem duas vertentes principais para desenvolvimento de software: as abordagens bottom-up e top-down. Na abordagem bottom-up, o programa é desenvolvido a partir de rotinas básicas que prestam serviços a rotinas de nível mais alto. Por exemplo, uma verificação de validade de CPF pode ser chamada em vários pontos de um programa. Será, então uma das primeiras a serem implementadas. Na abordagem top-down, faz-se o inverso. O programador trabalha supondo que o código de baixo nível já esteja pronto. Assim, pode-se codificar cha
Leia mais

Teste de Aceitação

O teste de aceitação é realizado com o propósito de avaliar a qualidade externa do produto e, na medida do possível, também a qualidade em uso. Assim, só é possível quando o software está concluído e pronto para ser implantado. Evidentemente, é um teste com forte relação com o cliente, que participa do planejamento e realização dessa atividade. O teste de aceitação é geralmente denominado de “alfa” quando realizado no ambiente de desenvolvimento (qualidade externa) e “beta” quando no ambiente do cliente (qualidade de uso). O teste de qualidade externa é com freqüência a única alternativa no caso de aplicações desenvolvidas para mainframes . Uma forma de paliar a impossibilidade de utilizar a plataforma definitiva de execução é simulá-la, por exemplo, utilizando dados reais. Outro tipo de teste de aceitação possível é o teste de paralelo, quando um sistema é desenvolvido para substituir outro já em funcionamento. O novo sistema pode funcionar em paralelo ao antigo e o comportamento
Leia mais