AutomationSTAR

Test Automation Conference Europe

test automation

The Skills I Learned and the Ones That Got Away

Ahead of her AutomationSTAR Deep Dive, Close Encounters with Systems, Rachel Kibler reflects on the skills that shaped her testing career—and how systems thinking gave her a name for what she was already doing.

I started my career by diving headfirst into the context-driven testing community, forming some very strong opinions along the way. I look back at my dogmatism and wonder why I was so convinced that I, a baby tester, was right just because I was parroting something persuasive that resonated with me.

I found my way to conferences, which broadened my horizons and showed me that yes, everyone thinks in terms of context, and the arguments that we have within our testing community can be tiresome, worn-out, and ultimately unhelpful, even harmful when they gatekeep and manufacture heightened emotions around who’s doing testing “the right way”.

Ten years in, I hold a lot of my strong beliefs still, but considerably more loosely, and I’ve become much more understanding of everyone’s journey. Turns out, not everyone needs to do things the way I do them!

In addition to my attitude shift, I found that the skills I learned early on formed a lot of what I care about and still think about. And that these skills that I value turned out to be systems thinking before I had the words for it. Elisabeth Hendrickson’s book, Explore It!, was massively influential in learning how to create test charters and organize my mental models, as was Janet Gregory and Lisa Crispin’s Agile Testing in thinking strategically about how to deliver quickly and not be a bottleneck.

James Whittaker’s How to Break Software was one of the earliest I read, and though he does spend a lot of time on printer testing, the idea of creativity in your testing by shaking up the machine (sometimes literally) was helpful. And doing the Black Box Software Testing foundations course by Cem Kaner and Rebecca Fiedler through the Association for Software Testing played a huge role in shaping my skills too.

Because of those influences, I learned to think about software in creative ways, to not trust what someone says the software does and does not do, and to spend time following my gut instincts about where things could be broken, largely at the boundaries of the software and the boundaries of our understanding of the software.

I learned how to communicate well with my developers and at the right time. I learned how to advocate for my bugs, and hopefully for the user. I learned how to identify risk and to bring people together for conversations about what matters and what quality is for our products, creating feedback loops and shared mental models. These skills felt good to me, they felt right, and they enabled a solid career with good delivery of software.

Some testing skills eluded me though. Writing extensive documentation has never been my strong suit, and though I do strongly believe that test management systems are a kindness and should be a system of record for our software, writing steps down in depth has always felt daunting and overwhelming to start with. But documentation does make our system legible to others, modeling what we understand to be true. I also never really got a handle on what my automation should look like when it’s at its best, when it’s giving the feedback on the system in the right place.

AI changed the game for me, enabling me to pay more attention to the “what” and the “why” of automation rather than the “how” that had been so much of the concern of past me. However, thinking about documentation and automation in terms of systems may be the thing that drives both of these forward for me.

For AutomationSTAR in Antwerp this November, I get to do a deep dive into systems thinking itself. I’ll give a brief overview of the concepts in systems thinking before we dive deeper into time delays and other less intuitive things, pulling heavily from the new work of Elisabeth Hendrickson and Joel Tosi (their book, Signals & Levers, releases on September 22nd, 2026) as well as the work of Donella Meadows (Thinking in Systems: A Primer) and many others. Learning from Elisabeth Hendrickson’s book at the beginning of my testing career and now from her new book with Joel Tosi seems fitting.

I didn’t invent any of this, it’s been around for a long time, but it’s more relevant than ever right now. Systems are becoming more and more complicated as we throw AI into the mix for both the software itself and the processes around it. Feedback loops are getting longer and stranger, and the levers to pull are moving. Testers talk about systems in daily work, but perhaps without the structured framework to make the conversation’s importance clear. Systems thinking gave me language for the things I learned to do by instinct or by mimicry, and I’m excited to pass that on so you can talk about the things you already do and care about in terms of systems.

