Vocabulário básico para testadores ágeis

Estou preparando um material recheado de novidades sobre testes ágeis, mas estava ficando um pouco preocupado com o vocabulário que vou usar, cheio de termos em inglês ou traduções literais não costumeiras das nossas listas e livros, por isso decidi “preparar o terreno” com um post falando um pouco sobre cada um dos termos mais usados e discutidos no mundo agile.

Os termos abaixo em alguns casos tem mais de uma tradução ou podem ter mais de um significado. Peço a gentileza de compreender que esse post é focado em quem não entende nada de agile, portanto as explicações serão bem básicas e em alguns casos até incompleta. O foco aqui é criar uma introdução para abordar mais tarde. Caso queira mais informações sobre os termos aqui dispostos, leitores mais avançados no assunto podem consultar as referências e postar outros pontos de vista aqui nos comentários :)

Termos Gerais:

Scrum:Scrum é um framework ágil para realização de projetos complexos. Scrum originalmente foi formalizado para projetos de desenvolvimento de software, mas funciona bem para qualquer escopo complexo ou inovador de trabalho. As possibilidades são infinitas. O Scrum framework é enganosamente simples” [4]. Essa é a tradução do conceito de scrum para o Scrum Alliance (http://www.scrumalliance.org), entidade sem fins lucrativos que difunde o uso do framework ágil Scrum.

Resumindo muito, na minha opinião o scrum é uma forma iterativa, colaborativa, real e transparente de planjemanto de projeto e relacionamento entre membros da equipe, clientes e demais interessados no projeto.

Iterativa pois TODOS tem o direito e o dever de participar. Nada de um gerente sênior julgar quantas horas você vai levar para fazer o que você faz todos os dias. Todos decidem juntos. Colaborativa pois a todo momento qualquer stakeholder (ver conceito abaixo) pode incluir itens no product backlog (ver conceito abaixo), opinar e acompanhar o andamento das atividades. Real pois ninguém tenta enganar a si mesmo, ao cliente, ao gerente ou a diretoria, todos tem conhecimento das limitações e da capacidade atual de produção, e usam a priorização para tomar decisões ao invés de criar cronogramas irreais para atender a um ou outro stakeholder. Transparente por todos os motivos anteriores. Ninguém tenta enganar ninguém, muito menos a si mesmo, todos sabem o que todos estão fazendo e a quanto tempo estão fazendo e as decisões sempre ficam na mão do próprio cliente, que também entende todo o processo de desenvolvimento do produto.

Figura extraída de http://www.mountaingoatsoftware.com/scrum/overview em 20/03/2011

Não vou detalhar o Scrum, pois existe bastante material sobre o assunto, inclusive um post muito bacana (e completo) do Fabrício Ferrari http://qualidadebr.wordpress.com/2009/07/12/scrum/. Provavelmente escreverei um no futuro, até lá, a literatura e os blogs tem MUITO material sobre :)

Depois de ler esse post completo, sugiro ler “The Scrum Framework in 30 Seconds” para reforçar os conceitos.

Extreme Programming: O XP é uma metodologia ágil parecida com o Scrum, mas focada no dia a dia do desenvolvedor. O XP funciona bem usando só desenvolvedores, isso significa que “não precisa” dos demais envolvidos como testadores, coordenadores e analistas de requisitos, bastando os desenvolvedores com conhecimentos multidisciplinares e os representantes do cliente que estarão full time disponíveis e preferencialmente no mesmo local que a equipe de desenvolvedores. Claro que não impede a existencia de testadores ou analistas de requisitos no time, inclusive já citei como o XP pode inspirar processos de teste, no post “Práticas XP ajudando na efetividade do teste de software“.

Figura extraída de http://www.extremeprogramming.org/map/project.html em 20/03/2011

Particularmente, eu vejo o XP como um modelo de engenharia para o desenvolvimento de software e o scrum como um modelo de gestão do processo de engenharia. Ambos tem aspectos dos dois lados, inclusive compartilhando técnicas como o sprint e alguns de seus derivados. Idealmente, a união dos dois modelos pode agregar muito valor para o produto em desenvolvimento.

Stakeholder: Uma descrição para representar os interessados no projeto. Stakeholder é qualquer um que tenha alguma relação com o projeto, dentro ou fora da equipe de desenvolvimento. Testadores, desenvolvedores, analistas de requisitos, gerentes de projetos, membros da diretoria e designers são exemplos de stakeholders, assim como especialistas do negócio do cliente, diretoria da equipe cliente, supervisores do cliente etc. Qualquer um que esteja relacionado diretamente com o projeto, ou seja, que afete e/ou seja afetado pelo projeto de alguma forma é um stakeholder.

Agile Manifesto: [1] Conjunto de valores e princípios, criados por Kent Beck e diversos outros especialistas da engenharia de software, que direcionam e motivam o pensamento ágil, como por exemplo a valorização da confiança nas pessoas, iterações e clientes ao invés de depositar toda a confiança em documentos, diagramas e contratos. Isso é um dos motivos que os “extremistas tradicionalistas ortodoxos contra agilidade” usam para difamar o Agile dizendo que não existe documentação ou que não tem organização. Comentei sobre os tradicionalistas, mas por outro lado, existem os “Xiitas Ágeis donos da verdade”, que acreditam que não existe nenhuma outra abordagem que não seja o agile. É muito importante saber usar a abordagem mais apropriada para cada tipo de equipe, para cada tipo de cliente e sempre usar um pouco de cada metodologia. Tanto o RUP quando o Scrum detem ótimas práticas e dezenas de anos de experiência de profissionais e empresas brilhantes, desfazer de qualquer um deles é virar as costas para um mundo de conhecimentos, erros e acertos da engenharia de software. Para saber mais acesse http://agilemanifesto.org/.

Figura extraída de http://blogdojonas.com.br/?p=1259 em 20/03/2011

Product Owner: Representante do cliente, detentor do conhecimento do produto. O Product Owner é o membro que no XP, deve ficar sempre junto da equipe de desenvolvimento. Ele também é a palavra final sobre os requisitos funcionais do sistema, ele conhece cada fração do sistema e ele sabe o que deve ser desenvolvido primeiro, o que pode ser substituído e o que deve ser mudado em cada sprint. Quando falamos que o Agile “abraça as mudanças”, falamos que esse cara, o Product Owner tem o poder de mudar tudo a qualquer hora. Claro que existem algumas regras para isso. Ele define quais User Storys devem entrar em cada Sprint. Dificilmente ele vai querer mexer em uma Sprint em execução, mas caso seja necessário, ele pode escolher User Storys que ainda não foram executadas e remover para adicionar um conjunto de User Storys de igual complexidade. Em ultimo caso, uma Sprint pode ser abortada, mas isso é muito incomum.

O Product Owner dos sonhos do XP é um pouco irreal, pois ele, utopicamente, deve ter conhecimento do negócio e visão do usuário como um usuário final do software e ao mesmo tempo ter o poder de decisão de um diretor ou patrocinador do projeto. Muito comum em empresas de software ERP, mas pouco comum em projetos de sistemas de informação tradicionais das nossas empresas.

Scrum Master: Líder e orientador da equipe. Organiza as tasks, preside o Daily Scrum Meeting, Planning Poker, Sprint Review e quaisquer outras reuniões que se façam necessárias. O Scrum Master tem o papel de manter a ordem e orientar a equipe a alcançar o objetivo de entregar software como valor.

Sprint: A Sprint é um pequeno ciclo que normalmente tem entre uma e duas semanas. Toda sprint é precedida de um planejamento onde podem ser usadas abordagens como planning poker ou outro tipo de planejamento. A ideia principal da sprint é ter um pequeno ciclo planejado e acompanhado por todos os envolvidos, inclusive pelo cliente, que gere software funcional ao seu fim.

Story Points: também chamado de Complexity points, são a medida que cada equipe usa para medir o tamanho funcional do que eles desenvolvem em cada sprint. Normalmente a equipe escolhe em todo o product backlog qual é a User Story mais simples, e juntos, durante o planning poker falam que essa User Story tem 1 (um) Story Point. Daí em diante, todos sabendo da complexidade dessa User Story mais simples a equipe define as demais complexidades para as demais User Storys do product backlog.

Product Backlog: É a fonte de todas as User Storys do projeto. Uma lista com as User Storys e a prioridade que o Product Owner seleciona para cada um. Daqui são retiradas algumas User Storys para serem julgadas em um Planning Poker. De acordo com a Sprint Velocity, são selecionadas as User Storys prioritárias até completar a quantidade de Story Points comportada.

Planning Poker: É a forma de planejamento usada pelo Scrum, XP e por alguns outros modelos ágeis. Cada membro da equipe tem um baralho como o demonstrado pela figura abaixo. em uma reunião em mesa redonda, cada uma das User Storys é colocada na mesa e explicada pelo Product Owner ou Scrum Master, enquanto os membros questionam e esclarecem suas dúvidas. Então o scrum master pergunta aos membros da mesa qual a complexidade dessa tarefa, e cada um dos membros, colocam a carta com a complexidade estimada em Story Points por ele na mesa. Então todos viram a carta o mesmo tempo, para que nenhum membro mude sua opinião em função da escolha de outro membro.

O baralho abaixo não está errado rs, ele segue uma numeração próxima a sequencia de Fibonaccci para que as diferenças entre as complexidades não sejam muito baixas. Quando uma User Story tem a mesma complexidade estimada por todos os membros da mesa, a complexidade automaticamente fica como a complexidade escolhida, caso contrário, cada membro justifica sua escolha, o que ajuda os membros com dúvidas a repensar a complexidade. Após essa discussão, uma nova jogada é realizada e assim fica até que a complexidade chegue a um consenso. Para entender mais acesse http://www.planningpoker.com/.

Figura extraída de http://elephant.pokerstrategy.com/categories/Development_Scrum

Scrumboard: Quadro onde ficam as user storys e tasks durante a sprint. O quadro também tem um workflow, por onde as tasks vão passando. Esses workflows podem ter diferentes combinações, mas normalmente tem um “to do” (para fazer), onde são depositadas as tarefas que ainda não foram pegas por nenhum membro da equipe, “Doing” (Fazendo) onde ficam as tarefas que cada membro da equipe está executando e “Done” (Feito) onde ficam as tarefas já concluídas. Em empresas mais preocupadas com a qualidade, existe uma fase após o Doing, chamada QA, onde é feita uma inspeção ou avaliação de um profissional de igual qualificação.

Figura extraída de http://ju-n.net/6-scrum-project-management-tools

Daily Scrum Meeting: Algumas metodologias ágeis, como o Scrum, pregam que o acompanhamento não deve ser feito por um único membro da equipe, como um gerente ou coordenador, mas por toda a equipe. Essa motivação deu origem a uma reunião em pé, de poucos minutos e poucos tópicos, no início do dia. Essa reunião pode ser de várias formas, uma que eu gostei muito é fazer um circulo em uma sala, em pé, onde uma bola passa de mão em mão e cada um responde a três perguntas: O que você fez ontem, o que vai fazer hoje e se existe algum impedimento. O Scrum Master da equipe arquiva essas informações e avalia os impedimentos citados. O Product Owner pode ou não participar dessa reunião.

Sprint Review: Para quem trabalha com modelos mais tradicionais, existe uma reunião ao fim do projeto ou no fim de cada iteração chamada “Lições Aprendidas”. O Sprint Review é parecido com essa reunião, mas acontece ao final de cada Sprint. Nessa reunião, são avaliadas as razões do sucesso da sprint ou de seu fracasso. São avaliados os resultados da sprint, tais como quantos pontos deixaram de ser executados, quantos pontos a mais foram executados, quais foram as atividades mais complexas etc. É muito recomendável que o Product Owner participe junto com a equipe de desenvolvimento. Essa reunião também ajuda a calibrar a Velocity do time.

Velocity: Cada equipe no mundo tem uma produtividade diferente. O que usamos no Scrum e em outras metodologias ágeis para medir a produtividade é a Sprint Velocity ou simplesmente Velocity. Para conhecer a produtividade, falamos que a Sprint Velocity é a quantidade de Complexity Points que conseguimos realizar em uma Sprint, ou seja: Sprint Velocity = Complexity Points de uma Sprint. Esse número varia muito de acordo com as equipes e não é um número fixo definido pelo scrum. Ou seja, uma equipe que tem uma Sprint Velocity de 10 pode ter uma produtividade muito superior a uma equipe que tem uma Sprint Velocity de 400. Isso acontece porque cada equipe define uma medida diferente para seus Complexity Points, como foi comentado anteriormente no item planning poker, a equipe define uma User Story mais mais simples para usar como referência para julgar as demais user storys, e essa tarefa vai influenciar diretamente na velocity do time. Isso assegura que a equipe vai conhecer sua própria produtividade com muita precisão e que vai competir com si mesma, realizando assim um aumento continuo da produtividade, sem perder em qualidade.

User Story: Assim como o caso de uso está para o RUP, a User Story está para o Agile. O RUP é baseado em casos de uso, ou seja, ele usa o caso de uso como menor unidade de funcionalidade. O Agile usa a User Story para isso. A User Story é um conjunto de passos definido pelo Product Owner ou pelos seus especialistas de negócios. Desse artefatos, derivamos tasks que a implementam. Uma User Story só está completada quando todas as tasks, incluindo análise, desenho, desenvolvimento, teste e aceite estão completas.

Algumas vertentes do Agile definem que uma boa User Story tem a seguinte sintaxe [6]: “Como um <papel>, eu quero <objetivo/desejo> então terei <benefícios>” Na Wikipedia (http://en.wikipedia.org/wiki/User_story) tem vários exemplos de User Storys.

Nada impede que em um modelo ágil de desenvolvimento, sejam criados inicialmente User Storys, e durante a Sprint, sejam criados também casos de uso convencionais. Como comentado anteriormente neste post, usar Agile não significa não usar RUP, e vice versa. O sábio usa o melhor dos dois mundos.

Tasks: Uma task é a menor unidade de trabalho. Qualquer Tarefa indivisível pode ser representada por uma Task. Desde desenvolver o layout de alguma tela, escrever uma procedure até testar um caso de teste. Qualquer atividade executável no scrum é uma task. Um conjunto de tasks implementam uma Feature ou User Story.

A tasks são os itens que navegam naquele workflow apresentado na scrumboard.

Pair Programming: Usada em algumas vertentes do Agile, como no XP, a técnica de Pair Programming consiste no desenvolvimento em conjunto entre dois especialistas. Não digo que pode ser aplicada apenas por desenvolvedores, pois eu aplico em diversas atividades de revisão. Resumindo, duas pessoas pensam enquanto uma executa. Saiba mais: http://www.extremeprogramming.org/rules/pair.html

Para entender um pouco mais de uma olhada no post “Praticas XP ajudando na efetividade do teste de software” deste mesmo blog.

Burndown Chart: É um gráfico que pode ser usado de duas formas. A primeira e mais convencional, é usando os Story Poins do Product Backlog contra as Sprints. Dessa forma, mostramos o quanto estamos evoluindo o produto. No caso de Sprints mais longas, como por exemplo de um mês, podemos usar um Burndown Chart diário que faz uma correlação entre os Complexity Points dentro da sprint e os dias. Dessa forma o gráfico nos mostra que estamos evoluindo dentro da Sprint. O ideal é que o gráfico fique na forma de uma correlação negativa, ou seja, os elementos tracem uma linha diagonal da esquerda para a direita e de cima para baixo, como na imagem extraída do site do Mick Cohn.

Extraído de http://blog.mountaingoatsoftware.com/improving-on-traditional-release-burndown-charts em 16/03/2011
Extraído de http://blog.mountaingoatsoftware.com/improving-on-traditional-release-burndown-charts em 16/03/2011

 

Postponed: (task ou User Story): Dizemos que uma task ou User Story está postponned (Postecipada) quando durante uma sprint temos que adiar sua execução. Normalmente existe um espaço na parte inferior do scrumboard reservado para este estado. São motivos aceitáveis para adiar uma task por exemplo descobrir que a task é muito mais complexa do que foi imaginado ou que não existem recursos para realizá-la. O Product Owner também pode optar por mudar alguma User Story durante a sprint, para isso ele deve seguir a regra da substituição pela mesma complexidade ou inferior.

Stretch (task): Quando fechamos terminamos a contagem dos complexity points e temos o total da sprint, selecionamos algo normalmente entre 10% e 30% do total da velocity da equipe em User Storys adicionais, e incluímos suas tarefas na sprint como Stretch. Ou seja, caso tenhamos uma visão pessimista da sprint ou tenhamos uma produtividade acima do normal nessa sprint, temos mais algumas tasks para terminar sem mudar o planejamento. Essas tasks não são de conclusão obrigatórias e nunca devem ser priorizadas sobre as tasks selecionadas para a sprint, são apenas tasks que devem ser realizadas caso completemos todas as tasks da sprint antes do final da sprint.

Foco em Teste:

Abaixo alguns termos usados focados em teste de software, ou que são menos conhecidos do que os termos apresentados até aqui.

Business-Facing Test: Ver Acceptance Tests.

Tecnology-Facing Test: Ao contrário dos Business-Facing Tests, os Tecnology-Facing Tests são testes que não se importam tanto com o negócio, mas sim com as tecnologias envolvidas. Testes elaborados para encontrar defeitos de tecnologia, problemas conhecidos da linguagem de programação, dos frameworks, componentes de terceiros ou ferramentas presentes no software desenvolvido. Também são aplicáveis para testes de interface entre esses itens, como por exemplo unit testes para validar o Spring ou o mapeamento do Hibernate.

São muito comuns em equipes que usam o XP e estão crescendo muito em equipes de teste de software, dentro e fora do universo agile. Esses testes são importantes principalmente para avaliação da arquitetura do sistema e de interfaces que comunicam com componentes externos ao sistema, como google maps entre outras bibliotecas disponibilizadas por web sevices.

Exploratory Test: Segundo o ISTQB, exploratory test é uma técnica de modelagem de teste informal na qual o testador controla ativamente a modelagem dos testes já que estes são realizados e utilizam as informações obtidas durante o teste para modelar testes novos e melhores. [Subsequente a Bach].

Muitas pessoas que praticam o “Testa aí” dizem realizar Testes exploratórios, em outros casos, empresas com baixa preocupação com a qualidade dos sistemas contratam estagiários ou analistas júniores para execução dos testes aleatórios e sem aplicação de técnica ou conhecimento citados anteriormente, o que acabou por tornar essa técnica mal vista por diversos gerentes, empresas e até profissionais de qualidade de software. Na prática, o explortory test é um teste executado por alguém, com profundo conhecimento do negócio e do sistema que usa de um roteiro simples para executar testes baseados no próprio conhecimento e em idéias modeladas em tempo de teste, o que pode ajudar na elaboração de casos de testes mais efetivos e realistas.

Recomendo o livro Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design do James A. Whittaker.

Smoke Test: O ISTQB define smoke test como Subconjunto de todos os casos de testes definidos/planejados que cobre a principal funcionalidade de um componente ou sistema, para averiguar as principais funções de um programa em funcionamento sem se preocupar com maiores detalhes. A realização diária de testes de construção e fumaça está entre as melhores práticas do ramo. Ver também teste intake.

Os smoke tests são fundamentais para times ágeis. Como na definição do ISTQB, ele é um conjunto de testes que já avaliam se “vale a pena” gastar mais tempo com todos os testes ou se é melhor devolver e reavalir se o que foi implementado está realmente implementado e satisfatório.

Imagine que você tem um plano de testes com mais de 150 casos de teste e que eles ocupem uma equipe de 5 testadores durante 7 horas de trabalho. Se quando o coordenador receber um sistema para execução de testes funcionais ele já distribuir os casos de teste para os testadores, ao final do dia ele pode ter um resultado de reprovação da maioria dos casos de teste, além de ter dezenas de casos de teste bloqueados. Esse tipo de situação pode ser evitada usando smoke tests, pois esse subconjunto de casos de teste garantem que o sistema está “testável” ou seja, vale a pena gastar esforço de teste com o sistema.

A execução de testes de fumaça anteriores aos ciclos de teste estão entre as melhores práticas do teste de software na minha opinião. Caso use o TestLink ou outra ferramenta de gestão de teste que permita o uso de campos customizados ou palavras chave, recomendo que use uma palavra chave “Smoke Test” para definí-los e use um filtro antes de executar o ciclo de teste.

Unit Test: Esse tema já foi abordado aqui no blog no post “Uma introdução ao TDD com JUnit“. Chamado em português como “Teste de unidade” (o termo “teste unitário” remete a idéia de “teste único” e não de teste de unidade), o Unit Test é um nível de teste em que testamos cada componente ou unidade do sistema. Normalmente é implementado pelo próprio desenvolvedor, na forma de código executável, utilizando as classes e algumas vezes até stubs (simuladores).

Segundo o ISTQB, também pode ser chamado de Componennt Testing (teste de componente) e pode ser definido como “Teste realizado com os componentes individuais de um software. [Subsequente ao IEEE 610]“.

Test Driven Development: Assim como no caso dos Unit Tests, esse tema também já foi abordado aqui no blog no post “Uma introdução ao TDD com JUnit“, mas resumindo, é uma “técnica” usada para ajudar o desenvolvedor a desenvolver “código saudável’  ao mesmo tempo garantindo cobertura de teste em todo o código fonte e ajudando no teste de regressão.  Ela consiste na elaboração dos Unit Tests antes mesmo do desenvolvimento do código do software, isso ajuda o desenvolvedor a pensar mais como testador e conhecer melhor suas implementações.

Para facilitar o desenvolvimento dos unit tests o desenvolvedor pode criar a classe, disponibilizando somente o contrato nos objetos, o que torna os testes mais tangíveis e fáceis de imaginar.

Acceptance tests: Lisa Crispin e Janet Gregory em seu livro Agile Software Testing[2] definem acceptance test (Testes de Aceite) como testes baseados nos documentos, também chamados de Business-Facing Tests (Testes focados no negócio*) e afirmam que comumente as pessoas confundem com o termo  UAT (User Acceptance Test), que são testes posteriores ao desenvolvimento do software, executados pelo cliente e acompanhados por um membro da equipe, preferencialmente o testador.

Segundo o ISTQB, o Acceptance test pode ser definido como Teste formal relacionado às necessidades dos usuários e aos requisitos e processos de negócios. Este teste é realizado para estabelecer se um determinado sistema satisfaz ou não os critérios de aceite e para possibilitar aos usuários, aos clientes e às outras entidades autorizadas decidir aceitar ou não determinado sistema. [Subsequente ao IEEE 610].

Deixando definições de lado, Acceptance Tests ou Business-Facing Tests são testes desenvolvidos para avaliar se uma User Story está implementada corretamente, ou seja, se o que o usuário pediu foi implementado e normalmente são executadas por um especialista em teste de software. Casos de teste podem ser ótimos exemplos de acceptance tests, embora abordagens com idéias de teste (test ideas) e outros tipos de guia para execução de testes exploratórios sejam mais citados do que casos de teste em muitos grupos de agilidade.

*Tradução literal seria “Testes que enfrentam o negócio”.

Uma dica extra para quem quer embarcar no movimento agile. O inglês aqui não é porque eu sou fã de “americanização”, mas sim porque quase tudo sobre agile ainda está em inglês e esses termos em sua maioria são usados em inglês. Inglês é essencial, pelo menos leitura. Todas as grandes referências e ferramentas e a maioria dos blogs sobre esse tema estão em inglês. Um post muito legal do José Correia é o “The Bug is on the Table“, onde ressalta a importância de bons conhecimentos em inglês com dez motivos para “go and kill the bug“.

Como comentado anteriormente, fiquem a vontade para comentar e incluir outros termos não citados aqui, bem como para questionar e melhorar essa lista de termos básicos ou para postar suas dúvidas.

Bons testes :)

Referências:

[1] http://agilemanifesto.org/ em (14/03/2011)
[2] CRISPIN, Lisa; GREGORY, Janet. Agile Testing: A Practical Guide for Testers and Agile Teams, Addison-Wesley Professional.
[3] http://www.scrum.org/ em (14/03/2011)
[4] http://www.scrumalliance.org/pages/what_is_scrum em (14/03/2011)
[5] http://www.extremeprogramming.org/ em (14/03/2011)
[6] COHN, Mike. User Stories Applied: For Agile Software Development, Addison-Wesley Professional.
[7] CRISPIN, Lisa; GREGORY, Janet. Agile Testing: A Practical Guide for Testers and Agile Teams, Addison-Wesley Professional.
[8] http://agilemanifesto.org/principles.html em (20/03/2011)
[9] BECK, Kent. Test Driven Development: By Example. Addison-Wesley Professional

2 Responses to “Vocabulário básico para testadores ágeis”

  1. Taina M

    Muito bom esse post..estava procurando algo parecido..
    Parabéns pelo blog..

  2. Leandro

    Muito bom, trabalho com Agile e aprendi e fortifiquei alguns conceitos com o seu post.
    Parabéns!

Comente :)

WP-SpamFree by Pole Position Marketing

Currently you have JavaScript disabled. In order to post comments, please make sure JavaScript and Cookies are enabled, and reload the page. Click here for instructions on how to enable JavaScript in your browser.