Click here to edit title

Click here to edit subtitle

Blog

O que vocês fazem?

Posted by JJ on January 27, 2015 at 10:50 PM Comments comments (0)
Em pleno 2015...

Essa foi a frase mais esperada na chegada desse ano. 

Então, para começar o ano bem, um artigo que vem de encontro ao que diz no bordão e à um assunto que volta e meia é debatido. O fato de saber o que temos que testar, para a partir dessa resposta iniciarmos nossos trabalhos. 




Enfim, sabermos o que temos que testar é algo importantíssimo, daí nos dá um próximo passo, o que temos que garantir, assim atuando com os 5W2H. Podemos então, voltar à temas já mais que discutidos anteriormente em várias comunidades, livros, eventos e demais. Onde, na maioria dos casos, cerca de 65% se chega à conclusão de que devemos levar em consideração às características conhecidas e listadas pela extinta ISO-9126.

 

  • Funcionalidade
  • Usabilidade
  • Performance
  • Manutenibilidade
  • Portabilidade
  • Operacionabilidade
  • Eficiência
  • Segurança
  • Conectividade
  • Continuidade

 

 

 

Mas, daí sempre vem aqueles comentários: "Poxa, o mundo mudou", "Isso é coisa de dinossauro", "Cade agilidade?", "A vida não é mais como antigamente". 

Então surgem as perguntas:

O que temos que realmente testar?

O que temos que garantir para que o sistema possa ser entregue ao cliente?

O que devemos garantir principalmente?

O que devemos garantir no mínimo?


Perguntei à alguns colegas que são destaques no Brasil do Oiapoque ao Chuí, a seguinte interrogação: 

"O que devemos garantir minimamente para aprovar um SW?" As respostas foram as seguintes:


"Em dias atuais, devemos pensar em usabilidade, o sistema pelo menos deve ser intuitivo e de fácil manuseio. O usuário ao olhar pela primeira vez para um SW ele tem de se familiarizar, identificar facilmente qual o intuito e como chegar ao seu objetivo.
Depois deste, as funcionalidades básicas e seus desdobramentos devem ser garantidos. Desempenho e capacidade vão sendo avaliadas e melhoradas de acordo com a necessidade real deste Software.
"


Kamilla Queiróz
GTS-CE




Robson Agapito
Testadores.com

" Sempre devemos olhar para o risco, e levar em consideração onde se perderá dinheiro.
Se for um software de vendas, o ponto mais importante pode ser no checkout, que finaliza a venda, então seria onde focaríamos os testes.
Sempre os seus casos de testes devem estar priorizados conforme a criticidade, e a partir disso testar o mas crítico primeiro e testar os casos de menor criticidade depois conforme o tempo disponível.
Outro detalhe, comece pelo "happy path", pois se este não funcionar nem vale a pena continuar o teste do "pacote" disponível.
"



"A garantia de que as expectativas do dono do produto sejam atendidas.
Mas você me fala: "Só isso?"
E eu digo: Sim!
Podemos ter a nossa experiência para colaborar e lapidar essa ideia, mas no final de contas, essa expectativa é a que precisa ser atendida. Linha de pensamento: "Ele pensou em algo, ele vai administrar (de maneira ou outra) e ele precisa estar confiante com aquilo. Sobre a tecnologia e como vai ser feita, isso é parte do nosso entusiasmo".
"


Ramsés Saccol
GUTS-RS




Vimos aqui várias opiniões e respostas para a mesma pergunta. O que se tem, são, visões e ambientes diferentes que resultam em diferentes formas de abordar um determinado assunto. 
Assim, uma das várias faces do Teste de Software que venho pesquisando à fundo nesses últimos anos, é com o intuito de trazer algo que possa servir para vários tipos de abordagem, ter visões iniciais, onde podemos partir do mesmo princípio para poder assim após este princípio chegar aos seus níveis de conhecimento e de atuação.
Um dos grandes desafios hoje é ter um conceito base à toda área de desenvolvimento de software. Se fizermos a pergunta a 50 pessoas envolvidas no desenvolvimento de software, em todo o Brasil, teremos cerca de 80% das respostas uma diferente da outra.

Um novo capítulo da Literatura dos Testes de Software, a Era que transcendem os Livros e vão de encontro à internet, diretamente nos Blogs.


Respondendo à pergunta feita em uma frase:

"Devemos garantir inicialmente 3 pontos, duas características vistas até hoje como principais: Usabilidade e Funcionalidade. E uma terceira característica relevante ao negócio"


Vamos à parte científica da resposta:

Desenvolvi uma prática bem interessante para partirmos do pressuposto de cada tipo de sistema com que vamos lidar. Uma técnica que persiste em definir um Triângulo da Qualidade onde vamos respeitar 3 lados que buscaremos garantir ao longo do projeto até sua entrega(o que garante no mínimo esses três pontos definidos no início).

SG = UF + x
Dado que Sistema Garantido é um sistema que atenda Funcionalidade e Usabilidade mais uma terceira característica relevante ao negócio.


Qual a diferença do que temos até hoje?

Nos últimos 15 anos recebemos um grande volume de literatura e uma massa enorme de informações para podermos atuar, para garantir a qualidade de um sistema. Técnicas para atuarmos no desenvolvimento e novas formas de desenvolver. Contudo, poucas formas de simplificar, poucas metodologias com que nos ajude de forma rápida a dizer o que temos que fazer, para garantir o mínimo. Podemos encontrar outras, utilizar outras e até aplicar metodologias de outras áreas de atuação dentro do desenvolvimento de um software. Mas essa vem de encontro ao que chamo de "praticidade de informação", ter aquele norte de forma prática.


Qual a metodologia?

Ao longo dos anos, viemos aprendendo novas técnicas de desenvolvimento dos testes e do controle da qualidade, porém, partindo de um lado gerencial e analítico para definirmos onde queremos chegar, foram poucas as novidades. 
A metodologia do Triângulo dos Testes, nos trás uma simplificação, uma forma de buscarmos aquela qualidade do software com que perdemos ao longo do desenvolvimento de um software. Com o passar do tempo dentro de um ciclo de desenvolvimento, seja ele um ERP de 30.000 horas de desenvolvimento, seja um Hotsite com 200 horas de desenvolvimento. Nos perdemos na hora de garantir o básico. 
Os pontos básicos para a garantia são esquecidos durante o desenvolvimento do software, então com esta simplificação, poderemos buscar a todo momento o que vamos garantir e chegar no resultado, seja após 15.000 depois do planejamento inicial do ERP, sabendo onde queremos chegar, seja, após 100 horas do desenvolvimento do Hotsite.


Como vamos definir os pontos a serem principais?

De acordo com o negócio de atuação do sistema. A base do triângulo, nos definimos com duas características: 

  • Funcionalidade
  • Usabilidade

A funcionalidade, é definida como base, pois nenhum sistema deve ser entregue sem as funções as quais ele deve atender. 
A usabilidade, é definida como base, pois o sistema tem de ser pelo menos utilizável

A terceira, é definida como variável através do negócio do sistema. 


Triângulo dos Testes de Software.

Partindo desta garantia, vai de cada tipo de negócio e exigência a partir do cliente, garantir outras características, bem como Portabilidade(hoje a 3° principal característica de um software), Performance seguida de Segurança. Entre outras mais especificas.


