Overview tipos de técnicas de testes

A figura abaixo mostra a taxonomia utilizada para estudo da CTAL.

A primeira distinção é entre teste estático e teste dinâmico. Testes estáticos compreendem os testes que não envolvem a execução de testes (rodar) e os testes dinâmicos são aqueles relacionados à execução dos testes.

Testes estáticos são as revisões e a análise estática. As revisões são realizadas por pessoas e análise estática é realizada através de ferramentas.

Testes dinâmicos são 5:

Caixa preta: é o teste baseado em especificações (ou comportamentos). O teste é realizado em cima da idéia de como o sistema deveria se comportar. Esses testes são divididos ainda em funcionais e não funcionais, seguindo a norma ISO 9126. Uma maneira de distingui-los é que os testes funcionais dizem o que o sistema deve fazer e os não funcionais dizem como.

Caixa branca: também chamados de testes estruturais. São realizados emcima de como o programa foi construido.

Baseado em experiência: baseado nas habilidades, intuições e experiências anteriores do testador.

Análise dinâmica: análise da aplicação enquanto ela está rodando através de ferramentas.

Baseado em defeitos: utilização do entendimento de defeitos como base para o projeto de testes.

Ao contrário do que pode sugerir a figura, esses testes não são exclusivos. É possível (e comum) utilizar mais de uma dessas técnicas. É necessário selecionar que tipos de teste se aplicam na sua estratégia e em que nível eles serão aplicados.

Os ATA e ATTA que aparecem nessa figura referem-se à especilidade do ISTQB em que a técnica é coberta. Os ATA são cobertos na prova de analista e os ATTA na prova de analista tecnico. Essa abordagem não necessariamente é a aplicada na sua empresa, é apenas uma divisão para estudos.

Nos próximos posts cobrirei algumas das técnicas desses tipos de teste.

Fonte: Advanced Software Testing Vol 1. - Rex Black


Ver também:
Partição por Equivalência
Análise por Valor Limite

A profissionalização do teste

(Artigo escrito para o GUTS-RS, publicado pela SUCESU-RS)

Quando o teste de software despontou, era apenas uma parte da Engenharia de Software. Após o UP (Unified Process), a disciplina começou a ter mais força e alcançar um lugar próprio na TI. Ainda hoje o conhecimento sólido dessa disciplina é restrito a poucos profissionais, e muitas vezes é tida como uma disciplina que não requer muito conhecimento técnico, ou que qualquer profissional sem um bom respaldo acadêmico e/ou treinamento adequado pode executar com maestria.

Poucas faculdades incluem no seu currículo uma disciplina dedicada a Teste de Software. Normalmente, quando é abordada, não compreende mais do que algumas aulas da disciplina de Engenharia de Software.

Esse cenário aos poucos vem mudando. Com a crescente demanda do mercado por profissionais que desejam seguir essa carreira, algumas faculdades têm incluído a disciplina no seu currículo e também têm surgido cursos de pós graduação na área. Essas iniciativas dão a base acadêmica que o profissional deveria ter para descobrir, ganhar interesse e ingressar na área. Até então, esse papel estava sendo desempenhado apenas por cursos de extensão/capacitação.

Antes mesmo dessas iniciativas acadêmicas, assim como em outras áreas de TI, surgiu a necessidade de criar uma maneira de atestar o conhecimento do profissional em Teste de Software. Começaram a surgir então as certificações. Todas elas com o objetivo de criar uma linguagem única e um guia de boas práticas a ser seguido pelos profissionais.

Algumas das instituições internacionais mais conhecidas que aplicam certificações em Teste de Software são ISTQB (2002) / BSTQB (2006), ISEB (~1980), QAI (1980), IIST (1966).

No Brasil, essa iniciativa veio por parte da ALATS (2002) que criou a CBTS (Certificação Brasileira de Teste de Software) após analisar as certificações internacionais e criar o seu próprio padrão.

Cada instituição possui a sua própria base de conhecimento para a aplicação desses exames. Em relação a processos, são bastante similares, mas podem gerar dúvidas quanto a algumas terminologias que nem sempre representam a mesma coisa.

Além das certificações, iniciativas de grupos de profissionais estão se tornando cada vez mais populares no Brasil. Há vários grandes grupos de discussão na web e grupos que promovem encontros com palestras.

Com o apoio da SUCESU-RS foi criado o Grupo de Usuários de Teste de Software do Rio Grande do Sul, integrando o time de GUs da instituição. Hoje o grupo conta com 213 usuários e encontros constantes que promovem o networking na área e a disseminação de conhecimento.

Esse tipo de iniciativa agrega bastante, ajundando a difundir a área e aprimorando o conhecimento dos profissionais de Teste de Software e de outras áreas que interagem com eles.

Há várias empresas no Brasil que valorizam o profissional de Teste de Software e entendem o seu papel no ciclo de desenvolvimento, mas ainda é muito pouco. A grande maioria ainda não entende o papel do profissional de teste, não tem um processo de contratação adequado para esses profissionais e até mesmo se negam a contratar um profissional especializado devido ao seu valor, para contratar pessoas sem experiência, sem treinamento, sem preparo algum.

Teste de Software é uma área que vem crescendo mediante essas iniciativas acadêmicas e profissionais, entretanto ainda é uma área que sofre preconceito, muitas vezes é tida como uma área que não demanda conhecimento técnico e que inclusive empresas que buscam profissionais de Teste de Software, não sabem exatamente o que estão buscando. O profissional de teste, na verdade, é um agente de mudanças, trabalhando na prevenção de defeitos e colaborando para a melhoria contínua das equipes e processos.

Essa é uma realidade que vem sendo transformada aos poucos e que conta com a sede de conhecimento de cada um para crescer ainda mais e firmar o seu lugar no ciclo de desenvolvimento de software.




Fontes:
Associação Latino-Americana de Testes
Brazilian Software Testing Qualification Board
International Software Testing Qualifications Board
Quality Assurance Institute Brasil
Information Systems Examination Board
International Institute for Software Testing

Gerenciamento de riscos

As principais atividades do gerenciamento de riscos são:

Identificação – identificar (ou as vezes imaginar) quais são/serão os riscos de projeto e de qualidade
Analise – classifica-los dentro de um nível, normalmente caracterizado por uma relação de impacto e probabilidade
Controle – abrange o conjunto de atividade de mitigação, contingência, transferência e aceitação de riscos

Um pouco mais de cada uma...:

IDENTIFICAÇÃO DE RISCOS

Como identificar riscos? Algumas sugestões:
-Entrevista com especialistas (na tecnologia e no negócio – pessoas diferentes, provavelmente)
-Checklists
-Analisar projetos similares já realizados
-Workshops, brainstorms

Pode ser interessante manter separadamente os riscos de projeto e os riscos de qualidade já que as pessoas que detém o conhecimento para elencá-los podem ser diferentes. O levantamento, entretanto pode ocorrer simultaneamente.

É possível detectar riscos estudando a documentação do projeto, nessa prática, essa revisão pode ajudar a encontrar erros na documentação.

As reuniões de identificação podem parar na detecção dos riscos, ou na própria reunião pode ser possível classificá-los ou mesmo detectar seu impacto. O acúmulo de atividades na reunião depende do andamento e produtividade dela.

ANÁLISE/AVALIAÇÃO DE RISCOS

Depois de identificá-los, deve ser feito um estudo emcima de cada risco categorizando-os e atribuindo-les um nível.

Sobre atribuir um nível, já foi mencionado que isso pode ser feito através da relação de impacto e probabilidade. Mas como definir isso? Probabilidade está normalmente relacionada a fatores técnicos e Impacto a fatores de negócio.

Exemplos de fatores técnicos:
-Complexidade da tecnologia
-Conhecimento do time
-Incompatibilidade de tecnologia legada com a aplicada
-Falta de quality assurance
-Ausência de testes em fases iniciais
E vários outros

Exemplos de fatores de negócio:
-Frequencia/Sazonalidade de uso de uma funcionalidade
-Possibilidade de sanções criminais
-Potenciais perdas de lucros
Entre outros

Pode-se atribuir o nível de risco quantitativamente ou qualitativamente. Quantitativamente pode-se considerar a probabilidade como um percentual e o impacto como um valor financeiro e assim teríamos exatamente o que representa o risco em números.

O mais comum é vermos essa atribuição qualitativamente, isso porque é difícil ter a base estatística necessária para pontuar quantitativamente. Qualitativamente os endereçaríamos como riscos de nível alto, médio ou baixo.

Sobre categoria, pode-se usar por exemplo as características descritas na ISO9126 (Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade, Portabilidade e suas sub caracteristicas). E pra que serve isso? No geral, para determinar os responsáveis (ou áreas responsáveis) pelos grupos de riscos. Isso, claro, se houver um motivo prático para categoriza-los.

MITIGAÇÃO/CONTROLE DE RISCOS

Os riscos podem ser controlados através das atividades de:
-Mitigação
-Contingência
-Transferência
-Aceitação

A mitigação consiste na definição de atividades que possam diminiur o impacto ou a probabilidade de um risco ocorrer.
A contigência é utilizada como uma ação caso o risco venha a ocorrer (quando um risco acontece, deixa de ser um risco, passa a ser um fato ou issue).
A tranferência consiste em transferir para outra parte o risco. E não interpretar isso como um jogo de culpas entre times. Nesse processo, no caso de uma empresa prestando serviço para um cliente, o risco pode ser assumido pelo cliente ao invés da empresa ou vice-versa, entre outras situações.

A abordagem analítica de teste baseado em riscos foca na criação de ações de mitigação, especialmente de riscos de qualidade, para o time de teste. O teste mitiga os riscos de qualidade durante todo o ciclo de desenvolvimento.

Alguns riscos de projeto também podem ser controlados, como:
Preparação adequada de ambiente de teste e ferramentas
Baixa qualidade de inputs para o teste
Falta de padrões, regras e tecnicas para o teste

Apesar de ser papel do gerente de controlar esses riscos, são riscos que afetam os analistas e estes devem controlá-los também.

