Skip to main content

Testing - The Hidden Profession

Software Testing - The Hidden Profession

After working at Assurity for a few months, I decided to catch up with some friends in Auckland. Given that most of my friends have left uni in the past few years; it’s safe to say that our lifestyles have changed; and a major topic that would arise would be what we’re doing with ourselves these days. That is, what exactly are we doing 40 hours a week?

The other person would start it off and go into how they’re enjoying their job as a lawyer/accountant/marketing co-ordinator. I’d ask about what their typical day is like; do they miss uni (and everything that came with it such as lectures and exams); do I know anyone who works at their company; and so on and so forth.

And then it would be my turn.

I’d say I’m working as a Test Analyst with Assurity Consulting Ltd.

I would then be faced with a blank look.

“So do you write code?”

No, not exactly. But some people in Testing do need that skill. I suppose you could say we want to verify the quality of software before it goes live and plan how to break it.

I’ve had many conversations go along these lines and I’ve come to the conclusion that a lot of people not only don’t know what exactly a Test Analyst does- but the fact that they exist.

Well I suppose that shouldn’t surprise me, given that I, for one, honestly thought that software development went a little like this (before I discovered the world of Software Testing):

  1. Project Managers and Business Analysts tell the developers what they want the system to do
e.g. I want a search website that finds what I want, is not case sensitive and comes up with a maximum of 10 search results per page.
  1. Developers write code for this
  2. It goes live
Oh and I suppose the developers and/or Project Managers & Business Analysts would try out the system to see how it was.

It didn’t occur to me that there are people whose profession is dedicated to ensuring software quality is present.
It didn’t occur to me that this role could branch out to many more roles such as a test engineer, test manager, integration specialist, automation...
It didn’t occur to me that this role is in high demand in NZ

Little did I know.

Now that the world’s reliance on technology is increasing, it makes sense that careers surrounding these changes are plentiful. Don’t get me wrong. I’m not in any way saying that it is easy to get a job as a Test Analyst. But I think I could say that the market is promising.

But you know what really irks me?

The fact that some people think that anyone can be a Test Analyst.

I’m pretty sure there are people out there who think they can just haul someone in front of a computer, tell them to ‘test’ it, and then go-live based on that person’s findings (who, in fact, has another day job).

Now maybe, this is suitable for a really small company where it doesn’t make sense to have someone devoted solely to software testing because everyone at that company has a range of roles in the organisation.

Or maybe it’s a start-up and no financial resources can be allocated to do software testing.

Both of the above scenarios are realistic, and dare I say justifiable.

But if you want to make sure that the system is performing the way it should be- then you know who to call.

Maybe it’s the fact that many people aren’t aware of how IT projects actually operate.
Maybe it’s the fact that people don’t see the point in hiring someone dedicated to ensuring software quality.

But let’s face it- Testing is the Hidden Profession.

So now what are we going to do about it?

My intention in this blog is not to raise awareness among those who already understand the  benefits of testing. But I do want people to raise awareness around this profession.

Tell people what you do day to day.
Tell people what makes your role important in an IT project
Tell people what makes being a Test Analyst stimulating.

Have that conversation, then see what happens next.


Popular posts from this blog

A reflection on Let's Test 2015: Part II

Here's the link to A reflection on Let's Test 2015: Part I The sessions (Part II) Below does not include all of the sessions I went to nor all aspects of the session I mention Visual Creativity: Using Sketchnotes and Mindmaps to aid your agile testing - Dan Ashby and Christina Ohanian Before this session I stumbled upon Christina drawing out her sketch notes from the previous session and marvelled at how fascinating it was. Sketch notes were only something I'd only ever seen on the net. They were gorgeous and a clever way to communicate information. When she told me that she was going to have a session on this - I was all in. We 'warmed up' by drawing whichever image came to mind when Dan said a word. It was interesting to see how a lot of people could interpret the same word differently. For example: "Time" could be a clock, a watch or an hourglass.

Getting started on a testing project

I started on a new project a few weeks ago and thought it would be a good idea to share a checklist for what new testers on a project need and some good starting questions when you, as a tester, are new on a project Checklist for what new testers on a project need (Note, your project may not include all of the below) Note to check if user credentials are needed for any of the below

4 Books Which I've Found Useful for my Testing

 1. Thinking Fast and Slow by Daniel Kahneman I heard from quite a few people how beneficial this book was for them. About six or seven years ago, I tried to read it, but couldn't get into it - then I tried again about two years ago and really enjoyed it. It's an intense read and focuses a lot on cognitive biases - a lot of which I come across in day-to-day testing.  2. Lessons Learned in Software Testing: A Context Driven Approach by Cem Kaner, James Michael Bach and Bret Petticord While this book was written almost 20 years ago, a lot of the lessons still apply today. There's A LOT of useful advice you can apply.  Strongly suggest you get a copy and then use it as a reference when the need arises.  The great thing about this book is that it's split into almost 300 lessons - so you can fairly easily pick it up and put it down. My highlights include: Lesson 9: You will not find all the bugs Lesson 25: All testing is based on models Lesson 57: Make your bug report an e