Triangulo UFPo


Triangulo UFS


Triangulo UFPe



A proposta é apresentar este novo método, essa visão dos Testes de Software. Bem como uma atual orientação dos testes. Um princípio atual e futuro, de onde possamos partir dele. Visto que é embasado em tudo o que foi dito no passado até hoje e prontamente utilizando esta base, para fazer esta melhoria consideravel na visão dos Testes de Software. 


Conhecendo os Triângulos dos Testes


Entendendo que nós precisamos garantir um mínimo de Qualidade, então sugiro essa metodologia de Garantia mínima da Qualidade. Aqui descrevemos sobre 3 tipos de Triângulos iniciais da Garantia da Qualidade.

Sabemos que temos que garantir os cenários de testes referentes à Funcionalidade e a Usabilidade, então, qual outra característica devo acrescentar? 



Triângulo UFPo

     Com esta abordagem, você pode prontamente definir o inicio dos Testes, com testes mínimos garantindo a qualidade pela Usabilidade, Funcionalidade e Portabilidade.

     A portabilidade representa a garantia do nosso sistema funcionar minimamente em mais de 1 plataforma. Nos casos Web, de funcionar em mais de um Browser, nos casos Mobile, funcionar em mais de 1 aparelho homologado.

Tipos de sistemas:

  • Sistemas Web
  • Sistemas Mobile
  • Games

     Assim ao definir que utilizaremos este Triângulo no inicio do desenvolvimento para garantir estas três caracteristícas, garantiremos que nosso sistema satisfaz os critérios mínimos das funcionalidades, é usável e possível de ser utilizado em mais de uma plataforma.



Triângulo UFPo



Triângulo UFS

     Com esta abordagem, você pode prontamente definir o inicio dos Testes, com testes mínimos garantindo a qualidade pela Usabilidade, Funcionalidade e Segurança.

     A Segurança é algo cada vez mais essencial nos dias de hoje, visto que a informação está para qualquer um na internet inclusive com a web em nuvem hoje.

Tipos de sistemas:

  • Sistemas que envolvem transações e integração entre sistemas.
  • Sistemas envolvendo Informações pessoais
  • Sistemas em Nuvem

    A abordagem definida com o Triângulo UFS, sugere uma garantia das características do sistema com a relevância em Segurança, assim, os termos de Usabilidade e Funcionalidade, devem por si, atuarem também com cenários que tendem a garantir que dados sejam protegidos pelo sistema.



Triângulo UFS

 



 

Triângulo UFPe

     Com esta abordagem, você pode prontamente definir o inicio dos Testes, com testes mínimos garantindo a qualidade pela Usabilidade, Funcionalidade e Performance

    Um sistema lento, que não utiliza de forma adequada os componentes utilizados pelo Hardware, sem uma arquitetura de código bem definida hoje pode ser algo prejudicial ao negócio do cliente.

Tipos de Sistemas:

  • Sistemas embarcados
  • Sistemas Desktop
  • Sistemas BI

    Com a abordagem do Triângulo UFPe, você define que abordará as regras de negócio e usabilidade, mas não apenas, que se preocupara com a arquitetura do software, e quão rápido você consegue obter a informação e dispôr ela na tela.



Triângulo UFPe

 


Esta metodologia pode ser utilizada livremente, também combinada com qualquer tipo de característica. Assim dependendo do usuário que esteja realizando o planejamento. As sugestões dos três Triângulos são sugestões aplicáveis.

 


Pirâmide da Qualidade de Software 

Após termos em mente que o mínimo necessário no nosso atual cenário mundial de Qualidade de Software, temos então 2 características fundamentais e uma variável.

SG = UF + x

Vamos evoluir o cenário da Abordagem da Garantia de Qualidade e quais características e Testes utilizar para  garantir com mais profundidade o Sistema.

Se combinarmos os 3 triângulos principais, citados acima, teremos a Pirâmide dos Testes. Assim, teremos uma maior garantia com cenários de testes em várias características.

Podemos também definir os quatro quadrantes base de sua pirâmide, assim definindo o Quadrado dos Testes. Porém em um segundo momento considerando o 5° elemento(o qual seria a ponta da pirâmide).


SG = UF + xy ± z  
logo
SG = UFxy + z ou SG = UFxy - Z






Pirâmide dos Testes





Assim, ao ser perguntado novamente, poderemos ter algo na ponta do lápis(lingua), para respondermos onde queremos que nosso sistema atenda com uma Qualidade Mínima que se espera dele.
Este artigo mostrou ainda que de forma simples um norte para você iniciar seus Testes, sabendo o que você deve garantir ao menos para entregar seu produto. 
Lembrando que esta sugestão metodológica não é uma Garantia Completa, mas sim a Garantia Mínima. 


Contribuições e Revisões: 
Ramsés Saccol
Kamilla Queiróz
Robson Agapito
Patrícia Araújo
Luana Lobão
Augusto Magalhães

Por

Reporte de Bugs

Posted by 4AllTesters on December 22, 2014 at 9:25 AM Comments comments (3)

O Júlio de Lima pediu pra eu falar sobre "Como melhorar o reporte de bugs".


Isso me surpreendeu por dois motivos. O primeiro, é que eu não estava acostumado com o uso de 'reporte' como substantivo.

O segundo motivo é o fato de entre todos os assuntos que apareceram até agora durante o desafio, este é o que mais combina comigo - obrigado pela escolha e pela aula de vocabulário, Júlio!

 



Reporte de bugs é que é um tópico muito amplo, e dá para escrever um sem-fim de artigos sobre isso!


Escolhi escrever um texto bem especifico, sobre a maneira de escrever um relatório de bug. Esses textos de reporte são de extrema importância na atividade de testes: Nosso esforço tem como objetivo descobrir informação sobre áreas de risco, e a maneira de expor essa informação é reportando os defeitos encontrados.


Descrições detalhadas tornam-se mais valiosas ao incluir evidencias (logs, screenshots, códigos de erro), ao definir quais as condições mínimas para replicação da falha, ao incluir os passos executados durante o debug. Mas talvez o mais importante seja seu título! Se os relatórios são parte essencial de nossa atividade de testes, os títulos são o coração dos relatórios.

 


Um bom título é um ponto onde mesmo um melhora pequena tem benefício multiplicado e grandes resultados.

Ha vários motivos para a importância dos títulos: É o primeiro encontro que qualquer um (parceiro de equipe, programador, gerente, cliente) tem com o problema exposto. Durante reuniões de triagem, poucas vezes há tempo ou vontade de ler mais do que esse resumo de uma linha. E muitos times optam por uma administração de defeitos mais ligeira, com post-its ou adições as estórias de desenvolvimento, onde não há necessidade (ou espaço) para mais que um cabeçalho.

 

Neste artigo, vou defender a apresentação dos bugs em linguagem de negócio e não técnica. Que o título contenha o efeito no negócio ao invés da descrição técnica do problema.

Ao usar uma linguagem genérica que se adapta ao negócio, detachamos o problema técnico e criamos uma conversação sobre risco e sobre valor ao cliente. Especificamente, ganhamos:

  • Melhor exposição do problema real
  • Decisões de severidade mais precisas
  • Decisões com encarregados do negócio
  • Menor autoridade técnica nas discussões sobre o bug



