The Odds and Otherside of Mentoring & Community Work

The space of mentoring and association is something not easy to understand in the begining days.  Especially when a mentor is not coming from a job having big designation and social media following.  I got hit by these waves.  Now, I know how to balance my swimming with these waves.  I'm swim smoothly without losing my energy and focus.  

I try to understand what could be going in the mind at the other end.

Here in this blog post, I'm sharing what I experience, and what I'm said by few who wants to pair up and practice.

The intention of this write up is to share what I look for in minimum and no intention of hurting or talking bad of anyone.

Do Not Disclose My Name and My Practice With You

I was approached by few fellow engineers from the software testing community.  After a few sessions of pair practicing and learning together, I was asked to not mention or take their name and talk about the practice's accomplisment in the community.  I respect and acknolwedge this ask.  But, then, I asked why so!  I did not see any appropriate reason or concern expressed for doing so.  I have not shared anything about our practices and so far accomplishment.

That said, I see these mentees and a few testing community had no concerns in tagging and getting associated with others in social media and in the community spaces.

The curious me, tried to uncover what could be the reason for this.  I learn, these are a first few reasons:

1. No big job title and role metnioned on my LinkedIn profile
2. Not having the major social media following
3. Not speaking often in conferences and not given an opportunity for not having a title or big company name in my LinkedIn profile
4. Not being a panelist in any conferences
5. Not being a panel member in  the discussion
6. Not being a AMA person in social media and community space
7. Not working in a organization which has brand name that bring crowd to conferences or to the one's benefits
8. Not getting into unneccessary discussion or space that highlights the exchange of words [not the thoughts]
9. For not taking the inequality gesture and treaments
10. For practicing deep
11. For offerring the assistance when it is not asked
• This thing, I stopped!
• I learned my lessons
12. Helping and assisting with no expectation in return
• When you do not asked for any returns, the value is not recongized
• The same people pay thousands elsewhere and say it did not help them
13. And, I'm too good and humble is what I see; this does not work in the longer run in any business
• And, being so makes me not practical

Today, I'm saying NO to --  who approach me, and, then ask me not to say with anyone in the community as it impacts them and their relationship with others. 

I'm asked to share and give my work and artefacts, but, do not want to step up for giving a mention or credit in public!  I don't get it how!

I'm saying NO for such learning association and mentorship connection for the last two years.  I see, this is the best that I can do.

The practice and learning need courage, and the openness to receive and give back. Without this, we cannot experience the learning, practice and growth.

It is not that I make it public by tagging and bragging.  I don't make enough time to brag by tagging unnecessarily.  I write it meaningfully when I see our accomplishment adds value and benefits to more people, and to the mentee and me.

The point is, who is seeking assisatance do not have enough courage to stand up and say, we are practicing.  But, the same people will associates every other corners tagging with credits to others.

So, where is the problem?  If it is associating together with me, I want to say no to those who see that problem.

This is not just with individuals.  I see the same with a few Software Testing Communities.  At the start of a day, it is a business for the software testing communities, today.  While I get a lot of learnings from the communities, such things need to be ignored, and I do it.  If we do not make a way to support and sustain the community bussiness, there will be no space to make meaningful and sensible noise and exchange the learning.  Today, I watch myself in how I contribute to certain testing communities.  Giving back to community is must when I get so much from community.

So, Why This Blog Post?

I want to share this blog post for first to whoever approach me for practicing together or a community work.

I do not want to partner and associate in a mentorship and community work, if a person and group is

• Lacking the courage
• Not wanting to give the due credits
• No mention for whatever we lose, learn and gain in the pair practice we do

If the receiver is not confident and happy about the learning, gain and loss we make together, then I want the person to make use of her/his time with other mentor and skilled engineer.  I refer them to other mentors [and skilled engineer].  That way, the person and group can feel proud of her/his learning and talk about it in public by mentioning the other mentor [and engineer] name. 

I'm not being paid or making money when I work with a mentee or for a software testing community.  I expect the recognition, mention and due credit to be put out in public when the mentee or a community makes a loss, benefit and gain.  I see this is a fair expectation!

I do not want to be used with no respect and keep asking for the same.  If I remain so, I will not set a better example to myself, my teams and to the fellow people in the community.

Be courteous to those who give you, while you do not know, what that person is going through.

Backtracking of Testing, Security and Tools

 

When I started my software testing career in 2006, I was in this thought -- What tools should I use, so that,

• I can do the testing that is sought after
• I can test for performance
• I can test for security

Moving from a search for tools to building the mindset and attitude.  It is a journey!  It took me time to see this journey.  I hopped on to this journey in 2011.  I see, this is not an ending journey, while I know where should I go and reach.  I'm on this journey.

I had no mentors.  I had no seniors in software testing to guide and discuss on my thought process.  I had developers (programmers) who had little or no interest in testing; so it did not matter to them.  But, they have helped me to be better tester.  I'm grateful to them.  Then, the community was not so connected, organized and share the knowledge as it does in 2024.  The software testing was not considered or seen as a technical activity, then.  I have stood, fought, demonstrated and delivered my testing as a technical activity.  I'm continuing it.

