terça-feira, 23 de novembro de 2010

MPT - Melhoria de Processo de Teste Brasileiro

Considerações do MPT:
   O MPT.BR é um modelo para Melhoria de Processo de Teste de Software Brasileiro, que está sendo desenvolvido com o princípio básico de ser compatível com o modelo MPS.BR criado pela Softex e é baseado também em alguns critérios usados pelo CMMI. O MPT é voltado para a melhoria das áreas de teste de software de empresas de qualquer porte. O modelo é leve e passível de ser adotado por áreas de teste de software para apurar o seu nível de maturidade, sem com isso onerar os seus processos anteriormente implementados. O objetivo principal será garantir que áreas de teste de software de tamanho reduzido possam ser avaliadas e estimuladas a alcançarem níveis maiores de maturidade, sem que para isso tenham que incorrer em altos custos de operacionais.


  1. O MPT está subdividido em níveis de maturidade, sendo que no total compreendem-se 7 níveis;
  2. A única área de processo que uma organização precisa para chegar ao primeiro nível do MPT é a de Gerência de Projetos de Teste(GPT);
  3. Níveis e respectivas áreas de processo;
    Nivel 1
    Gerência de Projetos de Teste - GPT
    Nível 2
    Gerência de Requisitos de Teste - GRT
    Nivel 3

    Aquisição – AQU (opcional)
    Gerência de Configuração – GCO
    Garantia da Qualidade - GQA
    Medição - MED
    Nível 4
    Gerência de Recursos Humanos - GRH
    Nível 5

    Desenvolvimento de Requisitos - DRE
    Integração do Produto - ITP
    Validação - VAL (opcional)
    Verificação - VER
    Nível 6
    Análise de Decisão e Resolução - ADR
    Desenvolvimento para Reutilização - DRU(opcional)
    Gerência de Riscos - GRI
     Nível 7

    Análise de Causas e Resolução de Problemas- ACP
  4. A implantação de uma área de processo não é obrigatória em nenhum nível. Trata-se apenas de uma forma de facilitar o uso das práticas exigidas.
  5. Cada área de processo possui Práticas específicas e Objetivos genéricos;

segunda-feira, 22 de novembro de 2010

Material para a Prova CBTS(Revisão)

Como todos sabem a prova da ALATS vai ser nesse fim de semana dia 27/11, tendo em vista o material que tenho, estarei disponibilizando abaixo um pouco do resumo que utilizo para estudar para a prova. Estarei postando em partes e ressalto que o mesmo não está organizado por sequência, são simplesmente pontos que achei importante enquanto lia o livro;


  1. Evidência de testes é garantir que os testes descritos foram executados e os resultados obtidos por cada um deles;
  2. Conforme Padrão IEEE os relatórios que devem ser elaborados são:
    Relatório de log de teste, Relatório de sumário de teste e Relatório de incidentes de teste.
  3. APT(Ponto de teste) utiliza funções transacionais que são:
    Entradas/Saídas, Consultas externas e Saídas externas;
  4. Testes unitários, de integração, de sistema e de aceitação, podem ser classificados como testes de validação;
  5. Fator de teste, são os riscos que precisam ser tratados através da estratégia de testes;
  6. Os teste unitários podem remover entre 30% e 50% dos defeitos dos programas;
  7. Documentos do processo de teste são:
    Estratégia de testes, Análise de riscos, Planos de testes, Casos de testes, Script de testes e Registro de testes.
  8. Após testes unitários e de sistema, os sistemas podem ir para produção ainda com aproximadamente 49% dos defeitos;
  9. Risco = Chance de falhar X Prejuízo causado pela falha;
    Risco é uma perda em potencial para a organização. É a probabilidade de algo acontecer ou não trazendo benefícios ou malefícios.
  10. Método PairWise de teste(Teste de Combinação dupla)
    Requer que para cada par de parâmetros de entrada de um sistema, cada combinação de valores válidos entre esses dois parâmetros, seja coberta ao menos por um caso de teste.
  11. Erro -> Defeito -> Falha
    Erro: engano cometido por seres humanos ou resultado de uma falha humana;
    Defeito: Resultado de um erro encontrado num código ou num documento;
    Falha: Resultado ou manifestação de um ou mais defeitos.
  12. FURPS é um modelo metodológico(do RUP) com as seguintes categorias de qualidade:
    Funcionalidade, Usabilidade, Confiabilidade, Desempenho e Suportabilidade.
  13. O QAI estabelece que um risco pode ser determinado de quatro formas:
    Intuição ou julgamento, Consenso, Fórmula de risco ou Estimativas de perdas anuais.
  14. O PMI desenvolveu um modelo onde cada processo(ou subprocesso) é definido como:
    Entradas; Ferramentas e Técnicas; Saídas.
  15. O plano de testes é formado por quatro partes:
    Informações gerais;               Especificações e avaliações;
    Plano;                                   Descrição dos testes.
  16. O tratamento de riscos aparece inicialmente na área de processo Planejamento de Projeto(PP), no nível de maturidade 2 CMMI.
  17. O processo de gestão de defeitos tem como objetivo primordial "evitar defeitos";
  18. Um dos princípios básicos para evitar defeitos é minimizar riscos;
  19. Quanto melhor e mais qualificada for a equipe, menor será o índice QET(Qualificação da equipe de teste);
  20. 3P X 3E
    3P: Procedimentos Iniciais, Planejamento e Preparação
    3E: Especificação, Execução e Entrega 
