Blog
O que vocês fazem?
|
|
comments (0)
|
- Funcionalidade
- Usabilidade
- Performance
- Manutenibilidade
- Portabilidade
- Operacionabilidade
- Eficiência
- Segurança
- Conectividade
- Continuidade
"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. |
Kamilla Queiróz |
|
Robson Agapito |
"
Sempre devemos olhar para o risco, e levar em consideração onde se perderá dinheiro. |
|
"A garantia de que as expectativas do dono do produto sejam atendidas. |
Ramsés Saccol |
- Funcionalidade
- Usabilidade
|
|
|
|
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:
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 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:
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 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:
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. |
|
|
|
|
|
Reporte de Bugs
|
|
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!
Ciência do Teste de Software
|
|
comments (0)
|
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
|
|
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
|
|
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
|
|
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
|
|
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
- Caixa de texto Input
- selecionar cair para baixo
- 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 | ||
| Command | Target | Value |
| open | http://www.wikipedia.org/ | |
| type | id=searchInput | ID Example |
Ou
| New Test | ||
| Command | Target | Value |
| open | http://www.wikipedia.org/ | |
| type | name=search | Name 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 | ||
| Command | Target | Value |
| open | http://www.wikipedia.org/ | |
| type | xpath://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 | ||
| Command | Target | Value |
| open | http://www.wikipedia.org/ | |
| type | xpath://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 | ||
| Command | Target | Value |
| open | http://www.wikipedia.org/ | |
| type | xpath://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 | ||
| Command | Target | Value |
| open | http://www.wikipedia.org/ | |
| type | xpath://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 | ||
| Command | Target | Value |
| open | http://www.wikipedia.org/ | |
| select | xpath://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
|
|
comments (5)
|
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
|
|
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
|
|
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.
|
|
 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
|
|
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
|
|
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
|
|
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:
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.