Qyrus Named a Leader in The Forrester WaveTM: Autonomous Testing Platforms, Q4 2025 – Read More

Book a Demo
Try is for free
View demo

Hello and welcome to another edition of Feature Friday, where we highlight specific features or even a specific set of features that help better enable testers to thoroughly and precisely test their applications for defects and functionality. However, we do more than just cover functional testing, we also have capabilities to capture performance profiling metrics. Today, we are specifically going to be covering how we can help enable better performance testing from an API perspective. Joining us are Tim and Jorell who’ll give us more information on the topic!

Tell us more about API performance profiling metrics offered by Qyrus and its use cases. 

Tim:
Performance profiling metrics on Qyrus enable testers to get a more granular view of how their API or APIs perform over time. Specifically, Qyrus is testing and gathering these metrics from a client-side perspective. Some basic information is given, such as the response time per thread and the resulting status code per thread.

Jorell:
However, there is also some more advanced information given, such as the minimum, average, and maximum response times, the standard deviation of response time, response latencies over time, active threads over time, hits per second, and transactions per second.

Tim:
Specifically, this enables testers to get a better understanding of how their APIs perform from a very critical client-side perspective. Ensuring proper response times and that the APIs can handle larger amounts of requests is important.

What is the overall impact that this tool has on the testing process? 

Tim:
This has an impact in terms of test coverage and reporting. From the coverage side of things, all of the performance tests are reused from the functional side of API testing on Qyrus. This allows for a high degree of reusability and a low degree of maintenance.

Jorell:
That also leads to a degree of effort reduction since things are highly reusable. Furthermore, we are looking to add more useful metrics throughout the process. Recently, we have added many more metrics for consumption by the user, such as hits per second, transactions per second, and the min, max, and average response time for the API call.

How might this feature help testers, developers, and business technologists? What value can this feature bring?  

Tim:
In terms of developers, they could utilize the performance testing to test out the APIs they had just finished developing. From that perspective, this type of testing can be done earlier than usual and at a higher degree than usual.

Jorell:
Business technologists will find it extremely easy to not only set up these types of tests but also to execute and view the reports of these tests, as well. The whole point is to make things easier, so that business technologists, can just import the already-created API tests from the functional area.

How do you see this feature impacting day-to-day operations across organizations? 

Jorell:
I know we’ve said it what seems like a million times, but the fact that we can just reuse tests cannot be understated. Cutting the test building time in half, as well as allowing for much easier, quicker, and simpler executions, would save a lot of time in terms of day-to-day operations.

Tim:
Yeah, and that comes from an individual tester’s standpoint but also from a higher level; overall, everything is sped up. Day-to-day operations on the creation of test scripts and API tests can be cut enormously depending on the amount of testing done on the performance side.

‍

Performance testing is an extremely important aspect of the testing process as a whole. Things may be functional, but if it takes 5 minutes for an API to respond after the click of a button, things are seriously wrong. With Qyrus, all aspects of testing are encompassed on one singular platform. We hope you’ve found this informative and invite you to join us next week for our next Feature Friday!

Innovation is the leading principle in technology. The industry as a whole is constantly factoring in new solutions to make lives easier. From dishwashers to video editing solutions, the concept of the industry is to utilize this synergy between hardware and software to make lives easier. The same can be said for the testing industry. There are constantly new and impactful solutions being created to make lives easier. This concept is not lost upon testing solutions, and more so, not staying up-to-date with testing and requirements could be the death of a given solution. This is why Qyrus is constantly releasing a range of action types that implement and simplify common testing tasks and requirements. With a library of action types, the functionality at your fingertips is endless. This week’s Feature Friday is brought to you by Kiwaun and Milton, who will discuss the updates to the mobile test building.

Tell us more about the updates to Mobile test building recently released by Qyrus, and the use cases.

Milton:
There has been a range of additions to mobile test buildings that make the process even simpler and more efficient. As you know, Qyrus is built on action types, and therefore, new ones are constantly being added to ensure steadfast and efficient testing. One of the most recent impacts is tapping by relative coordinates. This feature assists in tapping on elements that cannot be located by normal means. There are a range of reasons elements can be difficult to locate, and when the desired elements cannot be found in inspect mode, tapping Relative Coordinates fixes these problems by taking a user-defined percentage of the element to locate it on the screen. In essence, this allows users to use any unique part of the element to locate it.

