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!