Category

QA

Category

Over the past few years, our team has been working hard to improve the functionality and usability of our autonomous testing platform. This mindset is what made us successful in building a product that people love and trust. In 2019, we released many new features that help testers author and execute tests more efficiently.

In this webinar, we discussed how the AI works underneath the hood, what are some of the features that help in faster authoring, execution and maintenance of automated tests and finally, discussed the top features within Testim that were released this year.

Here is the recording of the webinar

Below are some useful links related to features discussed in this webinar

Some useful blog posts to quickly get to know Testim

Quite often there is a need to validate the content of a downloaded document which could be a PDF, Word Document, CSV file or databases such as MySQL, MongoDB. All these are possible within Testim using the CLI action step. This feature helps to create and execute custom Node.js scripts at runtime; to perform different validations. Below are some tips to help with CLI action steps.

Tip 1: How to find out what node.js packages you can use?

The different node.js packages that can be used within Testim are the ones found in https://www.npmjs.com/. This is the official website that has references to all the open source node.js packages. Say for example, you are searching for a package related to pdf documents; just search for “pdf” and you will get a list of all the node.js packages available for pdf.

Tip 2:  What are the available CLI action steps within Testim?

Below are the available CLI action steps within Testim-

  • Add CLI action
  • Add CLI validation
  • Add CLI wait for
  • Validate download
  • Wait for download

Tip 3:  How to add node.js packages to Testim?

To add node.js packages to Testim, follow the below steps

  • Add one of the above mentioned CLI action steps
  • In the Properties Panel, click on PARAMS-> PACKAGE

Tip 4: How to execute CLI action steps locally?

To execute node.js scripts via CLI action steps locally, you need to first set up the runtime environment using the below command. Ensure this command is executed from the command line before running a test with a CLI action step.

npm i -g @testim/testim-cli && testim –agent

Putting everything together

Lets see how all the tips work together to execute node.js scripts. Say you want to validate the content of a downloaded document such as a PDF file. The steps to do this would be-

  • Ensure CLI Action feature is enabled (Contact our CSM or customer support for this)
  • Add the “Validate Download” action
  • Add the necessary node.js package for the pdf content validation. In this case, we are adding the latest version of the package pdf-parse
  • Then, add the necessary code to do the content validation

Here is a sample test to show how to do PDF content validation – PDF Validation

For more CLI action examples, check out the last section of this doc – CLI Action

Today’s post is going to be all about automated functional testing. What’s this category of tests really about? Why do you need it? How do you go about implementing it? What are the challenges you might face when doing so? With this post, we’re going to answer these questions—and more.

We’ll start out by defining functional testing. Then, we’ll go on to explain the benefits of functional testing so you understand why you need it, even if you already employ other types of tests. After that, we’ll reach the “automated” part of “automated functional testing.” We’ll define automation, explaining how it’s imperative to apply it to testing. Then, we’ll be ready to cover automated functional testing.

With the definitions out of the way, it’s time to get to more specific advice. You’ll see how to get started with automated functional testing, the possible challenges on your journey, and how you can beat them.

Functional Testing: What It Is and Why You Need It

Functional testing, as its name implies, concerns itself with how a given application functions. Does the application meet its functional requirements? Does it solve the problems of its users? These are the kind of questions that should be answered by functional test cases.

Functional testing is, then, a type of black-box testing. In other words, functional testing couldn’t care less whether you’ve used an array or a list to model a given concept. The only thing that matters is that the application’s external behavior meets the requirements.

Unit Tests Are Not Enough

In some software development cycles, there are people who seem to think of unit tests as the ultimate software panacea, the mythical silver bullet that will solve all software crises for good.

There’s no such thing, of course.

Make no mistake: unit tests are awesome. They can either lead to a cleaner, low-coupled design or—in the worst scenario—make you acutely aware of poorly designed, high-coupled code. They often cause developers to learn about good development practices, such as immutability, purity of functions, and separation between logic and presentation. More importantly than all of that, a comprehensive suite of unit tests empower developers to fearlessly refactor, knowing they have a safety net if they break something.

Did you notice who is missing from the previous paragraph? The user.

Let’s Think of the Final Users

The previous section covered some of the benefits of unit testing. You’ll notice, though, that those benefits seem to benefit mainly the developers themselves. Sure, cleaner code and a more maintainable application will indirectly benefit users, no doubt about that. But that’s not enough.