Rachel Kibler is speaking at AutomationSTAR – check out her Deep Dive and book your tickets.

We analysed every AutomationSTAR 2026 submission. Here’s what test automation will look like in 3 years

This year’s Conference theme of “Future Skills” is not just a theme – it is being echoed by the data we are receiving for the Call for Speakers on the roles of the future and the skills that will define them.

Curious about how your job will look like in 3 years?

Instead of reading job advertisements from the past – our speakers are tackling the problems they face today with the tools they use and are frantically searching for the necessary skills to keep their job.

The AutomationSTAR Call for Speakers this year is even more valuable for those who work in test automation and quality in general. This year’s Programme Committee analysed all the submissions for the opportunity to speak at this event, and the result of such analysis paints a picture of what working in test automation will look like in 3 years from now.

If you work in quality this is THE event you MUST attend in 2026. Here is why.

book tickets

The topic map has been redrawn

Three years ago, our topic categories were organised around technologies: web, API, mobile, performance. Look at where submissions landed this year.

Of the submissions we received 35% fell into what we’re calling ‘AI-native’ categories of work such as ‘vibe testing’, ‘agentic AI’ and Gen AI-augmented automation. These categories have naturally evolved in the community and were not created by us for marketing purposes and have since taken off.

Meanwhile the category of Automation Strategy & Architecture retained its position as one of the most popular at 20%. Given the rapid evolution of the tools available for automation this category will continue to be relevant as someone needs to ensure that the automation is working effectively.

Code Craft & Maintainability scored the lowest with 2% of all submitted topics. As we were really excited to start to dive into the many questions and topics how to build something new in the first place, the community is clearly more interested in just building something new instead of taking care of something that has already been built. This is a gap one should be aware of.

The AI wave, measured

“AI is everywhere” is easy to say. Here’s what it looks like in numbers.

About two-thirds of the abstracts in all areas (design of tests, leadership, etc.) referred to AI, LLMs or agents. Autonomous and agentic AI was mentioned in 22% of the abstracts. On average, the abstracts focusing on AI, LLMs or agents received higher ratings from the committees than the abstracts that did not focus on these topics.

Additional to the former findings, the analysis furthermore detected a meta-trend within the abstracts under review: roughly 70–80% of the abstracts were written with the support of an LLM.

As before, however, when every single abstract was written to perfection using an LLM, the only remaining difference would be the authors’ experience. And this is exactly what the reviewers are trying to find – in line with this year’s review theme.

The vocabulary shift

Perhaps the clearest signal of all: count which words the community reaches for.

“Agents” and “agentic” were mentioned 40 times. The Model Context Protocol (MCP), for model deployment that was not yet established two years ago, was even mentioned more often than Selenium, Cypress and Appium together. Playwright, the heavyweight automation tool, was even mentioned as often as MCP.

The graph does not mean to suggest that all people have stopped using Selenium and Cypress for running their thousands of test pipelines. Rather, the focus of the test automation discussion has shifted from which test automation framework to use (Selenium, Cypress, Appium, etc.) to how to control, direct, put bounds to, and trust an autonomous test system.

Be in the room for all the important conversations at AutomationSTAR 2026 – book your tickets now.

Future Skills: the theme that chose itself

When we set “Future Skills” as this year’s theme, we wondered if the community would engage with it. They did — but not in the way a skills-matrix would predict.

The word that humans keep using in this year’s abstracts is: trust. It appears in 21% of the abstracts. This word is used to discuss the trustworthiness of AI, of different types of of fully autonomous agents, of teams of agents, and of the systems under test by the authors. Also discussed are collaboration, communication, leadership, and judging.

Interesting the term “test management” didn’t make the cut as a keyword in any of the abstracts. What was once a foundational term for a whole conference track a decade ago is now gone from practitioners’ vocabulary and has been replaced with terms that speak to trust, human judgment, and human / AI collaboration.

