I Transformed In The Heat of Software Testing's Words & Glossary

I'm talking about the words, glossary, and jargon we use in our communication, especially in software testing.

Words in Use

Manual Tester, Manual Testing, QA, QA Automation Testing, Automation Testing, Automate, Automation, Tests, Checks, Verify, Validate, Test Case, and more.

Are these words right or wrong to have in Software Testing's glossary?  I want to see beyond right and wrong.  I will share my learning on this in a different blog post.

Then

When I started my career, I advocated for using the appropriate words and glossary when talking about Software Testing.  I was in this state of mind. I continued in it.

The information on the web for Software Testing was minimal and not abundant as it is today.  I observed practitioners questioning, debating, arguing, and challenging the words and glossary used in Software Testing.  I see, it is good that this scrutiny happened.

It took me years to come out of it and realize what I should be focusing on.

Eventually, I realized it is not changing; it continued and continuing.  I changed. I transformed.  I'm evolving!

Now

Today as well, I see practitioners questioning, debating, and challenging the same words and glossary.  Is this a need?  Yes, it is a need.  Who else will do it if we do not do it?

But, how do I do it now?  I do not discuss it with all and everywhere I see a discussion and opportunity.

Today,

• I listen to people as I did
• I understand what they mean by the words and glossary used in the discussion
• I take an opportunity to trade and introduce the word in discussion in a light way
• I see the other side interprets it as I interpret their word
• We mutually agree on what is expected and to be delivered
• I will move on to continue our discussion and accomplish what we have to
• How often do I do this?
• I choose when to do it
• But I keep the happening calm and a delightful conversing

I'm not stuck or getting into a discussion on words and glossary as I did.

I'm watchful about what I use in discussion and testing delivery.  With my fellow software test engineers on the team, I share my insights, discuss and focus on our work.  I do not enforce or impose anything.  But, I always welcome questioning and challening me.

This has brought me calm, peace, energy, and time for what should I be learning and doing.

Do I ask other fellow practitioners to do the same?  I will not get into this thought.  Let one do what one wants to do.  I converse and discuss if I have any questions and it makes me curious. I move on!

As a practitioner, I know, it is important that I speak up for my craft's and subject's words and glossary.  I introduce it in a light way.  If one is interested, I will be asked about it.

Change in the self is a first progress and I feel peace with it.

Test Automation Pyramid and Its Multiple Misinterpretations

 

I Decided to Write this Post

I thought over a few months, should I write this post. I said, yes to myself for writing this post.  Before, I proceed, I want to express this:

Hello Mike Cohn, thanks for giving Test Automation Pyramid visualization to the software engineering community.  I see your thought process, experience, and work, in this model. This model's assistance to understand software systems is evident today.  

Again, thanks for giving this model as a metaphor for us.

What I See?

I see a risk for the Software Testing community especially when we use the word The Test Pyramid without knowing what it is and does it make sense. 

To keep you till the end of this post so that you get what is my point, I tell you this:

One of the common entities among Testing and Automation is the tests.  How the test's intent is expressed and executed in the testing and automation, is not similar; they are different and have to be different.  If similar, then it leads to misunderstanding -- automation as the only way of testing; or, the execution of tests by a human as the only way of testing.

Why did I Say "Yes" to Myself?

• The metaphor which Mike Cohn came up with is helpful
• I see, Mike Cohn knew what he is trying to say and it makes very much sense in today's Software Engineering
• His book Succeeding With Agile got published in 2010
• It has a chapter with title Quality
• I insist, that anyone who is involved in software development should read this chapter if cannot make the time to read this book
• This chapter talks about the pyramid
• The Test Automation Pyramid
• Mike Cohn came up with this concept
• This acts as a helpful metaphor and a heuristic
• In 2010, I don't know how much did it help then; but this model is a beautiful and simplistic explanation of how to categorize the software system's layers for test code
• In 2023, it helps everyone who is involved in the development of software system
• I have witnessed how software engineering has grown in the last 23 years
• Reading what Mike Cohn has to say about it, helps to clear the misunderstanding of The Test Automation Pyramid to The Test Pyramid, for first

