Importando casos de teste para o Quality Center

Essa semana fiz essa atividade no trabalho e resolvi gerar um post para ajudar com alguns “pequenos detalhes” que não são mencionados no User Guide oficial e que podem fazer a diferença entre um trabalho tranqüilo e um trabalho estressante. :)


Quality Center

Primeiro pra quem não conhece, o HP Quality Center é uma ferramenta de gerenciamento de defeitos que controla releases, ciclos, criação de testes, planejamento, gerenciamento de execução, gerenciamento de defeitos, provê relatórios, dashboards,... É uma ferramenta de testes bem completa.

É uma ferramenta proprietária da HP. É possível, entretanto baixar uma versão demo no site da HP.

Demo HP Quality Center


Excel Add-In

Para importar seus casos de teste do Excel para o Quality Center é necessário:

- que os seus testes estejam formatados de acordo com os campos do Quality Center.
- que você tenha instalado na sua máquina o Add-In do Excel.

Você pode acessar página de Add-ins do Quality Center ou na página inicial do Quality Center, antes da autenticação, ou caso já esteja dentro da aplicação, através do menu Help > Add-ins Page.

Se a opção Microsoft Office Add-ins não estiver disponível, clique em More Quality Center Add-ins e a opção deve ser exibida. Instale o Add-in do Excel. Após a instalação, no Excel, será possível perceber uma nova aba chamada Add-Ins e o botão Export To Quality Center.

Formatando o teste no excel

De início vamos conhecer a estrutura de testes do Quality Center. Essa ferramenta é personalizável e pode ser que a tela exibida abaixo não seja exatamente igual a que você costuma usar, mas nada que impacte a continuação da leitura desse post. :)

Dica1: Se os campos obrigatórios padrão do Quality Center são correspondem às informações que você já tem nos seus testes, personalize esses campos.

Esses são os campos obrigatórios padrão do Quality Center:

-Subject (perceba que para criar o teste eu tive que escolher primeiro a pasta na qual ele seria inserido)
-Test Name
-Level
-Priority
-Reviewed

Reforço que é possível alterar os campos que são obrigatórios pelo módulo Administrador da ferramenta. Mas vamos trabalhar com o padrão mesmo.

Claro que há várias outras informações que precisamos para completar um caso de teste, mas já é possível fazer a importação só com esses.

Normalmente você teria ainda no seu caso de teste a descrição do caso de teste e os passos a serem executados com ações e resultados esperados. Segue então um caso de teste fictício com esses atributos:

Dica2: Todos os valores tratados como lista no Quality Center precisam estar no Excel exatamente da mesma que estão no QC. Por isso, aconselho a criar um template para os testes utilizando listas também.


Dica3: Para separar hierarquicamente as pastas, utilize “\”. Não há outro separador válido. Se você errar a descrição do subject vai ter que deletar manualmente a pasta no Quality Center após a importação.


Importando

Com o caso de teste pronto podemos começar a importação. No Excel, clique no botão Export To Quality Center na tab Add-in. Nos primeiros passos serão pedidas informações de autenticação no Quality Center com endereço do servidor, usuário, senha e projeto.

O Quality Center importa Testes, Requisitos e Defeitos. Após a autenticação, será requisitado que você informe o que está exportando. Selecione Tests.

Para que o Quality Center reconheça as informações no seu Excel, é necessário fazer um mapeamento das colunas com os campos do Excel (a não ser que você nomeie as colunas exatamente com o nome dos campos do Excel. Nesse caso é possível fazer uma conversão automática).

Para criar um mapa temporário, selecione Create a temporary map. Se você quer salvar o mapeamento para utilizá-lo novamente, selecione Type a new map name e insira um nome para o seu mapa. Posteriormente será possível selecioná-lo em Select a map. Para seguir esse post, aconselho que seja salvado um mapa, vamos precisar refazê-lo depois. :)

No próximo passo, vamos relacionar os campos do Quality Center com as colunas do Excel. No caso do teste que eu criei o resultado foi:

Subject – A
Test Name – B
Description – C
Level – D
Priority – E
Reviewed – F
Step Name (Design Steps) – G
Description (Design Steps) – H
Expected (Design Steps) – I

Depois disso, cruze os dedos e clique em Export.