Mais fácil do que explicar esses benefícios, vamos dar exemplos:

 

[Versão a] Error 404 ao abrir link 'conexões' na página order.aspx.

[Versão b] Não existe informação disponível sobre os tipos de conexão durante a encomenda.

Qual a severidade da primeira versão do bug? Alguém precisa explicar qual a página order.aspx, que informação existe nela e no link, quais as outras formas de obter esse conhecimento. No segundo, isso está explicado. Quem toma as decisões de negócio pode com facilidade decidir a severidade deste bug.

 

[Versão a] BSoD (tela azul) acontece quando momentaneamente não há memória disponível no dispositivo.

[Versão b] Usuário perde controle do sistema operacional - potencial perda de dados! - de forma esporádica (maiores chances com uso extensivo do dispositivo).

Ficou mais comprido, eu sei. Mas a nova versão permite ao gerente, PO, ou outros encarregados do negócio participar da decisão sobre como e quando concertar. Apesar da reprodução do bug ser consistente quando não há acesso a memória, o acesso a memória não é consistente, e a segunda versão dá uma chance a interessados de perguntar sobre a frequência em que isto pode acontecer.

 

[Versão a] Drag-and-drop não habilitado para sub-itens no Chrome (versão 8 e acima)

[Versão b] Adição ao catalogo é feita diferente em navegadores Chrome (14% dos clientes)

Neste caso, não apenas a informação do impacto ao usuário é clara, como ela remove a discussão técnica. Um debate típico sobre o primeiro título incluiria "é obvio, a biblioteca gráfica que usamos não suporta Chrome" e logo estaríamos em uma argumentação técnica sobre a biblioteca. No segundo título, por outro lado, a conversa será sobre a experiência que gostaríamos de prover a um de cada oito usuários, sem autoridade técnica.

 


Espero que esses exemplos tenham deixado claro umas sugestões sobre como escrever os títulos, mas também esclarecido os benefícios de uma abordagem que foca o negócio:

  • Melhor exposição do problema real
  • Decisões de severidade mais precisas
  • Decisões com encarregados do negócio
  • Menor autoridade técnica nas discussões sobre o bug

 

Boa sorte - qualquer pergunta ou reclamação é bem-vinda!


Shmuel

Ciência do Teste de Software

Posted by JJ on December 8, 2014 at 10:10 AM Comments comments (0)
Mais uma fase de evolução natural do Portal Aprendendo a Testar.



A página Ciência, mostrará referências bibliograficas para estudo, pesquisa, trabalhos, modelos e processos para o Mundo dos Testes de Software.

 

Iniciei esta seção querendo chama-la de Literatura, porém, como em tudo o que tento passar busco fontes e pesquiso sobre aquilo.

 

"A Literatura é a arte de compor e expor escritos artísticos, em prosa ou em verso, de acordo com princípios teóricos e práticos, o exercício dessa arte ou da eloquência e poesia."

 

Conjunto de obras literárias: 1 bibliografia.
Conjunto de escritores: 2 autores, escritores, poetas.
Saber e erudição: 3 ciência, erudição, instrução, letradura, letras, saber.

 

Então após fazer algumas pesquisas e estudar um pouco, dei o nome de: Ciência.


"Em sentido estrito, ciência refere-se ao sistema de adquirir conhecimento baseado no método científico bem como ao corpo organizado de conhecimento conseguido através de tais pesquisasRef."


Qual o Objetivo desta sessão? 


Um lugar que possamos consultar e ver vários tipos de livros, monografias, artigos cientificos, colunas de revistas e tudo mais sobre Testes de Software.

Quem tiver, ou conhecer alguém que tem, basta enviar este link e pedir para pessoa preencher.

 


Então, é isso, espero que seja util para quem precise.

Testador largue o mouse e o teclado

Posted by JJ on June 29, 2014 at 4:05 PM Comments comments (0)

Há algum tempo venho pensando sobre o futuro da tecnologia, entre pesquisas e estudos de novas tecnologias, sobrevivendo com um trabalho onde na maioria das empresas era levado em um 3°, 4° ou 5° plano, e que hoje já não posso dizer mais, a Área de Testes em seus conceitos se tornou importante em um país que é considerado o País do Jeitinho.


 

Outrora não tínhamos acesso à tecnologia da informação, onde tudo era caro, ter um computador em casa era coisa de rico, internet passou com o tempo a poder ser acessada através de horários específicos(meia noite às seis), depois chegaram notebooks, telefones celulares, de repente booom, hoje temos o que temos.


 

Quando iniciei nos Testes, não tinha a mínima ideia do que estava fazendo, foi com o tempo que se vai aprendendo a verdadeira essência e o que são os testes. Do famoso testa ai pra ver se acha alguma coisa(que hoje ainda existe), até hoje automação de testes, pra que perder tempo se testando uma ferramenta 200 vezes(cenários diferentes)? Se você pode automatizar isso e a cada nova funcionalidade você se preocupar apenas com ela.


 

E o que dizer da tecnologia? A anos quem acompanha a industria dos games, ouve falar sobre realidade virtual, chegou a hora, o Project Morpheus esta ai. Quem tinha celular em 2003 um Nokia 3310(jogava cobrinha) imaginaria existir um Sony Z1(multi touth a prova d’gua). Celular com Holograma ta chegando.


 

Está chegando a Era Hands Free.


A tecnologia Hands Free, nos permitirá a digitar, movimentar o ponto focal tudo sem tocar no gadget.




Nunca estivemos tão perto de ter tecnologias como as do Homem de Ferro, hologramas, trabalhar com as mãos, os olhos, interação com outras pessoas.



 

Eu como todo grande fã do herói marvel, esperava quando poderiamos ter esse tipo de tecnologia à nossa disposição.


Tudo isso, está chegando e muito mais. Desde ano passado quando palestrei no TDC Floripa, fiquei atento e estou acompanhando as diversas atualizações do Perceptual Computing da Intel.


 

Para essa tecnologia sugiro que “Largue o mouse e o teclado” além de automação vá estudar física, ergonomia, anatomia e variações de ambientes. Pois teremos um novo patamar de tecnologia à ser Testada. Sistemas Desktop, Sistemas Web, Sistemas Mobile(entre outras tecnologias) e “agora” Sistemas Hands Free.


 

Estão ai algumas impressões sobre o que temos e o que podemos esperar.


Referências:

Nokia 3310 - http://pt.wikipedia.org/wiki/Nokia_3310

Sony Z1 - http://www.sonymobile.com/br/products/phones/xperia-z1/

Holograma - http://www.tecmundo.com.br/holografia/57536-smartphone-holograma-com-novo-chip.htm

Hands-Free Computing - http://en.wikipedia.org/wiki/Hands-free_computing

Perceptual Computing - http://en.wikipedia.org/wiki/Perceptual_computing

 


 

Testing with Selenium using commands While and XPath

Posted by JJ on May 19, 2014 at 4:50 PM Comments comments (1)


So,

