Skip to main content

TESTER PERCEPTION - PART 3

Its been a while since I have last blogged, its been hectic for one reason or another but I find myself with a bit more time so I can finish this series of blog posts.

In this post I will complete the set of posts on testers perception. This post will describe ways in which testers can change how they are interpreted. Testers can change how they are interpreted by showing how they add value by changing their behaviours.

Below are a few ways we can change how we are perceived as testers, 

1) Don't shout louder, improve your argument

Shouting louder than anyone else does not necessarily always work. We've all been there, you get quite heated in a discussion about a subject that you feel passionate about and someone else does the same and it all ends in disagreements and potentially damaged relationships. You need to think smarter. If you feel passionately about something on a project then do some research. Come up for valid reasons why you want something to be different.Try and find someone who agrees with you and work together to build a well formed argument around why this change would be good.

2) Use Socratic questioning

"The unexamined life is not worth living" - Socrates

Socratic questioning is disciplined questioning that can be used to pursue thought in many directions and purposes. This includes: 
  • to explore complex idea,
  • get to the truth of things
  • open up issues and problems
  • uncover assumption........ as well as many others. 

It is linked to critical thinking and is used for teaching to probe students thinking. It can be a useful tool for a tester as by asking the right questions. We can uncover things like:
  • Assumptions made by users and developers
  • Why a user wants a particular feature
By using this style of questioning we change how we are perceived as we can do things like  help uncover issues before code is written as well as catch bugs early If a developer or user has made the wrong assumption. 

3) Hold Lunch for Learnings

Lunch for learnings are a great way (in an informal) setting of getting people together and doing an info share about a particular topic. You could do a session on an aspect of testing that the audience don't know about. If your development team think that testing is just a matter of writing you tests cases in Excel with detailed steps, then do a lunch for learning on Exploratory testing. These kind of sessions will educate other people in your business about testing and this in turn can help change their perceptions about what you do. Hopefully some people will want to know more and this in turn could develop into relationships that will help the testing process going forward.

If you are having trouble getting people to attend, just offer Pizza that always seems to work, :)

4) Pair up with a developer

Just because as a tester you may not be able to code does not mean you cannot be a valuable asset to a developer. To foster this a good idea is to try and pair with a developer whist they are writing the code. If possible they can talk you through what they are doing and you can question this. This questioning could be something simple like "Wouldn't that be useful to log that out put?" or something that could mitigate the risk of a bug  like "What if the users mobile phones loses signal when they enter data on that screen?"

This pairing will soon help the developer to realise that you input is vital to help develop an application with quality ingrained in it. 

Not all developer are willing to do this but you should start small by maybe just asking a quick question about the code in passing then slowly trying to get some time with them.

5) Advocate building quality into the product from the start

To do this you need to encourage certain practices into the development process. This may be more of a company culture 'thing' but that does not mean that you cannot be an advocate for it. This could include doing things such as:
  • Getting involved in sprint planning
  • Sitting in on code design sessions
  • Helping to write user stories
the list goes on.....but by doing some of these you can demonstrate value by contributing and highlighting testing aspects that may not of been thought of. As a tester you probably have more experience than most in the UI (If there is one) and the overall functionality of the system, so you are 
full of useful knowledge that can be tapped into to help build quality in

Summary
Now the above points are just a few ways that you can add value which in turn can change how you are perceived as a person and a tester. There are more things you can do and some of these will be things that are less general and more specific to your company. 

It may be that you already feel valued and you are happy with how others perceive you, and if so keep doing what you are doing. However if you do not then you need to take some action to rectify it. We spend most of our lives with our work colleges and feeling appreciated and feeling like you are a valued contributor can make your days a lot more enjoyable. 






Comments

Popular posts from this blog

Testing and Mindfulness

How aware are you? Do you live in the here and now or is your mind always somewhere else? This blog post is about Mindfulness. Mindfulness is a simple meditation and is defined as (According to Wikipedia): "The intentional, accepting and non-judgemental focus of one's attention on the emotions, thoughts and sensations occurring in the present moment" Now Mindfulness has become more popular in the west in recent years as it has shown to have benefits for people who are suffering from Depression and Anxiety. It has been around for a while and is often thought to of originated from Buddhism and some people believe it started thousands of years ago. Now modern life is hectic and I’m sure we all have lots of things going on in our lives that keep our Brains busy and trying to focus on one thing at a time can be a challenge. I can't remember the number of times I've been doing something and my mind is somewhere else entirely. Mindfuln...

How to deal with pauses and timeouts in specflow

So this blogpost is in response to the weekly Specflow blog posts and challenges that have been written by Gojko Adzic. This weeks challenge was how would you rewrite or rephrase the below scenario: Given a user registers successfully When the account page reloads And the user waits 2 seconds Then the account page displays "Account approved" My initial though was something like this: Given a user registers successfully  When the account page reloads   Then the account page is displayed within a satisfactory time period     And the account page displays "Account Approved" Now the problem with this scenario is what defines a satisfactory time? You could add it as a comment or in a scenario outline but over time the time a user waits could change and if this is updated in the code behind but the scenario outline or comments are not, then what the test does and what is described do not match - this would potentially cause issues in the future. My next ide...

Building a test strategy for a new team

Teams, we have all been on them. Some are good and some are bad. Some we never wanted to leave and others we probably couldn't wait to leave. Now most of the time (well in my experience anyway) you tend to get put into a team that already exists. Maybe you are a new hire or maybe you have asked to change to a different product team.  When you do this, more than likely there will already be a testing strategy in place. It may be that you adapt it and change it in any way you see fit to improve the testing. But imagine if everyone on the team was new? How would you decide your testing strategy? This post will go through some useful things you can do to help a new team develop a test strategy. Table of Contents ๐Ÿ“ˆ What is a Test Strategy? ๐Ÿค” Where should I start? ๐ŸŽฏ Understand the company and their goals ๐Ÿ’ช Play to the teams strengths ๐Ÿ‘️‍๐Ÿ—จ️ Understand what quality looks like ๐Ÿ“ Understand Scope ๐Ÿงช Understand the type of tests you need ๐Ÿ“Š Measure your success ๐Ÿค Collaborate ๐Ÿ“ Summar...