Today, on 24th Feb 2024, I read the below question in a community's social space and decided to write this blog post.

Hey, everyone .... Can anyone please suggest a good tool for API security testing?

This question resonates in test engineers.  Most of we test engineers still look and ask for tools when it comes to security testing.  To test engineers, the performance and security testing are still a conception and activity with tools alone.  In reality, it is not!  If you are in such thought or you come across such question to answer, this blog post is for you.

Backtracking the Problem Identification

In programming, we have an approach by name Backtracking.  It is about exploring in possible ways to find possible solutions for a problem.  And, a best solution which works in context is picked.

What's the problem here?  Testing, Security and Tools. Are you with me so far? Let us backtrack this problem.

Note: I see a difference between the words 'possible' and 'all'.  Hence, I use the words "possible ways" and "possible solutions" and not "all ways and all solutions".

Bounties and Entry

There are reputed bug bounties for security testing.  To get into this bounties one has to showcase her/his discoveries and skills with her/his recognized portfolio.

The tools are accessible to all.  The community edition and licensed edition tools are available.  We use these both editions of tools.

• But, why not all of us with tools cannot get into such invited security bug bounties?  
• You will answer this question if you ask yourself.  Hope this backtracking should have helped by now!

The Security Engineering is a vast practice area in Software Engineering. There are dedicated security engineers in role.  But, we test engineers can take up the testing for the security of software systems which the team is programming and building.

I advise, a practicing test engineer

• To start with building an interest for security engineering.
• Consistently hone and build the mindset, attitude and skills needed for the testing the security aspects.
• Pick simple problems, solve it.  Do it consistently, while you explore the layers.

While this is done consistently, it is time to find the mentors in Security Testing. The mentors will assist you in practicing how to test effectively for security making use of simple contextual necessary tools.  Also, a mentor will let you know how to test for security without tools to an extent.  The tool is effective when known how to use it.  The tools help immensely only if I can test for security. 

To backtrack in a different perspective, did any tool that you use, find a P1 security problem [or risk] by itself in its scan?  Did your programmers acknowledge to that risk or problem?  I will pause with these two question to you.

Today, my testing for security is confined to systems that I test.  I test for web application, mobile apps, web APIs, and database.  I can assist here, if you do the home work and ping me.

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?

Inspiration and the Mentor Who Guided Me -- Part 3

 

Here is the first blog post of this series where I share how I started my Software Testing career.  I continue with the next question in this blog post.   The second question from Trending in Testing is -- "Who is your inspiration or mentor to guide you towards your journey?".

To start, I will thank my fellow testers and programmers with whom I worked and working today.  They influence my practice to get better each time.  I continue to learn from them.

People and Networking

I had just stepped into the second year of my Software Testing career.  One evening, I went to the desk of my friend and colleague Kantharaja MP.  He was reading the blog Thinking Tester by Shrinivas Kulkarni.  I got curious and asked what it is.  I did not know what the blog is then.  He explained to me what the blog is.  I got to know Shrinivas Kulkarni, James Bach, Pradeep Soundararajan, Ashok T, Rahul Verma, and Michael Bolton from the blog of Shrini.

Further, I got to know Vipul Kocher, Rahul Mirakur, Meeta Prakash, Ben Simo, Scott Barber, Gerald Marvin Weinberg, Martin Fowler, and Dr. Cem Kaner.  I connected with these practitioners and started to observe their practice.  Thanks, Kantharaja MP.

As I continued, I met Ajay Balamurugadas, Santhosh Tuppad, Parimala Hariprasad, and more friends who joined this network.

I'm continuing to connect with practitioners every day.  I interact, I observe.  I'm learning from each person with whom I interact.  I'm learning by observing the work of practitioners with whom I do not interact in person.

Mentor and Mentoring

I see, we must set out to find the mentor in our journey!  Find your mentors.  Yes, I said mentors and not a mentor.

My Mentor

I did not have a mentor.

I wish, I had a mentor who could connect, understand and help me to be competent, and know the craft, industry, and skills.  I continued to practice and learn from my mistakes, and by observing other practitioners.

I was seen as fun and the topic of fun for my attire, how I spoke and I write the English.  This made me distant from people whom I approached seeking help.  Today, I understand, could be this is the help I was offered for being better and I feel good about it.  I continue to respect them.  These people have inspired me to practice better.  I silently observed how they practiced and I experimented to develop my ways to practice.

I seek and step up to learn from all people when I see that, I can learn from a person or they can help me to learn.  This is doing good for me!

Today, I seek the help of people in the community by approaching them for their suggestions and guidance.  I give the credits and say their name in public and this is important.  I apply the suggestion, guidance, and what I learn from this appropriately based on the need and demand of context.

Ravisuriya as a Mentor

Today, 

• I want to be a mentor who understands the mentee and assists in the practice
• I want to connect with a mentee and listen

I understand,

• Each person is unique and comes with different
• emotions
• mindset
• attitude
• family situations
• personal life situations
• physical health conditions
• mental health conditions
• aspirations
• problems witnessed, and 
• connecting frequency levels
• and, it varies every day with a person

