STeP-IN Summit 2025 and My Experience

 

I start this blog post by expressing my gratitude.  My gratitude to STeP-IN and Vinay Baid.  I attended STeP-IN's 22nd International Conference on Software Testing, on 19th September 2025. 

This blog post is about my experience with STeP-IN Summit 2025.

I'm not paid or asked to write this.  I'm writing to document my experience and observations with STeP-IN Summit 2025.

The Conferences and Me

STeP-IN Summit 2008 is my first testing conference.

Since then, I'm seeing how the conferences around Software Testing & Engineering is shaping and continuing.  Together with the conferences and STeP-IN Summit, I'm shaping and continuing to grow.

For me, the conference[s] look as a timeline and the tree.

• It reflects the past, present and talks about tomorrow.
• In that, STeP-IN Summit shows the landscape of thoughts and drifts around the software testing practice for the last two decades.

I see the series of changes, transformations and trajectories in Software Testing as an industry.  I see the changes in conferences as well.

One of the conferences which is consistently attempting to capture it and get its gist to the test engineers is STeP-IN Summit.  Further, it emphasis on the practice of software testing.

Conference and Take Back

What do you take back from the conference?

Whatever you took back is what you tried to see.

If you want to experience and know the conference and your craft, you should walk in between the attendees in the conference, listen to them, and talk to them.

• You will know what's happening -- inside and outside.
• Inside and outside of what is said in the conference.
• Inside and outside of the one who is attending the conference.
• Inside and outside of you!

If you go to conference and meetup just to listen to the speakers and panel, may be you will not know about your craft, industry and what's happening.  

It is the attendees who carry the torch light. Talk to them.  Know what they are doing, why and how.  Network!

The speakers, panel, vendors booth and sponsors they attempt to show the drift, by calling it theme sometimes.  Is the drift being spoken is the actual drift? This is, uncertain.  Talk to the attendees.

To see the drift with current state, you need to find the torch light.

Find your torch light in your upcoming conferences and meetups.  Catch the drift and surf the waves.

I and STeP-IN Summit 2025

I thank the organizers and Vinay Baid for inviting me to STeP-IN Summit 2025.

This was my in-person software testing conference after 6 years.

I started at 6:30 AM to conference.

• I reached on time and collected my tag.
• The conference's reception was well organized.
• I moved to the conference hall; I see, it is full. I stood at the back.
• The conference's lamp lightened up and got a kick start!

I met my seniors in the conference.  They spotted me and gave a few minutes of their time to me.  I'm happy and grateful.  I see, people value for what you are and what you share.

I listened to talks and panel discussion.

Also, I was moving in between the people outside the hall and in the hall.

• I introduced myself and conversed on multiple subjects.
• I went to each booths outside the hall and learned what they are offering.
• I looked for TestAutothon participants and conversed about the problem statements, and how did they approach their solution to it.

Talks and Distance