Kiwaun:
Others include the Uninstallation app, which, as it sounds, allows users to reset the application data in a test script. Furthermore, verifications have also been added, in this case, verifying dynamic elements. In current mobile applications, a range of dynamic elements are being used. As screens load and generate data, verifying these elements becomes essential, leading to the dynamic element action type.

What are the updates to mobile test buildings’ overall impact on the testing process?

Kiwaun:
So as we mentioned a few, there have been a range of additions across test building, execution, and reporting where we see these action types enabling immediate effort reduction and increased coverage. More than one action type has been added, and the list can be noted as well on our new releases page, but the features go across the testing process and are available for immediate use.

Milton:
Exactly, and the user can reuse the new action types however many times are needed for the testing. These action types are there to be used as required and easy to implement, following the already low-code, no-code form-like functionality of the platform, making mobile testing smooth, simple, yet powerful.

How might updates to test building help testers, developers, and business technologists? What value can this feature bring?

Milton:
The idea of mobile testing with Qyrus is simple, and we see testers utilizing it the most, as they are often the most hands-on in the test building and execution process. Testers use these new action types across automated test scripts. As ‘dynamic element exists’ acts as a verifier with screenshots and data verification provided in reports, tapping by relative coordinates allows testers to tap the same element across multiple devices, often used with difficult-to-find elements across any application screen. Testers utilize these across testing processes to make testing simple, efficient, and rich.

Kiwaun:
Developers use these features in a similar light but often use beta or first-release applications to ensure functionality and further understand requirements. With more action types, developers can test base functionality to ensure the most viable product or sift through and test the deepest corners of their applications. With this freedom, developers test their mobile apps to see what needs to be changed on the front and back ends.

Milton:
Even business analysts use Qyrus testing as a preventive measure against critical bugs. Using these simple-to-use form-like action types, business analysts can build out tests easily and understand application intricacies across devices. Furthermore, with such a diverse action type pool, business analysts can simulate user journeys, interacting with their application in the shoes of the end-user, while creating repeatable, automated test scripts in the process.

Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems? 

Kiwaun:
So Qyrus action types are platform-specific and have all been developed in-house. The development of these action types is often influenced by customer feedback. The more engagement we have, the more we learn about testing and the industry, and we constantly roll out action types and features to enable a simple and efficient testing process. So simply put, no, these exact functionalities cannot be found within other testing solutions.

Milton:
To be specific, testing itself is very fluid, and therefore it is not that a similar feature or functionality cannot be found; it is more so that a similar feature or functionality with a form-like implementation providing screenshots and video evidence, all within an integrated testing solution, truly cannot be found elsewhere.

How do you see these updates to mobile test building impacting day-to-day operations across organizations?

Milton:
We see that users can automate tests further by utilizing these new action types, giving them more flexibility and capability when building test steps. Removing a code requirement and placing a range of functionality behind action types makes the entire testing process not only simpler and smoother but also more inclusive.

The foundation of technology is innovation, and as web and mobile applications develop, alongside API processes, it’s essential that testing capabilities follow suit. This is why a cloud-native, low-code, no-code, automated testing solution provides immense value. With the continued development of features and functionalities, such as the updates to the test building discussed, Qyrus positions itself at the forefront of testing technology, enabling users to simplify the testing process and optimize application functionality and quality.

Use AI to test AI

Topic: Test Chatbots Better – Use AI to Test AI
Date: 28th February 2023
Time: 12pm Eastern Time

Description:
Chatbots are great, but only when they function well.

It may have worked well for ChatGPT, but can’t say the same for Microsoft’s bot Tay who quickly turned to hate speech within just a day or CNN’s bot who had a hard time understanding the simple unsubscribe command.

Disasters happen, but we believe that such situations could have been avoided if they were tested well in the first place.

So here we bring you, Sage – a Conversational Testing Platform, the very first of its kind that provides the user (“a chatbot developer”) the ability to test their bot in a highly automated and regressive manner.

In short, using an AI to test another AI. Quite an irony, right?

Register for this webinar ‘Test Chatbots Better – Use AI to Test AI’, once again in collaboration with TechWell, a leader in software conferences covering Agile, DevOps, Test/QA, Requirements, and more.

In this session, we will talk about:


Speakers:
Ameet Deshpande
Senior Vice President, Product Engineering, Qyrus

