Everything I’ve learned about podcasting (before recording my first episode)

So if you’ve been following me on twitter recently you’ll see I’ve been getting ready to launch a podcast: Lets Talk About Tests, Baby (title courtesy of Mark).

I’ve been a fan of podcasts for a while, gradually adding to my library (22 in total, 19 of those listened to as soon as the new eps are released, the others as and when I’m in the mood for them).

I had guessed there was a lot to juggle when making a podcast, but I figured most of it was around content and editing (and I imagine this is actually the case), but there’s so much admin to do beforehand that I hadn’t really thought about:

  • A website: First port of call, really. Incidentally, I have an actual domain name courtesy of a friend, Mike, and so I will be getting the site on a custom domain at some point.
  • Podcast hosting: Most places I know use libsyn, as it does all the xml and rss feeds for you, and doesn’t charge for downloads, which is nifty. It’s pretty cheap, too.
  • Various accounts: email, twitter, iTunes, Soundcloud
  • Logo: To get a podcast on iTunes you have to have a logo, so you need a logo for a podcast. Thankfully a wonderful friend, Katie, is making one for me, so I don’t have to worry about trying to be creative there 😛
  • Intros, Outros, Stingers: I need some branding here. The words are easy, but the music is a different matter. Thankfully there is plenty of Creative Commons music and communities out there, offering music for free.
  • Content: I’ve started GDocs of episode ideas, show notes, etc. I’ve got a prequel ep and two full eps planned out, plus ideas and titles for 6 more, so that’s not too worrying.
  • Features: I’m hoping to be able to get a but/quirk/etc of the week going, so I need to start gathering them (submissions welcome!), recording them, and getting them into shows.

This is before I’ve even looked at editing and microphones. I’m going to do a brief recording on Tuesday to see what I can do with what I’ve got, and fingers crossed that should be good enough quality to put out there. I’ve done some editing before, but not with GarageBand, so I’ll be giving myself a crash course in that very soon.

This has been a unordered list of things I’ve realised I needed to do over the past two weeks or so. I’m feeling very nervous about putting speech to microphone and actually releasing this stuff into the world, but very excited as well. I only hope I live up to my own excitement and the tons of help I’ve got from my friends and colleagues.

You’ll be hearing from me very soon 😀 😀

It’s Scrum, Jim, but not as we know it (or: The role of QA/Testing in Scrum)

I gave a talk at Manchester Tech Nights about the role of QA in Scrum, and I decided to use this opportunity to write a blog post!

Software QA is a bit of a balancing act. Firstly there’s no immediate profit from our role the way there is for devs, designers, etc. Secondly, there’s the fact that there is going to be a contentious relationship between devs and QA. As much as devs will like having QA on their projects, there’s still the fact that no one likes having their work sent back to them with a ‘nope, you did this wrong/missed this. Try again.’ (Pro-tip, do not send notes like that to your dev teammates, they will hate you. Diplomacy, yo).

Which is one of the reasons I love working with Scrum the way we do. Firstly, being present right at the start of the project (instead of getting a site once its mostly built), is wonderful, both in terms of team building and QA.


First, a quick intro to Scrum:

  • Work broken down into sprints of 1-4 weeks depending on project size
  • Sprint planning meetings to decide what work to do in that sprint
  • Daily scrum meetings to give updates
  • Each sprint tackles some of the user stories

User Stories

So, requirements capture happens at the start of the project, this is then broken down into User Stories, with a business case.

As an Audience Member I want to be able to select a date from a datepicker so that I can quickly and accurately choose a specific date.

Acceptance Criteria

Scenario: Use a date popup calendar
Given I am an Audience Member
And there is a webform with a date component
And the date component has a popup calendar enabled
When I view the date field
Then I see a calendar icon next to the field
When I select the calendar icon
Then I see a calendar widget

You see how the story is broken down exactly, into a checklist of sorts for exactly what happens, when, and for whom.

The lead dev (in our case) then breaks those down into Acceptance Criteria. Acceptance Criteria provide boundaries and specifics for each User Story, so everyone knows exactly what this User Story encompasses and what the work entails.

Then, the lead dev and QA have to agree on these Acceptance Criteria. This means QA can flex their natural awkwardness to make sure all angles have been considered.