After the conference, I took BMTC bus [Bengaluru city's public transport] back to home. It is a long way to home.  These talks replayed in my mind as I traveled the distance to home.

1.  Rahul Verma's Man, Machine & Mischief: How I Co-Wrote a Testing Satire with GenAI

• I see, this talk is a journey shared.

• The journey which shares about self, writing, learning, perspectives, technology, GenAI, co-authoring, book, raising the bar each time, not giving up, design, book publishing, emotions, and testing.  There should be more to it; I could see these.
• What I recalled from this talk is,
• His journey of writing book - The Last Book On Testing.
• How he used the GenAI, while learning how to use it better each time.
• Challenging the ChatGPT models and its responses.
• Not just functional. Beyond functional responses.
• Taking the help of ChatGPT models to co-author.
• Testing the responses and fine tuning the prompts by expressing the personalities.
• Not just the persona; it is personalities.
• He engineered the prompts.
• How he identified the gaps in this tech and learning how to use the GenAI.
• This talk helped me to learn the hindsight behind the book "The Last Book On Testing"
• Per my understanding, Rahul has tested and testing the idea of GenAI.
• In this practice, he has experimented with ChatGPT models to understand the internals and externals of GenAI ecosystem.
• He experimented using ChatGPT models to co-author his book
• Wow!

Meeting Rahul in-person after years is happiness!

Though, I did not converse about testing, automation, engineering, and GenAI, I spoke to him.

I'm happy and surprised to reflect that we both can talk non-tech and non-testing.  But, we understand and know testing is elemental and has its presence in each systems not just the software systems.

2.  Raveendra Chakrakodi's Staying Ahead of GenAI Humanoids

You do not forget some people to whom you listened and spoke in conferences and meetups.  JP is one such person to me.  Now, Raveendra is another such person.

• I will remember this talk of Raveendra Chakrakodi for years.
• It was a 15 minutes talk which reached almost everyone I hope.
• It requires courage to do such talks and share with the audience.
• The audience could connect and feel the connection to this talk.
• He said, he manifested to do this talk day before the conference.
• And it happened!
• The another talk that I remember for years is from Jayapradeep Jiothis [JP].
• This is also a talk in a STeP-IN Summit 2019.
• The audience got up from chair and gave their claps to JP's.
• I will remember this talk of JP for all time.
• These two talks are not completely tech.
• But, these talks are around the life of the people in the software engineering.
• I recalled,
• Jayapradeep's talk as I traveled back to home.
• And, I conversed with the thoughts shared by Raveendra.

3.  Rajarajeswari Rangasamy's Autonomous Testing: The Next Frontier in Quality Engineering

• What struck to me and probably to all others is her body language and voice modeling, when she started.
• I recalled,
• Her body language, short punches, eye contact, and stage presence
• And, Wagile :)
• Waterfall + Agile

When I come across her upcoming talks, I will listen to it.

4.  Ramit Manohar Kaul's Metaphors and Audience Engineering

Ramit co-hosted the summit.  

He conversed with audience.  I have hosted the conferences and meetups.  So I say confidently, he conversed with audience.  He made it look so easy while it is not.

I want to call his hosting as -- Audience Engineering and not Audience Engaging.  As a host, he just did not converse; he shared insights.  This cannot be experienced in all conferences and meetups.

He gave the metaphors to the audience.

• The metaphors of daily life to relate with the tech stacks around the Transformers and GenAI ecosystems. 
• This was a bang, to me!
• I could easily recall and connect to these metaphors and visualize the ecosystem of Transformers and GenAI.
• I wish he gives a talk with the metaphors and it gets recorded, and will be on social media.  I have requested him for this. :)

He engineered the attention of the audience with his wits, humor, messages and insights.  I admire this personality of Ramit too.

I recalled those metaphors and our conversations.

I met Ramit after years.

• I see, we both see the journeys, time and transformation, and embraced each other.
• I feel good!

Conversation with Shrinivas Kulkarni

I met Shrini, my senior.  I got to know there is something called blog by reading his blog in 2007.

I could ask what all I had in my mind at that point in time.

• He shared and explained his perspectives and thoughts on career, roles, industry, layoffs, job, and life.
• I'm happy that I could talk about this with him.

I recalled the insights he shared and the examples he gave, especially the one of manager mindset and individual contributor or engineer mindset.  This example helped me to simply my thoughts around the job roles.

Found The Preface For Book - The Last Book On Testing

When Rahul announced he is authoring a book, I saw the book title having the word "testing".  I pinged him saying, I will be happy to review his book and it is a privilege and honor for me to do so.

Later, reading the teaser he posted for the book, I realized, I could not have reviewed it.  Today, I'm not equipped and skilled to do so.

When he published the book, I read the sample on Amazon Kindle.  I said to myself -- I'm not yet ready to read this book!  

But, how and when to be ready?  I had no answer nor clue to it.  Hence, I did not buy one.  I did not want to buy the book and keep it untouched.

The talk of Rahul in STeP-IN Summit 2025 helped me to see the book.  If I had not listened to this talk of him, I would have said myself -- I'm not yet ready to read this book!

Each book has a preface.  I see, this talk of him is an excellent preface to the book.

• An excellent preface to tell about,
• The book -- The Last Book On Testing,
• GenAI, ChatGPT models,
• Conversation with models, and
• Rahul Verma's experiment in book writing using ChatGPT models and the experiences.

