Vamos a definição de REST, também conhecido como Representational State Transfer ou ainda Transferência do Estado Representativo, segundo o Wikipédia REST é:

"A Transferência de Estado Representativo (Representational State Transfer) ou somente (REST) é uma técnica de engenharia de software para sistemas hipermídiadistribuídos como a World Wide Web. O termo surgiu no ano de 2000, numa tese de doutorado1 (PHD) sobre a web, escrita por Roy Fielding, um dos principais autores da especificação do protocolo HTTP que é utilizado por sites da internet."

REST não é um padrão muito menos um protocolo, a definição que acho que melhor se encaixa é que REST é um estilo arquitetural para aplicações. REST define um conjunto de princípios simples que devem ser seguidos para a implementação de uma API. Alguns dos seus princípios são:

• URL identifica um recurso 
• URLs tem uma hierarquia 
• Métodos executam operações em recursos 
• As operações devem ser implícitas 

A intenção deste Post não é definir, nem discutir princípios e boas práticas de REST e sim como podemos testar uma API REST. Para quem quiser aprofundar mais nos conceitos para entender melhor o que é o estilo arquitetural REST pode ler esses links: 

1. http://www.rodrigocalado.com.br/o-que-e-rest-um-resumo-do-assunto-caracteristicas-conceitos-vantagens-e-desvantagens-prefiro-dizer-que-e-uma-rapida-introducao-ao-assunto/
2. http://www.caelum.com.br/apostila-vraptor-hibernate/rest/#11-1-o-que-e-rest
3. http://www.infoq.com/br/articles/rest-introduction

Entres outros que vocês podem encontrar com uma rápida pesquisa no google. 

Motivado por este post eu escrevi uma API REST simples para que possamos experimentar ferramentas/frameworks de automação de testes para api's rest, a api irá persistir os dados num banco MongoDB (já aproveita e instala o Mongo é bem simples e no site tem todas as informações) iremos utilizar os recursos do protocolo HTTP (PUT, POST, DELETE e GET) para atualizar, criar, excluir e consultar contatos na nossa agenda telefônica.

Você pode estar perguntando porque eu não publiquei esta api e disponibilizei uma Url para facilitar?

Propositalmente quero que tenham a oportunidade de ter contato com o MongoDB, Java Script - NodeJs e o GitHub. Muitos testadores se quer tem um conta no GitHub que é uma excelente fonte de códigos para estudar e ter contato com diversas linguagens e frameworks.

Para começar vamos instalar na sua máquina o NodeJs e o MongoDB que são requisito para executar nossa API.

Mongo : Download & Install

Node.Js : Download & Install

 Para prosseguir caso não tenha uma conta no GitHub  aproveite para criar, logo em seguida acesse a nossa API-PhoneBook que utilizaremos como base para automatizar alguns cenários de testes. Na página no github existe uma pequena documentação no "Readme.md" que pode ser útil para testarmos algumas chamadas na api de forma manual para entendermos o que vamos automatizar.

Se você já criou sua conta no github apenas clone o projeto na sua máquina:

• git clone https://github.com/fredmoreira/PhoneBook.git

Se não faça download do projeto no github e descompacte em um local de sua preferência.

Com o projeto na sua máquina acesse o diretório raiz onde tem o arquivo "package.json" que contém as dependências do projeto e execute o comando:

• "npm install" ou apenas "npm i"

Agora inicie o mongo para que quando a api for iniciada ela possa já conectar ao banco, pois caso o mongo não esteja iniciado a api também não conseguirá ser "startada".

• http://docs.mongodb.org/manual/tutorial/install-mongodb-on-windows/

Agora vamos iniciar o mongo para que a aplicação quando iniciar possa acessar o banco e persistir os dados. Para iniciar o mongo basta digitar o comanda abaixo caso tenha colocado o mongo na estrutura proposta no seu site. 

C:\mongodb\bin\mongod.exe --dbpath d:\test\mongodb\data

Uma dica é colocar o mongo como serviço do seu sistema operacional para evitar que você inicie sempre o mongo manualmente.
Agora podemos iniciar a aplicação para começar a testar a api.

• npm start