Se você criou o seu teste como especificado aqui nesse post, você acaba de receber uma feliz tela de Sucesso. Mas não se iluda!! :) Vamos olhar no Quality Center o que aconteceu.

Parece que deu tudo certo. Vamos ver os passos:

E essa é a maior causa de dores de cabeça na importação de testes pro Quality Center. Onde estão os outros passos? No User Guide você vai encontrar uma instrução dizendo que os passos são identificados como sendo daquele teste se você informar para todos os passos o Subject e o Test Name, assim, o Quality Center faria essa relação. Bem, é quase isso.

Dica4: Replique para todas as linhas do seu teste TODOS OS CAMPOS OBRIGATÓRIOS, não somente o Subject e o Test Name. Se você não replicá-los, na hora da exportação o Excel vai dar um erro dizendo que os campos obrigatórios não estão preenchidos.

Não vou pedir para que façam a exportação novamente agora porque não é um post de teste de paciência, é um post para ajudar a pular alguns passos dessas descobertas. :)

Mesmo aplicando a dica 4 o caso de teste ainda vai chegar no Quality Center com apenas um passo a não ser que...

Dica5: Selecione todas as células do teste para exportá-lo.

MAS........

Dica5.1: Selecione todas as CÉLULAS mesmo. Não adianta selecionar a coluna inteira que o programa vai reclamar igual. :)

Ok. Vamos tentar novamente. Dessa vez selecione o mapa que você salvou anteriormente, ao invés de criar um novo.

E o resultado...

E para finalizar...

Dica6: Perceba que ao exportar um teste com o mesmo Subject e o mesmo Test Name de um existente, o teste existente será sobrescrito.

Análise de Valor Limite

Essa técnica é um refinamento da técnica Partição por Equivalência abordada anteriormente. Se você não conhece ainda a técnica recomendo fortemente a leitura dela antes de prosseguir.

Quando falamos em selecionar valores dentro de uma partição para realizar o teste, você pode ter pensado que há valores mais interessantes que outros de serem selecionados. Está certíssimo. Há mesmo. Um exemplo deles são os valores limite dessa partição.

Para determinar valores limite é preciso que estejamos tratando de uma partição com elementos ordenáveis, onde eu possa dizer que o elemento A é maior que o elemento B.


Exemplos de aplicações viáveis de valores limite:

- tamanho de fonte de um texto

- idade de uma pessoa

Exemplos de aplicações inviáveis de valores limite podem ser os que utilizados no post sobre Partição por Equivalência:

- cidades atendidas em um sistema de venda com entregas

- tipo de contrato, tipo de foto


Um valor limite é um membro de uma partição a partir do qual se espera uma mudança de comportamento. Por exemplo, alguns conteúdos na internet são considerados impróprios para menores de 18 anos. Ou seja, se você indica sua idade como um número menor que 18, a aplicação deve ter um comportamento, e se você indica sua idade como 18 ou mais, a aplicação deve ter outro comportamento.

Igual à técnica de Partição por Equivalência, cada valor limite inválido ou válido, deve ser representado em ao menos um caso de teste. No caso de Análise de Valor Limite, geraremos pelo menos duas vezes mais testes do que na técnica de Partição por Equivalência. Isso porque teremos pelo menos dois valores limites para cada partição.

Por que iríamos querer gerar mais casos de teste então? A Partição por Equivalência valida os membros de grupos de valores que levam a determinadas respostas da aplicação. A Análise de Valor Limite, por sua vez, verifica se o espaço delimitado entre uma partição e outra está correto.

EXEMPLO DE ANÁLISE DE VALOR LIMITE

Já tentou explorar qual o limite para a fonte no Word? Esse aplicativo aceita apenas tamanhos entre 1 e 1638. Se você tentar entrar valores maiores que 1638 ou menores que 1, na fonte Calibri, deve ser exibida essa mensagem:

Há diversos testes que podemos realizar nessa funcionalidade de troca de fonte. Abaixo, algumas sugestões. Se você pensar em outras, por favor, compartilhe no espaço de comentários.

- Testar a entrada de tamanho de fonte pelo combobox com um valor intermediário qualquer

- Testar a entrada de tamanho de fonte pelo combobox com o valor mínimo exibido

- Testar a entrada de tamanho de fonte pelo combobox com o valor máximo exibido