Testes preventivos são parte da estratégica de testes baseados em riscos. A idéia é mitigar os riscos de qualidade antes mesmo da execução dos testes preparando bem o ambiente de testes, fazendo um pre teste antes de começar formalmente uma fase de testes, participando em reuniões e revisão/inspeção, monitorando o progresso e a qualidade do projeto, etc.

Oportunidades de aplicação de testes preventivos:
-Escolher a tecnica de testes adequada
-Realizar revisões e inspeções
-Revisar os projetos de teste
-Definir estratégias de testes de confirmação e regressão

Perceba que as atividades do teste preventivo não são as que comumente lembramos quando falamos de teste. Se os requisitos parecem não estar bem definidos, então o ideal é realizar revisões e inspeções, ao invés de postergar essas correções para a fase de testes.

Existem duas formas de priorizar os testes: depth-first ou breadth-first.

Depth-first: Todos os testes dos riscos mais altos são rodados primeiros e os riscos mais baixos por último.
Breadth-first: São selecionadas amostragens em todos os níveis de riscos, usando esses níveis para ponderar as seleções (são selecionados mais testes de níveis de risco mais alto, que de nivel mais baixo).

A melhor cobertura depende de uma análise do seu projeto.

E a famosa pergunta: quando parar de testar? Nessa abordagem a resposta é; Quando o risco residual for considerado aceitável.

Supondo que não tenhamos mais tempo para testar ou que o tempo foi reduzido e não será possível cumprir o planejamento inicial. Como realinhar a estratégia? Repriorizando os testes de acordo com os resultados obtidos. Mas exatamente o que olhar nesses resultados?
-Novos riscos de produtos
-Áreas muito modificadas
-Áreas instaveis descobertas durante os testes
-Riscos associados a defeitos
-Descoberta de bug clusters inesperados
-Descoberta de áreas críticas de negócio

Aproveite para atualizar o seu planejamento de riscos inicial.

IV EBTS

Já está aberto o prazo de submissão de artigos para o IV Encontro Brasileiro de Testes de Software em Recife/PE

Os interessados podem submeter seus trabalhos até o dia 29 de dezembro, em formato PDF, através do e-mail ebts@gotest.biz. Os artigos devem conter entre quatro e seis páginas e seguir o modelo da ACM SIG Proceedings, disponível gratuitamente no site www.acm.org/sigs/pubs/proceed/template.html.


Os artigos a serem submetidos ao IV EBTS devem oferecer um melhor entendimento sobre boas práticas de testes de software, além de se reportar a lições aprendidas, inovações e aplicações práticas. No dia 25 de janeiro, será divulgada a relação dos artigos aceitos. Os selecionados terão até o dia 15 de fevereiro para entregar a versão final e o material de apresentação a ser usado durante o evento.


O EBTS é um evento que visa promover o intercâmbio de idéias entre empresas e academia com o objetivo de estimular debates e discussões sobre testes de software, promovendo, assim, a troca de conhecimentos e a integração entre academia e o mercado.

O encontro acontecerá entre os dias 23 e 24 de abril e terá, em sua programação, palestras técnicas, mini-cursos, convidados renomados da área de testes, competições e premiações. A iniciativa é promovida pela GOTEST e conta com apoio do C.E.S.A.R e do Porto Digital.


Mais informações através do site http://www.gotest.biz/ebts2010/

Testes basedos em riscos

Uma introdução a testes baseados em riscos...

Risco é a possibilidade de um evento negativo ou indesejável ocorrer. Um risco específico é qualquer problema que possa afetar negativamente a experiência do usuário ou o sucesso do projeto.

Em testes há dois tipos de riscos com os quais nos preocupamos. Riscos de produtos são potencias problemas que podem afetar a qualidade do produto e Riscos de projeto (ou riscos de planejamento) são riscos que podem afetar o sucesso do projeto em termos de operações.

Exemplos:
Risco de produto: um defeito que possa causar pane no sistema
Risco de projeto: diminuição dos membros de projeto (staffing shortage)

Cada risco possui um nível de importância que é classificado de acordo com a sua probabilidade e seu impacto.

A probabilidade pode ser medida por exmeplo pela linguagem utilizada, pela banda de transmissão de dados, pelo espaço em disco, etc. O impacto é medido de acordo com considerações do negócio como perda financeira, número de usuários impactados, etc.

É interessante no início do projeto ter alinhado esses conceitos que tendem a ser muito subjetivos. Numerando os níveis de probabilidade e impacto, é indicado que todos tenham um entendimento ao menos bastante parecido do que eh nível 1, 2, etc. Simplesmente dizer que 1 é maior que 5 ou que 5 é maior que 1 nao é muito parâmetro. É indicado que essa explicação seja feita através de exemplos.

Em uma abordagem de testes baseadas em riscos, a listagem de riscos levantadas é o ponto mais importante do processo e também ponto de partida para o planejamento.

O risco pode guiar todas as atividades de teste. É possível alocar esforços por nível de risco, selecionar tecnicas de teste, direcionar ordem de execução e inclusive guiar a priorização de correção de testes baseado na classificação dos riscos levantados. Também os reports de execução podem ser direcionados a riscos informando que riscos foram cobertos, quais não foram, qual a incidência de erro neles, etc.

Os riscos precisam ter planos de mitigação e/ou contingência e quanto maior sua importãncia (probabilidade x impacto), mais de perto ele deve ser acompanhado. A reunião de levantamento/acompanhamento de riscos deve ser uma constante no projeto e não acontecer apenas uma vez no início. É importante saber se mudou a importância do risco, qual o resultado das ações de mitigação e inclusive se o risco continua sendo um risco ou se, devido a aplicação de ações de mitigação ou mesmo mudanças de cenário no decorrer do projeto, deixou de ser um risco. També novos riscos podem ser indentificados. Esse acompanhamento resulta em novas avaliações de prioridades no projeto e talvez em realocação de esforços de teste.

Pragas do Teste de Software

Em Junho o James Whittaker começou uma série de publicações entituladas The 7 Plagues of Software Testing (As 7 pragas do teste de software), baseadas em um encontro interno na Google em que ele falou sobre o tema. No GTAC (Google Test Automation Conference) ele abordou o mesmo assunto.


Achei muito interessante e resolvi fazer um post reunindo essas publicações que podem ser encontradas no blog do google. Quem se interessar em ver os artigos na íntegra, seguem os links na ordem de publicação:

The 7 Plagues of Software Testing
June 22, 2009

The plague of repetitiveness
June 24, 2009

The Plague of Amnesia
July 13, 2009

The Plague of Boredom
July 21, 2009

The Plague of Homelessness
July 23, 2009

The Plague of Blindness
July 29, 2009

The 7th Plague?
August 10, 2009

The 7th Plague and Beyond
September 02, 2009

The Plague of Entropy
September 14, 2009

A PRAGA DA FALTA DE PROPÓSITO

Whittaker fala sobre a falta de um pool de conhecimento comum, sobre estarmos sempre reinventando a roda que alguém, as vezes até mesmo dentro da nossa empresa, já inventou. Sobre a falta de compartilhamento de conhecimentos, a falta de objetivos.

Por que testamos? Já se fez essa pergunta? Sabe respondê-la? Muitas das respostas poderiam ser: “Porque meu gerente me disse pra testar”. E por que automatizar? Também muitas das respostas poderiam ser: “Porque eu sei programar”. Infelizmente não seria um concenso responder que isso faz parte de uma estratégia e mesmo do set dos que pensaram nisso como resposta, apenas uma parte saberia explicar essa estratégia.

Contrariando o slogan da Nike “just do it”, que funciona muito bem para execicios físicos, mas péssimamente mal para teste de software, Whittaker nos convida a parar, pensar e perguntar-se: “Qual o meu objetivo?”, “Qual o propósito desse teste?”

Documente seu sucesso, avalie seus fracassos e compartilhe o resultado da sua introspecção com seus colegas.



A PRAGA DA REPETIÇÃO

Se a falta de proposito é resultado do “just do it”, então a repetição é o “just do it” várias e várias vezes.

Nesse post Whittaker cita o paradoxido do pesticida de Boris Beizer’s. Pesticidas matam insetos (bugs ;) ), mas se usar sempre o mesmo veneno, os insetos que sobreviveram vão ficar imunes a ele. Em testes, se usarmos sempre as mesmas estratégias, os mesmos testes, teremos a falsa sensação de não ter bugs, mascarando métricas e resultados, onde na verdade o que ocorre é o efeito do noss teste não é mais tão abrangente.

Questione-se qual o valor que os seus testes estão agregando, varie, mude a ordem de execução, encontre variações de ambientes e dados aplicáveis e impeça a sua aplicação de ficar imune aos seus testes.


A PRAGA DA AMNÉSIA

Whittaker fala sobre dois tipos de amnésia: a do time e a da indústria.

Sobre a do time, parece que cada projeto é um novo começo. O time esquece dos seus projetos anteriores, dos bugs encontrados anteriormente, dos testes, etc. Na verdade cada novo projeto é um objetivo novo para um time que já ganhou experiências em outros projetos. O que falta é um mecanismo de retenção de conhecimento.

Sobre a da indústria: você já tinha ouvido falar ou lido sobre o exemplo dado do pesticida de Boris Beizer? As chances de ninguém ter passado pela mesma dificuldade que você está tendo agora nos seus testes é mínima. Mas a memória coletiva da indústria é muito fraca e falta compartilhamento de conhecimento o que leva as pessoas a estarem sempre perdendo tempo e reinventando a roda.


A PRAGA DO TÉDIO

“Testar é chato”. Eu mesma já disse isso em algum momento :). Há alguns aspectos monótonos e não criativos no teste. No início, a sensação de estar caçando bugs e encontrá-los pode manter o profissional motivado por algum tempo, mas depois é preciso algo mais.

Projetar testes, definir estratégias, selecionar o que vai ou não ser testado, como vai ser testado, são atividades mais desafiadoras intectualmente que podem afastar a mesmice.