Today the word "The Test Pyramid" is very common among people who are into software development. For this reason, is it misread and communicated?  Maybe!  The software engineering community refers to this model as The Test Pyramid and not as The Test Automation Pyramid.

I want to share my thoughts on the risks of calling it The Test Pyramid.

• I strongly see the software engineering community and importantly the software testing community need to know it

So, I have decided to write this post.

Quality Is a Team Effort

Mike Cohn, said this in 2010 in his book Succeeding With Agile. 

Today, who does not claim "We are Agile"?  Are your team and organization, Agile?

Yet, we see discussions on who should be owning and responsible for the quality while we are in 2023.  Especially the software test engineers ask this as they are said responsible for the quality of the software systems they are testing.

The chapter Quality has a section "Quality Is a Team Effort"; this section has the below lines:

Acquiring new testing skills, learning how to apply them within the strict timeboxes of Scrum, and paying off technical debts are the responsibility of the whole team.  These are not challenges to be sloughed off onto the testers.

Quality is everyone's effort and responsibility.

Test Automation Pyramid

Automation is one of the ways we do the testing.

Here are some of the tests (actions) that can be done through automation and asserted:

• Which are repeatable and can be asserted
• Which are run to setup, tear down, configure, create, edit, read, and delete the resource 
• Which are monitoring to inform the change in state/event/data
• Whose execution is in a defined order and trying to assert the expected outcome

Some tests are better evaluated via automation and with the help of automation.  Some tests are better evaluated by the execution of a human.

• Both are important and necessary in today's Software Engineering and Software Development

Back in 2010, the boxes were monolithic; the microservices were a theory.  Today, we are thinking beyond microservices, containers, serverless and more.

Given the complexity of  Software Systems, today, we need a model of how we can isolate it into categories and layers.  So that it is simple to learn, understand, to categorize the development of code & test, and execute the testing of same.

This is where I see the usefulness of a model given by Mike Cohn.  It shows the layered architecture pattern in a way, for a [part of] software system:

• That we are about to understand, and 
• Figure out the strategy for testing using automation in respective layers

Now, do you see the importance and help of the Test Automation Pyramid model?

Mike Cohn expressed the three layers in Test Automation Pyramid. It is as below.  I have copy pasted this below image from his book Succeeding With Agile. That way, I keep the original thought and picture of the model as given by the author.

Pic: The Test Automation Pyramid from Mike Cohn

Pic credits: Mike Cohn

Benefits of Test Automation Pyramid

• It helps to relook into the automation strategy
• It says, we need a better strategy to automate by showing us to categorize the tests in a layered pattern
• It helps to learn how the two different layers can communicate and can be used together in automation 
• For example, the service and UI
• So that tests are isolated and maintenance is manageable, while the deterministic feedback obtained from the tests automated is value-adding.

I have heard Dorothy Graham say she did automation when she started testing.  I see she has 40+ years of experience in Software Engineering & Testing.  So, automation is not new.  It is evolving.

This Test Automation Pyramid describes the automation which we talk about in day-to-day engineering to be more understandable and communicative.

Is This a Test Pyramid?

I understand, Test Automation Pyramid is not The Test Pyramid.

It is a pyramid for the tests carried out through automation.  

Test Automation Pyramid helps to identify, design, categorize, relate, map, and use the outcome of tests from another layer.  This benefit can be sought in both, that is, testing through automation and testing by a human.

This is a risk I see

