Behind the Every Test Data, There is a ?!

 

Read this blog post to have a perspective about the Test Data and Test Data Management.  The point is, if I'm not aware of a test and what does it tell me to explore, I cannot think of a Test Data.

That said, if I know what I should be evaluating as part of performance, why, when and how, this will help me to come up with a thought for identifying the tests and its test data for the same. 

The ninth question from season two of 100 Days of Skilled Testing is:

What role does data management play in performance testing, and how do you ensure the availability of suitable test data sets?

Testing and "Ensure"

We test and have tests in testing, because, there is no "sure" and "ensure" idea in software.  But, we presume on a rational basis upon, "if, these are this", in a given context when the software processes.

Now, ask yourself, how can we ensure the availability of suitable test data sets?

In my opinion, the Test Data is often misunderstood.  This is the primary problem and should be the first problem, when asked "what are the challenges in creating the test data?".

When you read the concluding lines of this blog post, you will learn why I say this.

Test Data and Immunity

In my opinion and experience in practicing the Test Engineering, I see, the Test Data should be a viral strain and it should have its variants.  When this test data is used to test [experiment, test investigate, and debug], how do the software and its ecosystem respond?

• Does the software and its ecosystem is immune to this test data?
• Does it exhibit any risks and problems?
• If yes, then, do the purpose of my testing and automation is accomplished with this test data?

This puts me back to question, what is the purpose [intent] of my test?  It drives me to derive the test data which helps me to know -- What am I supposed to learn and on priority?  With this, I get an idea for what kind of test data I should be creating knowing its pattern.

If the system is immune to Test Data and not reveling anything new in the context, I classify this pattern of test data as "Immune" to the context.

In my practice and research work in Test Engineering and Software Testing, to start, I categorize Test Data into two areas.

1. Immune
2. Not Immune

Further, I have categories, under these two, where I classify the Test Data deterministically for the context.   Get in touch if you want to learn more about this.  I'm just one ping away!

The tests should help me to evaluate for the immunity and also non-immunity; both are essential and necessity.  

The credit is to me for such classification of Test Data.  It is my research work out of my practice.

Note that, Test Data is not just the input [characters or files] entered or given to a system.  Test Data has its association to tech stacks, infrastructure, ecosystem, business workflows and people.  To craft such Test Data, one has to have the understanding of the system and its internals, and, the problem it solves by knowing how it solves.

Performance Testing and Test Data

1. What is that I'm testing as part of performance?
2. What do I want to evaluate in the name of performance?
3. What part of the system is evaluated for its performance?
• Should I evaluate this in isolation or as a wholeness of the system?
4. What domain knowledge and information I should have when testing for performance?
5. What system's architecture and internal details I should understand and be aware to test for performance?
6. Is this the first delivery?  Or, do we have this system running in the production?
• If it is first delivery,
• How will I create the test data to suit the consumers of this application?
• What are the key workflows of business that we should be evaluating for its performance?
• Do all workflows and sub-systems need the evaluation for performance, and on priority?
• How do I map the fragmentation of users and their data [with its patterns]?
• What are the infrastructure and ecosystem characteristics that should be part of the test data identified?
• Does caching have any effect if the same pattern of data is used?
• If it is a running version in production
• Can I refer to the DB to figure out the pattern for the particular workflow that I'm evaluating?
• How can I match the test data to have the production data's characteristics and attributes?
7. What is the backup strategy for the Test Data?
• How do I version control the Test Data?
• Which version of the Test Data I should be using?
8. What is the threshold I'm targeting with Test Data?
• What should be the size of the data in DB when I make the IO and RW operations?
• What should be the network capability when I make the IO and RW operations?
• What should be the hardware capability when I make the IO and RW operations?
• What should be the geographical traffic and its pattern when I make the IO and RW operations?
• More of such factors will be considered when identifying and deriving the test data.
9. What is the client error yielding Test Data that I should have for the workflow?
10. What is the server error yielding Test Data that I should have for the workflow?
11. What is the redirection yielding Test Data that I should have for the workflow?
12. What is the no-response and no-change Test Data that I should have for the workflow?

And, more.  It is simple; get in touch to discuss and know beyond the listed.

To conclude and stop here, all these questions, do not ensure or assure or make sure that I will have test data for evaluating a characteristic of performance.

• It helps me to know:
• What are the tests I should be doing?
• What kind of preparation I should be having in my practice to create the Test Data for these tests?

The, Test Data should challenge the available Testability and its limits.  If it is not doing, then, we are having a test data no doubt about it; but, it is of shallow. Shallow!?

One has to ask self, "Is this sufficient enough and effective Test Data for the system [and workflow] I'm testing?"

The, Test Data should drive the engineering team to add more layers of Testability into the system.

MVQT: The Testing and Tests with a MVP's Perspectives

I was leading multiple teams and its delivery in a testing service company.  Then, I came up with this thought -- Like MVP, I also have the MVT (Minimum Viable Tests) for a MVP.