A PRAGA DA FALTA DE AMBIENTE

Há dois grupos de detectores de bugs, os profissionais de teste e os usuários. No caso dos usuários, eles encontram os erros casualmente executando suas rotinas, não planejam encontrar os bugs, simplesmente os encontram.

E porque não achamos todos os bugs do sistema? Por que por melhor que seja a nossa estratégia, ainda assim há o risco de o usuário encontrar falhas que não encontramos? Porque ele que está em contato com o sistema no habitat ideal.

Whittaker faz uma compração com uma casa. Por mais que uma obra seja conduzida com todo esmero, supervisão, etc, alguns problemas só serão encontrados quando houver alguém morando lá e utilizando a estrutura no dia a dia.

Por mais que tentemos criar um ambiente igual ao do usuário (que já é muito difícil) ainda assim ficarão gaps que podem ser espaço de bugs. Por isso o período de garantia de um software.


A PRAGA DA CEGUEIRA

Testar um software é similar a jogar vendado um jogo de videogame sem informação alguma das variáveis em jogo. Se você é o Hyu e consegue dar uma série de Ha Dou Kens sem o seu adversário se mexer até fica fácil, mas sem saber o lifescore do seu personagens fica dificil tomar decisões. Agora imagine-se jogando Warcraft sem ver seus inimigos ou qualquer outro jogo que você tenha que acertar (mesmo que nao seja matando :P) um alvo e não consegue vê-lo. Bom, teste tem muito disso. Você não sabe onde estão os bugs. Pior ainda, muitas vezes não se pode atestar a cobertura dos testes e as vezes sequer tomamos conhecimento de mudanças no código.

É preciso ter a segurança de poder responder perguntas como a cobertura de testes, o que mudou de um build para outro, que partes do software costumam ter mais bugs, quais são alteradas com mais frequencia, etc.


THE 7TH PLAGUE AND BEYOND

No post The 7th Plague and Beyond, Whittaker fala que recebeu várias sugestões do que poderia ser a sétima praga. Seguem abaixo:

A praga das métricas: Métricas as vezes mudam comportamentos e deixam de ser uma medida de comportamento para ser um alvo, um objetivo.

A praga da semantica: Não há um dialeto comum. Alguns termos de especificações são comumente mal interpretados por essa falta de senso.

A praga da inifinidade ou da exastão: Saimos do foco muitas vezes por sermos obrigados a passar a maior parte do tempo explicando porque estamos ou não testando algo. Sempre que temos um novo objeto de testes temos riscos associados e começa tudo de novo.

A praga da má comunicação: A linguagem de criação (desenvolvimento) e a de destruição (testes) são diferentes.Os desenvolvedores não entendem os reports de defeito dos testers. Alguns dos casos de reabertura de defeito por má ou falta de correção dos desevolvedores são por falta de entendimento do desenvolvedor em relação ao bug. Nesse caso ao inves de má comunicação, as vezes é falta de comunicação mesmo.

A praga da rigidez: A criatividade muitas vezes não é permitida. Há rigidez nos processos, nas estratégias e isso se torna um empecilho ao desenvolvimento do nosso trabalho.


A PRAGA DA ENTROPIA

Entropia é uma medida de incerteza. Considerando 5 eventos, se a probabilidade deles acontecerem é igual, então temos o valor máximo de entropia e se um evento é certo e os outros 4 impossívels, temos o valor mínimo de entropia.

Testers inserem entropia no desenvolvimento quando adicionam tarefas aos desenvolvedores. Quando os devs estão apenas escrevendo o codigo da aplicação, a entropia é baixa, quando submetemos bugs, a entropia começa a aumentar. Quanto mais tarefas paralelas, maior a entropia, maior a probabilidade de inserção de novos bugs.

Acabar com a entropia é “fácil”. Basta termos desenvolvedores que nunca erram :). Ou uma solução mais tangível é estarmos atentos a essa entropia e gerenciarmos melhor essas atividades.



E quais são as pragas que afetam o seu dia a dia?

Processo de Teste: Avaliando critérios de saída e reportando

Falamos sobre Análise e Projeto de Teste de Software:
Estudo CTAL: Processo de Teste
Falamos sobre Implementação e Execução em dois artigos:
Processo de Teste: Implementação e Execução
Processo de Teste: Implementação e Execução II

E o próximo ponto importante para o Analista de Testes é avaliar os critérios de saída e gerar relatórios para acompanhamento do gerente.

Nesse ponto do processo serão coletadas informações para o gerenciamento e medido o progresso, que consequentemente leva a detecção de desvios do plano.

Para medir a completude do teste é possível considerar informações como:

- Número de condições de teste, casos de teste, ou procedimentos de teste planejados, executados, passados, e falhados
- Número total de defeitos classificados por severidade, prioridade, status, ou outro fator relevante
- Requisições de mudanças (change requests) propostas, aceitas, testadas
- Planejado versus real: Custos, cronograma, esforço...
- Riscos de qualidade mitigados e os restantes
- Tempo de teste perdido com eventos que bloquearam testes (time de implementação não liberou a versão na data planejada, o ambiente estava fora, etc)
- Resultados dos testes de confirmação e regressão


Resumo do Test Suite

Permite fazer um tracking de algumas propriedades importantes da execução

Figura do livro Advanced Software Testing

Nesta tabela podemos avaliar:

- Progresso dos testes cases
- Taxas de testes passados e falhados
- Defeitos por test suite de acordo com prioridade/severidade (weighted failure)
- Valor agregado

No lado esquerdo, as duas primeiras colunas são o nome do test suite e o número de caso de testes dele.

Depois, sob Planning Tests Fulfilled, tem-se os testes que estão prontos, que não tem nenhum trabalho adicional a ser feito neles.

Weighted Failure é uma métrica para os bugs encontrados em casa suite. O peso de cada um é medido de acordo com a sua prioridade e severidade num cálculo simples. Bugs com severidade 1 prioridade 1 tem o ponto total (1.00) e considerando 5 niveis de prioridade e 5 niveis de severidade, o bug de menor severidade e menor prioridade vale o mínimo de 0.04. Acrescendo esse valor a cada relação severidade x prioridade, temos valores médios para cada combinação severidade x prioridade, como fica mais claro na figura abaixo:

Em Planned Tests Unfulfilled estão os testes incompletos, que ainda há algum trabalho a ser feito neles. A propósito, caso gere dúvidas, IP é In Progress.

Earned Value é um conceito de gerenciamento de projetos que diz que em um projeto, nós realizamos tarefas gastando recursos (faz sentido, não?). Então se o percentual de tarefas realizadas é mais ou menos igual ao percentual de recursos gastos, estamos no caminho certo. Se o percentual de tarefas realizadas é maior que o percentual de recursos gastos, estamos em um caminho melhor ainda :), a tendência é ficar abaixo do orçamento. Se o percentual de tarefas realizadas é menor que o percentual de recursos gastos, estamos a caminho de passar do orçamento.

Do ponto de vista de cronograma, o percentual das tarefas realizadas deveria ser aproximadamente igual a percentual de periodo decorrido do projeto (elapsed time). Então se o percentual de tarefas está acima do percentual do cronograma, ficamos felizes e satisfeitos e se está abaixo, ficamos tristes e preocupados :P.

Na execução de testes, consideramos o caso de teste ou o procedimento de teste como nossa tarefa básica. Os recursos (para testes manuais) são “pessoa-hora” para rodar os testes.

Fácil? Difícil? :)

Mais um então!


Defect Breakdown

Uma das muitas formas de olhar um defeito é analisando ele sob a perspectiva de severidade x prioridade ou uma combinação dos dois.

Na figura abaixo, temos um gráfico que, comparado a gráficos similares de projetos anteriores, pode nos dizer se estamos indo bem ou não. O ideal é que ele inicia com mais bugs de prioridade/severidade maior, isso demonstraria uma boa aplicação de risk-based testing.

 Figura do livro Advanced Software Testing

Temos nesse gráfico, 5 pontos de severidade. A definição de como aplicar o nível de severidade e prioridade deve estar bem clara para todos os envolvidos no projeto. É bastante comum descobrir, atraves da avaliação desses gráficos, erros na classificação de defeitos.

Para um projeto que esteja no início, parece um bom comportamento gráfico, entretando para um projeto que esteja que esteja próximo ao término do ciclo de execução, é um gráfico bem preocupante.


Taxa de Falha de Confirmação

Um evento que poucos (ao menos eu vi poucos) se preocupam em medir é a taxa de falha de confirmação. O testador encontra um bug, o desenvolvedor resolve, o testador re-testa para confirmar a correção e ..... ? devolve para o desenvolvedor porque o problema não foi resolvido. Esse tipo de situação, que é comum, é uma perda de tempo. E pode ser medida através de um gráfico como esse:

Figura do livro Advanced Software Testing

Nesse exemplo, vários bugs foram reabertos, uma média de 1 a cada 6 defeitos reportados.


Padrões

De acordo com o famoso padrão IEEE 829, alguns itens que devem ser incluídos em um report de testes:

- Identificador do report
- Resumo (o que foi testado, quais são as conclusões, etc)
- Variações (do plano, dos casos, dos procedimentos)
- Avaliação compreensível
- Resumo dos resultados (métricas, etc)
- Avaliação de cada item de acordo com seus critérios de falha ou sucesso
- Resumo das atividades (uso de recursos, eficiência, etc)
- Aprovações

Esses resumos podem ser entregues durante a execução do teste, não necessáriamente só no final, e usado como ferramenta de acompanhamento.


Ainda sobre o assunto, eu sugiro a leitura dos seguintes artigos:

Execução e Relatório de Teste
Relatório Parcial de Execução de Teste

E um agradecimento especial ao autor desses dois artigos, o Gustavo Quezada, por nossa conversa sobre métricas. Ajudou bastante :)

Processo de Teste: Implementação e Execução II

Continuando post Processo de Teste: Implementação e Execução, agora com foco maior em Execução.


Iniciando a execução dos testes

