Click here to edit title

Click here to edit subtitle

Blog

Está na história

Posted by JJ on December 14, 2015 at 5:00 PM Comments comments (0)

Acompanhando a evolução dos Testes, o site Aprendendo a Testar, traz a vocês um resumo sobre a história dos Testes de Software. 

Aos poucos a migração do Aprendendo Testar hospedado no Webs.com, vai para o domínio próprio da 4ALL Tests.




Migração:

Sobre - concluído

Guia - concluído

Exercícios - em andamento

Ciência - em andamento


E tudo o que mudou para o novo site, está sendo produzido. O intuito do aprendendo testar, é aquele: Entrou um funcionário novo para a equipe de Testes, você não tinha um local com informações suficientes e forma de passar o conhecimento. O Aprendendo Testar veio para isso. E muito mais, você treinador de testes, blogueiro ou empresa que gostaria de um local para servir de base, o Aprendendo Testar está ai.


Com metas de melhoria as criações dos módulos de conhecimento estão a todo vapor, e sempre haverão complementos, bem como melhorias e correções de erros:


Criação:

Comunidades: Pronto 

História: Pronto

Ferramentas:  em andamento

Automação: em breve novidades

Gestão: em andamento.



História: 

 

Reza a lenda...

 

Em meados de 1979, nascia os Testes de Software, Glenford Myers publicava seu primeiro livro: A arte de Testar Software ou A Arte dos Testes de Software.... continue lendo.


Entenda que: a área de Testes não é a Casa da Mãe Joana

Posted by JJ on February 5, 2015 at 11:55 PM Comments comments (0)

Muito se discute sobre a Área de Testes de Software(ser nova ou não, reconhecida ou não). Muitos mitos e discussões existem.

Mas todos tem que ter em mente que para todas as áreas suas tarefas existem, e cada um tem de desempenhá-la da forma mais correta, coerente e o principal: Mais Profissional possível. E como diferenciar o amadorismo, o achismo, o tentativismo do Profissional?

Simples, saber o que está fazendo. Se você sabe do que está fazendo e aliado ao conhecimento e técnicas sabe mixar e alinhar isso tudo, você pode fazer algo mais Profissional(logo se baseando em técnicas, metodos e fatos).

 

Entenda que:

 

Na Área de Testes de Software


- Existem papéis definidos (Testador, Analista de Testes, Automatizador de Testes, QA, Arquiteto de Testes, Engenheiro de Testes, Líder de Testes, Especialista em Testes, Coordenador de Testes, Gerente de Testes) e todos eles são TESTADORES.

- O testador não programa

- O testador TAMBÉM programa

- O testador não é apagador de incêndios (Quem apaga incêndios é Bombeiro).

- O testador não é quebra galho (ele tem suas tarefas e essas tem de serem finalizadas)

- O testador mostra resultado, o qual é utilizado pela qualidade

- Existem processos de testes

- Existem metodologias de testes

- Existem técnicas de testes (acho que pode dar erro aqui!) Não! Existe uma técnica para prever isso, existem técnicas que ajudam a trabalhar sem ser uma abordagem pela experiência.

- O testador estuda o tempo inteiro

- O testador TAMBÉM acha defeitos, mas não só ele

- Vim da área de suporte e preciso aprender o que é um Caso de Teste

- Vim da área de programação e tenho que aprender o que é um fluxo alternativo

- Testadores participam de eventos

- Testadores estudam fora do trabalho

- Testadores ensinam a programar

- Testadores ensinam a criar processos

- Testadores usam ferramentas para testar

- Testador não põe o dedo na boca e põe de volta no ar para saber se está ventando. (Ele olha para as árvores, quando não tem uma ele cria algo para validar isso)

- Testador Valida um Cenário de Teste

- Testador não Verifica um Teste ele Valida!

- Testador Verifica processo

- Verifica documentação.

- Testador tem Copa do Mundo da área


Se você gostou desse post, compartilhe para seus colegas e "chefes".

Se você gostou desse post, também vai gostar desses abaixo:

 


Por

João Júnior

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

O Mundo dos Testes de Software

Posted by JJ on December 11, 2014 at 9:15 AM Comments comments (2)

O mundo dos testes vai muito além do simples "Testa aí".