Further, I expanded this thought in my day-to-day practice on tailoring to different contexts. I'm observing that it is applying well to the different contexts when I tailor it to the contexts.  After experimenting it for 10 years, I'm sharing this as a blog post.

What is a MVP?

I take this from Eric Ries.  It looks simple and precise to me.

The Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

I see this technique [and a concept] can be applied to anything when I'm developing.  As a test engineer, I develop the tests and test code in major as part of my testing.  On applying the idea of MVP to my testing and deliveries, I see the value and result.

Reading this blog post of me to know who is a developer.

Testing, Tests, MVP and MVQT

In software test engineering, I see the MVP as Minimum Viable Questioning Tests.

The Minimum Viable 'Q' Tests (MVQT) for a focused area of a feature [or to a feature]

• Helps me to identify the priority tests that should be executed for first
• Allows me to learn information on priority which matters critically to product and stakeholders
• So that a informed decision can be made.

The Q in MVQT stands for "questioning".  I read it as Minimum Viable Questioning Tests.  I see the "Q" as a placeholder for the Quality Criteria.  That is, MVFT means Minimum Viable Questioning Functional Tests to a feature or a workflow.

The MVQT are key to know:

• Have I identified and designed the priority tests?  How do I know that I have got them?
• Did stakeholders get the information which they wanted to know on priority?
• Did MVQT help me to
• Explore and know what I wanted to know about a feature or a workflow?
• How fast I was here to know and learn this?
• How did I develop my tests incrementally?  Did I?  If not, then, is it a MVQT?
• Did MVQT help me to know
• Am I aligned and in sync with expectations of my stakeholders and customers who are using the software product I'm testing and automating?
• Did the MVQT help me 
• In collecting the critical information in a given context for the scope of testing and automation?
• Do the learning and outcome from this MVQT help to reinforce the validated learning of customer?
• Do MVQT result support the outcome of Unit Testing result?

The tests in MVQT has to be consistently revised and evaluated to keep it as a MVQT.  Note this, not all tests are MVQT.  If the number of MVQT is growing to a part of feature or to a feature, it is time to think about what is MVQT for you.

The "minimum" tests are highly effective and it helps me learn and test better technically and socially.

MVQT and Testing

• Sanity or Smoke Tests
• The set of MVQT which helps me learn can the build be taken further testing
• MVFT - Minimum Viable Questioning Functional Tests
• Apply this to a feature or a workflow or to that part which can be evaluated with minimum tests for its functionality
• To update is this aligning to the validated learning of customer [stakeholders]
• MVPT - Minimum Viable Questioning Performance Tests
• MVUT - Minimum Viable Questioning Usability Tests
• MVAT - Minimum Viable Questioning Accessibility Tests
• MVTxT - Minimum Viable Questioning Tester's Experience Tests
• MVST - Minimum Viable Questioning Security Tests
• MVAF - Minimum Viable Questioning Automation to a Feature
• MVLT - Minimum Viable Questioning Localization Tests
• MVUIT - Minimum Viable Questioning UI Tests

You add more of this to your list and context.

In a way, MVQT should ask and look for the testability, automatability and observability.  If this is not happening, then there is no possibility of saying I have got my MVQT.

More importantly, in the CI-CD ecosystem, MVQT pays a major role.  If I should have my tests in the  CI-CD pipeline, then, the MVQT is the way and it focuses on a targeted area to evaluate it.  Else, it is hard, impractical and not possible to test in CI-CD eco system by delivering continuously.

Ask and Review for MVQT

Ask for MVQT, when you review these:

• test strategy, test framing, test design, test ideas, test cases, test plan, test architecture, test engineering, testing center of excellence, and test code

For example,

• What is the minimum viable questioning performance tests that you have got to test this feature?
• What is the minimum viable questioning performance tests that you have got to test this workflow?
• What is the minimum viable questioning security tests that you have got to test this feature?
• What is the minimum viable questioning GUI tests that you have got to test this feature?
• What is the minimum viable questioning contract tests that you have got to test this end point?

Likewise, What is the minimum viable questioning automation tests that you have got to test this feature?

Ask how these tests qualify as MVQT in this context of testing and automation?

This should help you to see how effective is the test strategy in a given context.

Importantly, the MVQT and its effectiveness is a testability to test your tests.

The Credit is to Me

I'm not sure if the idea what I'm saying here in this blog post is practiced by other test engineers.  I have not seen this being discussed about it in public forum.  I have not come across it in my awareness and to the exposure I have put myself.

Hence, I will take this credit to me.  Giving the credit honestly is not a common sight and practice.  I have not got my due credits for using the ideas, thoughts and work that I have come up with.

So, I make it as a open letter and call out that credit for this idea, thought, concept, and practice will be to me when you listen, use and practice it.

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?

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.

Unsaid Skill embedded in the Code and Tests - Questioning

 

