I Transformed In The Heat of Software Testing's Words & Glossary

I'm talking about the words, glossary, and jargon we use in our communication, especially in software testing.

Words in Use

Manual Tester, Manual Testing, QA, QA Automation Testing, Automation Testing, Automate, Automation, Tests, Checks, Verify, Validate, Test Case, and more.

Are these words right or wrong to have in Software Testing's glossary?  I want to see beyond right and wrong.  I will share my learning on this in a different blog post.

Then

When I started my career, I advocated for using the appropriate words and glossary when talking about Software Testing.  I was in this state of mind. I continued in it.

The information on the web for Software Testing was minimal and not abundant as it is today.  I observed practitioners questioning, debating, arguing, and challenging the words and glossary used in Software Testing.  I see, it is good that this scrutiny happened.

It took me years to come out of it and realize what I should be focusing on.

Eventually, I realized it is not changing; it continued and continuing.  I changed. I transformed.  I'm evolving!

Now

Today as well, I see practitioners questioning, debating, and challenging the same words and glossary.  Is this a need?  Yes, it is a need.  Who else will do it if we do not do it?

But, how do I do it now?  I do not discuss it with all and everywhere I see a discussion and opportunity.

Today,

• I listen to people as I did
• I understand what they mean by the words and glossary used in the discussion
• I take an opportunity to trade and introduce the word in discussion in a light way
• I see the other side interprets it as I interpret their word
• We mutually agree on what is expected and to be delivered
• I will move on to continue our discussion and accomplish what we have to
• How often do I do this?
• I choose when to do it
• But I keep the happening calm and a delightful conversing

I'm not stuck or getting into a discussion on words and glossary as I did.

I'm watchful about what I use in discussion and testing delivery.  With my fellow software test engineers on the team, I share my insights, discuss and focus on our work.  I do not enforce or impose anything.  But, I always welcome questioning and challening me.

This has brought me calm, peace, energy, and time for what should I be learning and doing.

Do I ask other fellow practitioners to do the same?  I will not get into this thought.  Let one do what one wants to do.  I converse and discuss if I have any questions and it makes me curious. I move on!

As a practitioner, I know, it is important that I speak up for my craft's and subject's words and glossary.  I introduce it in a light way.  If one is interested, I will be asked about it.

Change in the self is a first progress and I feel peace with it.

I Have a Programming Book in My Software Testing Books List

A Question From Mentee

One of my mentees asked for the books to understand Software and Software Testing better.  She shared the list of books to which she is referring.  She asked,

What other books and resources do you recommend to me for learning and understanding Software Testing?

I want to share my thoughts by talking a bit about boxes of software testing, books, and personas.

Software Testing, Books, and Personas

Read this blog post (Black Box in Every Other Box of Software Testing). It talks about the different boxes in Software Testing.  On reading, do you see a Black Box in every other box?

I classify the books and resources on Software Testing per the below classifications.

Pic: Classification of Books & Resources for Software Testing

I keep the Programming book in Assistive classification.  I have it in my first three books.  How can I test a software system if I do not understand how it is programmed?  Maybe, I can do testing to some extent. But,

• What will I miss if I do not understand how it is programmed?
• What will I miss if I cannot make sense of the code?
• What will I miss if I do not know how to use automation to help my testing?

I consider the different personas to aid my testing.  But, I do not see the programmer persona of writing the code for the system I'm testing.  How to use the Programmer persona to test the system?

What stops me from considering programming as one of the characteristics of a persona?  What can influence and help me to think and include this persona?

I'm not knowing [or ignoring] the first circle of persona (programmer).  But trying to think of different personas to include in my testing strategy.  Is this rational, logical, sensible, and appropriate?

If I practice programming to the extent of reading and understanding the code, I can think of risks to a larger extent.  This is helpful.

If I practice programming skills to the extent where I write automation, I can think of how to automate, how much to automate, and where to automate in that context.  It is helpful.  Isn't it?

If I practice programming skills to the extent where I can discuss confidently with the programmer about the possible risks, it is helpful.  It will also help me to debug and test investigate better.  Isn't it?

This will change how I look at the system and how I test the system with my testing and automation.

Book, Programming, and Language

• In your list of Software Testing books and resources, have a programming book
• Testing software without knowing or understanding programming will always limit us sooner in our Test Coverage, Test Strategy, and Automation Strategy
• It will always limit our understanding of the system we are testing
• It will always limit us in knowing the potential risks and problems inside and outside of the system
• It will limit our perspectives
• For example, 
• When and how the functionality of a feature can be vulnerable?
• When and how to decide how much sampling is enough in a context?
• When you are building a mindset and thought process in programming, pick a programming language to practice the programming
• Start small
• Start simple
• But, start, and then continue

It is always good to derive relative learning and analogy from different practices and study areas.  It helps to register one's learning.  But it should not happen at the cost of avoiding and ignoring the practice of programming by a Software Test Engineer.

Programming is very closer to the software system which we build and test.

Do not get into the thought of whether it is compulsory to be aware of programming for testing software.  This is procrastination probably due to fear.  Face it!  Fight it!

I suggest "Head First Programming" for programming for one who is starting to practice programming.  This book is self-descriptive and communicative.

Start practicing the programming at your own capability; but, do not give up; continue the practice.

Upskilling yourself here will put you on the competence line.

I have a Programming book in my list of Software Testing books and resources.  Do you have it?