Showing posts with label skills. Show all posts
Showing posts with label skills. Show all posts

Wednesday, 20 July 2016

What do we mean by testers learning to be technical?

I recently read a post by Justin Rohrman entitled "Do testers need to code".  The following line gave me some concerns:

"So, I think that testers do need to learn some programming skills now."

Now I wish to begin by stating I am not against testers learning to code  if that is something they are interested in and they want to learn.  On the other hand it may not be the best value skill you could bring to a team, especially if you already have 5-6 exceptional coders on your team.   Justin within the article tries to align to this thought with the following:

"My new feeling is that testers need to learn to program, or at least become more technical –write SQL, use developer tools effectively, read code — for any sort of longevity in the field. "

I have blogged about this in the past- 'A discussion on do tester really need to code.' in which I talk about adding value by learning the syntax of code.  I was asked on twitter by Marcel Gehlen to provide an example of what I meant by this.  I replied with the following:

'I understand the syntax of the french language but I am terrible at speaking it.'
The main point of this update to the 'testers need to code' debate is around what we mean by being 'more technical'?  To the majority of people and from the many articles I come across this implies learning to code.  I feel this is too narrow and at the same time limits the potential and opportunities testers may have.  As an example if you now have a team in which everyone can code and there is a need to reduce the team due to financial and business pressures.   If the decision being made is based upon coding skills then I feel testers could be at risk.

Where does this learning to code end?    In the modern development world of 'devops' are we now going to state that operational people and marketing people should now learn to code?  we could end up with an over saturated market of half decent coders.  What skills are going to make testers stand out and be seen to be adding both team and business value?

Taking a step back what do we mean by coding?

I can writing scripts in bash which to me is similar to writing test script in the sense of logical following steps.  At the same time I understand the command line interface to enable me to deploy a test environment.  Going forward into the devops model I can write dockerfiles to create containers..

#
# Super simple example of a Dockerfile
#
FROM ubuntu:latest
MAINTAINER Andrew Odewahn "odewahn@oreilly.com"

RUN apt-get update
RUN apt-get install -y python python-pip wget
RUN pip install Flask

ADD hello.py /home/hello.py

WORKDIR /home

Example from http://odewahn.github.io/docker-jumpstart/building-images-with-dockerfiles.html

I understand how to use ansible to deploy an environment to enable me to test and run automated checks.

These are, what many would class as, highly technical skills.  However as Jerry Weinberg just posted about 'Becoming a Better programmer; ' there are other skills that are of value to a team and to the business that many would not class as technical.  The ability to get people to work well together and collaborate and communicate is a highly desirable skill to have.  Since it is classed as a soft skill not a lot of emphasis is placed upon this as a skill testers should learn.

What about analytical skills, as more and more companies move to a devops model for software delivery, the skill of being able to determine patterns within the software from all the data and collate that data to help improve try and improve the quality is a highly demanding and technically challenging skill.  I can see this skill becoming highly desirable in the future.  Maybe a tester could invest their time learning this skill?

Then we have the other areas such as an understanding of human behavior to help influence the design .  Learning about social science and systems thinking to help see the big picture and overcome obstacles for the team.   I have been running a series of blog posts on skills testers should learn away from the traditional 'must code' school of thought.  Using your time wisely to practice and improve these skills can help you become a better tester and more importantly show your value to the business.

A few examples are given below (feel free to browse my blog for other examples)




Also with your testing skill set you could mentor, coach and teach others about testing and how they can use that to help improve the software.  Set yourself a goal of coaching the programmers in simple test techniques that they could look to add to their frameworks to enable you to focus more on the difficult to find issues using exploratory testing .

Again I wish to state I am not against tester learning and if they feel they have a passion towards coding then go and do it.   At the same time think about what else they could learn that adds both team and business value.




Thursday, 23 June 2016

Testing Skills #10 - Persuasion and Selling

Like it or not everyone is now a salesperson.

As Daniel Pink states in his book 'To Sell is Human':

"If you spend any of your time both personal or in work "persuading, influencing, and convincing others," you're in sales."

The world of work is changing as described by Peter Drucker:

"The world of work is changing from one of manual workers to a world  of knowledge workers"
 Landmarks of Tomorrow

With this world comes the need to be able to persuade and sell to others.

“To sell well is to convince someone else to part with resources—not to deprive that person, but to leave him better off in the end.”
Daniel H. Pink, To Sell Is Human: The Surprising Truth About Moving Others

We all now have to sell our ideas and convince others that our ideas are sound and the right ideas.  How often have you needed to sell the testing you are performing?  Or persuade someone that a defect really does need to be fixed?

Having these skills is crucial for testers to be able to carry our their daily testing activities.

What follows are some tips on how to persuade and sell to others with a focal on selling testing.

The first tip is to be able to ask the right questions rather than try to provide answer.  This to some may appear simple however as Daniel Pink states:

“In the new world of sales, being able to ask the right questions is more valuable than producing the right answers. Unfortunately, our schools often have the opposite emphasis. They teach us how to answer, but not how to ask.”
Daniel H. Pink, To Sell Is Human: The Surprising Truth About Moving Others

When selling testing it is not that important to explain the technicalities of testing and how you go and do this.  This is vitally important when talking about testing to senior management.  Instead ask questions such as:

  • What do you see as the biggest risk for this product?
  • Where is our revenue going to come from with this product?
  • Is there anything about this product that gives you sleepless nights?