There’s a school of thought that argues that “unit testing” is an unfortunate name for an otherwise great tool, and I agree with that. I’ve seen people use “executable specifications” as an alternative name. The point is this: unit tests aren’t really tests. They’re verifications that developers use in order to check that the code they wrote does what they think it does.

But who’s checking whether the code they wrote does what the user expects it to do? That’s the job of functional testing.

It is possible to write a correct, elegant and efficient solution…to the wrong problem. While unit tests will make you confident you’re solving the problem correctly, functional testing is what ensures that you solve the right problem, for the right users.

Automated Functional Testing: Understanding Its Benefits

Up until now, you’ve seen what functional testing is and why you need it, even if you already use other, also very useful, types of tests. Now it’s finally time to add “automation” into the mix. We’re going to define automation and show why its use is imperative in testing. We’ll then zoom in and talk specifically about automating functional tests.

Automation Is Great. Are We Using It?

As developers—and software development professionals in general—we can consider that automation is the whole raison d’être of our jobs.  Why shouldn’t we use it to improve the efficiency of the software development process itself?

Sure, programmers have been automating aspects of their job since the dawn of software engineering. But in recent years, the industry’s use of automation increased to unprecedented scales. We can see this reflected in the growing use of automated testing and, more generally, in the DevOps movement.

Automation in Testing Is a Must

If there’s one area in the whole software development process that really benefits from automation, that area is testing. That’s due to one of the most unique characteristics of software—even the smallest change in one area of an application can cause unforeseen consequences in a totally different area. Yep, that’s a serious problem. In an ideal application, with sound architecture, something like that should never happen. We don’t live in the ideal world, unfortunately, and things like that do happen frequently.

The implication of this unique software characteristic is crucial. After making some change on a codebase, the only way to be sure the whole application still works properly is to retest the entire app. Just testing your own change isn’t enough. You could’ve broken something and you’d never know.

That means that, in modern software development, applying automation to testing is imperative.

Automated Functional Testing: You Can Have Your Cake and Eat It Too

Automated functional testing is, in a way, the best of both worlds—it brings to the table the benefits that automation provides to all kinds of tests, along with the functional testing ethos of putting the user’s needs first. It takes automated testing to its full potential, making it not only a tool for developer confidence (which is already awesome in itself), but also a tool for customer satisfaction. It bridges the gap between QA professionals and developers, creating a shared space where they can collaborate.

Automated functional testing sounds awesome—and it is—but how do you actually get started with it? I’m glad you asked.

The first step is to have specs. You can’t have tests that verify whether the application conforms to the specifications if there aren’t any. For this first moment, it shouldn’t matter that much whether the specifications are embedded into the code or recorded in an external document. The important thing is that you have them.

Then, it’s time to start thinking about the possible test cases for your application. Start your app, go to its main screen, and look at it critically. What are the tasks the user is supposed to perform here? How could they go wrong? It’s even better if you don’t do this on your own. Instead, bring in some coworkers to help. Do a brainstorm session on the current screen. Write down all of the ideas that you can come up with.

Then do the same with other areas of the application.

After all of this, do you have a reasonably sized list of possible use cases? Great, now it’s time to go shopping for tools. This post is meant to be platform agnostic, so we won’t actually recommend particular testing frameworks. But it doesn’t matter your language or tech stack of choice, rest assured, there are automated functional testing tools out there for you.

Automated Functional Testing Challenges: What They Are and How To Overcome Them

As promised, now it’s finally time to cover some of the common challenges when implementing automated functional testing. What are those? How do you beat them? Keep reading to learn more.

QA Skepticism

One of the most common challenges when implementing all kinds of automated testing is skepticism. It’s 2019 and there are still many professionals that are unfamiliar with automated testing, believe it or not. There are also others who know about automated testing but don’t quite buy into the usefulness. How do you deal with the skeptics? Education.

You must use every kind of material at your disposal—books, online courses, on-site training, and what have you. After some training, make your QA people get their hands dirty. Have them start creating automated functional tests, first on a very small scale. Then, start to gradually increase said scale. In true Agile fashion, use small steps, reviewing your results in short iterations. Rinse and repeat. That’s pretty much it.

Developers Skepticism

