Hoje na lista do selenium-users no Google foi postado um link onde o Automated Tester descrevia como capturar as evidências em vídeo através do Selenium RC + Python.
http://www.theautomatedtester.co.uk/blog/2010/castro-selenium-video.html
A biblioteca Castro foi criado pelo Jason Huggins, criador do Selenium e, obviamente, foi criada em Python...
Eu já consegui utilizar o demo que vem com a biblioteca em Python, mas como não sei bulhufas de Python estou até agora tentando fazer um script funcionar... :(
Assim que eu conseguir eu mostro o resultado....
O demo que a ferramenta gerou nos meus testes (do próprio Castro) pode ser visualizada abaixo: http://www.eliasnogueira.com/arquivos_blog/selenium/sandbox/castro-video.html
Abraços!
sexta-feira, 28 de maio de 2010
CTAL Syllabus em Portugues
Pelo que foi dito no grupo da BSTQB no Google hoje, saiu a versão traduzida do Syllabus da CTAL - Certified Tester Advanded Level da ISTQB e suas frentes em cada pais (como a BSTQB no Brasil)
Para efetuar o download gratuito do Syllabus da CTAL acesse o site da BSTQB, ou baixe diretamente o syllabus: http://www.bstqb.org.br/uploads/docs/ctal_syllabus_2007br.pdf
Abraços!
Para efetuar o download gratuito do Syllabus da CTAL acesse o site da BSTQB, ou baixe diretamente o syllabus: http://www.bstqb.org.br/uploads/docs/ctal_syllabus_2007br.pdf
Abraços!
terça-feira, 11 de maio de 2010
Automação de Teste - Revisão e Avaliação do Programa de Testes
A Revisão e Avaliação do Programa de Testes consistem em melhorar e aperfeiçoar todos os processos do Ciclo de Vida dos Testes Automatizados.
Após o término da execução dos testes a equipe de testes deve rever toda a eficácia do programa, analisando todos os documentos gerados desde a fase de concepção do modelo do CVTA (Ciclo de Vida dos Testes Automatizados) até a coleta de métricas depois da finalização dos testes. Esta fase precisa ser obrigatória para que o CVTA continue trazendo resultados satisfatórios para o processo de testes.
Saberemos se a automação ajudou a verificar se os requisitos foram cobertos mais rapidamente e também a avaliação dos ganhos em tempo de detecção de defeitos e o tempo que as métricas estão sendo geradas.
Um documento muito importante comumente utilizado na Gerencia de Projetos e que deve fazer parte desta fase é o de Lições Aprendidas junto com documentos para apoio na melhoria deste programa como as Avaliações de Métricas, Documento de Atividades e Ações Corretivas que devem ser aplicadas. Todas as anotações em cada fase do CVTA são muito importantes para identificar os problemas enfrentados e se estes têm impacto neste programa.
Com todas estas informações podemos definir, junto com o gerente ou líder de testes, o retorno de investimento que este programa está trazendo para a empresa durante todo o ciclo de vida dos testes.
Feedback da equipe de teste devem ser coletados para saber se a utilização do programa está tendo o efeito esperado, suas expectativas, melhorias e falhas neste programa. Percepções sobre a utilização das ferramentas também devem ser coletadas.
E com este post encerramos a primeira seria sobre Automação de Teste!
Não deixe de ler os outros posts relacionados:
Após o término da execução dos testes a equipe de testes deve rever toda a eficácia do programa, analisando todos os documentos gerados desde a fase de concepção do modelo do CVTA (Ciclo de Vida dos Testes Automatizados) até a coleta de métricas depois da finalização dos testes. Esta fase precisa ser obrigatória para que o CVTA continue trazendo resultados satisfatórios para o processo de testes.
Saberemos se a automação ajudou a verificar se os requisitos foram cobertos mais rapidamente e também a avaliação dos ganhos em tempo de detecção de defeitos e o tempo que as métricas estão sendo geradas.
Um documento muito importante comumente utilizado na Gerencia de Projetos e que deve fazer parte desta fase é o de Lições Aprendidas junto com documentos para apoio na melhoria deste programa como as Avaliações de Métricas, Documento de Atividades e Ações Corretivas que devem ser aplicadas. Todas as anotações em cada fase do CVTA são muito importantes para identificar os problemas enfrentados e se estes têm impacto neste programa.
Com todas estas informações podemos definir, junto com o gerente ou líder de testes, o retorno de investimento que este programa está trazendo para a empresa durante todo o ciclo de vida dos testes.
Feedback da equipe de teste devem ser coletados para saber se a utilização do programa está tendo o efeito esperado, suas expectativas, melhorias e falhas neste programa. Percepções sobre a utilização das ferramentas também devem ser coletadas.
E com este post encerramos a primeira seria sobre Automação de Teste!
Não deixe de ler os outros posts relacionados:
- Automação de Teste - Decisão por Automatizar
- Automação de Teste - Aquisição de Ferramentas
- Automação de Teste - Processos de Introdução dos Testes Automatizados
- Automação de Teste - Planejamento, Design e Desenvolvimento dos Testes - parte 1
- Automação de Teste - Planejamento, Design e Desenvolvimento dos Testes - parte 2
- Automação de Teste - Planejamento, Design e Desenvolvimento dos Testes - parte 3
- Automação de Teste - Planejamento, Design e Desenvolvimento dos Testes - parte 4
- Automação de Teste - Planejamento, Design e Desenvolvimento dos Testes - parte 5
- Automação de Teste - Execução e Gerenciamento dos Testes
quarta-feira, 5 de maio de 2010
Automação de Teste - Execução e Gerenciamento dos Testes
Depois que planejamos todos nossos testes, aplicações os testes com os scripts em um ambiente controlado e o mais semelhante possível do cliente é hora de aplicar toda a metodologia na execução real dos testes. Todas as técnicas de teste são executadas em suas fases seguindo toda a estratégia definida no Plano de Teste.
A equipe de teste irá se guiar, quanto à execução dos testes, pelo cronograma de testes que, na sua fase de execução contemplará todas as fases de teste. No âmbito de testes de caixa branca o engenheiro de teste terá de ser capaz de medir a profundidade de analise e execução e os caminhos que este teste faz na aplicação.
Esforços adicionais devem ser dados no teste de integração executando os scripts de teste e seguindo o processo de desenho criado no item anterior. Pode-se optar em executar uma bateria de testes em componentes primeiro, a fim de descobrir qual componente possui a maior quantidade de defeitos e em seguida executar uma bateria de testes de integração. Caso um componente apresente muitos defeitos, a equipe de teste pode direcionar esforços para ele, não deve comprometer a equipe toda. Testes manuais terão de ser executados, a fim de visualizar a execução dos passos como se fosse um usuário.
Todos os erros encontrados devem ser cadastrados na ferramenta de gestão de defeitos definida pela equipe de testes. O engenheiro de teste deve apoiar o gerente ou líder da equipe de teste fornecendo as métricas dos testes automatizados para que o mesmo possa tomas as devidas decisões sobre os esforços dos testes. Um diário de acompanhamento dos testes automáticos deve ser criado, a fim de obter informações para melhorar o processo no próximo teste do produto.
Lembre-se de executar, pelo mínimo uma vez todos os scripts automatizados de forma manual, assim você assegura o funcionamento não só em aspectos de erros e exceções, mas também percepções de uso do sistema.
Não deixe de ler os outros posts relacionados:
A equipe de teste irá se guiar, quanto à execução dos testes, pelo cronograma de testes que, na sua fase de execução contemplará todas as fases de teste. No âmbito de testes de caixa branca o engenheiro de teste terá de ser capaz de medir a profundidade de analise e execução e os caminhos que este teste faz na aplicação.
Esforços adicionais devem ser dados no teste de integração executando os scripts de teste e seguindo o processo de desenho criado no item anterior. Pode-se optar em executar uma bateria de testes em componentes primeiro, a fim de descobrir qual componente possui a maior quantidade de defeitos e em seguida executar uma bateria de testes de integração. Caso um componente apresente muitos defeitos, a equipe de teste pode direcionar esforços para ele, não deve comprometer a equipe toda. Testes manuais terão de ser executados, a fim de visualizar a execução dos passos como se fosse um usuário.
Todos os erros encontrados devem ser cadastrados na ferramenta de gestão de defeitos definida pela equipe de testes. O engenheiro de teste deve apoiar o gerente ou líder da equipe de teste fornecendo as métricas dos testes automatizados para que o mesmo possa tomas as devidas decisões sobre os esforços dos testes. Um diário de acompanhamento dos testes automáticos deve ser criado, a fim de obter informações para melhorar o processo no próximo teste do produto.
Lembre-se de executar, pelo mínimo uma vez todos os scripts automatizados de forma manual, assim você assegura o funcionamento não só em aspectos de erros e exceções, mas também percepções de uso do sistema.
Não deixe de ler os outros posts relacionados:
- Automação de Teste - Decisão por Automatizar
- Automação de Teste - Aquisição de Ferramentas
- Automação de Teste - Processos de Introdução dos Testes Automatizados
- Automação de Teste - Planejamento, Design e Desenvolvimento dos Testes - parte 1
- Automação de Teste - Planejamento, Design e Desenvolvimento dos Testes - parte 2
- Automação de Teste - Planejamento, Design e Desenvolvimento dos Testes - parte 3
- Automação de Teste - Planejamento, Design e Desenvolvimento dos Testes - parte 4
- Automação de Teste - Planejamento, Design e Desenvolvimento dos Testes - parte 5
domingo, 2 de maio de 2010
Dando poder aos testes existentes
O post abaixo foi retirado de um artigo de Dawn Haynes que é consultora em teste e instrutora da SQE Trainning.
O artigo pode ser encontrado em http://www.sqetraining.com/file/DawnHaynesArticle.pdf
Vou colocar o artigo na íntegra em português, que apresenta dez maneiras de dar poder aos seus testes de forma mais eficiente e valiosa sem ter diversas alterações na estratégia de teste.
1. Deja vú
A partir de um estado conhecido limpo ou estado inicial, execute um teste ou um cenário. Então, imediatamente, repita o mesmo teste ou cenário, utilizando os mesmos dados (se possível) sem reiniciar ou limpar qualquer dado ou configuração. Isso pode expor problemas com valores-padrão ou estados, fazendo com que a aplicação apresente um diferente comportamento ou saída devido a pequenas variáveis.
2. Ensaboar, enxugar e repetir, e repetir, e repetir
A repetição freqüentemente imita o modelo do uso real do aplicativo ou software. A maioria dos usuários fazem vários ciclos de um pequeno número de operações várias vezes ao dia. Se não testarmos a utilização real da aplicação podemos ter surpresas indesejáveis na aplicação (como o vazamento de memória)
3. A estrada menos viajada
Não siga sempre as instruções, os processos, os passos, ou caminhos óbvios. Muitos de seus usuários não farão esse caminho. Alguns dos defeitos mais caros em produção que eu ví foram encontrados, mas rejeitados como "falta de conhecimento da aplicação" ou não resolvidas pelo motivo "o usuário nunca faria isso". Mesmo que o seu software só esteja sendo acessado por outros sistemas, é arriscado presumir que os outros sistemas sempre irão interagir com a sua usando o mesmo padrão ou seguindo exatamente os caminhos da especificação ou design.
4. Eu sou um gênio
Utilize a abordagem de perito ou super-usuário. Pegue atalhos, pule etapas, utilize interfaces de linhas de comando, entre pela porta dos fundos, personalize trechos, utilize funcionalidades não documentadas ou use a interface/sistema rapidamente. Muitas vezes sistemas e interfaces com o usuário são projetado para um uso médio (esperado). Procure maneiras de "passar a marcha" na utilização da interface/sistema.
5. Doh
Ao passar por cenários óbvios, comuns ou críticos pare, beije a si mesmo na testa e então tente voltar e corrigir qualquer coisa no caminho, fazer algo que você esqueceu de fazer, editar uma entrada, etc.. Basicamente interrompa a aplicação e mude algo que você fez ao tentar voltar, refaça, substitua, desfaça,ou mude a perspectiva ou modo de utilização. Se seu aplicativo tem uma interface do usuário, especialmente se for baseada em navegador, você pode contar com usuários fazendo algumas destas coisas quando for o mínimo desejado.
6. Pense grande
Especialmente, pense em uma grande quantidade de dados. Durante a vida do seu software é provável encontrar um grande banco de dados, um grande conjunto de dados, arquivos grandes, entradas de valores grandes e grande volume de transações. Encontrando os limites e restrições que são suscetíveis de serem encontradas na produção, a curto prazo, ou no futuro pode ser extremamente valioso em termos de planejamento e execução de implementações de um software de sucesso.
7. Peças do Quebra-Cabeça
Os sistemas são muitas vezes concebidos e construídos em pedaços que são posteriormente montados em uma forma destinada a fornecer um valor para o negócio, usuários ou clientes. Como as peças se encaixam quando o quebra-cabeça é concluído? Pense em amarras as peças juntas em caminhos que podem ou não podem ter sido planejados na fase de criação ou do workflow.
8. Liquidificador: misture, pulse, adicione café e bebida
Misture variáveis, funções, operações, e cenários de uso em vários graus. (misture o normal x o caos)
9. Variações no espaço e tempo continuo
Utilize o sistema de forma lenta (como um novo usuário, usuário 'catando milho', usuário curioso, motorista de domingo) ou muito rápido (como o Ligeirinho). Cada uma destas taxas do sistema em diferentes caminhos. Alterne entre a utilização rápida e lenta. Interrompa um dos modos como uma "pausa para o café", abandone uma operação em fluxo sem salvar ou fechar. Ao viajar através de buracos para chegar lá e para cá entre universos lentos e rápidos, coisas interessantes podem acontecer.
10. Desastres naturais
Considere alguns cenários relacionados com a utilização contrária das funcionalidades ou propósito de uso. Tente o "teste do sapato no teclado". Ponha um sapato (ou a mão ou uma caneca de café) no teclado (de preferência na tecla Enter) e observe o que vai acontecer. Claro que o teste de "derramar o café sobre o teclado" ou "arrancar o cabo de alimentação" pode custar um pouco mais caro que os acontecimentos inesperados. Escolha-os sabiamente.
O artigo pode ser encontrado em http://www.sqetraining.com/file/DawnHaynesArticle.pdf
Vou colocar o artigo na íntegra em português, que apresenta dez maneiras de dar poder aos seus testes de forma mais eficiente e valiosa sem ter diversas alterações na estratégia de teste.
1. Deja vú
A partir de um estado conhecido limpo ou estado inicial, execute um teste ou um cenário. Então, imediatamente, repita o mesmo teste ou cenário, utilizando os mesmos dados (se possível) sem reiniciar ou limpar qualquer dado ou configuração. Isso pode expor problemas com valores-padrão ou estados, fazendo com que a aplicação apresente um diferente comportamento ou saída devido a pequenas variáveis.
2. Ensaboar, enxugar e repetir, e repetir, e repetir
A repetição freqüentemente imita o modelo do uso real do aplicativo ou software. A maioria dos usuários fazem vários ciclos de um pequeno número de operações várias vezes ao dia. Se não testarmos a utilização real da aplicação podemos ter surpresas indesejáveis na aplicação (como o vazamento de memória)
3. A estrada menos viajada
Não siga sempre as instruções, os processos, os passos, ou caminhos óbvios. Muitos de seus usuários não farão esse caminho. Alguns dos defeitos mais caros em produção que eu ví foram encontrados, mas rejeitados como "falta de conhecimento da aplicação" ou não resolvidas pelo motivo "o usuário nunca faria isso". Mesmo que o seu software só esteja sendo acessado por outros sistemas, é arriscado presumir que os outros sistemas sempre irão interagir com a sua usando o mesmo padrão ou seguindo exatamente os caminhos da especificação ou design.
4. Eu sou um gênio
Utilize a abordagem de perito ou super-usuário. Pegue atalhos, pule etapas, utilize interfaces de linhas de comando, entre pela porta dos fundos, personalize trechos, utilize funcionalidades não documentadas ou use a interface/sistema rapidamente. Muitas vezes sistemas e interfaces com o usuário são projetado para um uso médio (esperado). Procure maneiras de "passar a marcha" na utilização da interface/sistema.
5. Doh
Ao passar por cenários óbvios, comuns ou críticos pare, beije a si mesmo na testa e então tente voltar e corrigir qualquer coisa no caminho, fazer algo que você esqueceu de fazer, editar uma entrada, etc.. Basicamente interrompa a aplicação e mude algo que você fez ao tentar voltar, refaça, substitua, desfaça,ou mude a perspectiva ou modo de utilização. Se seu aplicativo tem uma interface do usuário, especialmente se for baseada em navegador, você pode contar com usuários fazendo algumas destas coisas quando for o mínimo desejado.
6. Pense grande
Especialmente, pense em uma grande quantidade de dados. Durante a vida do seu software é provável encontrar um grande banco de dados, um grande conjunto de dados, arquivos grandes, entradas de valores grandes e grande volume de transações. Encontrando os limites e restrições que são suscetíveis de serem encontradas na produção, a curto prazo, ou no futuro pode ser extremamente valioso em termos de planejamento e execução de implementações de um software de sucesso.
7. Peças do Quebra-Cabeça
Os sistemas são muitas vezes concebidos e construídos em pedaços que são posteriormente montados em uma forma destinada a fornecer um valor para o negócio, usuários ou clientes. Como as peças se encaixam quando o quebra-cabeça é concluído? Pense em amarras as peças juntas em caminhos que podem ou não podem ter sido planejados na fase de criação ou do workflow.
8. Liquidificador: misture, pulse, adicione café e bebida
Misture variáveis, funções, operações, e cenários de uso em vários graus. (misture o normal x o caos)
9. Variações no espaço e tempo continuo
Utilize o sistema de forma lenta (como um novo usuário, usuário 'catando milho', usuário curioso, motorista de domingo) ou muito rápido (como o Ligeirinho). Cada uma destas taxas do sistema em diferentes caminhos. Alterne entre a utilização rápida e lenta. Interrompa um dos modos como uma "pausa para o café", abandone uma operação em fluxo sem salvar ou fechar. Ao viajar através de buracos para chegar lá e para cá entre universos lentos e rápidos, coisas interessantes podem acontecer.
10. Desastres naturais
Considere alguns cenários relacionados com a utilização contrária das funcionalidades ou propósito de uso. Tente o "teste do sapato no teclado". Ponha um sapato (ou a mão ou uma caneca de café) no teclado (de preferência na tecla Enter) e observe o que vai acontecer. Claro que o teste de "derramar o café sobre o teclado" ou "arrancar o cabo de alimentação" pode custar um pouco mais caro que os acontecimentos inesperados. Escolha-os sabiamente.
sábado, 1 de maio de 2010
Testlink 1.9 beta 4 lançado
O Testlink lançou hoje (01/05/2010) a versão 1.9 beta 4 com a correção de 39 dos 100 bugs existentes na versão 1.9 beta 3.
Você pode baixar a versão beta em: http://sourceforge.net/projects/testlink/files/
Algumas melhorias foram adicionadas. A melhoria mais significativa foi referente a criação de passos dentro do Caso de Teste. Na versão 1.9.x os passos passam a ser tratados como uma entidade, onde você criar um passo e resultado esperado de cada vez.
Esta ainda é uma versão beta. O uso dentro do ambiente em sua empresa pode não ser recomendado. Faça isso por sua conta e risco!
Abaixo algumas imagens referente a criação dos Casos de Teste e dos Passos.
Agora na criação do Caso de Teste os campos de Passos e Resultados Esperados foram retirados. Houve também a criação de um novo campo, a Pré-Condição. Agora podemos colocar no campo Sumário todos os dados referentes ao Caso de Teste como Objetivos, Documentos Relacionados, etc...
Após a criação do Caso de Teste, um novo botão Criar um passo é apresentado. Devemos clicar nesse botão para adicionar os Passos e os Resultados Esperados do Caso de Teste
Agora a criação do Passo é totalmente ligada ao Resultado Esperado, virando uma "linha" (entidade) para cada conjunto deste par. Todas as outras entidades são listadas também. A adição da entidade é feita clicando sobre o Passo ou Resultado Esperado.
Após a finalização da criação dos Passos e dos Resultados Esperados, podemos ver o Caso de Teste completo.
Dica do leitor Jefferson!
Instalando o Testlink 1.9 beta 4 em banco de dados MySQL 4.1
"Estou instalando a nova versão do Testlink e encontrei algumas dificuldades referente a versão do MySql. Na empresa utilizamos a versão 4.1, (por motivos de força maior,rs). No script que cria as entidades na base de dados, existem alguns atributos que estão definidos como varchar de 4000, que seriam mais apropriados para quem utiliza a versão 5.0 ou superior, para a versão 4.1 um atributo varchar aceita até 255 caracteres. Para quem precisa utilizar o novo Testlink com a versão 4.1 do MySql é só alterar o script "testlink_create_tables.sql" que fica no diretório: C:\wamp\www\testlink-1.9beta4\install\sql\mysql, isso para quem usa o Wamp Server, localizar e substituir o varhcar(4000) por blob. Depois disso é só instalar e usar."
Obrigado Jefferson pela dica!!!
Você pode baixar a versão beta em: http://sourceforge.net/projects/testlink/files/
Algumas melhorias foram adicionadas. A melhoria mais significativa foi referente a criação de passos dentro do Caso de Teste. Na versão 1.9.x os passos passam a ser tratados como uma entidade, onde você criar um passo e resultado esperado de cada vez.
Esta ainda é uma versão beta. O uso dentro do ambiente em sua empresa pode não ser recomendado. Faça isso por sua conta e risco!
Abaixo algumas imagens referente a criação dos Casos de Teste e dos Passos.
Agora na criação do Caso de Teste os campos de Passos e Resultados Esperados foram retirados. Houve também a criação de um novo campo, a Pré-Condição. Agora podemos colocar no campo Sumário todos os dados referentes ao Caso de Teste como Objetivos, Documentos Relacionados, etc...
Após a criação do Caso de Teste, um novo botão Criar um passo é apresentado. Devemos clicar nesse botão para adicionar os Passos e os Resultados Esperados do Caso de Teste
Agora a criação do Passo é totalmente ligada ao Resultado Esperado, virando uma "linha" (entidade) para cada conjunto deste par. Todas as outras entidades são listadas também. A adição da entidade é feita clicando sobre o Passo ou Resultado Esperado.
Após a finalização da criação dos Passos e dos Resultados Esperados, podemos ver o Caso de Teste completo.
Dica do leitor Jefferson!
Instalando o Testlink 1.9 beta 4 em banco de dados MySQL 4.1
"Estou instalando a nova versão do Testlink e encontrei algumas dificuldades referente a versão do MySql. Na empresa utilizamos a versão 4.1, (por motivos de força maior,rs). No script que cria as entidades na base de dados, existem alguns atributos que estão definidos como varchar de 4000, que seriam mais apropriados para quem utiliza a versão 5.0 ou superior, para a versão 4.1 um atributo varchar aceita até 255 caracteres. Para quem precisa utilizar o novo Testlink com a versão 4.1 do MySql é só alterar o script "testlink_create_tables.sql" que fica no diretório: C:\wamp\www\testlink-1.9beta4\install\sql\mysql, isso para quem usa o Wamp Server, localizar e substituir o varhcar(4000) por blob. Depois disso é só instalar e usar."
Obrigado Jefferson pela dica!!!
Palestra - Viabilidade da Automacao Teste Software e Demo QTP
Dia 28/04/2010 em Porto Alegre o GUTS - Grupos de Usuários de Teste de Software promoveu uma palestra sobre Viabilidade e Conceitos Básicos de Automação com o QTP com Marcos Hermes, Engenheiro de Teste da Dell.
O post original pode ser encontrado lo link abaixo. Aqui vou apenas colocar a apresentação do SlideShare.
Vale a pena salientar que o Marcos Hermes é um dos Engenheiros de Teste mais capacitados em automação que eu ja conheci, e a apresentação está realmente ótima!
http://guts-rs.blogspot.com/2010/05/como-foi-o-evento-viabilidade-e.html
Ele também vai dar dois treinamentos sobre QTP na Qualister e na TargetTrust.
Na Qualister o treinamento será via webconferência (online) nos dias 24 a 24/05 das 19h as 21h.
Na TargetTrust o treinamento será presencial em Porto Alegre dia 21 a 24/06 das 18:45 as 21:45h
O post original pode ser encontrado lo link abaixo. Aqui vou apenas colocar a apresentação do SlideShare.
Vale a pena salientar que o Marcos Hermes é um dos Engenheiros de Teste mais capacitados em automação que eu ja conheci, e a apresentação está realmente ótima!
http://guts-rs.blogspot.com/2010/05/como-foi-o-evento-viabilidade-e.html
Ele também vai dar dois treinamentos sobre QTP na Qualister e na TargetTrust.
Na Qualister o treinamento será via webconferência (online) nos dias 24 a 24/05 das 19h as 21h.
Na TargetTrust o treinamento será presencial em Porto Alegre dia 21 a 24/06 das 18:45 as 21:45h
Assinar:
Postagens (Atom)