Técnicas de Testes de Software

Assuntos Gerais
#1

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:
:slight_smile: 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

#2

Boa tarde,

novos artigos relacionados a técnicas de testes:

http://testesdesoftware.blogspot.com/

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

#3

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

[list]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.[/list] [/quote]

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?)

#4

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/

#5

Como assim definir o nivel de qualidade??? :shock: :shock: :shock:

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.

#6

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!

#7

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

#8

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.

#9

[quote]
?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.? [/quote]

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:

funcionalidadestestesdefeitos.jpg1277×520

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.

#10

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

http://testesdesoftware.blogspot.com

#11

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

#12

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.

#13

[quote]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.[/quote]

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/

#14

Propaganda de Blog

[detected]

#15

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

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:

e tambem:

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.

#16

[quote]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. [/quote]

YvGa,

gostei muito do diálogo. Acredito realmente que eu devo estudar um pouco mais de metodologias ágeis. Convivi um pouco com a teoria, desde o XP, mas depois do seu post, cheguei a conclusão que poso ter conhecimento superficial do asunto por alta de aplicação.

Fique tranquilo, diálogos são sempre bem vindos.

O que quis dizer com a incerteza do cliente sobre o que ele quer é o seguinte:

Convivo com isso, quando solicito os níveis de serviço desejados para apicar…encontro respostas ambíguas, incertas e não tão importantes. vc entende? O cliente as vezes realmente quer o que não é importante para ele. E deixa de pedir o qu eé importante…

Quando estudamos requisitos não funcionair, priridades, pontos vitais do negócio…quando fazemos isso, sabemos o que o cliente precisa. O ideal é fazer parte do trabalho dele por algum tempo e transformar os requisitos dele em requisitos de TI.

Se você tiver algum material de Scrum e outras metodologias ageis para indicar, será bem vindo.

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

#17

Essa parte já não concordo tanto. Existem diferente segmentos. Você nunca será reconhecido se não tiver produtividade, não interessa no que acredita ou que metodologia usa. Eu não sei extamente o que quis dizer com “blablala”. Talvez um exemplo possa esclarecer.

#18

Fernando, nao me leve a mal se eu for um pouco rude, quero deixar claro antes que é rude com essa forma de pensamento e nao com voce em particular

Como todos os gerentes voce tem a labia afiada, aqui voce falou, falou e nao disse nada. Quantos usuarios? simultaneos? A carga? Esses sao requisitos a serem atendidos. Eles podem ser negociados, a qualidade do que foi negociado nao.

“Cliente, será realmente esse o numero de usuarios que utilizara a aplicacao? Essa é uma previsao de medio/longo prazo? Esse numero pode ser menor agora e com o tempo ser aumentado?”

“Cliente, será realmente esse o numero de usuários simultaneos ou essa é uma previsao baseada somente no numero de usuarios cadastrados? Esse numero pode ser menor agora e com o tempo ser aumentado?”

“Cliente, essa é a carga simultanea real prevista, ou é uma hipotética para medio/longo prazo.”

Baseado no que o cliente responder voce vai implementar esses requisitos, e eles vao ter que atender aquilo a que voce se propos, do contrario nao ha qualidade no seu trabalho.

Essa é uma ideia absurda, se é economicamente inviavel voce testar todas as possibilidades, voce TEM que conversar com o cliente, explicar que nao é possivel por agora ter todas as possibilidades de consulta. Ele vai dizer quais devem ficar e quais podem esperar. Voce nao tem como saber isso, voce nao pode dizer o que é testado e o que não é. Voce pode definir que tais variacoes serao implementadas, mas na hora que for pra producao, determinados usuarios podem precisar justamente daquelas que nao foram testadas. E ai? Ah vai pro servicedesk, mas o sistema nao funciona pra aquele usuario, logo nao tem qualidade nenhuma pra ele.

O custo de um cliente insatisfeito pode ser muito maior que esse calculo ridiculo que voce pos ai. O que foi implementado nao atende os requisitos e um sistema que nao atende os requisitos no prazo que foi estipulado, pode ter o contrato revisto. Nao é todo mundo que cai nessa conversa nao.

Voce tambem nao pode decidir o que é critico e o que nao é. Aquela pesquisazinha que voce considera bobagem pode ser critica para um usuario que voce nem conhece. Nenhum gerente tem condicoes de dizer o que é e o que não é critico. Só o cliente pode dizer, e se o japones da quitanda diz que o cadastro de clientes dele é critico, pra mim é tao crítico quanto a possibilidade de perdas financeiras do banco. Ambos devem ser tratados da mesma forma.

Ninguem esta falando em testar demais, tem que testar o que precisa ser testado, nao o que o gerente acha que talvez, quem sabe possa ser testado.

Impressionante como os gerentes, ou pretensos gerentes, subestimam testes unitarios, muitas vezes seque sabem o que sao. Subestimam tanto ou mais do que nós desenvolvedores os superestimamos.

#20

Entao, Marcos, é como eu disse pro Fernando a minha revolta nao é contra o Fernando, mas sim contra a ideia que ele defende. E to traumatizado sim hehehe, porque vivo num ambiente que prega exatamente essa teoria e resultado disso é lixo.

Sobre os seus exemplos do post-it, quero deixar claro que nao prego baderna. Se a equipe que voce citou usasse testes unitarios esse tipo de problemas seriam bem menores.

#22

Fernando, tem sim algum material interessante sobre scrum


Um livro sobre user stories, mas bastante interessante pra quem esta estudando scrum.

Tambem sobre extreme programming