So here’s the nutshell summary of Future Skills: The mechanical parts of our work are getting covered by automated tools and thus will cease to be our area of work in the future.

What will remain with us, is what makes us human. That is: knowing when the green of your dashboard is only painting it green and thus might be lying to you.

Deciding how much autonomy to give to which kind of autonomous agent. Explaining risks to people who have to make decisions on the basis of that risk.

Fresh stories, seasoned voices

One more finding we loved.

72% of proposed talks will be new to AutomationSTAR 2026. 58% of submitters are experienced conference speakers, yet they are rewriting their stories as the automation field is changing very quickly.

The audience-level mix for the proposed talks is 58% intermediate, 33% introductory, 9% advanced. The field of automation is being reinvented fast, and so there is a point at which everyone is a beginner for that section of the discipline. Hence the community will be presenting talks for this audience.

From everywhere, to Antwerp

We received submissions from 35 countries around the world with 2/3 of the submissions coming from all over Europe. The country with the most submissions was India followed by submissions from the Americas, the Middle East and Asia-Pacific. The community is asking the same questions in Bangalore, Berlin and Brussels.

What this means for your career

The 2026 program is essentially a translation of everything we have stated: the agentic frontier, the strategy and architecture backbone of the program, actual use cases as opposed to vendor pitches, and a thread of human skills of judgment, trust and communication that no model can ever automate.

Data confirms that our profession will not be replaced by machines. Instead, we will be redefining the work of the next generation of information workers, directing autonomous systems, architecting quality strategy that leverages off these systems, and bringing trust, judgment to the work that machines cannot.

We can get a grip on this work quickly by understanding the work of our peers around the submissions for the 2026 program have been written by the very people redefining our work, our students work, and the work of our clients – two fast-paced days in a room with them is likely to get you and your work ahead quickly – join us in Antwerp in November.

Join us at AutomationSTAR 2026, Antwerp, 4–5 November.

Book tickets

Eight recipes to get your testing to the next level

You’re doing well in testing. Your systems and business processes are well covered. Test automation is on track. Your reports are nice, shiny, and green. All is good.

But then you go for a beer with your colleagues.

You discuss your daily work. And, at least in Vienna (Austria), it is traditional (and not uncommon) to open up with friends, share your workday, and even complain in such a setting. You realize there’s still lots to do.

Every morning, failed test cases need to be analyzed and filtered. Some flaky tests are keeping the team busy – they are important tests, but they refuse to stabilize. Changes in product and interfaces are breaking your tests, thus requiring maintenance. The team must refactor and weed out redundant tests and code multiple times.

In short, it seems there is a lot of work to be done.

This article will guide you through some test automation pain points that will likely sound familiar. But every problem also has a solution. Along with the pain points, we’ll also highlight possible approaches to alleviate them. For most of these issues, Nagarro has also developed mature solutions (see our “AI4T“) – but that is not what this article is about.

What’s cooking? 

Innovation is like cooking – it is about listening to feedback and striving to improve by not being afraid to experiment and bravely trying out new things.

We’ve prepared this dish many times – so you need not start from scratch! And to top it off, we’ll even provide a basic recipe to get you started.

== First Recipe ==

From “Oh no – all these fails, every single day…” to “We can focus on root causes!”

You come into work (be it remotely or in the office). You’re on “nightly run duty.” Some tests in your portfolio have failed.

Step 1: You sit down and start sifting through. After about two hours, you identify seven different root causes and start working on them.

Step 2: Fixing test scripts, fixing environment configurations and logging actual issues.

Wouldn’t it be nice to skip step 1? Let’s say you have 3000 automated system test cases. And about 4% of them fail. That means 120 failed tests to analyze. Each and every day. That’s a lot of work.

But you do have a lot of historical data! Your automated tests and the systems you’re testing produce log files. You need to analyze the root cause – so if you capture it somewhere, you have a “label” to attach to each failed test case.