When it comes to developers, it’s possible that some of them have jumped on the “unit testing = software panacea” bandwagon. If that’s the case, make them get off the bandwagon. The tool for doing so? You guessed it, education. Hands-on education.

Have your developers collaborate with QA people. Create small, cross-functional teams on which QA and developers can work side by side. As automation experts, developers might be of incredible help, mentoring QA people on the nuances of automated testing frameworks and tools.

This approach will create trust and empathy between developers and QA professionals, bridging an otherwise insurmountable gap, and destroying every trace of skepticism toward automated functional testing on both sides.

Maintenance Burden

Another challenge of automated functional testing—and other types of automated testing—is the maintenance burden. You see, test code is code, after all. It can contain bugs. It might be unreadable. And the list goes on.

How do you overcome this challenge? First of all, education again. Educate yourself and your coworkers on the best practices for writing tests, be them functional or otherwise. Read about ways to keep your test code clean and readable. Learn about the common mistakes people make when writing tests and what you should do to avoid them.

Finally, there are tools that can ease your burden by providing you with test management capabilities that you would otherwise not have, such as comparing versions of the same test, scheduling tests executions, and automating bug reporting.

Automated Functional Testing Helps You Solve the Right Problems at the Right Speed

Software development is a field that evolves at breakneck speed. In order to keep up with such rapid change, companies rely more and more on automation, giving birth to approaches such as DevOps and continuous delivery.

Automated testing plays a crucial role in this scenario. It’s unfeasible for teams to completely retest their application by hand each time someone has made a change. Automated testing is way past the point of being something that’s “nice to have”—software development in the 21st century requires it.

Automated functional testing, in particular, brings the benefits of automation to a type of test that puts the user front and center. It bridges the gap between QA and developers, ensures the application meets the user’s needs, and takes automated testing to its full potential.

Author bio: This post was written by Carlos Schults.Carlos is a .NET software developer with experience in both desktop and web development, and he’s now trying his hand at mobile. He has a passion for writing clean and concise code, and he’s interested in practices that help you improve app health, such as code review, automated testing, and continuous build.

So your company is going Agile. If you’re a tester or QA person, that can bring about frightening thoughts about what your world will look like. For example, will you now be expected to test a codebase that changes daily, with no breaks or developer deadlines? Alternatively, you’ve heard that some teams do away with QA and testers completely once they go agile. How will you survive in this scenario?

Fear not, for there’s still a need for QA in our new agile world. However, instead of the old paradigm, where your goal involves finding defects, your new goals include preventing defects and helping ship products faster. And with this guide, you’ll be on your way to creating a robust and healthy QA process.

In this post, we’re going to take a look at what going agile means from a QA perspective and how you can change to thrive in this environment.

What Does Going Agile Mean for QA?

When reviewing the values and principles of agile, we don’t see testing addressed as clearly as we’d like. In fact, we’re not even sure if traditional QA has a place. But we need to read between the lines and picture what this means for us. Here are the four values that came from the Agile Manifesto:

  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
  • Individuals and interactions over processes and tools

Now let’s look at how these values fit together with QA.

Working Software Over Comprehensive Documentation

For the first value, we learn that working software comes before comprehensive documentation. Now, this doesn’t mean you can’t have any documentation, no matter what your development team tells you.

It means you should create documentation only if it provides value. In the testing world, we should spend less time writing out manual test plan documentation and more time automating the tests.

And we do have some things that will always need documentation. For example, putting together documentation for the customer can be a big part of QA’s job, as they’re most familiar with how to use the system.

As another example, you’ll need to document how to recreate a defect within the application. But don’t spend too much time filling out forms, tickets, or any other unnecessary work. Look for streamlined ways you can clearly communicate the defect to the development team without much overhead.

Whatever you do, make sure it drives the result of having working software.

Customer Collaboration Over Contract Negotiation

In the previous section, we mentioned putting together documentation for customers. That should be one of the last steps. Before the documentation, we should be working closely with our customers to understand how they use the system and why they might run into defects or bugs. Learn what their pain points are so you can share what you’ve learned with the development team.

Overall, your relationship with the customer should look like a partnership, not a criminal case.

Responding to Change Over Following a Plan

One big concern testers have when it comes to delivering software frequently involves keeping up with the testing. Everything changes in agile, and fairly quickly. Stop trying to build a plan for a future that might not come true. Instead, work to put in automated tests and guardrails so that you’re able to react quickly to changing priorities and functionality.