- Testar a entrada de tamanho de fonte pelo campo livre com o valor mínimo

- Testar a entrada de tamanho de fonte pelo campo livre com o valor máximo

- Testar a entrada de tamanho de fonte pelo campo livre com o valor mínimo -1

- Testar a entrada de tamanho de fonte pelo campo livre com o valor máximo +1

- Testar a entrada de tamanho de fonte pelo campo livre com um número bem menor que 1
- Testar a entrada de tamanho de fonte pelo campo livre com um número bem maior que 1638
- Testar a entrada de tamanho de fonte pelo campo livre com letras
- Testar a entrada de tamanho de fonte pelo campo livre com caracteres especiais (que não são letras ou números)
- Testar a entrada de tamanho de fonte pelo campo livre com Números Racionais
- Testar a entrada de tamanho de fonte pelo campo livre com uma operação
- Testar a entrada de tamanho de fonte pelo campo livre com números negativos

Veja que a abertura para o usuário do valor a ser entrado aumentou bastante nossas possibilidades. Para melhor testabilidade da aplicação, o ideal seria que a seleção pelo combobox fosse a única opção para entrar fontes. No caso do combobox, perceba também que não há testes inválidos a serem realizados.

Os testes marcados representam as melhores caracterizações dos testes válidos dentro da Análise de Valor Limite. Quanto evoluir na investida em testes inválidos? Depende do risco associado. Anteriormente à aplicação dessas técnicas, a aplicação de uma Análise de Risco pode determinar o quanto vale a pena criar testes para testar exaustivamente essa funcionalidade ou não.


EXEMPLO DE APLICAÇÃO INVÁLIDA DE VALOR LIMITE

Em algumas situações, a ordenação visual pode levar à falsa idéia de que há valores limite. Por exemplo, um menu.

Apesar de aparentemente ordenados, a ordenação utilizada não nos fornece nenhuma idéia de valores limite. Não faria sentido. Nesse caso, cada menu deve ser testado individualmente, representando cada um deles sua própria classe de equivalência.

A opção de valor inválido seria, caso haja algum menu que devesse estar desativado, verificar se o design é alterado para indicar isso e se ao clicar nesse menu ele realmente não executa nenhuma operação. Mas não há Análise de Valor Limite a ser feita.


E ENTÃO, PARECE FÁCIL?
A Análise por Valor Limite pode parecer fácil utilizando valores inteiros, mas quando tratamos da validação de Números Reais, pode ficar bem mais complicado.

Já um pouco mais difícil que o tamanho de fontes do Word, seria testar os limites de uma Calculadora, seja o aplicativo do Windows ou para complicar ainda mais, uma calculadora financeira ou científica ou gráfica.

Entendida a técnica, serão necessárias algumas vezes a aplicação de outros conhecimentos para conseguir identificar valores limite para os testes. Claro que uma especificação sempre ajuda.

Fonte: Advanced Software Testing vol.1 – Rex Black


Ver também:
Overview Tipos de Técnicas de Teste
Partição por Equivalência

Partição por Equivalência

TÉCNICAS DE TESTE DE SOFTWARE

A cada nova técnica apresentada, vou sempre bater na mesma tecla: Seria muito bom que pudessemos testar todas as combinações possíveis de valores durante os nossos testes. Talvez isso nos desse mais segurança de que realmente testamos 100% o software e que ele está 100% funcional de acordo com as especificações e expectativas do cliente. Sabemos entretanto que para a esmagadora maioria de casos que conhecemos, é impossível testar 100% um software.

As tecnicas de software existem para melhorar a nossa seleção de testes. Para classificar e agrupar possibilidades de teste que otmizem o nosso processo, sem que tenhamos a sensação de estar deixando buracos imensos sem cobertura de testes nos sistemas.


PARTIÇÃO POR EQUIVALÊNCIA

Partição por Equivalência é uma técnica de projeto de teste do tipo “Specification-based”, na qual os testes são projetados para executar partes representativas de partições. E a princípio, espera-se que ao menos uma classe de cada partição seja representada ao menos uma vez durante os testes.

A figura acima explica visualmente a definição dada.

