Alison Hawke
QA Practice Lead/Agent of Chaos
Actions
I'm the director of quality advocacy for WWT, serving a team of over forty testers in five cities. My goal is to write code that breaks code to make a better product for the user. I train technical testers who can help a team release awesome products that make client's lives better. I've been in QA since 2005 and I love getting into the code to test more thoroughly. I've written test code in Java, C#, JavaScript, and I am currently learning Elixir. Outside work, I'm a black belt in Chinese Kenpo and have fun sparring every week. I knit a lot of hats. Originally from England.
Links
Topics
A Hero's Journey: Manual Tester to Automation QA
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 post-battle tavern-debrief of how to give good feedback, and how to safely walk into Mordor.
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.
As a QA, you will leave with reasons why automation can make you more awesome, steps to get started, and a list of exercises to work through.
As a developer, you will leave with ways to help testers start into automation, how to give good feedback, and why this will help your team deliver a better product.
Outline:
Once Upon A Time in Software (why you should try automation)
The Reluctant Hero: But I don't want to be a developer!
One does not simply walk into Mordor (QAs taking the first steps)
Power-ups, dragons, wizards, and gold (How developers can teach, exercises to start with)
The post-battle tavern-debrief (Good feedback and coaching to improve)
Happily ever after, for everyone
Building a QA practice from scratch
When you’re the only QA, how do you instill quality practices and build that mindset into the wider company? I'm going to walk through how we went from eight to forty-five quality advocates, and talk about recruiting, training, fun, multiple remote offices, delegation, velociraptor-avoidance techniques, staffing, blood, sweat, and tea. I’ll share the potholes we fell into so you can fall in different ones, and build a practice of awesome testers.
Building a QA practice requires buy-in from management and developers, and can mean changing the process to include up-front quality advocacy, instead of end-of-the-line quality control. Quality starts before the project is sold to the stakeholders, and it doesn't end until after the product is in the hands of the end users. Growing a practice means finding the right people to work with, and communicating well with clients, users, sales, management, and developers.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top