In the tech sector, we have heard and occasionally still hear these phrases: “Testing will soon be extinct!”, “Testing can be automated”, or “Who even needs testers?”. But don’t sweat, the testing craft has a promising future as long as the software is available on our planet. But what will testing look like in the future?

To seek the answer, the LambdaTest team took a seat for a video chat on the grounds of the Testμ conference with Mayank Bhola, Co-Founder, Head of Product, LambdaTest, Priyanka Halder, Director Quality Engineering, Oscar Health, Vikul Gupta, Executive Vice President, QualiTest, and Larry Goddard, Quality Assurance Engineering, Oxford University Press.

If you missed the session, here is the video link for you!

“Instead of assuring quality, the quality has to be engineered”. — Vikul Gupta

Vikul Gupta strongly believes that Quality Engineering has significantly transformed over the past 5 to 7 years. He heard that, until development dies, testing exists. As the world moves toward DevOps and Agile, most software companies stated that they don’t want to eliminate Quality Engineering. Instead, the process of quality check needs to be transformed. When the requirements are popping in, QA Engineering validates the requirement and checks the ambiguity of the user stories. 33% of the defects in QA cycles are attributed to ambiguous and incomplete requirements if the QA team fails to validate the requirements.

“My Passion is to avoid defects,” says Vikul.

Priyanka added a different perspective here. According to her experience, when she started her career, there was a separate testing team where the requirement was validated, and the testing was done post-development within the scheduled time. There was a separate bubble team for finding bugs. As years passed, lots of sophisticated automation processes arose. This is where Quality Engineering has shifted.

“We no longer have different teams and are adopting an Agile methodology,” said Priyanka.

Today, when she establishes the Quality Engineering team in automation practices, she always preaches and figures out what the user journey looks like.

By figuring out the users’ browsers and functionality, you can assure that you already own the game with automation and cloud technology!

“Do Quality Engineering with the Strategy to get the maximum ROI” — Priyanka.

Mayank threw a question to the panel members. “Do you guys think that the practices available in the testing world are behind in terms of the pace at which the software development is moving”? Given that, is the code engine and the work we do is the same? Do you guys still feel there is some parity at this stage?

Larry jumped in to answer this question. He states that he thinks there are lots of tools for automation testing out in the market, and they vanish over time. It is all about getting the right balance in choosing the tool. As he travels five years back, it is all about Protractor and Mocha frameworks. “These two are at the top of my head,” he says. We all have used tools that get lots of attraction in the market. But it is important to analyze the context of the tool used for your product. But the tool does not stay longer in the market. “When I am using a tool that gets outdated, the market starts using an updated tool, so I need to jump in and start using it. Provided, the functionality must be the same.”, he added.

So it is we testers need to pay attention to the tool selection that would match the testing requirements.

Vikul Gupta waves in to add a few other points. “Tools have come a long way,” he says.
The companies are looking for smart solutions for specific problems. They try to mix & match. It is not only the 3rd party, paid, and commercial tools; the open-source has evolved a lot. According to Vikul, there are three key aspects irrespective of tools.

Tools rely on:

• INTEGRATION as a key.

• INTELLIGENCE as a key.

• INCLUSIVE as a key.

He also says that AI & ML is getting almost in every field of Computer Science, and testing will never stay ahead.

Mayank was interested to know if AI and ML have reduced the effort to ensure quality in any case. He questioned Vikul, “Do you feel AI & ML are providing the high value, making up for the height?

Vikul answered, “It depends on what use cases you pick”. He says that he has been highly successful in using AI in test optimization. Most people use Risk-based testing to optimize a test case, which the SMEs usually decide.

Even in risk-based optimization, there is 20 to 30% of optimization. According to his experience, there were only four days to run 1000s of test cases. Back are those days when it took 2 to 6 months for releases. But we have daily, and weekly releases happening. This is where AI would help. Data is the most important concept in AI. If the data is scraped, then the complete AI is scraped.

Priyanka seconds Vikul. She added, “You have to find the initial use case where you would be applying it”. She demonstrates it with a quick example.

In one of her organizations, which was content-heavy, she saw too much ROI on visual validation. It makes total sense to take snapshots visually, and through AI assures the correctness of various viewpoints.

Performing it with Selenium, Playwright, or Cypress would have assured each element is visible, and at the same time, you need to doubt the element’s visibility. Today, many tools give leverage to the people who are good at testing and the niche in finding various use cases, which we don’t see in a normal programmer.

But, at the same time, these tools empower people to utilize low-code systems and add automation to make them more efficient. So she still believes that finding a great exploratory tester and an SDET together is rare. Today, there are many platforms where you can utilize AI-enabled tools, which also empower great testers in the organization’s space.

Larry wanted to throw some points above Priyanka. “AI is good. It is all about the context. But there is still one fundamental thing about AI. A lot of people don’t look up the dataset. Here, we have a tool that takes time to collect all the data to choose the right ROI.”

Mayank thinks that there is a missing insight. People treat both codeless and low-code platforms as a single source of truth. The problem is using the incorrect tool for the right problem statement. It is more about getting to know ‘how’ and ‘when’ to use it. To test at scale, everybody jumps into automation. “Tools are making life easier with automation,” says Mayank.

Priyanka adds a different perspective again on low-code. “I have seen some smartest development teams using them as they don’t want to navigate the complexity of standing a framework and maintaining it. Every tool is a choice depending on where the team is and the availability of the team. Some companies don’t want to start an automation framework. Because that is extra work, they don’t have a team. There should always be a long-term strategy where you are utilizing a better, solid platform like Cypress, Playwright, and Selenium.”

It was indeed an insightful session with Larry, Priyanka, Vikul, and Mayank. The session ended with a few questions asked by the attendees to the panel. Here is the Q&A:

• Why so much emphasis on tools?

Larry: The core point about being a tester is what you bring to the table. How will you help me interact with the product? You need to look at the basics. You need to look at the product from the user’s point of view.

A good tester is distinguished as someone who can look at the product in hand. A good tester would enhance the user experience by showing curiosity and interest in the product’s functionality.

• What advice would you give the tester?

Vikul: Start feeling proud of what you are doing. You are not just the tester. You fix problems that developers don’t even realize they are having. Stop calling yourself a tester — You are a quality engineer.

You can be a musician but knowing the instrument is a must. Similarly, as a tester, you need to see the tool you are working on. It doesn’t matter which tool you use, but you need to know it well.

Larry: QA doesn’t have to prove usefulness in the team. He emphasizes how important it is for QAs to help the upper management realize that QA is not a pastime but part of the development process.

Priyanka has a strong opinion that previously, it was about breaking the code and finding as many bugs as possible, but now we are shifting to a genre where QSs are essential to take the product to the next level. A lot of emphasis on quality.

• Is there a difference between QA and QE?

Vikul: The world of QA is about executing test cases and assuring test cases. You need to understand programming language, design concepts, and the SDLC process to understand what a good requirement is, what’s a good design pattern, how to read the output of a code quality tool, and what code complexity means. You need to understand those aspects to help identify quality issues much earlier in the life cycle without writing a single test case or executive interest. This would be a high-level difference between QA and QE.

To the closing notes, Priyanka, Larry, and Vikul added final points to predict the future of testing.

Priyanka: The future of testing is bright as it has a lot of new concepts and new tools. I encourage everybody to choose what is best for their particular use case and adopt it.

Vikul: It is very exciting because if you look at development, many changes happen with the development language and analytics. If we look at QA for the last four or five years, the transformation has happened, and we started thinking about what the next-gen aspect would be.

Larry: It is really bright because we have a lot of stuff on the market, and we have a lot of new people coming in as well. One main thing I want to see is people like myself, Gupta, and Priyanka sharing the better knowledge that we already have with our little ones in the upcoming generation.

That was the icing on the cake!