Começamos selecionando um set de interesse, como entradas, saídas, precondições, pós condições de teste ou qualquer outra coisa que achemos interessante. Feito isso, podemos separar esse set em dois ou mais sub conjuntos. Por exemplo: Imaginemos um sistema de venda que vai calcular o frete baseado na regra:
- Norte = 40,00
- Nordeste = 35,00
- Centro-Oeste = 35,00
- Sudeste (fora SP/capital) = 20,00
- SP capital = 10,00
- Sul = 35,00

Essas serão então nossas classes de teste: Norte, Nordeste, CO, Sudeste (menos SP capital), SP capital, Sul.

Fora as classes válidas, também devemos criar classes inválidas, ou seja, opções que levem a aplicação a pedir uma ação de correção por parte do usuário ou trate como uma exceção. Nesse caso, uma cidade fora do Brasil levaria provavelmente a uma mensagem informando ao usuário que não são realizadas entregas fora do território brasileiro e perguntando se ele deseja continuar com a compra informando um outro endereço válido.

A segunda parte da figura, mostra como ocorre a seleção de elementos das classes para criação dos testes. Cada teste deve ter ao menos um elemento de uma classe.

Considerando um formulário, ou mesmo o sistema de vendas mencionado acima, concluiremos que haverão N conjuntos e sub conjuntos de valores para tratarmos. Para criar um test case válido, separamos então membros das classe de equivalencia válida e para um test case inválido, separemos UM membro de UMA classe inválida e todos os demais valores selecionados devem ser válidos. Dessa forma, evitaremos que uma resposta incorreta a uma classe de equivalencia fique mascarada pelo tratamento de outra classe.


ERROS COMUNS NA APLICAÇÃO DE PARTIÇÕES POR EQUIVALÊNCIA

1. As partições devem ser distintas. Não deve ser possível que um elemento hora se comporte como na partição A e hora como na partição B.

2. Não existem partições vazias. Se ela não possui membros, ela não existe.

3. A técnica não subtrai valores. Ela os divide.


CRIANDO TESTES A PARTIR DA TÉCNICA

Supondo que os subsets X1, X2, Y1, Y2 e Y3 são complemente independentes e válidos, podemos combina-los em três testes, como mostra a figura acima. O caso, a condição X1 foi testada duas vezes. Poderia ter sido tanto ela quanto a X2. Por exemplo, poderíamos testar a solicitação de um serviço em uma empresa de computadores. Poderiamos ter então as condições de contrato dentro ou fora da garantia (ambos os casos são válidos, mas um cobra pelo serviço e o outro não), e a localidade do comprador para definir que prestador de serviço irá atendê-lo que pode ser Porto Alegre, Grande Porto Alegre ou Outras cidades do RS. São variáveis independentes entre si que podem ser combinadas como na imagem acima resultado nos testes:

TC1: Contrato Dentro da Garantia para Porto Alegre
TC2: Contrato Fora da Garantia para Grande Porto Alegre
TC3: Contrato Dentro da Garantia para Outras Cidades do RS

Nem sempre as nossas combinações serão apenas de valores de valores independentes entre si. Um valor pode ser restritivo em relação a outro subset, gerando combinações inválidas.

Agora a seguinte situação. Temos um sistema de impressão de imagens. X é a paleta de cores dela. X1 = normal, X2 = escala de cinza , X3 = sepia (aquelas amareladas). Y é a qualidade que nesse caso pode ser Y1 = para impressão, Y2 = para web. Z é a impressora utilizada, sendo Z1 = preto e branco e Z2 = colorida

Os TCS criados para exemplo foram:
TC1: Foto colorida com resolução para impressão na impressora colorida
TC2: Foto preta e branca com resolução para web na impressora preto e branco
TC3: Foto sepia com resolução para impressão na impressora colorida
TC4: Foto colorida (ou sepia) com resolução para web na impressora preto e branco

O último caso deve ser inválido de acordo com regras da aplicação que não permitirá a impressão de fotos coloridas em uma impressora preto e branco.

Devemos começar com pelo menos 1 caso de teste inválido por set para verificarmos que cada conjunto é validado como deveria. Feito isso, você pode testar combinações de inválidos se for o caso. Mas lembre-se da importância de testa-los primeiro em separado para identificar o comportamento específico para o conjunto.

Fonte: Advanced Software Testing Vol.1 - Rex Black

Ver também:
Overview Tipos de Técnicas de Teste
Análise por Valor Limite

