Upgrade to Pro — share decks privately, control downloads, hide ads and more …

You Want Me to Test?!

Avatar for Bailey Hanna Bailey Hanna
September 24, 2019

You Want Me to Test?!

There’s a lot of discussion going on the software development world today about the incredible benefits of tester’s getting comfortable with code (reading it and writing it!) and about developers getting more comfortable with testing; but what is it really like to make that last shift within an organization and what does it really mean?

This talk will walk through how my team was able to shift testing in a way that the whole team was empowered to, and felt comfortable to, pick up QA tasks to increase our efficiency. We’ll go through how we identified the need for this shift, how we got the whole team on board, the process we took, and the outcomes we saw. I’ll also walk you through the challenges we faced and the lessons we learned along the way.

Key Takeaways:
- Understanding what it means and looks like for a whole team to be empowered to test
- Ways to get buy in (on your team and in your org) for non-testers to test
- Lessons learned by my team and advice for empowering your whole team to test

Avatar for Bailey Hanna

Bailey Hanna

September 24, 2019
Tweet

More Decks by Bailey Hanna

Other Decks in Technology

Transcript

  1. You Want Me to Test?! How our team shifted from

    a ‘Only testers can test’ mentality to everyone being willing to say ‘I’ll grab the next card in QA’ Targeting Quality 2019 @BaileyHanna
  2. What are we going to discuss today? ! My teams

    story ◦ Team/process background ◦ Proposed solution ◦ In practice ◦ What’s happening now ! Challenges faced in this change ! Lessons learned from it ! Q&A + Share your story!
  3. Team Process Developer works on code changes Card is ready

    for development (backlog) QA tests the change Product owner (re)defines requirements
  4. So what gaps/issues do we have? The symptoms ! Lots

    of looping back and rework ! Bottleneck of cards waiting in QA ! Everything had to be manually tested The root cause ! Over the wall process ! Large dev to test ratio for work ! Lack of understanding of what/how to test
  5. Proposed changes ! Redefine how we identify teams ! Involve

    the whole team in project decisions/meetings ! Empower the whole team to test ! Cut out the 3 day manual regression
  6. Changes for the Teams ! Testers are not the only

    ones who test ! Take on more of a coaching role ! Take the initiative to get involved in discussions, meetings etc to be a voice of quality in all aspects of the team life. Changes for the Testers ! Definition of team changed ◦ (Was previously dev team, test team, product team. Now we have teams comprised of all of those) ! Better understanding needed of each others roles ! Better communication required
  7. What wasn’t working? ! Low adoption rate ! Egos &

    attitudes interfering ! Not enough explanation of the why, just the how ! Prescribed change instead of natural change
  8. What did we do? ! Slowed our approach down !

    Found champions, focused on them ! Pair testing ! Asked more questions ! Invited ourselves to more meetings
  9. Before After Developer begins development Card is ready for development

    QA tests the change Product owner changes requirements Developer, Product Owner, QA, Design discuss project Individual card is ready for development Developer, Product Owner, QA discuss unclear reqs. Developer works on code change, QA assists from quality standpoint Team performs Exploratory Testing
  10. So what really changed? 1. We shifted testing the quality

    mindset left 1. We empowered the team to do Exploratory, Session Based Testing
  11. Challenges ! Old habits are hard to break ! Not

    everyone wants to change ! Team changes let us fall into old habits ! Prescribed change instead of suggesting or doing an experiment
  12. Lessons Learned ! Start with baby steps & champions !

    Make sure everyone has context ! Be ok with slow progress & failures ! Start with empathy and build from there