I decided to write this post to help with 3 functions of Selenium IDE. And I translate for to english, for my friends Indians, with we study selenium. So, sorry about my english, again. And too, sorry my, brasilian friends what know english best me.


1- Variable

2- While

3- XPath


So, what doing my scrit basicaly?


 

He create an environment for repeatition, and I can insert one any test.


In the example, I insert a test, what was to click in a button "Convidar" of a Facebook fanpage. For this test, I insert a quantity of repeat of 50 times.

Inserting a condition wherein While is until 50, I start to test agin.

 



Well, my test will to click in the button "Convidar" for invite my friends to like fanpage of 4All Tests. But you joke with the script wherever

 


Before ending the condition,  after the test Increment the variable, so, after at 13th test he incrementing the variabel, going for the 14th test(this is an example)



The part interesting, is to use the XPath, and my test get consistent in case where Id of button changes.

 

I post an article translate to portuguese about XPath




So, our test automation like this:


Script


*Look this,  it is important put a bar over there in target, because it is copied whith only a single bar. '//'


So look how our script works



On the step 1, he open the fanpage



Step 1




On the step 2, I declare my variable "QTD" and i change the his value for "1"


Step 2




In step 3, the condition of my command "While" checks if the my variable "QTD" is less than or equal to 50. If so, to do the test, if it is not less than or equal to 50, or 50 is equals or higher (51, ​​52 ...) for this condition and it goes straight to "EndWhile" command.


Step 3




In step 4 I will do all that is in my test, yes(in example), click the invite button.


Step 4




In step 5, after my test I add to the variable "QTD" the value "1" plus the value that is in "QTD".


Step 5



The script for download here https://github.com/testejoaojunior/Selenium/blob/master/While_com_variavel_incremental.html" target="_blank" rel="nofollow">in git.



So, brothers, sorry my english, and I not used google translate, kkkkkk.


And, rememer:

Testing software is not breaking it. It look simple and develops it.

While com variavel incremental

Posted by JJ on May 5, 2014 at 10:35 AM Comments comments (4)

Então, esse post estava aqui esfriando desde o dia 05 de maio(hoje 19).


Resolvi escrever este post pra ajudar com 3 funções do Selenium IDE.


1- Variável

2- While

3- XPath


O que meu script basicamente faz?


Ele cria um ambiente de repetição para eu poder inserir um teste qualquer.

No exemplo, inseri um teste que era clicar no Botão Convidar de uma página do Facebook. Para este teste, inseri uma quantidade de repetições de 50 vezes.

Inserindo uma condição em que Equanto minha variável não atingir o valor de 50, eu rodo o teste.


Veja bem, meu teste vai clicar no botão convidar para convidar os meus amigos para curtirem a página do 4All Testes no Facebook. Mas se você utilizar este script você pode brincar a vontade.


Antes de terminar a condição, logo após o Teste eu incremento a variavel, logo, após o 13° teste ele incrementa a variavel, indo realizar o 14° teste(exemplo).



Uma parte interessante é utilzar o XPath, assim meu teste fica mais consistente caso o Id do botão mude.

Eu publiquei um artigo de um post traduzido sobre XPath.



Então o nosso teste automatizado fica da seguinte forma:


Script


*Note que é importante colocar uma barra a mais no alvo, pois ele é copiado apenas com uma unica barra '//'


Vejamos como nosso script roda:



No passo 1 ele abre a página do facebook.


Passo 1




No passo 2 eu declario minha variavel "QTD" e dou o valor "1" à ela.


Passo 2




No passo 3, o meu comando de condição "While" verifica se minha variável "QTD" é menor ou igual à 50. Caso seja, realiza o teste, se não for menor ou igual a 50, ou seja, for igual a 50 ou maior (51, 52 ...) ele para a condição e vai direto ao comando "EndWhile".


Passo 3




No passo 4 eu vou realizar tudo que está dentro do meu teste, ou seja, clicar no botão convidar.


Passo 4




No passo 5, após meu teste eu acrescento à variável "QTD" o valor "1" mais o valor que estiver em "QTD".


Passo 5



O script pode ser baixado aqui https://github.com/testejoaojunior/Selenium/blob/master/While_com_variavel_incremental.html" target="_blank" rel="nofollow">no git.



Então pessoal, fica ai, este exemplo de While no Selenium IDE. Até mais pessoal.

Xpath

Posted by JJ on May 1, 2014 at 9:20 AM Comments comments (10)

Vamos entender um pouquinho sobre XPath


Você precisa fornecer qualquer elemento localizador(como id, nome, caminho css, XPath, etc) na coluna de destino do selenium, para localizar esse elemento específico e executar alguma ação. Se você conhece Selenium IDE, então você sabe que às vezes não contém elementos de identificação ou nome assim o seu teste para ali. O XPath é uma outra maneira de localizar o elemento e você pode usá-lo como uma alternativa de identificação ou nome do elemento.

 

XPath no documento XML mostra a direção do local do elemento através de nós e atributos. Vamos tentar entender como identificar XPath do elemento com exemplos.

 


A imagem acima é tirada de http://www.wikipedia.org/.


               


Olhe para a imagem, existem três campos

  1. Caixa de texto Input
  2. selecionar cair para baixo
  3. botão de entrada.


E abaixo desses campos há expansão de nós XML relativas através firebug. Como você vê na imagem, você pode usar "id = searchInput" ou "name = search" para identificar a caixa de entrada de texto para digitar algo nele como exemplo dado abaixo.

 

New Test
CommandTargetValue
openhttp://www.wikipedia.org/
typeid=searchInputID Example

Ou

New Test
CommandTargetValue
openhttp://www.wikipedia.org/
typename=searchName Example


Tutorial XPath


Agora, se você quer identificar o mesmo elemento (caixa de texto de entrada) com XPath, então você pode usar qualquer uma sintaxe abaixo dada para a coluna de destino com o comando tipo no exemplo acima.

 

Localizando elemento usando XPath com exemplos caixa de texto de entrada para

 

1. Identificar XPath usando caminhocompleto do XML

xpath://body/div[3]/form/fieldset/input[2]/ / / /

Aqui = / / body é o nó raiz principal, / div [3] descreve a terceira div nó filho do nó pai corpo, / form descreve a form nó filho do nó pai div [3] / fieldset descreve o fieldset nó filho de form nó pai, / input [2]descreve a entrada do segundo nó filho do nó pai fieldset.

 

New Test
CommandTargetValue
openhttp://www.wikipedia.org/
typexpath://body/div[3]/form/fieldset/input[2]Xpath Example1


 

2. EscritaXPath usando last()

xpath://body/div[3]/form/fieldset/input[last()-2]  / / / /

Aqui = / input [last () -2] descreve o nó de entrada superior 3 (entrada [2]) a partir de último nó de entrada.

xpath://body/div[3]/form/fieldset/*[last()-3]  / / / /

Aqui / * [last () -3] descreve o quarto nó superior(entrada [2]) da última nó.

 

New Test
CommandTargetValue
openhttp://www.wikipedia.org/
typexpath://body/div[3]/form/fieldset/input[last()-2]Xpath Example2



3.Localizador XPath usando @ e atributo

XPath= / / body / div [3] / form / fieldset / input [@ type = 'pesquisar']   // / /

