Skip to main content

Key characteristics that help me be a good tester

I recently took part in a PI assessment, for those that don't know what a PI assessment is, it's a behavioural assessment, the PI stands for Predictive Index. It asked 2 questions, and asked you to tick words that describe how you feel in reference to the questions. 

The questions were (something like) :

- Describe how you view yourself
- Describe how you behave in your work environment

You then had to tick as many words that you felt applied to the question. 

I'm going to take the results of the assessment and hopefully try and explain how this applies to testing and how it makes me a good tester, also how it highlights things that I feel that I need to work on.


The first part is to analyse your natural behaviours:

·         You are a team orientated person, co-operative and agreeable you seek harmony where you can. - I think this helps especially in working in an agile environment, where we work in such a close knit team, it's important to be co-operative and a team orientated person to help get work done.
·         You are sociable, easy-going and work best when you are in a familiar environment/team. 
·         You are trusting of others so feel comfortable delegating work/authority – only when are familiar with them, it takes time before you truly trust people. Your empathy to others means you often unselfishly show interest in others, you teach and share ideas/thoughts openly and freely. I think that this helps in mentoring others and develop other individuals, so not really testing related, but more about being a senior member of a team. Perhaps I could work on the trust issue, in that I could be more open and delegate tasks more freely, so I will look to work on this.
·         You are patient, calm and consistent which makes you dependable to others. This is useful when being a tester, as the last thing you want to do is panic when things could/can go wrong! A calming influence can help teams stay calm and working towards a goal.
·         You tend to avoid risks, preferring to do things by the book I would possibly disagree with this to a degree, I do tend to avoid risks, but I don't always perhaps do things by the book unless it's something I believe in. 
-  this is due to your attention to detail. You are accurate and careful with detail – meaning you can sometimes be cautious/conservative. I think this is always good for a tester to have! :)
·         When making decisions, you are very objective – needing all the facts in order to make a well balanced decision – some may say that your decisions are black or white. This comes in handy when coming up with a risk based approach to testing, when deciding what tests to run. I do disagree slightly with the decisions being black and white, I am open to negotiating!
·         You are motivated by encouragement, team recognition and freedom from risky decisions.
·         You are happier in a stable work environment and work better where there is certainty and you have specific knowledge of the job you are doing. I definitely agree with this, and this is possibly one of the reasons I haven't gone contracting yet, I like knowing what I am going to be doing, I like being a part of a team. 
·         The PI also suggest that you have a rather low mental energy – meaning you tend to burn out if you don’t get regular breaks from what you are doing.

Next is to look at your self-concept – this is essentially how you are behaving in your current environment. This shows that:
·         You are perhaps working at a more intense/faster pace than you would naturally. You are dealing with more variety and change than you would prefer. Suggesting that you are putting more pressure on yourself. This was weird as I've just changed roles, so is definitely something that I am dealing with at the minute, I'd like to think I'm coping though! And not putting too much pressure on myself!
·         Whilst you like detail, this suggests you are maybe having to be more detail orientated than you would normally. You are having to adjust to a more structured and controlled environment and as such being more formal and more individually involved – which goes against your natural team style. Again, with the new role, the team do seem more structured and it is a more controlled environment to what I was used to before, but I wouldn't say this is a negative, but it is strange not being a part of such a strong team.
·         Due to the adaptations you are making, this suggests that your morale is slightly low. I wouldn't say my morale is low, I'm enjoying what I am doing, there are things that I am missing, such as the team ethic, but I enjoy the challenge of the day to day role.


So that's pretty much it. I think it was pretty eye opening, and I do agree with the vast majority of it, and some of the characteristics, as discussed above do help me excel in testing.

What characteristics do you think are good to have as a tester? I often see people say testers need to be negative, but I strongly disagree with this, we don't have to be negative, we can be positive, but so long as we are objective and not positive without due cause!



Comments

Popular posts from this blog

Coding something simple.... or not! Taking a screenshot on error using Selenium WebDriver

I recently wrote a little function that takes a screenshot at the end of a test if it has errored. What sounded very simple at the start turned out to be quite a bit of work, and quite a few lines of code to handle certain scenarios! It's now over 50 lines of code! I'll start with what I had at the beginning, this was to simply take a screenshot in the working directory, we are using SpecFlow and Selenium to run the tests, so we are going to check if the ScenarioContext.Current.TestError isn't null, if it is, then using Selenium, take a screenshot (note the below code is a simplified version of what I had at the beginning). [AfterScenario]         public static void TakeScreenShotOnError()         {             if (ScenarioContext.Current.TestError == null) return;             var screenshotDriver = Driver as ITakesScreenshot;             if (screenshotD...

How to manage resources within new teams?

Working where I work we are constantly spinning up new teams to take on new workloads as business come up with new demands and new features they want developed and tested. The problem with this is how do we ensure the work of the newly spun up team is of sufficient quality. One method is by taking people from other established teams and placing them on the new team. This works great for the new team, but unfortunately it will oftenl eave the established team lacking in a resource whilst they try and fill the gap left by the person who has left. We are seeing this often with our offshore teams, it can be damaging to the team structure and the teams velocity, but try as I might, I can't think of another way around it. It's far easier to take 1 person from a team that is established than it is to build a whole new team from scratch. At least by leaving the core of a team in place, you should be guaranteeing that the new team are aware of any coding standards or any QA standard...

Considerations when creating automated tests

We recently released to a number of teams our automated regression pack that has been worked on over the past few months. This regression pack tests legacy code, but contains a large number of tests.  As a bit of background, a number of teams are working on new solutions whilst some are still working on legacy code. With this in mind we constructed an email with a list of guidelines when creating new tests that need to be added to this regression pack.  I figured that these can be quite broad so should apply for any organisation, so thought it would make an interesting blog post...  So here goes,  when creating automated tests, it's important to consider and adhere to the following: - Think about data . The tests need to retrieve or set the data they need without any manual intervention - This should help them be more robust and easier to run without manual intervention. - The tests need to be idempotent - By making it so that each test is standalone and does...