The Awareness Words On Growth And Promotion

 

I wish, I had seniors who said me about growth and promotions when I began my software testing career.  Could be my seniors did not know how important it is to share this with juniors who have started their career.  

Nevertheless, I want to share it here.  So that, it can be the words of awareness.  

These words of awareness related to promotions and growth is not limited to below sharing.  It is more and beyond.

The below are quick reminders to myself.  It can serve you as well.

• The good work delivered does not mean good money and benefits.
• The promotion and growth is not all about the good work done and delivered.
• It is about my identity, professional identity, visibility, communication, persuasion, influencing, the kind of problems I'm solving, the value and money I bring to the business.
• Me skilled in the tech stacks and capable to build, test and deliver is not the only priority factors for the growth, promotion and benefits, each time.
• The 1:1's and meeting with stakeholders should have a goal and way to evaluate the same periodically and consistently.
• It should be quantifiable and visible in the business.
• A manager's job is not to worry about my growth and promotions.
• A manager's job is to ensure the delivery is going good and meeting the business goals.
• A manager's job is to solve and enable the business on priority, most of the times.
• A manager can be of help in my growth and promotion to a certain role maybe until the senior engineer role.
• Beyond that, it is me and how I'm seen by my peers for what I'm and what I do.
• A manager is not responsible for my learning and upskilling.
• It is my responsibility and accountability.
• The manager might forget me after a release.
• She or he will remember me
• When I'm needed in the meeting.
• When a data is needed from me.
• When someone else need data of me.
• It is me who has to keep the manager engaged with my value and impacts delivered.
• The data has to be presented.
• The data should be quantifiable.
• The one whose work bring money to business and the one who sits in the role for making decisions that brings money to business, get identified and promoted usually.
• In other way, how close is my work to bring the money and impact to business and its growth?
• This is a preliminary equation which one has to have and solve before going to ask promotion, growth and benefits in a business place.
• How to keep myself here while I deliver an excellent work and value to the business?
• If you see, in a way this is politics.
• The office politics is not bad!  Everything runs on politics.
• It is the people and management dynamics, and that is how a system functions inherently.  This is my observation and interpretation.
• One should be able to play her or his role in the office politics.
• If ignored or keeping oneself away from the office politics, it projects one as muted with a label tagged -- he or she can be updated later and the job will get done and no need to be here.
• One's office politics is her or his identity, visibility, positioning and influencing

The manager is in the organization not to promote her or his team members.

• But, to ensure the business goals are being met.  
• Taking care of her or his team members in a defined scope is one of the responsibilities for a manager; it is not the only responsibility and not the number one priority responsibility.

Business goals do not have my promotions and growth as their priority goals.  It should be my goals.

Yet, the managers go and fight in a closed room for her or his team members growth, hike and promotion until a role.  You see, not all get promoted in a cycle.  That challenging is the advocacy in that closed room, tables and meetings for the managers.  Give the quantified data to your manager.

Underestimating self and letting that to be used by others in the floor can be lethal to the growth.  

To end here, my growth, hike, promotion and the benefits I need to get is my advocacy and visibility for first.  The manager and peers can be a catalyst here.

What Test Engineers Forgot By Saying "Out Of The Box"?

When I started my testing career, I read the lines which said, think Out of the Box.  My then manager said the team to think and work, out of the box.  

I see testers practicing, working, testing and automating by saying, out of the box.

Wait! When said boxes, what comes to one's mind is Black Box, White Box and Grey Box.  But, I tell you, there exists no such boxes.  These boxes are imaginary; it was termed probably to give an analogy, to see and know the ways to test the product's code and infrastructure.

I do not tie myself to these imaginary boxes, but, it is a useful analogy.  After all, when said Out of the Box, which box are we referring to?

And, what is that I'm missing by saying and doing out of the box?

What Have we Forgotten?

While me talking and saying *out of the box*, I'm not letting myself to think Inside The Box, for first.

If I cannot know what is *inside the box*, how will I know what is outside the box?

If I cannot see, think and explore for what is *inside the box*, how will I know what is outside the box?

I see, we have forgotten "Inside The Box" by saying and hearing "Out of The Box" for decades.

What's inside the box which you are testing?  Does it have just functionality, though the functionality is the heart beat of a system?  Okay, have I explored the functionality in all possible dimensions?