And that is precisely what you can use to train a Machine Learning algorithm.

So from now on, in the morning, you get a failed test result and a presumed root cause associated with it. This enables you to look in the right places, assign it to a specific team member with special skills, and skip all tests with the same root cause you just fixed. What an effective and efficient, wonderful and mouth-watering prospect, isn’t it?

== Second Recipe ==

From “Why do they keep changing things?” to “Our automation has an immune system.”

Systems change in an agile world (and even in a “classical” world). A lot. Both on the User Interface side and on the backend. The bulk of a test automation engineer’s time is spent on maintaining tests or changing them along with the product they test.

Now imagine, wouldn‘t it be great if your automation framework could, when some interaction with the system under test fails, check if it is likely an intended change and automatically fix the test?

Let’s say your “OK” button is now called “Confirm”. A human would likely take this change, maybe make a note of it but largely ignore it. It’s most likely they would not fail the test case. But guess what, your test automation might stumble here. And that means:

  • Analyzing the failed test case
  • Validating the change manually (logging in, navigating there etc.)
  • Looking for the respective automation identifiers
  • Changing them to the new values
  • Committing those changes
  • Re-running the test

All this can easily consume about 15 minutes. Just for a trivial change of word-substitution. We do want to know about it, but we don’t want to stop the tests. Imagine if this change is in a key position of your test suite – it could potentially block hundreds of tests from executing!

Now if your framework has some way of, instead of failing, noticing that “OK” and “Confirm” are synonyms, and validate some other technical circumstances to be confident that “Confirm” is the same button as “OK” used to be, it can continue the test.

It can even update the identifier automatically if it is very confident. Of course, it still notifies the engineer of this change, but it is easy for the engineer to take one quick look at the changes and decide whether or not they are “safe”.

== Third Recipe ==

From “AI in testing? That means huge amounts of data, right?” to “We already have all the data we need.”

Machine Learning requires thousands of data points, right? Maybe, even millions?

Yes and no. Let’s take our example from the first delicacy – finding out the root causes for failed test cases based on log files. Since log files are fairly well-structured and deterministic, they are “easy” to learn for an ML algorithm – the usual complexities of human speech are substantially reduced here. This means we can use ML algorithms that are on the simpler side. It also means that we don’t need as much data as we would need for many other use-cases.

Instead of tens of thousands of failed test cases labeled with the root causes, we can get to an excellent starting point with just about 200 cases. We need to ensure they cover most of the root causes we want to target, but it is much less work than you would have expected.

Add to that the fact that test automation already produces a lot of data (execution reports, log files for the automated tests, log files for the systems under test, infrastructure logs, and much more) – which means that you’re already looking at a huge data pool. And we‘ve not even touched production logs as yet.

One can gain many crucial insights through all this data. It is often untapped potential. So take a look at the pain points, take a look at the data you have, and be creative! There is a hidden treasure amidst the ocean of information out there.

== Fourth Recipe ==

From “Synthetic data is too much work, and production data is unpredictable and a legal problem” to “We know and use the patterns in our production data.”

Many companies struggle with test data. On the one hand, synthetic test data is either generated in bulk, making it rather “bland,” or it is manually constructed with a lot of thought and work behind it.

On the other hand, production data can be a headache – it is not only a legal thing (true anonymization is not an easy task) but also something about which you don’t really know what’s in there.

So how about, instead of anonymizing your test data, you use it to replicate entirely synthetic data sets that share the same properties as your production data while adding constellations to cover additional combinations?

Ideally, this is an “explainable AI” in the sense that it learns data types, structures, and patterns in the data from production. But instead of “blindly” generating new data from that, it provides a human-readable rule model of that data. This model can be used to generate as much test data as you need – completely synthetic but sharing all the relevant properties, distributions, and relations with your production data. The model can also be refined to ensure that it suits the test targets, even more, learned rules can be fixed, unnecessary rules can be removed, and new rules can be added.