Agora que iniciamos a aplicação, vá até o browser e digite :

• http://localhost:5000/

E verifique que a API está funcionando.

Vale ressaltar que a princípio eu deixei a porta 5000 configurada para rodar a API, nada impede de vocês irem no arquivo "server.js" e alterar para a porta que desejarem.

Vamos começar a persistir alguns dados manualmente para verificar o funcionamento da API, existe diversas maneiras de fazer isso, irei usar uma extensão do Chrome denominada Postman.
Existem diversas outras ferramentas que possibilitam executar chamadas na api manualmente como o Fiddler e o SoapUI.
Para acessar o Postman digite no Chrome: chrome://apps/.
Preencha os dados para criação de um contato da seguinte maneira:

Enviei a requisição post no botão "send" e o retorno deve ser:

Desenvolvi a api para responder um json com os dados que foram persistidos e o mongo automaticamente gera um "id" para o registro conforme destacado acima e ainda o status "201 Created" que é o status padrão para uma resposta de um post. Para saber o um pouco mais sobre os status que podemos retornar acesse http://i.stack.imgur.com/whhD1.png

Depois de ver a api persistindo podemos dar um get via browser ou via postman para ver o registro que acabamos de persistir.

Bom esta foi a parte de preparação e testes manuais na api que desenvolvi, fiquem a vontade para explorar mais alguns recursos de atualizar e excluir registros presentes na api, além da opção de pesquisar registros com filtros(Query String). Estas informações estão no readme do projeto da api presente no github. Caso achem possíveis bugs favor me informar.

Na parte II desta série de testes em API REST vou demonstrar algumas ferramentas que conseguimos automatizar os nossos testes desta api de exemplo que escrevi, para os preguiçosos de plantão escrevi o post orientando como preparar e executar uma api simples em ambiente windows e ainda irei publicar para quem não quiser executar a api localmente poder a partir de uma url automatizar seus testes.

Em breve a parte II estará publicada, aproveite e leia blogs e artigos sobre Rest-Client em Ruby, Rest-Assures em java, FrisbyJs, Mocha e SuperTest em Java Script, pois irei escrever alguns testes possivelmente em uma dessas ferramentas.

Aproveite o código da api e estude um pouco sobre Java Script, NodeJs, Mongo, Mongoose e etc!

Dúvidas, elogios e críticas são sempre bem vindas :) 

Até breve...

Comecei a me interessar por Agile Testing um pouco após do início da minha carreira, porém sem efetivamente saber do que se tratava. Em 2009 quando eu ainda tratava a Automação de Testes como um “super” desafio, através de um amigo de profissão tive acesso ao Livro “Agile Testing – A Practical Guide for Testers and Agile Teams” que assim como a grande maioria dos testers que já leram este, julgo como a bíblia do Agile Testing.

Mas antes de prosseguir já deixo uma primeira dica que é antes de estudar sobre Agile Testing, primeiro estudar sobre o “Manifesto Ágil”, considero de imensa importância entender os valores e princípios do manifesto, porque qualquer abordagem, práticas e etc que se derivar do manifesto irá seguir os mesmos valores e princípios.

Atualmente vejo em muitos currículos e até em perfis no Linkedin as pessoas escrevendo conhecimento em Agile Testing, mas será que estas realmente possuem este conhecimento? Assim como as pessoas as vezes falam que trabalham em times ágeis e na verdade aplicam parte de uma metodologia apenas, sem ao menos preocupar se estão agregando valor ou efetivamente aplicando as recomendações básicas da metodologia utilizada.

Acredito que não é apenas colocar um chapéu e dizer eu sou um Agile Tester ou então apenas por ter fortes skills de automação considerar ser um agile tester, o papel de um tester em um time ágil gira muito além de saber automatizar testes ou aplicar uma prática de BDD.

Partindo da quebra de paradigma que é necessária para atuar de uma forma mais efetiva em um time ágil, onde julgo que a comunicação é tudo, o tester precisa ter coragem, no sentido de sentar ao lado de um desenvolvedor e de uma forma amigável falar que alguma coisa não está certa ou não está retornando um comportamento esperado e ainda ajudando aumentar a cobertura dos testes unitários num time que utiliza TDD por exemplo. Até mesmo na hora de ajudar esclarecer um desejo de um cliente com perguntas, mesmo que talvez estas não sejam sempre pertinentes.

