Imagine you’re walking over to a colleague's desk, to ask a question, and they are there, but there’s this big book sitting on their desk and it looks like it gets used quite a lot. The spine is broken in a few places, the corners are all bent, and there's like two dozen bits of paper sticking out on top, and some of the sides. You look at the cover, and the title is something like "essential software testing strategies and practices for software developers, with examples in Python". You pick it up, and flip through it a bit. Looks pretty good actually. You go to the front of the book and flip through the first bit. You read the first line of the introduction and then skip to the table of contents. There's a bunch of stuff that you already know, some  you're familiar with, and then there is a bunch of things that you've heard of, but aren't exactly sure if you know what they really mean. You put it down and think, I should probably read that but I'm way too busy, wouldn't know where to start, and like who reads books anymore anyway? Well, this podcast is like that book, but you don't have to read it and it won't take much of your time, and you don't have to decide where to start, just follow along and ignore the stuff that you don't care about.

[music] Hello everyone. My name is Brian Okken, and welcome to the Python Test Podcast. For this first episode, I'm going to go through the front matter. That's all that junk at the beginning of the book, before chapter 1. Front matter can include stuff like who should read this book, the table of contents of course, you know, stuff like that. I don't have a book here, I've got a podcast, but I'm going to try and lay out what I'm shooting for in a similar manner.  So let's modify that list to: who should listen to this podcast, goals of the podcast, how we're going to deal with code examples, since this is audio, will there be guests or sponsors, how frequent will the show be, and what categories and topics will be covered. That's the table of contents things.

Ok so let's just run through those. First, who should listen to the podcast. If you work on software projects, this show is for you. This includes software developers, testers, managers, team leads, and others with titles I'm forgetting. Although I'm going to cover Python, most of the episodes will be useful to you regardless of what programming language you use. If you work on software projects, listening will be a good value for your time investments.

Ok, goals of the podcast. I have a dozen goals for This podcast that I'd like to run through. I know a dozen’s a lot. Hopefully they will go quick.

Number one. Promote the idea that strategically combining software testing and into the development process does not take more time. It makes shipping software faster, not slower. If it's slower you were doing it wrong.

Number two. Have learning a test framework be easy. That shouldn't be what's stopping you from testing.

Goal number three. Promote pytest for new projects. It's the easiest to learn and most powerful. I don't see why you choose something else if it's your choice.

Goal number four. It might not be your choice. You might be using nose or unit test, or something else. I will talk about unit test and nose,  because those are other things I know about, and  how to work round some of their limitations.

Goal number five. Promote functional, system and subcutaneous testing. I don't think they're used enough, or given enough attention, especially when teaching testing to developers. And unit testing has got enough flag wavers already.

Goal six. Get people to stop using the phrase units test when they mean automated test. They are different. Unit tests are a subset of automated testing.

Goal number seven. Introduce people to topics around software development and software testing. You really ought to know the difference between Agile, scrum, XP, lean, pragmatic, test first, TDD, BDD, ATDD,  foo, bar, baz, etc. Even if you aren't using them.

Goal number eight. Combine the good parts of agile, lean, BDD and TDD  into an effective mix that I'm calling lean TDD. I will talk more about that later.

Goal nine. Create a podcast series that can be used as a reference. I'm going to try to keep the episodes short and focussed on one topic. I'm thinking somewhere between 10 and 30 minutes. I'm not going to give you really long tutorials. This isn't the right format for that. Of course, if I bring in a guest it may run longer.

Goals ten through twelve. Now these last three are stretch goals. Number ten. Help put an end to war and poverty. Eleven. Align of the planets, and bring them into universal harmony. And 12. Allow meaningful contact with all forms of life, from extraterrestrials to common household pets.  Of course, these last ones are a real long shot, But Bill and Ted's music just hasn't been enough so far.

Alright next up. How am I going to deal with code examples, since this is audio? Well, I'm not going to read them, that would be silly. But I'm not going to shy away from code examples either. I read a lot of technical books and blogs, a lot of them about programming, and I really wish more of them had audio. I have more time to listen to podcasts and audiobooks that I have time to read. Take for example, Harry Percival’s book on TDD in Python. I have a copy, I read a few chapters, I liked it, and then I skipped ahead and read a couple of chapters in the middle. But I'm not a web developer, so I'm  really not going to read the whole thing. And I don't really care about the specifics of the code, but I do care about what Harry has to say about TDD, and the development process. So I wish I had an audio version. And when the narrator, even if it's not Harry, gets to the code parts, they can just say something like, hey there's some code here showing an example of blah. That’d be fine. If I really need the code, I will go get it. So, in this podcast when I need to talk about some specific code, I will just talk about it, and put the code example in the show notes, or at least link to it from the show notes. Those will most likely be at pythontesting.net/podcast.

Alright what's up next? Will there be guests? Yes. I'd like to bring in people to discuss stuff like how they use testing in their projects, and testing different types of things like maybe data models or, yes really anything, testing hardware, testing web things, people with different opinions than mine. I'm kind of opinionated, and I am sure that some people disagree with me. Let's get some of those people on. I do want to bring in some experts, but I also want to bring in some non-experts, everyday people that care about software quality, but don't consider themselves experts. And you, you have an opinion, you have experiences at work that we can all learn from. If you'd like to come on the show, or you know someone you'd like me to talk to you, let me know.