Now you can generate useful data to your heart’s content!

== Fifth Recipe ==

From “What is our automated test suite doing, actually?” to “I can view our portfolio’s structure at a single glance.”

Test coverage on higher test levels is always a headache. Code coverage often does not tell you anything useful at that level. Traceability to requirements and user stories is nice, but they also don’t really give you a good overview of what the whole portfolio is actually doing.

To get this overview, you have to not only dig through your folder structure but also read loads of text files, be they code or other formats, such as Gherkin.

But wait, there’s a catch here – Each test case, in a keyword-driven or behavior-driven test automation context, consists of reusable test steps at some level, representing an action. It could be a page-object-model-based system, or it could attach to APIs – either way, if our automation is well-structured with some abstraction on its business-relevant actions, the test cases will pretty much consist of a series of those actions, with validations added into that mix.

Now, let’s look at test cases as a “path” through your system, with each action being a step or “node” along the way. If we overlap these paths on all your test cases, we can quickly see the emergence of a graph. This is the “shape” of your test automation portfolio! Just one brief look gives you an idea of what it is doing.

Now we can add more info to it: Which steps have failed in the last execution (problematic color nodes as red)? How many times is a certain action performed during a test run (use a larger font for often-executed test steps)?

These graphs quickly become quite large. But humans are surprisingly and incredibly good at interpreting graphs like this. This now enables you to get a very quick overview and find redundancies, gaps, and other useful insights.

== Sixth Recipe ==

From “We run everything, every single time. Better safe than sorry” to “We pick the right tests, for every change, every time.”

Large automated test portfolios can run for hours, if not for days. Parallelization and optimization can get you very far. But sometimes, resources are limited – be it in systems, data, or even hardware. Running all tests every single time becomes very hard, if not impossible. So you build a reduced set of regression tests or even a smoke-test set for quick results.

But then, every change is different. A reduced test set might ignore highly critical areas for that one change!

So how do you pick tests? How do you cover the most risk, in the current situation, in the shortest time?

Much like cooking a nice dish, there are many aspects that go into such a selection:

  • What has changed in the product?
  • How many people have touched which part of the code and within what timeframe?
  • Which tests are very good at uncovering real issues?
  • Which tests have been run recently? How long does this test take?

Again, you’ll see that most of this data is already available – in your versioning system, in your test reports, and so on. While we still need to discuss “what does ‘risk’ mean for your particular situation?” (a very, very important discussion!), it is likely that you already have most of the data to then rank tests based on this understanding. After that, it‘s just a matter of having this discussion and implementing “intelligent test case selection” in your environment.

== Seventh Recipe ==

From “Nobody dares to touch legacy code” to “We know the risk our code carries.”

Continuing on the topic of “risk,” we noticed something else: After spending a lot of time with a certain codebase, experienced coders get very good at knowing which code changes are dangerous and which are not.

But then, there is always some system-critical code written by a colleague who left many years ago, written many years before that. There is code that came from a vendor who is no longer a partner of the company. There are large shared code-bases that vertically sliced teams are working on, with no one having a full overview of the whole. And there are newer, less experienced colleagues joining up. On top of that, even experienced people make mistakes. Haven’t all of us experienced such scenarios?!

There are many systems to mitigate all this. Some examples are code quality measurements, code coverage measurements, versioning systems, and so on. They tell you what to do, what to fix. But they are not “immediate.” Imagine, you’re changing a line of code – you’re usually not looking up all of these things, or the full history of that line, every single time.

So how about a system that integrates all these data points:

  • Is this line covered by tests?
  • How often has it been changed by how many people in the last two days
  • How complex is it?
  • How many other parts depend on in?

We can also factor in expert opinions by, let’s say, adding an annotation. Then we use all this information to generate a “code risk indicator” and show it next to the class/method/line of code. “0 – change this. This is pretty safe”. “10 – you better think about this and get a second pair of eyes plus a review”. If you click on it, it explains all these points and why this score was given directly in your IDE.

The purpose is not to fix the risk, although it can be used for that too. But the primary objective is to give developers a feeling of the risk that their changes carry, before they make them.

== Eighth Recipe ==

From “Model-based? We don’t have time for that!” to “Models create themselves – and help us.”

Model-based testing has been on many people’s minds for many years. But it seems it never really “took off.” Part of the reason might be the complexity of these models, coupled with the fact that these models need to be built and maintained by experts. Apart from this, while these models are very good at generating many tests, they usually have blind spots around the expected outcomes of these tests.

So in most cases, model-based testing is not regularly applied and still has a lot of potential!

So how can we mitigate these issues? By automatically generating a usable model from the available information. You can use many methods and sources for this, like analysis for requirements documents, analysis of code, dependencies, and so on. The flip side of these methods is that the model is not “independent” of these sources but is an interpretation of their content.

But that does not mean that they can’t be useful.

Think back to our “fifth recipe” – generating a graph from our automated test suite. This is actually a state-transition model of our tests and, by extension, the product we’re testing (because the structure of our tests reflects the usage flow of that product). And it has potential.

We could, for example, mark a series of connected nodes and ask the system to generate basic code to execute these test steps in sequence. They will then be manually completed into a full test case. We could ask the system, “is there a test case connecting these two nodes?” to increase our coverage or “are there two tests that are both covering this path?” to remove redundant tests.

Since this model is not created manually, and since the basis, it is generated from (automated tests) is maintained to be in sync with our product, we do not need to spend any extra time to maintain this model either. And it has a lot of use-cases.

== Our traditional recipe ==

Ingredients:

  • 5 annoying everyday tasks and pains
  • A fridge full of data you already have
  • 1 thumb-sized piece of knowledge about Machine Learning
  • 20g creativity

Instructions:

  • Stir your thoughts, complain about the most annoying things
  • Add creativity, mix well
  • Take the knowledge about ML out of the package
  • Add it to the creative mix, gently stir in the data
  • Bake in the oven at 200°C, for the duration of an MVP
  • While baking, check progress and generated value repeatedly
  • Take out of the oven, let rest for a bit
  • Serve while hot – best served with a garnish of practical experience

Have fun and enjoy this dish!

If you have any questions on the test automation and software testing process improvement, don’t hesitate to contact us at aqt@nagarro.com. 

Download your free infographic with all 8 recipes! 

Author

Thomas Steirer CTO and Lead of the Global Test Automation Practice

Thomas Steirer is CTO and Lead of the Global Test Automation Practice. He has developed numerous automation frameworks and solutions for a variety of industries and technologies. At Nagarro, he supports clients implementing test automation and building scalable and sustainable solutions that add value. He is also passionate about using artificial intelligence to make test automation even more efficient. In his spare time, he teaches at universities in Austria and is an enthusiastic Gameboy musician.

Nagarro was a exhibitor at AutomationSTAR 2024.

Efficient Software Testing in 2023: Trends, AI Collaboration and Tools

In the rapidly evolving field of software development, efficient software testing has emerged as a critical component in the quality assurance process. As we navigate through 2023, several prominent trends are shaping the landscape of software testing, with artificial intelligence (AI) taking center stage. We’ll delve into the current state of software testing, focusing on the latest trends, the increasing collaboration with AI, and the most innovative tools.

Test Automation Trends

Being aware of QA trends is critical. By staying up to date on the latest developments and practices in quality assurance, professionals can adapt their approaches to meet evolving industry standards. Based on the World Quality Report by Capgemini & Sogeti, and The State of Testing by PractiTest, popular QA trends currently include:

  • Test Automation: Increasing adoption for efficient and comprehensive testing.
  • Shift-Left and Shift-Right Testing: Early testing and testing in production environments for improved quality.
  • Agile and DevOps Practices: Integrating testing in Agile workflows and embracing DevOps principles.
  • AI and Machine Learning: Utilizing AI/ML for intelligent test automation and predictive analytics.
  • Continuous Testing: Seamless and comprehensive testing throughout the software delivery process.
  • Cloud-Based Testing: Leveraging cloud computing for scalable and cost-effective testing environments.
  • Robotic Process Automation (RPA): Automating repetitive testing tasks and processes to enhance efficiency and accuracy.

QA and AI Collaboration

It’s no secret that AI is transforming our lives, and ChatGPT’s collaboration can automate a substantial portion of QA routines. We’ve compiled a list of helpful prompts to streamline your testing process and save time.

Test Case Generation

Here are some prompts to assist in generating test cases using AI:

“Generate test cases for {function_name} considering all possible input scenarios.”
“Create a set of boundary test cases for {module_name} to validate edge cases.”
“Design test cases to verify the integration of {component_A} and {component_B}.”
“Construct test cases for {feature_name} to validate its response under different conditions.”
“Produce test cases to assess the performance of {API_name} with varying loads.”
“Develop test cases to check the error handling and exceptions in {class_name}.”

Feel free to modify these prompts to better suit your specific testing requirements.

Example

We asked for a test case to be generated for a registration process with specific fields: First Name, Last Name, Address, and City.

AI provided a test case named “User Registration” for the scenario where a user attempts to register with valid inputs for the required fields. The test case includes preconditions, test steps, test data, and the expected result.

Test Code Generation

In the same way, you can create automated tests for web pages and their test scenarios.

To enhance the relevance of the generated code, it is important to leverage your expertise in test automation. We recommend studying the tutorial and using appropriate tools, such as JetBrains Aqua, to write your tests that provide tangible examples of automatically generating UI tests for web pages.

Progressive Tools

Using advanced tools for test automation is essential because they enhance efficiency by streamlining the testing process and providing features like test code generation and code insights. These tools also promote scalability, allowing for the management and execution of many tests as complex software systems grow.

UI Test Automation

To efficiently explore a web page and identify available locators:
Open the desired page.
iInteract with the web elements by clicking on them.
Add the generated code to your Page Object.

This approach allows for a systematic and effective way of discovering and incorporating locators into your test automation framework.

Code Insights

To efficiently search for available locators based on substrings or attributes, you can leverage autocompletion functionality provided by the JetBrains Aqua IDE or plugin.

In cases where you don’t remember the location to which a locator leads, you can navigate seamlessly between the web element and the corresponding source code. This allows you to quickly locate and understand the context of the locator, making it easier to maintain and modify your test automation scripts. This flexibility facilitates efficient troubleshooting and enhances the overall development experience.

Test Case As A Code

The Test Case As A Code approach is valuable for integrating manual testing and test automation. Creating test cases alongside the code enables close collaboration between manual testers and automation engineers. New test cases can be easily attached to their corresponding automation tests and removed once automated. Synchronization between manual and automated tests to ensure consistency and accuracy is a challenge that does not need to be addressed. Additionally, leveraging version control systems (VCS) offers additional benefits such as versioning, collaboration, and traceability, enhancing the overall test development process.

Stay Tuned

The industry’s rapid development is exciting, and we are proud to be a part of this growth. We have created JetBrains Aqua, an IDE specifically designed for test automation. With Aqua, we aim to provide a cutting-edge solution that empowers testers and QA professionals. Stay tuned for more updates as we continue to innovate and contribute to the dynamic test automation field!

Author

Alexandra Psheborovskaya, (Alex Pshe)

Alexandra works as a SDET and a Product Manager on the Aqua team at JetBrains. She shares her knowledge with others by mentoring QA colleagues, such as in Women In Tech programs, supporting women in testing as a Women Techmakers Ambassador, hosting a quality podcast, and speaking at professional conferences.

JetBrains were an EXPO Gold partner at AutomationSTAR 2023.

