This post was co-authored by Margie Kehr
—-Link to presentation recordings—-
I was really excited to get to attend the 2017 Quality Jam. The schedule boasted speakers like Keith Klain and Michael Bolton (no, not either one of those Michael Boltons) so I knew it was going to be informative and fun. Plus a REAL LIFE DISNEY IMAGINEER TESTER! I attended several talks on topics including automation, agile testing, testing careers, building testing teams, and rapid software testing. Here are a few of the points from the talks that stuck with me.
**“Modern Apps Need Modern Development Practices” by Jeff Hammond – Jeff talked about how the current software development industry really needs a different kind of mindset or culture to succeed. He highlighted four qualities/practices that he sees as necessary for an organization to flourish in today’s development world.
- Speed and recovery valued over perfection and control
- A collaborative learning culture
- Automation that enables the creativity of the testing team
- A goal of building data driven experiences for the users
While I felt proud to know that we have been working towards those four points at my workplace, there was another section of the talk I found especially inspiring. Almost everyone has heard of the Autonomy-Mastery-Purpose model of job satisfaction, but as Jeff spoke about it, I really began to wonder what that looks like for a tester. Is it any different than for a developer? What model do I use to determine if I have Mastery in my role?
**“Evolve or Die” by Mike Cooper – This talk was over building and growing your career as a tester. I really liked how he spoke about taking personal responsibility for your career growth by setting your own career goals and figuring out what skills you need to get there. He emphasized not neglecting the soft skills, which is something I feel we all often do as we focus our learning efforts on new tools and techniques.
Mike also talked about the impact testers have on their organizations. He said “it’s QA who leads ATDD, BDD, and CI/CD adoption.” I hear so many testers in the community talking about how these things will be the “death of testing”, but if that’s true then why are testers leading the charge? I think that this contradiction was really what was at the heart of his talk – testers who evolve and grow themselves will always have a place in the software development field.
**”How to Get Automation in Your Definition of Done” by Angie Jones – “Automation is feedback. Ask if you really want this feedback and how often you want it before you automate.” I’ve seen and heard a variation of this quote in almost every automation article or talk I’ve encountered, but I feel like it can’t be said enough. Other good advice from the talk included getting others involved when developing your automation plan such as product owners to get usage analytics and customer pain points, testers to help build scenarios, and developers to build an initial contract between the development and the automation. Finally, I really liked how she advocated an incremental approach to automation. Building “just enough” automation to support the rest of the development process prevents wasted effort – but you can only do that well with the collaboration of the whole development team. This talk was just further proof that quality is something everyone on the team owns, not just the testers! I asked her how she prefers to handle test data and she directed me to “Four Test Data Strategies” by Paul Merrill. It was an excellent and informative read/listen!
**”Debugging Your Test Team” by Keith Klain – I felt like Keith knew the questions I would have after Jeff Hammond’s talk about mastery and purpose for testers and designed his talk to revolve around how to answer them. He identified three statements that are signs that someone doesn’t have AMP in their role.
- “I don’t think deeply about my work.”
- “I don’t trust my team”
- “I don’t like testing”
I found all three of these very powerful – I feel like all the amazing testers I’ve seen have been critical thinkers who built solid relationships with their team and really loved what they did. Seeing that idea boiled down into those three sentences was a serious ah-ha moment. As a follow up on thinking critically about our work inspired by this talk, I wondered what our testing values are at my company? Are we all striving to uphold those values? What could we do to improve? Because as Keith said, “No one needs permission to do their job better.”
There were a number of great sessions at the Quality Jam conference, all providing new testing perspectives and insights. Aside from the highlights that Jasmin mentioned above, here are a few more takeaways for me…
Keynote: Josh Clark & Chuck Bryant | A History of Testing (And Things that Failed Spectacularly)
Josh and Chuck, from the award-winning podcast “Stuff You Should Know”, provided a hilarious account of products that failed miserably in the market due to either a complete lack of testing or overlooked testing all together. They talked about iSmell, developed by DigiScents in 2001, which cost $20 million in research & development to produce the prototype – a peripheral device that connected to a PC via USB, designed to emit smells of the internet. However, of their research, none of it was user testing, or market surveys, or proving consumer demand – turns out no one wanted to smell the internet! Another product Josh and Chuck mentioned was the E.T. Atari game and how the designer was asked to complete development within a very tight 5-week deadline for the 1982 holiday season. This of course did not leave room for testing and the game ended up being quite buggy (one bug being the player could fall into a pitfall loop) and ultimately a very poor gameplay experience. These examples make you wonder how successful these products could have been if the user testing phase had been more prominent. I believe iSmell would not have even made it to market, and the E.T. game could have been legendary (and not buried, literally).
Keynote: Michael Bolton | A Ridiculously Rapid Introduction to Rapid Software Testing
For anyone that has heard of Michael Bolton, James Bach, or Rapid Software Testing (RST), and wants to learn more – I would suggest watching Michael’s super duper rapid 50-minute intro to RST conference session. Michael notes that testing investigates risk and testers should focus on two main questions: Is there a problem? & Are we okay with this? He goes on to suggest that every tester should have their own model (be it HTSM or something else), and testing should be exploratory, not confirmatory. Machines can only check, while humans can do ALL THE THINGS (learn, explore, collaborate, infer, question, observe, study, etc). The main thing we should remember as testers is to be suspicious of the things we perceive and conceive while we test, and to always question our assumptions.
And with that, I will leave you with a quote from Michael Bolton:
“Testing is like the tale of Captain Jack Sparrow, pirate so brave on the seven seas…”
Oh wait, wrong guy… here’s the right quote from the right guy:
“Exploratory Testing is not so much a thing that you do; it’s far more a way that you think.”