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).
Mostrando postagens com marcador defeitos. Mostrar todas as postagens
Mostrando postagens com marcador defeitos. Mostrar todas as postagens
quinta-feira, 27 de agosto de 2009
segunda-feira, 22 de junho de 2009
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 :)
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.
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.
Assinar:
Postagens (Atom)