• The Software Engineering and Software Testing communities are learning that automation is the only testing and the only way to test.
• No, it is not the only way to test and it is not what is testing all about
• Automation is one of the ways we do our testing and has its limitations
• Automation is a subset and a part of Software Testing
• Automation exists to assist Software Testing and to do better testing as a whole; not to replace the testing; not to claim it is the only testing and way to test in every dimension and context
• This is a problem for the upcoming generation of software engineers, and those engineers who take Software Testing as their full-time practice and job
• This sends a message that automation is testing and testing is automation
• This will be the problem to the practices of automation and testing in Software Testing
• For example, when I talk to test engineers and say, Test Automation Pyramid, I hear they are not aware of it; all they are aware of is The Test Pyramid of three layers used for automation
• As a result, there will be shallow results and benefits from both automation and testing with costs and short of value
• Here, automation and testing cannot complement each other effectively when used together

Calling it a Test Pyramid and referring it to just to talk about automation, is not right technically and logically.

I see Mike Cohn knows the differences between the value of Testing and the value of automation in testing, as different activities from his work and experiences.  I believe, for this reason, he labeled this model explicitly as The Test Automation Pyramid.

I did not find any references for Mike Cohn renaming this model as The Test Pyramid.

Also, calling it a Test Pyramid and the top of a triangle having a scoop or cloud with the name "Manual Testing" is misleading.  I see this is one more cause of confusion.  Does this triangle say to automate at every layer and just involve a human at the GUI interface for testing?

• No! We, humans, test at the service layer as well and also automate here
• At the unit layer,
• a human manages to setup/configure at the seam or/and use test doubles, stubs, mocks, and what is needed to execute the tests via code
• If you see, one pyramid, misinterpreted and misrepresented in multiple ways.

I learn, as a community, we are misinterpreting the Test Automation Pyramid model [work] and calling it by another name.  Is this right?

If one sees no difference between testing and automation, fine!  Then everything is applicable and looks alike.  Then calling Test Pyramid and Test Automation Pyramid does not make any difference.

But, actually, it is not the same [and similar].

The common thing between automation and testing is the tests.  The purpose, nature, procedure, design, strategy, and intent of the tests differ in automation and testing.

It is Test Automation Pyramid

We Software Test Engineers, think [of] [the] tests as automation most times because we believe and are said the programming and code are everything in the software system.

• The code of a software system is one of the byproducts of developing a Software System
• So are the tests.
• The test code is one of the byproducts of automation and not the whole software system

A part of the test is automatable. Which part? 

• It depends on how I express my test with its intent
• So that I will know which part and aspect of a test can be automated

Automation in testing is one of the subsets of Testing, but NOT similar to Testing in every dynamics, dimension, and aspect.

Automation has its own subsets of dynamics, dimensions, and aspects of testing.  If we practice by learning Testing and Automation are the same and if we remain in this understanding,

• We cannot identify
• The differences between Testing and Automation
• The differences between the tests identified for Testing through Automation and Testing by human
• The values each offer along with its limitations.

Referring it to as a Test Pyramid and just talking about automation out of it, is not Test Pyramid.

I call and refer it to as Test Automation Pyramid and not The Test Pyramid.  Again, I thank Mike Cohn for giving this clarity in his model and its name.

Let us refer to Mike Cohn's model by the name and understanding to which he refers it with.

If you ask/say, "it is a model; can't we improvise it to one's context?" 

• Yes, we can and a model is not fit for all contexts
• Showing the same model picture along with the same name for its attributes and expressing a different thought is a problem
• It misleads one if she/he takes this model as a reference
• This will have chains and it continues

To end,

• Embrace programming
• Practice programming
• Embrace automation
• Practice automation
• Implement automation
• Call and refer to automation as automation
• Know what is testing in automation
• Know what is testing
• Call and refer to testing as testing
• Practice testing
• Know your testing in Software Test Engineering
• Call and refer to the model with its name given by its creator/author
• That name has a purpose and intent
• Know it; understand it; learn it

References

• The book "Succeeding With Agile: Software Development Using Scrum" by Mike Cohn
• https://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid
• https://martinfowler.com/articles/practical-test-pyramid.html
• https://medium.com/tide-engineering-team/the-practical-test-pyramid-c4fcdbc8b497

When to Start the Automation in Software Testing?

The Question of a Decade?