Aqui / input [@ type ='pesquisar'] descreve o nó de entrada com atributo type = 'pesquisar'


New Test
CommandTargetValue
openhttp://www.wikipedia.org/
typexpath://body/div[3]/form/fieldset/input[@type='search']Xpath Example3


 

4.Expressão XPath usando @ e atributo

XPath= / / corpo / div [3] / form / fieldset / input [@ accesskey = 'F']   // / /

Aqui / input [@ accesskey = 'F'] descreve o nó com atributo de entrada @accesskey = 'F '.


New Test
CommandTargetValue
openhttp://www.wikipedia.org/
typexpath://body/div[3]/form/fieldset/input[@accesskey='F']Xpath Example4


 

5.Sintaxe XPath usando @ e atributo

XPath= / / input [@ accesskey = 'F']   / / / /

Aqui / / input [@ accesskey = 'F'] descreve o nó de entrada com [email protected] accesskey = 'F' . Experimente por usá-lo em exemplo acima.

 


6.Exemplo XPath usando @ e atributo

XPath= / / input [@ type = 'pesquisar']    / / / /

Aqui / input [@ type = 'pesquisar'] descreve o nó de entrada com atributo type = 'pesquisar'.  Experimente, utilizando-o no exemplo acima.

 


7. XPathXML usando / descendente :: palavra-chave

 

xpath://div[@class='search-container']/descendant::input[@accesskey='F']   // / /

 Aqui eu usei descendente no meio. Neste caso eu descrevi apenas começando div nó com classe de atributo = 'pesquisar-container "e de entrada do nó final com accesskey = atributo' F'. Portanto, não precisa descrever entre os nós.  Experimente por usá-lo no exemplo acima.

 


8. XPathexemplo consulta usando contém palavra-chave

XPath= / / input [contains (@ id ", searchInput")]   // / /

Aqui contém palavra-chave para identificar atributo id com o texto "searchInput".  Experimente, utilizando-o no exemplo acima.

 


9. XPathusando e com atributos

xpath://input[contains(@id,"searchInput") and contains(@accesskey,"F")]   ")]   / / //

Neste exemplo, ele vai olhar para dois atributos no nó de entrada.  Experimente por usá-lo no exemplo acima


10. XMLvalor valor XPath usando posição ()

xpath://div[@class='search-container']/descendant::input[position()=2]   // / /

Este XPath irá selecionar nó de entrada que está na posição de número 2 e é a caixa de texto de entrada para como mostrado na imagem. Experimente por usá-lo no exemplo acima.

 


11.Usando starts-with palavras chave

xpath://input[starts-with(@type,"s")]        // / /  

 Neste exemplo, ele vai encontrar nó de entrada com o atributo é 'tipo' e seu valor está começando com 's '(aqui ele vai ficar type =' search ' ).

 


12.Usando OR (|) com condição XPath

xpath://input[@accesskey='F'] |//input[@id='searchInput']

xpath://input[@accesskey='F' or @id='searchInput'] / / / /

 

Em ambos estes exemplos, ele vai encontrar a caixa de entrada de texto com accesskey = 'F' ou @ id ='searchInput'. Se qualquer um encontrado, então ele irá localizar. Muito útil quando os elementos aparecem como alternativa.


13.Usando curinga * com a encontrar elemento XPath

XPath = / / * [@ accesskey = 'F'] 


14.Encontrar enésimo elemento filho de pai

XPath = / / corpo / * [3] / form / fieldset / * [2]    / / / /

Este XPath é a caixa de texto para pesquisa. Aqui, / * [3] descreve o terceiro elemento filho do corpo, que é div [3]. Do mesmo jeito * [2] descreve o segundo elemento filho de fieldset que é de entrada [2]


Todos os exemplos acima são caixa de texto de entrada para. Agora deixe-me escrever XPath para drop down.

 

ExemplosXPath queda para baixo

1. xpath://body/div[3]/form/fieldset/select

2. xpath://body/div[3]/form/fieldset/select[last()]

3. xpath://body/div[3]/form/fieldset/select[@id='searchLanguage']

4. xpath://body/div[3]/form/fieldset/select[@name='language']

5. xpath://div[@class='search-container']/descendant::select[@name='language']

6. xpath://select[contains(@id,"searchLanguage")]

7. xpath://div[@class='search-container']/descendant::select[position()=1]

8. xpath://body/div[3]/form/fieldset/select[count(*)>1]

 

New Test
CommandTargetValue
openhttp://www.wikipedia.org/
selectxpath://div[@class='search-container']/descendant::select[position()=1]label=English



Outros Exemplos de XPath


1.Encontrar XPath para o link target 'url'

//a[@href='//meta.wikimedia.org/wiki/List_of_Wikipedias']  / / / /

 Este exemplo XPath vai encontrar ligação com determinada URL (/ / meta.wikimedia.org / wiki /List_of_Wikipedias) na página.

 


2. Encontrar XPath do elemento com nenhuma criança

xpath://img[count(*)=0]   ///// /

Este XPath é para logotipo do texto wikipedia que é exibição na parte superior da página. Este XPath vai encontrar esse elemento de imagem que não tem qualquer elemento filho. Aqui nó imagem é passado e não tem qualquer elemento filho.

 

xpath://div[2]/descendant::img[count(*)=0]   / / / / 

 Este XPath é imagem do logotipo wikipedia que é exibição sob logotipo para texto. 

 



Artigo traduzido de: http://software-testing-tutorials-automation.blogspot.com.br/2013/06/xpath-tutorials-identifying-xpath-for.html

Tecnicas de Especificacao de Testes

Posted by JJ on January 24, 2014 at 6:10 AM Comments comments (6)

Achei que eu tivesse postado esse artigo a um ano atrás, estive vasculhando aqui o blog e não postei. Então vejamos.

Este artigo te ajudará a enfrentar o perigo: testar sem um cenário.


Elaboração do Plano de Caso de Teste


O Plano de Caso de Teste é o documento que registra todo o planejamento dos testes dos requisitos estabelecidos durante o ciclo de desenvolvimento do software. Esse documento determina o que será testado, e seu principal objetivo consiste em identificar o maior número de cenários e variações de determinado requisito de software. Cada cenário será representado por um conjunto de casos de testes a ser validado por uma lista de procedimentos, incorporados numa suíte de testes que posteriormente será executada. Os casos de teste estabelecem quais informações serão empregadas durante os testes desses cenários, quais os resultados esperados e a massa crítica de testes necessária para validar todos os requisitos do software.


Definiçãodo Caso de Teste


 

Em geral, define-seformalmente um caso de teste como a especificação mais detalhada do teste, coma pormenorização de campos de telas, formulários etc. Estabelece quaisinformações serão empregadas durante os testes dos cenários e quais serão osresultados esperados. Para isso, é necessário determinar a massa a serutilizada no teste de modo a validar todos os requisitos do software.

 


Um bom caso de teste deve conter:


·        Identificação das condições de testes:

             o  Pré-condições;

             o  Pós-condições;

             o  Critério de aceitação.

·        Identificação dos casos de testes (o que testar).

·        Detalhamento da massa de entrada e de saída.

·        Critérios especiais, caso necessários, para ageração da massa de teste.

