Tuesday 5 January 2021

Publications and Public Speaking engagements

 The follow is a list of publications and public speaking engagements that I have done in the past.


PUBLICATIONS


PUBLIC SPEAKING ENGAGEMENTS


Posted by at No comments:
Labels: , , ,

Tuesday 27 February 2018

It has been a long time....

My last post on this blog was in June 2017 and now I think it is time to explain to those who subscribe to my blog the reasons why there has been little information.

It has taken me a long time to be able to put this in public but I now feel the time is right.

At the beginning of 2017 I started to suffer from panic attacks and feeling quite insecure in public places.   It took me awhile to get this sorted with some medication but at this time I feel much better.

During the spring/summer time I started to suffer pains in my joints which got to a point it became difficult to walk so after many tests (ironic pause) I was diagnosed with Rheumatoid Arthritis which means a lifetime of drugs and some weird side effects.from such drugs.  It has taken a good 3-4 months to get that under control.

Then at Christmas 2017 everything started to fall apart first my sister in law was diagnosed with Breast Cancer which has required surgery and all the after effects that entails. 

Then on top of that during a routine checkup my wife, Tracy, was also diagnosed with breast cancer.  The cancer type she has is very fast growing and aggressive and Tracy has now started a regime of chemo before surgery.  With all the side effects this brings on, hair loss, very distressing for Tracy, sickness, tiredness and numerous more. 

I am currently contacting the writers of all the soap operas to suggest this as a story line no-one would believe. We have all managed to keep a fairly warped sense of humor during all of this. 

I hope this explains why I have been very quiet in the community and will be for the foreseeable future. 

On a side note a friend of the family has decided then since both my wife and her sister got diagnosed with  Breast cancer at nearly the same time they are going to do the Great North Run in aid of Breast Cancer care.  Details of this can be found here.


I am not asking people to donate but if you feel you would like to then please feel free to do so.

Posted by at 3 comments:
Labels: , , ,

Monday 5 June 2017

Usage of words

I came across the following tweet:


I tried to reply on Twitter but the message I tried to portray did not come across in the way I wanted it to.

Disclaimer:  I am not, nor ever have been a member of any cult.

 Marlenas' words came across very strongly and appear to be based upon their negative experience when encountering discussions on the use of these words.  Others stepped in with their own experiences and the main message seems to be that the use of these words have been to derailed important discussions.  I find that a shame, since to me the distinction with these words has been useful to help talk to executives and others from outside the testing world about the risks of unfocused automation and testing.

My concern in the statement by Marlena is that the distinction is of low value  and a semantic argument.   Semantics and the meaning of words is vital for society to be able to flourish and this has been going on for a long time.  People have argued over what certain words mean and over time the meaning of some words change.  Some are taken over to deride or insult people and sometimes these words are reclaimed by those who are being insulted.  For example the word "Queer" to some this is a hostile word to others it is a badge of honor.

I worked in Israel for awhile and often would get strange looks when running workshops and replying to a question I would say 'smallish' It was awhile before I figured out that 'ish; is Hebrew for 'man' and I was saying 'small man'.  Culturally words can have different meaning and cause confusion, the same can be said of the words'checking 'and 'testing'  Using these words in the right situation and context to inform and have a discussion can be useful however if used to make a point or win an argument it becomes less useful.  If used in an attempt to show superior intellect then the discussion is already lost.

I use the distinction between the words when discussing the testing effort.  How much checking has been done against the amount of testing that has been done.  How much effort have we spent on putting in place explicit knowledge, information we feel we know, against the effort on information that we do not know, tacit.  Knowing the difference between these two items can be vital to help mitigate risk.  If all the effort and money is being spent on checking with very little testing then there could be a risk that something we do not know could be dangerous.  Unless we spend a little more effort on testing to uncover more of what we do not already know then there is unknown risks.  Another example could be that the product is mature and changes are minor so more effort is put into the checking.

