Técnicas de Testes de Software

Estou passando para deixar um artigo com uma técnica simples. Tirei da gaveta em minhas documentações antigas...

--------------

Conteúdo completo aqui: http://testesdesoftware.blogspot.com/

Técnicas de Testes

Esta seqüência de artigos tem o objetivo de demonstrar algumas técnicas de testes simples, contribuindo para homologadores/analistas de testes em início de experiência. Espero que contribua.
________________________________________
Por Fernando Palma, Setembro de 2009

TÉCNICA DE TESTE PARA TELAS DE PESQUISA

Ao validar uma tela de pesquisa, o homologador deve fazer os seguintes testes:
☺ Testar todas as combinações existentes dos campos para garantir que a tela funciona. Para uma busca com ?a? campos, existirão 2ª combinações.

Ex: 3 filtros são dispostos em uma pesquisa. Portanto, então seriam 8 combinações.

A melhor técnica para alcançar este fim, é utilização de números binários, como demonstrado a seguir:

ver imagem aqui: http://testesdesoftware.blogspot.com/

Como a tabela demonstra, 8 combinações de busca são realizadas.
Mas estes não são todos os testes, pois para cada campo preenchido, o desenvolvedor deve testá-lo preenchendo uma vez com parâmetros que retorne(m) registros(s) e outra vez com parâmetros que não retorne registro. Então, seriam na verdade 2 (ª + 1) à 2 elevado a ?a? mais 1 combinações diferentes. No exemplo acima, seriam 16 combinações, na verdade.

ver imagem aqui: http://testesdesoftware.blogspot.com/

Obs: Considerando que ?R? represente um parâmetro que retorne registro(s) e ?N? um parâmetro que não retorne nenhum registro.

O interessante desta técnica é imaginar uma tela com diversos filtros. 6, 8, 15 filtros de pesquisa. Representariam estes valores elevado ao cubo, quando traduzido em testes. Três conclusões podem ser tiradas, portanto:

1- O gerente responsável pelo projeto de software deve definir o nível de qualidade que é requerido para o sistema. Baseado nesta especificação, ou melhor: neste requisito de qualidade, o analista de testes/homologador executa a metade, um terço, ou até 1% das combinações existentes.

2- Quando parte das combinações são executadas, cabe ao Analista de Testes definir quais delas serão escolhidas, por representarem maior risco de falhas.

3- Ao receber os requisitos do sistema, no inicio do projeto, o Analista de Testes deve prevenir com estimativas de quantidade de testes que serão gerados. Esta colaboração é importante para que haja um balanceamento eficaz diante de escolhas, como esta: "quantos filtros existirão na tela?". Nem sempre o que é fácil de implementar é fácil de testar. Por isso, muitos analistas de testes já utilizam o conceito denominado "pontos de testes" para os requisitos de teste, que equivale aos "pontos de função" dos requisitos de sistema.

Fernando Palma

This message was edited 2 times. Last update was at 29/09/2009 16:56:00

Boa tarde,

novos artigos relacionados a técnicas de testes:

http://testesdesoftware.blogspot.com/

Sd´s
Fernando Palma.
http://gsti.blogspot.com/

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

Ao validar uma tela de pesquisa, o homologador deve fazer os seguintes testes:

Testar todas as combinações existentes dos campos para garantir que a tela funciona. Para uma busca com "a" campos, existirão 2ª combinações.

Ou a pessoa pode manter a sanidade mental dela e usar TDD. (Ou tá achando que o Google tem uma pessoa para testar todas as bilhões combinações de pesquisa dela?)

Olá Bruno,

existe uma parte do artigo que faz referência a esta quantidade de testes que deve ser executada:

"O interessante desta técnica é imaginar uma tela com diversos filtros. 6, 8, 15 filtros de pesquisa. Representariam estes valores elevado ao cubo, quando traduzido em testes. Três conclusões podem ser tiradas, portanto:

1- O gerente responsável pelo projeto de software deve definir o nível de qualidade que é requerido para o sistema. Baseado nesta especificação, ou melhor: neste requisito de qualidade, o analista de testes/homologador executa a metade, um terço, ou até 1% das combinações existentes.

"
Mais: http://testesdesoftware.blogspot.com/

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 517 Offline

