Elevator Pitch
Once Upon A Time in Software: Learning automation is a quest for valiant QAs. This talk gives you a road-map of how QAs get started, how developers can help, and why it’s a good idea. I’ll also talk about the end-of-level boss battle (giving/getting feedback), and how to safely walk into Mordor.
Description
Prologue: Once Upon A Time in Software
Once there was a project that was frustrating, it had lots of bugs and made the team unhappy. For the next project, we tried something new: the QA on the team would learn C# and she would write automated tests before the developers started coding. The team was happy, and the app runs to this day with only bugs caused by bad data the client told us could never exist.
The end. Or is it really… The Beginning?
This talk is the story of a learning quest, what I’ve discovered along the way teaching QAs to write test automation in Java, C#, and JavaScript, and my own journey of picking up new languages for fun, like Elixir. It is aimed at QA testers who want to broaden their testing skills, and at developers who want to help them get there. No prior coding knowledge is required for the QAs.
Notes
This topic is something I’ve been driving hard at WWT Asynchrony Labs, and we’ve seen big improvements in our software quality. I want to answer these questions:
As a QA, what do you gain from automation? Computers are great at performing automated checks to make sure the app does what it’s supposed to do, leaving you more time to make sure the app is NOT doing what it’s NOT supposed to do. Automation lets you stress and prod an app in new ways, and gives you a view of its internal workings that can guide your testing straight to the vulnerabilities
How do you teach people? There’s a road-map that I’ve used over the last four years with QA apprentices, automation boot-camps, and 1:1 teaching. You start simple and small, do it as test-driven development, and use pairing. I have battle-tested exercises to share that have helped people learn.
Why bother? We have developers for that. QA people learning to write test automation gives you benefits far beyond just having those tests. It helps cement team relationships, hugely improves opportunities for drive-by trolling of developers ;), and gives QA more understanding of how the application is put together. That improves knowledge of where the weak points could be, and how to better test. You also get better communication and more cross-role knowledge transfer, which makes better software.
Why feedback? Because you learn faster when you get useful, targeted, relevant feedback. I’ll briefly go over how to give and receive good feedback for the learning process.
Learning outcomes:
- QAs will know how automation can make your lives easier as testers
- Why automation gives you more scope to test, and provides leverage to increase your impact
- QAs will have a list of exercises to start exploring how to write tests in any language
- Developers will have a road-map for pairing with QAs to teach effectively (TDD, code reviews, questions to ask)
- People will have a framework for giving and receiving feedback that helps people improve (language specificity, facts not judgments, always be kind)
Agenda:
- Once Upon A Time in Software
- The Reluctant Hero: But I don’t want to be a developer!
- Your quest, should you choose to accept it: (This is how QAs get started)
- One does not simply walk into Mordor: (Taking the first steps)
- Power-ups, dragons, wizards, and gold: (How developers can teach)
- The end-of-level boss battle: (Good feedback and coaching to improve)
- Happily ever after, for everyone