I try to connect, listen, learn, and assist where I can.  I'm a jovial person but at the same time, I'm committed and disciplined when it comes to practice and working.  I see the fun where we all enjoy and get involved in the learning, practice, and work.

Working with a Mentee

I do not associate and work with a mentee by seeing:

• her or his social identity
• how his or her English is
• how she or he appears in dressing
• how she or he socializes and opens up to conversing  

All these are needed in the professional life of a Software Engineer.  I do not deny it.  These have to be groomed every day.  Today, I want to and will dress better than I did in the early 2000s.  I speak!  I express what I have, feel and think, and communicate.

But, it is not a mandate to me for listening to a person (mentee) and get started unless I can't make enough time to assist.  These all will change gradually when one sees self and puts in efforts to get better.  And, a mentor has a role to play here as well.

If mocked for this, probably the mentee or whoever wants to be a mentee will build the distance and more barriers.  This will disturb the communication and relationship between the mentor and the mentee.  All have different conditions and environments in which we grew up and it has an influence on a person (mentee and mentor).

I look for how serious, disciplined, and committed is the mentee in progressing where she or he wants to aspire.  I see the communication is consistent in whatever form between the mentee and mentor.  By the way, communication is not English; the spoken language is one of the mediums through which we communicate.  And, English is one medium to communicate in the communication.

I try to see how can I assist and to what extent.  If I can, I will assist; if I do not have the skills to assist, I will try to connect them with other practitioners who can help better than me.  I talk and make sure we smile together in discussions.

I do not make fun of a person who asked for help and assistance.  I wish no others undergo what I went through.

Find your Mentors

Having a mentor helps very much! 

Find your mentors. Have more than one mentors who have

• the different thought processes,
• ideologies,
• thinking style and pattern,
• different experiences in the area of your practice,
• contrasting questions and approaching ways to learn and solve a problem,
• practitioners of different roles in your field of practice and work,
• practitioners who are not from your field of practice and work,
• and, now you continue to add more to this list ...

Most of the time one will fall into the trap of having a mentor who has got similar thought process and ideology.  This is good.  But, it is never enough to see the perceptions of your subject, work, and practice.

Connect to people of different ages and more importantly who have gone through what you are going through and also who have not gone through it.  

You and your mentor should be able to connect and offer what you both can exchange in return.  Mentorship is a relationship and a partnership where you share and receive.

I try to learn consistently that, the mentor does not have to be older in age and industry experience than I have.  A mentor is one who is able to give and share what I'm looking for in the journey and thereby helps to grow and transform me into a better version each time.

Find your mentors!  Connect to them.

HTTP Request Methods - DOT 3P HCG

 

Today, in the morning session with a mentee, she asked, "I have difficulty in remembering all the HTTP request methods and what it does. How can I make it simple?"  

I had the same question in the end of 2009 when I started testing the applications built using the HTTP.

Learning, and Registering the Learning

When I read, I forget it, because it is not yet registered in me consciously.  How to learn in a way so that it registers in me? I had this question.  Especially, when I started my career, I had this challenge.

In the college days, I had formed a tricks and hacks to remember and the mnemonic was one of them.  In 2008, I came across mnemonics in Software Testing.  I saw the mnemonic used by practitioners in Software Testing as one of the learning techniques and to register and retrieve the learning.

I repeat my learning in multiple approaches until I understand a concept. Then I form a layer where I make it simple for me to register it, in me, and to retrieve.

I applied the same with the HTTP request methods.  It became simple to me to recall and use it in my test designs when needed.

DOT 3P HCG

I helped myself by framing the mnemonic DOT 3P HCG in 2010.  I had difficulty in recalling the HGC part. For this, I said to myself -- head, chest, and gut.  That HCG became smooth in registering.  Finally, I could recall all the HTTP request methods with this mnemonic.

DOT 3P HCG stands for:

• D: DELETE
• to delete the resource specified
• O: OPTIONS
• describes the communication options for the targeted source
• T: TRACE
• used for diagnostic purpose and does a loop-back test along the path to target resource

• P: POST
• to submit an entity to specified resource
• P: PUT
• to upload/update an entity that is saved on server at a specified endpoint
• P: PATCH
• to do a partial modification to a resource

• H: HEAD
• Ask for a response which is identical to GET but without a response body
• For example, fetching the expiry date in a header as a response so that it can be used in the next request's header or a payload
• C: CONNECT
• To establish a tunnel with a endpoint or server for communication
• G: GET
• To request a representation (an information copy) of specified resource

As the HTTP request methods name are verbal, I can recall easily the purpose of each method.  I shared the same today with a mentee.  She could register it in a minute and recall these HTTP request methods and its purpose.

She is happy and says it is so simple now to recall the HTTP methods and its purpose.

Technically, What is a Bug?

 

I'm mentoring the Software Test Engineers.  In one of the pair sessions with a mentee, we were discussing the technical aspects of one technology.  We started to test the application and a mentee said, she found a bug.