When both the lead dev and QA agree, the Acceptance Criteria goes to the client for approval. This means most of the awkward questions about how and why and ‘what about x?’ happen here, before any work happens. It means we can make better suggestions as we have a clear idea on what the client wants, when its much easier to fix.

After this approval process has been completed, work starts. Changes made after this point have to go through the approval process again.


This procedure means QA have a test case made against which work will be tested. If work meets the Acceptance Criteria, in theory, it’s ready to go (obviously judgement it used here). The tests can also be used for automatic regression testing.

It also provides a much higher quality of work. Devs have more insight and can offer suggestions to how to meet the client’s needs before work starts.

It encourages better buy-in from the client. They have to engage more in order to get the work going, which means they have to think about their needs as well.

Incidentally this also makes onboarding new staff easier – all the stories are already defined pretty narrowly, the process is defined so explaining it is relatively simple.

This method may seem cumbersome, but it doesn’t take up as much time as you’d think, and in the end, you get a collaborative project (both dev team and client), with every team member engaging to provide the best work possible.

It’s hard work, but its worth it.


On getting better

I wanted to talk about getting better. Because I am getting better, and that’s something that I need to bear in mind when I stumble and avoid doing something because it makes me heavy with dread and inactivity.

I remember that I can see and name the types of disordered thinking I’m doing. That I can stop the cycle of those thoughts and try to get myself onto something more constructive. That I don’t actually lose days of my life on the sofa, physically unable to move with the weight of it all.

The fact that getting better doesn’t necessarily mean ‘fixed’ is something that I’ve been thinking about a lot recently (this was going to be a blog post for Geek Mental Help week but it didn’t come together in time).

I manage my anxiety best I can, and most days I do this pretty well, but I’m not ‘cured’. And that’s ok, I have a toolbox that I can dive into when I need to, and I have a few signs of impending doom that I am aware of, and even if I don’t instantly know what to do, being mindful of these in and of itself can help with cutting things off at the pass. I’m not sure this will ever not be a thing that affects me, but its getting to the point where its not exhausting.

I still have days where I’ll put innocuous things off and it takes all my will and my therapist’s voice in my head talking about the anxiety cycle to do them. I try not to beat myself up too much about this, as it won’t help, but I try to take a mental note of what happened and why I was anxious for future use.

I’m not entirely sure how to end this post. I hope it comes across as hopeful as I wanted it to be. My anxiety and depression lies to me often, and during my therapy there were some times where it was fighting it, like I sub-consciously didn’t want to get better. I’m pretty sure that it was just because of all the hard work, but the result was the same. A Gollum like protection of my depression and anxiety, so admitting that, while I’ll always have it with me, its something that doesn’t take up all of my life is pretty amazing, to me.

On new jobs

I’m starting a new job next week! My new job title will be Outreach and QA technician, and I’m very excited. The company I’m working for will be Igniso, specifically on their Wavestreaming product.

I’ve been getting to grips with the product over the past week, and will be doing so more during this week off between jobs. The product works really well – even on my old Windows laptop with a broken fan. I tried using my linux laptop but for some reason Broadcast Using This Tool refuses to work on my copy of Mint. But I’m very impressed by the fact that my old laptop can handle it well, once I got winamp and the plugin downloaded.

They have a system for steaming from the dashboard (Cloud DJ) as well, which can be live or a playlist. I wish I had a microphone so I could have a play with this as it sounds awesome, but alas, I don’t have access to a mike at all.

My next bit is looking at the site itself to see how user friendly it all is and looking at the help section.

Its going to be a challenging role. I’ve done outreach before, mainly for Manchester Girl Geeks, which is a fantastic org that I volunteer for, and I’m looking forward to bringing those skills to a professional setting.

I’ve been reading up on Behat again, and also content creation/curation, and SEO, as all these will be parts of my new role as well. I’ve be writing more posts as I learn and achieve more.

Wish me luck!

On Testing

On the face of it, testing can seem pretty simple. The product needs to have X, Y, and Z functionality, so you test X, Y, Z, both with valid and invalid data.

But what about integration testing? How does the new functionality integrate with the existing functionality?

Continue reading