1) O documento discute como construir bons relacionamentos entre desenvolvedores e testadores, propondo seis pontos principais: trabalho em equipe, comunicação, adaptação à mudança, qualidade como responsabilidade de todos, cuidado ao relatar erros e não se apegar a erros. 2) É descrito o "desenvolvedor mediano" e o "tester mediano", que trabalham isolados e se culpam mutuamente, resultando em atrasos e bugs. 3) O "profissional super" é aquele que se comunica bem, entende o cliente,

1. Construindo bons relacionamentos
entre Desenvolvedores e
Testadores
1
Thomas Paula - @tsp_thomas
Gabriel Oliveira - @gpaoliveira

2. 2
Thomas Paula
Software Engineer @HP
• Developer desde 2012
• Feevale
• Pós em Engenharia de Software (Labex)
• Mestrando em Ciência da Computação
Gabriel Oliveira
Test Engineer @HP
• Tester desde 2011
• UFRGS
• Ex-Dev C/C++/C#
• Ex-Analista de Teste de Performance
Quem somos nós?

3. O que temos para hoje?
• Ciclo de desenvolvimento
• O Dev e o Tester “medianos”
• Problemas >.<
• Soluções :D
• O “super” profissional
• Perguntas ?
3

4. Era uma vez... um requisito!
4

5. Development
Testing
5

6. Se o software funciona
assim porquê a
documentação diz ao
contrário ?
???
???
Development
Testing
6

7. Que DOM horrível ? Não
dá pra automatizar teste
dessa forma !
???
???
Development
Testing
7

8. Não tem como
automatizar isso - vai
precisar de um trabalho
de refactor
???
???
Development
Testing
8

9. Por quê esse cenário não
foi testado ?
???
???
Development
Testing
9

10. Por quê esse cenário não
foi desenvolvido ?
???
???
Development
Testing
10

11. O nosso framework
deveria suportar essa
funcionalidade !
???
???
???
Development
Testing
11

12. 12
Resultado?
Entregas do projeto atrasam
Requisitos não atendem às
expectativas do cliente
Bugs, bugs e mais bugs!
Tester diz que o dev não
desenvolveu direito
Dev diz que o tester não testou
corretamente

13. “Isso ai é uma feature e não um bug!”
Developer, Qualquer
13

14. O desenvolvedor “mediano”
14
Somente desenvolve
Testar pra quê ? Documentar por quê?
Trabalha sozinho, isolado de tudo e de todos
Afinal, criar software exige concentração (e café!)
Entrega o máximo de requisitos possível
Mesmo que outras equipes não estejam prontas
Acredita fielmente que seu código não tem bugs
Ai daquele que disser ao contrário!

15. “Se o software funciona é mérito do
desenvolvedor. Se não funciona, é
culpa do tester”
Tester, #chateado com a vida
15

16. O tester “mediano”
16
Somente testa
Detesta programar
Quanto menos linhas de código por dia, melhor (de
preferência, 0 por mês)
Espera o desenvolvimento terminar para
começar a testar
Afinal, se não tá estável eu nem olho!
Não fala com o desenvolvedor
Para isso existem os relatórios de bug oras?!

17. 17
O que fazer para resolver?

18. #1: Teamwork, teamwork, teamwork!
18
Trabalhar juntos desde o início
do processo
Definir objetivos individuais e
conjuntos
Requisito é considerado pronto
quando desenvolvido e testado

19. #2: Comunicação
19
Leve diferentes pontos de vista
em consideração

20. #2: Comunicação
20
Leve diferentes pontos de vista
em consideração
Seja claro na sua intenção

21. #2: Comunicação
21
Leve diferentes pontos de vista
em consideração
Seja claro na sua intenção
Use uma linguagem próxima do
seu interlocutor

22. #2: Comunicação
22
Leve diferentes pontos de vista
em consideração
Seja claro na sua intenção
Use uma linguagem próxima do
seu interlocutor
Coordenação
Se algo mudou, avise a todos

23. #3: Mudança é inevitável: conviva com ela
23
Mudança nunca é fácil

24. #3: Mudança é inevitável: conviva com ela
24
Mudança nunca é fácil
Adaptar-se não é algo opcional

25. #3: Mudança é inevitável: conviva com ela
25
Mudança nunca é fácil
Adaptar-se não é algo opcional
Tudo se resume a escolhas

26. #4: Qualidade é algo que a equipe toda
constrói e não somente os testadores
26
Tarefa pronta deve envolver
testes!
Refatore o código
E denovo, e denovo e denovo...

27. #4: Qualidade é algo que a equipe toda
constrói e não somente os testadores
27
Tarefa pronta deve envolver
testes!
Todos precisam pensar
Testers e Developers
Refatore o código
E denovo, e denovo e denovo...

28. #4: Qualidade é algo que a equipe toda
constrói e não somente os testadores
28
Tarefa pronta deve envolver
testes!
Todos precisam pensar
Testers e Developers
Nem só os testadores podem ser
bons questionadores
Refatore o código
E denovo, e denovo e denovo...

29. #5: Bug no código dos outros não é
refresco: cuidado ao relatar bugs
29
Não se torne o vilão

30. #5: Bug no código dos outros não é
refresco: cuidado ao relatar bugs
30
Não se torne o vilão
Reportar um bug deve ser uma
crítica ao produto/problema
Não a pessoa

31. #6: Pratique o desapego: um bug no seu
código não é atestado de incompetência!
31
O código que você escreveu não
é seu: é de todos

32. #6: Pratique o desapego: um bug no seu
código não é atestado de incompetência!
32
O código que você escreveu não
é seu: é de todos
Um bug no código é como uma
sujeira no apartamento coletivo
Todos devem ajudar a “limpar”

33. #6: Pratique o desapego: um bug no seu
código não é atestado de incompetência!
33
O código que você escreveu não
é seu: é de todos
Um bug no código é como uma
sujeira no apartamento coletivo
Todos devem ajudar a “limpar”
Profissionais são humanos
Humanos falham

34. Como construir um bom relacionamento
entre desenvolvedores e testadores?
34
ACME

35. Como construir um bom relacionamento
entre desenvolvedores e testadores?
35
#1: Teamwork, teamwork,
teamwork!
#2: Comunicação: se algo
mudou, avise a todos
#3: Mudança é inevitável:
conviva com ela
#4: Qualidade é algo que a
equipe toda constrói e não
somente os testadores
#5: Bug no código dos outros
não é refresco: cuidado ao
relatar bugs
#6: Pratique o desapego: um
bug no seu código não é
atestado de incompetência

36. O “super” profissional
36
Comunica-se com clareza
Com a própria equipe e com os clientes internos
Saber trabalhar em equipe
Principalmente, em parceria com outros papéis
Procurar entender a necessidade do cliente
Muito mais do que entregar pilhas de requisitos,
entrega valor e adapta-se ao contexto
Entender que a construção do software é
colaborativa
Depende de todos para atingir os resultados

37. O “super” profissional
37
Pensar no todo (Big Picture Thinking)
Seja parceiro do cliente na construção do sistema
Dar ideias e defendê-las
Não ter receio de defender seu ponto de vista
Ser crítico
De uma forma construtiva
Compartilhar conhecimento
"Ninguém é tão sábio que não tenha algo para aprender e nem
tão tolo que não tenha algo para ensinar.“ (Blaise Pascal)

38. 38
Thomas Paula
@tsp_thomas
tsp.thomas@gmail.com
Gabriel Oliveira
@gpaoliveira
gabriel.pa.oliveira@gmail.com
Muito obrigado!