How about sponsors? Yes, probably. Well I don't know. Hopefully . that's the plan anyway. However, I don't have anybody lined up yet. If you'd like to sponsor the show, let me know. For now, the funding is coming from people who have purchased my eBook, which, you know, if you want to go and get a copy you can get it at pythontesting.net/book. Every sale makes my phone ding, makes me smile, and encourages me to keep doing this.

How frequent will the show be? Well, I haven't got to the topics yet, but I've got a lot to cover. It will take a long time if I only do one a week. So I'd really like to get more than one a week out. But don't hold your breath. I've got a full time job, and a family, and even though these episodes are short, they take a long time to prepare for. This will also depends largely on how well the show is received, and how successful I am at bringing in sponsors. So, I am not promising anything more than probably once a week, but I'd like to get it more frequent than that.

Alright, now here’s the table of contents, of sorts. Well, there’s my opinions, the mechanics of testing, testing concepts and strategies, software development methodologies, software development skills and best practices, and software testing in education and programming instruction, and lastly using Python test frameworks for non-Python projects. Ok, I'm going to run through these categories and describe them a bit better, and put some ideas for future episodes. And they definitely will not show up in the order that I'm going to read them. But hey, it's a plan.

So here goes. My opinions. Along with sharing lots of great and useful information, I will share my opinions. I'm not going to try to present these topics as a disinterested third party reporter. I'm a pretty opinionated guy, about just about everything. I'm hoping that including my opinions will actually do a couple of things. I'm hoping it will be therapeutic for me, I've got a lot to get off my chest. And I also think that it might make the discussion more interesting and maybe help you remember the topics better.

Next, mechanics of Testing. This is stuff like how pytest works, unittest, nose, how to set up test fixtures, test automation, results reporting, what exactly is the purpose of a reproduc-- or maybe not.

Let's see. The frameworks. I’ve written about all of these already. Actually, the introductory post for all three of these have been put together into an eBook that I now sell on pythontesting.net/book. Yeah, I definitely will talk about all of those, especially as I'm working through the rewrite. Also, I've just scratched the surface of pytest. It's quite powerful, while remaining elegant. Yes, I am a pytest fan. And there is a bunch of stuff I'd like to cover about using it effectively.

Next up, mechanics. Test fixtures, sharing resources across many tests, thinking of test fixtures as test resources, making sure that you understand the pytest fixture model, and how it's different from unit test and nose, Dealing with multiple fixtures, dealing with fixture failures, getting around some of the limitations in unit test and nose fixture models, combining module, class, and method level fixtures. Test automation and results reporting. So there is more than just pass and fail. There’s pass, fail, skip, error, xfail, xpass, how to take advantage of those. Alternative reporting methods and, alright, that's done with mechanics.

Some more test concepts. Oh I've got a long list. I'm going to read these really fast. Test case design, how to write tests to test a feature, what test cases do you need, black box, white box, grey box, the given-when-then model from BDD, partition testing, equivalence partitioning, boundary analysis,  developing mental models of a feature to help determine representative behaviours and representative test cases, using finite state machines to model behaviour, decision tables, behaviour coverage, code coverage, combinatorial testing, random testing, regression testing, stubs, mocks and simulations. How important is test speed, How important is readability? Readability is really important!  How important is repeatability? Using tests for QA, and using test for development, and how to integrate all of those. Yeah, all that would be good. Definitely got to get to all of that stuff.

Now, next up, software development methodologies. All this testing fits into a framework of getting software out of the door. Iterative development, agile software development, lean software development, Extreme Programming, scrum, test first programming, TDD and it's derivatives, Things like BDD, behaviour driven development, ATTD, Acceptance test driven development. There's probably more. I also -- since I learnt about agile and lean about the same time I was learning about Six Sigma, it ties together a bit, and it's not really test related but it's process improvement. I think it's a good thing to cover, I'd like to cover the DMAIC Model. The methodology we all love to hate is the waterfall model. I think we've got to cover it because there's a handful of people that may not understand exactly what it means. The three of you out there, you're welcome.

This next topic is a category of Software development skills and best practices. If you're writing automated tests, all of these apply to you. So, concepts: DRY, YAGNI, using good function names, refactoring practices, code stewardship, using revision control, proper use of code comments, text editors skills you need to figure out regardless of what you use, and some command line tools you should probably know. I'll probably come up with some other stuff we have to cover. You can help me out with that.

I am almost done, down to the end of the list. Next category, software testing in education and programming instruction. What I needed was the software testing stuff. I'm a developer with a CS degree, but I didn't learn any of my testing knowledge in school. Perhaps it’s taught now, I really hope it is, but I wasn't required to learn it for my degree. So, I figure there might be a bunch of other developers out there that missed out on some great testing techniques, that are kind of common in QA circles but not so common in the dev circles. I'd like to change that, if possible. I don't know how much influence I have, but hey.

Category, using Python test frameworks for non-Python projects. Of course we use Python for Python projects, but it's also used for testing quite a bit of other things, web services, embedded software written in C++ running inside of electronic test equipment that happens to be testing a cell phone, that's kind of personal to me. Really, anything that has an API that you can use from Python, you can test. I'd like to bring in guests for a lot of these discussions.

Wow, that's a lot. I'd better wrap this up so I can start working on all those promised future episodes. I hope you stick around, the show notes are at pythontesting.net/podcast. You can send comments, questions and suggestions via email using brian@pythontesting.net. All complaints can be sent to somethinglongthathasaq@pythontesting.net. That's really something I set up. I thought it was funny. I actually will read it. I think that's about it for now, thanks for listening.