Skip to main content

Bloggers Club: The Essential Skills for Testing

 I've been pondering about this blog post since I saw the Ministry of Testing discussion post  and to be honest, I really struggled to interpret it. I mean, how do I define essential skills exactly?

To help me structure my thoughts for this post, I'll be interpreting "The Essential Skills for Testing" to be "What skills are useful for a great tester?"

Strong communication skills

Let's be honest, we've all met people who claim they have communication skills or even strong communication skills and you can't help but roll your eyes.

Like wth does that even mean?

In my opinion, strong communication skills (for a tester) means that a tester is:

  • Able to communicate exactly what, where, why, how, etc they have tested in such a way that the team understands what they did
  • Able to communicate exactly what, where, why, how, etc they will test a feature (etc) in such a way that the team understands what they plan to do, and can help expand on those ideas/or question them - to me, the second part is a test of how well you communicated what you plan to test.


Can give effective, actionable feedback

Test reporting and bug reporting is essentially feedback.

A tester is giving the team (often the developers) feedback on the feature (etc) that they have tested. 

Often we expect/hope for people to gain some sort of value from our feedback, maybe we want them to know what a great job they did, or maybe we want them to know there are some areas of the feature that had quite a few problems. If it's the latter then a tester should deliver the feedback in an effective, actionable way.

I don't think a tester should just write a bug and say "it doesn't work". What is a developer supposed to do with that sort of information? There's no clear point for the developer to start investigating. Even if you don't know exactly what the problem is, you can note down what you did to investigate the issue; what you tried to do etc. 


Appreciation for the bigger picture

When I started my career, I sometimes struggled to appreciate the bigger picture. Testing and software quality was in the forefront of my mind and I struggled to comprehend why/how you could knowingly release software with bugs in it, or why people didn't want to dedicate more time to testing, or more budget to testers. (I've talked a bit about this in an earlier blog post)

I only saw the testers/testing perspective but failed to appreciate how testers/testing fit into the bigger picture. 

Often, decisions need to be made where if you have limited time and resources, then something has to give (often testing time unfortunately), now you don't have to always agree on the decisions made but if you accept that sometimes you don't get what you asked for - then you know (hopefully early) to prioritise your testing so the most important/riskiest areas are covered first.





Comments

Popular posts from this blog

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

My Most Used Test Heuristics (with examples)

First, what is a heuristic? A heuristic is a guideline ,  it is fallible.  Therefore, it will give you a good idea of what behaviour you should see BUT it isn't definitely what should happen - it's up to you to confirm that the behaviour you are seeing is correct.  In a previous blog post I shared a step by step guide on  how to test without requirements/little requirements.    But I figured it's good to share my most used test heuristics that I use for testing without requirements. They are: Consistency with History Consistency with User Expectations Consistency within Product Let's take a look at each of them along with some examples to illustrate the concept. 1. Consistency with History  The feature's or function's current behaviour should be consistent with its past behaviour, assuming there is no good reason for it to change. This heuristic is especially useful when testing a new version of an existing program. (Source: developsense) Example: Whitcoulls, a

Bloggers Club: The Importance of Exploratory Testing

 Before we dive into the importance of Exploratory Testing, I would like to clear three things up. Firstly, I align with this definition of Exploratory Testing, by Cem Kamer, it is an approach to software testing that consists of simultaneous learning, test design and test execution. Secondly, I don't think Exploratory Testing has to be a substitute for test cases, it can complement test cases. (It's up to you, how or if you choose to combine both Exploratory Testing and Test cases when you test a feature) Lastly, exploratory testing is not adhoc testing - adhoc testing is random, unstructured testing, exploratory testing forced you to think critically about the application under test. (For more about the difference go here .) Job Interview Analogy To illustrate the importance of Exploratory Testing, I'd like to first use the analogy of a job interview. (I wrote about this in a previous blog post but will expand on this further) The Test Cases in this analogy In a job inte