Sprinkle in as much automation as you can so that when change happens, you’re ready.

Individuals and Interactions Over Process and Tools

In our old waterfall world, the QA team would get a few weeks prior to release to learn and test all the new functionality. And, as waterfall usually went, those few weeks would shrink from four to three to two weeks max as software development deadlines slipped. We still needed to ship our product, and the QA team would feel much of this pain.

In this new agile paradigm, QA should be involved throughout the whole process. In fact, testers should interact daily with the team. Whether it’s pairing on a task or discussing how a story should be tested, they’re integral in discussions around testing and quality.

Another important note: agile teams have frequent ad hoc design discussions, so testers should be co-located and available to jump in on those discussions whenever they happen. So don’t create more paperwork and process to share ideas—instead, involve yourself in the whole software delivery process.

What Should QA Do Now?

Now that we’ve covered the agile values, we still might have questions as to how we’re supposed to work when agile. In this section, let’s cover some of the ways that our QA skills can help the team deliver quality software in a continuous way.

From a day-to-day standpoint, involve yourself in stand-ups, retros, and demos. Stay on top of the work the team is doing so you’re aware of dependencies between stories and what additional testing will be necessary.

What else should you do?

Join the Team

The biggest change involves not having a separate QA team. Instead, QA should be part of the development team. Since we’re part of the team, we’re able to assist in continuous testing, instead of doing it all at the end of the sprint.

Also, when we’re on the team from start to finish, we have the chance to affect the delivery of the product much more. Why is that? In an agile team, roles aren’t as clearly defined. You may be able to write your own story by stepping in as a testing coach or automation SME.

When the team focuses on delivering working software faster to the customer, you’ll have the opportunity to provide flexible support to your teammates.

Understand the Big Picture

While the developers dive into specific details of the task they’re working on, you have the responsibility of understanding the big picture. You’ll need deep knowledge of the working system to define tests and scenarios that might not be apparent from the outside. And with that whole-system view, you’ll be able to write the documentation that’s necessary for your customers.

Additionally, keep in mind application design. Understanding your product’s design can help identify interesting edge cases that should be considered.

Understanding the big picture can also help with a blind spot the engineers might miss. The big picture will help you uncover assumptions the team has made about the system. And those assumptions could leave a gaping quality hole in your end product. Therefore, you’ll always want to have a keen understanding of the system as a whole.

Automate Your Test Suite

Since agile testing is done in parallel to development, automation becomes critical. Without it, you’ll find yourself retesting the same functionality three or more times in a sprint or iteration.

Your developers will write unit and integration tests. However, they write those tests to a spec and typically can’t cover the use case from end to end. This is where you come in as a QA professional.

Now, you may think that you’ll need to learn to code to automate all these tests. Learning to code—or at least learning some light scripting—definitely has its benefits. But also take advantage of tools like Testim to easily put together automated functional tests for your product.

These automated tests can be based on the acceptance criteria in developer stories. Create tests that ensure that your product works correctly. And look for where there may be gaps in understanding, and therefore a need for additional tests.

Test Manually for the Right Reasons

Exploratory testing can identify gaps in automated tests. This shouldn’t involve going through the same manual processes over and over.

Instead, this time is for asking those “what if?” questions.

What if the order gets canceled after the shipping paperwork gets printed? What if I lose my internet connection while sending the payment?

Put time into exploratory testing to give your team more confidence that they didn’t miss a critical bug or loss of functionality.

Enable Faster Delivery

As mentioned before, because it’s so critical, we need to enable faster delivery of software. As the QA person on the team, this can mean a lot of different things. For example, help your team define what a completed story looks like. Assist with story creation. Help the team identify what’s missing or out of scope for a particular story. Guide them to ensure that you deliver your product with quality.

But most importantly, don’t be a bottleneck or a block. Enable the team to go faster.

Share Testing Practices

As QA, you have an understanding of good testing practices. Help the team by sharing your experience. Consider how a feature would be easier to test. Perhaps look for ways to make the design more testable.

Continuously Improve

Though quality is the whole team’s job, you should be driving continuous improvement of testing practices. Work to become an expert on agile testing methodologies and strategies. Help the devs create integration tests that aren’t flaky but ensure that the system is working. Help build maintainable and healthy test suites.

Summary

In an agile team, everyone is responsible for quality. And this can be your time to shine by sharing your expertise with the team. Work with your team to build quality into the development process. As I mentioned earlier, the goal no longer involves finding bugs and defects, but preventing them.

Find ways to use agile practices and values to make that happen in collaboration with the team and the customers. You’ll be able to find comfort in your new agile workplace without fear or apprehension.

Author bio: This post was written by Sylvia Fronczak. Sylvia is a software developer that has worked in various industries with various software methodologies. She’s currently focused on design practices that the whole team can own, understand, and evolve over time.

Artificial Intelligence (AI) has taken over the world in the past few years. Not a day goes by without hearing something new that has come up in the field of finance, healthcare, ecommerce, computer vision and much more. Now we have AI in the field of software testing.

In this webinar we discussed how Testim has implemented AI to speed up authoring, execution and maintenance of automated tests and has significantly reduced the cost of maintenance. We covered-

  • How the AI works underneath the hood?
  • How we reduce the time spent on authoring, execution and maintenance of tests?
  • How we integrate Testim in a CI/CD pipeline?
  • What kind of reporting we get when using Testim?

Here is the recording of the webinar

Introduction
We work hard to improve the functionality and usability of our autonomous testing platform to support your software quality initiatives. This month we’re thrilled to release a few of your most requested features; Multi Tab Screenshots, Generate Random Value Step, Suite View Free Text Search, Test List Export Feature. Check them out and let us know what you think.

Multi Tab Screenshots

What is it?

As a follow up to the multi tab indicator feature released last month, we now provide additional visibility when working with multi tab steps. You will now see test fail screenshots from all test tabs.

NOTE: The bottom carousel displays all tabs. There is indication of which tab the step executed on (the “Run Tab” label) as well as an indication of which tab is currently presented in the main viewport.

Why should I care? 

There is no longer a need to open a step and look at the screenshots or other related information to know what tab the step ran on. With the tab number indication and the screenshots, the user has more visibility into test runs that involve multiple tabs/windows. Learn More

Generate Random Value Step

What is it?

You now have a step to generate random values containing text, numbers and certain prefixes during run time. The value gets stored in a variable name which can be used in other steps as well. By default the variable name is randomValue.

In the interest of making this step more robust, we’ve added a few simple (but useful) features:

● Ability to generate letters only, numbers only, or letters and numbers (mixed) strings.

● Ability to control the length of the output string

● Ability to add a prefix to the generated value (can be a string, variable, or JS expression)

Why should I care? 

Until now, you had to add custom code to generate random strings. With this new step everything is handled by Testim within one click and the need for code is eliminated.

Suite View Free Text Search

What is it?

You now have the ability to do free text search in the Suite Runs tab to search for a particular suite.  As you type in the characters, a list of suggestions (based on the existing test suites) are automatically pre-populated for you to click on.

Why should I care? 

There is no longer the need to scroll through all the suites and then click on the required one. Instead, you just search for the suite and it automatically shows up.

Test List Export Feature

What is it?

You will now see an export button in the test list page. Clicking this button will download the test list as a CSV file, which can then be imported into excel or Google sheets.

NOTE: We have the same feature in the results page as well. Learn More

Why should I care? 

We now have the ability to easily share the tests across teams with people who use and do not use Testim. This also gives the flexibility to feed the generated CSV file to any external tool or framework for more customized reporting. The possibilities are endless.


Quite often there are some elements and attributes that change dynamically on a page. For example – Say you have a currency conversion application. Today, 1 US Dollar would be equal to 0.89 Euros. The same dollar could be 0.90 Euros the very next day; as they change dynamically on a daily basis. In Testim, you have the following ways to handle dynamically changing elements-

Tip 1: Validating Dynamically Changing Elements

Whenever you want to validate dynamically changing elements, Testim has export parameters to handle this situation. 

For example – Say you want to validate the price of your flight trip. The price changes dynamically on a daily basis based on multiple factors. In this case, you can use export parameters; where in, you can store the element in an export variable and use the variable in different steps as parameters and also use it to do different validations in a page.

Tip 2: Generating random values during run time

Quite often there is a need to generate random values containing text, numbers and certain prefixes during run time. This is possible using the generate random value step in Testim. The value gets stored in a variable name which can be used in other steps as well. By default the variable name is randomValue.

