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

Título da palestra	Nome do palestrante	Link para o material
Eu não garanto a qualidade	Diego Blond	Link
Testes em API Rest	Claudenir Freitas	Não disponibilizado
Testes exploratórios não são sinônimos de bagunça!	Igor Leite	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	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ó	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	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	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.