Webinar da RBCS: Risk Based Testing

Ontem participei do Webinar sobre Risk Based Testing da RBCS. Discutimos questões como aplicação de RBT em diferentes ciclos de vida, RBT como guia para testes exploratórios e RBT andando junto com a documentação de requisitos. Essas questões só vou responder no final :) Pode dar alguns page downs e verificar as respostas do Rex Black para elas, ou acompanhar o texto que tem algumas referencias bem interessantes.

Segue um pouco do que foi visto no seminário com duração de 1:30 (início 23:30 – fim 01:00)


INTRODUÇÃO

Um sistema nem precisa ser tão complexo para ter infinitas possibilidades de teste. Sistemas complexos poderiam levar uma eternidade para serem testados com uma cobetura de 100%. Dentro das infinitas possibilidades, é preciso escolher um número finito e alcançável de testes, e considerando que não vamos testar tudo, precisamos ser bastante criteriosos na escolha do que testar.

RBT (RISK BASED TESTING)

Risco é a possibilidade de uma coisa ruim/negativa acontecer. A possibilidade de algo bom acontecer é vista como uma oportunidade.

Riscos de qualidade referem-se à possibilidade de algo falhar no sistema afetando sua habilidade em alcançar o nível desejado de operacionalidade e satisfação do cliente.

RBT se utiliza da análise desses riscos de qualidade para alocar e distribuir esforço de teste da maneira mais eficiente possível. Essa análise envolve stakeholders técnicos e de negócio. Quanto mais for explorada a diversidade de conhecimento dentro do projeto, melhor será o resultado da análise.

Riscos de qualidade estão relacionados com o produto: um calculo que falha, baixa performance. São itens que ameaçam a satisfação do cliente ou a rentabilidade da empresa. Riscos de projeto estão relacionados com o andamento do projeto como redução de recursos para o projeto, atrasos de cronograma, falta de ambiente de testes, ou seja, ameaças à condução do projeto como inicialmente planejado.

Devemos acompanhar também os riscos de projeto, mas aqueles que tem relação direta com o que vamos testar são os riscos de qualidade.

BENEFICIOS DE RBT

• Execução dos testes por ordem de risco provê maior probabilidade de descobrir bugs também em ordem de severidade (“find the scary stuff first”). Uma coisa comum em alguns projetos é ver os testadores começarem pelos testes “mais fáceis”, ou “mais rápidos” que não necessariamente levam a descoberta dos bugs mais importantes. 
• Alocar esforço em teste com base em riscos é a maneira mais eficiênte de eliminar riscos residuais no release (“pick the right tests out of the infinite cloud of possible tests”). Mesmo que hajam problemas no projeto que limitem a execução dos testes posteriormente, os piores bugs já foram descobertos no início. O que passar no release não terá um impacto tão alto quanto o que ja foi descoberto e corrigido. 
• Medir os resultados baseado nos riscos permite à organização tomar decisões mais inteligentes sobre o release da aplicação (“release when risk of delay balances risk of dissatisfaction”) . Falar sobre qualidade não é fácil. Como medir qualidade? Como ter idéia de risco associado a atrasos? 
• Se o cronograma apertar, retirar testes de acordo com o inverso do risco reduz o periodo de testes aumentando o minímo possível dos riscos de qualidade (“give up the tests you worry about the least”). E os cronogramas sempre apertam :) 

ESTUDO DE CASO: CA

A CA é um dos clientes da RBCS e juntos eles realizaram diversos projetos implementando RBT. Durante o seminário, RB falou sobre um dos pilotos aplicados nessa empresa.

O Podcast dessa sessão ainda não está disponível hoje, mas é possível assistir um vídeo de uma outra apresentação que ele fez em Melbourne, Australia, sobre o caso na RBCS Digital Library.

O piloto consistiu nas atividades:

• Treinamento dos stakeholders chave em RBT 
• Realizar uma sessão de análise de riscos 
• Analisar e refinar a análise de riscos 
• Alinhar os testes com os riscos de qualidade 
• Guiar os testes baseando-se em riscos 
• Demonstrar benefícios e aprendizados

TREINAMENTO

O treinamento realizado através de uma apresentação, discussões e exercícios cobriu:

• Os principios de RBT 
• Categorias de riscos de qualidade (Sugiro dar uma olhada na lista de riscos de qualidade proposta pelo RB. Há uma adaptação do Managing the Testing Process, Second Edition na biblioteca da RBCS) 
• Análise de riscos de qualidade 
• Alinhando testes com níveis de riscos 
• Documentando riscos de qualidade 
• Monitorando riscos de qualidade durante execução de testes 
• Reportando resultados de testes baseados em riscos

Dessa sessão, já foi possível sair com uma lista de riscos de qualidade para serem trabalhados. É importante dar um tempo aos participantes para assimilarem esses conceitos e descansar um pouco antes de continuar com as atividades. Não é bom que os próximos passos sejam afetados por fatores como fadiga.


COMO LEVANTAR RISCOS DE QUALIDADE?

Uma maneira é fazendo entrevistas individuais com os stakeholders e depois criar uma listagem única para validar com todos. Outra maneira é realizar uma sessão de brainstorm que pode ser um pouco mais complicada de arranjar devido a questões de alocação do time, mas pode ser mais produtiva. Se tiver um quadro branco para explorar, use-o. Fica bem mais fácil quando os participantes podem ter uma visão do todo e refletir emcima dos riscos ja levantados também.

COMO DEFINIR NÍVEIS DE RISCOS?

Depois de levantados os riscos, serão atribuidos números de prioridade para esses riscos. Esse número (RPN – Risk Priority Number) é calculado multiplicando a probabilidade (likelihood) do risco pelo impacto que causará se for descoberto apenas após o release.

É necessário definir uma escala tanto para o impacto quanto para a probabilidade. RB sugeriu uma escala de 5, ou seja, o RPN varia de 1 a 25, sendo 1 os riscos mais altos e 25 os mais baixos.

AVALIANDO A DEFINIÇÃO DE NÍVEIS COM HISTOGRAMAS

Falei acima da fadiga como um item que pode impactar a análise. Fora ela, vários outros, inclusive uma tendência pela discussão levantada durante a reunião de atribuição de níveis, podem impactar na avaliação dos níveis dos riscos.

Ao final da primeira reunião, nesse projeto, o time alcançou o seguinte historgrama:

Na coordenada x, os níveis de risco e na coordenada y, a quantidade de riscos no nível x.

Perceba que há muitos riscos classificados como 6. Está saindo bastante da curva esperada. Claro, não necessariamente o comportamento do gráfico final será 100% na curva, mas ao menos podemos alcançar um resultado mais condizente.

Analisando os dados que levaram a construção desse histograma, foram apresentados os seguintes valores:

Probabilidade - Qtd

1 – 5
2 – 9
3 – 25
4 – 39
5 – 26

Por se tratar de um sistema de manutenção, esses números parecem aceitáveis. Em sistemas novos, o número de riscos nos primeiros níveis provavelmente seria maior.

Impacto - Qtd

1 – 10
2 – 52
3 – 32
4 – 8
5 – 2

Agora sim achamos um problema. Houve uma tendência muito forte a indicar o nível 2 de impacto. Pode ter ocorrido um desvio de análise dos stakeholders durante a reunião devido a influências de discussões. As vezes por alguem ter levantado um issue classificado com um alto impacto, um outro participante fez associações similares levando a um aumento significativo nesse nível.

Para corrigir esse desnível, foi realizada uma reformulação dos conceitos do que é nível 1, 2 e 3 para reavaliação de impacto e foi alcançado o seguinte gráfico:

ALINHANDO TESTES COM RISCOS DE QUALIDADE

Feita a análise dos riscos, é hora de alinhá-los com os testes. É possível construir a seguinte rastreabilidade:

• Riscos de qualidade x Itens de especificação (requisitos, design, o que houver) 
• Riscos de qualidade x Casos de Teste 

Também é hora de avaliar e alocar (ou realocar) o esforço de teste baseando-se nos riscos e priorizar os testes a serem executados.

ALOCAÇÃO DE ESFORÇO

RB na sua apresentação sugeriu a seguinte aplicação de esforço em teste de acordo com o RPN.

• 1-12 Extensivamente
  
  Executar um grande número de testes de forma abrangente e profunda, exercitando diversas combinações e variações de condições
• 13-16 Abrangentemente
  
  Executar um número médio de testes que exercitem várias condições diferentes