Enquanto nas metodologias tradicionais os testers esperam pelo documento de requisitos para deste derivar seus casos de testes, num time ágil o papel de um tester é questionar, levantar a maior quantidade de dúvidas que você tiver a respeito dos desejos de um cliente, ajudando assim não só a ele mesmo, mas o time inteiro entender melhor o que o cliente realmente deseja, como consequência você irá ajudar no planejamento gerando assim tarefas mais objetivas.

  Automação de Testes

 As skills de automação de testes desempenham um papel fundamental no Agile Testing, mas estas estão longe de ser o objetivo final, nem mesmo os testes manuais feitos de maneira exploratória, o objetivo do Agile Testing é fazer com que os testes sejam parte integrada e natural dentro de um processo de desenvolvimento ágil que seja Scrum, Kanban ou qualquer outro.

"Coisas" Técnicas

Entender de "coisas" técnicas é essencial! Muitas vezes testers tradicionais não tem acesso ao banco de dados da aplicação que estão testando, quando tem acesso nem se quer executam um Select qualquer. Não tem mais como fugir disto, pode ter certeza que entender "coisas" técnicas vai agregar e muito valor ao time e a qualidade do produto desenvolvido. 

Defino coisas técnicas como coisas "simples" mesmo, como uma query sql, alguma ferramenta de integração continua como Jenkis, Bamboo e Continuum, entender um pouco de CSS, um pouco da linguagem que o time utiliza, conhecer e utilizar algum framework da família xUnit. Não é se tornar especialista, mas sim saber como utilizar uma ferramenta X,Y,Z em pró do time ou saber o básico da linguagem utilizada no time para aumentar a cobertura dos testes unitários junto ao desenvolvedor por exemplo, não só implementando, mas contribuindo com cenários de testes que só nós conseguimos imaginar.

Testes Exploratórios

Segundo Elisabeth Hendrickson testes exploratório é "Uma abordagem sistemática para descobrir riscos utilizando técnicas de análise rigorosas juntamente com heurísticas de testes".

"Em um time ágil os testers utilizamos testes exploratórios para ajudar o time a identificar se estão evitando, com sucesso que os bugs cheguem ao código final." 

Teste manual existe sim em Agile Testing, mas de uma maneira diferente, na verdade de forma exploratória, onde simultaneamente um tester vai aprender sobre o software que está testando, utilizando a sua experiência e usando sempre o feedback do ultimo teste para executar o próximo.

Vinculado ao assunto os testers pode utilizar o SBT (Session Based Test) onde criamos um pequeno documento conhecido como Charter, podemos dizer que o charter é o objetivo do teste baseado em sessão. Abaixo segue um exemplo:

Explore it! By Elisabeth Hendrickson

A maturidade do time é muito importante, pois a qualidade passa ser responsabilidade de todos da equipe não só da pessoa com o papel de tester, o time agora é auto-organizado, onde a comunicação é tudo e fugindo do tradicional o time não responde mais e-mails, foco na colaboração, teste agora é uma atividade não mais uma fase, a suposição perde espaço para perguntas, prevenir bugs é MAIOR que procurar bugs, as alterações requisitados pelo cliente são "bem vindas", ou seja, são vistas de maneira diferente do tradicional e possuem maior aceitação.

Qualidade = Responsabilidade do Time

Uma das atividades mais interessante na minha opinião é decidir junto ao time a estratégia de automação de teste, ou seja, definir  em qual nível deve-se automatizar um cenário de teste, diferente dos tempos que eu trabalhava em empresas onde existia apenas testes automatizados na profundidade de interface (GUI Tests) e ainda feita apenas por testers, muitas vezes sem se pensar em arquitetura de um projeto de teste automatizado, algumas vezes projetos feitos apenas com record-play e sendo executado em uma quantidade de horas que tornava na maioria das vezes o projeto de automação incrédulo na visão de gerentes de projeto e diretoria de tecnologia das empresas. 

Pirâmide de Automação de Testes

