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.

Why my emails are so short

It's been brought up on a couple of occasions that my emails (heck, my online communication in general) are short. There's a reason for this:1 I've yet to decide whether it's a good one or not.

I've come to realise that in general, people don't read entire emails. Given a two line email or a two page email, I'm more than likely to read (and follow up on) the former.

We all have busy lives, and we all get tens -- if not hundreds -- of emails every day. All asking for those two minutes of your time that nobody has, so we tend to be choosey on which emails we read, and respond to. And -- being the selfish type -- I want that email to be mine.

So, I write in short paragraphs, short sentences, and in short prose. In hope that you're more likely to read what I have to say if I do. It probably means that I miss things out, and that things need further explaining. In which case, that's best done over a followup email, phonecall, or face to face meeting (Speak to me face to face, and there's a likelihood you won't be able to shut me up).

If that sounds rude, or missing details, I'm sorry. Let me buy you a coffee as an apology?

(Of course, I'm not smart enough to come up with this myself. I learnt this from Oren Klaff, who sent out an email newsletter about this).

  • 1. Well, two: I've struggled with RSI in the past, and it's not a nice condition to have. Ask me and I'll tell you what I think is wrong with keyboards

Video: re:develop conference 2016

The video of my talk at re:develop 2016 is now online. With thanks to the organisers for having me, and all attendees for asking some great questions, being nice people, and laughing at the right places.

 

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 Clair 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.

 

Direct link to talk on Vimeo | Link to slides

A suggestion for conference organisers

Conferences are great, I really enjoy going to them. But also, I find conferences can be difficult to be at.

I suffer from anxiety, and from time to time it can be difficult to deal with. Things that I struggle with are being in a place with lots of people (especially people I don't know), being in places where there's a lot of chatter or a loud noise from a microphone, and learning difficult or new things. So, basically things that by design you get at conferences.

Sometimes, it isn't a problem at all. I can usually cope for a while if it is a problem. But often I just need to get away from it all for a few moments.

So, I have a suggestion for all conference organisers. Can we have some kind of "quiet space" for people to escape to? Somewhere away from the usual hustle and bustle of the conference where I can just sit down with a cup of tea 1, perhaps catching up on twitter. Being by myself where my brain can recover.

It doesn't need to be a separate room. Just some space away from the main break area (ie. away from the sponsor hall), that's clearly defined as "I need to take five minutes" space.

Because often, as much as I'm enjoying the talks and meeting old and new friends, all my brain wants to do is run away. And my brain will thank you for providing somewhere I can run to.

  • 1. Which brings me to another suggestion, this one for conference caterers: please don't take away refreshments just because the talks are on. Not everybody goes to every talk. And no, jugs of water and small glasses don't count as refreshments.

Five years

Image removed.It’s been five years since Steve Jobs was cruelly taken away from us.

In those five years, multiple biographies have been written, business books have been published promising the “Steve Jobs way”, and many anecdotes have been told from people who have been lucky enough to meet, or work with, the man.

Jobs has touched many of our lives; whether it’s through the phone we use or the way we listen to our music. But for me, he also touched my life by showing me what uncompromising looks like.

Uncompromising is being sacked from the company he founded, only to lick his wounds and start again
Uncompromising is using beautiful typography
Uncompromising is building a mouse that you can use on your jeans
Uncompromising is being unhappy with the mobile phone market, so making your own
Uncompromising is making a computer that isn’t a beige box
Uncompromising is patenting a design for a better staircase, when you aren’t in the staircase business
Uncompromising is saying no to Flash, when everybody else is saying yes
Uncompromising is creating hundreds of prototypes of a box, to find the best product packaging for an iPod

Like many, I still think about Jobs from time to time, and the things he gave the world. The technology he gave us is obvious, but it’s not what I’m the most thankful for.

What I am the most thankful for, is being shown that it’s ok to never be satisfied, and instead to think about every last detail. Because it’s the small stuff that makes the world a better place.

Testing, and being a tester

Gem Hill made a really interesting episode of her podcast, talking about how she became a tester, and invited people to speak about their stories. 

Like almost every other tester, I kinda fell into it by accident. Like Gem (spoiler alert) I started by testing, realising I quite enjoyed doing it and had a natural talent for it, and so decided to become a tester.

Almost by coincidence, the company I worked at was both moving the platform to a language I couldn't — and still can't — grasp, and building up their test team. Given I did some testing previously (agile, people!) and didn't completely suck at it, the switch was a no brainer. 

The day before I was due to move team, my soon-to-be manager checked how I was. My response was a barely understandable panicked mash of worry.

The day I moved, and the subsequent days afterwards, I found myself talking with the others in the team like I'd been there forever. That all testers seem to have the same sense of humour generally helped. 

It was that week I realised I was no longer testing: I was a tester. Almost two years later, I'm starting to scale back the amount of development I do.

(It was that week I was also introduced to Inside Number 9, which after a few episodes I decided was far too creepy...)

 

It's a bug

Avecto:

Human beings are not interested in whether you have introduced a problem when designing your product or when coding it. They’re all just bugs.

Good to see the big companies saying this out loud. Just because your app functions correctly and to spec, doesn't mean there isn't an important usability problem in there.

Colour blindness and the iPhone

Jason Snell has written an interesting article on colour blindness:

The design of Apple's MagSafe chargers are a case in point: They contain a clever design to indicate your charging status at a glance — green means charged, amber means charging, and no light means that there's no power or connection.

Except, well... I can't really tell the difference between the green and the amber lights at a glance. For a long time, I didn't even realize the light on the MagSafe connector changed color. (Apple is far from alone here — lots of electronics use subtle color shifts of an LED to indicate things in a way that I simply can't digest.)

But I do love that Apple are trying to make things easier:

In iOS 10, Apple will let users filter their entire display, whether that's applying grayscale, red/green filters for both protanopia and deuteranopia color blindness, and a blue/yellow filter for a very different form of color blindness called tritanopia. There's also an option to just overlay a color tint of any hue or intensity.

I had a discussion with someone last week about how developers can, and do, keep disability and individual circumstances in mind. When asked what kind of built in features were built into the iPhone for accessibility, the list in my head was growing as I thought of more and more.

The answer I verbally gave was "gosh, loads!".

It's nice that Apple are growing accessibility features for iOS year after year, even though they don't have to. I like that they see it as their social responsibility to do so.

 

Downgrading from iOS beta

A handy Knowledgebase article which provides instructions on downgrading iOS. Ignore the title, these steps work.

At least, I was able to downgrade from iOS 10 development beta to iOS 9.3.2 by doing this. 

ITunes bug deleted music library

Serenity Caldwell:

It appears that the most recent version of iTunes 12.3.3 contains a database error that affects a small number of users, and can potentially wipe out their music collection after the update.

I've given up being surprised about bugs in Apple software. I now subconsciously expect it to not work properly. Which is a shame.

The last sentence says it perfectly:

Now is the time for the company to recognize that without stable base applications, Apple Music will always be plagued with accusations and problems — even if it doesn't always rightly deserve them.