Speaker Bio:
Ameet Deshpande is an Engineering generalist and a builder at heart with a focus on Quality Engineering, Product Engineering, Product Management, cross-functional team building and Agile. He has been involved in many strategic initiatives at Qyrus and its clients and especially in Financial Services with primary experience in Quality Engineering, Cloud, SaaS, and AI. He was also involved in large-scale transformation programs as part of a consulting & architecture group within one of the top 10 Banks in the world.

 

Peanut butter and jelly, salt and pepper, cookies, and milk. Though all objects are often found in a kitchen or a pantry, synergy is eminent. Often bought together, and in this case, with the intention of being consumed together, this concept is seen across industries and products. This synergy is often more lucrative than the original products, providing the most possible value. This exact synergy can be found between testing solutions and test case management solutions and led to the development of Qyrus’ integration with Xray. This leads to the topic of this week’s Feature Friday, where Parth and Steve will further discuss the Qyrus Xray integration.

Tell us more about the Xray integration offered by Qyrus and its use cases.

Steve:
The Xray integration is an out-of-the-box integration that provides a link between your Xray issues and your Qyrus test scripts. Upon execution of these test scripts, the results are then populated straight into Xray to view execution results and updates from a single platform.

Parth:
The beauty of it comes in the use cases. Integrating these platforms and building these connections requires no code, simply select the scripts associated with the given issue. This means that regardless of the Xray setup, use case or implementation, Qyrus integrates smoothly, providing immediate value.

What is the Xray integration’s overall impact on the testing process? 

Parth:
The immediate impact of this feature can be seen in the reporting and test case management aspects of the testing cycle. As Xray is a test case management tool, and Qyrus is an automated testing solution, utilizing both in tandem is truly powerful. Taking it one step further in relaying the reports back to Xray with the added option to open Qyrus at any point to further dissect the execution is the meat of this feature.

Steve:
Exactly, and the configurations do not have to be repeated at the project level, you can utilize existing organizational practices and configurations across the teams, services, and projects. Seamlessly bringing a whole ecosystem of test case management to an already powerful end-to-end automated testing solution, this feature immediately impacts the testing, reporting, and test management processes.

How might this Xray integration help testers, developers, and business technologists? What value can this feature bring? 

Steve:
We often see testers dive into this feature, as it really makes their day-to-day tasks more efficient. Testers often work with the X-ray issues firsthand and are already part of the test case creation, maintenance, and management processes. Testers will quickly link and organize Xray issues with Qyrus executions, centralizing reporting with automatic updates to Xray steps upon results.

Parth:
This also brings developers into the testing process. Prior to the integration, developers would simply create Xray issues as arise within the application across beta versions. Now developers can build out issues, and monitor them with reporting that is centralized and saved in one location.

Steve:
This feature also enables business analysts to be further invested in the testing process. Utilizing their knowledge of end-user requirements and the day-to-day usage and impact of applications, they’ll assist in building out the Xray issues and formalizing specific testing requirements. Instead of waiting to hear from team members on test executions or further collaboration on the team, all reports are centralized on Xray.

Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems? 

Parth:
Qyrus is very unique in its Xray integration because it does integrate at a platform level. This means that upon integration, you can take any scripts across any projects within Qyrus, and simultaneously link them to any issues across Xray.

Steve:
Exactly and requiring no coding knowledge or requirement, built into a form-filling manner while relaying reporting back to Xray is something entirely unique to Qyrus.

Steve:
And without the integration, Xray would have to be updated manually. Testing results would not be populated by Xray but would have to be centralized, stored, and shared as a manual effort.

How do you see the Xray integration impacting day-to-day operations across organizations? 

Parth:
It really simplifies the test case management process alongside increasing coverage. For every issue, there is an associated automated test script, and for every execution, there is an associated report. Furthermore, being able to configure once and make endless connections makes sure every corner of your application is covered.

Steve:
Exactly, and regardless of who is working on the Xray issues or developing test scripts, a tester developer or business technologist—everyone with access is immediately on the same page. As updates occur, everyone is updated, and all data is consistent and centralized, directly impacting the daily workflow, and making the process simple, yet more efficient.

‍