Assim como a um tempo atrás eu fiz, aconselho a você testador, de modelo tradicional ou não, profissional alocado, profissional de fábrica de teste ou software a repensar sua carreira, é colocar na balança seus conhecimentos e desejos de evolução. Sair da zona de conforto quase sempre é um bom combustível de ânimo para uma evolução na carreira e possibilitando até a realização de um sonho de trabalhar com atividades incríveis/desafiadoras em um ambiente incrível que você sempre almejou. 

Adeus Zona de conforto

Muitas pessoas vão dizer: "Mas existe isso?", "Existe este lugar?" Sinceramente não sei se todos encontrarão, mas ao apostar numa oportunidade que eu tive, me fez sair da zona de conforto e encontrar um ambiente / atividades com características bem perto do que eu sempre quis trabalhar.

A intenção  deste post foi trazer algumas informações e opiniões minhas sobre Agile Testing, já possuo uma certa experiência atuando efetivamente em times ágeis, mas acredito que temas como este são passíveis de discussões e de uma diversidade imensa de opiniões. Fiquem a vontade em concordar ou não, aqui críticas são bem vindas também! :)

Referências:

Elisabeth Hendrickson:

1. http://www.slideshare.net/ehendrickson
2. Explore It! new book on Pragmatic Programmers

• https://leanpub.com/AgileTesting/read
• http://blogdojonas.com.br/2014/05/18/o-papel-dos-testadores-nos-times-scrum/
• http://www.stickyminds.com/article/how-software-tester-helps-during-product-discovery?page=0%2C1
• http://blog.myscrumhalf.com/2014/03/melhorando-sua-estrategia-de-testes-automatizados/
• Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin e Janet Gregory

Quantas vezes tentamos acessar uma página e não conseguimos, recebemos uma página contendo uma mensagem de erro. Quem nunca passou por isso?

Muitas pessoas quando acessam uma página, não tem ideia do que acontece nos bastidores para que esta página possa ser exibida.

Existe um protocolo denominado HTTP(HyperText Transfer Protocol) que é o responsável pela comunicação entre o seu navegador Web e o servidor onde a página está hospedada. 

Os servidores onde as páginas estão hospedadas sempre que requisitados, retornam um código de resposta HTTP para quem fez uma requisição. 

Podemos ressaltar a importância desses códigos para um time de desenvolvimento, pois estes informam o status de uma requisição de uma página ou de algum recurso dela. Estas informações podem ser usadas como Debug por exemplo durante um ciclo de desenvolvimento. 

Esses códigos de status HTTP podem ser classificados em cinco grupos específicos, sendo que o primeiro dígito de cada grupo especifica a sua classe de resposta:

• Classe 1xx (Informativo)
• Classe 2xx (Sucesso)
• Classe 3xx (Redirecionamento)
• Classe 4xx (Erro gerados pelo lado do cliente)
• Classe 5xx (Erro do Servidor)

Irei mostrar alguns exemplos de cada classe.

100 - Continue - O cabeçalho do pedido foi recebido pelo servidor corretamente eo cliente pode continuar a enviar o corpo da solicitação.

101 - Ligue o Protocolo - O cliente tem solicitações ao servidor para mudar o protocolo e o servidor está respondendo de forma positiva.

102 - No processo - Devido a este código, ele indica que o servidor recebeu o pedido do cliente e processar o pedido, mas a resposta ainda não está disponível. Devido a este cliente não se expirou e presume-se que o pedido foi perdido.

201 - Criado – A solicitação foi bem sucedida e o servidor criou um novo recurso.

202 - Aceito – O servidor aceitou a solicitação, mas ainda não processou.

305 – Utilizar Proxy – O solicitante poderá acessar a página solicitada utilizando um proxy. Quando o servidor retornar essa resposta, também indicará qual proxy o solicitante deverá usar.

400 - Solicitação Inválida – O servidor não entendeu a sintaxe da solicitação.

404 - Não encontrada - A página solicitada não se encontra agora, mas podem estar disponíveis no futuro.

406 - Não Aceitável – A página solicitada não pode responder com as características de conteúdo solicitadas.

