Personal responsibility for your development

Within many companies (those worth their salt) you will find a clear path of progression, a path that has been planned out and proven. That’s brilliant, and if you work for such a company, well done, don’t waste the opportunities that are put before you.

These paths are not always funded literally, you won’t always get to go off on conferences, training courses and the like. Especially now where many company budgets are tight in the current economic climate.

But my advice is this, do not rely solely on the good will of your company. Take responsibility for your own development.

I have been an IT professional since 1999 across a variety of industry sectors and companies. In all that time, I have understood that I need to be passionate about my career. If I like my career then I need to invest in myself, regardless of what a company can offer me in training, I am a tester…I need to master my craft.

While a company might provide training, this is typically only if it has at best mutual benefit. At worst it only benefits the company (although very rare). But that’s only going to provide a snapshot of the wealth of information out there. Your company may only test A & B type project, so any training will be tailored to that goal…but what about the X, Y and Z projects…what about the skills needed for that?

If you are a tester, if this is your chosen career, take it seriously. You must take responsibility for your personal development. Testing is a vast subject, it touches on  the technical, the psychological and the logical. The potential for learning is huge, so reach out and get stuck in…grab your personal development by the horns and make it work.

I personally hook up with like minded individuals, and use social media to learn interact and ask questions. You can visit Ministry of Testing to get started, you might also like this post.

My TestSphere deck has arrived!

I thought I would get myself a TestSphere deck to use with my teams, and for personal development also. It arrived today and it’s rather exciting!

To my team…hold onto your hats, this could be fun. To my blog readers…I’ll try to remember to blog about the TestSphere sessions I hold, maybe you can see how they go and if they might work for you!

Avoiding ad hominem arguements

Ad hominem (to the person) arguments make everything seem personal, or that the person you are talking to is making a statement about you or your personal character, or ability.

As testers we must work to minimise this type of discussion or argument. We almost always have some bad news to deliver…the product doesn’t work, the product can’t go live.

De-personalise reporting, feedback and discussions. Talk in terms of the product, not the developer who wrote it. It’s not always easy but this separation is key to fostering strong relationships, it can also be the foundation to more open and direct conversations later.

Avoiding ad hominem is the foundational element of civil discourse.

How do you keep connected?

Being connected to the testing community is something that has always been important to me. There have been times when its not always been possible, but I continually strive to connect, share and learn from others in my field.

One of the most significant ways I have found is through the Ministry of Testing, a big online community dedicated to testing.

Another very good way to connect is via the various social media channels available to us all. I personally use Instagram, LinkedIn and Twitter…all of which have advantages and disadvantages depending on what you are tying to achieve.

My personal list looks like this, maybe you could benefit from these connections as well. I have listed these with name, blog link and then twitter handle.

James Bach

Michael Bolton

Anne-Marie Charrett

Ministry of Testing

Rosie Cherry

Dan Ashby

Richard Bradshaw

Gem Hill

Heather Reid

Andy Carrington-Chappell  (me)

Logic Errors in Testing

While testing it’s easy to fall foul of logic errors in your thought processes. One of the most common errors is the post hoc fallacy.

This is a logic error or fallacy of post hoc, ergo propter hoc (after this, therefore because of this). It can sometimes be all too easy to attribute issues to unrelated events just because they follow them.

For example, a new tenant moves into a new flat and upon arrival the flats hot water boiler goes faulty. The landlord automatically assumes the arrival of the new tenant caused the fault. This is an example of the post hoc fallacy.

In testing we must resist the urge to jump to conclusions, and instead use investigation, logic and critical thinking.

Creating your own test tool

Sometimes you may need to create a tool that helps you in a specific task, perhaps not specifically testing but related to it. From my experience I have created tools that check and format EDI messages, or run data cleanup or tools that provide high level test estimates based on team / department metrics.

You wont always have development resource to help you create these tools, as a result if you cant create them then you wont leverage the efficiencies they bring.

This means it’s worthwhile learning a development / scripting language. As a minimum you should consider a universally accessible scripting language such as Python.

Remember though, that anything you create will more than likely have to be ratified by your IT team, especially in some industry sectors. You’ll also need to take ownership of that tool, it’s maintenance and source code storage (in case of audit, updates or incident).

Why not think about some of the tasks you currently undertake in your team(s). Is there somewhere you could use a bespoke tool? If so, why not get started as a self-learner and undertake a project to create your own tool.

Testers must be learners

It’s no secret that there is always something new to learn in the field of testing. However, it’s important that we as testers establish ourselves as perpetual learners.

There are a multitude of topics, tools and systems that you will have to learn a you go through your career. I personally encourage the self-learner and encourage others to take on the approach of being a self-learner.

You are not always going to have the luxury of a user manual, a tutor or a course to assist your learning journey. So what then? That’s when you need to take charge of your own education.

But what does this look like? Well, in most cases this means getting hands on with the system, using it and experimenting with it, probably making notes as you go and forming your own user documentation.

In short…take control of your own learning. Grasp every opportunity with both hands and see what you can learn from it. Never, ever just go through the motions to get the job done…always look out for those nice little learning opportunities as they arise. Also, and I cant say this forcefully enough, DO SOME LEARNING IN YOUR OWN TIME…if you are serious about your career, your craft and your development.

But if you are able to master the art of self reliance in your learning, you are going to empower yourself to learn. Never be left floundering again and equip yourself to learn almost anything.

A great book to get you started is this one from James Bach.

Testing Ninja

I’m delighted that the Ministry of Testing made me their Club Ninja for March 2018.

I have been a tester for some time both hands on and as a more aloof test lead and manager. However throughout my testing career I find that participation in the testing community is vitally important. 

By joining a large online (and offline) community, you are able to learn, grow and share ideas with other in your profession…maybe even masters of the craft.

Ministry of Testing is a fantastic community, so why not get going and join in at The Club !