Palestra dada em 21/10/2015 na Jornada de Informática - Unesp/Bauru.

1. Verdades e mitos sobre testes
que eu gostaria que tivessem
me avisado
Livia Gabos

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

3. Objetivos da palestra
• Contar um pouco sobre as minhas experiências.
• Coisas que vi e ouvi em eventos e outras pessoas da área.

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

5. Testes não são importantes

6. Testes não são importantes

7. Testes não são importantes

8. Testes não são importantes
Defeito Erro Falha

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

10. Testes não são importantes

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

12. Testes só acontecem no final

13. 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?

14. 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/

15. Testes só acontecem no final

16. Testes só acontecem no final
• Espiral
• Ágil

17. 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í...”

18. 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?

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

20. Se testar só a última versão está tudo bem!
Fonte: @c_caetano

21. Se testar só a última versão está tudo bem!
Fonte: @c_caetano

22. Se testar só a última versão está tudo bem!
Fonte: @c_caetano

23. Se testar só a última versão está tudo bem!
Fonte: @c_caetano

24. Se testar só a última versão está tudo bem!
Fonte: @c_caetano

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

26. Se testar só a última versão está tudo bem!
UI
Integração
Unitário
UI
Integração
Unitário
Manuais
Manuais
VS
SIM NÃO

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

28. Testar tudo!
• Implementar testes unitários, de regressão, testes automatizados
com scripts de testes.

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

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

31. Acho que a função de
controle e integração
entre o departamento
de marketing e da
controladoria pode
ser.....

32. O que ele estava pensando
quando escreveu essa
funcionalidade?

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

34. 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”.

35. 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ê!

36. Todo bug encontrado é culpa
do desenvolvedor

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

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

39. Todo bug encontrado é culpa
do desenvolvedor
Depois 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.

40. Todo bug encontrado é culpa
do desenvolvedor
Depois 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;

41. Todo bug encontrado é culpa
do desenvolvedor
• Precisamos achar de quem é a culpa?
• Não
• Porque só se faz isso então?

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

43. O teste é responsabilidade
apenas do testador

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

45. O teste é responsabilidade apenas do
testador
UI
Integração
Unitário
UI
Integração
Unitário
Manuais
Manuais
VS

46. O teste é responsabilidade apenas do
testador
• TDD - Test Driven Development
• Programação em duplas

47. Todo mundo tem que testar!
• Todo mundo testa com diferentes visões.

48. O teste de sistema/funcional é o
mais importante

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

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

51. 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?

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

53. Faça testes que garantam o que você precisa !
• Tudo depende do que você precisa garantir para saber qual teste é
melhor para você.

54. Teste não-funcional não é
importante

55. Teste não-funcional não é importante
• Você sabe escrever um requisito não-funcional?
• Você sabe o que é um requisito não-funcional?

56. 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.”

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

58. Teste não-funcional não é importante
• Custo de conformidade inicial
• Custo de conformidade contínua

59. 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?

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

61. Ninguém tem esse nome tão
comprido!

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

63. Ninguém tem esse nome tão comprido!

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

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

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

67. 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)

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

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

70. Você não precisa saber
programar!

71. Você não precisa saber programar!
UI
Integração
Unitário
Manuais

72. Você não precisa saber programar!
UI
Integração
Unitário
UI
Integração
Unitário
Manuais
Manuais
VS

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

74. Você tem que saber programar sim!
• Saber banco de dados
• Saber programar
• Saber mexer com frameworks de testes

75. Testes são só custos

76. 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?

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

78. Sigam no twitter
• @thoughtworks_pt
• @eliasnogueira
• @qualister
• @c_caetano
• @gutsrs – canal no youtube também
• http://agiletesters.com.br/

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

80. Sites legais
• http://pt.slideshare.net/GTS-CE/
• http://eliasnogueira.com/
• http://bugs-busters.blogspot.com.br/
• http://pt.slideshare.net/stefanteixeira/

81. Dúvidas?
• about.me/liviagabos
• @liviagabos