Para iniciar os testes, espera-se que os critérios de entrada para essa fase tenham sido atendidos e que esses critérios cubram o que foi discutido no post anterior.

Nessa fase, espera-se que todas as condições de teste e riscos de qualidade tenham sido cobertos e que todos os passos do procedimento de teste tenham sido executados. (...) E por que não seriam?

Como não cobrir as condições de teste e riscos de qualidade? Com testes em alto nível que dependem da interpretação do testador ou que exigem do testador maior conhecimento na aplicação.

Como não executar todos os passos? Alguns passos podem corresponder à configuração de dados, realização de pré condições, retorno do sistema ao estado inicial antes do teste, etc. Em algumas situações esses passos podem ser pulados resultando na execução parcial do teste.

Nos testes manuais pode-se adicionar um certo grau de testes exploratórios deixando o procedimento um pouco mais vago ou na orientação dos testadores explicando que o teste pode servir como um mapa, um guia do que tem que ser testado e que eles podem explorar essa área e investigar os pedaços que eles considerem mais interessantes.


Zoom: Executando um procedimento de teste

Ao executar um procedimento de teste o testador vai comparar o resultado obtido com o resultado esperado no teste e esse é o momento que realmente agrega valor. Tudo o que foi realizado até agora foi para chegar a esse momento, portanto o registro dessas anomalias é a parte mais importante de todo o processo. E falando em anomalia, vamos lá ao dilema das definições.

SEGUNDO O ISTQB: Um resultado obtido diferente de um resultado esperado é uma anomalia e ao a observarmos, temos um incidente. Até ai tudo bem? :) Alguns incidentes são falhas. Uma falha ocorre quando o sistema não se comporta adequadamente devido a um ou mais defeitos. Nesse caso podemos coletar dados e situações para ajudar os desenvolvedores a solucionar o defeito. Alguns incidentes podem não ser falhas mas falso positivos, ou seja, o resultado obtido foi diferente do esperado por má especificação dos testes, dados inválidos, ambiente mal configurado, etc.


Reportando resultados de testes

Maiores detalhes Reportando Defeitos
Não é possível usar o valor que você ganhou na realização dos testes se você não registrá-lo. Em estratégias de teste reativas, é possível usar os defeitos registrados para fazer um script ou mesmo como base de conhecimento da aplicação. No post acima eu listo alguns dados a serem incluídos nessa reportagem de defeitos.

É importante para o controle e gerenciamento do projeto reportar qualquer problema que atrase, interrompa ou bloqueie os testes. Por exemplo: Se na hora de começar os testes descobre-se que o ambiente está fora, está correndo o tempo de execução de testes e é impossível executá-los, é possível abrir um defeito de ambiente e o tempo de correção deve ser indicado com uma das justificativas de atraso (se houver) na execução.


Padrões

IEEE 829 test procedure specification. Esse documento especifica como rodar um ou mais testes e inclui as seguintes seções:

- identificador da test procedure

- objetivo (que testes serão rodados)

- requisitos especiais (permissões, habilidades, ambiente...)

- passos do procedimento (logar, configurar, executar os passos, medir os resultados, finalizar, recomeçar, parar, etc)

IEEE 829 também sugere o que colocar em um log de teste:

- identificador do test log

- descrição do teste (itens de tetse, ambiente, versões, etc)

- atividades e eventos de entrada

Outros padrões que sugiro que dêem uma lida: BS 7925/2 e DO-178B(ou ED-12B).

Salvando Vendas

É comum vermos problemas em sites de vendas que nos afugentam e fazem com que desistamos da compra. Hoje uma colega passou por uma situação dessas, mas houve um outro evento que me fez simpatizar bastante com o mesmo site. Vou fazer um comentário negativo e um positivo, um elogio ao profissionalismo com que uma situação foi tratada.

Uma colega estava olhando uns apartamentos no site da Imobiliária DUCATI e não conseguiu entrar no chat Corretor Online exibido no site. Esse foi o problema. Ela preencheu os dados indicados (todos) e o site dava a mensagem de que o e-mail não estava preenchido. (Vou ficar devendo a imagem pois esse problema só aconteceu no computador dela). <-- Esse é o negativo.

(Mas...)
Em seguida eu tentei entrar no chat para ver qual era o problema. De repente eu descobria algum furo na validação e a avisava como sobre como entrar no chat. Mas com os meus dados, funcionou! :) Entrei no chat por duas vezes e sai, pois estava apenas testando (entretanto poderia ser algum problema com a conexão).

Em menos de 2 minutos após a minha última entrada no chat, meu telefone tocou. Era o corretor que me "atendeu" no chat. Ele comentou que eu estava tentando entrar no chat sem sucesso e perguntou se poderia me ajudar. Nota 1000 pro atendimento. Expliquei a situação e passei o telefone para minha amiga que ficou bem feliz também e elogiou um monte o atendimento.


Parabéns ao atendimento e fica a dica para outros sites que utilizam funcionalidades similares.

Processo de Teste: Implementação e Execução

Nada de gripe suína por aqui. Estava sem postar porque o trabalho estava tomando mais tempo, neurônios e energia do que o normal.


Sem mais ladainhas, vamos ao que interessa:

No último post de processo de teste falei sobre Análise e Projeto de testes. Agora é a vez de Implementação e Execução.

A referência é a mesma: Advanced Software Testing Vol.1 – Rex Black



Implementação e Execução

Passadas as fases de Análise e Projeto, tudo o que falta para que possamos executar o teste encontra-se agora na fase de Implementação. E o que falta? :) Se quisermos estruturar nossos testes em roteiros ao invés de depender do conhecimento do testador do sistema, nessa fase vamos organizá-los em procedimentos de teste, ou seja, documentar todos os detalhes que restam para a execução do teste. O nível de detalhes depende sempre da estratégia de teste adotada.

Para a execução dos testes, também é necessário que estejam bem resolvidas as dependências de dados e ambiente e pode ser que nesse ponto seja necessário utilizar ferramentas para produzir dados em massa.

Precisamos também definir o cronograma de execução e responder perguntas como: Quem vai testar? Em que ordem? Quais são os ambientes necessários?

É importante procurar assegurar ao máximo que as áreas mais importantes/críticas do sistema serão testadas primeiro.

E claro, para a execução dos testes, é necessário que o critério de entrada dessa fase tenha sido atendido.



Test Procedure Readiness

A pergunta que guia essa seção é: Os roteiros de teste estão prontos para serem rodados?

Deve ser determinada uma seqüência clara (e obviamente lógica) de execução dos testes, que engloba a definição de quem vai rodar o quê, quando, com que dados, em que ambiente, em que ordem. Note que “em que ordem” pode não ser uma decisão obvia técnica. Pode ser uma boa idéia pedir auxílio de stakeholders pra entender qual a ordem ideal de execução dos testes.

Se utilizados testes automatizados, devemos organizar a participação deles nesse roteiro. O ideal seria um ambiente separado para os testes automatizados para evitar corrupção de dados que acabam por afetar os resultados não só dos testes automatizados, mas também dos testes manuais, se rodados no mesmo ambiente.

Teoricamente os test scripts e o test harness são construídos na fase de Implementação. Porque “na teoria”? Porque o test harness deveria estar pronto semanas ou mesmo antes de você começar a automatizar seus testes, mas vamos, a título de ISTQB, considerar que são construídos nessa fase.

Também nessa fase trabalhamos as dependências dos testes. Duas bem fortes são: ambiente e dados. Alguns podem agora soltar um “não diz!”. Quem nunca passou por esses problemas? Em uma empresa que trabalhei isso era um suplício e essas eram as maiores causas de desperdício de recursos.



Test Environment Readiness

Se eu rodar meus testes em um ambiente mal configurado, o que acontece? Eu vou ter que rodá-los novamente. Esses resultados não poderão ser ditos confiáveis. Vão gerar “falsos positivos”.

Falsos positivos são testes que passaram, mas deveriam ter falhado, assim como falsos negativos são testes que falharam, mas deveriam ter passado.

Os dois problemas podem acontecer por problemas no ambiente, o que vai aumentar o número de rejeições de defeitos, e gerar uma grande perda de tempo para testadores, desenvolvedores e gerentes.

Um ambiente bem configurado permite que rodemos nossos testes dentro das condições previstas. É um ambiente que opera normalmente quando não há falhas (não gera falsos positivos). Para testes de sistema e testes de integração de sistemas, um ambiente bem configurado deve replicar o ambiente de produção. Defeitos reais de performance, em especial, são difíceis de achar se não forem fornecidas essas condições.

Para ambientes complexos, é comum ter uma pessoa dedicada à manutenção desses ambientes.

É importante também checar todas as ferramentas para gerência de configuração, report de testes, gerenciamento de incidentes, o próprio gerenciamento de testes, etc.



Combinação de estratégias de teste

Geralmente é uma boa idéia usar uma combinação de estratégias de teste para balancear a abordagem, por exemplo, planejando uma porção de estratégias dinâmicas com estratégias risk-based.

É importante, entretanto, que essa porção reativa esteja bem controlada. Os testes não podem ser ad-hoc. E também esses testes têm pouca previsibilidade de duração e cobertura. Sobre esse último ponto, pode-se aplicar uma técnica de gerenciamento de testes chamada session-based, e para estruturar melhor esses testes, aplicam-se técnicas como attacks, error guessing, e exploratory testing.

E porque isso? Testes baseados em experiência tendem a ser responsáveis pela descoberta de 5 a 10 vezes mais bugs que as técnicas scripted. Mesmo sendo de difícil previsibilidade e necessitando de um testador expert, pode ser uma técnica complementar que vá agregar valor à sua estratégia.

Para cada decisão em relação a técnicas e estratégias adotadas, pergunte-se sempre que valor agregará a sua adoção e que contras ela trará? Balanceie e tire dessa reflexão a sua decisão.



(Continua aqui)

Encontro GUTS - Escolas de Teste

Pessoal,



