Talk: There's more to code review than you might think at Software Tester Usergroup Hamburg

I’m currently on a contract in Germany, so what better excuse to give a talk at the local testers usergroup?

So, you do code reviews, and that’s great. But there’s always more that you can check during the review. More places you can check for any potential bugs or problems before deployment, before you find yourself with technical debt. Or worse: unforeseen downtime.

In this talk I will be going through the things that you should be checking to ensure confidence for developers, project owners and stakeholders. We’ll be looking at documentation, commit messages, and common code problems, with examples and tips along the way.

Links: xing, meetup

Note that there will be two talks, one in German and mine, in English.

Talk: There's more to code review than you might think at PHP-Usergroup Hamburg

Not content with speaking at the local tester’s group, I’ll also be speaking at the local php usergroup next week. I’ll be giving a 20 minute version of my code review talk.

So, you do code reviews, and that’s great. But there’s always more that you can check during the review. More places you can check for any potential bugs or problems before deployment, before you find yourself with technical debt. Or worse: unforeseen downtime.

In this talk I will be going through the things that you should be checking to ensure confidence for developers, project owners and stakeholders. We’ll be looking at documentation, commit messages, and common code problems, with examples and tips along the way.


Hmmm... _there's_ a bug

I spent some time tonight speaking with Michael Bolton, about automation. Something he said that could be done really struck me:

He set things up to alert him whenever there was a significant variation in how long functions took. At least half the time, a change in timing would cause a developer to say “hmmm… there’s a bug.”

That’s totally going into my bag of tricks.

On making a conference lineup more diverse

If you’re getting the following error in Ruby, and no matter what you do you just can’t fix it:

/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/net/http.rb:921:in `connect': Connection reset by peer - SSL_connect (Errno::ECONNRESET)

Try using a non-system version of Ruby. I used brew to install it, but it doesn’t seem to matter how you accomplish it.

★  On making a conference lineup more diverse

(Or, why I didn’t submit to the PHP Unicorn conference)

I don’t usually blog about internal community struggles. They’re often important discussions to have, sure, but I usually don’t like to get involved. But this one is important to me, because I had an opinion on it before it was a problem. But I decided to keep silent at the time. In hindsight, maybe I shouldn’t have done.

So. The problem: (another) conference has a speaker lineup which is 10% female, 0% PoC. This problem is far too common; I’ve called out conferences for this in the past. But the main difference in this case is Peter has held his hands up, admitted he could’ve done better, and openly asked for (and importantly, listened to) advice on how to be better next year.

[By the way, Peter, if you’re reading this (and I hope you are): hats off for making this a learning experience for both you and other conference organisers. I have no beef with you or your conference, I want to watch but sadly I cannot get the day off work. I just wanted to share my experience to add to the pool of knowledge that’s out there.]

From what I can tell, the generally accepted reason why the conference doesn’t have a very diverse speakers lineup is because there wasn’t a very diverse choice of talk submissions. Which was caused by who the CfP was marketed to.

I saw the tweets advertising the CfP, but deliberately chose not to submit. I spent the last couple of days putting into words why that was. Here’s my attempt.

The tweet that I saw advertising the CfP was very close to this one:

Watch 8 of the top PHP experts (unicorns) in the world streaming live (or access the videos later) for just $50.

— PHP Unicorn Conf (@PHPUnicornConf) March 14, 2017

The three important words are “top PHP experts”.

There were also two initial (I assume invited) speakers already announced: I guess this was to drive ticket sales. They are undoubtedly two well respected names in the community. And they’re both incredibly smart and accomplished people. Between them they have contributed to Core, written books, written very popular development tools, and keynoted at conferences.

So, that’s the level of this conference. Experts (or unicorns: legendary creatures known to be hard to capture). People who have contributed to php in a big way. Like, for example, writing books or contributing to Core.

Which is why I didn’t submit. I have never written a book (the most I’ve done is written articles for other blogs), and I wouldn’t even know where to begin when it comes to contributing to the php language itself.

And is, probably, why many other people – especially underrepresented people – thought the same as me. That the CfP probably isn’t for them. The conference wants more intelligent people. More accomplished people. What am I doing even considering I deserve to share a stage with these giants of php?

Which is a lesson to all other conference organisers. I see the same faces on conference websites all the time. Some of these faces I saw at my very first conference I attended, almost 10 years ago. I literally learned my craft from these people.

If we want to bring in more speakers – more diverse speakers – we need to say that yes, you can submit to a CfP. It’s not for the elite, chosen, few. You don’t have to look, sound, or act like the other speakers you’ve been watching and learning from for the last ten years.

We need to be say that even if you’ve only been developing for a few years, you absolutely have something to say. Something which the most experienced developer can learn from. You bring something to the table, and we want to hear it. We promise.

We need to say that we don’t need unicorns on stage. We need YOU.

On Apple buying Workflow

I’m sure over the next few days, there will be lots of opinion pieces written and published by lots of different people over the news that Apple have purchased Workflow.

My opinion, however, isn’t that special. It’s little more than “oh, that’s pretty cool. They wrote a great app, so good that Apple wanted in. They did pretty well there!”.

But there’s one part of the Techcrunch article announcing the deal which struck with me. It’s near the bottom, and it’s a couple of paragraphs about some words Apple said about the app:

Apple confirmed the deal, and has said the following about Workflow:

“The Workflow app was selected for an Apple Design Award in 2015 because of its outstanding use of iOS accessibility features, in particular an outstanding implementation for VoiceOver with clearly labeled items, thoughtful hints, and drag/drop announcements, making the app usable and quickly accessible to those who are blind or low-vision.”

The accessibility features of Workflow are super impressive, especially for an app that is a tool for building complicated macros. It would have been much easier to say hey, this is for heavy users maybe we don’t need to make sure it’s 100% accessible — but they didn’t, and they won a bunch of awards (and an exit) for their trouble.

It’s all too easy to say that in an advanced app for pro users, with a lot of complicated features, accessibility isn’t at the top of the priority list. But Workflow has proven that it’s still an important thing for app developers to worry about.

And Apple, apparently, agrees.

★  Is ISTQB worth it?

A common conversation among testers is certification, and whether it’s worth it. I only have experience with the ISTQB certification: I have both the Foundation and Advanced (Test Manager) certificates, so my opinions are on these.

I think that in certain circumstances, having an ISTQB pass to your name can be beneficial. Sure, lots of hiring managers might just ignore it, but in some cases you might want to consider the test anyway.

Your manager/company asks you to and pays for it

This is perhaps the most overlooked reason to attend an ISTQB course and take the test, whether or not you pass or fail. And I think it’s probably the most important reason. Heck, it’s the reason I have done it.

For me, the conversation started during my annual appraisal at work. I was given the objective to attend a course and to pass the examination. At the time, I didn’t have a clue what ISTQB even was: I was a newcomer to the testing world. But I accepted the objective, I attended the first course I could get onto, and during those three days I worked hard to make sure that I passed.

This made me look good to both my line manager and to the company as a whole. During my next annual appraisal I could say “I did this, because you asked me to it”, and it helped me prove to my line manager that I’m serious about improving my skills.

It also showed me that the company was serious about helping me increase my skills: they were happy to pay serious money for this to happen. To refuse to take up this offer would look bad. It shows dedication from both the employee and the employer.

It teaches trainees to a certain (minimal) standard

OK, so it may not be your company’s own processes and standards, but ISTQB is a good way to teach QA to those new to the field to at least some standard.

As long as the tester understands that the ISTQB foundation syllabus only touches the iceberg of QA – and they are encouraged to continue learning – I see no harm in using the ISTQB foundation course and examination as a “kick start” to learning what you need to know to be a good tester.

Your enthusiasm during the course will be noticed

You never know who might be in the same room as you. It could be your next colleague, or even your next employer.

The training course before an ISTQB exam is a good way to show everybody how much you care about the art of QA. If you ask lots of questions, and generally try to get involved, you’ll be remembered. And when it comes to your next job or your next promotion, getting noticed has never harmed anybody.

Of course, on the flip-side, if you’re sitting there looking bored and wondering what time lunch will be, that will be noticed, too.

It’s a standard vocabulary

OK, I know, you might not like this one, but it’s there. ISTQB is a standard. It might be a standard that you disagree with, but it gives us all a common vocabulary.

It helps imposter syndrome

This is why I took the Advanced (Test Manager) exam. Unfortunately, imposter syndrome is all too prevalent in our industry. Something objective to prove that you do indeed know what you’re doing can be a step towards controlling these doubts.


If you already have a career in QA, and have had one for at least a couple of years, then I don’t think it is worth the cost and time to take an ISTQB course and test. The value it gives you (a minimal standard of knowledge, and showing your dedication to your managers and peers) is something that you can show through your years of experience.

But for people who are new to testing – less than a year – I would absolutely recommend that if given the opportunity to sit the ISTQB, they should take it. They are still fresh and unproven, and there might be things that they just don’t yet know (as there may be concepts that just haven’t come up during day to day testing).

The courses are not cheap, granted. I only took a course because my employer paid for me. To be clear: I do not think that an individual should pay for an ISTQB training course. But the exam itself is affordable for individuals, and you can download the syllabus and sample exam papers for free from the ISTQB website for self-study. In fact, this is how I received my ISTQB Advanced (Test Manager) certificate.

★  Developer and Tester

On my personal business card, it says “Software Developer/Tester”. I usually call myself a “Software Engineer”. I develop, and I test. And my CV has plenty of skills and experience in both.

But, can I really do both? Surely I can only do one or the other? Does it make me indecisive about my career choice and career path?

The short answers are yes, no, and no.

Let me give you the long answers

Can I really do both?

Why not? There is a lot of overlap in development and QA. Good project teams generally, in my opinion, are more successful when the developer and the tester are in constant communication.

It’s true, I prefer to test software than develop it, but that doesn’t mean I can’t develop software (or write automated tests) when the need arises. And it doesn’t mean I don’t have my own personal projects where I’m developing.

Surely I can only do one or the other?

We all know that in the tech industry, there’s specialists and generalists. Some argue that being one is better than the other. Me, I think that both types of people have very valuable skills that are useful in a project.

Very early in my career, I decided I was going to be a generalist. I was interested in a lot of things (I still am. My secret to being a good listener is I am genuinely interested in what the other person is talking about. Even if it’s about their trip to Morecambe with Aunt Sally. I just love to know things).

So I learnt as much as I could about development. I learnt PHP, and I learnt JavaScript. I learnt about Linux, because that’s what web servers ran on. There are people out there who know lots more about topics than I do, and honestly, it frustrates me. But I also know, I have enough baseline knowledge to be able to pick stuff up.

It’s the same now I’m testing. I might be a tester by day, but by night I’m learning Swift. I’ll never be the expert in iOS development, and I’ll probably have to Google some syntax, but I know enough to do a very good job.

I would prefer to also be able to test very well. I’m almost certain that there will be a “Selenium expert” who knows more than me, but does that really matter when I have enough broad knowledge to learn what I need to know?

Does it make me indecisive about my career choice and career path?

No. My day job is as a tester, with my career plan being to one day, be a test manager. And, if you ask me, the best managers are generalists. But that’s probably a blog post for another day…

Automatically test your database backups 🔗

A smart solution by Marco Arment:

I keep a running spreadsheet with pretty graphs to monitor the health and growth of my business, I update it once a week, and — critically — I pull almost all of the stats I need from the backup emails.

A nice way to confirm that your backups work.

Drop the crutches🔗

I’ve never really been that much of a fan of test cases. I like to call the method of going through a list of tests one by one “checkbox testing”. I don’t like how it encourages you down a specific path, and discourages you from doing what testers are good at: checking the quality of a product.

I always thought I was in the minority. I thought that my dislike of test cases made me, in some ways, a bad tester. I mean, I can write test cases. But almost every job description I see requires experience in doing so. I never understood this emphasis on something I didn’t think was a very good way of checking the quality of a product throughly.

So it was heartening to see the tweet thread, and this later blog post, by Michael Bolton, which includes this brilliant thought:

We also agreed that test cases often lead to goal displacement. Instead of a thorough investigation of the product, the goal morphs into “finish the test cases!” Managers are inclined to ask “How’s the testing going?” But they usually don’t mean that. Instead, they almost certainly mean “How’s the product doing?” But, it seems to me, testers often interpret “How’s the testing going?” as “Are you done those test cases?”, which ramps up the goal displacement.

I might have to bookmark this one, as a well thought out argument outlining the problems that come with test cases.