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.

Do forno: TestLink 1.8.3

Pros que usam TestLink, saiu ontem a versão minor 1.8.3 com alguns bug fixes.

Lista de Bug Fixes e link para download aqui.

O TestLink é uma ferramenta de gerenciamento de testes open source, com interface web based em php e bancos MySQL, Postgress ou MS-SQL. Pode ser integrado com Bugzilla, Mantis..

Para conhecer um pouco mais das features da ferramenta, clique aqui.

Nós pensamos diferente

Ou deveríamos, pelo menos :)

Estava há pouco lendo um artigo no Sticky Minds sobre essa capacidade de olhar de maneira diferente para as coisas. O artigo é o Are you set in your ways da Naomi Karten. Ele fala sobre um livro, o Why We Make Mistakes do Joseph Hallinan.



O livro tras explicações através de situações reais sobre como lembrar de algo que você escondeu, porque homens cometem erros e mulheres não (essa frase foi tirada do site do livro hehehehe), porque realizar várias tarefas ao mesmo tempo não é uma boa idéia, etc.



Há uma passagem do livro no site, em que um homem agride outro que estava numa cadeira de rodas, mas só percebe isso depois que o cara já estava longe. Ele olhou para o outro homem, mas não percebeu a cadeira de rodas (leia a passagem para entender). E quantas vezes não nos deparamos com errinhos que ‘vimos, mas não vimos’? Acho que esse é um bom gancho para falar da importância de revisões.



Mesmo passando corretores ortográficos nos nossos textos, mesmo lendo e relendo-os, há sempre a probabilidade de ter um erro que passamos por ele várias e várias vezes e não conseguimos enxergar. Por isso é importante o olhar de ‘alguém de fora’. Alguém que não participou desse desenvolvimento e que vai ter uma mente analítica para definir se tudo o que está escrito está correto, coerente e entendível.



Outro gancho do texto é a mente do testador (profissional de teste em geral). Um desenvolvedor pode ser um testador? Até pode. Mas não com a mente de desenvolvedor. Ele precisa trocar o chapéu e mudar uma chave no cérebro também. Calma, calma, não estou questionando a capacidade dos desenvolvedores, muito pelo contrário. Acho que muitos que conheci são capazes sim de testar adequadamente, mas o pensamento tem que ser diferente. O testador olha diferente pros requisitos. E fora isso, como eu comentei no post passado, ele precisa ter uma visão de agregar valor. Se algo pode ser melhorado, é papel de todo o time ver isso e sugerir, mas isso fica ainda mais fácil para a equipe de testes que está vendo o programa rodar, que está pensando e agindo como se fosse um usuário.



Não li o livro citado acima, mas parece bem interessante. Para quem tiver interesse:

Amazon

Cultura


E outro artigo interessante da Naomi sobre o mesmo assunto What organizations can learn (not to do) from six-year-olds

Você não é simplesmente um profissional de TI

Chamativo o título? :)

Se você trabalha desenvolvendo software, você é um realizador de sonhos. Isso mesmo, bem filosófico, mas já parou para pensar o que REALMENTE você realiza? Esse projeto que você está exatamente agora serve pra que? Que serve pra que? Que serve pra que? (...) No fim, projetos são sonhos, ou partes de sonhos (sejam eles bons ou maus, não vou entrar nesse mérito).

O ponto que quero chegar é que deveríamos estar preocupados muito mais com o valor que estamos gerando a partir das nossas atividades do que somente (não que isso não seja essencial) realizá-las com perfeccionismo.



Um caso verídico :)

O cliente teve problemas com um fornecedor A e sondou seu outro fornecedor B ( \o/ )sobre uma possível re-análise do trabalho realizado por eles. Fui consultada nesse momento sobre a atividade e as minhas considerações.

A primeira resposta foi “Olha.. Se é simplesmente pra deixar o pessoal alocado, com atividades, é isso sim. Se for para deixar o cliente feliz, se for pra atender o que ele realmente quer, vai precisar de mais algumas outras coisas.” Ah! Isso é um problema muito sério, de tirar sono e dar muita dor de cabeça. É um verdadeiro trabalho de vidente (obviamente carregado de experiência) entregar pro cliente o que ele quer, especialmente porque num grande número de casos, nem ele sabe.



Ok, falando praticamente. O fornecedor fez um trabalho de especificação de negócio, geração de documento de padrões, casos de uso, e mais outros artefatos. Até ai parece perfeito. Exceto pela qualidade da documentação produzida que ficou deixando a desejar bastante, com requisitos que não aparecem nos casos de uso e outras atrocidades.

A pergunta era: podemos fazer uma reengenharia dos casos de uso e elaborar um documento de requisito de acordo com os nossos padrões?

Resposta de alguém focado em suas atividades, sem olho no cliente (por melhor técnico que seja): Sim.

Resposta dada: Que dá, dá. Mas pra que o cliente quer isso? Por mais que não esteja nos nossos padrões, eles têm uma especificação. A gente vai formatar dentro do template? Fazer trabalho de formatação e era isso? Porque não dá se basear só nos UCs, já que tem informação faltando neles. É melhor se basear no documento de especificação de negócio, ou seja, transcrevê-lo pro template. (Vulgo trabalho burro)

P.: Ok, e o que você sugere?

R.: Qual é o problema? Do que o cliente ta sentindo falta? Por que ele nos pediu pra fazer isso? Ele certamente não quer pagar nossas horas de consultores porque não gostou da cor do documento. Do que temos conversado em reunião e do que temos analisado com essa documentação, sabemos que o cliente não tem rastreabilidade alguma do que está sendo implementado e isso sim é um diferencial. Podemos catalogar decentemente os requisitos atribuindo IDs e outras propriedades, dentro do nosso template, mas mais que isso, podemos dar ao nosso cliente visibilidade, controle, conhecimento. Podemos dar a ele uma ferramenta de verificação se o que ele ta pedindo dos outros fornecedores está realmente sendo atendido.

