segunda-feira, 16 de dezembro de 2013

Tabelas de decisão

No post sobre cenários de teste, citei que uma das formas de derivá-los é utilizando tabelas de decisão. Vejamos detalhes sobre a técnica.

As tabelas de decisão são utilizadas para testar a interação entre as combinações de condições. As tabelas de decisão são um método claro para verificar a realização de testes com todas as combinações de condições pertinentes e para garantir que todas as possíveis combinações sejam tratadas pelo software em teste.

Uma tabela de decisão é composta de:

1. Condições: cada condição é descrita numa linha da Tabela de Decisão e deve ter seus possíveis valores conhecidos e descritos.

2. Ações: as ações também são descritas nas linhas da Tabela de Decisão e indicam declarações do que é realizado no processo.

3. Regras ou normas: as regras são as combinações dos valores das condições atreladas da Tabela de Decisão. Cada regra consiste em um conjunto de valores possíveis das condições, envolvendo um único valor para cada condição. As regras devem esgotar todas as possibilidades de combinações de valores resultantes das condições da Tabela de Decisão. Cada regra é representada em uma coluna da Tabela de Decisão.

O projeto de uma Tabela de Decisão implica em formar uma tabela com quatro quadrantes, sendo um para a exposição das condições, outro para a exposição das ações, outro para a descrição das regras e o último para relacionar as ações que são executadas para cada regra. A Figura abaixo mostra a disposição dos quadrantes na tabela.




A tabela pode ser construída seguindo os seguintes princípios:


1. Todas as condições devem ser identificadas e descritas no primeiro quadrante da tabela (cada condição deve ser descrita em uma linha).

2. Para condição, deve ser identificado o número de valores possíveis para ela e estes valores devem ser descritos na frente da variável da condição no primeiro quadrante.

3. Todas as ações possíveis para o processo devem ser identificadas e descritas no terceiro quadrante (cada ação deve ser descrita em uma linha). As ações devem ser descritas por sentenças que iniciam com verbo no infinitivo ou por fórmulas.

4. O número de regras deve ser calculado, sendo o resultante do número possível de combinações que podem ser feitas com os valores de cada condição. O cálculo do número de regras é feito multiplicando-se os números de valores possíveis das condições.

Por exemplo, se todas as condições forem binárias, ou seja, puderem assumir apenas dois valores
(por exemplo: verdadeiro ou falso; sim ou não; 0 ou 1; etc), o número de regras será 2N, onde o número 2 representa o fato das condições serem binárias e N representa o número de condições. Se houver uma Tabela de Decisões onde há três condições com dois valores possíveis e uma
condição com três valores possíveis, o número de regras é obtido pela multiplicação de 23
(que representa as três condições binárias) por 3 (ou 31, que representa uma condição ternária). Neste caso, o número de regras será 24.

5. Para cada regra, uma coluna deve ser desenhada no segundo quadrante, sendo numerada na extremidade superior para identificar cada regra.

6. As linhas do primeiro quadrante (condições) devem ser prolongadas até o final do segundo quadrante

7. O cruzamento entre linhas e colunas do segundo quadrante deve ser preenchido por todas as combinações de valores possíveis das condições que formam cada regra. Uma forma de evitar se perder neste preenchimento, quando há um grande número de regras, é começar pela última condição preenchendo, na sequência, cada valor possível em uma coluna e repetindo este procedimento até o final da linha. Em seguida utiliza-se o mesmo procedimento para a penúltima condição, mas ao invés de repetir uma vez cada valor, ele é repetido seqüencialmente tantas vezes quanto for o número de valores possíveis da condição já representada na tabela. Depois, repete-se o
procedimento para a antepenúltima condição, repetindo o mesmo valor da condição tantas vezes quanto for o resultado da multiplicação entre o número de valores possíveis das condições já expressas na tabela. E assim sucessivamente, até completar a linha da primeira condição.

8. As colunas do segundo quadrante devem ser prolongadas até o final do quarto quadrante.

9. Para cada regra, deve(m) ser identificada(s) a(s) ação(ões) que são executadas no caso da combinação respectiva de valores das condições ocorrer. As combinações impossíveis de acontecer ensejam a marcação de toda a coluna, no quarto quadrante, do símbolo “–“.

10. As omissões, contradições e ambiguidades devem ser identificadas e discutidas com o usuário para o aperfeiçoamento da especificação. Uma omissão ocorre quando não há ação definida para uma regra possível. Uma contradição ocorre quando duas ações contraditórias são executadas para uma mesma regra. E uma ambiguidade ocorre quando há muitas regras diferentes definindo a execução das mesmas ações.

domingo, 1 de dezembro de 2013

Cenário de Teste

Cenários de teste, informalmente, podem ser definidos como uma estória sobre o sistema e é útil para ajudar o Testador no momento da execução dos testes.Assim, o cenário não descreve passos para efetuar os teste, descreve "o que" deve ser testado, divergindo do caso de teste onde se descreve "como" deve ser testado o software.

Um cenário de teste pode ser visto também como um caminho ou uma determinada situação a ser testada. Cada cenário poderá ser composto  por um ou por um  conjunto de casos de testes.

Exemplo de Lista de Cenários do Requisito A




Mas como gerar esses tais cenários?

- Identificar o fluxo principal de um caso de uso
- Localizar os fluxos alternativos
- Localizar os fluxos de exceção
- Se o requisito contiver operações de manutenção levante os fluxos para cada uma delas.
- Usar técnicas como a Tabela de decisão, Grafos de transição de estado, e também o Pairwise.

terça-feira, 19 de novembro de 2013

Planejamento x Execução


domingo, 10 de novembro de 2013

E sobre a CPRE-FL?

Pesquisando sobre áreas "irmãs" do teste, encontrei essa certificação que, apesar de ainda não ser muito difundida no Brasil, pode auxiliar um bocado nas ativiades de teste e ser um diferencial a mais para o profissional.

CPRE-FL é a sigla para Certified Professional for Requirements Engineering - Foundation Level.

O que preciso estudar?
O material coberto pelo Syllabus do Foundation Level.

Onde está o Syllabus?


Em: http://abramti.org.br/node/80

Fazendo a prova eu aprendo o que?

- Delimitar o sistema e o contexto do sistema
- Elicitar Requisitos
- Documentação de Requisitos
- Documentação de Reuisitos usando linguagem natual
- Documentar Requisitos usando modelos
- Validar e acordar requisitos
- Gerenciar requisitos


Mais informações em:
http://www.abramti.org.br/faq-page#t2n108

quarta-feira, 18 de setembro de 2013

Verificação x Validação

• Verificação
– Estamos fazendo corretamente o software?
– Aderência aos requisitos especificados

• Validação
– Estamos fazendo o software correto?
– Aderência aos requisitos desejados do usuário

segunda-feira, 9 de setembro de 2013

Ao que se deve ficar atento o planejamento dos testes

  • Certifique-se de que os planos do teste não se limitam ao teste funcional. Todos os tipos de teste devem ser levados em consideração no plano de testes e assim agendados.
  • Revise as estimativas de teste e certifique-se de que há tempo suficiente para a obtenção e a validação do ambiente de teste;
  • Faça plano para o teste de configurações. Se vários tipos de processadores, sistemas operacionais, máquinas virtuais, navegadores e diversos periféricos puderem ser combinados em muitas possíveis configurações, faça planos para aplicar as técnicas de teste que proporcionarão uma cobertura adequada a tais combinações;
  • Faça planos para testar a documentação. Os usuários recebem o software com a documentação.
  • Reserve tempo para verificar a documentação e pode ter que trabalhar com a equipe de redação técnica a fim de preparar os dados que serão utilizados em capturas de tela e videoclipes;
  • Faça planos para testar os procedimentos de instalação. Os procedimentos de instalação, de back-up e de restauração devem ser testados o bastante. Tais procedimentos podem ser mais importantes do que o próprio software. Se o software não puder ser instalado, não será nem sequer utilizado.
  • Faça planos para que o teste se adapte ao ciclo de vida do software. A execução sequencial de tarefas não combina com a maioria dos cronogramas. Frequentemente, muitas tarefas precisam ser realizadas ao mesmo tempo;
  • Reserve tempo para testes de confirmação e regressão;

Adaptado do Syllabus CTAL-TA

segunda-feira, 2 de setembro de 2013

Software Seguro

A McAfee disponibilizou um pdf ( http://goo.gl/MAaDZD ) com exemplos práticos dos 5 erros mais comuns:
- SQL Injection 
- Broken Access Control
- XSS – Cross Site Scripting
- Error Generation
- Crypto Wannabe

Para que você não saia por ai fazendo coisa errada, a McAfee também disponibiliza uma aplicação gratuita para você praticar:
http://www.mcafee.com/br/downloads/free-tools/hacmebooks.aspx

terça-feira, 6 de agosto de 2013

Os 7 hábitos dos Testadores Altamente Eficazes

Mais uma da série "Leitura Obrigatória":, desta vez com o Cristiano Caetano

http://www.linhadecodigo.com.br/artigo/1083/os-7-habitos-dos-testadores-altamente-eficazes.aspx

terça-feira, 16 de abril de 2013

Qual o time dos Tester em um contexto ágil?

Pertencem ao Time do cliente?

A equipe de clientes inclui especialistas em negócios, proprietários de produtos, especialistas em domínio,gerentes de produto, analistas de negócios, todoas especilistas no lado  "negócio"  um projeto.

A equipe do cliente escreve as histórias ou conjuntos de recursos para a equipe de desenvolvedores. Eles fornecem os exemplos
que irão  conduzir o time na implementação da história.

Eles se comunicam e colaboram com a equipe de desenvolvedores ao longo de cada iteração, respondendo perguntas e revisando as histórias que ainda não foram finalizadas.

Ou ao Time dos desenvolvedores?

Todos os envolvidos com o código de entrega é um desenvolvedor, e é parte do time do  desenvolvedor.

Princípios ágeis incentivam os membros da equipe para assumir múltiplas atividades; qualquer membro da equipe pode assumir qualquer tipo de tarefa.
Muitos profissionais ágeis desencorajam funções especializadase incentivam todos os membros da equipe a transferir suas habilidades para os outros tanto quanto for possível.

No entanto, cada equipe precisa decidir o que seus projetos exigem de experiência: programadores, administradores de sistemas, arquitetos, administradores de banco de dados, escritores técnicos, especialistas em segurança, e as pessoas que usam mais de um destes chapéus podem ser parte da equipe, fisicamente ou virtualmente.

Ambos!

Testers são membros do time do cliente ajudando a levantar requerimentos, exemplos e ajudando o cliente a expressar seu requerimento de uma forma onde será possível valida-lo (testa-lo)

Testers também são parte do time de desenvolvedores pois teste é um componente central para o desenvolvimento ágil.Tester são como advogados da qulidade exigindo sempre que o time de desenvolvimento entregue o máximo de valor ao produto.

domingo, 31 de março de 2013

Itens do plano de teste



        Identificador do Plano de Teste;
        Introdução;
        Itens de teste;
        Features a serem testadas;
        Features a não serem testadas;
        Abordagem do teste;
        Critérios de liberação/falha dos itens;
        Requisitos de suspensão e retomada;
        Entregas do teste;
        Tarefas do teste;
        Necessidades de ambientes;
        Responsabilidades;
        Necessidades de equipe e de treinamento;
        Cronograma;
        Riscos;
        Aprovações.

sábado, 23 de fevereiro de 2013

Pra que serve o plano de teste?


O Plano de Teste, documento básico gerado através da etapa de planejamento, serve como escopo de referência durante a execução do teste e também serve como documento de comunicação junto ao cliente que contratou o serviço de teste.

Estratégia de Teste está contida no Plano de Teste!