fernando.palma wrote:
1- O gerente responsável pelo projeto de software deve definir o nível de qualidade que é requerido para o sistema. Baseado nesta especificação, ou melhor: neste requisito de qualidade, o analista de testes/homologador executa a metade, um terço, ou até 1% das combinações existentes.

Como assim definir o nivel de qualidade???

Só existem dois niveis de qualidade possiveis: "Total" e "Nenhuma". Qualidade não é negociavel, qualidade é requisito básico.

Se voce nao tem tempo habil pra implementar todos os requisitos do sistema, voce tem que negociar ou o tempo ou os requisitos, nunca, jamais, em tempo algum a qualidade.

Olá YvGa,
Qualidade é negociada sim em nível de serviço, não como tu estás pensando mas em termos de entrega do sistema.
Não existe um sistema livre de bugs, logo a qualidade "total" não existe!

Quando uma aplicação é desenvolvida, em empresas mais maduras (diga-se empresas que realmente sabem o que é Teste de Software e os reais benefícios que ele traz) existem uum nível de aceite: o gerente de teste determina o % de bugs, pela sua criticidade, que o sistema pode ter. Mas isso é sempre alinhado com o cliente.
Tento em vista que o cliente sabe que existe bugs, a qualidade é negociada.
Uma vez que a área de teste encontrou 10 defeitos, sendo 3 críticos, 5 médios e 2 baixos. Podemos negociar de entregar o sistema para funcionamento com os 3 erros criticos e os 5 médios corrigidos, deixando os 2 baixos para a proxima entrega.
Essa é a visão da área de Teste, que Controla a Qualidade.

Na mesma linha, na visão da Garantia da Qualidade, nos procedimentos inciais para desenvolvimento e testes, o gerente (desenvolvimento e/ou testes) podem definir o nível de qualidade adotando quais características da qualidade a aplicação terá que atacar prioritatiamente (veja ISO 9126). É muito dificil uma aplicação aplicar 100% das características da qualidade, logo não existindo assim também uma qualidade "total"

Abraços!

Isso aí é pra usar com fábrica de software, waterfall. Todos nós já conhecemos os problemas desse modelo.

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 517 Offline

Desculpe, Elias, mas eu discordo.

O foco deve ser sempre qualidade total. Eu concordo que nas primeiras iteracoes, e mesmo no inicio da vida util dos sistemas existem problemas. Mas voce vai ter que resolve-los todos antes de poder dizer que o sistema foi implantado.

É exatamente o que o Neofito colocou, essa sua teoria vem da boa e velha fabrica de software que ja provou por a + b que é ineficaz.

Repito, qualidade não é negociavel. Se nao funciona voce nao entrega, se funciona mais ou menos voce nao entrega. Se funciona mas contem pequenos bugs suportaveis voce conserta-os e entrega.

Erros existem e sempre um ou outro passa, mas nunca passa quando sabe-se da existencia dele.

?Repito, qualidade não é negociável. Se nao funciona voce nao entrega, se funciona mais ou menos voce nao entrega. Se funciona mas contem pequenos bugs suportaveis voce conserta-os e entrega.?

YvGa,

O nível de qualidade de um serviço ou produto é variável e negociável, depende do que este serviço/produto irá atender.

Ex: Quando um gerente de projetos planeja a entrega do de um sistema, ele precisa analisar conhecer o escopo do sistema a nível de requisitos não funcionais:

- quantos usuários irão utilizar a aplicação;
- quantos acessarão o sistema simultaneamente;
- qual a carga de informação que será tratada nas transações do sistema.

Entre outros.

Baseado nestes requisitos, ele entrará em acordo de nível de qualidade tais como performance, disponibilidade e níveis de serviço em geral que o sistema deve atender. Irá então formalizar os critérios de aceite do sistema e gerenciar a qualidade, através dos processos de controle e garantia da qualidade.

O Analista de testes por sua vez, irá especificar os testes que atendam ao nível de qualidade que o gestor do projeto aprovou com o cliente.

Voltando para o exemplo anterior da tela de consulta:

Eu estou entregando em Novembro um sistema para uso interno em uma Universidade aqui em Salvador. Este sistema irá atender a 3 mil professores entre os meses de Novembro de 2009 e Março de 2010.