She explained the bug.  Further, she asked how, can I explain this bug technically.  And, going ahead, she asked, "Can you technically tell what a bug is?"  

Technically, What is a Bug?

I have come across various definitions of a bug from other software testing practitioners.  If I have to tell technically what a bug is, I put it this way:

• A bug, is a logical incident experienced
• It is logical because the programming instructions written are logical
• Technically, the bug is a logical incident

 

My Work, My Fit, and Company's Goals

 

I, My Role and Expectations

At least once a day, it is useful to think about oneself.  I started doing this late in my life and career. I started doing it in recent years.  If I do not think about myself, I will be lost very soon.  This is not selfishness; it is self-care, which is what I'm learning.

It is essential for me to think about myself, because:

• It helps me to see what I'm
• It helps me to see where I moved today
• Does this move help me personally?
• Does this move help me professionally?
• What benefits does it bring me?
• What benefits does it bring to those with whom I associate and work together?
• Does it keep me in sound mental and physical health?
• Did I learn today?
• Something new?
• Anything I refined and unlearned?
• Does it bring any costs and cons to me?
• Am I fit?
• Fit to where?
• Fit to what?
• Fit? How?
• Fit? Why?
• Fit? When

In all the roles I take in my personal and professional life, I'm evaluated at some point in time.  I will be judged for:

• Did I fit?
• Did I do my role
• Did I meet the expectation?

The problem is not that I'm evaluated.

The problem is I'm evaluated without saying what makes me fit to be in the association and how I will have to meet the expectation.  Some associations can remove us while some cannot.

When I say this, I want to say this -- the word family is often misunderstood; not all associations can be a family although the word family is used often in associations.  This is reality and not a fact!

Does family eliminate me if I do not fit in?  I don't know!  At least the hope is, family is where I can be myself; without the thought of me being judged and evaluated for what I take and bring to the family.  My family as well have expectations from me in the different roles I live in with them.

When I can see this in my family, why don't I see this in the place where I work together with other people?

Do I fit in here for what I make out of this place (company) and take it to my family, home, and my life?

I wish my home and school had helped me learn this question early in my life!  I expect it now because I realize the "value of fit", now, that is, after I graduated and started to work with people in the organizations.

I consistently learn that every one of us is replaceable in any association, be it family or a workplace.  And, it moves on; it does not stop.  If not replaceable, it is manageable to continue and move on.

When we are in the association, how fit we are so that it is hard to replace?  Maybe that's a price (value) tag and a necessity of one!

The Response, That I Should Evaluate

As a responsible colleague and team member, I promote the discussion of this question at least once a month.  I ask this question to whom I report at work.

I will have this question in every one-on-one catch-up that I will have with my reporting manager.  And, I expect a response to this question and want it recorded for future reference.

What is that question?

How does my work fit in with the company's goals?

Evaluating the response:

• How do I evaluate the response to this question?
• What should I do on the evaluation of the response?
• Why should I evaluate the response?
• What should be my next course of action?
• After all, what is my response to this question and how do I evaluate it?

To get promoted to the next roles,

• I need to be solving the problem of my higher (or next) role
• I need to have the capability (skills) to solve problems of my higher role

But this is not a question of promotion.  It is the question of being fit for the company's goals.

While I get promoted or to be promoted, my work may still not fit with the company's goals.  Identifying this early helps.

I have learned, sometimes the promotion does not necessarily come with the fit for the company's goals.  But then eventually the fit will be evaluated at one stage by someone in the company together with a promotion given.

This has led me to ask this question consistently and then evaluate the response with the business, political and rational mindsets.

I say the same to my team, that is, ask this question for yourself and to the reporting manager.  Evaluate the response that comes to you.

Should you ask this question to your reporting manager in each month's one-on-one catch-up?

The Fit Equation Changes

In the team and company, we believe:

• We are contributing
• We are a value-adding fit type
  

We keep saying to ourselves how we make a great fit and difference.  Isn't it?

This "fit equation" keeps changing every day or quarter or year or appraisal cycle.  I learn, this "fit equation" keeps changing rather than evolving.

Adapting to this consistent change and delivering is evolving.  This is my understanding for today.

Biases, Communication, and Problem Solving

We all are in biased mindsets and perceptions at any point in time.  The people in the company need help to break these mindsets so that one's fit equation is questioned and assessed regularly.  In my opinion, this is a great assistance that a manager and a leader can give to her/his people.

I expect the managers and leaders to ask the company:

• What the company wants from the people?

We people in the company and in the team, let us ask the manager and leaders:

• What the company expects from me?
• What is my fit equation?
• Does the current work that I'm delivering fits the company's goals?

I have heard most times from people saying, "I was said that I did not fit with the company's goal".

How will one know what is the company's goals and how can one align with them unless it is communicated and recorded professionally?  I see, to start it needs communication, clarity, and affirmation first from both ends.

Does this solve the problem?  No!  It gives an onset to understand the problem and the differences to fix.  With this, the manager and leader can help the team, and vice versa, in solving the problem.  Thereby contributing to the company's goals by aligning with them.

