From Gatekeeper to Partner by Kelsey Shannahan
•Télécharger en tant que PPTX, PDF•
1 j'aime•254 vues
The document discusses moving from a "gatekeeper" model of testing, where testing is done separately after development, to a "partner" model where testing is integrated into development and shared responsibility of the team. It provides tips for making this transition, such as fixing problems developers experience with testing, integrating testing into development workflows, and helping testers contribute to other parts of development to become true partners. The overall message is that testing is most effective when it is easy to do and an inherent part of the development process done collaboratively by the entire team.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à From Gatekeeper to Partner by Kelsey Shannahan
Similaire à From Gatekeeper to Partner by Kelsey Shannahan (20)
Plus de QA or the Highway
Plus de QA or the Highway (20)
Dernier
Dernier (20)
From Gatekeeper to Partner by Kelsey Shannahan
- 1. FROM GATEKEEPER TO PARTNER Kelsey Shannahan
- 2. THE OBLIGATORY ABOUT ME ● Been in testing for 8 years I guess ● Sogeti Safelite Chemical Abstract Services ● Cohesion Grange ● CoverMyMeds ● Currently working in Elixir Come talk to me about it! ● Finished my MBA
- 3. THE TWO MODELS OF TESTING ● Gatekeeper Throw it over the wall ● Partner Shared responsibility
- 4. HOW I LEARNED TO TEST
- 5. HOW I LEARNED TO TEST
- 6. HOW I LEARNED TO TEST
- 7. THROW IT OVER THE WALL ● Slow Lot of back and forth Loss of context ● Stressful Work piles up Pre-release testing/bug fix marathons Bugs may not get fixed before a release ● Antagonistic QA vs. Devs
- 8. SHARED RESPONSIBILITY ● Everyone on the team owns testing Testing is part of development ● Fast turnaround No big pre-release push for testing ● Fewer bugs go to production Bugs are addressed before the work is done ● Better team dynamic QA is a resource instead of a blocker
- 9. THAT SOUNDS GREAT! ● Find out what hurts Identify problems the devs are having with testing and fix them ● Integrate testing into the development workflow Make it easy to do testing ● Learn and contribute to all work Actually be a partner to the team
- 10. FIX WHAT HURTS
- 11. SO I’M NEW TO THIS TEAM ● They were trying to test something ● It took hours ● It took specialized knowledge ● It took custom setup that was only useful once ● The problem wasn’t the desire to test - it was the ability So I built a thing to fix it.
- 12. FIX WHAT HURTS ● Find a problem that the team is experiencing RIGHT NOW with testing. ● Fix it. ● It’s great to talk about the benefits of testing… ● But what people really notice is something that fixes their problems right now. ● Creates buy-in.
- 13. FIX WHAT HURTS ● Identify Listen to what the complaints are Ask Shadow See where the delays are You may identify many problems - pick the biggest ● Solve This may involve building something It will be very situational Remember: you are not a test monkey If you leave, does the problem come back? Keep it simple and easy to maintain - we are removing work, not adding Devs and testing should use a common language Use simple concepts
- 14. FIX WHAT HURTS ● Implement Advocate What, how, time, gains “this will fix problem X” Design Include the team Get them invested into it Use their expertise Prioritize Don’t go off into a hole and do test things Build Everyone should know how this works
- 15. WE’VE NOW ESTABLISHED... ● Testing can make our lives easier ● You can solve their problems ● Credibility for you and testing
- 16. INTEGRATE
- 17. LET’S ESTABLISH SOMETHING... ● Developers don’t actually hate testing. Being the person that broke something feels terrible. We’ve all experienced broken code.
- 18. SO I BUILT THIS APP It’s cool. I didn’t write unit tests. I only tested the happiest of happy paths. Then I gave it to my friends to look at.
- 19. SO I BUILT THIS APP It’s saying “500 Internal Server Error”. What did you do? I clicked the button. Oh, you can click on things? I need the URL again.
- 20. LET’S ESTABLISH SOMETHING... ● Developers don’t actually hate testing. Being the person that broke something feels terrible. We’ve all experienced broken code. ● So why do people not test? It’s hard Badly designed Not maintained ● Basically, testing is about as much fun as running
- 21. TESTING IS LIKE RUNNING This is great! I got so much benefit out of this! Let’s keep doing it! This is stupid. I hate this. I never want to do it again.
- 22. OUR BASELINE IS: ● Developers know testing helps them ● Developers would like to do testing ● Sometimes things get in the way of that Our goal is: make testing part of the development process
- 23. INCLUDE TESTING ● Don’t have separate workflows It’s confusing It doesn’t work
- 24. INCLUDE TESTING ● Don’t have separate workflows It’s confusing It doesn’t work Backlog In Progress Test Done Card 1 Card 2
- 25. INCLUDE TESTING ● Don’t have separate workflows It’s confusing It doesn’t work Backlog In Progress Test Done Card 1 Testing for Card 2 Card 2
- 26. INCLUDE TESTING ● Don’t have separate workflows It’s confusing It doesn’t work Backlog In Progress Test Done Card 1 Testing for Card 2 Card 3 Card 2
- 27. INCLUDE TESTING ● Don’t have separate workflows It’s confusing It doesn’t work Backlog In Progress Done Card 1 Card 3 (Tester) Card 2 Card 2 (Tester)
- 28. INCLUDE TESTING ● Don’t have separate workflows It’s confusing It doesn’t work ● Put tests on cards Work isn’t done until testing is done
- 29. But what about testing?
- 30. MAKE TESTING EASY ● Testing processes should integrate into current workflows with minimal extra work No one likes extra effort ● Automate Shuffle as much as possible into unit tests
- 31. MAKE TESTING EASYEnd to End Integration Unit
- 32. MAKE TESTING EASYEnd to End Integration Unit
- 33. MAKE TESTING EASYEnd to End Integration Unit
- 34. MAKE TESTING EASY ● Testing processes should integrate into current workflows with minimal extra work No one likes extra effort ● Automate Shuffle as much as possible into unit tests ● Keep processes down to the important stuff - get rid of the junk Testing has a purpose - help us deliver code If it doesn’t benefit that purpose, don’t do it
- 35. COMMON PROBLEMS ● Hard to work with Working on convoluted test systems is a situation nobody wants to be in. The fix: make your systems easy to work with and fix bad code ● Test suites don’t work The fix: stay up on maintenance Re-evaluate or re-do flakey tests ● Too much complexity Don’t use tools that don’t add value We jettisoned Cucumber and Capybara ● All of this is stuff that makes developers not want to
- 36. THAT WAS A LOT OF STUFF ALL ROLLED IN TOGETHER ● Don’t segregate testing ● Make testing part of the work ● Make testing easy Automating Getting rid of what doesn’t provide value ● Address common barriers to testing Hard to work with Not maintained Too complex
- 37. CONTRIBUTE
- 38. MY SECRET IDENTITY Expert Tester on one card... Painfully Insecure Developer on another.
- 39. CONTRIBUTE ● Testing is on the board with the rest of the work ● This means some “test” work will be picked up by devs ● The lines are going to get blurry and this is scary. But it means there’s now more of you. ● Participate in design work and research Testers often have in-depth knowledge of the business and the app that can’t be learned except through experience Document! ● Remember: you’re an expert on testing. Share that expertise.
- 40. THE TESTING MINDSET ● Gatekeepers - run tests “I do all the testing.” ● Partners - make testing accessible “I make testing easier for everyone.”
- 41. WHAT DOES TESTING LOOK LIKE NOW? ● I promised to cover this in my abstract ● It’s a trick ● Testing looks much the same Unit tests Integration/functional tests End-to-end tests Risk analysis ● Everyone knows the benefits of testing and shares responsibility for ensuring it happens
- 42. IN CONCLUSION ● Gatekeeper vs. Partner ● Fix what hurts ● Integrate ● Contribute
- 43. #tooreal