Inicialmente estou disponibilizando uma parte e estarei tentando disponibilizar ainda essa semana mais conteúdo, vou tentar preparar um conteúdo referente ao MPT.BR.

Críticas e sugestões, efetuá-las através de comentários que estarei realizando o Feedback.

sábado, 6 de novembro de 2010

Questões ALATS - Certificação Brasileira de Teste de Software

    É faltam poucos dias para o exame da CBTS e muitos devem estar se preparando para a prova, então, para esse post eu preparei um resumo de algumas questões que caíram no último exame realizado pela ALATS. De certa forma servirá para todos terem uma boa noção do que é abordado na prova. Os conceitos foram retirados do livro “Base de conhecimento em teste de software”, que é a principal referência para a prova.


01.  Definição de erro
Engano cometido por seres humanos/ Resultado de uma falha humana.
02.  Definição de testes de regressão
Testar novamente segmentos já testados após a implementação de uma mudança em outra parte do software.
03.  Definição de conceito V de testes
O grupo que FAZ trabalha com o objetivo de implementar o sistema e a equipe que CONFERE, simultaneamente, executa procedimentos de testes visando minimizar ou eliminar riscos. O ciclo de vida de testes pressupõe que sejam realizados testes ao longo de todo o processo de desenvolvimento.
04.  Objetivo de testes de segurança
Os testes de segurança visam descobrir defeitos muito difíceis de identificar.
05.  Definição de atividades de verificação
As atividades de Verificação e Validação servem para assegurar que o software funcione de acordo com o que especificado e atenda aos requisitos dos stakeholders. Essas atividades constituem um processo iniciado com as revisões dos requisitos, passando pelas revisões da análise e do projeto do software e as inspeções do código até chegar aos testes.
Verificação é uma atividade que tem como objetivo assegurar consistência, completitude e corretitude do produto em cada fase e entre fases consecutivas do ciclo de vida do software (Estamos construindo corretamente o produto?).
06.  Definição de atividades de validação
 Validação é uma atividade que tem como objetivo assegurar que o produto final corresponda aos requisitos do software (Estamos construindo o produto certo?).
07.  Nível máximo de maturidade sem testes
Podemos dizer que, sem o teste perfeitamente caracterizado numa área separada, não é possível atingir, nesse caso, o nível 3 de maturidade. Portanto o nível máximo a se atingir sem testes é o nível 2.
08.  Nível de maturidade CMMI (verificação e validação)
Nível de maturidade do CMMI que possui como área de processo Verificação e Validação é o nível 3.
09.  Regra 10 Mayers
Estabelece que o custo de correção de defeitos tende a aumentar quanto mais tarde o defeito é detectado.
10.   Objetivo de testes de estresse
Avaliar o comportamento do software sob condições críticas, tais como restrições significativas de memória, de área de disco e de CPU.
11.   Turnkey(Pacotes/Softwares fechados)
Requer modificações de funções ou regras estabelecidas nas responsabilidades dos participantes das atividades do CVDS.
12.   O que determina os testes de tratamento de erros
Determinam a capacidade do sistema de tratar apropriadamente transações incorretas.
13.   Categoria dos testes de estresse na metodologia FURPS
Confiabilidade
14.   Categoria dos testes de carga na metodologia FURPS
Desempenho
15.   Definição de testes de recuperação
Testes de recuperação garantem a continuidade das operações após um desastre, também verifica a eficácia das partes do componentes do processo.
16.   Definição de teste estrutural
Testes estruturais garantem que o software e programas sejam estruturalmente sólidos e que funcionem no contexto técnico onde serão instalados.
17.   Qual o princípio de pareto?
20% do software é responsável por 80% de suas funcionalidades.
18.   Modelo desenvolvido pelo PMI em que cada processo é definido como:
Entrada; Ferramentas e técnicas; Saídas
19.   Formas de avaliação gerência de riscos
Identificação, Análise, Classificação, Planejamento, Rastreamento e Controle.
20.   Risco
É uma perda em potencial para a organização. O risco pode ser medido através da análise de risco.
21.   Análise de riscos
É uma avaliação dos recursos de informação de uma organização e suas vulnerabilidades. A análise de riscos combina a probabilidade de ocorrência com a gravidade dos danos causados por sua ocorrência.
22.   Análise quantitativa
Processo de análise numérica do efeito dos riscos identificados nos objetivos gerais do projeto. A análise quantitativa de riscos é realizada nos riscos que foram priorizados pelo processo de análise qualitativa, por afetarem potencial e significativamente das demandas conflitantes do projeto.  Ela analisa o efeito desses eventos de risco e atribui uma classificação numérica a esses riscos. Ela também apresenta uma abordagem quantitativa para a tomada de decisões na presença da incerteza.
23.   Plano de testes em planejamento de riscos
Os seguintes planos de testes devem ser elaborados: Plano de Mitigação e Plano de Contingência.
24.   Especificação de projeto de teste
Um detalhamento da abordagem apresentada no plano de teste que identifica as funcionalidades e as características a serem testadas pelo projeto.
25.   Técnicas de teste
Método Step-by-step, Método PairWase, Gráfico de Causa e Efeito, Método de Classe e Equivalência e Método dos Valores-Limite.

Inicialmente estão descritas acima apenas 25, em alguns dias postarei mais, bons estudos.