Verdades e mitos sobre testes que eu gostaria que tivessem

me avisadoLivia Gabos

Objetivos da palestra

• Não é fazer vocês desistirem da área de testes.

• Não é fazer vocês pensarem que eu estou reclamando da vida.

• Não é fazer vocês pensarem que o pessoal de testes leva a pior (sempre).

• Não é fazer vocês pensarem que testes são chatos.

Objetivos da palestra

• Contar um pouco sobre as minhas experiências.

• Coisas que vi e ouvi em eventos e outras pessoas da área.

Livia adverte:

Qualquer situação relatada pode ou não ter acontecido comigo ou com um amigo meu.

Testes não são importantes

Testes não são importantes

Testes não são importantes

Testes não são importantes

Defeito Erro Falha

Testes não são importantes

• Engano de uma pessoa produz um passo incorreto

• Era para ser x>=4 e virou x>4Defeito

• Estado inconsistente ou inesperadoErro

• Resultado é diferente do resultado esperado

• 1, 2, 3 e 4 não passa...xiii, acho que não funcionouFalha

Testes não são importantes

Testes são importantes!

• Testes são uma parte da qualidade.

• Já ajudam muito para garantir a qualidade.

• Processo de desenvolvimento deve possuir qualidade.

• “Sem testes, sem defeitos” by @ProgramadorREAL

Testes só acontecem no final

Testes só acontecem no final

• Final do que?• Da iteração?

• Do desenvolvimento da funcionalidade?

• Do ciclo de desenvolvimento?

• Da semana?

• Do mês?

• Do software ter sido produzido por inteiro?

• Do meu salário?

Testes só acontecem no final

• “O produto final do processo de desenvolvimento é exatamente o somatório de todas as decisões e realizações geradas durante todo o ciclo de desenvolvimento.

• Se for desejado produzir software com alta qualidade, será necessário investir em qualidade em todos os pontos do processo.”

• https://patiaragon.wordpress.com/

Testes só acontecem no final

Testes só acontecem no final

• Espiral

• Ágil

Testes só acontecem no final

• Por que isso acontece?• Ninguém gosta de alguém falando que você está errado.

• Ninguém quer alguém questionando suas ideias.

• “Do seu jeito é melhor? Então desenvolve aí...”

Testes não acontecem apenas no final

• Existem testes que são papel do desenvolvedor.

• Se você pensa: qualidade = testes, como você deixa a qualidade para o final?

Se testar só a última versão está tudo bem!

Se testar só a última versão está tudo bem!

Fonte: @c_caetano

Se testar só a última versão está tudo bem!

Fonte: @c_caetano

Se testar só a última versão está tudo bem!

Fonte: @c_caetano

Se testar só a última versão está tudo bem!

Fonte: @c_caetano

Se testar só a última versão está tudo bem!

Fonte: @c_caetano

Se testar só a última versão está tudo bem?

Se testar só a última versão está tudo bem!

UI

Integração

Unitário

UI

Integração

Unitário

ManuaisManuais

VS

SIM NÃO

Se testar só a última versão está tudo bem!

• Acham que programar script de teste é complicado.

• Acham que teste automatizado é usando ferramenta de play-record.

• Por conta disso, ninguém quer testar antes de nunca mais mexerem um pixel na tela.

• Daí o teste fica tudo no final.

Testar tudo!

• Implementar testes unitários, de regressão, testes automatizados com scripts de testes.

Você não precisa de documentação para testar!

Você não precisa de documentação para testar!• O que você considera documentação?

• Diagrama de classe?

• Documento de requisitos (atualizado)?

• Casos de uso (atualizado)?

• O que você considera documentação de testes?• Plano de testes

• Casos de testes

• Relatório de teste

Acho que a função de controle e integração entre o departamento

de marketing e da controladoria pode

ser.....

O que ele estava pensando quando escreveu essa

funcionalidade?

Você não precisa de documentação para testar!• Documentação serve para comunicar.

• Preciso fazer um longo documento de requisitos (que eu não vou atualizar depois da terceira iteração)?• Não

• Posso escrever de um jeito mais simples o que aquela funcionalidade precisa fazer?• Sim

Você não precisa de documentação para testar!Cenário <descrição do teste>

Dado <uma pré-condição>

Quando <passo>

Então <resultado esperado>

Cenário: Consultando um triângulo Escaleno

Dado que eu estou na página de consulta de triângulos

Quando eu informo os lados do triangulo como 3 – 4 – 5

Então o sistema informa que o triângulo é “escaleno”.

Você precisa de alguma documentação!

• Você precisa de um oráculo!