I understand, if one do not listen to this talk, one might not get the author's intent and its pitch voice.  

Is that fair?

• When co-authoring a book together with an assistance of a software technology, it is necessity.
• Why?
• That's how you will see the inner side of the author and what did he do with the technology.  How? Why?

And, for someone who is peeling the layers of GenAI and Transformers in her or his practice,

• The narration of this book will be intriguing.
• Because, it is the reviewed and fine tuned versions of dialogues,
• Between, 
• The probing engineered prompts of the author, and, 
• The responses [to the prompts] from the Transformers and its attention.

I could see the dots now.  I saw, maybe a 1% of what Rahul saw and he is seeing.  

This is enough for me to find other dots and connect for reading the book.  Now, I have the context to read the satire -- The Last Book On Testing.  I'm ready!

I moved to the counter and bought one with a discount.  I wanted to pay for the book, buy, and read it.  That is one of the ways I can show my respect to the book's author.

But, Rahul had said, he will give me one copy of his book.  His humbleness!  Thanks, Rahul. :)

I collected it from him and he signed it for me.  Here, you see it.

Picture: The book that I got from Rahul Verma. :)

This, the one I bought, I got it signed it as well.  I will be gifting to a test engineer who deserves it.  I am yet to find one, now. 

Picture: The book that I bought and got it signed to gift.

In short, this talk of Rahul Verma is an excellent preface to the book and for his experiences of co-authoring together with GenAI technology.  

I wish, this talk's video recording will be published on the social media.

When I get the essence of the book and can consume its perspectives, I will share my experience as a blog post.

Ah! I forgot to say this.  As I listened to Rahul's talk, I got an idea on how to see this book, read this book, and reflect.  I shared the same with him.  And, he did say one of the reader and reviewer did that.

To summarize,

• Thanks STeP-IN and Vinay Baid.
• Gratitude!
• Thanks Rahul, Ramit, Shrini, Vipul
• Thanks to my seniors who gave me their few minutes and a pat.
• Thanks to attendees who gave me their time as I moved between them and conversed.
• Thanks Raveendra Chakrakodi for standing up and speaking your soul.
• I will be travelling distance with the dots I have collected [and collecting] in STeP-IN Summit 2025.
• I got a much needed preface to read the book -- The Last Book On Testing
• One request that I have for STeP-IN is to publish the videos of talks.
• This is a long standing request. :)

I Have a Programming Book in My Software Testing Books List

A Question From Mentee

One of my mentees asked for the books to understand Software and Software Testing better.  She shared the list of books to which she is referring.  She asked,

What other books and resources do you recommend to me for learning and understanding Software Testing?

I want to share my thoughts by talking a bit about boxes of software testing, books, and personas.

Software Testing, Books, and Personas

Read this blog post (Black Box in Every Other Box of Software Testing). It talks about the different boxes in Software Testing.  On reading, do you see a Black Box in every other box?

I classify the books and resources on Software Testing per the below classifications.

Pic: Classification of Books & Resources for Software Testing

I keep the Programming book in Assistive classification.  I have it in my first three books.  How can I test a software system if I do not understand how it is programmed?  Maybe, I can do testing to some extent. But,

• What will I miss if I do not understand how it is programmed?
• What will I miss if I cannot make sense of the code?
• What will I miss if I do not know how to use automation to help my testing?

I consider the different personas to aid my testing.  But, I do not see the programmer persona of writing the code for the system I'm testing.  How to use the Programmer persona to test the system?

What stops me from considering programming as one of the characteristics of a persona?  What can influence and help me to think and include this persona?

I'm not knowing [or ignoring] the first circle of persona (programmer).  But trying to think of different personas to include in my testing strategy.  Is this rational, logical, sensible, and appropriate?

If I practice programming to the extent of reading and understanding the code, I can think of risks to a larger extent.  This is helpful.

If I practice programming skills to the extent where I write automation, I can think of how to automate, how much to automate, and where to automate in that context.  It is helpful.  Isn't it?

If I practice programming skills to the extent where I can discuss confidently with the programmer about the possible risks, it is helpful.  It will also help me to debug and test investigate better.  Isn't it?

