Construindo bons relacionamentos entre desenvolvedores e testadores
Transferir como PPTX, PDF4 gostaram1,056 visualizações
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,
Construindo bons relacionamentos entre desenvolvedores e testadores
- 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
- 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)