I read this question from Balaji Santhanagopalan in the Telegram group of The Test Chat.  This question is also on Linkedin, here.

A question to my fellow testers. How you are sharpening your questioning skills?

I see the first is to know the need for it.  And the ability to identify the question first.  In this blog post, I'm sharing how I cross through it.

I'm attempting to open my thoughts on questioning in different facets that I see:

1. Philosophical
2. Problem Learning and Identification
3. Binary and Questions
4. Pausing and Stopping with Questioning
5. Persuasion and Communication

I understand the word "skill" as:

• how do I make use of or apply what I practice, what I have or know in learning and solving a problem

Philosophical or Meta Layer Thoughts

1. When did we not use a question?
2. To better the questioning skills, we will have to identify the questions first.
3. How do we identify the questions?

How do we identify the questions?

• When I communicate
• When I communicate by showing I belong there and also do not belong there, I identify the questions. 
• And eventually, I will be identified in it

Decisions and Questions

• Everything and anything we do is by making a decision
• To decide, did we make use of the question(s)?  
• We keep making thousands of decisions every day, and 
• Each decision will have at least one question to it

For example, the last time you unlocked and locked your mobile screen, you had a question.  But that question went unnoticed.  It was at a subconscious level; it was not noticed by you consciously.  

At times what helped your subconsciousness could be a contextual question, and sometimes it can be a context-free question.  The combination of both is also possible.

Problem Identification, Learning, Understanding, and Solving Thoughts

While I use the questioning to learn, I will have to cross these challenges:

1. Keeping the questions in conscious order so that I can classify them
2. Classifying them to record it better in a contextual and context-free section
3. Will the questions annoy the one at receiving end and how to persuade so I receive a response that helps me?
4. Keeping the questions aligned with the objective yet we have context-free ones

Using the persuading skills with question and questioning will help much.  Consistently develop self-confidence and courage.

Technical Layers - Binary and Questioning

Binary - true or false.  You see that is a decision.  When I have a decision, I have a question.  The binary execution uses the conditions, states, events, data, and controls at the granular level with all interactions we have with it.

For example,

1. What happens when you unlock your screen with the fingerprint?
2. When you sign in to your email, what happens?
3. Here, internally software executes the set of conditions and the assertions by switching the controls, state, data, and events.

What are contextual questions and context-free questions in this case?  When you have a condition and an assertion in execution, you see a question?

In other words,

• the execution is an outcome of a question be it in binary or in a human

Internally the software works by asking questions and deciding what to do.  Now, what should my tests do?  Should it ask questions?

We engineers, we work with questions day in and out.  And, we do not know it consciously. 

Pausing and Stopping with Questioning

Have you come across the question

When the testing will be complete?

  

Can the testing be complete?

We would have paused the testing. Or, we would have stopped the testing.  But we never complete or completed the testing.  Testing can go and go on.  But it has to find a stop.  So is the questioning.  The questioning has to find a stop.  It can't go on and on.

When to stop questioning?  Ask when you want to stop or pause the testing.  It is important to know when to stop it.

Questions (tests) keep coming up and they may not be heard by the interfaces or people.  Learning to deal with it is a needed skill.

Art of Persuasion

When I communicate, how I persuade plays a role.  It also applies to questions I ask.

• Questioning is also communication
• Practicing the skill of persuasion will help as I continue to question

How to persuade using a question to a binary and human?  I work on this skill to assist my communication and questioning skills.

My Experiences and I

The below is missed to see on the floor by people who interact with the engineers and by the engineers.

1. A programmer has questions in the code via conditions, states, events, data, and controls.
• The product responds to do what it is supposed to do with help of these questions.
• Do you see any contextual and context-free questions here?
2. A tester has questions in the form of the tests.
• The question of testers will be to the
• code, 
• product, 
• data, 
• programmer, 
• infrastructure, 
• system, and 
• anyone who adds value to the product
• Do you see any contextual and context-free questions here?

Identifying the questions (code and tests) and their layers is one of activity I do in my practice.  I try to understand and identify myself here so we communicate.  

For example, I have to test if the host serves requests coming from the client which is not on TLS v1.2.  What are the layers and their intermediates here?  What questions do I have in my tests here?  When I look into these layers, I see the questions (code) logically?  To question the logic what is my test (question).  Here is the start!

Further, to hone or better the questioning skills, I will identify the questions in the below mentioned:

• system,
• design
• code,
• product, 
• business, 
• technology, 
• people, 
• self, and
• what you are not aware
• what you know

I will classify the questions into contextual and context-free.  

I persuade my communication and questions by making use of Test Strategy, Test Design, and Testing Techniques to drive me towards value adding questions in the context of testing. 

I will work to develop my skills, self-confidence, and courage to test, communicate, and question.  I will break my ego and hesitation and step up. I initiate the communication.  I will acknowledge the feedback. I review and refine my questions.

To start, I will start first and the rest follows.