As a tester, what do I know, and what would I like to know?

As part of my ongoing quest to learn more to be better at my job as a tester, I’ve had to think about not only what I know, but also what I want to know.

I feel I’ve got the ability to write a manual script as well as execute it down. Granted, I hate writing super-detailed scripts as I find them restrictive, but it is the style I have to work to.

I can write a SQL query to search against a database, which is essential for where I work (I can’t speak for testers everywhere),along with deletes and updates. I also know there are things I’m not confident with using in SQL – Unions, joins other than cartesian, and likely other tricks that I’m yet to be exposed to.

I know different types of analytical techniques, with decision tables being one of my strongest (though mind maps are rising as a technique for me).

It feels like I don’t know much, as knowledge of the processes and day to day actions of end users is great where I work, but won’t do much for me elsewhere. However, there are bound to be things I know I don’t think about that only come up when I get asked about it.

As for what I want to learn, that is all thanks to the Internet and what it gives me access too. So, these are what I would like to learn, and who I would like to credit so others know where to go for further information:

  • Pairing up with another tester (Katrina Clockie) – Recently I have been working alone as the only tester on my various projects, so whilst I’m part of a larger team I’m not involved with any of their work, and vice-versa. When I have been working on the same project as others, it was still a case of we go away, do our own planning/scripting/execution, and then meetup periodically to see how it’s going. But having the two of us sat at a single computer, talking through our analysis, scripting and execution would be a great experience, even if it goes horribly wrong. “Two heads are better than one” is a saying everyone knows in some regard, yet doesn’t seem to be commonly done around me, perhaps out of fear it looks inefficient?
  • Pairing up with a developer – Related to above, but instead of both of us looking at what we are doing from a purely testing perspective, I sit with the developer as they write their code, allowing me instantaneous access to what they’re working on so they can talk through what they’re doing, and I can ask questions about it whilst it’s as fresh as it will ever be. It also allows me to talk about the tests I’m intending to perform, so they can either say which may not be achievable, or which would have caused a problem for their code if I didn’t say now instead of waiting for it to be released and lose more time. Due to being a foreign concept again, I imagine fear of the unknown has stopped this ever happening before.
  • Mob Programming (Maaret Pyhäjärvi) – Taking the pairing up a notch is mob programming. So instead of me and one other, there would be several of us all working together, taking it in turns to talk through ideas, drive a laptop, and give us the peak of everyone’s knowledge and performance.
  • Security Testing – It is a grand unknown to me, and where I am  it is purely outsourced due to the knowledge required. But with the hype from the Ministry of Testing’s 30 Days of Security Testing challenge, it is something I’d like to look more into. The Internet isn’t going away, and security will only get more important, even if most of it won’t be relevant on a daily basis for me.
  • MI testing – This is the sub-team that I’ve moved into, with no real knowledge or experience of, so beyond knowing I will use SQL, this will be a brave new world for me. Although I’ve also been told to look at BI testing as there is a major overlap between the two.

I’m not giving myself a hard deadline as to when I would like to learn these, as deadlines can slip, reality causes delays, and other things can and will turn up. But if I keep moving forward with these, each little step puts me closer from wanting to learn, to understanding and perhaps even teaching others.

This is what I want to learn. What about you?


4 thoughts on “As a tester, what do I know, and what would I like to know?

  1. In practice you might encounter resistance from a developer if you ask to pair with them. Putting myself in the developer’s shoes, I have two alternatives. I can guarantee that your testing will result in feedback. I can either have that feedback as I go, or I can have it after I think I’ve finished. Once I’ve finished, I won’t just wait for your feedback (which will come hours, days or weeks later), I will move onto something else. Much has been written about the lost productivity caused by context-switching. If your feedback comes later, I will need to switch context from the new work back to something that I had finished, and overall this will slow me down. Another advantage of pairing with you is that you get an insight into the choices I make and the constraints within which I’m working, which may help you to tailor your feedback to things that I can take action on. I may also be more receptive to your feedback earlier in the process because it is easier for me to change course at that stage (do the work differently, rather than do it and then rework it). I’ve focused on the benefits to me as a developer, because I think you can already describe the benefits to you as a tester.
    A final point, I don’t like the idea of pairing. But whenever I’ve tried it, I have to say that it has worked quite well. One of my worries is that I won’t be able to think very well while I’m talking to someone. If you set some groundrules, and make sure that you interleave pairing with time for reflection, it will work out. And I’ve noticed that, in practice, it can improve focus and reduce interruptions because people are less likely to come over and interrupt a conversation than they are if I’m working independently. If you encounter a reluctant developer, reassure them that it’s just an experiment for (say) 90 minutes and there is no further commitment if it doesn’t work for both of you.
    Good luck, and keep learning!

    Liked by 1 person

  2. It is interesting how some kind of testers (myself included) are motivated by continous steps forward to wider technical knowledge to stay closer into the devs world.

    Nowadays testers have to be at their highest level technically speaking because Development departments demand it, I am happy due to I like to reach those ‘little further’ steps everyday.

    Keep learning and make your brain a little happier


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s