• A documentação ajuda para quando não tem ninguém da sua equipe• Todos estão de férias menos você!

Todo bug encontrado é culpa do desenvolvedor

Todo bug encontrado é culpa do desenvolvedor• Algo não está escrito certo ou está difícil de entender.

• Desenvolvedor não entendeu o que estava escrito.

• Nem tinha documentação.

Todo bug encontrado é culpa do desenvolvedor• Porque o desenvolvedor tem que testar?

• Testar =! Debugar

• Códigos de refatoração -> o testador não vai achar isso!

• Teste unitário e integração

Todo bug encontrado é culpa do desenvolvedorDepois que o erro é encontrado, podemos declarar que o procedimento ideal seria:

• Analisar o bug, resolvê-lo, e registrar a atividade como “Erro” na ferramenta de controle interno para fins de documentação;

• Utilizar métodos de análise de causa para descobrir como o erro chegou até a produção;

• Certificar-se de que a causa seja resolvida para evitar ocorrências futuras.

Todo bug encontrado é culpa do desenvolvedorDepois que o erro é encontrado, podemos declarar que o procedimento ideal seria:

• Analisar o bug, resolvê-lo, e registrar a atividade como “Erro” na ferramenta de controle interno para fins de documentação;

Todo bug encontrado é culpa do desenvolvedor• Precisamos achar de quem é a culpa?

• Não

• Porque só se faz isso então?

Os bugs encontrados não é culpa de ngm!

• É necessário corrigir o processo que criou o bug e o processo que não encontrou ele a tempo.

O teste é responsabilidade apenas do testador

O teste é responsabilidade apenas do testador• Porque isso acontece?

• Falta tempo para o desenvolvedor testar

• Falta tempo para o desenvolvedor desenvolver (às vezes)

• Falta experiência

• Sobre preconceito

O teste é responsabilidade apenas do testador

UI

Integração

Unitário

UI

Integração

Unitário

ManuaisManuais

VS

O teste é responsabilidade apenas do testador• TDD - Test Driven Development

• Programação em duplas

Todo mundo tem que testar!

• Todo mundo testa com diferentes visões.

O teste de sistema/funcional é o mais importante

O teste de sistema/funcional é o mais importante• Técnica de teste

• Valor limite• Partição de equivalência• Exploratório

• Nível do teste• Módulo único

• Teste de Unidade

• Agrupamento de módulos • Teste de Integração

• Sistema completo • Teste de Sistema

O teste de sistema/funcional é o mais importante• Tem outros?

• Testes funcionais

• Testes não-funcionais• Teste de usabilidade

• Teste de acessibilidade

• Teste de performance

• Teste de carga

• Teste de stress

• Teste de segurança

• Aceitação

• Regressão

O teste de sistema/funcional é o mais importante• O que você considera como qualidade?

• O que o seu gerente considera como qualidade?

• O que seu cliente considera como qualidade?

• O que o usuário final considera como qualidade?

O teste de sistema/funcional é o mais importante

• Testes funcionais

• Testes não-funcionais• Teste de usabilidade• Teste de acessibilidade• Teste de performance• Teste de carga• Teste de stress• Teste de segurança

• Aceitação

• Regressão

Faça testes que garantam o que você precisa !

• Tudo depende do que você precisa garantir para saber qual teste é melhor para você.

Teste não-funcional não é importante

Teste não-funcional não é importante

• Você sabe escrever um requisito não-funcional?

• Você sabe o que é um requisito não-funcional?

Teste não-funcional não é importante

• Requisitos não-funcionais são relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, disponibilidade, segurança e tecnologias envolvidas.

• Muitas vezes, os requisitos não funcionais acabam gerando restrições aos funcionais.

• “Não é preciso o cliente dizer sobre eles, pois eles são características mínimas de um software de qualidade.”

Teste não-funcional não é importante

• Declarar os requisitos não-funcionais como user-stories• Como um cliente, quero ser capaz de executar o seu produto em todas as

versões do Windows, do Windows 95 até a versão atual.

• Como diretor de tecnologia, quero que o sistema use nosso banco de dados de pedidos ao invés de criar um novo banco, para não termos mais um banco de dados para manter.

• Como usuário, quero que o site esteja disponível 99,999% do tempo em que tentar acessá-lo, para que eu não fique frustrado e procure outro site.

Teste não-funcional não é importante

• Custo de conformidade inicial

• Custo de conformidade contínua

Teste não-funcional não é importante

• Equipe de desenvolvimento lembra dos requisitos não-funcionais?• Gerente

• Dev

• Analista de requisitos