Quando escuto um "Testa aí", tenho aquela sensação que é descrita por aqueles que estão(ou estiveram) à beira da morte:
"Ver toda a sua vida diante dos seus olhos".


Ou seja: Quando escuto um "Testa aí" vejo todo o mundo de Testes passar diante dos olhos e descubro que não é tão simples quanto a frase de 2 palavras a diz.




Por isso, há algum tempo venho trabalhando no projeto do "Aprendendo Testar" e moldando um "livro"(o qual no grupo de testes já foi comentado até para fazermos um Wiki- Oliveira, o Gabriel; entre outras idéias)[lançamento 2015].

Neste livro, venho escrevendo várias coisas da BASE do que seria para mim(e agora para o grupo, pois abri ao grupo para escreverem e me ajudarem), uma Base de Testes de Software. Aquele caminho que seria mesmo utilizado e visto em qualquer lugar que você vá trabalhar.

Desde aquela euquipe em uma startup, até aquela euquipe em uma empresa já sólida porém que não tem um, como posso colocar, um Fluxo Conceito de Testes.  Desde aquela empresa que tenha uma equipe com 2, 3, 5 testers, até aquela que tem 100 testers.

 

O certo é que toda empresa tem seu próprio processo de desenvolvimento de software(utilizando como base metodologias, ou até criando a sua), e o software precisa ter qualidade, para alcançar a qualidade, existem várias coisas a serem feitas e ferramentas que podem auxiliar, os Testes, seriam na minha visão, uma "ferramenta" para se obter mais qualidade em um software. 

Para explicar este livro, desenvolvi a palestra que mostra como o mundo de testes de software em sua base, não é somente um Testa aí, ela foi apresentada no Tech Day(Evento da Softplan, para seus colaboradores), que contou com mais outras 3 palestras e cerca de 120 participantes em sua maioria de Testadores. 



Slides da Palestra abaixo:


Abaixo segue o Mind Map deste mundo, este mind map, é a base do Livro, e está aberto à você que queira participar da construção deste livro, pegar um dos temas e suas ramificações e escrever seus conceitos. 


O livro será Gratuito E-Book, e talvez quem o quiser em meios fisicos, apenas custear sua impressão no formato correto.


O livro O Mundo dos Testes será volumado de 2 em 2 anos, com o primeiro volume sendo lançado em 2015.


Se interessou? Entre em contato.

10 testadores que não precisam saber programar

Posted by JJ on October 17, 2014 at 6:40 AM Comments comments (1)

 

Testador


 

Essa eu nunca imaginei.

É chamado testador aquele que faz o seu testamento; testamenteiro o encarregado pelo testamento ; herdeiros os contemplados com o patrimônio sem individualização e legatários os contemplados por bens individualizados.

Veja



Testador de Amostras


Esse é um testador "vip", é o Beta tester dos mais diversos produtos, desde chicletes, balas, até computadores e tablets. Se liga no Clube dos Testadores.

Veja


 

Testador de Medicamentos


Sim, não, um rato, é... não, não é um rato. Tem voluntários cadastrados para serem utilizados nos testes de medicamentos. Nem é melhor fazer piada, algumas doenças são serissimas e pessoas podem estar precisando tanto que se propõe a serem utilizadas nos testes.

Veja  Também

 


Testador de Airbag pra moto

 

Dublê profissional:

Veja

 

 

Testador de Maquiagem

 

Avaliar se causa algum tipo de alergia não é a única atividade dessa profissão, elas também veem em tipos de pele e fazem relatórios extensos.

 


Testador de Toboágua

 

Saiu numa agência de empregos uma notícia sobre um clube que estava contratando

Veja

 

 

Testador de Produtos de Sex Shop

 

Esse foi uma vaga que saiu na mídia e foi alvoroço na época.

Veja

 

 

Testador de Veículos

 

Ele faz testes que verificam a dirigibilidade, aceleraçao, frenagem do carro, claro que em uma pista fechada da montadora com toda a seguranca, só por curiosidade ele não testa os air-bags esta função fica por conta de um robo que tem a capacidade de ver quanto de dano a pessoa vai tomar.

 

 

Testador de Jogos de Video Games (ta no nosso mundo)

 