A very popular story is of the one ring that ruled them all, and Qyrus does not aim to be as such. Ironically, the very power of Qyrus comes from its ability to integrate out of the box with a range of other solutions, including CI/CD pipelines, defect management, and test case management tools. These integrations, such as the recently developed Xray integration, provide a range of benefits across test building, execution, and reporting. Making the testing and quality assurance processes more efficient, and ultimately enabling the deployment of higher quality products with a high-quality user experience.

Most organizations see testing as a complex activity that, if given a choice, many would like to avoid. Unfortunately, this choice doesn’t exist, and software testing is critical to any software development lifecycle. By 2030, the global testing market is expected to reach US$ 57 billion. This figure illustrates the significance of testing and its place in the development ecosystem.

But there is a problem. A survey conducted amongst the QA organizations Qyrus works with made some interesting revelations concerning API testing. 78% of respondents said it is complex, 65% of respondents were dependent on a manual approach to API testing, while 23% relied on semi-automated testing to get the job done. Testing complexity, its time-consuming nature, and its tendency to be error-prone is a direct outcome of legacy testing driven by manual test software, semi-automated or even code-backed automation testing.

It is time organizations moved to codeless API testing to overcome the challenges of API testing and stopped depending on a testing ecosystem that offers diminishing returns. The most significant benefit of codeless automation testing is that it helps organizations shift left, which fits perfectly within the agile development framework.

Here are three big benefits of adopting an advanced API testing strategy and which improve testing ROI:

  1. Simplified and Accelerated Testing

“Writing reams of code”.

This is what stares at testers when they leverage a legacy or an ordinary automated testing approach. Every aspect of API testing, whether it is onboarding APIs, executing tests and more, requires coding, which can endlessly delay the testing process, especially if an organization is working with an inexperienced team of testers, outdated API tools for testing, or a lean team saddled with other responsibilities.

As the name suggests, codeless automation testing takes the effort out of API testing, improving the testing cycle’s efficiency, and speeding up the testing process. It also helps push testing at the early stages of the development lifecycle and reduces dependency on error-prone coding efforts. In addition, a point-and-click, drag-and-drop interface helps design end-to-end tests with desired response parameters and the ability to easily add assertions to increase test coverage, improve build efficiency, and speed up testing cycles.

       2.  Test APIs Together in a Chain

Testing an individual API is good; testing the functionality of multiple APIs together in a chain is an even better API testing strategy because that’s how APIs work in a real-world scenario. APIs are essential components that facilitate information sharing between applications and processes, and organizations must be absolutely sure the complex business flows central to the organization’s functioning are performing as per desired expectations.

A codeless API automation testing toollike Qyrus helps test the functionality of APIs in a chain by passing data received in one response from an API to another, stringing requests together in a chain. The time taken to create such tests is significantly reduced, as Qyrus enables testers to import previously built tests and integrate tests with CI pipelines to test APIs upon build. The benefit is that bugs can be detected early, allowing organizations to meet release deadlines quickly.

        3.  Leverage Reusability for Performance Testing

The key to a high-performance API is performance testing, and this can be difficult at the best of times. If an organization uses a legacy testing approach, testers will have to spend a good deal of time changing attributes, data or values within test scripts to build performance tests for multiple use cases. With codeless test automation, reusability of tests enters the picture. Test scripts from functional testing can be used to conduct performance tests across various use cases without changing attributes, data or values and without having to write code. This helps save a lot of valuable time and resources. Testers can quickly generate loads with minimal effort and benefit from detailed reports on API performance.

Qyrus offers end-to-end performance testing, which delivers a holistic view of the performance of the entire process or flow, meaning testers test the response of an API and the API flow.

Organizations must focus on unlocking business value with ROI-driven API testing.
An automated API testing strategy will not only increase the speed, efficiency, security, and quality of testing, but also deliver sustainable and tangible long-term benefits to the overall software development life cycle and improve resultant software outcomes.

A feeling we have all felt is being lost for words. Maybe a name or a recently visited place, but being able to paint an image in your mind while tasting the word on the tip of your tongue. A word so familiar that you laugh at your inability to remember it. It is not the best feeling, and if prolonged, it can be extremely tedious. A similar feeling exists in automated testing with impossible-to-locate elements. In essence, the element exists on the screen, and is visible, but cannot be found in the code or by conventional testing methods. Whether it is a text box, image, or title, the element has no basic or obvious locator. Depending on the complexity and design of the page and application, this can become a menacing problem over large-scale test creation and deployment. This leads us to the topic of this Week’s Feature Friday, where Milton and Kiwaun will discuss how Qyrus mitigates these exact problems through a range of tools for difficult-to-find locators.