Today, when I draft this post, the calendar date is 14th February 2023.  If I look back to 10 years ago and ask myself what are the questions in and around Software Testing and Automation, I see this question.  What is that question?

When to start the automation?

We answer, hear, read, and discuss this question, today too!

Often, the opinion that comes out is, ".... to automate when it is stable".  Note that it is an opinion, not an answer or a fact accepted universally.

To Start Automation when it is "Stable"!?

My learning is,

Do not think of starting the automation when it is "stable".

The "stable" is an assumption we tend to believe by the outcome of using the system.  The binaries are never "stable".

The binaries appear to not show any risks and problems for the way one is using it in a context.  To be more precise, we are not seeing the risks and problems that binaries are showing us in other dimensions.  That is, the dimensions that we are not aware of or the dimensions that we are not focusing on.

When to Start the Automation?

I learn,

Start the automation, when the system is testable!

This leads to me the questions:

• What is testable?
• When it is testable?

Understanding testability helps me to learn and identify its child attribute -- automatability.  That is, understanding testability helps me to learn the order of "testable".

Testability does not mean "stable".  Testable does not mean "stable".

But the assumption "stable" means there are some characteristics of testability, automatability, and order of testable.

Automate when you learn, it is testable, and identify a layer of testability.  This helps to pick the better seam [that is the appropriate layer(s)] for automation in a given context.

Keep the automation structure ready, so that intent of a test can be expressed via code as we identify [a layer of] testability.

Maybe, this is what people say LEFT or SHIFT LEFT or START LEFT.  Or, could be out of the SHIFT LEFT BOX!

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

 

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.

Between the words Smoke and Sanity, and Test

 

Why Testing and Tests?

In simple and short, we test to have confidence in what we expect to believe or claim.  For example, I believe this code does what it is supposed to do in a context.  The tests in the testing may help to learn that and thereby help in having confidence.  Likewise, if the tests in testing are intended to prove with rational evidence that this does not work as expected -  this is also a confidence in how we see the claim.

Testing and Tests:

• are highly contextual
• it depends on the person who is testing
• her/his understanding of testing and tests
• how she/he applies the testing and tests
• her/his thought process and ideologies on testing and tests
• it depends on the person who is referring to the outcome of testing
• it is highly oriented toward the expectation of the stakeholders
• on what it has to be
• on how it has to be
• on what it has to serve

If there is anything in Software Development that can be tailored to the need, I see it is Software Testing.  It happens that everyone has her/his own understanding and definitions for Software Testing and how it has to be implemented and executed.  And, it is done that way!

But the same is not observed with programming, DevOps, finance, sales & marketing; or, not to the extent seen in Software Testing.  This is my observation and understanding.  Is that wrong?  That's altogether a different topic of discussion.

In the organizations, I have worked and in the projects that I have worked on within an organization, the software testing was defined and executed how they wanted it.   Though they were a few common things, how these common things were implemented and understood is not the same.

Smoke and Sanity, and Test

Before I begin, here are the questions that I would want you to answer for yourself:

1. Would you start with Smoke Test and then start the Sanity Test?
2. Would you continue with Sanity Test after the Smoke Test?  Why?
3. What do you consider in Smoke Test and Sanity Test?  Anything in common?
4. What did you learn from the outcome of the Smoke Test and Sanity Test?
5. What did you decide and what was the next action to the outcome of the Smoke Test and Sanity Test?
6. What was the need if you carried out Smoke Test and Sanity Test as a different testing activities?
• How this is helping you and your stakeholders?
7. What will you lose if you do not perform either the Smoke Test or the Sanity Test?
• What is the cost of doing so?
8. What is your understanding of the Smoke Test?
• How did you establish this understanding?
• Any update to this understanding of yours?
• What is the coverage expected out of the Smoke Test?
9. What is your understanding of the Sanity Test?
• How did you establish this understanding?
• Any update to this understanding of yours?
• What is the coverage expected out of the Sanity Test?
10. Do software engineers, software companies and practitioners, and engineering teams use these terms as you use?