For me having these meanings helps to inform and tell a story.  I do not use them to score points or be a member of a cult I use them because they have a value to me in my context.  I do not really care if you use these words or not.  I have explained how I use them and the usefulness I find in them.  Yes I will discuss with people why I feel the distinction has value but at the same time I respect others opinions and viewpoints.  To me it is a useful tool to be able to communicate with teams around the world.


Posted by at No comments:
Labels: , , , , , , ,

Wednesday 26 April 2017

A test is...

On twitter Santhosh Tuppad posted the following tweet:



It made me think about what 'a test' really is.

I made half an attempt to improve the statement Santhosh made and suggested the following:


This would make the statement read as following:
A Test is an experiment that tests to see if the testing yields observational information.
I have thought about this and it still does not appear quite right for what I would say is a test.

There have been many discussions on what testing is and how 'a test' relates to the testing.

A test is a part of testing as some of the links above state, therefore the definitions used for testing could apply to a test.  However there is a gap if you are communicating with someone and they ask you 'What is a test?'  What is your reply?  'Oh, it is a part of testing'  Hence thanks to Santhosh I wanted to look a little more into the definition of a test.

My thoughts is that for a definition of a test we should borrow from the scientific method.

You start with a theory, you run a series of experiments against that theory, you observe what happens, you analyse what you saw, you report the findings and adjust your theory based upon your new knowledge.

There is no mention of finding bugs within that process, looking at a dictionary definition of test it gives the following:


a critical examination, observation, or evaluation :  trial; specifically :  the procedure of submitting a statement to such conditions or operations as will lead to its proof or disproof or to its acceptance or rejection a test of a statistical hypothesis (2) :  a basis for evaluation :  criterion 
 an ordeal or oath required as proof of conformity with a set of beliefs 
a means of testing: such as (1) :  a procedure, reaction, or reagent used to identify or characterize a substance or constituent (2) :  something (such as a series of questions or exercises) for measuring the skill, knowledge, intelligence, capacities, or aptitudes of an individual or group 
 a positive result in such a test 
:a result or value determined by testing


Wow so many different meaning for a simple word!  

To aid the definition it needs context.

We are focusing on a software test, this enables us to narrow the definition of 'a test'. Note we are not using the term 'test case'.  Using 'test case' I feel encourages limitations in the scope of what a test means.

To conclude the following is my definition of 'a test' within the context of software testing.

A test is a series of experiments performed against a theory that evolves based upon observational and behavioral information uncovered by the test.
The software testing part is the reporting of these evolving theories and the observation made.

What about you?  Could you improve this?  Do you have your own definition?



Posted by at No comments:
Labels: , , , , , , ,

Monday 24 April 2017

Fake News!



It has been a long time since my last post and I apologize, there have been many factors as to why this has been the case some to do with work load and others to do with my health.  Suffice to say I may not publish as often but I still want to get out into the public domain information that others may found useful.

The topic for this post is to do with the current wave of 'fake news' articles and how this may have influenced people and persuaded them to make decisions different from what they may have made if they had not seen such articles.

