Estou de volta. Dei um tempo no blog para organizar o casamento, sair de férias e quando voltei, voltei no projeto a mil! Agora em 2011, espero retomar o pique dos posts.
Primeiro, um 2011 cheio de realizações para todos! :)
E falando em realizações e conquistas, em 2010 eu tirei a CTAL-TA. Quando criei o blog, a idéia era ir me preparando para a prova e postando aqui o material que eu ia lendo e compartilhando esse preparo, mas muitas coisas aconteceram. O trabalho não deu muita folga e mesmo o m eu planejamento inicial não foi muito seguido.
O que eu usei para me preparar? Apenas li o livro Advanced Software Testing do Rex Black que indiquei aqui no blog.
O livro é bem legal. O ponto que ele peca um pouco, em minha opinião, é no detalhamento de resoluções de questões relativas a técnicas de análise. No mais, é um excelente guia.
Não li o Syllabus. Mas não recomendo essa prática, afinal é o material oficial da CTAL.
Sobre simulados, baixei alguns no VTB (Vietnamese Testing Board), mas só resolvi um que tinha gabarito. Não vejo sentido em resolver sem ter certeza se está correto ou não.
Eu achei os simulados do Advanced Software Testing bem legais. Pra CTFL também só usei o Foundations of Software Testing.
O que eu achei do nível da prova? Tem perguntas bem fáceis, como as questões de ética e questões sobre definição de PDCA, auditoria, etc. Tem perguntas mais chatinhas de responder como quantidade de testes que devem ser feitos em determinado cenário aplicando as técnicas A e B (tem essas perguntas para treinar no Advanced Software Testing).
Quais pontos eu acho que fui pior e podia ter me dedicado mais? Tem várias normas citadas no livro. Não só as IEEE e ISO, mas também as BS e DO. Se tivesse tido mais tempo para estudar teria baixado as normas e lido.
Quanto tempo eu dediquei para estudar? Comecei o blog em maio/2009, mas não posso dizer que venho estudando desde então. Li o livro até a parte de Análise por Valor Limite, que eu postei em março/2010. Depois parei de ler o livro. Ainda não haviam marcado a CTAL no Brasil, eu estava sem perspectiva de fazer a prova fora do BSTQB e sem um prazo, fiquei desmotivada. Quando voltei de viagem de lua de mel, estava na última semana para me inscrever na prova e só depois da confirmação retomei a minha leitura. Mas como havia iniciado há muito tempo, resolvi começar do começo. Lógico que não deu tempo de ler o livro inteiro. Li até o quarto capitulo, e os seguintes eu apenas resolvi as questões do simulado que tem no final. No total eu diria que foi algo em torno de 1 mês se eu fosse por em tempo produtivo.
Qual a minha visão geral da prova? Assim como a CTFL, acredito que se você é uma pessoa que freqüenta eventos de teste, está atualizado com os conceitos, técnicas, anda visitando os blogs, participando de listas de discussão, não fica acomodado em mundos que muitas vezes são restritos no trabalho, há grandes chances de passar sem surtar estudando. Claro que vale a pena dedicar um tempo para o estudo, não é uma prova tão trivial quanto a CTFL. Se você não achou a CTFL fácil, então estude o dobro pra CTAL, senão não passa.
O que eu recomendo? Já me mandaram emails perguntando isso. Bom, primeiro eu fiz um relato de como foi PRA MIM. Não quer dizer que vai ser assim para todos. Outros que fizeram a CTAL podem ter opiniões diferentes, claro. Não recomendo fazer o meu plano de estudo (até porque não segui nenhum). Recomendo o leitura do Syllabus, do Advanced Software Testing e resolução de simulados, que como comentei tem alguns no Vietnamese Testing Board. Também acho um bom caminho se preparar como se fosse fazer o ISEB Intermediate. Eu não fiz essa prova, mas pode ser um bom passo intermediário para quem quer ter mais certeza do seu preparo antes da CTAL. O ISEB segue a mesma linha do ISTQB e a CTFL vale como certificação inicial para ambos os boards.
É isso. Boa sorte para o pessoal que vai fazer a CTAL na próxima prova.
Mostrando postagens com marcador CTAL. Mostrar todas as postagens
Mostrando postagens com marcador CTAL. Mostrar todas as postagens
domingo, 2 de janeiro de 2011
terça-feira, 2 de março de 2010
Partição por Equivalência
TÉCNICAS DE TESTE DE SOFTWARE
A cada nova técnica apresentada, vou sempre bater na mesma tecla: Seria muito bom que pudessemos testar todas as combinações possíveis de valores durante os nossos testes. Talvez isso nos desse mais segurança de que realmente testamos 100% o software e que ele está 100% funcional de acordo com as especificações e expectativas do cliente. Sabemos entretanto que para a esmagadora maioria de casos que conhecemos, é impossível testar 100% um software.
As tecnicas de software existem para melhorar a nossa seleção de testes. Para classificar e agrupar possibilidades de teste que otmizem o nosso processo, sem que tenhamos a sensação de estar deixando buracos imensos sem cobertura de testes nos sistemas.
PARTIÇÃO POR EQUIVALÊNCIA
Partição por Equivalência é uma técnica de projeto de teste do tipo “Specification-based”, na qual os testes são projetados para executar partes representativas de partições. E a princípio, espera-se que ao menos uma classe de cada partição seja representada ao menos uma vez durante os testes.
A figura acima explica visualmente a definição dada.
Começamos selecionando um set de interesse, como entradas, saídas, precondições, pós condições de teste ou qualquer outra coisa que achemos interessante. Feito isso, podemos separar esse set em dois ou mais sub conjuntos. Por exemplo: Imaginemos um sistema de venda que vai calcular o frete baseado na regra:
- Norte = 40,00
- Nordeste = 35,00
- Centro-Oeste = 35,00
- Sudeste (fora SP/capital) = 20,00
- SP capital = 10,00
- Sul = 35,00
Essas serão então nossas classes de teste: Norte, Nordeste, CO, Sudeste (menos SP capital), SP capital, Sul.
Fora as classes válidas, também devemos criar classes inválidas, ou seja, opções que levem a aplicação a pedir uma ação de correção por parte do usuário ou trate como uma exceção. Nesse caso, uma cidade fora do Brasil levaria provavelmente a uma mensagem informando ao usuário que não são realizadas entregas fora do território brasileiro e perguntando se ele deseja continuar com a compra informando um outro endereço válido.
A segunda parte da figura, mostra como ocorre a seleção de elementos das classes para criação dos testes. Cada teste deve ter ao menos um elemento de uma classe.
Considerando um formulário, ou mesmo o sistema de vendas mencionado acima, concluiremos que haverão N conjuntos e sub conjuntos de valores para tratarmos. Para criar um test case válido, separamos então membros das classe de equivalencia válida e para um test case inválido, separemos UM membro de UMA classe inválida e todos os demais valores selecionados devem ser válidos. Dessa forma, evitaremos que uma resposta incorreta a uma classe de equivalencia fique mascarada pelo tratamento de outra classe.
ERROS COMUNS NA APLICAÇÃO DE PARTIÇÕES POR EQUIVALÊNCIA
1. As partições devem ser distintas. Não deve ser possível que um elemento hora se comporte como na partição A e hora como na partição B.
2. Não existem partições vazias. Se ela não possui membros, ela não existe.
3. A técnica não subtrai valores. Ela os divide.
CRIANDO TESTES A PARTIR DA TÉCNICA
Supondo que os subsets X1, X2, Y1, Y2 e Y3 são complemente independentes e válidos, podemos combina-los em três testes, como mostra a figura acima. O caso, a condição X1 foi testada duas vezes. Poderia ter sido tanto ela quanto a X2. Por exemplo, poderíamos testar a solicitação de um serviço em uma empresa de computadores. Poderiamos ter então as condições de contrato dentro ou fora da garantia (ambos os casos são válidos, mas um cobra pelo serviço e o outro não), e a localidade do comprador para definir que prestador de serviço irá atendê-lo que pode ser Porto Alegre, Grande Porto Alegre ou Outras cidades do RS. São variáveis independentes entre si que podem ser combinadas como na imagem acima resultado nos testes:
TC1: Contrato Dentro da Garantia para Porto Alegre
TC2: Contrato Fora da Garantia para Grande Porto Alegre
TC3: Contrato Dentro da Garantia para Outras Cidades do RS
Nem sempre as nossas combinações serão apenas de valores de valores independentes entre si. Um valor pode ser restritivo em relação a outro subset, gerando combinações inválidas.
Agora a seguinte situação. Temos um sistema de impressão de imagens. X é a paleta de cores dela. X1 = normal, X2 = escala de cinza , X3 = sepia (aquelas amareladas). Y é a qualidade que nesse caso pode ser Y1 = para impressão, Y2 = para web. Z é a impressora utilizada, sendo Z1 = preto e branco e Z2 = colorida
Os TCS criados para exemplo foram:
TC1: Foto colorida com resolução para impressão na impressora colorida
TC2: Foto preta e branca com resolução para web na impressora preto e branco
TC3: Foto sepia com resolução para impressão na impressora colorida
TC4: Foto colorida (ou sepia) com resolução para web na impressora preto e branco
O último caso deve ser inválido de acordo com regras da aplicação que não permitirá a impressão de fotos coloridas em uma impressora preto e branco.
Devemos começar com pelo menos 1 caso de teste inválido por set para verificarmos que cada conjunto é validado como deveria. Feito isso, você pode testar combinações de inválidos se for o caso. Mas lembre-se da importância de testa-los primeiro em separado para identificar o comportamento específico para o conjunto.
Fonte: Advanced Software Testing Vol.1 - Rex Black
Ver também:
Overview Tipos de Técnicas de Teste
Análise por Valor Limite
A cada nova técnica apresentada, vou sempre bater na mesma tecla: Seria muito bom que pudessemos testar todas as combinações possíveis de valores durante os nossos testes. Talvez isso nos desse mais segurança de que realmente testamos 100% o software e que ele está 100% funcional de acordo com as especificações e expectativas do cliente. Sabemos entretanto que para a esmagadora maioria de casos que conhecemos, é impossível testar 100% um software.
As tecnicas de software existem para melhorar a nossa seleção de testes. Para classificar e agrupar possibilidades de teste que otmizem o nosso processo, sem que tenhamos a sensação de estar deixando buracos imensos sem cobertura de testes nos sistemas.
PARTIÇÃO POR EQUIVALÊNCIA
Partição por Equivalência é uma técnica de projeto de teste do tipo “Specification-based”, na qual os testes são projetados para executar partes representativas de partições. E a princípio, espera-se que ao menos uma classe de cada partição seja representada ao menos uma vez durante os testes.
A figura acima explica visualmente a definição dada.
Começamos selecionando um set de interesse, como entradas, saídas, precondições, pós condições de teste ou qualquer outra coisa que achemos interessante. Feito isso, podemos separar esse set em dois ou mais sub conjuntos. Por exemplo: Imaginemos um sistema de venda que vai calcular o frete baseado na regra:
- Norte = 40,00
- Nordeste = 35,00
- Centro-Oeste = 35,00
- Sudeste (fora SP/capital) = 20,00
- SP capital = 10,00
- Sul = 35,00
Essas serão então nossas classes de teste: Norte, Nordeste, CO, Sudeste (menos SP capital), SP capital, Sul.
Fora as classes válidas, também devemos criar classes inválidas, ou seja, opções que levem a aplicação a pedir uma ação de correção por parte do usuário ou trate como uma exceção. Nesse caso, uma cidade fora do Brasil levaria provavelmente a uma mensagem informando ao usuário que não são realizadas entregas fora do território brasileiro e perguntando se ele deseja continuar com a compra informando um outro endereço válido.
A segunda parte da figura, mostra como ocorre a seleção de elementos das classes para criação dos testes. Cada teste deve ter ao menos um elemento de uma classe.
Considerando um formulário, ou mesmo o sistema de vendas mencionado acima, concluiremos que haverão N conjuntos e sub conjuntos de valores para tratarmos. Para criar um test case válido, separamos então membros das classe de equivalencia válida e para um test case inválido, separemos UM membro de UMA classe inválida e todos os demais valores selecionados devem ser válidos. Dessa forma, evitaremos que uma resposta incorreta a uma classe de equivalencia fique mascarada pelo tratamento de outra classe.
ERROS COMUNS NA APLICAÇÃO DE PARTIÇÕES POR EQUIVALÊNCIA
1. As partições devem ser distintas. Não deve ser possível que um elemento hora se comporte como na partição A e hora como na partição B.
2. Não existem partições vazias. Se ela não possui membros, ela não existe.
3. A técnica não subtrai valores. Ela os divide.
CRIANDO TESTES A PARTIR DA TÉCNICA
Supondo que os subsets X1, X2, Y1, Y2 e Y3 são complemente independentes e válidos, podemos combina-los em três testes, como mostra a figura acima. O caso, a condição X1 foi testada duas vezes. Poderia ter sido tanto ela quanto a X2. Por exemplo, poderíamos testar a solicitação de um serviço em uma empresa de computadores. Poderiamos ter então as condições de contrato dentro ou fora da garantia (ambos os casos são válidos, mas um cobra pelo serviço e o outro não), e a localidade do comprador para definir que prestador de serviço irá atendê-lo que pode ser Porto Alegre, Grande Porto Alegre ou Outras cidades do RS. São variáveis independentes entre si que podem ser combinadas como na imagem acima resultado nos testes:
TC1: Contrato Dentro da Garantia para Porto Alegre
TC2: Contrato Fora da Garantia para Grande Porto Alegre
TC3: Contrato Dentro da Garantia para Outras Cidades do RS
Nem sempre as nossas combinações serão apenas de valores de valores independentes entre si. Um valor pode ser restritivo em relação a outro subset, gerando combinações inválidas.
Agora a seguinte situação. Temos um sistema de impressão de imagens. X é a paleta de cores dela. X1 = normal, X2 = escala de cinza , X3 = sepia (aquelas amareladas). Y é a qualidade que nesse caso pode ser Y1 = para impressão, Y2 = para web. Z é a impressora utilizada, sendo Z1 = preto e branco e Z2 = colorida
Os TCS criados para exemplo foram:
TC1: Foto colorida com resolução para impressão na impressora colorida
TC2: Foto preta e branca com resolução para web na impressora preto e branco
TC3: Foto sepia com resolução para impressão na impressora colorida
TC4: Foto colorida (ou sepia) com resolução para web na impressora preto e branco
O último caso deve ser inválido de acordo com regras da aplicação que não permitirá a impressão de fotos coloridas em uma impressora preto e branco.
Devemos começar com pelo menos 1 caso de teste inválido por set para verificarmos que cada conjunto é validado como deveria. Feito isso, você pode testar combinações de inválidos se for o caso. Mas lembre-se da importância de testa-los primeiro em separado para identificar o comportamento específico para o conjunto.
Fonte: Advanced Software Testing Vol.1 - Rex Black
Ver também:
Overview Tipos de Técnicas de Teste
Análise por Valor Limite
domingo, 20 de dezembro de 2009
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 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
quinta-feira, 27 de agosto de 2009
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).
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).
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)
domingo, 5 de julho de 2009
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
**
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
sexta-feira, 5 de junho de 2009
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.
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.
sexta-feira, 29 de maio de 2009
Testing Experience Magazine – The new ISTQB® Certified Tester Advanced Level Focus on practical know-how by Professor Mario Winter
Notícia quentinha, saída do forno! Saiu a sexta edição da Testing Experience. Pra quem não conhece ainda, trata-se de uma revista especializada em teste de software de periodicidade trimestral, com artigos bastante interessantes. Para pegar a sua, basta se inscrever no site e fazer o download free da versão virtual.
Resumo da 6ª edição
A última matéria da revista é a que dá título a esse post, escrita por Mario Winter que dentre os vários itens interessantes do seu currículo, guarda o título de membro fundador do Board da Alemanha.
A matéria é bem focada na realidade da Alemanha, falando sobre quando começa a ser aplicado o novo formato lá e outras informações mais direcionadas. O que eu colhi de mais significativo da matéria:
O syllabus sofreu uma modificação considerável em 2007 (comparado a versão anterior de 2003), chegando a triplicar de tamanho (de 38 para 114 páginas) e isso se deve ao cunho prático adotado nessa nova versão. Isso também significa que os cursos têm maior duração, obviamente.
O trabalho de padronização do syllabus está sendo mundial. Todos os Boards estão contribuindo e sendo afetados por essa padronização que só trás ganhos como a unificação do uso de terminologias específicas em projetos offshore.
O uso de habilidades analíticas está sendo mais bem explorado como no exemplo dado na matéria: As figuras apresentadas indicam que determinado projeto e produto estão atrasados. Qual a explicação desse atraso e que passos devem ser tomados para recolocar o projeto no planejamento de cronograma?
As três áreas de conhecimento estão bem dividas explicitando a especialização natural da profissão. Para gerentes de teste, é necessário conhecimento para responder perguntas como ‘Como medir os benefícios do teste para o negócio?’; ‘O que é FMEA (Análise de Modo e Efeitos de Falhas) e como isso pode ser implementado?’. Para analista e analista técnico o foco se dá em técnicas baseadas em especificação, estrutura, erro e experiência; sendo o analista focado nas de especificação, erro e experiência e o técnico devendo executar bem todas elas, exceto algumas de especificação.
Também na matéria é citada uma lista de indicações de livros do site do GTB (German Testing Board) que me parece muito proveitosa. É uma excelente dica de manutenção de conhecimento.
Vale a pena dar uma conferida na revista não só por esta, mas por todas as outras matérias. E se você não a acompanhava, vale a pena passar a acompanhar.
Abs,
Resumo da 6ª edição
A última matéria da revista é a que dá título a esse post, escrita por Mario Winter que dentre os vários itens interessantes do seu currículo, guarda o título de membro fundador do Board da Alemanha.
A matéria é bem focada na realidade da Alemanha, falando sobre quando começa a ser aplicado o novo formato lá e outras informações mais direcionadas. O que eu colhi de mais significativo da matéria:
O syllabus sofreu uma modificação considerável em 2007 (comparado a versão anterior de 2003), chegando a triplicar de tamanho (de 38 para 114 páginas) e isso se deve ao cunho prático adotado nessa nova versão. Isso também significa que os cursos têm maior duração, obviamente.
O trabalho de padronização do syllabus está sendo mundial. Todos os Boards estão contribuindo e sendo afetados por essa padronização que só trás ganhos como a unificação do uso de terminologias específicas em projetos offshore.
O uso de habilidades analíticas está sendo mais bem explorado como no exemplo dado na matéria: As figuras apresentadas indicam que determinado projeto e produto estão atrasados. Qual a explicação desse atraso e que passos devem ser tomados para recolocar o projeto no planejamento de cronograma?
As três áreas de conhecimento estão bem dividas explicitando a especialização natural da profissão. Para gerentes de teste, é necessário conhecimento para responder perguntas como ‘Como medir os benefícios do teste para o negócio?’; ‘O que é FMEA (Análise de Modo e Efeitos de Falhas) e como isso pode ser implementado?’. Para analista e analista técnico o foco se dá em técnicas baseadas em especificação, estrutura, erro e experiência; sendo o analista focado nas de especificação, erro e experiência e o técnico devendo executar bem todas elas, exceto algumas de especificação.
Também na matéria é citada uma lista de indicações de livros do site do GTB (German Testing Board) que me parece muito proveitosa. É uma excelente dica de manutenção de conhecimento.
Vale a pena dar uma conferida na revista não só por esta, mas por todas as outras matérias. E se você não a acompanhava, vale a pena passar a acompanhar.
Abs,
quinta-feira, 28 de maio de 2009
CTAL Inside
A certificação Advanced Level da ISTQB é direcionada para pessoas que já tem experiência em teste de software (testadores, analistas, gerente, consultores de teste) ou que estejam interessadas em aprofundar seus conhecimentos na área (gerentes de projeto, de desenvolvimento, de qualidade, analistas, diretores de TI). Para ter a certificação é necessário ter a CTFL e atender aos requisitos do Exam Board que valida se o candidato tem experiência prática suficiente para ser considerado um profissional Advanced Level (3 anos de experiência em teste de software, desenvolvimento, garantia da qualidade ou similar).
Taxas (Aplicadas nos Estados Unidos):
US$200,00 para a prova e US$100,00 para o exame de qualificação
Especialidades
* Advanced Level Test Analyst
* Advanced Level Test Manager
* Advanced Level Technical Test Analyst
Objetivos da certificação
Assegurar entendimento e execução de técnicas atuais e inovadoras por profissionais de teste experientes
Apoiar/Incentivar o desenvolvimento profissional
Servir de guia na profissão de teste
Conhecimentos avaliados
Técnicas avançadas de testes funcionais para testadores e programadores, conceitos contemporâneos de gerenciamento de testes, melhoria de processo, automação de testes, performance, usabilidade e outros tipos de testes não funcionais.
Cursos
Segundo o ASTQB, um curso para as 3 especialidades levaria em torno de 15 a 20 dias de duração. Que eu conheça, não tem cursos para CTAL no Brasil ainda. :)
A prova
São 65 questões do tipo múltipla escolha
É necessária pontuação acima ou igual a 65%
O tempo de prova é de 3h
Hoje no Brasil a prova não é aplicada, como comentei no post anterior. A BSTQB está em processo de tradução do syllabus.
Sugestão: Acompanhar a lista de discussão da BSTQB
Processo de certificação (descrito no ASTQB)
É recomendado inscrever-se com alguns dias de antecedência para que sejam avaliadas as documentações. Será paga a taxa de qualificação e deve ser enviada uma cópia do certificado da CTFL e um currículo ou comprovação da experiência de 3 anos ou mais na área, como citado acima.
O candidato será informado da sua aceitação, assim como o centro de exames. Se o candidato estiver em treinamento, o centro de treinamento também será informado.
Se o processo de avaliação não for completado até a data de aplicação da prova, o candidato poderá fazer a prova desde que tenham sido pagas as taxas de qualificação e da prova. Entretanto o resultado só será divulgado após a avaliação de qualificação.
Se o candidato não passar na qualificação, o valor pago não será devolvido, entretanto essa taxa servirá como crédito para futuras tentativas de realização do exame.
Fonte: http://www.astqb.org/
Taxas (Aplicadas nos Estados Unidos):
US$200,00 para a prova e US$100,00 para o exame de qualificação
Especialidades
* Advanced Level Test Analyst
* Advanced Level Test Manager
* Advanced Level Technical Test Analyst
Objetivos da certificação
Assegurar entendimento e execução de técnicas atuais e inovadoras por profissionais de teste experientes
Apoiar/Incentivar o desenvolvimento profissional
Servir de guia na profissão de teste
Conhecimentos avaliados
Técnicas avançadas de testes funcionais para testadores e programadores, conceitos contemporâneos de gerenciamento de testes, melhoria de processo, automação de testes, performance, usabilidade e outros tipos de testes não funcionais.
Cursos
Segundo o ASTQB, um curso para as 3 especialidades levaria em torno de 15 a 20 dias de duração. Que eu conheça, não tem cursos para CTAL no Brasil ainda. :)
A prova
São 65 questões do tipo múltipla escolha
É necessária pontuação acima ou igual a 65%
O tempo de prova é de 3h
Hoje no Brasil a prova não é aplicada, como comentei no post anterior. A BSTQB está em processo de tradução do syllabus.
Sugestão: Acompanhar a lista de discussão da BSTQB
Processo de certificação (descrito no ASTQB)
É recomendado inscrever-se com alguns dias de antecedência para que sejam avaliadas as documentações. Será paga a taxa de qualificação e deve ser enviada uma cópia do certificado da CTFL e um currículo ou comprovação da experiência de 3 anos ou mais na área, como citado acima.
O candidato será informado da sua aceitação, assim como o centro de exames. Se o candidato estiver em treinamento, o centro de treinamento também será informado.
Se o processo de avaliação não for completado até a data de aplicação da prova, o candidato poderá fazer a prova desde que tenham sido pagas as taxas de qualificação e da prova. Entretanto o resultado só será divulgado após a avaliação de qualificação.
Se o candidato não passar na qualificação, o valor pago não será devolvido, entretanto essa taxa servirá como crédito para futuras tentativas de realização do exame.
Fonte: http://www.astqb.org/
quarta-feira, 20 de maio de 2009
Apresentação do Blog - CTAL
Bem vindos ao Ensaios de Qualidade
O objetivo desse blog pra mim é o de aprender um pouco mais tentando passar alguns conhecimentos e experiências na área de qualidade de software, especialmente testes de software.
O motor de início é a CTAL, certificação de testes para a qual estou estudando no momento. Antes de falar sobre a certificação e essa escolha, quero indicar um post bastante famoso do Fábio Martinho com um resumo das principais certificações da área no mercado no site Test Expert
CTAL (Certified Tester Advanced Level) é a certificação do ISTQB para níveis avançados. São oferecidas as especialidades ‘Test Analyst’, ‘Test Manager’ e ‘Technical Test Analyst’. O conjunto dessas três certificações dá ao profissional o diploma CTAL Full Advanced Level. O meu foco, por hora, será na especialidade Test Analyst e como base de estudos, fora o syllabus, estou usando o livro Guide to the ISTQB Advanced Certification as an Advanced Test Analyst do Rex Black
E como se faz pra tirar essa certificação?
O primeiro passo é tirar a CTFL, que é a certificação Foundation Level da ISTQB. No Brasil, ela é aplicada pelo BSTQB ou pela ISEB através de um centro Prometric.
E, segundo o ASTQB, três anos de experiência comprovada em teste de software, desenvolvimento, garantia da qualidade, engenharia de sistemas ou funções relacionadas.
E porque eu estou usando o ASTQB como referência e não o BSTQB? Porque atualmente nenhuma CTAL é aplicada no Brasil. Ao que venho acompanhando, o syllabus está em processo de tradução. A minha expectativa é poder fazer essa certificação ainda esse ano. Caso os planos mudem, com certeza vai dar pra acompanhar por aqui. :)
E dentre todas aquelas certificações que o Fábio apresentou no post dele, porque eu escolhi a CTAL? Bem, antes de escolher a CTAL, na realidade eu escolhi a CTFL. Eu precisava de uma certificação em testes por uma demanda profissional e além de ser uma certificação internacional, eu tinha a comodidade de escolher quando fazer a CTFL, já que é possível fazer a prova por um centro Prometric. Então providenciei um material para estudar: Foundations of Software Testing: ISTQB Certification de Dorothy Graham, Erik Van Veenendaal, Isabel Evans e Rex Black, agendei a prova e já sai na hora com o meu resultado da sala.
Os estudos então continuam e o próximo objetivo é a CTAL. Espero que a manutenção do blog além de me ajudar a focar nos estudos para a certificação, possa ajudar os transeuntes com alguns assuntos interessantes que pretendo compartilhar nesse canal.
Abs,
O objetivo desse blog pra mim é o de aprender um pouco mais tentando passar alguns conhecimentos e experiências na área de qualidade de software, especialmente testes de software.
O motor de início é a CTAL, certificação de testes para a qual estou estudando no momento. Antes de falar sobre a certificação e essa escolha, quero indicar um post bastante famoso do Fábio Martinho com um resumo das principais certificações da área no mercado no site Test Expert
CTAL (Certified Tester Advanced Level) é a certificação do ISTQB para níveis avançados. São oferecidas as especialidades ‘Test Analyst’, ‘Test Manager’ e ‘Technical Test Analyst’. O conjunto dessas três certificações dá ao profissional o diploma CTAL Full Advanced Level. O meu foco, por hora, será na especialidade Test Analyst e como base de estudos, fora o syllabus, estou usando o livro Guide to the ISTQB Advanced Certification as an Advanced Test Analyst do Rex Black
E como se faz pra tirar essa certificação?
O primeiro passo é tirar a CTFL, que é a certificação Foundation Level da ISTQB. No Brasil, ela é aplicada pelo BSTQB ou pela ISEB através de um centro Prometric.
E, segundo o ASTQB, três anos de experiência comprovada em teste de software, desenvolvimento, garantia da qualidade, engenharia de sistemas ou funções relacionadas.
E porque eu estou usando o ASTQB como referência e não o BSTQB? Porque atualmente nenhuma CTAL é aplicada no Brasil. Ao que venho acompanhando, o syllabus está em processo de tradução. A minha expectativa é poder fazer essa certificação ainda esse ano. Caso os planos mudem, com certeza vai dar pra acompanhar por aqui. :)
E dentre todas aquelas certificações que o Fábio apresentou no post dele, porque eu escolhi a CTAL? Bem, antes de escolher a CTAL, na realidade eu escolhi a CTFL. Eu precisava de uma certificação em testes por uma demanda profissional e além de ser uma certificação internacional, eu tinha a comodidade de escolher quando fazer a CTFL, já que é possível fazer a prova por um centro Prometric. Então providenciei um material para estudar: Foundations of Software Testing: ISTQB Certification de Dorothy Graham, Erik Van Veenendaal, Isabel Evans e Rex Black, agendei a prova e já sai na hora com o meu resultado da sala.
Os estudos então continuam e o próximo objetivo é a CTAL. Espero que a manutenção do blog além de me ajudar a focar nos estudos para a certificação, possa ajudar os transeuntes com alguns assuntos interessantes que pretendo compartilhar nesse canal.
Abs,
Assinar:
Postagens (Atom)