If you are a manager or a leader, make sure you have this as an essential practice in monthly catch-up to assess this fit equation and let know your people.  I love seeing this initiative from managers and leaders.

This is one of the leader's fitness to be in the role to assist people and the company.  By doing so, we will help the company, business, employees, investors, and customers.

To reset this post's intent equation:

• How the work expected from me fit in with the company's goals?
• How does the work I'm doing fit in with the company's goals?

I'm Open to Mentoring the Software Test Engineers

 

Hello!

I hope you are doing well.  With this blog post, I want to let you know that I'm open to mentoring Software Test Engineers from this November 2022.  I will have a minimal fee for the mentoring that I do.  If the fee is bothering you, do not worry!  You move forward for The First Catch Up.

The First Catch Up

Before we start the mentoring sessions, I would like to listen to you until I and you get an insight that we have listened enough.  From the discussion and listening, it will be evident to us whether can we pair up in the mentoring session or not for the time being.  If I see that you need mentoring from another orientation, I will connect you to the appropriate mentor.

This is to assist you better and to let me know how I can assist you.  For the first catch up, we can connect on a call.  Please use below QR Code to connect on Telegram.  If you are not on Telegram, I'm just one email away. Here is my email -- ravisuriya1 at gmail dot com.

My Telegram ID to Connect for The First Catch Up

I and Mentoring

I have been a hands-on Software Test Engineer for 15 years now and continuing my practice.  In my practice, I have put myself into different contexts and demands of software development and engineering.  Working with a two-member organization, start-ups, and enterprise organizations, I understand the dynamics of engineering and can adapt to it.  

In doing so, I  have tested and continuing my testing with the monolith, microservices, and distributed systems.  Put me in any domain and seam (layer) here, I can test and automate here by learning what is needed.  I can share this learning and practice of me with you.

Do you expect motivation from me?  I'm motivated and I will share what is motivating me.  To keep my motivation up and consistent, I'm disciplined.  I look to commitment in your discipline to be motivated to take both of us forward.  It is our job and not just of you or me.

This keeps me up and high and not the minimal fee that I take from you.

And, do not stick on to one mentor. Find your mentors with contrasting thoughts and practices.  It helps a lot.

How and the New Beginning, Not the End

Anything has to be time-bound and with milestones to accomplish.  When I'm mentoring with defined and evaluated milestones, we will be along with the time.  Though mentoring does not come to end, the picked activities have to see a new beginning and challenges, rather than continuing the same discussions and practice.

If we are not seeing this, then we have something not going right for our goal.  We will be evaluating it consistently week-on-week.

It is not about seeing the results.  It is about understanding where we are in seeing ourselves in where we have to be.  It is a journey. The result that we experience is just one minute part of this exploring journey

In simple, we will be outside of our comfort zone!  I said, ours comfort zones!

The Fee

As I mentioned, you will have to pay a minimal fee monthly basis only if you choose me to mentor you and we both work together in this activity.  It is a minimal fee that I will tell you on connecting.  There is no fee for The First Catch Up.

Why the wait?  Let us catch up and listen to each other.

A Direction Sign for Beginners and Everyone to Start and Grow in Software Testing

 

I'm volunteering for the Agile Testing Alliance (ATA) for this year 2022.  This 10th September 2022, we had an ATA Round Table Talk 2 on account of International Testers Day.  We planned two events on this day -- QuizATAhon-1 and Ask Me Anything (AMA) with ATA volunteers.

One of the questions that we volunteers got from the community is:

"Best advice for beginners who wants to start there career in the testing field as per there experience level"

I shared my thoughts on this question in the AMA session.  I have a strong intuitive feeling that this will be the question of the interns, freshers, and also of experienced test engineers.  Hence, I want to write it as a blog post, so that it can be referred to as one of the directional heuristics.

This is Not an Advice

What I'm sharing in this post it is not advice.  It is information. You can use this information to advise yourself on what you should be doing to grow consistently in the practice of Software Testing and testing job.  As said, it is a directional heuristic that you can use.

This information will make sense to every one of us irrespective of experience in the industry with software testing as a career and practice.  There is no best advice.  I see, advice is information or carries a piece of information that can show us a direction.  And, the advice is a heuristic!

Direction Sign To Be a Skilled Tester

This will be super useful to you if you actually make use of it to your need and to the maximum possible extent that you can.

