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

Conclusion

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.

Lightning talks, August 2017

This month I gave lightning talks at PHPNW and NWDUG, “Educating Enfys”.

Slides available on Speakerdeck.

Speaking: re:develop conference 2016

I spoke at re:develop conference 2016. 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.

★  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¹, 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.

★  Five years

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.