Isso mesmo, uma matriz de rastreabilidade. Quem já fez isso na mão, ainda mais pra projeto grande deve estar tendo calafrios. É bem xarope mesmo. :) Feliz de quem tem ferramentas que geram isso automaticamente.

Pensem bem o valor que isso agrega! O diretor de TI do cliente XYZ tem que controlar vários fornecedores fazendo as atividades todas em separado. Um time gera especificação, outro codifica, outro gera analise de teste, outro testa e no fim o pobre do diretor não sabe se todo mundo ta usando todos os 647832483278947329 de documentos que deveriam para gerar tudo isso. O que sai no final? Só Deus sabe.

Agora imagina se ele pode ter uma ferramenta que diz pra ele: O requisito 123 está mapeado nos casos de uso A1, B2, C3 e D4. O caso de uso A1 é coberto pelos testes CTA1, CTA2, CTA3; e o B2 pelos CTB1, CTB2...

Há uma idéia bem mais concreta que o requisito realmente foi implementado. Consegue-se avaliar posteriormente o impacto de uma mudança, pode-se gerar vários indicadores como por exemplo o número de defeito por funcionalidade, avaliar a complexidade de uma funcionalidade, entre várias e várias outras coisas.

Virou um post sobre rastreabilidade :) Mas voltando ao título do post, fica um incentivo a não se limitar somente ao que lhe foi pedido para fazer. Questione, pense como fazer melhor, como gerar valor pra sua organização, pro seu cliente, pra você mesmo. Lembre-se que o que você produz vai em algum momento da cadeia estar realizando sonhos.

Teste no ciclo de vida de software

Aspectos básicos de teste

Conhecimentos avançados requerem conhecimentos básicos. Como o estudo da CTAL envolve ter na veia os conteúdos da CTFL, segue uma sessãozinha para relembrar, reforçar ou complementar a sua visão do lugar do profissional de teste no mundo (ou no ciclo de vida do software) :)



Teste no ciclo de vida de software

O teste deve estar intrínseco no ciclo de vida do software, seja ele seqüencial (cascata, V, W,...), iterativo (RAD, espiral,...) ou incremental (evolutivo, métodos ágeis,...). É essencial o alinhamento dessa disciplina com as outras como engenharia de requisitos, gerenciamento de projetos, gerencia de configuração e mudança, manutenção e desenvolvimento, documentação técnica, ...

Modelo Seqüencial:
Nesse modelo, o time irá definir os requisitos do sistema no início e depois gerenciar as “eventuais” mudanças que possam ocorrer (“eventuais” foi um eufemismo mesmo).

O time de testes pode se envolver no início do projeto planejando e projetando os testes através da análise das especificações dos requisitos para identificar condições de teste. Esse planejamento, análise e projeto realizados antecipadamente, favorecem a identificação de defeitos nos requisitos, fazendo do teste um processo mais preventivo que reativo. A detecção de falhas começaria mais tarde, quando os testes de sistema tiverem início (fim da fase de desenvolvimento).


Modelo Incremental:
Adotando uma metodologia ágil como Scrum, o time de teste não recebe o conjunto final e completo de requisitos no início do projeto (se é que recebem algum dia :) ). O time irá receber requisitos a cada 30 dias (ou como definido o sprint).

Nesse caso, o time pode, por exemplo, seguir uma estratégia baseada em riscos, identificando e priorizando áreas de risco, ajudando assim a montar os escopos dos sprints. Projetos e implementações de teste ocorrem logo após a execução, reduzindo a capacidade preventiva do teste. A detecção de falhas começa mais cedo, ao final de cada sprint, e continua repetidamente em ciclos curtos pelo projeto.

Lembrando que aplicação de Metodologia Ágil não quer dizer abolição de documentação!!


(Um parêntesis para o Gerenciamento de Configuração)

Independente do ciclo de vida adotado, gerenciamento de configuração e mudança é crucial para o teste. Falhas nesse processo podem resultar no impedimento de realização dos testes, invalidando as impressões sobre o que realmente está acontecendo no sistema. Pode resultar na perda de uma mudança, na impossibilidade de acertadamente definir o que foi testado e em que ponto foi testado e por em dúvida a confiabilidade do teste.

Saiu na Testing Experience uma matéria sobre isso. Bem cara de pau, eu vou copiar o início da matéria para dar o gostinho:

“A lei número 1 da Engenharia de Software é: ’Não importa onde você está no ciclo de vida do sistema, o sistema irá mudar, e o desejo de mudá-lo persistirá por todo o ciclo’ – Bersoff, et al, 1980"

A matéria está na 6ª edição!


Níveis de teste introduzidos no Syllabus Advanced

No Syllabus Advanced, são introduzidos os níveis de teste:

- Hardware-Software integration testing

- System integration testing

- Feature interaction testing

- Customer Product integration testing

E cada nível (não só esses, mas também todos os outros do Syllabus Foundation) deve ter:

- Objetivos

- Escopo

- Rastreabilidade para a base de teste

- Critérios de entrada e saída

- Artefatos 'entregáveis', incluindo relatórios

- Técnicas de teste

- Métricas e medidas

- Ferramentas de teste

- Conformidade com os padrões da organização e outros padrões




E assim termina o primeiro resuminho da introdução do syllabus (também com base no Advanced Software Testing Vol.1 do Rex Black.