Marcamos o nosso próximo encontro para essa quinta-feira (06/08), aproveitando a presença aqui em Porto Alegre do Elias Nogueira. A palestra será sobre Escolas de Teste e ocorrerá às 19h na FACIN (PUC-RS).

Em breve divulgaremos o auditório. Interessados no evento, acompanhem as informações pelo blog do GUTS



Palestrante:

Elias Nogueira, CSTE. Graduado em Análise e Desenvolvimento de Sistemas pela Ulbra - Canoas/RS. Arquiteto de Teste de Software na InMetrics, Instrutor de Teste de Software na Iterasys e Consultor em Automação de Teste na Testanywhere.

Softwares que decidem nosso futuro

Quantos exames você já fez em máquinas que poderiam de alguma forma, se mal configuradas, prejudicar a sua saúde? Softwares que lidam com a saúde humana são considerados software de segurança crítica. Preciso comentar que esses softwares devem passar por uma bateria de verificações e validações bem mais rígida que quaisquer outros? Ou explicar os motivos? Estamos lidando com a vida do ser humano, e um erro pode causar danos sérios, quiçá irreversíveis.

Em junho a lei seca, também conhecida como de tolerância zero, fez seu primeiro aniversário. Uma lei que estipula condições de liberdade caso o condutor de um veículo apresente mais de 0,2 grama de álcool por litro de sangue.

Numa pesquisa rápida no Google cheguei ao resultado que na capital paulista em 2005, o álcool foi responsável por 45% das mortes no trânsito. Fora que o álcool é responsável por alterações nos sentidos, favorecendo o acontecimento de outros crimes e acidentes com seu consumo excessivo. Em um cenário caótico como esse, talvez a lei de tolerância zero seja mesmo a melhor opção para um combate radical a esses números absurdos.

A teoria, na minha opinião, é belíssima.

Mas vamos à prática. Como ocorre essa fiscalização? Através de testes de bafômetros. Como aparecem aqueles números? Através de um software! Um software que pode decidir a sua liberdade. Então, se esse software é responsável por algo tão sério, obviamente é um software que passa por uma bateria de verificações e validações bem mais rígida que quaisquer outros, certo?

“The program presented shows ample evidence of incomplete design, incomplete verification of design, and incomplete “white box” and “black box” testing. Therefore the software has to be considered unreliable and untested, and in several cases it does not meet stated requirements.”, é o que diz este artigo.

Vou reforçar em português: O programa apresenta ampla evidência de projeto incompleto, verificação de projeto incompleta, testes caixa branca e caixa preta incompletos. O software deve, portanto ser considerado não confiável e não testado, e em vários casos ele não atende os requisitos.

Este é o software que define ou não se um condutor será penalizado por essa lei. Veja a pena:.

Quem for flagrado com uma dosagem superior a 0,2 gramas de álcool por litro de sangue (equivalente à ingestão de uma lata de cerveja ou um cálice de vinho) pagará multa de 957 reais, receberá sete pontos na carteira de motorista e terá suspenso o direito de dirigir por um ano. Aqueles cuja dosagem de álcool no sangue superar 0,6 g/l (duas latas de cerveja) deverão ser presos em flagrante. As penas poderão variar de seis meses a três anos de cadeia, sendo afiançáveis por valores entre 300 e 1.200 reais. Os infratores também perderão o direito de dirigir por um ano.

Silvio Meira, professor Titular de Engenharia de Software do Centro de Informática da Universidade Federal de Pernambuco em Recife, cientista-chefe do Centro de Estudos e Sistemas Avançados do Recife (C.E.S.A.R) e engenheiro formado pelo Instituto Tecnológico de Aeronáutica (ITA), fala sobre ao assunto no seu blog.

Obviamente não estou questionando a necessidade de controle do álcool nas nossas vias, nem estou questionando a tolerância da lei. Estou questionando as ferramentas utilizadas para verificar o seu comprimento, ou melhor, a falta de comprometimento social das empresas e dos profissionais que liberam esse tipo de aplicação para serem usados pelo mundo.

A equipe desse software precisaria entender que seus clientes não eram seu gerente, o dono da empresa ou em primeira mão o governo que o compraria, mas pessoas que podem em algum momento ao invés de serem protegidas, serem penalizadas por esse produto.

Verificação – Inspeção

Sou uma pessoa privilegiada. Posso começar o post dizendo que ontem estava conversando com meu namorado sobre inspeções (e ele me entendia! :D). E foi isso que motivou o post.

Se você já leu Software Inspection de Gilb e Graham, talvez não tenha muita coisa interessante (ou melhor, nova) nesse post. Se não, eu o convido a refletir comigo sobre uma seção desse livro.

Na sua empresa, vocês inspecionam artefatos? Mesmo? Inspecionam ou 'revisam'? :)

Inspeção formal como estudamos vem da experiência de Michael E. Fagan na IBM, publicada como um artigo em 1974. Nesse livro, Tom Gilbs e Dorothy Graham explanam sobre esse trabalho, também com base em outros casos posteriores e complementares ao de Fagan, e com o suporte também de outras empresas que contribuíram para o livro.

No prefácio há um self-assessment para que você analise o seu processo de inspeção. Segue o mesmo abaixo com uma tradução livre :).

1. Você nega a entrada no processo de inspeção quando o produto a ser inspecionado não saiu de uma inspeção prévia? Se a resposta é não, você realiza primeiramente uma mini inspeção nesses artefatos ou pelo menos em uma amostra deles? Você proíbe a inspeção se os artefatos não estão com nível de qualidade adequado como resultado de uma mini inspeção ou similar?
Sempre – Geralmente – Algumas Vezes – Nunca

2. A reunião de abertura determina os objetivos da inspeção numericamente, e estabelece as estratégias correspondentes para alcançá-los?
Sempre – Geralmente – Algumas Vezes – Nunca

3. Os papéis são designados e definidos em checklists de papéis? Há uma biblioteca com esses checklists disponível para todos os líderes da inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca

4. O líder da inspeção verifica que para cada desvio registrado houve alguma ação do editor?
Sempre – Geralmente – Algumas Vezes – Nunca

5. As taxas de revisão individual e em reunião são atualizadas e comparadas com as taxas ideais, e usadas para planejar a próxima inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca

6. A razoabilidade das taxas é usada como critério de saída?
Sempre – Geralmente – Algumas Vezes – Nunca

7. O número de defeitos restantes após a edição é previsível? Se esse número é muito alto para o tipo de documento, o mesmo falha na inspeção? Em outras palavras, o número estimado de defeitos restantes é um critério de saída?
Sempre – Geralmente – Algumas Vezes – Nunca

8. A eficiência de detecção de defeitos é registrada? Esse dado é usado para estimar os defeitos restantes ao fim do ciclo de inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca

9. A quantidade substancial de desvios encontrados no documento é registrada? (Ex. uma média de 10% a 25% dos desvios registrados resultaram em requisições de mudança (CR))
Sempre – Geralmente – Algumas Vezes – Nunca

10. Líderes de inspeção são formalmente certificados de acordo com um critério documentado? Há uma lista atualizada de líderes certificados? Líderes não certificados são proibidos de rodar uma inspeção de software (a não ser sobre devida supervisão)?
Sempre – Geralmente – Algumas Vezes – Nunca

11. Há melhorias nas regras, procedimentos e checklists regurlamente?
Sempre – Geralmente – Algumas Vezes – Nunca

12. Os resultados das melhorias nos padrões de inspeção são compartilhados com todos os líderes de inspeção e os inspetores?
Sempre – Geralmente – Algumas Vezes – Nunca

13. Há uma biblioteca de materiais de inspeção (formulários, checklists, regras), que seja bem organizados e conhecido, usado por todos os líderes de inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca

14. Há um processo de reunião de brainstorming realizada para analisar as causas-raíz dos defeitos encontrados nos produtos de inspeção? Melhorias pequenas são implementadas imediatamente? Todas as sugestões de melhoria são formalmente registradas?
Sempre – Geralmente – Algumas Vezes – Nunca

15. Alguém ou algum grupo (geralmente o Time de Gerenciamento de Mudança de Processo) implementa melhorias no processo usando o banco de dados de inspeções?
Sempre – Geralmente – Algumas Vezes – Nunca

Agora, uma continha de padaria.
Sempre – 3 pontos
Geralmente – 2 pontos
Algumas Vezes – 1 ponto
Nunca – 0 ponto

E uma avaliação da sua pontuação:

45 (Perfeição)
Você não foi honesto com você mesmo!! :) Ninguém no mundo real alcança a perfeição! Volte e conte de novo a sua pontuação.

Entre 0 e 7
Não é exatamente considerado como nível. Definitivamente o que é feito não é uma inspeção. Fica a dica do livro ;)

Entre 8 e 15
Nível iniciante

Entre 16 e 23
Nível competente

Entre 24 e 31
Nível experiente

Entre 32 e 38
Nível estabelecido

Entre 39 e 45
Nível pioneiro

Claro que tem toda uma análise de perfil para essas pontuações. Mas a idéia do post era chamar atenção pro que se chama se inspeção por ai. Inspecionar não é revisar, passa o olho, etc. Consiste num processo estruturado que deve ser bem estudado antes de ser implementado. Fica a dica do livro que é A fonte para esse assunto.

Dúvidas sobre as perguntas e acusações de má tradução, podem colocar nos comentários para direito de defesa :D

Vamos revisar o processo!

Recebi há pouco um e-mail muito legal da STP, com o artigo Is QA About People or Process?. Colei o artigo no final do post para quem tiver interesse.

Achei muito interessante o questionamento feito sobre controle de qualidade. Temos um bug em produção! Vamos rever o processo! :)

O processo de uma empresa deve ser algo vivo, ou seja, deve estar em constante aperfeiçoamento e sim, bugs e métricas relacionadas a esses bugs (bem como outras métricas e outros inputs) são utilizados como base para essas melhorias.