By asking these types of questions you can then use the information provided to reassure the person how testing may be of value in this situations. Sell less about testing and more about what it may do to support the business needs.

At the same time their is a need to be able to persuade people about doing the right testing.  This could be other peers and colleagues.  In these situations it is not about selling but about showing to people the value of testing by doing.  Working closely alongside people so they can see in real time the benefits of the testing that is being performed goes a long way to helping to persuade people. The art of persuading is more based on showing by doing rather than by trying to sell an idea.  If you are in a situation as a tester to be given an opportunity show the value of testing, lead by utilizing practical examples rather than explaining theory.  People are more easily persuaded by examples they can relate to rather than a theoretical example that has no relevance to them.

To conclude it is important for testers to have the ability to sell the benefits of testing and the skill to persuade others of these benefits.   Selling testing will normally mean not talk about testing but the value testing can bring in terms of bottom line and risk.  Persuading others of the benefit of testing is more about showing what testing is and how it can add value.  To get better at either of these skills you need to practice and practice and practice even more.  Try and get others you are comfortable with to help you to practice and give you feedback on your selling and persuasion skills.

Tuesday, 15 September 2015

Testing skills - Abductive Reasoning

This is the first in a series of hopefully short articles which looks at  skills and techniques outside the traditional testing that can be useful to those who practice testing.

Future topics planned include:

  • Influencing by listening
  • Note Taking
  • Leading teams
  • Persuasion and how to sell
  • Speaking the language of business 
  • Remote teaching experiential style
  • Going beyond the model
If you can think of any others that would be useful please leave a comment. 

I am making these public,  since by writing it down and making it public I am committing myself to do it.  That is your first tip in this article, if you want to commit to doing something which you keep putting off, writing it down and make it public.

Abductive Reasoning.

 Abduction came about from the work of Jo Reichert, in this work Reichertz came up with another cognitive logic process to describe discovery when the researcher encountered surprising findings in the data. He called this "a cognitive logic of discovery".  Before this there were two types of reasoning in common use, 'inductive' and 'deductive'.
  • Inductive - Making generalized conclusions from specific observations
  • Deductive - Proving or disproving a theory from observations (scientific method)
Abductive reasoning is an important process for those involved in testing.  The majority of time when we are testing we discover surprising behavior in the software.  This normally makes us rethink our theories of how the software works and as such we begin to re-evaluate our understanding of the software.  We create a new rule, or test idea to further investigate the surprising element of what we have just tested. This is key within grounded theory; our thoughts about the software and how it behaves change as we explore the software more.  How we report these surprises and the behavior of the software is crucial to the value that testers provide to a project.
"There are two strategies involved in abduction, both of which require creating the conditions in order for abductive reasoning to take place"* (Reichertz, 2007: 221). 
The first is a ‘self-induced emergency  situation’ (Reichertz, 2007: 221). This means that in the face of not knowing what to make of a surprising finding, rather than dwelling on the infinite number of  possibilities, the analyst puts pressure on themselves to act by committing to a single meaning.
The second strategy is completely antithetical to the first. It involves letting your mind wander without any specific goal in mind, or what Pierce (1931–1935), a key writer on abduction, called ‘musement’* (Reichertz, 2007: 221). "
Qualitative Research Methods in Psychology: From core to combined approaches - Nollaig Frost - 2011.
Reichertz makes the following observation about these two strategies.
"What these two quite antithetical strategies have in common is tricking the thinking patterns of the conscious mind in order to create ‘an attitude of preparedness to abandon old convictions and to seek new ones."
 The SAGE Handbook of Grounded Theory:(Sage Handbooks) - Antony Bryant, Kathy Charmaz  - 2010.
Testers need to be able to abandon their old convictions and seek out new ones.  This is especially important when we are testing software, since our biases and beliefs and previous experiences can influence our decision making. Using some of the methods described in this book can allow us to challenge our thinking about the software and engage in abductive reasoning.

One famous use of abductive reasoning is that used by the fictional detective Sherlock Holmes by Sir Arthur Conan Doyle.  Many people believe, wrongly, that Sherlock Holmes uses deductive reasoning to solve his cases, when in reality he used abductive reasoning.
"Holmes' method doesn't resemble deductive reasoning at all. Instead, it's much more similar to a form of reasoning known as "Abductive Reasoning"Debunking Sherlock Holmes Myths - Maiza Strange  May 2014
To summarise abductive reasoning is taking your best guess based upon your current knowledge, observations and experiments.  These pieces of information maybe incomplete but you use your cognitive reasoning processes to form a theory or conclusion.  For example:
"A medical diagnosis is an application of abductive reasoning: given this set of symptoms, what is the diagnosis that would best explain most of them? Likewise, when jurors hear evidence in a criminal case, they must consider whether the prosecution or the defense has the best explanation to cover all the points of evidence. While there may be no certainty about their verdict, since there may exist additional evidence that was not admitted in the case, they make their best guess based on what they know."Deductive, Inductive and Abductive Reasoning - Butte College.
This article has been taken from the Testing and the Social Science chapter in my book - The psychology of Software #Testing.


Monday, 24 June 2013

Testing Your Career Path

I have had an article published on the Test Planet website

http://www.ministryoftesting.com/2013/06/testing-your-career-path/

It is a look at the perception of testing and what options testers have with regards to progressing their career.