• 17-20 Rapidamente
  
  Executar um pequeno número de testes que sirvam como amostra para as condições mais interessantes
• 21-25 Oportunamente
  
  Reserve um tempo para executar uma ou outra condição, mas apenas se levar pouco tempo. 

CONCLUSÃO: BENEFICIOS E PONTOS CHAVE

O projeto piloto teve os seguintes benefícios:

• Alocação inteligente dentro das restrições 
• Bugs prioritários descobertos primeiro, otimizando a janela para correção de bugs 
• Flexibilidade na redução de tempo e recursos 
• Otimização da qualidade dentro das restrições do teste focado 

Pontos chave

• Inclusão dos usuarios de negócio e mesmo clientes em potencial na análise
• Início da análise no início do ciclo de vida

PERGUNTAS E RESPOSTAS (com adições de comentários meus)

. Como se dá a aplicação de RBT nos diferentes ciclos de vida?

No caso do modelo incremental, a primeira análise de risco fica como um draft. Periodicamente (pode ser, por exemplo, a cada aprovação de documento) o analista insere novas informações e o resultado da análise dessas novas informações ao seu planejamento.

No modelo iterativo, a análise se dá por iterações. A cada iteração é feita uma análise de acordo com o escopo. É bem menos esforço do que fazer tudo de uma vez.

No modelo ágil, a análise pode ser feita sempre no início de uma sprint.

. Há desvantagens na aplicação de RBT?

A idéia da aplicação de RBT não é ser um processo oneroso. Muito pelo contrário. Não é um processo que demande tanto esforço. O processo de Failure Mode and Effect Analysis é muitas vezes mais demorado. É possível entretanto, burocratizar demasiadamente o processo com o preenchimento de pilhas e pilhas de planilhas. Se o processo é muito burocratizado não cumpre um de seus objetivos que é otimização de esforço.

Também há casos, especialmente quando se trata de outsourcing, nos quais o cliente define exatamente o set a ser testado, sem precisar de uma análise prévia. No máximo a equipe pode perguntar ao cliente se há uma ordem preferencial para execução dos testes, que podem inclusive já estar prontos. Talvez o próprio cliente já tenha feito essa análise de riscos antes.

A falta de tempo para preparar a análise não é uma desculpa tão acetável, já no caso que o RB apresentou, por exemplo, os testes foram escritos concomitantemente à execução.

RBT não é perda de tempo. Ao contrário, é uma optimização e melhor direcionamento de esforço.

. Como aplicar RBT se estamos caminhando lado a lado com a escrita de requisitos e não temos todos eles definidos ainda?

Para aplicar RBT você pode ou não ter um documento de requisitos como guia. Se você não tiver o documento, contará com a visão compartilhada dos stakeholders do que é o projeto, do que ele deve atingir. Talvez essa visão seja ainda melhor que seguir fielmente um documento de requisitos.

Quando baseamos a criação de test cases em requisitos, podemos testar errado se os requisitos estiverem errados, ou deixar gaps nos nossos testes devido a gaps na documentação. Requisitos também não nos ajudam a alocar esforço ou definir prioridades. Dificilmente eles estão classificados corretamente em termos de impacto. Requisitos também não vão nos ajudar a fazer uma triagem de casos de teste.

Então, a aplicação de RBT pode acontecer independentemente da definição do documen to de requisitos.

. É possível agrupar logicamente os riscos para alcançar maior eficiência nos testes?

Sim. Muitas vezes temos uma ordem ideal para executar um caso de teste. Mas é preciso tomar cuidado com esse projeto para não incorrermos no desperdício de tempo testando riscos de menor proporção mais vezes devido a esse link com riscos de maior proporção.

Também é necessário ter em mente que aplicar uma ordem de execução muito rígida com relação aos riscos pode acobertar erros nas áreas que definimos como riscos de menor proporção. O ideal é fazer um mix de áreas testando exaustivamente os riscos maiores e minimamente (mas sem deixar de testar) os riscos de menores proporções.

. Podemos guiar testes exploratórios com base na análise de riscos indicando áreas de maior risco para os testadores verificarem?

Na verdade o diferencial dos testes exploratórios são o conhecimento, a intuição, o julgamento e a experiência do testador. Se moldarmos isso, estaremos perdendo o pontecial dos testes exploratórios, então não é bom fazer isso.