I learn the word "Smoke Test" comes from the hardware testing context.  Then from where did the word "Sanity Test" come from?  I don't know!  

Further, I understand that the intent of these two words is the same.  That is, to have confidence in either continuing to use the build for further tests or not to use that particular build to test.

Scope and Coverage of Smoke and Sanity Tests

What comes in the scope of the "Smoke Test" or "Sanity Test" is again the question and confusion that is being carried and passed on to the generation of Software Test Engineers.  Could be this is creating a gap in understanding what it is.

Often, I have seen the scope and coverage expected out of the Smoke Test and Sanity Test are the same.  Just these two words, the Smoke Test and Sanity Test are being used interchangeably in the Software Engineering community and practice.

I could not differentiate and identify the uniqueness among them to date in my experience.  All I see is the words "test" and "testing" associate very well with any word you bring into a context. Later, everyone will define their own idea and words to it.  

If observed, the same does not happen in the other areas of software engineering.  Why?  I learn that we have kept Software Testing to be far from being technical.  This is one of the major setback reasons.

Software Testing is Technical

When I say technical, the programming is treated and accepted as technical; the DevOps is considered technical; the database administration is taken as technical.  But the software testing which overlaps with all of these engineering areas is not considered technical.

I started my software testing career in the waterfall practice days.  At times, the testing and programming teams were independent and did not interact at all. The business and project management team which got the requirement did not have interaction with testing unless for asking "can you sign off saying this be shipped.".

Today, I see the mindset of accepting software testing is technical.  In my career, over the last 7 years, I see the industry is slowly including software testing to tech excellence.  But it is yet to get its one common standards and glossary which will be used by all practitioners.

However, I see the software industry and communities yet to accept and acknowledge that people and context dynamics are also the propellers of Software Testing while it is technical.

A Solution to the Problem

When a subject and practice are considered technical, the ideas and how it is defined will also be taken seriously.  There will be no casual language when communicating the subject, work and practice.  

When I say technical, I mean it in the context of Software Engineering.  How we perceive what is technical in Software Engineering, I mean that.

I wish, this comes to Software Testing and possibly put an end to the casually used language and words.

Time to Update the 101s for Test Engineers

 

The thought I'm sharing in this post is growing stronger in me, in recent years. I shared it as points with the community in the #21Days21Tips initiative from The Test Chat.  I post it on my blog as well so that it will be a reminder to me when I scroll through my posts.

The 101s for Test Engineers

Today, the first few stepping lessons of Testing and Automation to be on -- "How to Overcome the Fear of Failure".  If this is not available in the team and organization, it is time to start and build it.  The present and future Test Engineers need it.

The starting lessons or 101 of the Testing and Automation need not necessarily be:

• What are Testing and Automation?
• Test Design and Techniques
• Programming Language
• Tech Stack, Full Stack
• Clean Code
• Design Patterns
• Tools
• What should I pick; how & where to start here?

All these will connect and align when one can handle self-doubts and fear of failure.

Approach Goals and Avoidance Goals

As a team, organization and mentor, help your Test Engineers to have "Approach Goals" than letting them build "Avoidance Goals" out of fear.  I see practicing the Approach Goals is a life skill, today.

I take the below lines from this post:

Approach Goals are those with positive outcomes that we work towards.  Positive can mean different things in different contexts, such as liked, desirable, pleasurable, or beneficial.

Avoidance Goals are those with negative outcomes that we work to avoid. Negative can mean different things, including disliked, undesirable, painful, or harmful.

Examples:

• Approach Goals
• Know why I have those fears when I think of automation?
• I need to be skilled in automation. How can I manage my fears and proceed with practicing automation?
• I need to do better testing with help of automation. What I should practice for doing this? What help I will need?

• Avoidance Goals
• I will start practicing automation next month
• I will start automation once I understand and write good code
• I will start automation once I understand Design Patterns and Clean Code
• I will start automation once I learn how to write a framework
• I need to do it well; let me learn the basics very well first and then let me do automation
• I will check for workshops and people who can help me to do automation