We recently hosted a webinar on Common Automation Pitfalls and Solutions with an awesome panel consisting of Jonathan Lipps, Philip Lew and me. There were a lot of great discussions on this topic and we wanted to share this with the community as well.

Several topics related to automation were covered in this webinar, including-

  • How automation fits in the SDLC?
  • Is the Testing Pyramid still relevant in this day and age?
  • How automation complements manual testing?
  • How it fits in the CI/CD pipeline?
  • How to come up with a good test automation strategy?
  • What are common pitfalls we fall into while doing test automation?
  • What are some good practices of automation to keep in mind?
  • What are the new trends in automation?

Automation is not a “one size fits all” solution. It does not solve all testing problems. It is just one aspect of the overall testing process. This webinar helps to instil that mindset. It will also be a good resource for all the testers starting to do test automation and experienced testers who are looking for more ideas to build and maintain robust automation frameworks.

Below are some quotes from the conversation-

Phil: “I think when we talk about automation strategy, a lot of folks start digging down really quickly and do tools and frameworks and things like that. But to me, I think that’s the easy part, the hard part, determining why and how are we going to show value?”

Johanthan: “Don’t call something a flake, investigate, figure out exactly what the problem is with it and then either fix that problem in your app or your infrastructure or consider doing away with the test entirely.”

Me: “When you’re trying to build automation frameworks try to also make it as simple as possible because in that way you can further avoid a lot of pitfalls in running and maintaining it.

Below is the recorded video of the webinar-

If you have any feedback or ideas for other webinar topics, we would love to hear that as well. You can email us at raj@testim.io and share them.

Introduction

We work hard to improve the functionality and usability of our autonomous testing platform to support your software quality initiatives. This month we’re thrilled to release a few of your most requested features; Multi Tab Indicator, Advanced Merge, Failed Test Retry Flag and Refresh Option. Check them out and let us know what you think.

Multi Tab Indicator

What is it?

You now have a numeric value that displays in the top right section of each step that executes in multiple tabs.

Why should I care?

There is no longer a need to open a step and look at the screenshots or other related information to know what tab the step ran on. With the tab number indication, the user has more visibility into test runs that involve multiple tabs/windows. Learn More

Advanced Merge

What is it?

When merging changes into a branch, a modal window will now pop up showing different changes that are being merged into the branch. The changes are categorized into Test, Shared Steps and Suites.

At the top level, users will be able to see what changed in each category – how many new items were created, updated, or deleted. Expanding each item, will display more details about individual changes.

Why should I care?

You now have better visibility and confidence before merging branches. All the details that are getting into the branch are clearly detailed in the modal window.

Failed Test Retry Flag

What is it?

When this flag is set, a failed test will be executed repeatedly until either the test passes or the max number of retries has been reached (in which case the test will finish execution with a failed status). This flag is passed in via the CLI by using the below syntax

––retries <max_num_of_retries>

Why should I care?

You now have the ability to re-run failed tests automatically, with the use of this flag. So even if a test fails once or twice because of some unexpected issues, it will automatically run again so that the test passes the next time.  

NOTE: When a test passes after one or more retries, it will be indicated in the UI as shown below

Refresh Option

What is it?

This new option will completely reload the page before proceeding to the next step.

Why should I care?

You no longer have to add custom action to reload the page. Now, there is a one click option to do it.

Testim gives you the ability to playback tests in incognito mode. The reason you may want to use incognito mode is, to get the true behavior of the application without any cached data. This is similar to running tests on the grid, where in each test runs on a new browser instance without any cached data (same as running in incognito mode). The different tips to help you playback tests in incognito mode are as follows-

NOTE: Ensure you allow Testim to run in incognito, before playing the tests.

Tip 1: Running a single test in incognito

If you want to play a test you just created in incognito, follow the below steps

  • Click on the drop down arrow next to the play button
  • Click on “Run in Incognito mode”

Tip 2: Running multiple tests in Incognito

Multiple tests can be run in incognito mode by using the CLI. Each time a test is run on the grid a fresh browser instance opens up without any cached data. Follow the below steps to run multiple tests in incognito all at once-

NOTE: Tests cannot be run in incognito mode from the Test List view. The CLI needs to be used to run multiple tests in incognito.

Be smart & save time...
Simply automate.

Get Started Free