1. Find your Software Testing Community
• You might find the community quicker than finding the people, books, and syllabus of Software Testing
• If you don't read Software Testing and Programming resources, someone in the community might be reading it
• You can use their learning for your growth
• Look out for the Software Testing Communities in your place (city or country)
• Just do not look at one testing community; find more than one active communities
• Collaborate with the communities
• Interact with fellow Test Engineers in the community
• Start contributing to the communities in the possible ways you can
• Note that, the groups on Social Media will not make it a community
• People come together in a community
• Events, Meetups, Conferences, Discussions and much more will happen in the communities
• Today we can associate with Software Testing Communities which are in other countries
• Could be this community will have one of its chapters in your city or country
• Find the Software Testing communities
2. Mindset - Do not get easily influenced
• You are bound to get influenced and follow easily
• when you look into the community and the people in the community
• with their works, writing, accomplishments, social presence, and identity
• when your fellow peers in college or the workplace talk about testing to you in anyways and in any dimensions
• It is their opinion
• It is their understanding
• It is their assumptions
• It is their mindset
• and, with what you read or watch about testing posted on social spaces
• Have the mind and thought that questions; try to seek what makes sense rationally to you
• Be practical and experimental
• Do not attach your past and present experience's emotion to others' opinions
• You evaluate it
• Pick what makes sense to you and to your context
• Do not be a mind of other Test Engineer or practitioner
• Have our own voice and identity
• Express your opinion while you respect the work and opinion of other Test Engineers and practitioners
• Develop your working style, learning style, and problem-solving style
• But do not stop observing others and how they are doing it!
• Question!
• It is about being included than being influenced
• Do not stop questioning
• Talk, and talk with respect!
• A test is a question asked to learn what it is and to understand what actually it is
• It needs a mindset
• A mindset not to get easily influenced and accept an opinion or a thought
• Note: Do not be influenced by this blog of me; just read it as a heuristic
• You build your approach using this heuristic only if it helps you
3. Knowing the chaos around Software Testing is very important
• Everyone knows Software Testing and everyone believes to have an idea of what it is
• This is the state of mind in the college that teaches computers and programming
• This is the state of mind in the software industry
• Chaos starts right from the syllabus, textbooks, and reference books, and with you
• Here are some chaos and myths existing for 20+ years and they will exist in the coming years
• Software Tester has no bright career as Software Testing is not technical
• End of Software Testing is coming soon
• Software Testing has seen its end
• No need of knowing the programming
• It is a necessity in today's Software Development context
• It is an easy job
• Is it so?
• Try finding at least 3 business stopping risks and problems in the system every day
• If you do this consistently, label it as an easy job
• Let your business stakeholder acknowledge the findings of your testing as a business stopping risks and problems
• No good money earned when compared to a programmer
• No career in Software Testing as we grow with our experience in the industry
• To be a Software Tester one need not be technical
• It is a Women's job
• Yes, that is how it was projected and was said
• I'm saying this from my experience in India
• I'm not aware of how it was or it is in other countries
• 2014 and onwards, I have not heard this statement
• Happy, that we don't hear this today
• Thanks to SDET and SET roles
• At least, this removed the gender bias is what I see
• Today both women and men work in the role of SDETs
• I worked with women SDETs and I did learn from them; I say this is in pride
• I'm happy that women are taken out of this framing today
• I'm very happy!
• We don't have to bring gender discrimination in Software Testing career and jobs anymore
• I see, there is no job that women cannot do today in the technology space
• This is an empowerment of women
• Women are equally skilled and work to upskill
• We have skilled women technologists, CTOs, VP Engineering, Architects, Test Architects, SDETs, & Test Engineers
• I'm happy that I have worked with technically skilled women and I reported to a few of them
• Ah! I should stop calling men and women here; it is we Test Engineers
• Do not panic with the chaos that is created frequently and consistently
• Talk to your community
4. Find your Mentors
• I said mentors and not a mentor
• Have more than one mentor
• Know how to work and practice while you have more than one mentors
• Respect your mentors by giving the credits and with your gratitude
• Find your mentors in the workplace and in the community
• Good if your mentors have the contrasting thought process and ideologies
• Pick from both sides
• Know what both sides advocate and practices
• Apply the appropriate one to your work when the context demands it
• Do not be the mouthpiece of your mentor
• Do not be the mind copy or replica of your mentor
• Do not imitate your mentor
• Seek your mentor's assistance in you being you
• Seek help in growing with your identity and voice
• Have a voice and your identity
5. Communicate with your Software Testing Community
• When you talk to the community, you will know
• where you are
• where is Software Testing
• the challenges your fellow testers in the community are having
• how the challenges and problems are being solved
• It will set you a tempo with an attitude if you talk and share your learning
• In simple, just read or listen to the problems the testers share everyday
• This is awareness!
• At least, it opens to the awareness of technology, tech stacks, problems, solutions, industry, people, and more
• Attend the meetups
• Small crowd and high interaction with networking
• High exchange of learning and experiences
6. Be the Technical Mind
• We Test Engineers are said to think like a user
• Good!
• This is an empathy mindset that is being cultivated in us for the users who use the solution we are building
• But this empathy is alone enough today? No!
• Empathy with technical skills will be much value adding
• And it is today's need
• When I say technical, it is not just programming
• Programming is one small aspect of being technical
• Let your technical journey start from learning:
• How this works and what makes it work
• Know the technology layers internally and externally when you learn how it works or when it does not work
• Start here! And expand your technical capability dimensions
• Today, we are said and expected to think like an engineer
• An engineer who understands the user
• An engineer who understands the business
• An engineer who understands the investor
• An engineer who understands the management and managers
• An engineer who understands all this can change at any time
• An engineer who can work, scale and deliver in a startup mindset and environment
7. Seek and Share Awareness
• What sets back we Test Engineers is the lack of awareness before lack of attempts to practice
• We don't work, collaborate and associate to be aware of
• We are not aware of -- what to be aware of
• This includes me as well
• I consistently keep trying to be aware
• Do not just attend  and be part of the Software Testing community
• Attend the community of programmers, DevOps, products, businesses, startups, enterprise
• You will see the direction sign -- which happens to be a heuristic
8. Know what is your Software Testing
• Everyone has their understanding of Software Testing
• Engineering Managers and Director of Engineering with whom I worked had their own understanding of Software Testing
• No one was similar nor did match anywhere
• All have their version of testing in their work
• Know what is Software Testing you want to practice
• Software Testing is contextual
• Tailor and deliver Software Testing to what is expected at your workplace
• While you do that, try educating your fellow Test Engineers
• That's the seeding
• This is the place where we can seed and harvest for a better tomorrow in Software Testing and for our growth
9. Practice your Software Testing in all dimensions
• Software Testing is with people, software, hardware, and more
• When we are dealing with Software we cannot be away from programming
• Programming gives a different order to our testing
• Practice programming
• Embrace it
• Shell out the fear of programming
• Start small; more importantly start and continue
• To keep going, find one tester in the community who wants to do it
• Go to your mentors and follow up with your accomplishments, setbacks, challenges, and problems
• Get unblocked; make progress; learn, implement and share
• Do not run away from the practice of automation
• It is a necessity for today's Software Development & Engineering
• Find all possible dimensions you can
10. Build your portfolio
• Explore how to build your portfolio in Software Testing
• Ask community
• We have several portfolios to refer to in the community
• Build it and continue improvising it with the time and context
11. Solve the Software Testing problems
• Before solving at least be aware of the problems
• Community is one place where you can hear the problems and challenges
• Contribute to the solution and solving
• This helps you a lot as a practicing Test Engineer
• Problems come in flavors and contexts
• Testing, Automation, DevOps, Product, Requirement, Delivery, and more
• Have yours hands-on on all these verticals to help and scale your testing and automation
• This will make you talk and help you grow with experience and learning
12. Tune up yourself with Business, Political, and Management skills
• Not all problems can be solved with a technical mindset and skills
• It needs the skill of political and management orientation
• Do good and be good
• Work on how you communicate; it is important
• Know how the business decisions are made
• Know how business decisions influence technology, engineering, and anything
• The business decision need not be based on logical and technical analysis
13. Beat your EGO and respect your self-respect with dignity for Software Testing
• Ego has killed a lot of us from talking and growing
• Ego has made many managers lose their engineers
• Ego had made many testers lose what their managers could offer to learn and grow
• Software Testing has its touch points in every vertical of Software Development
• Programming
• DevOps
• Product Management
• Solutions
• and, what else?
• Testing is done in all these verticals
• Ego can set us back and block from what we can make for our benefit and contribute to the organization and business
• Managing the ego is a skill
• While managing ego, balancing one's self-respect is a challenge
• Know what is the objective and what you make out of it for your growth
• While doing this keep the dignity of Software Testing and team morale high along with your self-respect
• Talk to your mentors!
• Yes, talk to your mentors
• Mentors might be handling ego, self-respect, and dignity of their work and practice
• Your mentors can tell you the ways to do it
• Take care of your Mental Health and help others too
• Physical health is also important

