Testers and Coders - Blurring the Lines
•Download as PPTX, PDF•
0 likes•227 views
Coders are writing tests and testers are writing code. This seemingly paradoxical truth is becoming more and more prevalent in companies of every size. But coders and testers still have very different cultures and processes and are actually sharing very little knowledge, even in companies that have supposedly taken down the wall between the disciplines. In this talk, we explore the increasingly blurry lines, discuss some of the differences in the approaches coders and testers bring to the table, and provide practical examples of lessons learned by sharing knowledge, cultural perspectives and evolved wisdom.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Testers and Coders - Blurring the Lines
Similar to Testers and Coders - Blurring the Lines (20)
More from Noam Kfir
More from Noam Kfir (14)
Recently uploaded
Recently uploaded (20)
Testers and Coders - Blurring the Lines
- 1. TESTERS AND CODERS: BLURRING THE LINES Noam Kfir Consultant & Trainer noam@kfir.cc | http://noam.kfir.cc | @NoamKfir
- 2. NOAM KFIR • Consultant and Trainer • Telerik Developer Expert • Ranorex Professional • ISTQB Reviewer • Agile Practitioners Meetup Co-organizer • Specialize in test automation for both testers and coders • Ranorex, Selenium… • TDD, BDD, Unit & Integration Testing… • JavaScript, C#…
- 3. TESTERS AND CODERS MUST LEARN FROM EACH OTHER
- 4. BULWORTH a little warning about language
- 7. MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. http://agilemanifesto.org/
- 8. AGILE PROGRAMINĖS ĮRANGOS KŪRIMO MANIFESTAS Kurdami programinę įrangą ir padėdami ją kurti kitiems, mes randame geresnius būdus tai daryti. Dirbdami mes vertiname: Žmones ir jų bendravimą labiau nei procesus ir įrankius Veikiančią programinę įrangą labiau nei išsamią dokumentaciją Bendradarbiavimą su klientu labiau nei derybas dėl kontraktų Reagavimą į pokyčius labiau nei plano vykdymą Be abejo, teiginiai dešinėje svarbūs, tačiau mes labiau vertiname teiginius kairėje. http://agilemanifesto.org/iso/lt/manifesto.html
- 9. PRINCIPLES BEHIND THE AGILE MANIFESTO 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. http://agilemanifesto.org/principles.html
- 10. QUALITY WE’RE MISSING SOMETHING… Why do we need Agile to begin with?
- 12. ROLES & RESPONSIBILITIES WE’RE MISSING SOMETHING ELSE… It’s a bit more subtle…
- 13. ROLES & RESPONSIBILITIES we customers business people developers individuals teams sponsors users
- 14. THE CHICKEN AND THE PIG A Pig and a Chicken are walking down the road. Chicken: Hey Pig, I was thinking we should open a restaurant! Pig: Hm, maybe, what would we call it? Chicken: How about 'ham-n-eggs'? Pig: No thanks. I'd be committed, but you'd only be involved. https://en.wikipedia.org/wiki/The_Chicken_and_the_Pig
- 15. WE ARE ALL DEVELOPERS Programmers (Coders) Quality Professionals (Testers) Designers Architects Product Managers Support 😎
- 16. DEVELOPERS == PROGRAMMERS • Everybody else is just support • Reflected in culture, salaries, work conditions, growth potential, personal relations, etc. • Do you participate in every important meeting: spec, planning, daily…? • Fight entrenched perceptions • Do not use “developers” as an eponym
- 17. TAKE DOWN THE WALL • Between coding and testing teams • And within cross-functional teams • Focus on “individuals and interactions” and “face-to-face conversations” • Be kind, insistent and professional, not aggressive • The organization is a facilitator for change • Responsible for culture, work conditions, personal mindsets, involvement… • Change your place of work…
- 19. THE ANNOYING BUGGER PARADIGM • Testers seen as incompetent • Unexpected environments and configurations considered improper usage • Trivial issues considered pedantic, annoying, critical or even insulting • Testers faulted for “no repros” – their inability to reproduce bugs • Testers considered solely responsible for bugs Annoying Bugger incompetent
- 20. THE OUT IN THE COLD PARADIGM • Testers generally seen as nonessential • Not “builders”, so can’t contribute much • Can never reach full coverage, so collaboration considered wasteful • Insightful feedback reported as defects often ignored • Testing seen as mundane and repetitive, lacking creativity • Often unappreciated and regarded as insignificant and unskilled Out in the Cold nonessential
- 21. THE NECESSARY EVIL PARADIGM • Testers seen as gatekeepers, a safety net, a necessary evil • Often seen as the last line of defense, and become the only line of defense • Responsible for the impossible feat of catching every bug before it gets to production… and inevitably ruins the company • Sign-offs may entail repercussions • Don’t want them, but can’t live without them… Necessary Evil lone gatekeeper
- 22. PARADIGM SHIFTS
- 23. ANNOYING BUGGER REVISITED • Testers accepted as quality experts • Bugs reported and evaluated by consensus • The team tracks down “no repros” together • Testers share authority and collaborate with coders and other team members Annoying Bugger incompetent quality expert
- 24. OUT IN THE COLD REVISITED • Testers accepted as active collaborators • Quality perspective expected in every meeting • Feedback given face-to-face • Prioritized coverage preferred to full coverage as system evolves • Reliance on automation and tooling grows • Testing recognized as creative, challenging and essential Out in the Cold nonessential active collaborator
- 25. NECESSARY EVIL REVISITED • Testers accepted as full-fledged team members • Testers are no longer lone gatekeepers • The “last link” in the chain no longer blamed for everybody else’s failures • Everybody takes responsibility together • Safety net provided by proper planning, tools and collaboration • Automation and reflection replace sign-offs and repercussions Necessary Evil lone gatekeeper team member
- 26. TESTERS ARE DEVELOPERS Annoying Bugger incompetent quality expert Out in the Cold nonessential active collaborator Necessary Evil lone gatekeeper team member
- 27. EVOLUTION Agile testing is finally catching up with Agile programming
- 28. CONVERGING ROLES Coders are writing tests Testers are writing
- 29. MANY PARALLELS AND SIMILARITIES • Reliance on tests • Iterative work patterns • Focus on preventing regressions • Verifying correctness • … • Solving problems • Creativity • Satisfaction
- 30. NOT ENOUGH SHARING • Coders and testers both have rich tomes of knowledge • Each has its own culture, educational material, best practices, heroes, career paths, tools, humor… • They are slowly converging, but not benefitting from each other’s maturity
- 31. INEFFECTIVE CONVERGENCE Coders are writing poor tests Testers are writing poor code
- 32. CODERS MUST IMPROVE THEIR TESTING SKILLS
- 33. SOME SYMPTOMS Overlapping tests Wholes in coverage Only one or two types of test Missing boundary value tests Unhandled exceptions Swallowed exceptions No repros Consistent difficulty debugging Obvious use cases untested All tests in one file Legacy code black holes High cyclomatic complexity
- 34. TESTING SKILLS Boundary analysis and equivalence partitioning Test design techniques Exploratory testing Assessing risk and prioritizing tests
- 35. TESTERS MUST IMPROVE THEIR CODING SKILLS
- 36. SOME SYMPTOMS Scripts Magic strings Buggy test code Unreadable code Not reusable Purely imperative Parameterless functions One test machine Different languages Lack of structure Require intervention No modularity
- 37. CODING SKILLS Apply SOLID principles and design patterns Refactor (safely!) Write atomic, resilient maintainable tests Be lazy (in a good way…)
- 38. ELIMINATE PROGRAMMERS AND TESTERS We need a voluntary free-spirited open-ended program of procreative racial deconstructionMetaphorically…
- 39. DECONSTRUCTING CULTURE Take down the wall All pigs are developers Break the dissonance paradigms • quality experts, active collaborators, team members
- 40. DECONSTRUCTING COLLABORATION Motivate individuals to take ownership of expertise • Let individuals self-select areas of expertise Build up cross-functional and self-organizing teams Encourage face-to-face conversations
- 41. DECONSTRUCTING SKILLS Train all developers together • On an ongoing basis Share knowledge and skills across professional boundaries • Teach the rudiments of each role to all developers Encourage pairing as needed • To solve problems and to train
- 42. QUALITY IS A SHARED RESPONSIBILITY! Specialization Collaboration Common ground
- 43. QUESTIONS? Testers and Coders: Blurring the Lines Noam Kfir Consultant & Trainer noam@kfir.cc | http://noam.kfir.cc | @NoamKfir