Prompt-Driven Test Automation

Bridging the Gap Between QA and Automation with AI

In the modern software development landscape, test automation is often a topic of intense debate. Some view it strictly as a segment of Quality Assurance, while others, like myself, believe it intersects both the realms of QA and programming. The Venn diagram I previously shared visualizes this overlap.

Historically, there’s a clear distinction between the competencies required for QA work and those needed for programming:

Skills Required for QA Work:

  • Critical Thinking: The ability to design effective test cases and identify intricate flaws in complex systems
  • Attention to Details: The ability to ensure that minor issues are caught before they escalate into major defects.
  • Domain knowledge: A thorough understanding of technical requirements and business objectives to align QA work effectively.

Skills Required for Programming:

  • Logical Imagination: The capability to deconstruct complex test scenarios into segmented, methodical tasks ripe for efficient automation.
  • Coding: The proficiency to translate intuitive test steps into automated scripts that a machine can execute.
  • Debugging: The systematic approach to isolate issues in test scripts and rectify them to ensure the highest level of reliability.

We’re currently at an AI-driven crossroads, presenting two potential scenarios for the future of QA. One, where AI gradually assumes the roles traditionally filled by QA professionals, and another, where QAs harness the power of AI to elevate and redefine their positions.

This evolution not only concerns the realm of Quality Assurance but also hints at broader implications for the job market as a whole. Will AI technologies become the tools of a select few, centralizing the labor market? Or will they serve as instruments of empowerment, broadening the horizons of high-skill jobs by filling existing skill gaps?

I’m inclined toward the latter perspective. For QA teams to thrive in this evolving ecosystem, they must identify and utilize tools that bolster their strengths, especially in areas where developers have traditionally dominated.

So, what characterizes such a tool? At Loadmill, our exploration of this question has yielded some insights. To navigate this AI-augmented future, QAs require:

  • AI-Driven Test Creation: A mechanism that translates observed user scenarios into robust test cases.
  • AI-Assisted Test Maintenance: An automated system that continually refines tests, using AI to detect discrepancies and implement adjustments.
  • AI-Enabled Test Analysis: A process that deploys AI for sifting through vast amounts of test results, identifying patterns, and highlighting concerns.

When it comes to actualizing AI-driven test creation, there are two predominant methodologies. The code-centric method, exemplified by tools like GitHub Code Pilot, leans heavily on the existing codebase to derive tests. While this method excels in generating unit tests, its scope is inherently limited to the behavior dictated by the current code, making it somewhat narrow-sighted.

Contrarily, Loadmill champions the behavior-centric approach. An AI system that allows QA engineers to capture user interactions or describe them in plain English to create automated test scripts. The AI then undertakes the task of converting this human-friendly narrative into corresponding test code. This integration of AI doesn’t halt here – it extends its efficiencies to areas of test maintenance and result analysis, notably speeding up tasks that historically were time-intensive.

In sum, as the realms of QA and programming converge, opportunities for innovation and progress emerge. AI’s rapid advancements prompt crucial questions about the direction of QA and the broader job market. At Loadmill, we’re committed to ensuring that, in this changing landscape, QAs are not just participants but pioneers. I extend an invitation to all attendees of the upcoming conference: visit our booth in the expo hall. Let’s delve deeper into this conversation and explore how AI can be a game-changer for your QA processes.

For further insights and discussions, please engage with us at the Loadmill booth. 

Author

Ido Cohen, founder and CEO of Loadmill.

Ido Cohen is the Co-founder and CEO of Loadmill. With over a decade of experience as both a hands-on developer and manager, he’s dedicated to driving productivity and building effective automation tools. Guided by his past experience in coding, he continuously strives to create practical, user-centric solutions. In his free time, Ido enjoys chess, history, and vintage video games.

Loadmill are a Gold Sponsor at AutomationSTAR 20-21 Nov. 2023 in Berlin

part of the