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.
domingo, 2 de janeiro de 2011
segunda-feira, 16 de agosto de 2010
Testar sem documentação é possível?
Essa é a minha contribuição para o livro do DFTestes.
Falei um pouco sobre a problemática da falta de documentação para a equipe de testes.
Confiram outros capítulos na página do livro.
1. Introdução
De acordo com o RUP, caso de teste "é a definição (geralmente formal) de um conjunto específico de inputs de teste, condições de execução e resultados esperados, identificados com a finalidade de avaliar um determinado aspecto de um item de Teste-alvo". Duas disciplinas da Engenharia de Software provêem informações para criação dos casos de teste. São elas: Engenharia de Requisitos e Projeto.
De acordo com o IEEE, a Engenharia de Requisitos é o processo de aquisição, refinamento e verificação das necessidades do cliente. Dentro das diversas metodologias de desenvolvimento há maneiras distintas de documentar requisitos. No RUP, o principal documento gerado, que é utilizado pela equipe de teste, são os Modelos de Caso de Uso; já nas metodologias ágeis, um documento mais comum é o conjunto de User Stories. Na prática, muitas equipes não têm nem os Casos de Uso e nem as User Stories, mas sim, descrições em alto nível dos requisitos, sejam elas por escrito ou não.
A disciplina de Projeto, por sua vez gera documentos complementares às especificações de Requisitos. Nessa etapa, a estrutura interna do software é descrita através de diagramas. A utilização da linguagem UML é bastante recomendada na geração desses diagramas. Exemplos de diagramas de projeto são Diagramas de Estados, Diagramas de Seqüência e Diagrama de Atividades, entre outros.
Essa documentação serve como apoio para a elaboração dos testes. Todas elas são de grande valia para o analista no seu projeto de casos de teste. Mas e se o analista não as tiver? É possível, mesmo assim, testar? Essa é a pergunta tema da Nona Mesa Redonda do DFTestes.
Esse tema nos fez refletir sobre a necessidade da documentação para o teste. Primeiramente não vamos confundir necessidade com importância. Denotativamente o termo necessidade significa uma obrigação imprescindível, enquanto que importância ou relevância significa valor.
As participações nessa mesa redonda são freqüentemente utilizadas no texto que segue para expressar a opinião da comunidade sobre o assunto.
2. Testes Exploratórios
É possível sim testar sem scripts e isso já não se pode chamar de novidade. O termo "testes exploratórios" foi citado pela primeira vez por Cem Kaner em seu livro Testing Computer Software (1999).
Segundo James Bach, testes exploratórios são simultaneamente um aprendizado, um projeto e uma execução de teste. Através da profunda exploração das habilidades de ouvir, ler, pensar e reportar eficazmente, os testes exploratórios podem trazer informações muito importantes de maneira tão ou mais produtiva que os testes baseados em casos de teste. A falta de um script a ser seguido tende a potencializar essas habilidades.
3. Escolas de Teste
Sobre a documentação em que iremos embasar a criação dos casos de teste, o Jorge Diz disse: "não coloquemos todas as nossas fichas na documentação do sistema. Com certeza, é possível testar sem documentação formal: pode ser mais ou menos eficaz, dependendo do contexto. E sempre devemos lembrar que o documento mais atualizado é sempre o próprio sistema sendo testado."
O contexto! Esse é o grande segredo dessa discussão. A eficácia do seu teste pode ou não ser impactada pela falta de documentação considerando diversos cenários. É papel do analista de testes sinalizar até que ponto ele consegue aferir a qualidade do sistema com as ferramentas (documentação, especialista, etc.) que lhe foram dadas.
Dentro das Escolas de Teste, veremos que de acordo com as características de cada escola (um contexto), o tema "testar sem documentação é possível?" é tratado de maneiras diferentes.
De acordo com Pettichord (2007), uma escola é definida por afinidades intelectuais, interação social e objetivos comuns. São compostas por uma hierarquia de valores, técnicas, padrões de crítica, instituições organizadas e vocabulário comum.
Existem cinco escolas de teste e suas visões são:
Escola Analítica: o teste deve ser rigoroso e técnico, com base na academia
Escola Padrão: o teste é uma maneira de medir o progresso com ênfase no custo e padrões repetíveis
Escola da Qualidade: enfatiza o processo e policia os desenvolvedores
Escola baseada em Contexto: enfatiza as pessoas, procuram bugs com os quais os clientes se importam mais
Escola Ágil: usa o teste para provar que o desenvolvimento está completo. Enfatiza o teste automatizado
Sobre os testes sem documentação, são a favor:
Escola baseada em Contexto: "Faça o que puder para ser útil. Faça perguntas se necessário. Desencave especificações escondidas."
Escola Ágil: "Conversas são mais importantes que documentação"
E são contra:
Escola Analítica: "É impossível"
Escola Padrão: "Algum tipo de documentação é necessária"
Escola da Qualidade: "Force os desenvolvedores a seguir o processo"
Como cada escola vive um contexto e analisa o teste de acordo com os seus cenários, cada uma expressa uma visão diferente da possibilidade de testar sem documentação. Na visão geral dos participantes da discussão, testar sem documentação não é impossível, mas essa abordagem também não foi defendida como a melhor prática. A comunidade do DFTestes parece ter uma tendência muito próxima a da Escola baseada em Contexto, entendendo que não devemos olhar as nossas dificuldades de documentação como muros intransponíveis, mas como empecilhos que devem ser vencidos.
4. Reflexões da Mesa Redonda
"À medida que os sistemas se tornam mais complexos, os riscos se tornam maiores, chegando ao ponto no qual ninguém conhece o que há no sistema. Isto é ruim não só para o teste, mas também para todas as fases anteriores do desenvolvimento.
Falando de casos de uso ou similares, um dos problemas comuns de quem não tem essa documentação é o de não saber o que testar. Recentemente fiz uma análise de cobertura de código em um programa de pedidos e concluí que ao incluir um pedido neste sistema com o máximo de opções que consegui informar, não cobri nem 20% do código. Se você não tem nada para consultar, como testar os outros 80% de forma eficiente? Agora imaginem se este programa estivesse 60% documentado com casos de uso e casos de teste. Já seria uma garantia bem maior.
Outro problema é o de não saber o que alterar. Recentemente em um projeto foi esquecido de alterar um programa, e só esse programa gerou mais estresse que todas as outras alterações juntas porque estava dando problema lá no cliente. Sem documentação, não há rastreabilidade." [Ismael Munchen]
Na colocação do Ismael conclui-se que:
1. Falta de documentação pode prejudicar a cobertura dos testes
2. Falta de documentação implica em falta de rastreabilidade e aumento dos riscos nas manutenções do sistema
A visão do Marcelo Andrade complementa o primeiro cenário do Ismael:
"Claro que não dá para testar tirando conclusões sobre regras de negócio da própria cabeça do testador. Neste caso, se a informação está disponível (com o cliente ou com quem quer que seja) é ela que deve ser buscada."
Então, na falta de uma documentação, caso haja alguma outra fonte de conhecimento sobre os requisitos, ela viabiliza os testes e também aumenta a sua cobertura. Essa opinião também foi expressa pela Andrea Cruz quando ela fala que "testar sem documentação é possível, porém podem existir em determinados sistemas requisitos implícitos importantes que podem não ser cobertos pelo teste."
Existe sem dúvida um risco na falta de documentação. Para ser bem sucedido, o Analista de Teste precisa contar com alguma outra fonte de informação, ou a sua cobertura poderá ser seriamente prejudicada.
Segundo Daniel Goettenauer, "o beneficio da documentação só é percebido atualmente em grandes projetos, onde os testes de regressão são constantes e existem muitas mudanças.
[...] dependendo do tamanho do projeto de teste a documentação poderia ser tratada de forma mais simples (documentos básicos) ou complexa (todos os documentos). Dessa forma não teríamos projetos desenvolvidos em 16 horas e testados em 72 horas por conta do volume de documentação."
Ter algum nível de documentação é mesmo importante, entretanto o que define sua necessidade? Uma documentação necessária é aquela que é consultada e mantida, que serve de apoio para o time ou, não se encaixando em nenhum desses objetivos, ela se torna necessária apenas se for uma requisição do cliente. Jeffries, 2001 expõe em seu blog esse mesmo ponto quando fala que "você pode precisar de um UML bem formatado para o seu projeto, ou você pode precisar imprimir o Javadoc quando distribuir o seu código para outros, ou você pode precisar documentar os requisitos para o gerenciamento ou como parte de um contrato. Se e quando você realmente precisar dessas documentações, você deve realmente tê-las." Se elas não forem realmente necessárias apenas demandam tempo da equipe e nem sempre são mantidas adequadamente.
Um sem número de documentos que são criados no início do projeto e não sofrem mais atualizações é uma realidade em muitos projetos. De acordo com o Shmuel, "uma documentação desatualizada é menos útil, mas ainda pode ser usada da mesma maneira. Mas essa ajuda não é um pré-requisito necessário, e podemos testar mesmo sem tê-la. Por meio de abstrações e inferências, é possível aprender sobre o programa de várias outras maneiras, durante os testes, durante conversas, durante as discussões sobre bugs etc.”
Essa opinião está alinhada com uma pesquisa do IEEE, 2003 em que entrevistas com engenheiros de software revelaram as seguintes opiniões sobre documentação:
"- Documento de arquitetura e outras documentações abstratas são freqüentemente válidos ou ao menos provêem um guia histórico que pode ser útil para manutenção.
- Documentações de todos os tipos freqüentemente estão desatualizadas
- Uma fração considerável da documentação não é confiável. "
O Felipe da Silva trouxe um ponto diferente sobre a necessidade e assinalou outro uso dado à documentação fora o projeto de testes que é o de contrato. É comum utilizarmos uma documentação e a aprovação do cliente como um contrato ou parte dele na definição de escopo e base para cronograma. Segundo Felipe, "na maioria dos casos além de brigarmos para querer ter um sistema testável por qualquer um, em determinados processos de engenharia de software também brigamos porque queremos ter um documento como "defesa" contra a insatisfação do cliente. É aquele problema que se você não documenta, o cliente não assina, se ele não assina, não existe um registro que ele havia dito que era aquilo que ele queria, correndo o risco do cliente reclamar e ter melhorias no sistema sem pagar por elas nem ajustar cronograma e etc."
5. Conclusão
As opiniões expostas na Mesa Redonda levaram a um entendimento de que a documentação pode não ser necessária, mas é importante. O tema é bastante abrangente e a cada participação na lista foi possível idealizar novos cenários para responder a mesma pergunta. E você? A que conclusão chegou após ler o que discutimos em mais uma edição da Mesa Redonda do DFTestes?
Participantes da Nona Mesa Redonda:
Fabrício, Shmuel Gershon, Juliana Kryszczun, Ueslei Aquino, Ana Rosa, Sarah Pimentel, Fernanda Coelho, Ismael Munchen, Daniel Goettenauer, Felipe da Silva, Cristiana Yukie, Rodrigo Almeida, Rodrigo Souza, Andrea Cruz, Marcelo Andrade e Jorge Diz.
Referências:
Much Ado About Nothing: Documentation
Ron Jeffries 2001
Schools of Software Testing
Bret Pettichord, 2007
How Software Engineers Use Documentation: The State of the Practice
Timothy C. Lethbridge, Janice Singer, Andrew Forward
IEEE Computer Society
2003
Exploratory Testing Explained
James Bach, 2003
Falei um pouco sobre a problemática da falta de documentação para a equipe de testes.
Confiram outros capítulos na página do livro.
1. Introdução
De acordo com o RUP, caso de teste "é a definição (geralmente formal) de um conjunto específico de inputs de teste, condições de execução e resultados esperados, identificados com a finalidade de avaliar um determinado aspecto de um item de Teste-alvo". Duas disciplinas da Engenharia de Software provêem informações para criação dos casos de teste. São elas: Engenharia de Requisitos e Projeto.
De acordo com o IEEE, a Engenharia de Requisitos é o processo de aquisição, refinamento e verificação das necessidades do cliente. Dentro das diversas metodologias de desenvolvimento há maneiras distintas de documentar requisitos. No RUP, o principal documento gerado, que é utilizado pela equipe de teste, são os Modelos de Caso de Uso; já nas metodologias ágeis, um documento mais comum é o conjunto de User Stories. Na prática, muitas equipes não têm nem os Casos de Uso e nem as User Stories, mas sim, descrições em alto nível dos requisitos, sejam elas por escrito ou não.
A disciplina de Projeto, por sua vez gera documentos complementares às especificações de Requisitos. Nessa etapa, a estrutura interna do software é descrita através de diagramas. A utilização da linguagem UML é bastante recomendada na geração desses diagramas. Exemplos de diagramas de projeto são Diagramas de Estados, Diagramas de Seqüência e Diagrama de Atividades, entre outros.
Essa documentação serve como apoio para a elaboração dos testes. Todas elas são de grande valia para o analista no seu projeto de casos de teste. Mas e se o analista não as tiver? É possível, mesmo assim, testar? Essa é a pergunta tema da Nona Mesa Redonda do DFTestes.
Esse tema nos fez refletir sobre a necessidade da documentação para o teste. Primeiramente não vamos confundir necessidade com importância. Denotativamente o termo necessidade significa uma obrigação imprescindível, enquanto que importância ou relevância significa valor.
As participações nessa mesa redonda são freqüentemente utilizadas no texto que segue para expressar a opinião da comunidade sobre o assunto.
2. Testes Exploratórios
É possível sim testar sem scripts e isso já não se pode chamar de novidade. O termo "testes exploratórios" foi citado pela primeira vez por Cem Kaner em seu livro Testing Computer Software (1999).
Segundo James Bach, testes exploratórios são simultaneamente um aprendizado, um projeto e uma execução de teste. Através da profunda exploração das habilidades de ouvir, ler, pensar e reportar eficazmente, os testes exploratórios podem trazer informações muito importantes de maneira tão ou mais produtiva que os testes baseados em casos de teste. A falta de um script a ser seguido tende a potencializar essas habilidades.
3. Escolas de Teste
Sobre a documentação em que iremos embasar a criação dos casos de teste, o Jorge Diz disse: "não coloquemos todas as nossas fichas na documentação do sistema. Com certeza, é possível testar sem documentação formal: pode ser mais ou menos eficaz, dependendo do contexto. E sempre devemos lembrar que o documento mais atualizado é sempre o próprio sistema sendo testado."
O contexto! Esse é o grande segredo dessa discussão. A eficácia do seu teste pode ou não ser impactada pela falta de documentação considerando diversos cenários. É papel do analista de testes sinalizar até que ponto ele consegue aferir a qualidade do sistema com as ferramentas (documentação, especialista, etc.) que lhe foram dadas.
Dentro das Escolas de Teste, veremos que de acordo com as características de cada escola (um contexto), o tema "testar sem documentação é possível?" é tratado de maneiras diferentes.
De acordo com Pettichord (2007), uma escola é definida por afinidades intelectuais, interação social e objetivos comuns. São compostas por uma hierarquia de valores, técnicas, padrões de crítica, instituições organizadas e vocabulário comum.
Existem cinco escolas de teste e suas visões são:
Escola Analítica: o teste deve ser rigoroso e técnico, com base na academia
Escola Padrão: o teste é uma maneira de medir o progresso com ênfase no custo e padrões repetíveis
Escola da Qualidade: enfatiza o processo e policia os desenvolvedores
Escola baseada em Contexto: enfatiza as pessoas, procuram bugs com os quais os clientes se importam mais
Escola Ágil: usa o teste para provar que o desenvolvimento está completo. Enfatiza o teste automatizado
Sobre os testes sem documentação, são a favor:
Escola baseada em Contexto: "Faça o que puder para ser útil. Faça perguntas se necessário. Desencave especificações escondidas."
Escola Ágil: "Conversas são mais importantes que documentação"
E são contra:
Escola Analítica: "É impossível"
Escola Padrão: "Algum tipo de documentação é necessária"
Escola da Qualidade: "Force os desenvolvedores a seguir o processo"
Como cada escola vive um contexto e analisa o teste de acordo com os seus cenários, cada uma expressa uma visão diferente da possibilidade de testar sem documentação. Na visão geral dos participantes da discussão, testar sem documentação não é impossível, mas essa abordagem também não foi defendida como a melhor prática. A comunidade do DFTestes parece ter uma tendência muito próxima a da Escola baseada em Contexto, entendendo que não devemos olhar as nossas dificuldades de documentação como muros intransponíveis, mas como empecilhos que devem ser vencidos.
4. Reflexões da Mesa Redonda
"À medida que os sistemas se tornam mais complexos, os riscos se tornam maiores, chegando ao ponto no qual ninguém conhece o que há no sistema. Isto é ruim não só para o teste, mas também para todas as fases anteriores do desenvolvimento.
Falando de casos de uso ou similares, um dos problemas comuns de quem não tem essa documentação é o de não saber o que testar. Recentemente fiz uma análise de cobertura de código em um programa de pedidos e concluí que ao incluir um pedido neste sistema com o máximo de opções que consegui informar, não cobri nem 20% do código. Se você não tem nada para consultar, como testar os outros 80% de forma eficiente? Agora imaginem se este programa estivesse 60% documentado com casos de uso e casos de teste. Já seria uma garantia bem maior.
Outro problema é o de não saber o que alterar. Recentemente em um projeto foi esquecido de alterar um programa, e só esse programa gerou mais estresse que todas as outras alterações juntas porque estava dando problema lá no cliente. Sem documentação, não há rastreabilidade." [Ismael Munchen]
Na colocação do Ismael conclui-se que:
1. Falta de documentação pode prejudicar a cobertura dos testes
2. Falta de documentação implica em falta de rastreabilidade e aumento dos riscos nas manutenções do sistema
A visão do Marcelo Andrade complementa o primeiro cenário do Ismael:
"Claro que não dá para testar tirando conclusões sobre regras de negócio da própria cabeça do testador. Neste caso, se a informação está disponível (com o cliente ou com quem quer que seja) é ela que deve ser buscada."
Então, na falta de uma documentação, caso haja alguma outra fonte de conhecimento sobre os requisitos, ela viabiliza os testes e também aumenta a sua cobertura. Essa opinião também foi expressa pela Andrea Cruz quando ela fala que "testar sem documentação é possível, porém podem existir em determinados sistemas requisitos implícitos importantes que podem não ser cobertos pelo teste."
Existe sem dúvida um risco na falta de documentação. Para ser bem sucedido, o Analista de Teste precisa contar com alguma outra fonte de informação, ou a sua cobertura poderá ser seriamente prejudicada.
Segundo Daniel Goettenauer, "o beneficio da documentação só é percebido atualmente em grandes projetos, onde os testes de regressão são constantes e existem muitas mudanças.
[...] dependendo do tamanho do projeto de teste a documentação poderia ser tratada de forma mais simples (documentos básicos) ou complexa (todos os documentos). Dessa forma não teríamos projetos desenvolvidos em 16 horas e testados em 72 horas por conta do volume de documentação."
Ter algum nível de documentação é mesmo importante, entretanto o que define sua necessidade? Uma documentação necessária é aquela que é consultada e mantida, que serve de apoio para o time ou, não se encaixando em nenhum desses objetivos, ela se torna necessária apenas se for uma requisição do cliente. Jeffries, 2001 expõe em seu blog esse mesmo ponto quando fala que "você pode precisar de um UML bem formatado para o seu projeto, ou você pode precisar imprimir o Javadoc quando distribuir o seu código para outros, ou você pode precisar documentar os requisitos para o gerenciamento ou como parte de um contrato. Se e quando você realmente precisar dessas documentações, você deve realmente tê-las." Se elas não forem realmente necessárias apenas demandam tempo da equipe e nem sempre são mantidas adequadamente.
Um sem número de documentos que são criados no início do projeto e não sofrem mais atualizações é uma realidade em muitos projetos. De acordo com o Shmuel, "uma documentação desatualizada é menos útil, mas ainda pode ser usada da mesma maneira. Mas essa ajuda não é um pré-requisito necessário, e podemos testar mesmo sem tê-la. Por meio de abstrações e inferências, é possível aprender sobre o programa de várias outras maneiras, durante os testes, durante conversas, durante as discussões sobre bugs etc.”
Essa opinião está alinhada com uma pesquisa do IEEE, 2003 em que entrevistas com engenheiros de software revelaram as seguintes opiniões sobre documentação:
"- Documento de arquitetura e outras documentações abstratas são freqüentemente válidos ou ao menos provêem um guia histórico que pode ser útil para manutenção.
- Documentações de todos os tipos freqüentemente estão desatualizadas
- Uma fração considerável da documentação não é confiável. "
O Felipe da Silva trouxe um ponto diferente sobre a necessidade e assinalou outro uso dado à documentação fora o projeto de testes que é o de contrato. É comum utilizarmos uma documentação e a aprovação do cliente como um contrato ou parte dele na definição de escopo e base para cronograma. Segundo Felipe, "na maioria dos casos além de brigarmos para querer ter um sistema testável por qualquer um, em determinados processos de engenharia de software também brigamos porque queremos ter um documento como "defesa" contra a insatisfação do cliente. É aquele problema que se você não documenta, o cliente não assina, se ele não assina, não existe um registro que ele havia dito que era aquilo que ele queria, correndo o risco do cliente reclamar e ter melhorias no sistema sem pagar por elas nem ajustar cronograma e etc."
5. Conclusão
As opiniões expostas na Mesa Redonda levaram a um entendimento de que a documentação pode não ser necessária, mas é importante. O tema é bastante abrangente e a cada participação na lista foi possível idealizar novos cenários para responder a mesma pergunta. E você? A que conclusão chegou após ler o que discutimos em mais uma edição da Mesa Redonda do DFTestes?
Participantes da Nona Mesa Redonda:
Fabrício, Shmuel Gershon, Juliana Kryszczun, Ueslei Aquino, Ana Rosa, Sarah Pimentel, Fernanda Coelho, Ismael Munchen, Daniel Goettenauer, Felipe da Silva, Cristiana Yukie, Rodrigo Almeida, Rodrigo Souza, Andrea Cruz, Marcelo Andrade e Jorge Diz.
Referências:
Much Ado About Nothing: Documentation
Ron Jeffries 2001
Schools of Software Testing
Bret Pettichord, 2007
How Software Engineers Use Documentation: The State of the Practice
Timothy C. Lethbridge, Janice Singer, Andrew Forward
IEEE Computer Society
2003
Exploratory Testing Explained
James Bach, 2003
1o Livro DFTestes
Pessoal,
tá saindo do forno o 1o. livro do DFTestes falando sobre as mesas redondas que ocorrem no grupo. Por enquanto a publicação foi feita no formato site, mas em breve será disponibilizado em pdf.
Está bem interessante e estamos procurando feedbacks.
Dêem uma olhada por lá e deixem sua contribuição :)
Acessem aqui.
tá saindo do forno o 1o. livro do DFTestes falando sobre as mesas redondas que ocorrem no grupo. Por enquanto a publicação foi feita no formato site, mas em breve será disponibilizado em pdf.
Está bem interessante e estamos procurando feedbacks.
Dêem uma olhada por lá e deixem sua contribuição :)
Acessem aqui.
terça-feira, 27 de abril de 2010
Preparado para as novas tecnologias?
Dêem uma olhada nesse vídeo.
Recebi hoje por e-mail do meu pai. O intuito não foi o de atiçar o meu lado consumista e fazer com que eu delirasse imaginando como eu poderia ficar feliz mais rapidamente entrando numa loja e otimizando o tempo de ficar provando toda a loja até encontrar (ou não) o que eu quero. (Calma, foi só uma piadinha pra descontrair, não é assim tão sério :P) Na verdade meu pai tava me questionando sobre a proximidade desse tipo de tecnologia da nossa realidade.
Claro que eu não espero chegar ano que vem no shopping e encontrar algo do gênero, mas não duvido que um filho ou um neto meu possam ter contato direto com essa tecnologia. As coisas andam muito depressa e quando nos damos conta estamos rodeados de tecnologias que há 10 anos não podíamos mensurar quando fariam parte do nosso dia a dia.
Agora a parte mais nerd da coisa :) Claro que quando eu olhei o vídeo eu pensei: Deve ser MUITO legal testar isso ai!!! Com o que poderíamos comparar isso? Uma loja de e-commerce? Acho que o que eu cheguei mais perto disso é quando eu vou a Chilli Beans e tiro fotos com N óculos que eu coloco no rosto e o programa exibe pra mim as fotos e eu posso comparar o “look” entre um e outro. E vamos combinar, não chega nem na unha do pé disso ai.
Se você fosse criar um plano de teste para esse sistema, no que pensaria? Como seria o seu ambiente? Qual seria sua massa de dados? Que estratégias você definiria? Bastaria conhecer o negócio ou o conhecimento da tecnologia se tornaria mais relevante nesse caso?
Confesso que não consegui destrinchar todas essas questões ainda e depois de pensar em tudo isso me veio a pergunta que originou o post: Você está preparado para as novas tecnologias?
Recebi hoje por e-mail do meu pai. O intuito não foi o de atiçar o meu lado consumista e fazer com que eu delirasse imaginando como eu poderia ficar feliz mais rapidamente entrando numa loja e otimizando o tempo de ficar provando toda a loja até encontrar (ou não) o que eu quero. (Calma, foi só uma piadinha pra descontrair, não é assim tão sério :P) Na verdade meu pai tava me questionando sobre a proximidade desse tipo de tecnologia da nossa realidade.
Claro que eu não espero chegar ano que vem no shopping e encontrar algo do gênero, mas não duvido que um filho ou um neto meu possam ter contato direto com essa tecnologia. As coisas andam muito depressa e quando nos damos conta estamos rodeados de tecnologias que há 10 anos não podíamos mensurar quando fariam parte do nosso dia a dia.
Agora a parte mais nerd da coisa :) Claro que quando eu olhei o vídeo eu pensei: Deve ser MUITO legal testar isso ai!!! Com o que poderíamos comparar isso? Uma loja de e-commerce? Acho que o que eu cheguei mais perto disso é quando eu vou a Chilli Beans e tiro fotos com N óculos que eu coloco no rosto e o programa exibe pra mim as fotos e eu posso comparar o “look” entre um e outro. E vamos combinar, não chega nem na unha do pé disso ai.
Se você fosse criar um plano de teste para esse sistema, no que pensaria? Como seria o seu ambiente? Qual seria sua massa de dados? Que estratégias você definiria? Bastaria conhecer o negócio ou o conhecimento da tecnologia se tornaria mais relevante nesse caso?
Confesso que não consegui destrinchar todas essas questões ainda e depois de pensar em tudo isso me veio a pergunta que originou o post: Você está preparado para as novas tecnologias?
quarta-feira, 7 de abril de 2010
Importando casos de teste para o Quality Center
Essa semana fiz essa atividade no trabalho e resolvi gerar um post para ajudar com alguns “pequenos detalhes” que não são mencionados no User Guide oficial e que podem fazer a diferença entre um trabalho tranqüilo e um trabalho estressante. :)
Quality Center
Primeiro pra quem não conhece, o HP Quality Center é uma ferramenta de gerenciamento de defeitos que controla releases, ciclos, criação de testes, planejamento, gerenciamento de execução, gerenciamento de defeitos, provê relatórios, dashboards,... É uma ferramenta de testes bem completa.
É uma ferramenta proprietária da HP. É possível, entretanto baixar uma versão demo no site da HP.
Demo HP Quality Center
Excel Add-In
Para importar seus casos de teste do Excel para o Quality Center é necessário:
- que os seus testes estejam formatados de acordo com os campos do Quality Center.
- que você tenha instalado na sua máquina o Add-In do Excel.
Você pode acessar página de Add-ins do Quality Center ou na página inicial do Quality Center, antes da autenticação, ou caso já esteja dentro da aplicação, através do menu Help > Add-ins Page.
Se a opção Microsoft Office Add-ins não estiver disponível, clique em More Quality Center Add-ins e a opção deve ser exibida. Instale o Add-in do Excel. Após a instalação, no Excel, será possível perceber uma nova aba chamada Add-Ins e o botão Export To Quality Center.
Formatando o teste no excel
De início vamos conhecer a estrutura de testes do Quality Center. Essa ferramenta é personalizável e pode ser que a tela exibida abaixo não seja exatamente igual a que você costuma usar, mas nada que impacte a continuação da leitura desse post. :)
Dica1: Se os campos obrigatórios padrão do Quality Center são correspondem às informações que você já tem nos seus testes, personalize esses campos.
Esses são os campos obrigatórios padrão do Quality Center:
-Subject (perceba que para criar o teste eu tive que escolher primeiro a pasta na qual ele seria inserido)
-Test Name
-Level
-Priority
-Reviewed
Reforço que é possível alterar os campos que são obrigatórios pelo módulo Administrador da ferramenta. Mas vamos trabalhar com o padrão mesmo.
Claro que há várias outras informações que precisamos para completar um caso de teste, mas já é possível fazer a importação só com esses.
Normalmente você teria ainda no seu caso de teste a descrição do caso de teste e os passos a serem executados com ações e resultados esperados. Segue então um caso de teste fictício com esses atributos:
Dica2: Todos os valores tratados como lista no Quality Center precisam estar no Excel exatamente da mesma que estão no QC. Por isso, aconselho a criar um template para os testes utilizando listas também.
Dica3: Para separar hierarquicamente as pastas, utilize “\”. Não há outro separador válido. Se você errar a descrição do subject vai ter que deletar manualmente a pasta no Quality Center após a importação.
Importando
Com o caso de teste pronto podemos começar a importação. No Excel, clique no botão Export To Quality Center na tab Add-in. Nos primeiros passos serão pedidas informações de autenticação no Quality Center com endereço do servidor, usuário, senha e projeto.
O Quality Center importa Testes, Requisitos e Defeitos. Após a autenticação, será requisitado que você informe o que está exportando. Selecione Tests.
Para que o Quality Center reconheça as informações no seu Excel, é necessário fazer um mapeamento das colunas com os campos do Excel (a não ser que você nomeie as colunas exatamente com o nome dos campos do Excel. Nesse caso é possível fazer uma conversão automática).
Para criar um mapa temporário, selecione Create a temporary map. Se você quer salvar o mapeamento para utilizá-lo novamente, selecione Type a new map name e insira um nome para o seu mapa. Posteriormente será possível selecioná-lo em Select a map. Para seguir esse post, aconselho que seja salvado um mapa, vamos precisar refazê-lo depois. :)
No próximo passo, vamos relacionar os campos do Quality Center com as colunas do Excel. No caso do teste que eu criei o resultado foi:
Subject – A
Test Name – B
Description – C
Level – D
Priority – E
Reviewed – F
Step Name (Design Steps) – G
Description (Design Steps) – H
Expected (Design Steps) – I
Depois disso, cruze os dedos e clique em Export.
Se você criou o seu teste como especificado aqui nesse post, você acaba de receber uma feliz tela de Sucesso. Mas não se iluda!! :) Vamos olhar no Quality Center o que aconteceu.
Parece que deu tudo certo. Vamos ver os passos:
E essa é a maior causa de dores de cabeça na importação de testes pro Quality Center. Onde estão os outros passos? No User Guide você vai encontrar uma instrução dizendo que os passos são identificados como sendo daquele teste se você informar para todos os passos o Subject e o Test Name, assim, o Quality Center faria essa relação. Bem, é quase isso.
Dica4: Replique para todas as linhas do seu teste TODOS OS CAMPOS OBRIGATÓRIOS, não somente o Subject e o Test Name. Se você não replicá-los, na hora da exportação o Excel vai dar um erro dizendo que os campos obrigatórios não estão preenchidos.
Não vou pedir para que façam a exportação novamente agora porque não é um post de teste de paciência, é um post para ajudar a pular alguns passos dessas descobertas. :)
Mesmo aplicando a dica 4 o caso de teste ainda vai chegar no Quality Center com apenas um passo a não ser que...
Dica5: Selecione todas as células do teste para exportá-lo.
MAS........
Dica5.1: Selecione todas as CÉLULAS mesmo. Não adianta selecionar a coluna inteira que o programa vai reclamar igual. :)
Ok. Vamos tentar novamente. Dessa vez selecione o mapa que você salvou anteriormente, ao invés de criar um novo.
E o resultado...
E para finalizar...
Dica6: Perceba que ao exportar um teste com o mesmo Subject e o mesmo Test Name de um existente, o teste existente será sobrescrito.
Quality Center
Primeiro pra quem não conhece, o HP Quality Center é uma ferramenta de gerenciamento de defeitos que controla releases, ciclos, criação de testes, planejamento, gerenciamento de execução, gerenciamento de defeitos, provê relatórios, dashboards,... É uma ferramenta de testes bem completa.
É uma ferramenta proprietária da HP. É possível, entretanto baixar uma versão demo no site da HP.
Demo HP Quality Center
Excel Add-In
Para importar seus casos de teste do Excel para o Quality Center é necessário:
- que os seus testes estejam formatados de acordo com os campos do Quality Center.
- que você tenha instalado na sua máquina o Add-In do Excel.
Você pode acessar página de Add-ins do Quality Center ou na página inicial do Quality Center, antes da autenticação, ou caso já esteja dentro da aplicação, através do menu Help > Add-ins Page.
Se a opção Microsoft Office Add-ins não estiver disponível, clique em More Quality Center Add-ins e a opção deve ser exibida. Instale o Add-in do Excel. Após a instalação, no Excel, será possível perceber uma nova aba chamada Add-Ins e o botão Export To Quality Center.
Formatando o teste no excel
De início vamos conhecer a estrutura de testes do Quality Center. Essa ferramenta é personalizável e pode ser que a tela exibida abaixo não seja exatamente igual a que você costuma usar, mas nada que impacte a continuação da leitura desse post. :)
Dica1: Se os campos obrigatórios padrão do Quality Center são correspondem às informações que você já tem nos seus testes, personalize esses campos.
Esses são os campos obrigatórios padrão do Quality Center:
-Subject (perceba que para criar o teste eu tive que escolher primeiro a pasta na qual ele seria inserido)
-Test Name
-Level
-Priority
-Reviewed
Reforço que é possível alterar os campos que são obrigatórios pelo módulo Administrador da ferramenta. Mas vamos trabalhar com o padrão mesmo.
Claro que há várias outras informações que precisamos para completar um caso de teste, mas já é possível fazer a importação só com esses.
Normalmente você teria ainda no seu caso de teste a descrição do caso de teste e os passos a serem executados com ações e resultados esperados. Segue então um caso de teste fictício com esses atributos:
Dica2: Todos os valores tratados como lista no Quality Center precisam estar no Excel exatamente da mesma que estão no QC. Por isso, aconselho a criar um template para os testes utilizando listas também.
Dica3: Para separar hierarquicamente as pastas, utilize “\”. Não há outro separador válido. Se você errar a descrição do subject vai ter que deletar manualmente a pasta no Quality Center após a importação.
Importando
Com o caso de teste pronto podemos começar a importação. No Excel, clique no botão Export To Quality Center na tab Add-in. Nos primeiros passos serão pedidas informações de autenticação no Quality Center com endereço do servidor, usuário, senha e projeto.
O Quality Center importa Testes, Requisitos e Defeitos. Após a autenticação, será requisitado que você informe o que está exportando. Selecione Tests.
Para que o Quality Center reconheça as informações no seu Excel, é necessário fazer um mapeamento das colunas com os campos do Excel (a não ser que você nomeie as colunas exatamente com o nome dos campos do Excel. Nesse caso é possível fazer uma conversão automática).
Para criar um mapa temporário, selecione Create a temporary map. Se você quer salvar o mapeamento para utilizá-lo novamente, selecione Type a new map name e insira um nome para o seu mapa. Posteriormente será possível selecioná-lo em Select a map. Para seguir esse post, aconselho que seja salvado um mapa, vamos precisar refazê-lo depois. :)
No próximo passo, vamos relacionar os campos do Quality Center com as colunas do Excel. No caso do teste que eu criei o resultado foi:
Subject – A
Test Name – B
Description – C
Level – D
Priority – E
Reviewed – F
Step Name (Design Steps) – G
Description (Design Steps) – H
Expected (Design Steps) – I
Depois disso, cruze os dedos e clique em Export.
Se você criou o seu teste como especificado aqui nesse post, você acaba de receber uma feliz tela de Sucesso. Mas não se iluda!! :) Vamos olhar no Quality Center o que aconteceu.
Parece que deu tudo certo. Vamos ver os passos:
E essa é a maior causa de dores de cabeça na importação de testes pro Quality Center. Onde estão os outros passos? No User Guide você vai encontrar uma instrução dizendo que os passos são identificados como sendo daquele teste se você informar para todos os passos o Subject e o Test Name, assim, o Quality Center faria essa relação. Bem, é quase isso.
Dica4: Replique para todas as linhas do seu teste TODOS OS CAMPOS OBRIGATÓRIOS, não somente o Subject e o Test Name. Se você não replicá-los, na hora da exportação o Excel vai dar um erro dizendo que os campos obrigatórios não estão preenchidos.
Não vou pedir para que façam a exportação novamente agora porque não é um post de teste de paciência, é um post para ajudar a pular alguns passos dessas descobertas. :)
Mesmo aplicando a dica 4 o caso de teste ainda vai chegar no Quality Center com apenas um passo a não ser que...
Dica5: Selecione todas as células do teste para exportá-lo.
MAS........
Dica5.1: Selecione todas as CÉLULAS mesmo. Não adianta selecionar a coluna inteira que o programa vai reclamar igual. :)
Ok. Vamos tentar novamente. Dessa vez selecione o mapa que você salvou anteriormente, ao invés de criar um novo.
E o resultado...
E para finalizar...
Dica6: Perceba que ao exportar um teste com o mesmo Subject e o mesmo Test Name de um existente, o teste existente será sobrescrito.
terça-feira, 16 de março de 2010
Análise de Valor Limite
Essa técnica é um refinamento da técnica Partição por Equivalência abordada anteriormente. Se você não conhece ainda a técnica recomendo fortemente a leitura dela antes de prosseguir.
Quando falamos em selecionar valores dentro de uma partição para realizar o teste, você pode ter pensado que há valores mais interessantes que outros de serem selecionados. Está certíssimo. Há mesmo. Um exemplo deles são os valores limite dessa partição.
Para determinar valores limite é preciso que estejamos tratando de uma partição com elementos ordenáveis, onde eu possa dizer que o elemento A é maior que o elemento B.
Exemplos de aplicações viáveis de valores limite:
- tamanho de fonte de um texto
- idade de uma pessoa
Exemplos de aplicações inviáveis de valores limite podem ser os que utilizados no post sobre Partição por Equivalência:
- cidades atendidas em um sistema de venda com entregas
- tipo de contrato, tipo de foto
Um valor limite é um membro de uma partição a partir do qual se espera uma mudança de comportamento. Por exemplo, alguns conteúdos na internet são considerados impróprios para menores de 18 anos. Ou seja, se você indica sua idade como um número menor que 18, a aplicação deve ter um comportamento, e se você indica sua idade como 18 ou mais, a aplicação deve ter outro comportamento.
Igual à técnica de Partição por Equivalência, cada valor limite inválido ou válido, deve ser representado em ao menos um caso de teste. No caso de Análise de Valor Limite, geraremos pelo menos duas vezes mais testes do que na técnica de Partição por Equivalência. Isso porque teremos pelo menos dois valores limites para cada partição.
Por que iríamos querer gerar mais casos de teste então? A Partição por Equivalência valida os membros de grupos de valores que levam a determinadas respostas da aplicação. A Análise de Valor Limite, por sua vez, verifica se o espaço delimitado entre uma partição e outra está correto.
EXEMPLO DE ANÁLISE DE VALOR LIMITE
Já tentou explorar qual o limite para a fonte no Word? Esse aplicativo aceita apenas tamanhos entre 1 e 1638. Se você tentar entrar valores maiores que 1638 ou menores que 1, na fonte Calibri, deve ser exibida essa mensagem:
Há diversos testes que podemos realizar nessa funcionalidade de troca de fonte. Abaixo, algumas sugestões. Se você pensar em outras, por favor, compartilhe no espaço de comentários.
- Testar a entrada de tamanho de fonte pelo combobox com um valor intermediário qualquer
- Testar a entrada de tamanho de fonte pelo combobox com o valor mínimo exibido
- Testar a entrada de tamanho de fonte pelo combobox com o valor máximo exibido
- Testar a entrada de tamanho de fonte pelo campo livre com o valor mínimo
- Testar a entrada de tamanho de fonte pelo campo livre com o valor máximo
- Testar a entrada de tamanho de fonte pelo campo livre com o valor mínimo -1
- Testar a entrada de tamanho de fonte pelo campo livre com o valor máximo +1
- Testar a entrada de tamanho de fonte pelo campo livre com um número bem menor que 1
- Testar a entrada de tamanho de fonte pelo campo livre com um número bem maior que 1638
- Testar a entrada de tamanho de fonte pelo campo livre com letras
- Testar a entrada de tamanho de fonte pelo campo livre com caracteres especiais (que não são letras ou números)
- Testar a entrada de tamanho de fonte pelo campo livre com Números Racionais
- Testar a entrada de tamanho de fonte pelo campo livre com uma operação
- Testar a entrada de tamanho de fonte pelo campo livre com números negativos
Veja que a abertura para o usuário do valor a ser entrado aumentou bastante nossas possibilidades. Para melhor testabilidade da aplicação, o ideal seria que a seleção pelo combobox fosse a única opção para entrar fontes. No caso do combobox, perceba também que não há testes inválidos a serem realizados.
Os testes marcados representam as melhores caracterizações dos testes válidos dentro da Análise de Valor Limite. Quanto evoluir na investida em testes inválidos? Depende do risco associado. Anteriormente à aplicação dessas técnicas, a aplicação de uma Análise de Risco pode determinar o quanto vale a pena criar testes para testar exaustivamente essa funcionalidade ou não.
EXEMPLO DE APLICAÇÃO INVÁLIDA DE VALOR LIMITE
Em algumas situações, a ordenação visual pode levar à falsa idéia de que há valores limite. Por exemplo, um menu.
Apesar de aparentemente ordenados, a ordenação utilizada não nos fornece nenhuma idéia de valores limite. Não faria sentido. Nesse caso, cada menu deve ser testado individualmente, representando cada um deles sua própria classe de equivalência.
A opção de valor inválido seria, caso haja algum menu que devesse estar desativado, verificar se o design é alterado para indicar isso e se ao clicar nesse menu ele realmente não executa nenhuma operação. Mas não há Análise de Valor Limite a ser feita.
E ENTÃO, PARECE FÁCIL?
A Análise por Valor Limite pode parecer fácil utilizando valores inteiros, mas quando tratamos da validação de Números Reais, pode ficar bem mais complicado.
Já um pouco mais difícil que o tamanho de fontes do Word, seria testar os limites de uma Calculadora, seja o aplicativo do Windows ou para complicar ainda mais, uma calculadora financeira ou científica ou gráfica.
Entendida a técnica, serão necessárias algumas vezes a aplicação de outros conhecimentos para conseguir identificar valores limite para os testes. Claro que uma especificação sempre ajuda.
Fonte: Advanced Software Testing vol.1 – Rex Black
Ver também:
Overview Tipos de Técnicas de Teste
Partição por Equivalência
Quando falamos em selecionar valores dentro de uma partição para realizar o teste, você pode ter pensado que há valores mais interessantes que outros de serem selecionados. Está certíssimo. Há mesmo. Um exemplo deles são os valores limite dessa partição.
Para determinar valores limite é preciso que estejamos tratando de uma partição com elementos ordenáveis, onde eu possa dizer que o elemento A é maior que o elemento B.
Exemplos de aplicações viáveis de valores limite:
- tamanho de fonte de um texto
- idade de uma pessoa
Exemplos de aplicações inviáveis de valores limite podem ser os que utilizados no post sobre Partição por Equivalência:
- cidades atendidas em um sistema de venda com entregas
- tipo de contrato, tipo de foto
Um valor limite é um membro de uma partição a partir do qual se espera uma mudança de comportamento. Por exemplo, alguns conteúdos na internet são considerados impróprios para menores de 18 anos. Ou seja, se você indica sua idade como um número menor que 18, a aplicação deve ter um comportamento, e se você indica sua idade como 18 ou mais, a aplicação deve ter outro comportamento.
Igual à técnica de Partição por Equivalência, cada valor limite inválido ou válido, deve ser representado em ao menos um caso de teste. No caso de Análise de Valor Limite, geraremos pelo menos duas vezes mais testes do que na técnica de Partição por Equivalência. Isso porque teremos pelo menos dois valores limites para cada partição.
Por que iríamos querer gerar mais casos de teste então? A Partição por Equivalência valida os membros de grupos de valores que levam a determinadas respostas da aplicação. A Análise de Valor Limite, por sua vez, verifica se o espaço delimitado entre uma partição e outra está correto.
EXEMPLO DE ANÁLISE DE VALOR LIMITE
Já tentou explorar qual o limite para a fonte no Word? Esse aplicativo aceita apenas tamanhos entre 1 e 1638. Se você tentar entrar valores maiores que 1638 ou menores que 1, na fonte Calibri, deve ser exibida essa mensagem:
Há diversos testes que podemos realizar nessa funcionalidade de troca de fonte. Abaixo, algumas sugestões. Se você pensar em outras, por favor, compartilhe no espaço de comentários.
- Testar a entrada de tamanho de fonte pelo combobox com um valor intermediário qualquer
- Testar a entrada de tamanho de fonte pelo combobox com o valor mínimo exibido
- Testar a entrada de tamanho de fonte pelo combobox com o valor máximo exibido
- Testar a entrada de tamanho de fonte pelo campo livre com o valor mínimo
- Testar a entrada de tamanho de fonte pelo campo livre com o valor máximo
- Testar a entrada de tamanho de fonte pelo campo livre com o valor mínimo -1
- Testar a entrada de tamanho de fonte pelo campo livre com o valor máximo +1
- Testar a entrada de tamanho de fonte pelo campo livre com um número bem menor que 1
- Testar a entrada de tamanho de fonte pelo campo livre com um número bem maior que 1638
- Testar a entrada de tamanho de fonte pelo campo livre com letras
- Testar a entrada de tamanho de fonte pelo campo livre com caracteres especiais (que não são letras ou números)
- Testar a entrada de tamanho de fonte pelo campo livre com Números Racionais
- Testar a entrada de tamanho de fonte pelo campo livre com uma operação
- Testar a entrada de tamanho de fonte pelo campo livre com números negativos
Veja que a abertura para o usuário do valor a ser entrado aumentou bastante nossas possibilidades. Para melhor testabilidade da aplicação, o ideal seria que a seleção pelo combobox fosse a única opção para entrar fontes. No caso do combobox, perceba também que não há testes inválidos a serem realizados.
Os testes marcados representam as melhores caracterizações dos testes válidos dentro da Análise de Valor Limite. Quanto evoluir na investida em testes inválidos? Depende do risco associado. Anteriormente à aplicação dessas técnicas, a aplicação de uma Análise de Risco pode determinar o quanto vale a pena criar testes para testar exaustivamente essa funcionalidade ou não.
EXEMPLO DE APLICAÇÃO INVÁLIDA DE VALOR LIMITE
Em algumas situações, a ordenação visual pode levar à falsa idéia de que há valores limite. Por exemplo, um menu.
Apesar de aparentemente ordenados, a ordenação utilizada não nos fornece nenhuma idéia de valores limite. Não faria sentido. Nesse caso, cada menu deve ser testado individualmente, representando cada um deles sua própria classe de equivalência.
A opção de valor inválido seria, caso haja algum menu que devesse estar desativado, verificar se o design é alterado para indicar isso e se ao clicar nesse menu ele realmente não executa nenhuma operação. Mas não há Análise de Valor Limite a ser feita.
E ENTÃO, PARECE FÁCIL?
A Análise por Valor Limite pode parecer fácil utilizando valores inteiros, mas quando tratamos da validação de Números Reais, pode ficar bem mais complicado.
Já um pouco mais difícil que o tamanho de fontes do Word, seria testar os limites de uma Calculadora, seja o aplicativo do Windows ou para complicar ainda mais, uma calculadora financeira ou científica ou gráfica.
Entendida a técnica, serão necessárias algumas vezes a aplicação de outros conhecimentos para conseguir identificar valores limite para os testes. Claro que uma especificação sempre ajuda.
Fonte: Advanced Software Testing vol.1 – Rex Black
Ver também:
Overview Tipos de Técnicas de Teste
Partição por Equivalência
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
Assinar:
Postagens (Atom)