·        Especificação das configurações de ambienteno qual o teste será executado: sistema operacional, ferramentas necessárias, origem dos dados etc. (onde testar).

·        Definir o tipo de implementação do teste: automática/manual (como testar).

·        Definir o cronograma, ou seja, em qual fase esse teste será executado (quando testar).

·        Listar as interdependências, casos existam, entre os casos de teste.


O caso de teste deve ter as características a seguir para que possa ser usado e atender às expectativas de validação de qualidade:


·        Efetivo: testar o que se planejou testar;

·        Econômico: sem passos desnecessários;

·        Reutilizável: que possa ser repetido;

·        Rastreável: que possa identificar o requisito a ser testado;

·        Auto-explicativo: que possa ser testado por qualquer testador.

 

Especificação de Caso de Teste: Define os casos de teste, o que inclui os dados de entrada, os resultados esperados, as ações e as condições gerais paraa execução do teste. Utilizaremos a nomenclatura de Plano de Caso de Teste para esse documento gerado.

 

Qual a importância de documentar casos de teste?

·        Descrever o passo a passo de cada caso de teste;

·        Importante para permitir a disseminação do conhecimento e para ajudar na manutenção;


Existem diversas ferramentas no mercado que auxiliam nesse processo de documentação, como:

             o  Testlink

             o  Jira

             o  Rational Test Manager

             o  Rational Quality Manager

 

Vamos exemplificar técnicas de elaboração para telas de cadastros


- Procure descrever um caminho curto e objetivo

- Procure descrever da forma mais sucinta possível o Caso de Teste

- Procure elaborar o caso de teste com o menor número de passos possíveis

- Se um Caso de Teste ficar maior do que o Caso de Uso, procure dividir em mais Casos de Testes

- Em um Caso de Teste ágil, tente colocar as condições para a ação, a ação a executar e se possível os resultados esperados (é desejável, pois na maioriadas vezes não conhecemos o resultado)

 

 Entre outras, estas técnicas podem ajudar a criar um Caso de Teste até mesmo bem dinâmico com o testador que irá executar o teste.

 


 

Agora vamos ao exemplo de Um caso de Teste Elaborado de forma tradicional eum Caso de Teste Elaborado de forma Ágil, assim como um elaborado de forma Hibrida.

 

CT002 - Validar Cadastrar Time

Objetivo: Cadastrar um novo time no sistema

Pré-condições: Usuário(Administrador) ter acesso a tela de cadastro

Passos:

Entrada

1. Usuário acessa tela de cadastro de time

2. Usuário insere o campo Nome: "Corinthians"

3. Usuário insere o campo Empresa: "Corinthians S.A."

4. Usuário insere o campo Responsável: "Mario Gobi"

5. Usuário clica em salvar

 

Saída

1. Sistema valida os campos nome, empresa e responsável com sucesso

2. Sistema salva no banco

3. Sistema exibe mensagem "O time foi salvo com sucesso"

Exemplo de Caso de Teste utilizando o conceito tradicional e que poderia ser inserido no Testlink.

 


Teste de campos obrigatórios do cadastro de filmes

Dado que:

- Os campos obrigatórios são: Nome do Filme, Ator, Atriz, Diretor

Quando:

- Eu não preencho o campo Atriz

Então:

- O sistema não salva o filme

- O sistema exibe mensagem que não foi salvo o filme

- O sistema lista campos a serem preenchidos

Exemplo de Caso de Teste utilizando o conceito  Ágil. Estes podem ser controlados por postits

 


CT011 - Validar inserção de caracteres especiais no campo Nome

Objetivo: Testar se o sistema permite inserção apenas de caracteresespeciais

Pré-condições: Usuário(Administrador) ter acesso a tela de cadastro

Passos:

Entrada

Usuário preenche os campos com valores válidos

Usuário preenche o campo Nome apenas com caracteres especiais

Saída

Sistema não permite inserção de apenas caracteres especiais no campo

Exemplo de Caso de Teste utilizando um conceitotradicional, mas também sendo um 'pouco' ágil.


O objetivo do Teste de Software

Posted by JJ on October 10, 2013 at 9:50 AM Comments comments (0)

Há alguns dias atrás entrei em uma discussão sem fim, em que consegui explicar com um fato recente que foi noticiado e virou meme do face.




O que é o Teste de Software?

 

O Cliente pede um liquido refrescante, com sabor cola e viciante. (implicito coca)
O analista descreve uma coca.
O teste 'valida' se o analista escreveu uma coca e não uma pepsi.
O programador codifica.
O teste é 'valida' se o programador fez uma coca e não uma pepsi.
O teste 'relata' que foi feita a coca.
O Cliente recebe e agradece pela coca.

Fim.

 


O que é o Teste de Software?

 

O Cliente pede um liquido refrescante, com sabor cola e viciante. (implicito coca)
O analista descreve.
O teste valida se o analista escreveu uma coca e não uma pepsi.
O programador codifica uma pepsi.
O teste é valida se o programador fez uma coca e não uma pepsi.
O teste relata que foi feita a pepsi e não a coca.
O programador codifica uma coca com rato.
O teste é valida se o programador fez uma coca.
O teste relata um rato na coca.
O programador codifica uma coca.
O teste é valida se o programador fez uma coca.
O teste relata que foi feita a coca.
O Cliente recebe e agradece pela coca.

Fim.

 

moral da história: Se no teste é encontrado um rato na coca, isso é uma consequência, e não o objetivo. O objetivo era validar se foi feita a coca.

 

 


Ou seja, na minha humilde visão, não se pode Testar um Software(entenda-se testar um software, todo o processo, e não sómente EXECUTAR UM TESTE) com o objetivo de encontrar falhas.

Nós da área de Qualidade ou Testes de Software temos de deixar explicito que o objetivo de encontrar falhas é na hora da execução de um teste, ou exploração de um sistema.


O Teste de Software, é um processo mais de negócio do que propriamente técnico. Pois trabalha diretamente qua a Qualidade do Produto. E um produto com qualidade é um produto com valor de negócio.


Outro ponto, é aquele discutido na comunidade de Testadores a algum tempo atrás, o "testador vai acabar". Pode até não existir mais este cargo, porém aqueles que trabalham ou trabalaram com este processo, podem ir para ambas as areas, Negócios ou Técnica. Mas a Area de Qualidade e Testes de Software nunca vai acabar. Mesmo aparecendo "Programadores Perfeitos" o Teste deve continuar.

Tecnicas de Levantamento de Casos de Testes

Posted by JJ on April 3, 2013 at 2:45 PM Comments comments (5)

"Este artigo é direcionado à pessoas que conheçam os processos de testes bem como;

- técnicas: Estresse, Execução, Contingência, Operação, Conformidade, Segurança.

- fatores de qualidade: Correção, Confiabilidade, Eficiência, Integridade, Usabilidade, Manutenibilidade, Testabilidade, Testabilidade, Flexibilidade, Reusabilidade, Interoperabilidade e Portabilidade."



Este artigo te ajudará passar ileso dos feedbacks negativos em finais de projetos.

 

Há quem diga e defenda constantemente que os objetivos dos Testes são encontrar o maior número de falhas possíveis no sistema. Eu defendo o conceito de que o Objetivo do Teste de Software é garantir que ele funciona conforme requisitado. Encontrar falhas são meras consequências.

 

 