This information should hint you with the direction of practice, growth, and excellence as a Software Testing practitioner.  I'm here to connect with you anytime and talk more and take it forward.

Dealing with the Fallacies of a Fallacy

 

One of my mentees asked me to help in identifying and understanding the fallacies in Software Testing.  I did not know the context in which the help was sought.  All I got is, on reading the book from Gerald M. Weinberg, the mentee wanted to understand and know the testing fallacies better and in simple terms.  For "fallacy", I understand it as -- a misconception resulting from incorrect reasoning and a false belief.  

Further, I learn that reasoning and belief are also heuristics. Can the heuristic be a fallacy? I see, the heuristic can be a fallacy.

The Reality of the Fallacy is a Fallacy

I will keep this blog post layered and oriented with technical lines so that it becomes easy for anyone in tech to understand my thoughts.  As I write this, I get hit by this question -- "Fallacy is a Fallacy?".  With that, I'm left with a successive question -- Fallacy is a Fallacy? Is that not a logical question? 

When I mean logical, I understand logic is one of the aspects of rational, scientific, and systematic analysis.  The analysis has limitations, knowns, and unknowns.  Further, this is super covered by a meta context which includes the uncertainty -- we are aware of and not aware of in our analysis.

When I write this, I see the word "meta context" in my mind.  I don't know if someone has used it earlier.  I presume, someone should have definitely used it when talking about engineering and systematic rational analysis. 

When we work on an engineering problem, we work with a context.  In that context, we learn 

• the problem, 
• need (requirement), 
• assumptions we make, 
• what we know, 
• what we do not know, 
• potential solutions, 
• approaches, 
• execution, and more

