Tips To Become A Better QE: Lessons From The Trenches

What makes a Quality Engineer better than others Quality Engineers? What are the skills and required Modus Operandi that sets really good Quality Engineers apart from their peers? You've seen them, you may even have one of them working on your team! I'm talking about the Elite QE member that seems to know all the tricks and tips on how to handle pretty much every single task thrown their way without a bat of an eye! They are the ones that somehow seem to know the answer to pretty much everything that is going around and somehow find the time to not only do their job, but do it really well! Would you like to be part of this Elite Team? Do you wish you knew the secret to their 'powers'? Well, now you can! In the talk I will reveal and explain how you too can become a Super Quality Engineer! Based on real world experience and well tested methods, I will show you how to expertly create issue reports, how to perform data mining and derive useful information from customer cases, how to become the "Go To" person for your project, and how to stop trusting your gut and start using REAL DATA to make REAL, LOGICAL DECISIONS! Whether you just started working in the field of Quality Engineering or are a seasoned veteran, this talk will provide you valuable information that will help you map your career and guide you to become a Better Quality Engineer!

Transcript

1. Tips To Become A Better QE Lessons From The Trenches Og Maciel <omaciel@redhat.com>
2. Name: Og Maciel Work: Red Hat Job: Manager, Quality Engineering Social: • Twitter: @OgMaciel • Github: omaciel
3. The problem Afterthought • Not every company or project has a dedicated QE team. • Usually starts as an afterthought, especially when first customers start reporting issues Pushing Buttons • QE == pushing buttons • “No real value added” • Must follow “recipe” from others • No room for creativity Starts Late • Starts only after DEV freeze • No room for collaboration early on
4. Quality Early, Quality Often Planning Contribute Early Provide constructive feedback early, based on experience with product and customer knowledge. TWO-WAY street! Development Provide Feedback Propose use cases and explore areas outside the ‘happy path’. Automate as much as possible! It is still a TWO-WAY street. Testing Test, Test, Test If you have automated it, use it! If not, consider doing it! Do exploratory testing too!
5. Solution Become a Super Quality Engineer! Quality Engineering. We do Precision Guess Work Based on Unreliable Data Provided by Those of Questionable Knowledge
6. Tip #1: Get The “Basics” Down to a Science
7. Write Awesome Reports • Be clear and concise • Provide context and background • Write clear, well tested steps to reproduce the issue • List of packages, build number, OS, web browser versions • Include logs • Include screenshots/videos • Do some leg work • Submit a patch!!! • Example: BZ 1387382
8. Follow Up • Set up ‘reminders’ • ‘Check in’ and provide more relevant feedback after the original issue discovery • Schedule a quick meeting (if needed) • Offer a system where folks can do forensics • Don’t take ‘No’ for an answer • Offer to test patches
9. Wrap It Up • Provide clear steps as to how issue was resolved • Include scripts used (if any) • Include screenshots/videos • Write down what the solution was :)
10. Tip #2: Walk The Extra Mile
11. Extra Mile • Gather all facts • Fill in gaps • Do the leg work • Provide feedback • Follow up
16. Tip #3: Sign Up For Commit Notification
17. • Follow all commits • Build up knowledge of changes to product • Find patterns • Warn of potential conflicts and pitfalls • Provide feedback • Raise concerns early
18. Tip #4: Do Bug Triage
19. Tip #5: Do NOT Trust Your Gut
20. Use Data • You cannot quantify “gut” • Numbers don’t lie! • You cannot argue against real data • It is easier to make logical decisions • Use Bugzilla and customer data trends • Find the tree from the forest • Report your findings (show the data!)
21. Tip #6: You Are Customer #1
22. Customer #1 • Make no assumptions (use the docs) • No shortcuts allowed (No Buts, No Cuts, No Coconuts!) • Beware of usability pain points • Don’t be afraid to explore • If it hurts, let people know about it (provide feedback!)
23. Tip #7: The Customer Is (Mostly) Always Right
24. The Customer • Learn about customer pain points • Correlate it with bug reports • Find trends and collect data • Propose testing strategy (increase customer satisfaction) • Know when/how to turn down RFEs • Deliver quality!
25. Tip #8: Don’t Be The Gatekeeper
26. Gatekeeper • Controversial point • Aim to educate and warn of risks (use data!) • Propose alternative strategies • Show the data • Team decision, NOT QE decision!
27. Tip #9: Find Smart People
28. Smart People • Nobody is an island • Learn from others ◦ Developers ◦ Support ◦ Documentation • Sharpen your saw • Share what you know • Feedback is a gift!
29. Tip #10: Quality Is Free
30. Q & A max growth
31. Thank You Speaker Deck: https://speakerdeck.com/omaciel/tips-to-be come-a-better-qe-lessons-from-the-trenches /