Há algum tempo atrás, saiu uma vaga inusitada. Testador que precisava jogar video game e ter português fluente (*-* sonhoooo). Sim, para morar em londres, porém receber cerca de miseros 3k(queh mais o quê maluco?).

Veja

 


Testador de Cerveja(essa todo mundo quer)

Veja noticia sobre uma vaga:

O profissional terá outras tarefas além de beber cerveja. O escolhido irá visitar bares, conhecer mais sobre a história da Guinness e irá relatar a (árdua) experiência. Também irá visitar a fábrica da bebida na Irlanda. Para participar, o candidato deve ter mais de 19 anos e mínimo de 1 ano de experiência em beber cerveja.

Empresas possíveis: Guinness, Ambev.

 

 


Sim, todos são profissionais, recebem para isso.

Agora se tu quer uma vaga de Testador na Área de Testes de Software, além de conhecer muito bem o negócio, que tal começar a aprender sobre como é construído?

Segue um site com zilhões de vagas


Pesquisa sobre Ferramentas e Gestão de Testes

Posted by JJ on May 30, 2014 at 12:10 AM Comments comments (0)

 

No final de março, realizei uma pesquisa com meus colegas da área de Testes de Software, para saber quem realiza um controle do Cronograma dos Testes.

Pra isso, teríamos que saber quais ferramentas de gestão os profissionais mais utilizavam e em relação aos cronogramas quais eram utilizadas para o controle.

Também, perguntei qual o tipo de equipe, qual o papel e qual a metodologia utilizada dentro da área.

 

Vejamos os resultados da pesquisa

 

Link - pt.slideshare.net/jjjuniorjr/os-testes-no-desenvolvimento-de-software


Fique à vontade para comentar.

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

#Exercicio3 Testando Entrada e Saída

Posted by JJ on April 1, 2014 at 12:20 AM Comments comments (0)

No nosso 3° exercício, vamos estudar algo que está no dia a dia do Testador, além, do trabalho, em toda sua vida. A premissa: "Você tem que dar, para receber"



 



Basicamente, você sempre passa alguma coisa e te devolvem alguma coisa, certo? Vejamos na nossa vida.

 

Para você comprar aquele IPhone tão desejado, você necessita ter dinheiro, certo?

Tirando a parte de como você vai obter esse dinheiro, para adquirir este produto tão sonhado, você necessita passar por um processo. Vamos entender o porquê:


 

 

" Você realiza uma pesquisa de preços, para ver se consegue pagar(ou você tem muita grana e não ta nem ai, assim, vai no primeiro lugar que achar). Chega na loja, pede ao vendedor que te mostre o produto, escolhe a cor que deseja, solicita aquele produto naquela cor, faz a requisição de compra, paga e assina o termo de compra(canhoto, nota fiscal etc.) e sai da loja feliz da vida com seu novo Iphone."



Nessa história temos um processo para realizar a compra contendo nesteverdadeiros critérios de entrada e saída.

 

Mas antes de analisarmos estes critérios vamos aos estudos

 


O Syllabus que é: "Este syllabus forma a base deconhecimento para a Qualificação Internacional de Teste de Software no nível Foundation." Palavras do Próprio.

 

Explica os critérios de entrada e saída:

 


5.2.3 Critério de Entrada 

Os critérios de entrada definem quando começar um teste, no início de um nível de teste ou quando um conjunto de testes está pronto para execução.


Os critérios de entrada podem ser constituídos de:

  • Disponibilidade do ambiente de teste.
  • Preparação da ferramenta de no ambiente de teste.
  • Disponibilidade de código a ser testado.
  • Disponibilidade dos dados de teste.

 

5.2.4 Critério de Saída 

Os critérios de saída definem quando parar de testar, no final de um nível de teste ou quando um conjunto de testes realizados atingiu um objetivo específico.


Os critérios de encerramento podem ser constituídos de:

  • Métricas como a cobertura de código, riscos ou funcionalidades.
  • Estimativa da densidade de defeitos ou segurança nas medições.
  • Custos.
  • Riscos residuais, como defeitos não solucionados ou falta de cobertura de teste em algumas áreas.
  • Cronograma, baseado na data de entrega do produto.



