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	Link
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	Link
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	Link
4 dicas valiosas para uma pirâmide de testes saudável	Taíse Dias da Silva / Ricardo Cavalcanti	Link
BrowserSync: Acelerando seus testes manuais na web	Danilo Feijó	Link
Automação de testes com Docker	Danilo Torres Porcelani	Link
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	Link
A transição de um QA tradicional para um Agile Tester	Priscila Beltrami Formaggio / Jessica Aparecida Mollo	Link
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	Link

Eu não garanto a qualidade.

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!

Igor Leite

Visão geral sobre os testes exploratórios e apresentou uma ferramenta da Microsoft para auxiliar nesse tipo de teste.

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

Katiana Maia

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

Jônatas Davi Paganini

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 push. 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

Luiz Augusto dos Santos Lohn

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.

4 dicas valiosas para uma pirâmide de testes saudável

Taíse Dias da Silva e Ricardo Cavalcanti

Os palestrantes explicaram o formato da pirâmide de testes tradicional.

Imagem da pirâmide de testes dividida em três níveis: Unit (base), Service (meio) e UI (topo)

• Testes unitários: mais fáceis de serem automatizados, mais rápidos de serem executados. Softwares: JUnit, Karma, Sccalatest, Unittest.
• Service: camada abaixo da UI. Testes mais lentos e mais caros para escrever.
• UI: Mais lentos para rodar e frágeis devido às mudanças nas interfaces. Softwares: Protractor, Capybara, Selenium.

Imagem da pirâmide de testes com um seta apontando para cima: Aumento de escopo e confiança. Os testes realizados no topo da pirâmide trazem confiança sobre a aplicação.

Imagem da pirâmide de testes com um seta apontando para cima: Mais rápido e melhor isoladamente.

Recomendações do palestrante:

• Separar os testes unitários dos testes de aceitação para promover feedback mais rápido.
• Não adiar implementação de jornada do usuário.
• O topo traz confiança sobre a aplicação.
• Provedor e consumidor devem poder iniciar os testes de contrato. Testes de contato: integração entre dois sistemas que garante que um provedor de serviços cumpre o contrato com o consumidor. Exemplo: cliente da API – serviço.

Na empresa ThoughtWorks os desenvolvedores fazem testes unitários. Isso não significa perda de tempo de desenvolvimento e sim dão passos mais firmes no processo.

Testes em API Rest

Claudenir Freitas

Palestra de 15 minutos com demonstração de um teste em API.

O palestrante comentou das vantagens em se usar APIs: descomplicar, simples, seguro, escalável.

Ferramentas: Postman, Rest client. Extensão do Chrome.

BrowserSync: Acelerando seus testes manuais na web

Danilo Feijó

Palestra de 15 minutos apresentando a ferramenta BrowserSync. Essa ferramenta espelha as ações realizadas em um navegador para todos os outros, otimizando o tempo de testes.

Características da ferramenta:

• Muito utilizada em DEV e suporte de sites.
• Assistente de execução
• Agiliza os testes
• Replica URLs
• Espelha ações

Pontos de atenção: Mouseover, steps diferentes.

Problemas conhecidos: Javascript

Para instalar: necessita do NodeJS.

npm install -g browser-sync

Para executar:

Browser-sync start -p “aplicação”

Redução de 40% no tempo de testes.

Automação de testes com Docker

Danilo Torres Porcelani

Por que virtualizar? Facilitar a infraestrutura.

Docker: cria contêiner localmente através de imagens. Compartilha o kernel do Linux, o que deixa mais rápido.

1. Criar dockfile

2. Arq YML

3. Run app

Programando testes: uma quebra de paradigmas entre Dev e QA

Lucas Martins Ramos e Julio Cesar de Freitas Parra

Quem é responsável pela qualidade? O time.

Segundo os palestrantes, não deveríamos criar tarefas para testes. O teste deve fazer parte do desenvolvimento. Pareamento entre DEVs e Testers não é desperdício de tempo e sim disseminação de conhecimento.

Ferramentas: Cucumber, Selenium. Front end: Jasmine

Vantagens:

• Descoberta de bugs antes do deploy
• Time preza pela qualidade

O palestrante informou que na sua empresa os testes passam um tempo com os desenvolvedores aprendendo as linguagens.

Tomada de decisão baseado em teste de carga

Edilaine Zamara

A palestrante apresentou os conceitos básicos dos testes de desempenho, dando foco nos testes de carga. O intuito da palestra foi apresentar as principais tomadas de decisão possíveis a partir dos resultados dos testes de carga.

Processo dos testes: Criação dos scripts -> Cenários -> Execução -> Monitoramento -> Análise dos resultados

Ferramentas: JMeter

Características da ferramente:

• Gratuito
• Gera resultados em CSV
• Execução distribuída
• Diversos tipos de requisição
• Controle de variáveis
• Programação

Qual sua reação quando seu cliente diz que o sistema caiu no meio de um evento importante?

O teste de carga ajuda a identificar:

• capacidade
• fraquezas
• coleta de dados para escalabilidade
• Falhas de segurança, como senhas sem encriptação
• Desempenho do BD

Análise através de:

• Gráficos, tabelas, árvore de resultados

Exemplos:

• Nível do SO
• Aumentar hardware
• Diminuir tamanho dos arquivos
• Minificação e sprites CSS
• Otimizar algoritmos
• Cache de dados

A transição de um QA tradicional para Agile

Priscila Beltrami Formaggio

Testers tradicionais:

• Apenas aponta erros
• Jurassic testes
• Resistente a novos processos
• Não sabe definir suas habilidades

Como mudar?

O QA tem que manter o timr focado em entegar o valor certo para o cliente em cada ciclo. Ao mesmo tempo devem estar preocupados com a qualidade.

• Ajudar na tomada de decisão
• Trabalhar desde o começo no processo
• Carreira em T
• Automação
• Organizar o time
• Motiva o time

Perfis

Negócio:

• Visão analítica
• Regras de negócio
• Fica ao lado do PO
• Lado racional do PO
• Testes funcionais e não funcionais
• Motiva o time

Técnico:

• Programação em par com os DEVs
• TDD
• Conhecimento em automação
• Conhecimento em frameworks
• Motiva o time

DEVQA:

• Conhecimento do pipeline de implantação
• Configuração de scripts
• Motiva o time

Estou desempregado e agora? Como me recolocar como QA

Robson Agapito Correa

O palestrante contou sua experiência em tentar se recolocar no mercado de qualidade de software. Dentre os principais itens:

• Inglês
• Selenium WebDriver
• Cucumber
• Teoria de testes de software
• Ruby

O que a IOT vai mudar no mundo dos Testes

Alan José Nascimento

O palestrante falou sobre a Internet das coisas (IoT). O intuito da palestra foi apresentar o conceito e nos deixar cientes de que é uma área que vai crescer muito nos próximos anos. E uma reflexão: Como os testes vão acompanhar essa evolução?

A Internet das coisas é um grande e confuso campo a espera de explodir. Não envolve necessariamente Internet.

O que muda? Agora temos:

• Eletrônica embarcada
• Sensores
• Relés
• Servos

O palestrante apresentou o caso da marca OMO, onde a empresa instalou GPS dentro de uma caixa de sabão em pó. Quando o cliente chegava em casa, a equipe chegava e presenteava o cliente.

Dispositivos IoT vai crescer 30% em 2016.
Principais áreas: saúde, serviços públicos, prédios comerciais, casas, transporte e utilidades.