Ep. 32 Exploring Quality Assurance with Peggy Sturman

Episode 32 – Exploring Quality Assurance with Peggy Sturman

In this episode we’ll be talking about the QA role on an agile team, skills and knowledge beneficial to this role, and how developers and QA can work together collaboratively.

Today we’re happy to welcome Peggy Sturman to the show. Peggy has been a long time listener and supporter of the show. We met her through our Slack channel where we often have discussions around technologies we’re learning, career and interview advice, and thoughts about the field in general. She has nearly two decades of Quality Assurance experience and is currently learning about software development and coding in her free time.

Welcome to the show Peggy! Is there anything else you’d like our listeners to know about you?


“‘Sharpening the Tools’ is the section of the show where we discuss what tools we’re using, concepts we’re learning, and generally how we are continuing our learning in software development.”


  1. If you were to describe Quality Assurance in an elevator pitch, how would you describe it?
    1. Quality Assessment, trying to break the application
  2. Did you have any formal education to prepare you for working in QA? If so, did you feel adequately prepared for your first QA role?
  3. Can you take us through a typical day as a QA Engineer?
  4. What technologies and tools do you use?
  5. What’s the structure at your job? Are you doing QA for multiple teams / projects?
  6. What allows your team members/software developers to help you do you your job effectively?
  7. You’ve talked about learning to code in your free time, what languages and frameworks are you learning? How are they coming along?
  8. Do you feel that your QA experience helps when learning code, and / or does learning code help with your QA role?
    1. Black box testing – also known as Behavioral Testing, is a software testing method in which the internal structure/design/implementation of the item being tested is not known to the tester. These tests can be functional or non-functional, though usually functional. http://softwaretestingfundamentals.com/black-box-testing/
    2. Smoke testing – also known as “Build Verification Testing”, is a type of software testing that comprises of a non-exhaustive set of tests that aim at ensuring that the most important functions work. The result of this testing is used to decide if a build is stable enough to proceed with further testing. http://softwaretestingfundamentals.com/smoke-testing/
    3. Regression testing – s the process of testing changes to computer programs to make sure that the older programming still works with the new changes. Regression testing is a normal part of the program development process and, in larger companies, is done by code testing specialists. https://searchsoftwarequality.techtarget.com/definition/regression-testing
  9. What would you tell someone interested in learning about or exploring Quality Assurance? Are there certifications you can get? Recommended resources?
    1. https://www.ministryoftesting.com/
  10. What’s something you wish you knew before starting this role?


Peggy’s LinkedIn: https://www.linkedin.com/in/psturman/




Extra Links


You can reach us at helloworld@juniordevelopertoolbox.com

Facebook: Junior Developer Toolbox

Twitter: @JrDevToolbox

Instagram: JuniorDeveloperToolbox




Posted by Junior Developer

1 comment

I found this episode quite interesting as I am currently working in QA. I have been trying to get into development for quite some time now, and because of various circumstances I have been unable so far. In one position, hired into IT with the hopes of moving to dev, and got laid off. Another job, I started as a liaison between users and devs, and the goal was to work into dev in 4-6 months, but that bank sold to another bank, the second bank sold our small division, and the third bank reorganized several of us out of jobs.

At this point, I was hired as support, but about 90% of what I do is software QA, and I’m awaiting a developer opening. I’ve been here for a year now, and our development manager as well as a couple of the devs have commented that they appreciate having someone in QA who knows code well enough to dig into it and find where the problem is, and if I have time, ocassionally getting right down to root cause of a bug. I was actually rather surprised when the manager told me that most QA people aren’t technical – at least not technical to the point of reading code.

Thanks for the podcast, and keep it up!

Leave a Reply