Nossa pesquisa pela Web mostrou uma apresentação de Eduardo Figueiredo que traz um modelo de entrada e saída.

http://homepages.dcc.ufmg.br/~figueiredo/disciplinas/aulas/testes-software_v01.pdf.

 






Então:

 

O que podemos entender como Entrada e Saída?

 

Simplesmente podemos utilizá-las em todo o ciclo de Testes, de Qualidade de Software e sim, de Desenvolvimento de Software. Deixando um pouco de lado o conceito em Processos de Entrada e Saída(Documento de requisitos -> Sistema). Voltando aos testes, podemos dividir em duas macro partes. Nos testes de Caixa Branca e nos testes de Caixa Preta.




Nos testes de Caixa Branca, entende-se que podemos inserir o mais limpoe mais baixo nível dos testes de Entrada e Saída:

 

Dado:

 

         Temos um sistema de notafiscal e retirada de compras, que buscam os códigos dos produtos informados,trazendo seus valores e somam os valores para mostrar o resultado final dacompra.

 

Dentro dessa expectativa, temos alguns testes, porém o mostrado aquiseria a somatória dos valores do produto para apresentar o valor da compra.

 

Mais ou menos seria isso:

 

         int produto1 = 59,90;
         int produto2 = 22,00;
         int resultado = 81,90;

         se( produto1 + produto2 =resultado){
                   print("Ocalculo está correto");

         }senão{
                   print("Aconteceualgo errado com o cálculo       );

         }

 

Onde:

 

 public class Calculadora {  
      public int somar(int x , int y){  
           return x+y;  
      }  
      public int subtrair(int x,int y){  
           return x-y;  
      }  
      public int multiplicar(int x, int y){  
           return x*y;  
      }  
      public int dividir (int x, int y){  
           return x/y;  
      }  
 }  


Então teríamos:

 

 @Test  
     public void somar() {  
         assertEquals("Passou com sucesso", 4, calculadora.somar(2, 2));  
     }  
     @Test  
     public void subtrair() {  
        assertEquals("Passou com sucesso", 0, calculadora.subtrair(2, 2));  
     }  
     @Test  
     public void multiplicar() {  
        assertEquals("Passou com sucesso", 4, calculadora.multiplicar(2, 2));  
     }  
     @Test  
     public void dividir() {  
        assertEquals("Passou com sucesso", 1 , calculadora.dividir(2, 2));  
     }  


Assim teríamos um teste de Entrada e Saída nos testes de Caixa Branca, informando uma entrada especifica dentro do código, e requisitando a saída correta.

 

É meio lógico um teste desse dar certo. Porém no nosso dia a dia veríamos que se o código do nosso programador estivesse assim:

 

      public int subtrair(int x,int y){  
           return x+y;  


Nosso teste daria erro, pois nossa Entrada seria 2+2, e a saída seria 0:

 

     @Test  
     public void subtrair() {  
        assertEquals("Passou com sucesso", 0, calculadora.subtrair(2, 2));  
     }  


 

Nos testes de Caixa Preta, não vemos o código, somente a interface jápronta. Assim, utilizaremos o sistema como se fossemos o usuário final. Informandodados reais e esperando os resultados corretos a partir dos dados informados.Testando o seu real funcionamento.

 

O Testlink trabalha com entradas e saídas, as entradas são ações à serealizar para se obter as saídas esperadas.

 

No nosso Software Gestor de Testes Testlink, nós utilizamos osconceitos de Entrada e Saída para executar os Casos(Cenários) de Testes.

 


Ações do passo seria o que nós entraríamos no sistema, Resultados Esperados seria o que o sistema responderia.

 

Dado:

 

         Temos um sistema de nota fiscal e retirada de compras, que buscam os códigos dos produtos informados, trazendo seus valores e somam os valores para mostrar o resultado final da compra.

 

Nessa expectativa, temos um teste:

Onde:

        Entrada:

         Informar um produto x; Este produto x, tem o valor x;

         Informar um produto y; Este produto y, tem o valor y;

 

        Saída:

         O Sistema retorna a somados produtos x e y;

         O resultado da soma deve ser correto;

 

Não entre em pânico caso o resultado do seu teste for como esse:

 


 

 


Voltando ao exemplo citado no início do artigo, teríamos além de váriasformas o seguinte Cenário de Teste como exemplo:

 

Pré requisitos:

Realizar uma pesquisa de preços;

Ter um resultado dessa pesquisa de preços;

Ir à loja de sua preferência;

Loja ter o produto em estoque.

 

Passo 1:

Entrada:

Requisitar ao vendedor o Produto

 

Saída:

Vendedor mostra o produto

 

Passo 2:

Entrada:

Escolher a cor do produto

 

Saída:

Vendedor mostra as cores disponíveis

 

Passo 3:

Entrada:

Escolhe o produto

Solicita a ordem de compra

 

Saída:

Vendedor tira a ordem de compra

Vendedor destina a ordem para o caixa

 

Passo 4:

Entrada:

Realiza o pagamento

 

Saída:

Caixa entrega nota de compra

 

Passo 5:

Entrada:

Assina nota fiscal

Retira produto

 

Saída:

Entrega produto com sucesso.

 



Desafio: Teste de Entrada e Saída, cadastre o usário e confira o cadastro no Relatório, faça isso para vários clientes.

Informe o nome, confira o nome.

Informe o animal, confira o animal e o dono correto.

Informe datas de nascimento diferentes. Entre outros.

 

 

 

 

Leitura do dia:

 

- Caixa Branca

- Caixa Preta

- Testlink

- Cenários de Testes

 

 

Post descritivo ao teste do exercício 3 - Testando Cadastro Veterinário Desktop

 



Como baixar os repositorios do GitHub

Posted by JJ on March 7, 2014 at 8:35 AM Comments comments (0)

Estou migrando aos poucos meus arquivos o GitHub.

Então, para baixar arquivos dos downloads, exercicios basta seguir os seguintes passos:


Para baixar os arquivos dos exercícios, basta acessar aminha página do Github: https://github.com/testejoaojunior


 

Na página principal acessar à aba Repositórios:


 

Digitar o nome do exercício no campo de busca;

E clicar no repositório desejado;


 

 

Serão apresentados todos os arquivos do repositório, clique em download zip para baixar os arquivos.

 

 


Pronto agora é só estudar e aprendender mais e mais.

APP Software Quality News

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

Criei um aplicativo para celular, para que eu passasse para as pessoas lerem os meus ultimos artigos, isso me motivou à criar um outro aplicativo, esse sim acredito que com utilidade para toda a galera.


O APP Software Quality News, serve para quem quer se manter atualizado com os posts de blogs ou ver artigos antigos dos blogs mais facilmente. E o melhor, de qualquer lugar que não esteja no pc ou notebook.


Blogs do app:


4 All Tests: Este blog.

Guts-RS: Blog da comunidade do Rio Grande Do Sul

The Bug Bang Theory: Blog do Camilo Ribeiro

Qualidade de Software: Blog do Eduardo Freitas(Test Day)

Testing Thoughts: Blog do Shumel Gershon

Sem Bugs: Blog do Elias Nogueira

ALM e Tests: Blog do Alan Correa Morais

Agile Testes: Comunidade de Testadores criada pelo Leonardo Galani


Em breve irei inserir o Blog da Qualister.

Bom esses blogs são os que eu mais consulto, acredito que possa servir para o pessoal.

Clique no logo ou utilize o Code Bar.

Nota: O APP requer acesso à internet, para carregar os feeds dos blogs.


Também caso queiram baixar o app do 4 All Tests, tem nele os artigos do blog, downloads e em breve Videos.


Para instalar, você precisa liberar o seu aparelho para aceitar aplicações além da play store:


No aparelho acessa as configurações ou o app de configuração do aparelho


> Menu Pessoal

>> Opção Segurança

     > Menu Administração do Serviço

     >> Opção Fontes desconhecidas

           Marque essa opção: Permitir baixar fontes que não venham da play store.

   

Assim você conseguirá instalar o aplicativo.


Qualquer dúvida estamos ai.

Espero que sirva também à vocês.

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.

Esse Tester sou eu

Posted by JJ on May 28, 2013 at 5:55 PM Comments comments (1)

Video apresentado no 1° Workshop de Testes de Software e no TDC Florianópolis.

You need Adobe Flash Player to view this content.



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