Approach Goal: I will start it! No matter how small it is, I will start. I will keep updating as I learn. I start it from here -- Automate a browser to launch and open a new tab.

Frame the Approach Goal that helps to take one ahead by dealing with the fear.  The goal needs to make sure the milestones of learning are highlighted to one.  That way, one feels confident and has clarity along with skills of learning better be it what is new or what one is aware of.

Note: If the question is why I talk of automation in the examples of Approach Goals and Avoidance Goals, this is what we hear from the majority of Test Engineers today.

My Experience

When the Test Engineers know to build and use the Approach Goals, they will align and practice better on subjects:

• With which Test Engineers are unfamiliar
• With which Test Engineers are uncomfortable

Also, help the Test Engineers to build skills to spot Avoidance Goals.  So that, they are aware of the Avoidance Goals they tend to have and construct positive Approach Goals to learn new skills and solve the problems.

Understanding - Are Framework and Library the Same?

We Have This Question

• What is a Framework?
• What is a Library?  

I had these questions when I started my testing career.  At times, I ask this question today as well, when I listen to fellow engineers talk about it.  

I can say firmly that you had these questions.  You would have asked these questions to yourself or to your fellow testers.

Using Interchangeably

In the teams in which I have worked and in the community, I have seen these two terms are used interchangeably.  This has added to the confusion.  At times you might see the programmers using these two words interchangeably; but, they might know what it does and how to use it.

If I were to start my automation practice, to what should I call framework and library?  Does this question have crossed your mind and thoughts?

Framework and Library - What it is?

I understand both Framework and Library as code.  Yes, both are programming code that is structured and organized in a way.  This code is written by a programmer and will be consumed by other programmers and testers.  

Why do we use it?  We use it to assist in solving a problem we have in our work.  May be is what leads one to get confused or use these words interchangeably.  But are they one and the same?  I had this question.  I spoke to programmers and testers with whom I worked.  I observe each of them having their own ideas and perspectives about it.  

But are they one and the same?  As of today, I understand Framework and Library are not the same. It differs in -- the ease of consumption as is and the code to be written and organized for using it.  I see these two factors differentiate Framework and Library; there could be more factors and I'm not aware of it.

Framework and Library - My Experiences

I use libraries in testing and automation I do.  For example, 

• the Selenium library to interact with the browser and perform the actions on the web pages
• the RestAssured library to build the HTTP request
• the Appium library to interact with the mobile OS and its app's UI

I shared the above examples as most of us are aware of them and relate to them in our work.  Then, what is the framework?  

Have we heard of these words -- React, Angular, Bootstrap, and Flutter?  Today we use them to build web apps and mobile apps (using Flutter).  These are frameworks consumed by programmers to build the applications.  Some of these frameworks provide libraries to test as well.  For example, Chai and Jest assertion libraries.

Trying to understand further, one of my programming friends said me about the principle -- Inversion of Control.  Inversion of Control allows a framework to inject dependencies, inject configuration and manage lifecycle. That way programmer's program can focus on what it must do and not have to worry about any additional responsibilities.

I learn, Inversion of Control refers to transferring the control of objects and their dependencies from the main program to a container or framework.  How this will be implemented depends on the programmer and the design used to implement the same.

Note: In one of the perspectives I learn the framework provides the abstraction to its libraries.  We use these abstractions of a framework and develop our applications.  Can I say framework means abstraction?

Difference: Framework and Library

In the way we communicate, most times it is communicated as there is no difference between them and both mean the same.  Probably this is the reason we have the confusion, especially the Test Engineers who want to start the practice of automation will have this confusion.  This is being passed on to the next generation of Test Engineers who come take up Software Testing as a career.

Technically, the difference exists between the Framework and Library.  One of the key differences lies in the principle mentioned above -- Inversion of Control.  Let me walk through this with a use case that we Test Engineers cross every day.

Use Case in using a Library: Automating a user action on a web page

• I make use of the Selenium library
• I initialize the WebDriver and a driver of a browser
• I open a browser on my machine using WebDriver communicating with the browser's driver
• I talk to the browser to launch a URL
• I make actions on the web page

I'm not writing a code to do all of the above said.  I'm making use of APIs exposed by the Selenium library to do all of these actions.  The library's code handles all these for me.  My code will be for -- to consume Selenium's API and to aid evaluation of business logic -- the Utils is a commonly used word to describe the Class which has methods for the same.  

When I'm using a library, I have control over the code that I write in automation in deciding how the automation should execute that is in what order and what flow.  I can decide when to make what actions on the web page here.  The Selenium library does not mandate it on me.  

The only mandate I see is the sequence of actions that has to be made when using a particular API.  For example, the action events to be made in what order when used the Touch Actions API.

Use Case in using a Framework: Building a web and mobile app

• The team developing Android and iOS mobile apps using Flutter
• The team developing a web using Flutter or React

Just by using the Flutter and React frameworks, the apps and website will not be ready.  The programmer follows the structure and sequence insisted by the framework in her/his code.  The framework will tell how the code should be written and probably this also means the flow of code is controlled by Framework.  For example, when loading the content on the web page and screen.

In one of my current projects, the place where the message is displayed, how it is displayed, and how to interact with it, is a flow in code.  The programmer has to work oblige how the framework parses the error message.  It has to be done that way unless the programmer writes a custom code and plugs it into the framework, provided the framework supports it.  

This code which the programmer plugs in now, it is a custom library developed to use with a being used framework.  Now using this custom-built library, the reading or/and display of error messages can be made as per the need of the product.

Automation: Do We Write Library or Framework?

When we testers say automation framework, I see that we are referring to the structured library we have written consuming a framework and library.  For example, Arjuna developed by Rahul Verma is a framework.  I will consume Arjuna and build a library that has tests to automate web applications using the library as Selenium.

The automation I write consuming a framework and/or a library will have methods. Few of these methods will be written once and can be used in multiple places.  That is no repeating code and practicing the reuse of code.  It is like DRY -- Do Not Repeat Yourself.  We can see this practice in the automation we write.

For example, the below code can be written once in a class and invoked in different places where we test the business logic.  Now, these two methods will act as a library code and it is also part of a library code.  

We just call the method name and pass the parameters in different classes where it is needed.  No need to implement these methods each time in business logic where it is needed.  

Doesn't this give a perspective that a framework includes a library within it?  And, this questions me --  should I call automation what I do as an Automation Framework?  I say NO!  Unless someone uses my work as a foundation to build their tests and it dictates how the code should be written and structured, I do not call it a framework.  

But, one can use the classes that I write in their work.  This class act as a library.  Recall the class file name with Utils; this file has methods that we use by invoking it across the package.  One good example of this is, the logging part we write in our automation.  This logging part of code can be built as a library and can be used in different automation projects in which we work.

This is my understanding of Library and Framework at this point in time.  You have any questions or other perspectives that I'm not seeing, do share.

Time and Reflection of Time - Test Engineering

 

Time and Reflection of Time

I wish to share by writing my observations and experiences with the happenings in and around Software Testing since I started my career.  Be it technical or not, I write it so I can mark the time (past and present) of Software Testing.  The time which I experienced and experiencing!  Reflection!

I will be sharing the observations and learning of me under the label Time.  My reflection is always limited; probably constrained too, as I cannot observe the happenings and development in Test Engineering at multiple dimensions in a given time.  I will try to reflect on my learnings and understanding of the changes, adaptation, and evolvement in Software Test Engineering.

Does that happening is good or bad that is not the subject of analysis.  But, the subject is to see what it is with respect to Software Testing and Test Engineering; how it contributes to problem solving in Software Engineering.

I read and understand that time is multi-dimensional.  So is the Software Testing.  An engineer can observe, look and test a system in the multi-dimension.  But is that a need?  The time in which we are testing helps to see it with a stakeholder(s) or business's decision.