The concern is that there appears to be little critical thinking done around these stories by those who read them or watch them on the 'news' channels. These articles appeal to peoples biases either via 'confirmation bias'  (What is confirmation bias? - https://www.psychologytoday.com/blog/science-choice/201504/what-is-confirmation-bias) or appeal to authority.  (What is appeal to authority - https://yourlogicalfallacyis.com/appeal-to-authority)  Humans are easily duped or mislead and it requires conscious effort to overcome these fallacies and others.  There are many fallacies that we fall prey to and the following has a good list and description of them - http://www.webpages.uidaho.edu/eng207-td/Logic%20and%20Analysis/most_common_logical_fallacies.htm.

There are many guidelines and techniques that can be used to overcome such fallacies and clarify what is truthful or not.

One easy method is to look at the source of the information.

  • Is the source reliable?  
  • Does it come from multiple sources?  
  • Does the source have an undisclosed agenda? 
  • Can the information be verified independently?
Critically analyzing the information presented can help you make better judgement on  what is being said.

The following are a couple of techniques for critical thinking that I came across and are included in my book The Psychology of Software Testing

The 5 W's and H

Another technique, often used in journalism, is the five W's and one H.  The five W's are Who, What, When, Where and Why, The H is How.

The five Ws and one H have been immortalized in the poem 'I Keep Six Honest Serving Men' by Rudyard Kipling.
I KEEP six honest serving-men
They taught me all I knew; 
Their names are What and Why and When And How and Where and Who.
I send them over land and sea,
I send them east and west;
But after they have worked for me,I give them all a rest.    
I let them rest from nine till five,
For I am busy then,As well as breakfast, lunch, and tea,
For they are hungry men.
But different folk have different views; know a person small
She keeps ten million serving-men,
Who get no rest at all!  
She sends'em abroad on her own affairs,
From the second she opens her eyes
One million Hows, two million Wheres,And seven million Whys!    

The five W's and One H are a series of questions used to get the complete story, hence its use in journalism.  

Reporting on the 3 Little pigs story
  • Who was involved? 
    • The three little pigs (the first pig, the second pig and the third pig) and The Big Bad Wolf (a.k.a. Wolf).
  • What happened?
    •  Each pig constructed a house out of different materials (straw, sticks and bricks). Wolf (allegedly) threatened to blow over their houses and is believed to have destroyed both the straw and stick homes at this time. Pig one and two were able to flee to the brick house, where they remain at the moment. We’re still waiting to hear from local authorities, but it looks like the Wolf may have been injured while attempting to enter the brick house.
  • Where did it take place?
    • Outside a straw house, a stick house and a brick house.
  • When did it take place? 
    • At various times throughout the day.
  • Why did it happen? 
    • Apparently the Big Bad Wolf was trying to eat the pigs. Several eyewitnesses recall the Wolf taunting the pigs before he destroyed the straw and stick homes by chanting, “Little pigs, little pigs, let me in.” The pigs apparently scoffed at the Wolf’s idle treats, saying “Not by the hair of our chinny, chin chins.” It’s believed this angered the Wolf and led to him blowing the houses down.
  • How did it happen? 
    • It would appear the first two homes were not built to withstand the Wolf’s powerful breath. The incident inside the brick house is still being investigated, but early indications suggest the Wolf fell into a boiling pot of water when trying to enter the house through the chimney.


If you read any articles and it does not appear to follow this journalistic technique would be cause for concern as to its truthfulness.  You may want to delve deeper and see if the article is accurate and independent in its reporting.  

16 Steps to become a critical thinker

The following set of steps are based upon the article 'Intro to Logic: Techniques of Critical Thinking'.  
It is a useful critical thinking exercise to examine each of these steps and rewrite them to form your own set of steps to enable critical thinking.
  • Clarify
    • Ask questions to clarify what is being said.  Simplify to aid clarity.
  • Be accurate.
    • Facts can only be in the past.  Is anything in the statement making future predictions?  If so this is not fact.  Are the facts correct? Is there any factual evidence to back up the statement?
  • Be precise.
    • Make sure what is being said is accurate, try to avoid ambiguity.
  • Be relevant.
    • Make sure to stick to the issue under discussion, avoid falling for strawman or other fallacies.
  • Know your purpose.
    • Figure out what the most important thing is in the discussion.  Try to remove any related but not relevant information (see 'be relevant' above).
  • Identify assumptions.
    • When involved in critical thinking it is important to be aware that all thinking is based upon some level of assumption. Try to identify these assumptions.
  • Check your emotions.
    • Emotion can directly affect our critical thinking.  Try to keep emotions under control when discussing issues.  Ask yourself are my emotions influencing my judgement?
  • Empathize.
    • Look at what a person is saying from their viewpoint.  Try to put yourself in their shoes, how would you feel if someone spoke to you in the way in which you are speaking to them.
  • Know your own ignorance.
    • Know your level of knowledge. You do not know everything and what you do know may be wrong. Be gracious when someone proves you wrong, learn from being wrong.
  • Be independent.
    • Do not follow the crowd.  Verify information with dependent thought.  Do your own research to verify what is being claimed. 
    • Laurent Bossavit has a wonderful book on this subject called The Leprechauns of Software Engineering
  • Think through implications.
    • Look at what is being claimed and see what the implications of this claim could be.  Look for alternative implications, both negative and positive.
  • Know your own biases.
    • Being aware of your biases is crucial when involved in critical thinking.  How are they affecting your judgement? Are they affecting your judgement of others?
  • Suspend judgement.
    • Do not arrive at a conclusion and then try to find reasons that support your conclusion.  Use the scientific method as discussed earlier in this chapter. Form a theory on how it should work and then attempt to find ways to disprove your theory. 
  • Consider the opposition
    • Look for alternative and opposite perspectives.   Do not base your conclusion from one source.  Look for sources that disagree with the first source.
  • Recognize cultural assumptions.
    • Be conscious of stereotyping and cultural bias.  It does not mean if someone is from a different culture or period in time that their views are any less greater than your own.
  • Be fair, not selfish.
    • We are naturally selfish creatures and find it hard to be wrong and admit our mistakes.  Be fair with yourself and others, look for selfish traits in yourself and others.

Some links:

Speaking events.

I am due to speak at a couple of events this year.


Posted by at No comments:
Labels: , , , , , ,

Monday 17 October 2016

Debating and challenging.

“The smart way to keep people passive and obedient is to strictly limit the spectrum of acceptable opinion, but allow very lively debate within that spectrum....” 
― Noam Chomsky, The Common Good
There has been a lot of debate, posts and discussions about what is acceptable and not acceptable within the testing community recently and it makes me feel sad and unhappy.  Some appear to have disintegrated into personal attacks and the message has been lost and to me that feels wrong.  Could things have been worded differently?  Of course and hindsight is a wonderful thing.   I am not going to go into detail of these discussions or state who was right or who was wrong.  You can form your own opinions and look up the discussions yourself.

 What I will say is we have to be careful as a community of  limiting the ability to challenge ourselves and allowing others to challenge us.  This should be done respectably  and with the purpose of trying to help us all learn without it becoming a personal attack and counter attack.  As the above quote states if we want to be passive and obedient then sure let us limit what can and cannot be said.  what is seen as acceptable to someone may not be so acceptable to others.  In the same way each individual has their own perspective of what quality is:

"quality is of value to a person" - Jerry Weinberg

I am not closed to the fact that as humans we will often disagree passionately with each other and to me that is OK, however once emotions are involved it can lead to some behaviors which  are not so pleasant. Maybe if you feel in these situations it is best to step back and think before replying.  I try to do that a lot and hence my delay in writing this post.

As individuals we will see the same thing in a different way, hear the same words differently and read into what someone is doing wrongly, hence the unreliability of eye witness in court trials. We may say things which we feel is right  at the time which has unintentional results .   Allowing time for people to explain their intentions and what they meant, is to me respecting each other.   The outcome from this maybe an apology, correction of facts or better clarification of what was meant.

I have to believe that in our community people do not deliberately try to hurt or upset others  however I feel as a community we need to challenge ourselves and others to improve our knowledge and skills.

Let us respect each other even if we do not agree, otherwise people will use this to limit what can and cannot be debated and decide for us what is acceptable to challenge.  At the same time using this to limit what we can and cannot read, listen to and who we can talk to.   To me this starts to become like 1984 and big brother.

To finish we may not always agree with each other but sometimes as the song in Frozen goes we have to

"Let it go"

If the worst thing you get from this post is having that song in your head all day then my job is done. :o)
Posted by at 2 comments:
Labels: , , , ,

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.




Posted by at 6 comments:
Labels: , , , , , ,
Subscribe to: Posts (Atom)