This will change how I look at the system and how I test the system with my testing and automation.

Book, Programming, and Language

• In your list of Software Testing books and resources, have a programming book
• Testing software without knowing or understanding programming will always limit us sooner in our Test Coverage, Test Strategy, and Automation Strategy
• It will always limit our understanding of the system we are testing
• It will always limit us in knowing the potential risks and problems inside and outside of the system
• It will limit our perspectives
• For example, 
• When and how the functionality of a feature can be vulnerable?
• When and how to decide how much sampling is enough in a context?
• When you are building a mindset and thought process in programming, pick a programming language to practice the programming
• Start small
• Start simple
• But, start, and then continue

It is always good to derive relative learning and analogy from different practices and study areas.  It helps to register one's learning.  But it should not happen at the cost of avoiding and ignoring the practice of programming by a Software Test Engineer.

Programming is very closer to the software system which we build and test.

Do not get into the thought of whether it is compulsory to be aware of programming for testing software.  This is procrastination probably due to fear.  Face it!  Fight it!

I suggest "Head First Programming" for programming for one who is starting to practice programming.  This book is self-descriptive and communicative.

Start practicing the programming at your own capability; but, do not give up; continue the practice.

Upskilling yourself here will put you on the competence line.

I have a Programming book in my list of Software Testing books and resources.  Do you have 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

Testability: More About it from the Programming Literature

 

My friend Parimala Hariprasad gifted me the book Essential Skills for The Agile Developer, authored by Alan Shalloway, Scott Bain, Ken Pugh, and Amir Kolsky.  Thank you, Parimala, for gifting this book.  I'm experiencing the value of this book and using it.

In this post, I'm sharing the content shared in Chapter 3 of this book. It is about Testability and how it improves the code quality.  

Why this Blog Post?

I continue to read Software Testing literature.  I understand the below as one of the primary key skills for a Software Test Engineer practice:

• Identifying the Testability attribute in the system
• Mapping and classifying how the available Testability attribute can be used in Tests
• Asking for the Testability attribute

With that, I understand "how easy it is to test by a test engineer in a given context" as Testability.  If noticed, this is from Software Testing literature.  And, I see it has these three elements which tell the prominence of each:

• How easy it is to test?
• what factors make it easy to test?
• how does it make it easier?
• how does it bring the deterministic character?
• how can I isolate the observations with my analysis with the help of deterministic character and aid added?
• By a Test Engineer's
• awareness, experience, learning, applying the skills, and more
• In a given context
• time, people, environment, availability, and more

If any of these three elements has trouble, it has its effects on the test and testing.  If you ask what effects, I don't know.  If I pick from my case to share one of the effects, I say, I was not very sure what was happening though the product looked to do what is expected.  But will it continue to do what is expected to do and in what all ways? I had no answer for in what all ways and in what contexts. This is one such case of how the absence or not using the Testability can influence the tester to be unsure about the learning made with help of a test.

The book I mentioned here gives another perspective from the Computer Programming literature.  It talks at the fundamental level and I see this is important to understand for we Test Engineers.  Soon in the coming days, we Test Engineers will be working and testing in these layers of product development. 

In the next section, I will share the lines from the book as is in italics and blue font color word.  The credits are to the authors of this book. I'm taking the text as it is from this book.  And, I will share my interpretation for the same and see the relativity of Computer Programming and Software Testing literature.  

Note: The credit is to James Bach for the Testability definition used above.  I added "the tester and context" to it as these two influence the Testability and outcome of using the Testability to a greater extent.

Testability and Code Quality

The authors of the book say, "testability is highly correlated to the code qualities we want to manifest, in particular, loose coupling, strong cohesion, and no redundancy."  Further, they illustrate how one remarks at the start of testing one's code by saying the below:

I can't test this code; it does too many things that are so interwined -- weak cohesion

I can't test this code without access to dozens of other things -- excessive cohesion

I can't test this code; it's been copied all over the place, and my tests will have to be duplicated over and over again -- redundancy

I can't test this code; there are too many ways for external objects to change its internal state -- lack of encapsulation

