Teaching the "soft skills"

Good morning and here we are again, the beginning of a new week :smiley:

When it comes to testing there are many different types of skills required - but the type I’m interested in here is the skills around the ability to be critical of a product, and to ask questions. This is an area feels a bit more difficult to train people in. I also notice that when working with ofshore team members seems to be a missing element.

So what I mean here is testers can confirm requirements are being met, they may have skills to do automation etc. But as we know testing has a lot to do with the evaluation of the product.

For example, functionality may be present, and it may work, but does it do it in the best way it can, does it give the best User experience, what are perhaps the risks which the BA perhaps didn’t account for etc. There’s also the risk of the testers getting “too close” to the product and lose the ability to be critical. For the latter there are a few reasons for this - one becoming blind, or forgiving/accepting of some small “quirks”, the other is there becomes a conflict of interests to an extent where they don’t want to upset the project (raather than keeping the role of being the straight talking truth teller in the team).

How have you trained others to think critically of a product? Or how do you train yourselves? How do you maintain that “thinking distance”?

1 Like

I like to do online-test-labs which require you to think outside of the box. Most are security related but they keep your mind sharp and makes your think how to not use a product which is a very nice skill for a tester.

Besides my 9-5 day job I also volunteer for testing for companies (software/video games etc) so I’m pretty much into it 24/7. Testing video games vs software is also a nice addon to keep your mind sharp. Trying to find exploits for infinite amount of coins or strategies to have “unlimited X or Y”.

I’ve had things done in video games that I said, maybe if I tweak it here or there, I can do it on my project also. So by seeing new and other technologies then your current project, you’ll expand your knowledge and testing capabilities to uncover more scenario’s / test cases.

Takes a while to realise its the other way around - You getting into the product, loving it, wants you to give the end user the best possible product and thats by getting what the programmers develop right. And the team loves it. Its by enhancing the quality you add value to that great piece of SW.

Testopsies can help with that:
Either watching others testing and explain their testing or having to explain your own testing (and get feedback on that) can help to trigger learning of critical thinking; because it will generate stories about critical thinking - the person can remember the situation and apply the different approaches and thinking patterns.

Hey there @testerfromliverpool!

Critical thinking is for sure a hard one to teach. I’d consider it a technical testing skill more than a soft skill, with the soft skill being around communicativeness and speaking out. In the past I’ve used and seen these things working:

  • Running training around how to create, or think about, risks for a product (maybe using risk storming).
  • Posting testing brain teasers in slack channels to encourage people to start thinking about things. I think @danashby has a good stock of these.
  • Training people on communications techniques like active listening and asking questions.
  • Training people on 3amigos and the role testers have in this to ask questions.

With regards to “getting too close”, there’s definitely an issue with comfort testing in the industry. Testers not thinking about new things and focusing on what they already knew, the old “we’ve always done it like this…”. As testers, we need to be able to subject new features / products to risk analysis, so it could be worth having sessions across teams where all testers look at one product… maybe the embedded tester will see more risks based on what their peers come up with.

Also remember, if the product team / organisation don’t care about an issue then that issues doesn’t matter. There’s nothing wrong with forgiving a small quirk that’s been exposed to the business and agreed as not important… pragmatism is good :slight_smile: