Testing is Contextual—No Best Practices, Please

Hi !!

Are you following testing best practices??

Be cautious.?

Best practices aren't always the “best”.They are not the golden rules you might think they are.?

They’re highly dependent on context.

What works wonderfully in a situation might backfire in another.?

I will explain this concept unpacking why context is important in testingPut.And how you can approach to face the challenges.

It will be in 2 parts.

1st part is here for you !

Why There’s No Universal “Best Practice”

“Best practice” implies that it is a silver bullet.

It also suggests that there’s a universally optimal way to approach testing. And that can be applied to any situation.?

But it is not !

Software development and testing are complex activities. They are influenced by various factors. Those factors can be project requirements, team dynamics, stakeholder expectations and technology stacks.?

The same practice can yield different results depending on these factors.

Consider the example of agile methodologies.?

Agile practices, such as continuous integration and continuous testing, are widely regarded as best practices.?

Yet, these practices may not always be suitable for you.?

In a small startup environment with limited resources, implementing a full-fledged CI/CD pipeline might not be feasible due to cost or time constraints.?

This can be different in large enterprises.

They might have? multiple teams working on the same product, CI/CD is almost a necessity to ensure smooth collaboration and rapid delivery.

An Example from My Experience

Here’s an experience from my career that illustrates it.

I was working on a project.

In this project, my team was responsible for testing a specific story. The intended functionality of the story was working as expected.

So I closed it.?

Bugs I found during testing were reported and linked to the story, which seemed like a logical and effective approach.?

This process worked well in that project.

And I concluded it as a “best practice.”

Obviously. Right?

Now I started working on a new project.

In that different project, I applied the same approach and quickly ran into trouble. The project manager escalated the issue.

Reason was alarming to me.

He argued that the story should not be closed if there were any bugs related to it.Even if the primary functionality was working fine.?

He was correct.

The reason was that closing a story could signal to developers that the feature was complete.And is ready for production.

This could have potentially led to bugs being overlooked or deprioritized.

This experience taught me a lesson.

What I considered a best practice in one context was not applicable in another. The project’s specific needs, stakeholder expectations and the way success was measured all contributed to my failed approach.

Rest of this article will be in 2nd part.

See you soon !!

-Jayateerth Katti