505 - Versão HTTP incompatível – O servidor não é compatível com a versão do protocolo HTTP usada na solicitação.

O protocolo HTTP define somente alguns códigos em cada classe descritos na RFC 2616, mas cada servidor pode definir seus próprios códigos.

Referências:

http://www.testinginterviewquestion.com/2014/06/what-are-different-http-status-codes_5.html

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

http://www.w3schools.com/tags/ref_httpmessages.asp

Já respiro novos ares profissionais e me deparei com novos conceitos, metodologias e desafios.

Em outras experiências na minha carreira não havia trabalhando tanto com testes de integração no projetos que participei. No meu contexto atual faz parte dos testes da solução da empresa, integração com operadoras de telefonia entre outros parceiros.

Portanto o uso de mocks e stubs são constantes, resolvi escrever um post sobre essa "dupla", com o intuito de entender a diferença entre eles, além de tentar esclarecer para nossa comunidade o que são e em quais situações podemos cada um.

De forma resumida concluí que Mocks são utilizados para testar interação e Stubs para esboçar estados, entendi que ambos são Fakes, mas são muito úteis em um ambiente de desenvolvimento, que se trabalha com integração com outras plataformas, parceiros, Web Services e etc.

No meu contexto atual utilizo com maior frequência os Stubs, principalmente para testar integração com operadoras de telefonia.

Para criar um novo Stub é feita uma conexão via WebService (ServiceReference) com o parceiro, afim de buscar informações WSDL sobre o funcionamento dos seus serviços. A partir dessas informações é possível simular todos os possíveis comportamentos desta integração, gerando o que chamamos de DataCases.

DataCases são possíveis comportamentos que podem ocorrer durante uma integração. Todos os possíveis comportamentos são cadastrados em um XML de configuração e a partir deste o Stub realiza os tratamentos necessários para uma simulação. Neste XML também encontramos os DataRules que são "as regras" que definem o comportamento, ou podemos dizer que contém informações necessárias para a simulação de um comportamento.

Segue abaixo um exemplo:

No exemplo acima, temos um arquivo de configuração de um Stub que simula para o retorno para todos número de celulares consultados da operadora Claro com o DDD 31, a regra contém o filtro do tipo DDD('TypeFilter-DDD-TypeFilter') e ainda indica que o retorno irá usar as informações presentes no DataCase 0('IdDataCase-0-IdDataCase').

Vendo as informações do DataCase 0 podemos ver que o Stub retornará que o número é do tipo Pós-Pago('SubscriberType-POS-SubscriberType') e ainda que o número está Ativo('Status-A-Status') para um certo cenário de teste, onde iríamos consultar se um número é válido na operadora seriam suficientes estas informações configuradas no arquivo de configuração de um Stub.

Relacionando o Mocks e Stubs na pirâmide de automação de testes de Mike Cohn, digamos que os Mocks estão no nível de unidade principalmente para times que utilizam TDD, já os Stubs estão mais próximos do nível serviços.

[1]

Espero ter conseguido clarear os conceitos e informações sobre Mocks e Stubs.

Em outras palavras, segundo Robson Castilho:

"Mocks são fakes assim como os stubs, porém um mock decide se um teste passou ou falhou. Outra forma de dizer isso é que stubs são usados em testes de estado, isto é, testes orientados ao resultado. Um método é testado e espera-se que algum resultado seja “X” ou verdadeiro ou não nulo, geralmente checando o valor retornado pelo método.

Por sua vez, mocks são usados em testes de interação, isto é, testes orientados à ação. O mock verifica se o método sob teste executa uma determinada ação (e não se ele retornou algo)."

Algumas ferramentas de Mock:

- EasyMock

- .Net EasyMock

- jMock

Referências:

http://martinfowler.com/bliki/TestPyramid.html

http://martinfowler.com/articles/mocksArentStubs.html

http://robsoncastilho.com.br/2010/11/20/testes-de-interacao-usando-mocks/

http://stackoverflow.com/questions/3459287/whats-the-difference-between-a-mock-stub

[1] Figura retirada do slide 17 do Elias Nogueira

http://pt.slideshare.net/elias.nogueira/todas-as-abordagens-de-testes-dentro-do-gil

