Exibir código-fonte para Trilha Testes 2016

A trilha de Testes I do TDC 2016 foi dividida entre palestras técnicas e não técnicas. As palestras técnicas tratavam de assuntos relacionados a implementação de testes unitários, melhoria de performance nas suites de testes, ferramentas de auxílio nos testes. As palestras não técnicas eram básicas em sua maioria, onde palestrantes com pouco tempo na área de testes contaram suas experiências.

==Materiais disponibilizados pelos palestrantes==
{| class="wikitable"
!Título da palestra
!Nome do palestrante
!Link para o material
|-
|Eu não garanto a qualidade||Diego Blond||[http://pt.slideshare.net/DiegoBlond/tdc2016-eu-naogarantoaqualidade Link]
|-
|Testes em API Rest||Claudenir Freitas||Não disponibilizado
|-
|Testes exploratórios não são sinônimos de bagunça!||Igor Leite||[http://www.slideshare.net/igoravl/testes-exploratrios-no-so-sinnimo-de-baguna Link]
|-
|10 coisas que não me contaram sobre testes||Katiana Maia||Não disponibilizado
|-
|Otimizando tempo de build: performance da suíte de testes||Jônatas Davi Paganini||[http://pt.slideshare.net/jonataspaganini/otimizando-tempo-de-build-performance-da-sute-de-testes Link]
|-
|Automação de Testes Mobile com Appium ||Luiz Augusto dos Santos Lohn|| Não disponibilizado
|-
|4 dicas valiosas para uma pirâmide de testes saudável ||Taíse Dias da Silva / Ricardo Cavalcanti|| Não disponibilizado
|-
| BrowserSync: Acelerando seus testes manuais na web ||Danilo Feijó|| [https://docs.google.com/presentation/d/1MIT52DgWv69umTgI2njPnlz_q8_dt9GANOFcBws1E1E/edit#slide=id.g36937d2ff_132 Link]
|-
| Automação de testes com Docker ||Danilo Torres Porcelani|| Não disponibilizado
|-
| Programando testes: uma quebra de paradigmas entre Dev e QA ||Lucas Martins Ramos / Julio Cesar de Freitas Parra|| [http://geofusion.tech/programando-testes-uma-quebra-de-paradigmas-entre-dev-e-qa-lucas-martins-e-julio-parra/ Link]
|-
| Tomada de decisão baseada em testes de carga ||Edlaine Teodora Silva Zamora|| Não disponibilizado
|-
| A transição de um QA tradicional para um Agile Tester || Priscila Beltrami Formaggio / Jessica Aparecida Mollo || Não disponibilizado
|-
| Estou desempregado e agora? Como me recolocar como QA ||Robson Agapito Correa||[http://pt.slideshare.net/robsonagapito/estou-desempregado-e-agora-como-me-recolocar-como-qa Link]
|-
| O que a IOT vai mudar no mundo dos Testes ||Alan José Nascimento|| Não disponibilizado
|-
|}

==Eu não garanto a qualidade.==

Palestrante: Diego Blond

Conteúdo simplificado para iniciantes.
A qualidade é responsabilidade da equipe, não só do testador.

* Abrir bugs não garante a qualidade. E se ninguém corrigir?
* Não ter bugs não garante a qualidade. 
* Relatórios não garantem a qualidade.
* Discussões não garantem a qualidade.
* Planos de teste não garantem a qualidade. Gastam muito tempo e as pessoas acabam não seguindo os planos de teste. Tudo pode se perder caso o plano de testes seja construído com base num documento falho.
* Hora extra não garante qualidade pois não quer dizer que o funcionário está efetivamente produzindo mais.
* Desistir não garante qualidade.
* Equipe maior não garante qualidade. Equipe menor também não.
* Focar na qualidade não garante qualidade. De que adianta construir um sistema perfeito se ele não é entregue no prazo?
* Entregas com pressão não garantem qualidade.
* Entregas sem pressão também não garantem qualidade.
* Testes automatizados não garantem qualidade. Levam tempo para serem construídos. Esse tipo de teste nunca vai entender o usuário da mesma forma que você.
* Ser um bom QA não garante qualidade. A equipe garante! Equipe informada conhece o usuário e faz questionamentos. É importante saber se comunicar com o cliente e fazer sugestões. É importante sair da zona de conforto. Bom senso: Saber onde aplicar cada esforço. É importante ter bom senso em tudo.

Tudo isso junto garante a qualidade.

Dicas do palestrante: 
* Fazer workshops com os clientes. Ninguém entende melhor das regras do sistema do que o próprio cliente.
* Seja o exemplo da equipe. Mostre que é possível aplicar melhores práticas.

==Testes exploratórios não são sinônimos de bagunça!==

Nos testes exploratórios o testador aprende, faz o design e executa o teste ao mesmo tempo, evoluindo à medida em que executa os testes.
Ser ágil não é fazer de qualquer jeito. Cadastrar um bug não é apenas mandar um print para o desenvolvimento.

O palestrante apresentou o plug-in da Microsoft chamado Exploratory Testing para Google Chrome (disponível em http://aka.ms/xtinstall).

* Integração com o TFS ou roda sem conexão;
* Grava os cliques do usuário durante a execução dos testes;
* Permite abrir os prints para edição;
* No modo standalone, gera um relatório após a execução dos testes;
* Integrado ao TFS, permite o cadastro de bugs diretamente no servidor.

==10 coisas que não me contaram sobre testes==
Esta palestra contou a experiência de uma Tester que está há pouco tempo na área, através de 10 itens que contam o que ela descobriu na profissão.
*Ser detalhista é bom
*Psicologia
*Works on my Machine – quando o sistema funciona apenas na máquina no desenvolvedor
*Nem todos fazem testes
*Programar, eu? – conta que decidiu aprender programação também, pois achou os testes repetitivos
*Automação não é complicado
*Tradicional ou ágil? A keyword é comunicação
*Tempo é um atributo definitivo
*Cortes
*O mundo dos testes é maior do que pensamos

Foi uma palestra bem básica que pouco agregou tecnicamente.

==Otimizando tempo de build: performance da suíte de testes==

O palestrante contou sua experiência em otimizar o tempo de execução de uma suíte de testes com mais de 13 mil testes.
No cenário, os testes rodam cada vez que o desenvolvedor dá um pull. 
Os testes levavam 25 minutos em 3 conteiners, utilizando o programa CircleCI.
O tempo de execução dos 13 mil testes em localhost passava de 2 horas.
Após as melhorias, o tempo de execução dos testes passou de 25 para 13 minutos, utilizando uma máquina a mais apenas.
Utilizou a ferramenta Factory Girl para definir a estrutura dos testes.

O palestrante deu algumas dicas para a otimização:

*Evitar call-backs, como por exemplo a funcionalidade de envio de e-mails. É irrelevante para a execução dos testes num primeiro momento. Mas e quanto a cobertura de código? O ideal seria escrever um cenário apenas para o envio de e-mails e executá-lo em separado.
*Associações também podem ser problema. Exemplo seria o cadastro de empresas que depende de pessoas que depende de contatos. A ideia é fazer factories especializados: apenas empresa, empresa com pessoas e empresa com contatos. Em vez de fazer 3 inserts, faz só 1. Isso causa ganho de velocidade.
*Associações lazy. Associações que naturalmente chamam os próprios factories.
*Hack sign_in: Cria usuários simulados, sem precisar fazer todas as validações. O cálculo da criptografia pouco importa no teste.
*As inserções no BD custam caro computacionalmente.
*Dividir os testes no CircleCI apresentou ganhos.
*Hack no postgres: fsync = ‘off’ .Configuração desnecessária nos testes.
* full_pages_writes=’off’
*Rodar o postgres direto na memória

==Automação de Testes Mobile com Appium==

Serve tanto para apps IOS e Android.

Filosofias do Appium: 

*Você não deve ter que mudar o código para automatizar
*Use a especificação padrão
*Código aberto

O appium serve como ponte entre o App e o Device. O primeiro passo é definir as capabilities: Appium, Android, Versão, Emulador, onde vai rodar.

O palestrante fez uma rápida demonstração da automatização de uma ação em um app Android.