Tell us more about how Qyrus handles difficult-to-find locators, and these feature use cases. 

Milton:
Leading automated testing solutions often struggle to find locators and locator values. While some work seamlessly, that’s not always the case across all applications, devices, screens, or elements. To solve this problem, Qyrus offers a range of features and functionalities. One example is tapping by relative coordinates, which allows the user to tap on the screen based on a percentage.

Kiwaun:
Exactly, often even locators that Appium and other solutions cannot find can be located. Some other functionalities for exactly this include the recorder for both web and mobility, which allows the user to just click anywhere on the environment to find the locator data of the element, tap and click by coordinate offerings to click by screen location, among more.

What are the features, regarding difficult-to-find locators, and their overall impact on the testing process?  

Kiwaun:
So these features are not as simple as selecting the element of choice. When users have access to any and every element across the screen, the testing output is endless. This increases both creativity and coverage and allows the testing of true end-to-end user journeys.

Milton:
And being able to access any given resource at any given time and find its true impact within the test-building process. Regardless of the application code, screen, device, or any other settings, being able to select and interact with any given element enables effort reduction and increases test coverage.

How might tools to find difficult locators help testers, developers, and business technologists? What value can this feature bring?    

Milton:
These features are important to testers, as they can use the step recorder or some of the specific action types to find otherwise inaccessible locator data. This allows for continual and smooth testing, allowing testers to get all the required test-building data without ever leaving the solution. Also, interacting with more elements allows for more of the application to be tested, expanding coverage.

Kiwaun:
Developers can also establish which elements are difficult to test or require different locator inputs within the application code. This makes applications more accessible, and easier to use, allowing developers to adhere to best practices. Within regression suites, implementing constant development and deployment of this feature makes it very easy to extend test case coverage and reuse test scripts.

Milton:
Even business analysts can utilize these features. When test building is this simple, business analysts can interact with all elements and follow the most impactful user journeys to ensure functionality and quality of experience. This invites more of the team into the testing process and enables high-quality applications with a flawless user experience.

Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems?    

Milton:
Though finding difficult locators is possible, other methods are much less conventional and require diving deep into the code base. This requires a knowledge of not only the language but also how the page is constructed to locate the proper element.

Kiwaun:
Exactly. Qyrus offers multiple options to locate difficult-to-find elements. Utilizing action types specific and verifying elements by type, or utilizing recorders and inspect mode options to course across screens and select desired elements. These features and functionalities are unique to Qyrus and truly optimize the test-building process.

How do you see Qyrus tools to find difficult locators impact day-to-day operations across organizations?

Kiwaun:
Well, the impacts are truly seen within the test-building process, but the impact can be noted across the whole QA cycle. With more options to find elements and multiple locator options, testing teams have the ability to adhere to best practices and create high-quality test scripts without flaky locators.

Milton:
Exactly, and this leads to fewer test failures and broken scripts. Especially when considering regression suites and pipelines, these failures can be catastrophic, and constantly fixing broken scripts due to shaky locators is an inefficient use of resources. This is why Qyrus offers a range of tools to locate elements, along with locator options to utilize and maintain strong, reusable test scripts.

Kiwaun:
And that is not a one-time, or quick impact, but one that can be seen in every build and execution.

‍

The foundation of automated test scripts is locators and locator values. Primarily, having the option to select strong locators to build your test scripts as well as the proper values to ensure exact functionality. Though difficult to find locators is a generally tedious issue, it can be a weed to kill a garden in terms of regression. In many cases, another brittle or flaky locator type will be used, which over time, and when individual scripts develop into regression suites and enter pipelines, this becomes a significantly larger issue. Qyrus offers a range of features and functionalities for difficult-to-find locators to simplify the test-building process, mitigate unnecessary headaches, and solidify the foundation of test scripts, ultimately optimizing regression suites, pipelines, and the entire testing process. Join us next week as we dive further into different Qyrus features and functionalities that optimize testing and quality assurance.