Futuramente publicarei um post mais técnico com exemplo de códigos relacionados a Mocks e Stubs.

Obrigado pela visita!

O Agile Testers está com uma espécie de pesquisa interessante, não só a pesquisa, mas o intuito dela também. Diferente do que todos irão pensar no primeiro momento, esta pesquisa não é para eleger o melhor contribuidor, a melhor empresa e ainda o melhor site/blog. E sim mostrar para a comunidade quem é o mais lembrado(a) por todos nós, quando pensamos em contribuição e compartilhamento de informações e/ou experiência.

Acredito que ainda seja um experimento, mas que com opiniões pode transformar em uma espécie de "Prêmio Nobel" para nossa área, motivando as pessoas a compartilhar de suas experiências e com a intenção única de prover informações que ajude o crescimento de nossa comunidade.

Participe, contribua, o tempo gasto é mínimo e você pode estar ajudando muito nossa comunidade!

Não deixe para depois!

Vote:destaques.agiletesters.com.br

    Firmware Ágil?

Assim como no desenvolvimento de software, conseguimos aplicar apenas algumas práticas ágeis no desenvolvimento de firmware, por existir limitações citadas no último post.

  

Pensando com uma visão de um testador ágil, durante a definição das "estórias" já atuamos ajudando com perguntas, questionando, levantando o máximo de dúvidas possíveis fazendo com que o time entenda melhor o real desejo do usuário, além de servir de apoio para um melhor planejamento das atividades. Em si tratando de firmware é muito importante já ir pensando como um testador irá testar a funcionalidade em questão, pois existe durante os testes muitas vezes a manipulação de um hardware na qual o firmware é embarcado.

Por muito tempo conversando com os desenvolvedores de firmware, pensamos que não era possível fazer TDD no desenvolvimento de firmware, pois existia algumas preocupações como conseguir emular através da IDE de desenvolvimento o comportamento do firmware já embarcado.

Até que um dos desenvolvedores fez alguns testes com Unity e percebeu que o emulador usado, atendia a simulação do comportamento do firmware embarcado. O Unity é um framework de teste unitário escrito totalmente em C, é leve e possui recursos especiais para sistemas embarcados.

Voltando as atividades do testador, durante o TDD cabe a ele, ajudar o desenvolvedor a pensar nos diferentes cenários de testes para aumentar a cobertura de testes no código, no desenvolvimento de firmware o TDD fica mais "confiável" nas mãos do desenvolvedor, uma vez que muitas vezes um parâmetro passado num método por ser até uma posição de memória.

void test_ShowSomeSillyExamples(void)
{
TEST_ASSERT_NOT_EQUAL(0, -1);
TEST_ASSERT_EQUAL_INT(1, 1);
TEST_ASSERT_EQUAL_HEX16(0x1234, 0x1234);
TEST_ASSERT_EQUAL_STRING("These Are The Same", "These Are The Same");
TEST_ASSERT_BITS(0x1111, 0x5555, 0x7175);
TEST_ASSERT_INT_WITHIN(5, 100, 102);
}

Na linha do Unity temos o Cmock que é uma framework que trabalha junto com o Unity para ajudar na criação de Mocks e Stubs de interfaces para simplificar os testes.

A integração continua é possível para a compilação do firmware , mas o desafio ainda é o embarque do firmware no hardware, mas até o momento que participei do projeto já existia possíveis contornos para este desafio.

A automação encontrava-se bem evoluida com os primeiros casos de teste automatizados já sendo executados, com o auxílio de geradores de sinais e um framework desenvolvido para o apoio da automação.

Livros para apoio:

http://www.lulu.com/spotlight/mvandervoord

http://pragprog.com/book/jgade/test-driven-development-for-embedded-c

 

Este post é o último relacionado a a testes de firmware e hardware, uma vez que nesta semana iniciei minhas atividades em uma nova empresa, onde estou tendo a oportunidade de trabalhar com testes ágeis voltados para aplicações.

Pretendo escrever a partir de agora sobre meu dia a dia atuando em times ágeis, assim como ferramentas de BDD e automação, além das novas experiências com Agile Testing.

Créditos: Felipe Provenzano