• Se minha empresa tem um processo maduro, então os softwares produzidos por ela serão sempre de excelente qualidade?
• Se minha empresa não tem um processo maduro, então os softwares produzidos por ela serão sempre de baixa qualidade?

 O que é processo afinal? Será que posso dizer que tenho um processo porque desenhei algumas caixinhas de workflow?

Falta ai uma consideração muito importante: pessoas!

São projetados procedimentos a serem seguidos, mas são pessoas que os vão seguir e onde temos pessoas, temos suscetibilidade a falhas. E nem todas as falhas devem necessariamente ser motivo de revisão no processo.

No artigo abaixo, Edward faz uma comparação interessante entre indústria de manufatura e de software e a aplicabilidade de modelos de qualidade nesses ambientes.

Is QA About People or Process?
By Edward J. Correia

Any time a defect gets through to production, companies have a tendency to reexamine their processes. “If we had tighter processes in place, this would not have happened,” is usually the thinking of management. If you deal with product quality, perhaps your reaction was something like, “Here we go again.”

But is quality control really about process? Can an air-tight process make up for sloppy, apathetic, or time-constrained people? Or, can a meticulous person assure quality despite controls that are less than perfect? Are people or processes most responsible for good quality?

Obviously, quality assurance involves a combination of the two. But according to V. Viswanathan, a quality analyst with international IT services company Virtusa, the answer might also depend on the industry. Having worked in manufacturing as well as software development, he believes that project-related endeavors like software development tend to be person-centric, whereas the manufacturing industry centers on process. “The amount of savings and benefits that occur in the software industry due to process improvement activities may not be really significant,” he says, whereas the Six Sigma process is a cornerstone of manufacturing.

“Six Sigma is mainly applicable to industries where operations or activities are identical,” he points out, hardly a characteristic of software development. “I don’t mean that Six Sigma is not applicable to software development. But by applying Six Sigma, drastic benefits may not be achieved as those that occur in the manufacturing industry."

Part of the Six Sigma strategy for business process improvement is to identify the root cause of a problem and then find and implement a solution. “In order for Six Sigma to be most effective, the operations have to be repeatable,” says Viswanathan. Hence, individual talent plays a far smaller role in manufacturing than in software development. Some of the differences include the following:

In manufacturing, each product is intended to be identical; in software development each product is customized (otherwise there would be nothing to develop).

Processes in manufacturing are the same for each operation; processes in software development vary in terms of content.

Most manufacturing workers perform at a similar level of effectiveness; software development workers’ abilities vary widely, as do their levels of skill and effectiveness.

As is true of many creative activities, the content involved with software projects can vary wildly, and operations related to application development will vary accordingly. “In software, the operations across projects might be similar, but are not identical. You may have the same set of phases…requirement analysis, design, coding, testing, and implementation… between projects. But the details of each are different,” he says.

Therefore, activities that you might have implemented to improve a process or solve a problem in one project may not be valid for another. “Also, the level of success might be different. Even if it is applicable, the consistency of success cannot be maintained across projects,” says Viswanathan. What’s more, errors are inevitable whenever human input is involved. And the places where errors turn up cannot be predicted. Such relative chaos is anathema to manufacturing, which relies on predictability and consistency for maximum output.

Each According to Ability

Perhaps the biggest difference between the software office and factory floor is the way in which each makes use of ability. A nimble factory worker might produce one percent more widgets and be less prone to injury than someone who is clumsy. But a skilled developer can become the basis of an entire industry (think Linus Torvalds).

The most effective software development team is one that combines skilled, competent and caring workers with solid, logical processes that work well and make sense to all involved. Because without buy-in from the team, your processes are not worth the paper they’re printed on.

Estudo CTAL: Processo de Teste

No Advanced Software Testing Vol 1 do Rex Black, processo de teste está no segundo capítulo. Segue abaixo um overview desse capítulo.

**
O processo de teste consiste em:
-- Planejar e Acompanhar
-- Analisar e Projetar
-- Implementar e Executar
-- Avaliar critérios de saída e reportar resultados do teste
-- Atividades de fechamento de teste

O foco do livro é dado nas 3 atividades do meio.

Análise e Projeto de Teste
Nas atividades de planejamento, o líder de teste e o gerente de teste trabalham junto aos stakeholders na definição dos objetivos de teste. No template IEEE 829, essa informação fica documentada em “Features to be tested”.

Um pouco mais sobre documentação e norma IEEE 829 em:
- Sem Bugs – Como documentar seus testes
- ANSI/IEEE 829-1983 IEEE Standard for Software Test Documentation –Description

A partir dos objetivos de teste, na fase de análise e projeto, são desenvolvidas as atividades de:
-- Identificar e refinar as condições de teste para cada objetivo de teste
-- Criar casos de teste que exercitem as condições de teste identificadas

Saber o que testar, ainda não é suficiente. É preciso saber em que ordem e o quanto. Para que as áreas mais importantes sejam testadas primeiramente e o esforço de teste seja mais efetivo e eficiente, é preciso priorizar as condições de teste.

Essa definição de prioridades normalmente envolve a determinação do impacto e da probabilidade de um risco de qualidade (Conceito aplicado em estratégia baseada em risco – que fica pra outro post).

Durante o processo, as condições de teste e o risco associado a elas pode mudar conforme as necessidades (ou entendimento das necessidades) do projeto. Essas atividades de priorização e re-priorização ocorrem durante todo o ciclo, da análise e projeto, à implementação e execução, e influencia na avaliação dos critérios de saída e report de resultados.

Objetivos de testes funcionais
Objetivos de teste funcionais podem ser aplicados durante todo o ciclo, em qualquer nível de teste. É importante testar os principais objetivos de teste primeiro para não se deparar com falhas muito graves ao final da execução.

No livro há um exemplo de um vídeo game e a funcionalidade de salvar e resumir o jogo. Um exemplo que eu gosto de usar é o de um telefone celular. Qualquer aplicação para celular deve ser capaz de tratar uma ligação. Ele deve ser interrompido para que o usuário receba a ligação e deve continuar após o término da ligação. Receber uma ligação é a funcionalidade principal do telefone (mesmo que hoje em dia eles praticamente cozinhem pra você), e quem está ligando não pode receber uma mensagem de indisponibilidade porque você está consultando sua agenda, ou porque está jogando, ou usando a calculadora. Esse é um teste que deve estar nos testes unitários, de integração, de sistema e de aceitação. Todos dando uma especial atenção a esse objetivo de teste. Lembrando que o teste começa ainda antes, na revisão de requisitos, de projeto e de código.

Posteriormente no livro é detalhada a estratégia baseada em riscos. Se você não está usando essa estratégia, você necessitará selecionar as entradas e técnicas de acordo com a estratégia utilizada, que claro, deve estar alinhada com o plano de teste, com as políticas de teste, etc.

Há duas escolhas importantes no processo de identificar e documentar as condições de teste:
- O nível de detalhamento das condições de teste na documentação
- A estrutura da documentação para as condições de teste

Há várias maneiras de se estruturar as condições de testes. Uma delas pode ser um paralelismo com a documentação base. Por exemplo, se a sua empresa trabalha com requisitos de marketing e especificações de requisitos, entende-se usualmente que o primeiro é uma descrição alto nível e o segundo, baixo nível. Assim, com base nesses documentos, você pode criar uma estrutura de condições de teste alto nível e uma em baixo nível equivalentemente.

Outra abordagem envolve a análise dos riscos de qualidade, identificando esses riscos para cada funcionalidade e assim temos as condições de teste.

O importante é que o nível de detalhamento deve estar alinhado com a estratégia de testes, que deve estar alinhada com o plano, que está alinhado com as políticas,...

Aproveite para criar a rastreabilidade nesse momento. É sempre mais fácil do que tentar criá-la numa abordagem bottom-up.

Tendo as condições de teste documentadas, o próximo passo é, normalmente, escrever os casos de teste. Há estratégias reativas discutidas no syllabus Foundation que nem sempre têm casos de teste documentados. Esses testes serão escritos utilizando técnicas que serão abordadas posteriormente.

Para os casos de teste, também deverá ser selecionado um nível e uma estrutura que deve ter todo o alinhamento já mencionado acima.

O processo de design depende agora das técnicas selecionadas para o projeto do caso de teste, mas em linhas gerais pode-se dizer que ele contém:
- Pré-condições
- Requisitos de ambiente
- Entradas de teste e outros requisitos de dados para o teste
- Resultados esperados
- Pós-condições

Definir os resultados esperados pode não ser tão trivial, especialmente considerando que esses resultados nem sempre são saídas na tela, mas condições de dados ou de ambiente. Para acuracidade dessa definição usamos o oráculo de teste.

Oráculo de teste
É a fonte que usamos para determinar o resultado esperado de um teste. Podem ser requisitos, um manual, um especialista,... Só não pode ser o código, ou a validade do teste estará comprometida. Seria o mesmo que testar o compilador.

Agora se você está achando que esse oráculo é uma especificação detalhada de testes, para a qual os resultados podem ser perfeitamente mapeáveis, isso é quase uma utopia. Normalmente essas fontes são superficiais, vagas, ambíguas e no caso de mais uma fonte, às vezes contraditórias. É preciso acrescer a elas experiência e um pouco de pessimismo profissional. Isso não acontece apenas no nível de sistema, mas em todos os outros níveis de teste.

Quem nunca teve a experiência de brincar de ping-pong com um bug? Vai pro teste, vai pro dev, vai pro teste, vai pro dev,... Isso decorre muitas vezes da ausência de um oráculo estável e confiável.

Padrões

Especificação de design de teste da IEEE 829:
Nele é descrita uma coleção de casos de teste e as condições de teste que ele cobre num alto nível. Inclui as seguintes seções:
- Identificador da especificação de teste
- Funcionalidades que serão testadas
- Refinamento de abordagem (técnicas específicas, ferramentas, etc)
- Identificação do teste
- Critério de validação (como determinar se a funcionalidade passou ou não no teste)
Essa coleção de testes descrita na especificação de design é também chamada de suíte de teste.