Low/no-code platforms have been gaining popularity in recent years, especially in the testing industry. According to market estimates, the global low-code and no-code market stood at $25 billion in 2022 and is expected to reach $45.5 billion by 2027. Given that these platforms enable the creation and automation of applications without the need for writing code, they promise to reduce costs, increase efficiency, and make it easier for non-technical team members to get involved in code development as well as testing. But are low-code development and no-code platforms worth the hype? In this article, we will explore the benefits of low/no-code in testing and best practices for using it effectively.

‍How Low/No-Code Automation in Testing Gives You an Edge

‍
‍According to Gartner, by 2025, 70% of the new applications developed by enterprises will use low-code or no-code technologies, a big leg up from less than 25% in 2020. One of the main benefits that have made low/no-code a go-to platform for testing is the significantly reduced time and cost of test automation. Using drag-and-drop interfaces and pre-built templates makes it possible to automate test cases faster and with less specialized skills, saving time and budget and making it easier to scale testing efforts.

The increased efficiency and flexibility offered by low/no-code testing solutions also work in its favor. By automating repetitive tasks, such as test case execution and data management, enterprises can free up time for testers to focus on more complex tasks. Additionally, low/no-code solutions can be customized to fit the specific needs of a team, which can improve overall testing efficiency.

Moreover, by empowering citizen developers and improving accessibility for non-technical team members, low-code or codeless testing solutions also provide a shot in the arm of overworked tech teams. Visual interfaces and simplified processes make it easier for non-technical team members to get involved in testing and contribute to the quality assurance process. Additionally, they can be more scalable and maintainable than custom-built solutions and often come with built-in governance and security features, making it easier to manage and secure testing environments.

‍Best Practices for Using Low/No-Code Automation in Testing

‍
‍To get the most out of low/no-code solutions in testing, it is essential to follow industry best practices. We discuss the top three below.

  1. Identify use cases: Begin with identifying specific use cases where low/no-code can add value. This can help teams focus on the areas where they will see the most benefit from low/no-code automation and develop a clear strategy for implementation. Some examples of specific use cases where low/no-code can add value include:

It is critical to note that while low/no-code can provide many benefits, organizations should carefully evaluate their specific needs and requirements to determine the most appropriate approach for their use case.

       2.  Evaluate different low/no-code platforms: Enterprises should look at factors such as ease of use, scalability, and security features when choosing a no/low-code development platform. Additionally, teams should continuously monitor and evaluate the performance of low/no-code solutions to ensure that they meet their needs and deliver the expected results. This evaluation can be done by considering several factors, including:

It is also recommended to research the vendor’s track record, case studies, and customer reviews. It may be helpful to try a few platforms on a trial basis before committing to one.

      3.  Ensure robust governance and security: This is vital to ensure the safe and secure operation of their testing processes. Here are a few examples of how teams can implement governance and security measures:

By implementing governance and security measures, teams can ensure that their low/no-code solutions for testing are safe and secure and comply with relevant regulations and standards.

‍Staying Ahead of the Game with Qyrus


‍Low/no-code platforms can provide a wide range of benefits for teams in the testing industry. From reducing costs and increasing efficiency to making it easier for non-technical team members to get involved in testing, the benefits are incredible. By identifying specific use cases, carefully evaluating different platforms, and implementing governance and security measures, teams can use low/no-code automation to improve their testing processes and achieve their goals. And Qyrus is a proven and trusted partner for global enterprises looking to achieve these objectives.

Qyrus is a comprehensive, codeless, and highly intelligent test automation platform for all things digital. It efficiently tests Web, Mobile, and APIs with a single AI‑Powered cloud‑based platform that detects and eliminates bugs much earlier in the software development lifecycle. Its codeless, taxonomy driven interface helps increase test coverage and eliminates the need for time-consuming custom frameworks and expensive test infrastructure. Qyrus uses AI to empower everyone. It empowers testers, developers, and business teams to produce high‑quality products for an exceptional user experience.

The pandemic instigated a range of lifestyle changes, as we all know. But as the situation becomes more contained, and we see hopes of normality, we see reactions in these pandemic processes. That being said, there are many things that have changed how we live. One of the most prominent is delivery service. What used to be ordering delivery for dinner after a long day has now extended to groceries, household items, pharmacy items, and more. If you can name it, somebody will deliver it. But when diving a little deeper, the concept is simple. By running a delivery service, the customer expends fewer resources, in this case, time and effort, while yielding the same results, dinner. Meanwhile, the customer has the ability to utilize that time between ordering and delivery to do more. Qyrus CLI commands were developed in the exact same light. While tests are built on Qyrus, pipelines are essential. In the same way, food or goods can be ordered and delivered, test scripts can be executed and returned without ever leaving your pipeline. This week’s Feature Friday is brought to you by Parth, and Steve, who will tell you more about the benefits of CLI commands.