Esse tipo de testes acontecendo em paralelo aos testes baseados na análise de risco podem trazer benefícios como a descoberta de um número elevado de bugs em áreas consideradas de baixo risco, ou o contrário, poucos bugs onde se esperava encontrar mais, ou ainda a mesma fórmula para imapcto: bugs de alto impacto onde se esperava serem de baixo, e bugs de baixo impacto onde se esperava encontrar de alto impacto. Ainda há a possibilidade de alguns riscos de qualidade não terem sido previstos. Tudo isso leva a uma análise da própria análise. Esse tipo de teste pode revelar problemas e sugerir um replanejamento.

Webinars RBCS

A RBCS realiza um Webinar aberto por mês onde qualquer um pode se registrar e participar. Cada sessão consiste em uma apresentação e um espaço final para perguntas. Há dois horários para escolher de qual participar.

Os próximos Webinars serão falando sobre técnias de testes. Confiram a agenda completa.

RBT na biblioteca da RBCS

Há várias referencias sobre RBT na biblioteca da RBCS. Muitos artigos e vídeos. É um verdadeiro arsenal para entender como aplicar RBT. Vale a pena conferir.

Em junho do ano passado eu postei um texto sobre o Teste no ciclo de vida de software. Quando a gente começa a estudar testes e procura amadurecer um pouco a idéia, esse é o primeiro questionamento que vem: Onde se encaixam os testes? Parece meio intuitivo que testar só ao final do projeto demanda muito esforço e gera muitos problemas.

Recebi um email da STP com um artigo do Rich Hand,um dos diretores da STP, sobre o mesmo assunto. Examining the software development lifecycle. Recomendo a leitura e a reflexão proposta no fim. "Onde o teste se encaixa no ciclo de desenvolvimento de software na sua empresa?"

CInTEQ 2010

Nos dias 22 e 23 de Março / 2010 vai acontecer o CInTEQ, um congresso internacional sobre Teste e Qualidade de Software, no Caesar Business Faria Lima, em SP.


O evento vai contar com a participação de grandes nomes como Rex Black, Erik Van Veenendaal, Alessandro Collino e Dorothy Graham.

Fora as palestras, também haverão mini cursos de TMMi, Test Automation, CTAL, Agile Testing e IREB.

Mais informações: http://www.cinteq.org.br/

Mesa Redonda do DFTestes

Serviço de utilidade pública (ao menos para os profissionais de teste :) )

Se você ainda não assina a lista de discussão do grupo DFTestes, não sabe o que anda perdendo.

No dia 02 de novembro, por inciativa do Fabrício Campos, teve início no DFTestes uma série de discussões muito proveitosas sobre teste de software.

Durante uma semana inteira os participantes discutem os temas selecionados por eles mesmos em uma votação prévia. Ao final, o Fabrício faz um apanhado de tudo o que foi comentado e gera um post no blog dele com um resumo da mesa redonda.

Nas discussões tivemos o prazer de ver bons nomes que estavam com pouca participação no grupo reaparecerem e contribuirem muito com o conteúdo discutido no grupo, como José Correia, Jorge Diz e Anderson Bastos. Essa iniciativa esquentou mesmo o grupo e vale muito a pena conferir, não só quem está aprendendo, iniciando na área de testes, mas também quem já tem uma boa bagagem.

Seguem alguns resumos feitos pelo Fabrício do que rolou até agora e o link para inscrição no DFTestes. Se você tem dúvidas ou gostaria que algum assunto em especial, sugira um tema para discussão.

Post inicial: Primeira Mesa Redonda DFTestes
Mesas:

1. Testar é tão fácil, que até a minha mãe testaria!
2. Teste Ágil, como implementar?
3. Estimativa de Testes (APT)
4. Certificações, valem a pena?
5. MPT: Melhoria do Processo de Testes
6. Utilização de Processos Ágeis no Teste de Software (SCRUM, XP, TDD…)
7. Quando documentar não é preciso?
8. O Testador também necessita saber programar?
9. Testar sem documentação é possível?

E a 10a mesa está rolando na lista com o tema "Quando automatizar?".

Inscreva-se no grupo através do site do Yahoo ou mandando uma mensagem em branco para DFTestes-subscribe@yahoogrupos.com.br. E seja bem vindo ;)