The engineer in me says, there is a meta context for every context.  Doing engineering to the meta context is an over-engineering is what I understand.  

Engineering to a context, by solving the risks and problems which are identified in that context, is what we all are doing, today.  This is my observation!  An example of this is the software system that we are building and continuing to consistently develop to be updated for the need.  The software system we are building, testing, and deploying is bound to a context and not to the meta context.

In Software Engineering, we work on a context, and, that itself is huge engineering.  Eventually we start seeing the context in which we work as a meta context, while it is actually not.  This is one of the fallacies which we encounter and most times do not identify it.  You see?  Then how to think about the meta context which comprises the infinite contexts from which we have picked a context to engineer and solve?

Once we try and continue to be aware of meta context and what it has, we start to learn everything is a fallacy, including the fallacy.  That's enough philosophical from me.  But, that's the reality and fallacy, as well. 

That said, thinking is a fallacy.  We know that exhaustive testing is not possible.  Likewise, exhaustive thinking is not possible.  When one's thinking is not exhaustive and bounded, don't a fallacy exist there? 

One's scientific and logical thinking is modeled and sampled over a few models, space and dimensions.  The decision from this thinking, practice, and testing will have limitations and fallacies that are noticed and unnoticed.

If an organism can think, then that organism will undergo the influence of a fallacy.  And, the organism can learn to identify fallacy, if at all it understands -- I can be fooled no matter what.  That is one of the byproducts of testing -- knowing the few possible ways how one can get fooled.  And, we have no leisure and luxury to find "all the ways"; this bound brings in fallacies in one's belief, thinking, work and decision.  So I say we work in a context which is pulled out of a meta context.

I see this is the stem of fallacy; the fallacies get wired to our thought process and to the engineering we do. Our systematic and scientific interpretation accepts the fallacy as -- logical, and systematic, and claims the problem we're solving is solvable.  Note that, when I say solvable here, I mean, we can deal with it for the costs and value we get out of it.  By doing so, we handle and manage the fallacy to yield the value.

What Did I Read Just Now?

Well, what you read above are engineering philosophical thoughts of me.  Now, let me pull that to the Software Engineering and Software Test Engineering.

The software system or a hardware system or any system that we have built is an assumption.  We assume it works because we work to make it work.  And, we sense that it works because we adhere to the protocols which define these assumptions.

So that tells me, that anything and everything is built, and being built is an assumption and has protocols. And if anything is working, it is on assumptions.  If anything has failed to work, it is on our assumptions.  That infers me, that rational and systematic analysis is an investigated and experimented assumption.

These protocols and assumptions can blind us to fallacies and limits us to not identify the fallacy.  On witnessing an incident, the fallacy or the outcomes of a fallacy may get uncovered a bit.  That is what we do in the RCA -- Root Cause Analysis.  We do the RCA so that we learn the fallacy in which we got trapped.

On RCA for an incident, we will experience a similar or same problem again.  Why?  We think, that once we do the RCA and practice, we do not repeat the mistake -- this is a fallacy too.  We do a new mistake, which leads to another RCA.  Does that means, the RCA of an incident says not to fall for the same fallacy again but okay for another fallacy?

Managing Self with Fallacy

I too fail in identifying the fallacies.  I continue to prompt my thinking and analysis to see the obvious traps while I test and deliver the testing.  I do not identify all the fallacies in a context.  I will work to find the list of fallacies that brings the most cost in testing delivery and system development technically.

Here are a few questions that I ask myself each time in my test session and analysis:

1. What are the five contexts where this is a problem or risk?
2. What are the five contexts where this is not a problem or risk?
3. What are the five ways where this looks to work as expected?
4. What are the five ways where this does not work as expected?
5. What are the five contexts that matters most about this system and I have missed to know them?
6. In what contexts this bug is not a bug anymore? Why?
7. In what contexts this will be a bug/problem/risk/cost? Why?
8. What are the influencing factors and practices considered in making this decision? In what contexts do these factors and practice displace the value with the cost?
9. What are the assumptions and beliefs that are driving my testing?  Whose assumptions and beliefs are they?
10. Do I know that I can be fooled?
11. Do I see any problem here?
12. Do I see any value here?
13. Do I see any cost here?
14. What More Can I See Here?

Understanding and learning -- how my team and stakeholders attach the importance to the same information, helps me. This potentially hints me if they are under influence of any fallacies.  I learn, the context in which team members and stakeholders are also influencing the importance attached to the same information.  Sometimes, the team and stakeholders use the same word; but, I notice they have other meanings.

This has lead me to learn, it is not about being precise or not for first; it is about, having the ability to communicate and help each other to have the clarity in what is expected.  And, how to achieve this clarity considering the thought processes and beliefs that each stakeholders hold, is a must to understand.

To sum up, we cannot avoid ourself from the fallacy.  What is not a fallacy at present, it can and will be a fallacy in coming time.  The goal is to how we manage to identify and deal with the fallacy which is influencing us and our work.

There is no escape from the fallacies!

Note: The count of words "fallacies" and "fallacy" in this blog post is 47.