Tell us more about CLI command packages offered by Qyrus and their use cases.

Steve:
CLI commands allow users to interact with, inspect, or execute automated test scripts without visiting the Qyrus UI. With a range of pipeline integrations out of the box and webhooks for required custom integration, these packages allow a range of functionality without ever leaving the pipeline, enabling Qyrus to execute in the background.

Parth:
Exactly, and it goes beyond simply executing. CLI commands have a range of functionality, including allowing testers to execute Qyrus Scripts, update global variables, upload IPA and APK files, delete IPA and APK files, and send reports via email, all through the pipeline.

How do CLI commands impact the overall testing process?  

Parth:
CLI commands really optimize the test execution and reporting processes. Being able to handle a range of commonly required functionality, straight from a desired pipeline, with relayed reports. Centralizing execution and reporting while utilizing Qyrus automated test execution capabilities further optimizes the testing process.

Steve:
Exactly Qyrus adds features such as checking device availability, checking previous reports, seeing a list of all tests, seeing a list of all global variables, executions at a suite level, and running the same test against multiple devices in parallel, among more. All of these capabilities are available within your, already existing, testing environment and pipeline, creating a powerful synergy.

How might CLI commands help testers, developers, and business technologists? What value can this feature bring?    

Steve:
Testers are often the most well-versed in our CLI commands. CLI commands come in handy when you have regression tests and suites that are being scheduled or triggered from a pipeline. In this scenario, the tester would have already developed scripts, even suites, using CLI commands across a range of functionality, enabling the tester to leverage Qyrus capabilities. This makes testers’ lives simpler as the required information is centralized.

Parth:
Developers also utilize this feature and often build out logical pipelines and flows that are then filled by the tester. In essence, developers can build out logical business processes that need testing on a given pipeline. After building out complex flows, testers or developers can associate the Qyrus executions with their accompanying pipeline executions, empowering the client straight from the pipeline.

Steve:
Furthermore, business analysts can also utilize Qyrus to understand more about the testing lifecycle and the generation of large-scale testing flows. Because there is no code involved, and these connections have form-like functionality, they enable business analysts to easily create flows and follow logical processes. After doing so, they have visual and data-driven reports, with video and screenshots waiting for them on the other side. This feature brings together the entire testing team.

Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems? 

Steve:
Other competitors don’t allow CLI commands on CI/CD tools. The usual case is executing CLI commands locally through the command prompt and working from there. With Qyrus, you don’t need to learn anything different. These commands can be executed straight from the pipeline and yield results accordingly.

Parth:
Furthermore, there is the aspect of functionality. Outside of basic commands, such as executing tests, we also have a range of options, including updating global variables, uploading IPA and APK files, among more, all while on the pipeline UI.

How do you see CLI commands impacting day-to-day operations across organizations? 

Parth:
This is a daily use feature as it can be applied anytime execution and update is required. The concept is simple, the more we can centralize, the more efficient the testing process will become. In this case, taking the value of Qyrus and placing it behind CLI commands enables users to do more in a steadfast manner.

Steve:
Exactly, the tester can test the application immediately after the IPA or APK file is finished building by uploading the file to Qyrus and triggering a test execution through their pipeline using the CLI commands. This unifies developing and testing into one flow rather than a separate process and allows teams to shift left, and test earlier within the testing process.

‍

CLI commands allow you to access the power and functionality of Qyrus in a range of different ways, directly from pipelines and defect management tools. This enables more efficient testing where the foundation is Qyrus and relayed directly to the desired tool. By centralizing test data, minimizing the learning curve, and adding an immense value set to an already existing system, Qyrus simplifies automated testing to optimize testing and QA lifecycles. Like food and grocery delivery services have impacted the daily dinner process, Qyrus impacts everyday testers, developers, and business analysts across day-to-day testing activities. Join us next week as we continue our dive into the Qyrus automated testing platform.