• Chega no final de tudo e alguém fala:• Vai testar a acessibilidade?

Teste não-funcional é importante sim!

• Existem startup usando teste de usabilidade para avaliar protótipos e ideias.

• Existem testes não-funcionais que são tão importantes quanto os funcionais.

Ninguém tem esse nome tão comprido!

Ninguém tem esse nome tão comprido!

• Qual o problema com o nome?

• O nome é comprido demais

• O nome é curto demais

• Um nome normal não usa números

Ninguém tem esse nome tão comprido!

Ninguém tem esse nome tão comprido!

• Antônio Treze de Junho de Mil Novecentos e Dezessete

• Benedito Frôscolo Jovino de Almeida Aimbaré Militão de Souza Baruel de Itaparica Boré Fomi de Tucunduvá

• Brígida de Samora Mora Belderagas Piruégas de Alfim Cerqueira Borges Cabral

• Carlos Alberto Santíssimo Sacramento Cantinho da Vila Alencar da Corte Real Sampaio Carneiro de Souza e Faro

• Napoleão Bonaparte Sem Medo e Sem Mácula

• Simplício Simplório da Simplicidade Simples

Não subestimem a criatividade das pessoas!

• Testar com informações reais e possíveis• Nome: ahskdauhsdkuahskduhakushdkaushdukas

• Sejam criativos

• Façam composições de informações para serem complexas

Testes são rápidos/lentos de se fazer. (Deixa pra depois)

Testes são rápidos/lentos de se fazer.

• As pessoas pensam que testes são rápidos de se fazerem e por isso deixam para depois. (E não fazem)

• As pessoas pensam que testes são muitos demorados e atrasam o processo de desenvolvimento. (E não fazem)

Testes são rápidos/lentos de se fazer.

• Tudo depende se você tem ou não uma métrica.

• Se você entende das necessidades essenciais de teste.

• Não adianta não fazer testes porque demoraram mais a entrega final por conta disso.

Sem conhecimento não existe qualidade

• Se você registra as condições do teste, você pode obter métricas e tornar o processo de teste mais inteligente.

• Se você conhece seu produto, entende seu processo de desenvolvimento e sua equipe, você sabe como testá-lo.

• Ter qualidade no processo significa no final que se você fizer o teste no começo, no meio ou no fim de uma iteração o resultado não será trágico.

Você não precisa saber programar!

Você não precisa saber programar!

UI

Integração

Unitário

Manuais

Você não precisa saber programar!

UI

Integração

Unitário

UI

Integração

Unitário

ManuaisManuais

VS

Você não precisa saber programar!

• Você só sabe fazer teste manual.

• Você só faz testes com a interface.

• Você não tem voz ativa na equipe de desenvolvimento.

Você tem que saber programar sim!

• Saber banco de dados

• Saber programar

• Saber mexer com frameworks de testes

Testes são só custos

Testes são só custos

• Por que você quer fazer testes?• Provar que tudo funciona?

• Provar que não tem erros?

• Provar que você não vai ter surpresas desagradáveis quando entregar aquilo pro cliente?

• Provar que tem qualidade?

Testes são só custos

• Qualidade é o principal.

• Se seu processo de desenvolvimento possui problemas de qualidade não é o teste que vai salvá-lo.

Sigam no twitter

• @thoughtworks_pt

• @eliasnogueira

• @qualister

• @c_caetano

• @gutsrs – canal no youtube também

• http://agiletesters.com.br/

Sites que usei na apresentação

• http://engtesteagil.blogspot.com.br/

• http://eliasnogueira.com/diferencas-entre-um-testador-real-e-um-testador-fake/

• https://patiaragon.wordpress.com/

• http://www.fredmoreira.com/

• http://bugs-busters.blogspot.com.br/2015/08/7-passos-para-o-desenvolvedor-odiar.html

• http://bugs-busters.blogspot.com.br/2015/09/7-passos-para-o-responsavel-pelo-teste.html

• http://www.andrecelestino.com/bug-software-de-quem-e-culpa-parte-2/

• http://imasters.com.br/desenvolvimento/gerencia-de-projetos/nao-reclame-de-software-ruim-para-o-desenvolvedor-a-culpa-e-dos-gerentes/?trace=1519021197

• http://www.infoq.com/br/news/2011/06/dominando-requisitos-nfuncionais

Sites legais

• http://pt.slideshare.net/GTS-CE/

• http://eliasnogueira.com/

• http://bugs-busters.blogspot.com.br/

• http://pt.slideshare.net/stefanteixeira/

Dúvidas?

• about.me/liviagabos

• @liviagabos