Author: Enrique Decoss

Some consultant companies will not eliminate all the risks by offering an automagic solution (Perhaps a revolutionary testing tool). However, it could give better possibilities for applications to be evaluated in case of quality gaps and deliver accurate applications for the consumers.

We see products/services failing before any launch or retiring a couple of months later. Companies often admit to underestimating market competition, using the wrong business model, lacking Quality, or having no product-market fit. These failures leave room for analysis while involving QA expertise often increases the chances of being competitive and delivering higher-quality applications.

A Brief About Customer Centricity

Before answering, what is customer centricity? We must emphasize a critical point: the customer centricity approach’s ultimate aim is the same as the product-centric model’s. It is to make the company as profitable as possible in the long run. In simple words, the end goal is to make money; now, let’s provide a basic definition of customer centricity:

“Customer centricity is a strategy that aligns a company’s development and delivery of its product and services with the current and future of a select set of customers to maximize their long-term financial value to the firm.”

Why Customer Centricity is Important?

Customer-centricity puts customer satisfaction at the heart of the projects to ensure all project customers believe the scrum team is delivering quality services. As a result, every customer will continually rate our services as Good, Very Good, or Excellent.

Customer Centric Model in Testing

Some questions need answering if we want to accomplish customer centric Testing:

How professional is our Testing operation?
Are we good enough to deliver high-quality applications/services?
What does the Quality look like for our customers?

Let’s start with basics, creating value; traditional Testing methods do not guarantee value; projects will deliver according to the agreed corporate standards and within defined tolerances.

When we mention “Traditional Testing,” we are talking about the “Testing done right,” which is more related to some projects within the triple constraint: on time, on budget, and meeting quality standards. However, there is a missing piece with traditional Testing, the final users who receive the application/service probably want to do something useful.

The Agile Teams must understand the customers; more specifically, the Product Owners must share the vision of the product and the outcome with the final users (Are we good enough to deliver high-quality applications/services?). Therefore, customer centric Testing captures not only acceptance criteria, but we also should align the acceptance criteria and the goals of our applications/services with the needs of the most influential people, in this case, our customers.

We should maintain an open channel with our Product Owners and evaluate multiple scenarios (What does the Quality look like for our customers?); keep in mind what is delivered is fit for purpose and meets the customer’s expectations. As Agile Teams, we should change and adapt. If our customers’ expectations change, we should adjust our user centric testing scenarios (How professional is our Testing operation?).

Test Automation Values the Real Worth of Our Customers

Test Automation can help us speed up our Testing activities; we must understand the cost of automating, the project’s time constraints, and available resources. Also, keep in mind other testing options (Exploratory Testing, Mob Testing, Pair Testing), and most importantly, don’t automate tasks that will not have to be repeated.

“Test Automation without covering customer scenarios may result in a lot of activity but little value for our customers.”

Our Test Automation strategy should emphasize the customers and perhaps more related to covering customer scenarios. Of course, the strategy can also improve our team’s daily workflow, but it shouldn’t be the focal point of your planning. Instead, prioritize your Testing on making the product better for the customer. It would be best to centralize your Test automation efforts on valuable test scenarios.

Now, let’s focus on Test Automation’s customer centric strategy; for those already familiar with BDD (Behavior-Driven Development), BDD tests are customer-facing scenarios that attempt to describe the behavior of a Story or a Feature from a user’s perspective. The incredible thing about automated BDD tests is that the applications continuously meet the specified behavior, whether we need to introduce some changes or the applications evolve.

Another excellent option for Test Automation’s customer centric strategy is Natural Language Processing (NLP), a field of Artificial Intelligence (AI) that makes human language intelligible to machines. NLP combines the power of linguistics and computer science to study the rules and structure of language and create intelligent systems (run on machine learning and NLP algorithms) capable of understanding, analyzing, and extracting meaning from text and apply to specific tasks like test automation scripts.

NLP engine addition to our Test automation can make it much easier to create test cases and modify each in the future in an intuitively accessible format for anyone in our projects to understand and execute.

Introducing new approaches to the Agile teams could be challenging; some team members will support the change, others will not, and others may resist. Unfortunately, we have the false perspective that the decision-makers must introduce the changes to the teams. Believe me when I say the changes come from many places (How Gmail happened).

If we want a fundamental change, key players must be enrolled in the discussion and debates. The last point is that companies must align their business objectives to their test automation strategy; we must ensure the delivery of high-quality applications that meet company business goals.

Final Thoughts

Test Automation strategies focusing on writing thousands of test scripts and only relying on QA for a posteriori validation overwhelm your projects from the beginning. Instead, we should avoid these by ensuring that your Test Automation provides real value to our customers, balancing the test automation efforts, and ensuring That everyone in the company has quality efforts.

“The essence of a good Test Automation strategy is to impact our project landscape positively, making everyone part of the strategy.” – Enrique A De Coss

A successful Test automation strategy must adapt to our current customer needs and team capacity. Consequently, we must avoid generic approaches and make sure we apply a robust automated test strategy that will help your existing team and your customers. So, first, consider our current situation and where the company or project is heading. After that, we must use the right parts that we believe will best deliver high-quality applications that meet company business goals.

Lastly, apart from following Customer Centric Test Automation Approach, you should also be aware of Automation Tools for Software Testing as it helps you to test anything with more ease.

At this moment, there’s no doubt that automation testing is the fastest and most cost-effective way of delivering high-quality applications in a short time. However, it cannot do everything since some limits of test automation are built into the system and must be in balance with exploratory testing. At the same time, some result from fuzzy pre-programming logic, such as a failure to develop effective test automation scripts.

Imagine a world with these flaws; is it worthy? Last decade and a part of this one, Selenium has been the tool most used for automation testing (with many companies strictly using Selenium automation testing tools as the only option). Currently, we have a bunch of latest software automation testing tools . However, we continue to use the same mindset used 20 more years ago.

We have seen some improvements in DevOps, TestOps, and Spotify models, but we need to keep working; in this blog post, we will explore some of those challenges and successes.

Automation Testing is Rocket Science

As Ozan Varol proposed in his book, thinking like a rocket scientist is to look at the world through a different lens. Rocket scientists infer the unimaginable and solve the unsolvable. They transform failures into triumphs and constraints into advantages; like modern QA, we are not here to break the software; we must work together to reveal the flaws and deliver high-quality applications.

Automation Testing as the primary goal is not short-term results but long-term ones. We know that the rules aren’t set in stone, the default can be altered, and a new path can be forged. If you are looking for short-term results in test Automation, you are not solving the puzzle in your company; you are just adding extra complexity to your current chaos.

Let’s learn from the past in terms of automation testing, pick your calibration targets carefully, and make sure you can trust their judgment. If their determination is off, yours will be too. Unfortunately, it happens more often than you imagine. Our goal should be to find what adds value to our customers (Customer scenarios, API automation, Performance) instead of just looking for regression tests all green.

Automation Testing Tools Limitations

Many test automation tools focus on locating defects in our systems as soon as possible and reducing the cost of finding those bugs in Production. The premise sounds accurate; we believe there are defects in our system; despite the development team’s efforts, various automation testing tools help us to write automation tests to find the bugs hidden in our system.

Unable to Test All (100% Test Automation is NOT testing All)

Automated tests are merely coded scripts; like all code, they can contain bugs and mistakes. So imagine those companies following practices like 99.99% of our flows are automated or, even worst, looking for that. Anything tool mentioning 99.99% – 100% of something could be easily questionable (100% availability, 100% free of bugs, 100% test coverage, etc.) 

Consider multiple scenarios or different flows requiring context; now, imagine those engineers transforming the test cases without the minimal context of the flows; some automation tools encourage anyone to create a test script for automation testing. Let’s picture the other scenario, fewer QAs or Developers, and one person is coding, testing, creating automation testing (happy paths), performance testing, and encouraging good automation coverage; it sounds oniric.

Failing with Test Coverage

Many companies often depend on metrics like code coverage & test coverage to proactively encourage testing and maintain a certain standard across teams. Code coverage tools work by parsing code into decision trees, then running through it alongside the test code (Unit testing or Component Testing) and generating a numerical rating based on how much the decision tree was visited during the test. 

We end up with some percentage, like 78.98%; that looks tempting to put in fancy reports or cool slides. What does it mean? How do we know if test coverage is enough? Is 80% too low? What about 90%? Or 100%? Does it depend on the project? Or the company? And what about the quality of the test scripts? Is it possible we’re visiting all logical combinations in the code but checking something trivial or unimportant flows for our customers?

Some automation testing tools in software testing can help us to automate boring or trivial flows. Still, sometimes they prevent us from seeing the forest for the trees (Customer scenarios or other critical flows).

Expensive Experimentation

Time is a zero-sum game. Every hour we spend writing test scripts is an hour we could have been writing product feature code. And vice versa; if we slow down our progress on churning out new features, we have more time for writing test scripts. The same when selecting an Automation Testing tool or switching from one to another; some companies or startups can’t perform multiple PoCs or learn from failure over and over.

Keep in mind that QA departments compete for limited resources and time. So we must ensure we’re investing correctly and with the right tool. Last but not least, automation testing is not “automagic” once we select the automation testing tool, it takes considerable time to implement the proper automation process; again, if you automate chaos, you will get automated chaos.

Automation Testing Tools Success

Before considering the Automation tool a success, we must evaluate the test automation process and look at the bigger picture. Specifically, it would help if you outlined the kinds of questions you’re trying to answer regarding:

• How quickly can we deploy to Production?

Accelerating releases is a fundamental goal, especially in digital transformation. Comparing pre-automation release cycles with current ones can give you an idea of how automation affects timelines, and the selected top automation testing tools can help us with this. 

• Are we improving software quality? 

Something an engineer or developer sees as brilliant may not be as enthusiastically accepted by end users. You’ll have to solicit bug reports, surveys, and other feedback to get the users’ perspectives and include them in our Automation test scripts.

• What are our automation costs, and how do they evolve? 

The expense will increase during the initial automation project. The payoff is that long-term cost should drop if we have a clear strategy for our Automation Testing process. 

• What is the automation value for this project? 

A crucial part of automation is comparing the expense of the automation project and tool implementation to the savings it creates. After all, if automation isn’t providing any value, what’s its purpose? 

Assigning a numerical value to each of these means you can connect them to the smaller metrics that make them possible. You won’t just have results, you will understand the specific path you took to get there, and then we can clarify the success of our Automation project and tool.

Wrapping Up

Some automation solutions are excellent for amplifying human intelligence and ingenuity. Automated tests, for example, save us the trouble of some testing aspects of our product. Thank goodness we don’t live in that old world without them.

If we explore only well-trodden paths or if we avoid games we don’t know how to play, we’ll remain stagnant. Progress can begin when you’re dancing in the dark, only when you don’t know where the light switch is or even what a light switch is.

But we need those intelligent, thoughtful, and conscientious engineers at our side to look for problems in our work and to challenge us to perfect our designs gently. Indeed, this is often the easiest way to catch severe system defects. Automated testing should always be a complement to our collaboration with colleagues, not a replacement for it.

Happy Bug Hunting!