‍

 Doing things manually can be meticulous and time-consuming. Manual testing requires a human interface where people are in control of tests and reporting. This can be problematic in some ways, including limiting the organization of tests, limiting test coverage, and costing a high amount of resources. However, what if we could tell you that Qyrus has a way to enhance your manual testing methods? Joining us this week are Jorell, Tim, and Linto to tell us more about the manual testing opportunities through Qyrus.

Tell us more about manual testing through Qyrus.

Jorell:
Although Qyrus is an automated testing platform, we do offer some simple manual testing to be done, as well. This can be done through our Device and Browser Farms in which we allow users to connect to devices such as Android or iOS mobile phones and tablets.

Tim:
For mobile devices, users can add their app to the device through Qyrus or download it from the App Store or Play Store. Screenshots and video playback of the manual test are also provided once the manual test is finished.

Linto:
And besides that, you can throttle the internet and configure the connection. For example, on a mobile device, you can switch between 5G, LTE, and even Wi-Fi networks of different speeds. Even using the physical hardware on the device isn’t out of the question, enabling users to manually turn up and down the volume, lock and unlock devices, or use the camera app.

How can manual testing on Qyrus have an impact on the testing process? 

Linto:
Well, to start off, it expands the usefulness that Qyrus provides beyond just automated testing. This can be a starting point or a bridge for mostly manual testing teams to start the transition to becoming more automated.

Tim:
But next, we also have the reporting aspect. As mentioned before, a complete recording of your session is kept, along with any screenshots you might take. But it doesn’t just stop there. There are analytics and hardware metrics captured from the device during the session. This includes power consumption, CPU, RAM, network usage, and much more.

‍

Now you might see how all of this can be helpful, especially if it stores it all for you in one convenient place. Our reporting capabilities are extraordinary, and you can share reports across your organization and through email. Read more here about our collaborative efforts at Qyrus here and here.

How might manual testing on Qyrus help testers, developers, and business technologists? What value can this feature bring? 

Linto:
Testers are able to run quick manual tests on their applications, and developers also have that same access. Developers might find use in it to quickly check their applications, how they are working, and how they are performing on different devices. It might be more based on unit testing.

Tim:
Business technologists could also perform simple manual tests, allowing them to capture the necessary data themselves. Remember, everything on Qyrus has no code or low code, and that means Qyrus is more accessible to a larger number of people.

Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems?  

Jorell:
Manual testing isn’t something that has a high barrier of entry. If you have a phone and can download an application, you can manually test it yourself on your device. However, that’s just the start of manual testing. To really build up a system capable of capturing a recording of your session, screenshots on demand, as well as simulating different network connections, is something that takes time and a great deal of coding knowledge.

Tim:
On top of that, figuring out how to capture all of those analytics and metrics from the device is not the easiest thing to do. The great thing is that with Qyrus, everything is already set up for you, and requires no setup time afterward from your end. Just an internet connection and a browser are necessary to do manual testing on Qyrus, or any kind of testing on Qyrus for that matter.

How do you see manual testing on Qyrus impacting day-to-day operations across organizations? 

Tim:
Well, without the requirement of setting up and maintaining test infrastructure, lots of things usually handled on a day-to-day basis by testers are now picked up by Qyrus and handled by us. It can be a real hassle to maintain infrastructure as well as make sure all devices are working correctly, updates are being made, and much more.

‍

In conclusion, we can see that there are many ways that Qyrus can enhance even your manual testing efforts. By providing better analytic and metric tracking and report capture, testers can save loads of time. And, as mentioned, since Qyrus is an automated testing platform, this provides the best opportunity for those testing teams that want to transition to an automated testing methodology. Thanks for joining us again, and we hope to see you next week to learn more about our amazing features!

Web test-building turnarounds can significantly set back your time-to-market goals. Such challenges in Web development arise due to the use of custom code and multiple-point solutions for testing.

Eliminate such dependencies and go live faster with Qyrus’ comprehensive automation testing platform. The codeless, taxonomy-driven Qyrus interface can seamlessly improve your Web tests.

For example, testers can rely on its Auto-suggest feature to instantly select the right step action with just a simple description. Or you can enable users to automatically build and import Web tests with Qyrus’ Test Recorder feature.

Watch this 1-minute video to learn about:

Discover more about how you can improve Web tests with Qyrus’ AI- and ML-powered Web application testing platform. Ping us today for more about how your business can overcome challenges in Web development.