Encontrando Bugs

 


Seja amigo do bug

Para isto, vem outro conceito que defendo cegamente, o processo de Teste de Software deve começar la no inicio, com a documentação e o levantamento dos requisitos. Não simplesmente entregar um conjunto e emaranhados de telas e códigos e falar pro testador("Testa ai"). Não, não aceitem isto.

 

Para se testar um sistema, precisa conhecer a regra do negócio, saber o que o sistema fará. Conhecer quem utilizará o sistema, o que este faz diariamente, como ele utilizará e para qual fim.


Assim você poderá realmente iniciar a garantia de que o software foi construído de forma eficaz. Assim você terá testes limpos e eficiente. Do contrario, temos meros chutes e caça aos bugs.

 

Então para testarmos um sistema de forma eficiente, e não apenas chutar o que o usuário talvez fará. Vamos criar idéias de Testes, Criar Casos de Testes, este processo se chama:

- Levantamento de Casos(Idéias) de Testes

 

O processo de Levantamento de Idéias e Casos de Testes auxiliará o próximo processo dentro dos Testes de Software que é a Elaboração dos casos de Testes, ou simplismente já testar o sistema com as idéias levantadas.

 

Este levantamento pode ser feito simples em qualquer bloco de notas por exemplo, para mais tarde a elaboração em um documento próprio ou testlink.

 

 

O Caso de Teste deve ter as características a seguir para que possa ser usado e atender às expectativas de validação da qualidade:

- efetivo: testar o que se planejou testar;
- econômico: sem passos desnecessários;
- reutilizável: que possa ser repetido;
- rastreável: que possa identificar o requisito a ser testado;
- auto-explicativo: que possa ser testado por qualquer testador.

Livro: Base de Conhecimento de Testes de Software

 

A decisão de determinar o nível e estrutura das condições de teste pode ser baseada em características funcionais e não-funcionais dos itens de teste usando o seguinte:

1. Granulosidade da base de teste: Exemplo: requisitos de alto nível podem gerar inicialmente condições de alto nível. Exemplo: prove que a tela X funciona, a partir da qual é possível derivar condições de teste de baixo nível. Exemplo: prove que a tela X rejeita um número que é um dígito menor que o comprimento correto.

2. Riscos de produtos correspondidos: Exemplo: para uma característica de alto nível de risco, condições de teste detalhadas devem ser um objetivo definido.

3. Requisitos para relatório gerencial e rastreabilidade de informação

4. Quando a decisão for tomada para trabalhar com condições de teste somente e não desenvolver caso de teste. Por exemplo, usando condições de teste para foco de teste sem script.

Livro: Syllabus



A modelagem de caso de teste inclui a identificação de:

· pré-condições tais como o projeto ou os requisitos do ambiente de teste localizados e os planos para sua entrega
· os requisitos de dados de teste
· os resultados esperados e as pós-condições

Livro: Syllabus


 

Vejamos mais algumas Técnicas de Levantamento de Casos de Testes

- Levante casos em que o seu teste irá validar os valores limites dos campos(tente criar estes casos de testes para os desenvolvedores realizar nos Testes de Unidade)

- Levante casos de testes para o fluxo principal

- Levante casos de testes para fluxos alternativos(campos obrigatórios vazios, salvar um cadastro sem nenhum campo preenchido, na edição do cadastro apagar os dados e salvar, etc)

- Levante casos em que o usuário poderia exigir algo do sistema em que o sistema não esteja preparado para responder a ação

- Levante casos de testes de usabilidade, descrevendo como o layout deveria ficar ou como deve ser a ordenação do campo para utilização apenas pelo teclado.

- Levante casos de testes exploratórios iniciais, estes irão indicar se a suite de teste(bloco de testes de uma tela, caso de uso ou módulo), já pode ser iniciada.

 

Vejam alguns Casos de Testes que poderíamos levantar de exemplo.

 

ST001 - Suite Cadastrar Time

CT001 - Validar exploração da tela através de cliques em todos os campos e botões
CT002 - Validar Cadastrar time
CT003 - Validar Cadastrar time sem nenhum campo preenchido
CT004 - Validar campo Nome
CT005 - Validar campo Empresa
CT006 - Validar campo responsável
CT007 - Validar cadastro do time no banco

 

ST002 - Suite Cadastrar Filme

CT008 - Validar Cadastrar filme
CT009 - Validar campos obrigatórios do cadastro de filmes
CT010 - Validar tipo campo Diretor
CT011 - Validar inserção de caracteres especiais no campo Nome
CT012 - Validar inserção de atores principais

 

Então pessoal, espero colaborar a todos com estas técnicas para levantamento dos testes.

Qualquer dúvida estou à disposição.

Pequenos Projetos Grandes Desafios - Parte Final

Posted by JJ on March 18, 2013 at 4:10 PM Comments comments (0)

Passamos por semanas terriveis, vários e vários testes, nessa vida de testador "tá fácil pra ninguém".

Bom, depois de muito cofabular, passamos por 3 partes de Pequenos Projetos & Grandes Desafios.

E todo mundo está deste jeito lendo esta matéria.




Vamos desenhar para que fique mais fácil.


Nos capitulos anteriores vimos basicamente o que descrevi nestas próximas imagens, e o que seria o caminho feliz de nosso projeto?




Dentro deste macro processo nós temos muitos processos, falamos como seria um projeto de testes em metodologia Tradicional e Ágil, exemplificando em um modo 'Híbrido':


Atividades no Projeto de Testes antes de definir a metodologia


Atividades dentro do Projeto de Testes em uma metodologia Ágil


Atividades dentro do Projeto de Testes utilizando uma metodologia Tradicional


Atividades dentro do Projeto de Testes utilizando uma mescla das duas metodologias



Nós utilizamos um modo meio a meio, para trabalharmos em um pequeno projeto com poucas horas de testes. Porém, conseguimos finalmente entender o sistema quase que 100%, assim defino que a Qualidade do Software está diretamente ligada ao entendimento do que ele tem de fazer.


Ou seja, se você não sabe o que o software tem de fazer mesmo no final do projeto, o software não tem qualidade.


Vejamos o que eu digo de qualidade percebida no nosso projeto e quanto nós tiramos de dúvidas no decorrer dele:



Iniciamos um projeto sem saber nada do sistema, sem nenhuma documentação e ao decorrer do projeto fomos sanando as dúvidas e assim melhorando a qualidade do projeto, até que ao final na parte mais critica (Execução), tinhamos poucas dúvidas de o que o sistema deveria fazer e assim diminuindo os riscos do projeto, diminuindo assim a facilidade de encontrar erros 'simples' extraídos no momento em que passamos testes ao desenvolvedor, até os erros mais 'complexos' extraídos no levantamento e especificação, onde definimos os testes de funcionalidade, onde que poderiamos deixar algo despercebido que faria futuramente em produção que o sistema parasse de funcionar, assim causando um prejuízo enorme.


Bom chegamos ao fim da série, Pequenos Projetos e Grandes Desafios, com um gostinho de quero mais.

