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).
quinta-feira, 27 de agosto de 2009
sexta-feira, 21 de agosto de 2009
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.
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.
segunda-feira, 17 de agosto de 2009
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)
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)
terça-feira, 4 de agosto de 2009
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.
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.
Assinar:
Postagens (Atom)