Almost everything in the box is associated with functionality.

When I'm not said to test for what is inside the box, I will be lost with Out of The Box.  Do you?

If I explore Inside The Box, fore sure, it will help me to go beyond functionality.  What all I can do inside the box?  What all I can evaluate inside the box and how?  That is, I think of performance, security, usability, observability, traceability, monitoring, and you label next.  All these are associated directly with the functionality.

All the boxes in software testing are imaginary.
We have forgot to see and explore Inside the Box.

Inside the Box, helps you to identify and observe,

• Why these exists?
• Why these are interconnected?
• How these are interconnected?
• How are they communicating?
• What are they communicating?
• To whom they are communicating?
• When are they communicating?
• When they fail to communicate?
• How fast and reliably they can communicate?
• The programming, code, protocols, tech stacks, libraries, money, ports, cables, people, etc.
• What they are holding and where, how and why, when?
• And, more ...

As you go Inside the Box, this space grows in multi dimension.  You will realize what is out of the box and what is inside the box.  You will consistently tune yourself to fit in any imaginary boxes with your tests.  From there on, you will explore, test, automate and talk to all the imaginary boxes and system[s] you are interacting with.

If I cannot see what is within, how can I see what is outside?

The Reality, Pain, and Cost

This is my observation.

• When I ignore Inside the Box, I will continue to talk with more focus on vocabulary, terminologies, schools, process, advocating on one aspect of the discipline and think this is craft and craftsmanship.  
• I will be stuck here and pass on the same to upcoming generation of software test engineers and practice.  
• This is the reality and painful part. 

Is talking and working on vocabulary, terminologies, schools, craft, craftsmanship and advocating that one aspect is testing, wrong?  

• No, it is not wrong.  
• But getting lost here indefinitely is beyond wrong.  
• The cost of this is huge to the craft as a practice and to the software test engineering discipline.
• As a result, the upcoming test engineers and generation will pick whose voice, approach and content is more opted.
• If observed, this is not the case with programming and programmers.
• I see, the programmers challenge most times and everyone who pushes or sells the thoughts. 
• Why? I see, they are trying to learn and understand from inside the box for first.

Unfortunately the smart people who are with role and title of influencers, thought leaders, keynote speakers, seniors, directors, VPs, ambassadors, and advocators of a thought and schools are lost here.  My question to them and me is, why not we explore Inside the Box?  Why just confined for propagating the philosophies and one's ideas alone ignoring what is Inside the Box?  The philosophy is a need; I do not say we should not ignore it.  Philosophy alone do not pay one's bills and fill the stomachs.  I wish, I had learned this lesson in the start of my career.  The business is a philosophy by itself and it will make use of or ignore any other philosophies as and when needed.  I hope and wish, the test engineers will interpret this.

I see this is one of the key reasons why the software testing as a discipline and practice we did not gain the recognition and importance as programming the product and solution.  Though we work closely with the product code and the test code, we miss our craft and names being called out.  This is reality and painful.

To end here, if I'm not seeing and thinking for what is Inside the Box, how will I excel in Out of the Box?

There Is No Flaky Test! Then, What Is Flaky?

In general, I understand, the flake means brittle and inconsistent or uneven.  Like the flakes one will have as food.

I'm not a native English.  It took me years to understand and correlate between the words 'flake' and 'flakiness'.

Test and Flakiness

There are no Flaky Tests.  A test is not flaky anytime.

The responses of a system to a test can be flaky.  That is, the response is not deterministic and inconsistent to one's expectation and understanding.  

In other words, the responses of the system is unreliable to the same action, data, state and other parameters.

This is not a philosophy of testing or test.  In my opinion, it is a misunderstanding that is accepted and passed on in the software engineering.

A test is not flaky; the response of a system is flaky.

Are there no flakiness when testing for services?  It exists!  That is, the inconsistent behavior of a service for the same set of data, state and other parameters. What is inconsistent in context of a service's response?

Flakiness is not bounded to just GUI  It can be with any UI [User Interface].  And, an API is an another user interface which opens up to the bunch of services.

To end, 

• It is not Flaky Test.
• It is a flaky response of a system which a test is letting you and me to experience.
• What is a flakiness to one who is testing for security and performance?
• Flakiness is not confined to the UI response or a functional response of a system.

You decide how you should be seeing a test in your suite and label the response of the system you are testing.