Especificação de casos de teste IEEE 829:
Detalha o caso de teste. Inclui as seguintes seções:
- Identificador da especificação de teste
- Itens de teste (o que vai ser entregue e testado)
- Especificações de entrada (arquivos, entradas do usuário, etc)
- Especificações de saída (resultados esperados, telas, arquivos, etc)
- Requisitos de ambiente (software, hardware, pessoal, etc)
- Requisitos procedurais especiais (permissões, intervenção do operador, etc)
- Dependência entre casos (se necessário para definir as pré-condições)
Casos de teste variam em esforço, duração, número de condições cobertas e podem ser escritos de maneiras diferentes.

ISO 9126:
Esse padrão determina seis características de qualidade de software: funcionalidade, confiabilidade, usabilidade, eficiência, manutenabilidade e portabilidade. Cada característica tem 3 ou mais sub-características. Vide figura abaixo.

O foco da certificação é na funcionalidade, os demais são considerados testes não funcionais, mas alguma dessas características pode sim vir a intervir no teste funcional.

Testes estáticos
São as inspeções, revisões. Todos conhecem a clássica curva de custo de detecção de um defeito ao longo das fases do projeto, certo? Tem um post do Fernando Palma sobre o assunto com uma figurinha do custo da não qualidade.

Fazer a análise e o projeto de teste em cima de uma especificação pode ser a própria revisão.

Métricas
Nessa parte do processo é possível medir:
- percentual de requisitos cobertos pelas condições de teste
- percentual de condições de teste cobertas pelos casos de teste
- número de defeitos encontrados na fase de análise e projeto de teste


Próximo post CTAL-related será sobre Implementação e Execução, continuando o fluxo do processo de teste.

Glossário de termos usados

Off Topic: Horizontes

O assunto não é tão off topic assim, mas como não é exatamente relacionado a testes e qualidade, preferi colocar dessa maneira.

O post é sobre o evento Horizontes: Empreendedorismo e Networking em TIC para Novos Profissionais que ocorreu ontem no auditório da Faculdade de Informática da PUC-RS.

Foi bastante produtivo o evento para conhecer pessoas, fazer contatos, aprender um pouco mais sobre a importância do networking, como fazer networking e sobre o papel de CIO nas empresas.

O evento começou com uma apresentação dos ‘hosts’: Eduardo Arruda, CIO TJ-RS e Presidente da SUCESU-RS; Newton Braga Rosa, Secretário de Inovação de Tecnologia de Porto Alegre; e Avelino Francisco Zorzo, Diretor da FACIN/PUC e Diretor Adjunto de Treinamento e Ensino da SUCESU-RS.

Houve então um painel com o Eduardo Arruda, Newton Braga, Ricardo De Rose (CIO da EPCOS e Vice Presidente da SUCESU-RS) e Guilherme Lessa (CIO do Banco Matone e Presidente do GUCIO-RS).

Ao que interessa:

Newton Braga falou sobre a importância do empreendedorismo, o que é ser um empreendedor, tirando o estigma de que necessariamente um empreendedor é um empresário. Citou uma frase que disse o diretor da SAP ao falar sobre os profissionais que contrataria para o centro que está sendo desenvolvido na TECNOPUC, em que o mesmo afirma que a SAP deseja contratar profissionais auto-motivados e que assumam riscos (controlados). E o que é isso senão um empreendedor?

Falou então da importância de se assumir riscos no seu trabalho, e fez uma colocação bem famosa:

Há dois tipos de funcionários que destroem uma empresa:
- aqueles que não fazem o que lhes é mandado (óbvio..)
- aqueles que fazem apenas o que lhes é mandado (e esses são mais perigosos que os primeiros)

Em seguida, explanou sobre networking e sua importância citando fatos como, por exemplo, que a recolocação no mercado se dá em sua maioria através de networking e não anúncio em jornais e afins.

O ápice da palestra foi uma dinâmica bastante pertinente. Temos o vício de ao chegar a um local qualquer, um evento, uma festa, seja qual for o lugar, e procurar pessoas conhecidas, nos aproximarmos e ficarmos ao lado delas durante o evento. Isso não é networking.

Fomos convidados então a nos organizarmos nas fileiras do auditório de acordo com a data de nascimento de cada um, sendo a primeira fileira ocupada pelos aniversariantes de janeiro, em ordem, a segunda pelos de fevereiro e assim subseqüentemente. Percebemos ainda que apesar de a comunidade de informática ser tão unida e não terem tantos profissionais assim, a grande maioria acabou por ficar ao lado de pessoas que não conhecíamos. Fomos então convidados a nos apresentar e trocar cartões

Hein?!? Trocar cartões? Como assim?

Pergunta: Como você vai para um evento em que espera fazer networking e não tem um cartão de visita? Vários cometeram essa gafe (e eu estou no meio :$). Fica aqui uma dica a todos: se não tem um cartão, faça um agora!!! No próximo evento, mantenha-o próximo e troque cartões, apresente-se, conheça pessoas, faça relacionamentos, pois é neles que se baseiam todas as oportunidades profissionais (e pessoais, pra quem anda procurando, quem sabe? :P)

Após a reviravolta no auditório, todos em lugares trocados, ao lado de ‘desconhecidos’, foi a vez de Eduardo Arruda fazer sua apresentação sobre o que é um CIO. Você sabe?

CIO – Chief Information Officer, o responsável por todas as informações de uma empresa. É uma baita responsabilidade, inclusive uma responsabilidade criminal (consultar a SOX). As empresas precisam de um CIO porque precisam de previsibilidade e é disso que trata a Governança de TI. Empresas confiáveis atraem investimentos.

O CIO deve ser um líder, o que envolve talento e competência. Nem todos têm o talento nato, mas competência é algo que se adquire. Três tópicos relacionados ao líder: inspiração, coaching e delegação.

Tentador foi o último slide, com o salário médio dos CIOs no RS:
Base: 8k
Média: 14k
Mais alto: 25k

É muito trabalho, é muita responsabilidade, e a remuneração está ai. Vale a pena? Essa pergunta foi feita, não foi respondida, e fica em aberto pra vocês pensarem também.

Após o Eduardo, o Ricardo fez uma palestra rápida incentivando a participação em grupos de usuários, eventos, fóruns, leituras de blog, etc. Na sua apresentação tinham slides bem legais dando uma idéia de como nos sentimos quando entramos na faculdade (um monte de gente, uma área toda aberta para caminharmos, e sem saber ao certo pra que lado vamos), depois uma figura de um labirinto complexo, cheio de gente representando a entrada no mercado, onde temos que nos sobressair. Precisamos pensar além, mais que o senso comum, e saber para onde vamos. Em seguida falou sobre a importância do networking nessa caminhada e sobre a necessidade de constante inovação no nosso dia a dia.

Finalizando os painéis, Guilherme Lessa trouxe um slide muito legal:

Há 10 tipos de profissionais

- Aqueles que entendem números binários
- Aqueles que não entendem

Uma abordagem muito legal de valorização do nosso trabalho. Lembram que em outro post falei que somos realizadores de sonhos? Ele tocou nesse mesmo assunto. Fazemos mágica!!! Imagina nosso primeiro antepassado que viu um fax funcionando. Como assim, entra uma folha em branco e depois ela sai escrita?!? E o telefone móvel, e o iphone que revolucionou o próprio telefone? E tantas outras invenções... Somos mágicos! Nós somos a força motriz que está mudando o mundo.

Bom, como eu adoro o que eu faço, eu compro logo essas idéias de que o meu trabalho é o máximo! :)

Lessa então apresentou o GUCIO, um grupo de 40 amigos CIOs que trocam experiências mensalmente dividindo seus sucessos, seus fracassos, aprendendo uns com os outros, que é o sentido de um Grupo de Usuários (GU).

Depois dessas apresentações teve um coquetel, excelente oportunidade pra colocar em prática o que aprendemos sobre networking. Valeu muito a pena o evento e sugiro que quem recebeu o convite mas não foi, da próxima vez não deixe passar essa oportunidade, pois foi bastante enriquecedor.


As apresentações estarão em breve no site da SUCESU-RS.

Máquina de estados de defeitos

No último post foi comentado sobre a reportagem de defeitos, um pouco sobre a sua importância e algumas informações importantes de serem registradas ao se abrir um defeito.

E depois que ele foi aberto, o que acontece? Se há algo errado, espera-se que ao menos na maioria das vezes seja corrigido (volto a essa observação em um post sobre critérios de saída). Então de Aberto o bug vai para? Corrigido. Muito bem, é só isso? Claro que não! :) Agora você vai re-testar e ver se o bug realmente foi corrigido (e preferencialmente testar as funcionalidades que tem relação com a área em que foi encontrado o bug para garantir que ao corrigir um problema não foi(foram) criado(s) outro(s)). E agora sim ele está Verificado.

O ciclo de vida mais simples possível de um bug seria: Aberto – Corrigido – Verificado.

Se não há controle sobre a máquina de estados de um erro na sua empresa esse é um excelente ponto de início. Mas com o tempo (bem pouco tempo) esse ciclo vai se mostrar pobre e já não vai atender às necessidades de respostas do projeto. E então temos a oportunidade de elaborar mais um pouco. Ao invés de apresentar primeiro a clássica figura de máquina de estados, vamos a um jogo de perguntas e repostas. Se a pergunta q eu estiver fazendo não parece se encaixar na sua realidade, ou você acha que é exagero, então pra sua realidade ela provavelmente não serve e é provável que você possa abrir mão desse status.



Desvendando a máquina de estados

Claro que os nomes que serão utilizados aqui podem ser mudados, o que importa é a semântica. Vamos ao P&R (onde P onde ser Pergunta ou Problema ;) ).

Abri um defeito, ele está há dias para ser corrigido e eu tenho a sensação que ninguém está sequer olhando para ele.


Ou ainda, há um atraso considerável na correção dos defeitos abertos. Os defeitos parecem estar em um cesto e os desenvolvedores puxam qualquer um para resolver. Não sei qual o tempo médio de resposta de acordo com a prioridade/severidade indicadas no defeito.

