Showing posts with label Must Read. Show all posts
Showing posts with label Must Read. Show all posts

Thursday, March 6, 2025

When Does the Community Choose Not to Respond to Questions?


I read the testing, automation and test engineering related questions posted on the social media and web.  I try to understand the question, problem expressed and collaborate to assist.  I do keep 46 minutes in a day for this activity.  

Sometimes, it is hard to assist reading the question.  I feel like not giving up; but, then I do not see the communication happening actively from other end.


What Makes It Hard To Assist?


The questions asked,
  • It will lack the context.
  • It does not tell who is the person and what she or he is trying to accomplish.
  • It will not have information on
    • the environment.
    • what is the challenge he or she is facing.
    • what she or he tried so far.
  • It will not have minimal data as
    • screenshot, exception stack trace, the complete error message and details following it, data being used, code outline, and more details to the context.

The above are minimal data needed on removing any sensitive information.  Know and understand what is sensitive information for your context when you are sharing.



Then, what do the question will have?
  • Most will have a phrase or a couple or three sentences of what they are doing and what is seen on the screen.  And, asking what to do for what is seen on the screen?


Why it is hard to assist with vague details?

People who want to assist won't have any context about you -- who you are, what you are doing, or why are you doing it that way.  They won't understand your purpose or what you are actually experiencing based on the limited and vague information in the questions.

Without clear details, it is hard to connect the dots or pinpoint the problem.  Instead, people who want to assists will be guessing, making assumptions, and probably considering multiple possibilities.  Is this a way to use the time in community?

When questions follow a similar pattern but vary in challenges and context, it becomes demotivating to decode them.  Over time, people will lose interest in reading unclear questions, leading to fewer responses and missed opportunities for meaningful discussions.


What's happening at other end?

People who want to collaborate and assist will take the time to read the question.  But, when a question is too vague to understand, they often give up.  And, they feel bad for doing so.  The question remains unanswered.

When a solution is provided, there's often no update on whether it worked or not.  Those who contributed keep checking back, only to find no response.  Is that fair to those who invested their time to help?  Would you feel good if you were in their position?

Remember, in the community one can't buy someone's time to listen or solve a problemIt has to be earned!  And, it has to be earned every single time.




How to Frame and Post the Question?


There is no one excellent way of doing it.  Then, what should I do to post my questions?

  1. Know the community.
  2. Read through the questions shared earlier in that community.
  3. Look at the questions that have found resolutions, acknowledged and accepted.
    1. Observe how the question or problem experienced is described.
    2. Look at the details shared and how it is shared.
    3. Look at the context details shared and how it is shared.
    4. Observe how the interactions and conversation is taken forward from the two sides.
      1. Closely notice the words and how the energy is kept high in both ends and how each side is pushing for it.
      2. Importantly, look at the time taken to respond from both ends.

I do not want to share an example or reference saying this is the way to do it.

You figure out for your problem and to its context.  Share the minimal information said above and ask for the help.  Consistently improvise on how you ask, share and describe the problem.




Friday, February 14, 2025

My Advise to a Software Test Engineer


I was discussing with a Software Test Engineer post meetup.  We two stayed back for a couple of hours conversing on various topics and how to approach the problems.  He was assisting a recent graduate to get started in Software Testing.  His question to me was, "What all should I share and where should I start?".

I ask the same question to myself when I sit back and observe my practice and journey.  That is, 

"Ravi, what is the one advise you give to your younger self when you are starting career and practice in Software Testing?"

That question of him resonated in me as I listened to him.  I said him, 

"I ask the same to myself. I align; I'm a beginner resetting and starting over everyday using the learning of till date.".


Note this; what I'm saying here it is my experience and learning.  I feel, it make sense to me in my contexts.  You evaluate it and take it to your context.  Nevertheless, I see it is sensible advise and it should be must in your practice the day you start to practice Software Testing & Engineering.