Then I read this line from the authors, "Gee, I wish they had thought of how this code was going to be tested while they were writing it!".  That's a question that every one of us has to ask ourselves for the work we deliver and not just for the programming.  

Alan Shalloway says he is kind of slow sometimes because it took him some time to realize this -- I should consider how my code is going to be tested before writing it! 

Testability is related to loose coupling, strong cohesion, no redundancy, and proper encapsulation.  Another way to say this is:

• the tighter your coupling, the weaker your cohesion; 
• the more your redundancy and the weaker your encapsulation, the harder it will be to test your code

Therefore, making your code easier to test will result in the loose coupling, strong cohesion, less redundancy, and better encapsulation.  This leads to a new principle -- Considering how to test your code before you write it is a kind of design.

Since testability results in so many good code qualities and since it is done before you write your code, it is a very highly leveraged action.  That is, a little work goes a long way; it is a great trim tab.

I and Testability

I try to understand and learn about Testability every day in my practice.  When I started my career 15 years back, I learned from my network, that one of our fellow testers in the community that is Meeta Prakash did her Ph.D. in Testability.  I wanted and still want to read the thesis of Meeta Prakash.  I hope she will find it and give me soon, one day.  In those days, I referred to the slides of James Bach on RST; that legacy slides that had contents filled with blue color. 

From there, I tried looking into the testability in what I test and what programmers deliver to me.  When I worked with Moolya in 2012, I realized from my practice -- context and the skill sets of a tester matter to make use of the available testability and to identify if it is present or not, and to what extent. I added this to the definition of James Bach and I shared the same with my fellow testers with whom I was mentoring and working together.

Relating the Literature and Interpretation

When the programming is talking about testability, I see it is talking about:

• internal aspects of how it is programmed and to test the same easily in isolation, and in integration for the context while being deterministic

The words used to express in programming literature are more programming oriented.  Whereas, what we see in the Software Testing literature, it is more of a common man's words.  But, what both means is the same and the difference between them is to which layer and aspect they are referring and how, and why.

The Weak Cohesion

• It will be an obvious experience to a tester when it is difficult to speculate and pull a particular observation with more information for a feature or a user flow
• For example, if the Refresh Token is used along with Auth Token everywhere, then it will be tough to isolate when Refresh Token is used and when the Auth Token is used

I feel the same when wanting to test a piece of code in isolation from other code.  I have experienced this when testing one aspect of utility or a complete utility in isolation from the rest of the automation code.

The Excessive Cohesion

• I could not test the mobile apps as I needed data
• Certain data came from a portal that is also under development and depends on APIs to work
• APIs would be under development till the last day of release and did not deliver the endpoints to the portal and mobile apps team

So how could the test team create data to test for mobile apps, web portal, and for APIs themselves?  If you see this is excessive cohesion at the product development level.

The Redundancy

• In one project, I had to login each time to see the status of a session
• All tests were programmed in a way that I should login each time
• The test team used the login function in every test and it was duplicated
• When signed in, the Auth token got changed which lead to difficulty in debugging and isolating the problem
  

This complicated the test code and also messed up debugging.  The tests could not be deterministic here.

I see a static Auth token or one-time login and using the same Auth token in all other tests in the suite could have helped to debug the problem and where it occurred.

The Lack of Encapsulation

• My team had a tough time when started to use an existing automation
• It had public access modifier for all methods in all packages
• The team picked up and authored more tests that changed the data and states
• This led to any object of a method to modify the data or state; it was not supposed to be modified at all
• The debugging led us here and it was not a problem with the product
• It was the problem with the product's automation code and how the tests changed data and state;  it was in turn used in other tests

This led to much more chaos as the automation and testing environment were the same.  The invalid bugs, meetings that got scheduled to discuss and time went into the meeting that ended with no use, and a couple of releases came into a decision should we deploy or not, and more.

Continuing the Unlearning and Learning of Testability

If you see, Testability has got multi-dimensions in the dynamics of software development.  Testability is not just about Programming and Testing.  It can be from the environment, project, people, what we understand and how we use it further in work, and the business itself.

I continue to unlearn and learn testability every day as I practice testing and automation.