Para essas, que tal incluirmos um estado intermediário entre Aberto e Corrigido?

Aberto – Designado – Corrigido

Nesse caso é interessante ainda ter um campo Designado Para. Assim é possível saber quem está responsável pelo bug naquele momento. Quando Aberto pelo time de testes, o bug será Designado para o time dev. Como comentado no post anterior, pode ser para o líder para que ele de acordo com o seu acompanhamento indique quem irá corrigir o bug ou pode ser direto para o desenvolvedor. Após a correção, quando o desenvolvedor marcar o bug como Corrigido, o campo Designado para vai conter o nome do testador que abriu o bug (preferencialmente) ou do líder de testes para que ele indique quem irá verificar a correção. O campo Designado para então é um campo ativo em todos os status. Sempre que a responsabilidade de verificação do bug mudar, o campo deverá refletir essa mudança.

Eu verifiquei o bug, tava certinho, mudei o status dele para Verificado. Mas não sei se essa correção já foi integrada no novo build que me deram para testar. O responsável pelo build tem um monte de defeitos para integrar e precisa saber que defeitos já foram integrados e quais ainda não foram já que a todo instante a equipe de desenvolvimento está entregando correções.

Podemos então incluir um status após Verificado. Integrado.

Aberto – Designado – Corrigido – Verificado – Integrado

Mas pode haver problemas na integração, certo? E como eu sinalizo isso?

Que tal incluir um status após o Integrado para sinalizar que o bug está realmente encerrado tendo sido verificado inclusive em produção.

Aberto – Designado – Corrigido – Verificado – Integrado – Fechado

Esse é “caminho feliz”, certo? Aquele em que o defeito foi detectado, corrigido eficazmente, verificado, integrado e não deu nenhum probleminha nessa seqüência. Mas e se eu quiser controlar os bugs que o desenvolvedor disse que estavam corrigidos e que na verdade não estavam? Volto eles para Aberto? Para designado?

Até poderia ser, mas que tal um status Reaberto para sinalizar claramente que a correção não foi efetiva? O Reaberto teria então o mesmo valor do Aberto e a partir daí, segue-se o fluxo normal.

E se eu abri um defeito, mas na verdade eu me equivoquei? Como faço para mandar ele pra Fechado?

Não faz! :) Cria um status Cancelado para indicar que não era um bug.

E logo no comecinho do post foi falado em bugs que não são corrigidos, critérios de saída... Não dá pra adiantar nada sobre isso?

Às vezes nem todos os bugs são corrigidos. Há uma negociação com o cliente e esses defeitos vão como Conhecidos. Veja bem, não é dizer que não tem defeitos, é sinalizar que eles existem, são conhecidos, mas o cliente está aceitando recebê-los mesmo assim.

Ou ainda, um defeito pode não ser corrigido na iteração corrente, mas na próxima iteração devido ao seu impacto em outras funcionalidades ou devido ao total de trabalho já previsto para determinada iteração. Pode ser um defeito Adiado.

Alguns outros campos podem dar suporte aos status, assim como o Designado Para, poderíamos usar um campo versão do build para indicar em que versão o bug foi Integrado, versão do release ou iteração para indicar a iteração em que será integrado o bug Adiado e por ai vai.

Abaixo uma figurinha da máquina de estados do Bugzilla. Há diferenças em relação ao post, mas como comentei antes, o que interessa é a semântica e não é porque o pessoal do Bugzilla desenhou que esse fluxo se encaixa na sua realidade, certo?

Como na maioria dos meus posts eu incentivo: pense, questione, reflita. Testar é essencial, não burocrático. Faça do seu trabalho o mais prazeiroso possível, torne suas atividades úteis. Evite burocracia :)

Reportando defeitos

O processo de teste consiste em planejar, analisar, projetar, implementar, executar e ....? Criar reports de defeitos (e re-testá-los, etc.).

Podemos testar para conhecer (testes exploratórios), podemos testar para verificar a qualidade de um produto já pronto e validar se ele atende às expectativas para que seja comprado ou ainda, acredito que o mais comum, podemos testar softwares antes de serem fechadas versões entregáveis dele ou como homologação para aceitar o produto.

Acredito que o principal resultado do trabalho de testes é o report de defeitos. A diferença entre o esperado e o atual. A reportagem incorreta de defeitos resulta na perda de valor da execução do teste.

Mesmo quando se está usando uma abordagem reativa de testes, e ainda não existem scripts, logue o defeito que você encontrar. Eles vão inclusive ajudar a criar esses scripts futuramente.

Que informações deve conter um log de defeito?

Bem, isso depende do contexto do seu projeto.

É fortemente recomendado que ele tenha um identificador único. Um número ou um código formado como convir que sirva como referência a esse erro.

Também é uma boa prática que ele tenha uma descrição sucinta, uma espécie de título (uma única frase) que indique em linhas gerais do que se trata o defeito.

Parece óbvio que a descrição do defeito é o mais importante, certo? Nessa descrição, procure especificar como se deu o defeito. Coloque um passo a passo, os dados que foram utilizados, tudo o que outra pessoa pode precisar para reproduzir novamente o erro encontrado. A propósito, procure informar nessa descrição a incidência desse erro (reproducibilidade), se com o passo a passo que você proveu é certo que ele vá ocorrer, ou se é um erro intermitente.

Informações como ambiente, versão do build, versão da documentação base (caso de teste, requisito, o que se aplicar), também são importantes. Lembre-se “a única constante da vida é a mudança” e se você não documentar essas informações, o seu defeito pode ser cancelado como se nunca tivesse existido e tivesse sido logado erroneamente. Não só como elemento de defesa, essas informações podem ser usadas para detectar instabilidade no ambiente, problemas de integração, erros de documento, ou mesmo para rastrear o defeito e a sua causa.

Para quem está gerenciando/acompanhando essa execução e as correções, é importante saber a severidade do erro encontrado. Esse parâmetro tem suas variações conceituais de empresa pra empresa. Um exemplo seria classificar com sev 1 um erro que impede que uma funcionalidade principal do sistema seja executada, sem workarounds; sev 2 um erro que impede que uma funcionalidade menos importante do sistema seja executada, sem workarounds; sev 3 um erro que não bloqueia a execução da funcionalidade, mas impacta no funcionamento correto, entretanto há um workaround para ele; sev 4 um erro sem grande relevância para a execução do projeto; sev 5 uma sugestão de melhoria. Reforço que esse é um exemplo qualquer e que essa definição varia de empresa para empresa, entretanto não deve variar de projeto para projeto. Deve ser um padrão da empresa e haver um entendimento uniforme do seu uso.

Outra informação útil é a prioridade. Isso vai dar um norte para a correção do erro. Na verdade quem pode ter mais insumos para opinar sobre isso pode ser o líder de desenvolvimento ao invés da equipe de testes. Imagine por exemplo que você está testando um módulo de um sistema de vários módulos dos quais você não tem tanto conhecimento de como anda o teste e há uma equipe de desenvolvimento integrada para resolver todos os erros reportados por todas as equipes de todos os módulos. O líder de desenvolvimento vai avaliando junto aos desenvolvedores a prioridade para correção desses erros e ele vai, provavelmente, ter muito mais conhecimento para determinar isso que você. Mas você pode dar uma idéia. Assim como a severidade, a prioridade deve obedecer a um padrão. Um critério para o teste estabelecer prioridades pode ser o número de casos de teste bloqueados ou impactados pelo defeito registrado.

A priorização da correção de um defeito deve então dar-se pela combinação de severidade e prioridade.

Em um time de teste é importante saber quem encontrou o defeito para se tirar dúvidas sobre ele, é importante saber a hora em que ele foi aberto para controlar o tempo de correção, é importante, se estão sendo utilizados casos de teste na execução, saber que caso de teste ‘desvendou’ o bug para que após sua correção o mesmo seja re-executado e que tipo é esse caso de teste (se manual ou automático).

É importante saber quem vai corrigir o defeito, ou melhor, quem está responsável pelo bug. A princípio ele pode ser designado para o líder de desenvolvimento e este selecionar quem no time dele ficará responsável pela correção ou designar direto para o desenvolvedor que fará a correção. Essa política também fica a cargo da empresa/projeto.

E por fim (o que não quer dizer que se esgotam as possibilidades), o defeito deve ter um status. Só essa informação já rende um post falando sobre máquinas de estado de defeitos.

Essas informações (e outras) podem ser encontradas no formulário padrão de abertura de defeitos das ferramentas de gerenciamento de execução de teste. Há várias free no mercado, mas é possível documentar os defeitos no Excel ou no Access, claro, com um gerenciamento dessas informações bem comprometido. Mas se você não tem ferramenta alguma e quer começar a documentar os defeitos encontrados no seu projeto, pode ser um começo.

Procure documentar qualquer coisa que atrase, interrompa, bloqueie ou interfira de alguma maneira na execução dos testes. Fica mais fácil controlar o que está acontecendo na execução e tomar medidas. Por exemplo: O banco de dados está fora do ar. Não é um defeito na aplicação, mas é um problema que deve ser logado e que ajuda a responder coisas como “quanto tempo a equipe de testes ficou parada e por quê?”, “que impacto teve a queda do banco na execução dos testes e conseqüentemente no cronograma do projeto?”

Ainda o report de defeito pode ser usado na avaliação do critério de saída da fase de testes, dependendo do que foi estabelecido no planejamento de testes, mas isso também é assunto para outro post.

Abaixo, uma telinha com o report básico de issues do Mantis. Note que ele contém poucas informações se comparado a todas as sugestões dadas aqui, mas lembre-se também de não colocar todas essas informações porque é bonitinho ter um report cheio de informações. Ao contrário, todas as informações registradas devem ser úteis e todos devem ter ciência da utilidade delas para que haja comprometimento e responsabilidade ao preencher essas informações. Fazer com que sejam informados dados que não serão utilizados caracteriza o processo de report de defeitos como burocrático e ao contrário, é talvez essa seja essência da produção do teste.