My Words and One Advise

This is a advise I give to younger myself who is starting the career in Software Testing & Engineering,

 "Practice programming!  This should be your day to day activity [practicing programming] to improve your testing skills.  It is critical and elemental to be a better Software Test Engineer.  Do not ignore it.  Embrace programming and leverage your testing."


Any other skills that you hear or said, you can apply them on your programming practice work.  Evaluate it.

For example, if you hear skills as questioning, thinking, critical thinking, lateral thinking, and whatever, apply them to the programming activity and the code you are writing.  Take help of mentors here.  Know the boundaries to set and unset as you progress here.

That said, do not be biased and get stuck to just programming alone. The programming should aid your testing practice and skills, and vice versa.

If I'm testing a software and the general [contextual] systems with which it associates, I should know how the software is being implemented, how it communicates, and manages.  This is essential and necessity for a Software Test Engineer.  This is a need!

Being away from programming, I will fall short in the ways I think of the tests and how I test.  The software that I'm testing is composed from the programming along with other general [contextual] systems integration [specific to the contexts].  If I cannot identify, learn, write and understand the composition of software, I have to think about my testing and question it.

For example, how would this blog post get saved and published when I publish this draft?  What goes behind and in front?  If I cannot see the layers here and understand them, I cannot test better.  Maybe, I can see them to an extent without programming skills.  But, the programming skills gives the different perspectives to the testing, automation and test engineering.  The advantages of these perspectives are unparallel and helps immensely when identifying and designing the context's priority and critical tests, and its samplings.  Hope this makes sense to you and tell how critical it is.


To end this post, I summarize it as,

  • I do not have to practice programming in the scale for being a full time skilled programmer.. I practice programming to be a full time test engineer whose testing is sought after.  I stand here for today.
  • Practice programming to engineer your testing better.
    • Apply all other skills which you see as important to test the code that you are programming in your testing practice.
  • If you are starting to practice Software Testing, start from programming and test your program.  In testing this programming of yours, apply all other skills which are said critical for testing better, and upskill them in parallel.



Friday, January 10, 2025

Caution! Know This Before You Prompt For Your Testing


My Fellow Test Engineers,


If you are using Gen AI and LLMs as an aid to do better work, yeah, we should be exploring it.  I have no second thoughts in it.

Are you giving anything bounded by NDA to Gen AI models and LLMs?
  • Like a part of software requirement, video, an image, code or anything that hints what the system is?
    • That is, is this part of your prompt text which you are giving to the Gen AI model(s) and other LLMs?  If so, do exercise the below questions:
      1. Do my organization and its business see any threat and risk from me for doing so?
      2. Does it violate the NDA (Non-Disclosure Agreement)? If yes, how will I be impacted and prosecuted by the employer's business and organization?
      3. Will I be terminated from my job or contract for doing this?
      4. Will I have to face the legal consequences?

I tell you, for today's LLMs, it is sufficient to have gist of requirement or code or video or an image to isolate one's request. From there, it can monitor fairly better with additional anticipation.


My questions:

  1. How would you trust the models behind?
  2. Do you know how it is observing especially when you use your business identity to login and prompt?
  3. Though you have customized the LLM's model and it is in within your environment, how do you know it is not connecting to its vendor environment and updating the gist?

Let us leverage the prompt engineering, Gen AI and associated LLMs. But, be aware and conscious of what we are giving out!


Also, be aware of what you tell to fellow test engineers. Not all Test Engineers or SDETs think of the consequences; instead just blindly mimic or follow what is being done or said to do by trying and using it.


Let us think about what we are passing to community by just saying to use prompts for --  to write test cases for this given requirement; read the given requirement and give a test design and strategy; review the code snippet and more.  Such loose and vague messages can be harmful if it is blindly followed!

By prompting the text and calling it out as prompt engineering, we might be giving out what we are not supposed to in the context of our employer's work. Caution!