Em futuros posts, postarei formas de criação de um Plano de Testes, o que realmente ele é e sua importância. Falarei em um post sobre as ferramentas do dia a dia e novas ferramentas de testes. Postarei sobre novidades neste mundo, cursos, projetos, entre outras atividades.

Já deixo um arquivo com os processos de uma Fabrica de Testes em que criei para a fabrica de Software que trabalho. Quem quiser baixar é só entrar em Download ai em cima.


Quem gostou faz barulho, quem não gostou bate palma! Abraços.

Pequenos Projetos Grandes Desafios - Parte 3

Posted by JJ on February 21, 2013 at 7:55 AM Comments comments (0)

Bom estamos chegando ao final de nossa saga para planejar os testes do sistema. Vamos recordar o que já fizemos?

 

- Reunião de Repasse com o Gerente Trakinas
Nessa reunião descobrimos regras do projeto e ainda descobrimos algumas possiveis falhas do sistema
- Pensamos se utilizariamos metodos ágeis ou tradicionais e então definimos que utilizariamos um hibrido.
- Verificamos que tinhamos pouco tempo para 'os testes' do sistema. Então tinhamos que definir quais seriam as linhas criticas do sistema.
- Verificamos quais são os processos dos métodos tradicionais e dos ágeis.
- Anotamos os provaveis erros que mais poderiam acontecer na fase de testes e repassamos ao desenvolvedor.

 

Neste capitulo, vamos levantar os casos de testes e Elaborar os Casos de Testes(tecnicas tradicionais).

Porém vamos exemplificar um Caso de Teste mais simples, apenas com idéias de testes, para sermos mais rápidos, não criando muitos 'pesos' aos testes.

 

 

Técnicas de Levantamento de Casos de Testes

 

Vamos exemplificar técnicas de levantamento para telas de cadastros

- Levante casos em que o seu teste irá validar os valores limites dos campos(tente criar estes casos de testes para os desenvolvedores realizar nos Testes de Unidade)

- Levante casos de testes para o fluxo principal

- Levante casos de testes para fluxos alternativos(campos obrigatórios vazios, salvar um cadastro sem nenhum campo preenchido, na edição do cadastro apagar os dados e salvar, etc)

- Levante casos em que o usuário poderia exigir algo do sistema em que o sistema não esteja preparado para responder a ação

- Levante casos de testes de usabilidade, descrevendo como o layout deveria ficar ou como deve ser a ordenação do campo para utilização apenas pelo teclado.

- Levante casos de testes exploratórios iniciais, estes irão indicar se a suite de teste(bloco de testes de uma tela, caso de uso ou módulo), já pode ser iniciada.

 

E por ai vai, existem milhares de técnicas para se levantar um Caso de Teste.

Escreva este levantamento em um bloco de notas por exemplo, para mais tarde a elaboração.

 

Vamos exemplificar alguns Casos de Testes que poderiamos levantar com os 2 sistemas de exemplo.

 

ST001 - Suite Cadastrar Time
CT001 - Validar exploração da tela atravéz de cliques em todos os campos e botões
CT002 - Validar Cadastrar time
CT003 - Validar Cadastrar time sem nenhum campo preenchido
CT004 - Validar campo Nome
CT005 - Validar campo Empresa
CT006 - Validar campo responsável
CT007 - Validar cadastro do time no banco

 

ST002 - Suite Cadastrar Filme
CT008 - Validar Cadastrar filme
CT009 - Validar campos obrigatórios do cadastro de filmes
CT010 - Validar tipo campo Diretor
CT011 - Validar inserção de caracteres especiais no campo Nome
CT012 - Validar inserção de atores principais

 

Estes foram alguns exemplos do levantamento de Casos de Testes nos dois sistemas descritos anteriormente.

 

 

 

Técnicas de Elaboração de Casos de Testes

 

Vamos exemplificar tecnicas de elaboração para telas de cadastros

- Procure descrever um caminho curto e objetivo

- Procure descrever da forma mais sucinta possivel o Caso de Teste

- Procure elaborar o caso de teste com o menor número de passos possíveis

- Se um Caso de Teste ficar maior do que o Caso de Uso, procure dividir em mais Casos de Testes

- Em um Caso de Teste ágil, tente colocar as condições para a ação, a ação a executar e se possivel os resultados esperados(é desejavel, pois na maioria das vezes não conhecemos o resultado)

 

Entre outras, estas técnicas podem ajudar a criar um Caso de Teste até mesmo bem dinamico com o testador que irá executar o teste.




Agora vamos ao exemplo de Um caso de Teste Elaborado de forma tradicional e um Caso de Teste Elaborado de forma Ágil, assim como um elaborado de forma Hibrida.

 

CT002 - Validar Cadastrar Time

Objetivo: Cadastrar um novo time no sistema

Pré-condições: Usuário(Administrador) ter acesso a tela de cadastro

Passos:

Entrada

1. Usuário acessa tela de cadastro de time

2. Usuário insere o campo Nome: "Corinthians"

3. Usuário insere o campo Empresa: "Corinthians S.A."

4. Usuário insere o campo Responsável: "Mario Gobi"

5. Usuário clica em salvar

 

Saída

1. Sistema valida os campos nome, empresa e responsável com sucesso

2. Sistema salva no banco

3. Sistema exibe mensagem "O time foi salvo com sucesso"

Exemplo de Caso de Teste utilizando o conceito tradicional e que poderia ser inserido no Testlink.

 

Teste de campos obrigatórios do cadastro de filmes

Dado que:

- Os campos obrigatórios são: Nome do Filme, Ator, Atriz, Diretor

Quando:

- Eu não preencho o campo Atriz

Então:

- O sistema não salva o filme

- O sistema exibe mensagem que não foi salvo o filme

- O sistema lista campos a serem preenchidos

Exemplo de Caso de Teste utilizando o conceito Ágil. Estes podem ser controlados por postits

 

 

CT011 - Validar inserção de caracteres especiais no campo Nome

Objetivo: Testar se o sistema permite inserção apenas de caracteres especiais

Pré-condições: Usuário(Administrador) ter acesso a tela de cadastro

Passos:

Entrada

Usuário preenche os campos com valores válidos

Usuário preenche o campo Nome apenas com caracteres especiais

Saída

Sistema não permite inserção de apenas caracteres especiais no campo

Exemplo de Caso de Teste utilizando um conceito tradicional, mas também sendo um 'pouco' ágil.

 

Então é isso pessoal, neste capitulo fizemos o levantamento e a elaboração dos Casos de Testes no próximo e último capitulo teremos os testes e o resultado dos nossos testes de um Pequeno Projeto e resultados significantes.

 

Dicas do dia: Técnicas de levantamento de casos de testes e Técnicas de elaboração de casos de testes.

 

Abraços

import jj.utils

Posted by JJ on January 21, 2013 at 12:30 AM Comments comments (1)

Bom pessoal, começar a falar sobre testes, vou começar mesmo no próximo post.
Porém, não posso esquecer o que já postei no meu blog pessoal.


Segue os links quem quiser dar uma lida:

Teoria de testes em jogos

Norma ISO/IEC 9126-1 Qualidade de Software

Tipos de Testes de Software pt1

UML - Modelagem de software por meio da UML 2


se quiserem deixar um comentário, podem comentar aqui neste post.