Digamos que neste sistema descrito acima, exista uma tela de consulta com 5 campos. Eu com certeza irei orientar que os testes sejam realizados para cobri apenas uma parte de todas as combinações possíveis (da análise combinatória apresentada).

Exemplo de quantidade de testes que eu faria:

Campo 1 Campo 2 Campo 3 Campo 4 Campo 5
1 0 0 0 0
1 1 0 0 0
1 1 1 0 0
1 1 1 1 0
1 1 1 1 1

Como pode ver, estes não são todos os testes que possíveis de se realizar. Existem mais combinações. Entretanto, eu assumo o risco de não estar testando todas elas.

Razão:
Digamos que ao omitir alguns testes, eu esteja correndo o risco de 5% de ocorrer um bug em produção, nesta tela de pesquisa, ao realizar uma consulta.

Este bug será relatado ao servicedesk e representará um custo, em média de 100 reais por hora para ser corrigido (por conta da indisponibilidade e alocação de recursos.

Lembrando que estes números são ilustrativos.

Na verdade eu estou correndo o risco de 5% com impacto de 100 reais a hora. Em uma estimativa de 10h de paradas (pessimista), eu estou dando um prejuízo de 0,05 * 100 * 10 = 50 reais.

O custo que eu teria para testar todas as possibilidade é maior do que 50 reais, ainda mais pelo fato de eu não possuir uma ferramenta.

Agira tomemos um contra-exemplo: um sistema bancário.

Uma única falha de minutos em um sistema de banco, pode significar milhões em perdas financeiras. Por isso, ao implementar um sistema de banco o nível de qualidade deve ser negociável ao extremo. Deve ter um alto nível de qualidade e isso tem um custo.

O google , por exemplo, deve ter ferramentas poderosas de testes que realizam todas a combinações possíveis em "pesquisa avançada". Isso porque um erro de pesquisa no google é mais custoso do que no meu caso.

Segue abaixo, um gráfico clássico para profissionais de qualidade:

Esta imagem mostra o numero de testes executados e o número de erros. O Gerente de projetos deve moderar os testes feitos para encontrar o ponto de cruzamento entre a linha amarela e a vermelha: numero de testes começa a ultrapassar o custo do número de erros.

Testar demais é tão ineficiente quanto testar pouco.

Caso alguém queira participar mais do tema concordado ou discordando:

http://testesdesoftware.blogspot.com

Isso aí é pra usar com fábrica de software, waterfall. Todos nós já conhecemos os problemas desse modelo.

Com gestões ágeis, o processo muda. As entregas e avaliações são constantes. Entretanto, o nível de qualidade deve existir, indendente de modelo cascata ou iterativo.

http://testesdesoftware.blogspot.com

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 517 Offline

Desculpe, Fernando, mas eu insisto.

Alias, eu já to bem cansado dessa conversa, esses graficos, essa burocracia... trabalho numa empresa que tem exatamente esse discurso, exatamente essa forma de trabalho, e te digo com todas as letras isso é engodo, blablabla pra justificar os altos salarios de um monte de gente que nao tem a menor ideia do que esta fazendo.

Qualidade não é negociavel, e só cliente e mais ninguem pode dizer se o sistema esta apto ou nao para ir pra producao.

Esse monte de bolinha e linhazinha colorida pra la e pra ca nao faz nada, nao serve pra nada, nao agrega valor, nao deixa o cliente satisfeito. So serve pra alimentar as ilusoes dos diretores "semi-competentes" que adoram graficozinhos. Enquanto isso gasta-se milhoes e milhoes em software por ano. Sendo que a maioria, a maioria mesmo, dos projetos falha.

This message was edited 2 times. Last update was at 30/09/2009 18:05:45

Desculpe, Fernando, mas eu insisto.

Alias, eu já to bem cansado dessa conversa, esses graficos, essa burocracia... trabalho numa empresa que tem exatamente esse discurso, exatamente essa forma de trabalho, e te digo com todas as letras isso é engodo, blablabla pra justificar os altos salarios de um monte de gente que nao tem a menor ideia do que esta fazendo.

Qualidade não é negociavel, e só cliente e mais ninguem pode dizer se o sistema esta apto ou nao para ir pra producao.

Esse monte de bolinha e linhazinha colorida pra la e pra ca nao faz nada, nao serve pra nada, nao agrega valor, nao deixa o cliente satisfeito. So serve pra alimentar as ilusoes dos diretores "semi-competentes" que adoram graficozinhos. Enquanto isso gasta-se milhoes e milhoes em software por ano. Sendo que a maioria, a maioria mesmo, dos projetos falha.

Concordo que a satisfação do cliente é foco principal. Mas nem sempre o cliente sabe o que precisa, não é verdade?

Entendo o seu ponto de vista e também prefiro atuar do que exibir gráficos. Claro que é mais produtivo. Entretanto, no momento que desenvolvemos um sistema, nós como analista devemos entender dos requisitos do negócio para prever o nível satisfatório de: disponibilidade, performance, trafego, etc.

Caso a gente não desenho um pouco de gráfico e não faça nossas contas, o que faremos? Intuição? Ou esperamos o cliente dizer OK e liberamos em produção. E se o sistema apresentar performance baixa e der prejuízo a empresa? Pense grande: imagine se nós dois estivermos responsáveis por desenvolver o site do submarino. Como fazemos isso sem cálculos, gráficos, números, estatísticas, forecasts....como?

O cliente pode até olhar o sistema e validar. Mas ele estará assinando atestado de falência.

http://testesdesoftware.blogspot.com/

http://gsti.blogspot.com/

JavaGuru Membro desde: 29/07/2009 14:43:29 Mensagens: 249 Offline

Propaganda de Blog

[detected]

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 517 Offline

fernando.palma wrote:
Concordo que a satisfação do cliente é foco principal. Mas nem sempre o cliente sabe o que precisa, não é verdade?

Nao concordo. Muitas vezes ele nao sabe expressar o que quer, mas ele sabem bem o que quer.

fernando.palma wrote:
Entendo o seu ponto de vista e também prefiro atuar do que exibir gráficos. Claro que é mais produtivo. Entretanto, no momento que desenvolvemos um sistema, nós como analista devemos entender dos requisitos do negócio para prever o nível satisfatório de: disponibilidade, performance, trafego, etc.

Caso a gente não desenho um pouco de gráfico e não faça nossas contas, o que faremos? Intuição? Ou esperamos o cliente dizer OK e liberamos em produção. E se o sistema apresentar performance baixa e der prejuízo a empresa? Pense grande: imagine se nós dois estivermos responsáveis por desenvolver o site do submarino. Como fazemos isso sem cálculos, gráficos, números, estatísticas, forecasts....como?

O cliente pode até olhar o sistema e validar. Mas ele estará assinando atestado de falência.

Em que os graficos e os calculos ajudariam? Em que?? A sua pergunta é de resposta simples. Se nós estivermos responsáveis por desenvolver o site do submarino e nenhum de nós dois nunca desenvolveu um site como o do submarino e na nossa equipe na ha ninguem que tenha desenvolvido um site como o do submarino, o nosso submarino imaginario vai naufragar.

E pode fazer grafiquinho a vontade que nao vai salvar nada.

Separei uma frase em particular do teu post:

fernando.palma wrote:
Caso a gente não desenho um pouco de gráfico e não faça nossas contas, o que faremos? Intuição? Ou esperamos o cliente dizer OK e liberamos em produção.

e tambem:

fernando.palma wrote:
Concordo que a satisfação do cliente é foco principal. Mas nem sempre o cliente sabe o que precisa, não é verdade?

Essas suas colocacoes mostram claramente que voce, apesar de citar e comentar aí no seu blog, nao faz a menor ideia do que sejam as metodologias ageis. Sao a solucao pra tudo? nao nao sao. Resolvem todos os problemas do desenvolvimento de software. Nao nao resolvem. Mas elas superam e muito as "metodologias" tradicionais.

O que eu posso te sugerir é o seguinte:
Se sua preocupação é fazer software de qualidade, estude as metodogias ageis e esqueca esse blablabla de graficos e planilhas. Se a sua preocupação é conseguir uma boa "colocação" em uma fabrica de software como gerente de TI ou galgar posicoes em uma em que ja esta, ganhar um salario alto e entregar software mais ou menos, continue com essa sua estrategia de auto-promocao e conversa pra boi dormir que os diretores adoram.

P.S. Espero que nao leve pelo lado pessoal.

Notícias, artigos e o maior fórum brasileiro sobre Java