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.
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:
Automating repetitive tasks, such as data entry or validation, improves efficiency and reduces errors.
Building custom workflows and forms to support specific business processes, such as incident management or customer service.
Creating and executing test cases for software products without the need for complex coding.
Providing a self-service portal for end-users to access information or request assistance.
Building and deploying custom applications to support specific business functions or processes, such as marketing automation or CRM.
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:
Functionality: The platform should have the necessary functionality to support the specific testing needs of the organization, including features such as test case management, automated test execution, and integration with other testing tools.
Usability: It is vital to have a user-friendly interface, allowing easy test case creation and execution. The platform should also provide visual workflows, drag-and-drop interfaces, and pre-built components to make it easy for non-technical team members to create and execute test cases.
Scalability: The capability to support the testing needs of the organization as it grows is critical. The selected low/no-code software should be able to handle large volumes of test cases and test data.
Integration: The platform should be able to integrate with other tools and frameworks used by the organization, such as JIRA, TestRail, XRay.
Support and documentation: The platform should have good documentation and support so that users can get help when needed.
Pricing and licensing: The cost of the platform should be considered, as well as the licensing model.
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:
Access control: Implementing access controls to ensure that only authorized users have access to the low/no-code platform and its test cases.
Data protection: Ensuring that all test data is protected and that sensitive information is not exposed. This can be achieved through data encryption and secure storage.
Auditing and monitoring: Tracking all activities and changes made within the platform to detect and respond to any suspicious activity.
Version control: Implementing version control for test cases to track changes and ensure that the correct version of the test case is being used.
Compliance: Ensuring that the platform and test cases comply with relevant laws, regulations, and industry standards.
Regular security testing: Regularly testing the platform for vulnerabilities and security risks and taking appropriate measures to address any issues identified.
Training: Providing training to users on how to use the platform securely and best practices for data protection and governance.
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!
“Progress is impossible without change.” These are words spoken by Walt Disney, one of the most culturally influential men to walk the Earth. These are words that Qyrus personifies and that our amazing minds here live by. Change is what makes the world go round, and what keeps us writing these amazing Feature Fridays! This week we are joined by Tim, Jorell, and Linto to go over some changes that are coming to our main page’s dashboard. Let’s hear about how these changes can help you!
Tell us more about updates to analytics and insights on Qyrus.
Tim: Well, for starters, the first thing you might notice is the update to the main dashboard. Previously, we were making little use of the available space on the dashboard. Now, we’ve changed that. You’re able to access information on passing versus failing rates across different projects, the total number of tests built and executed across the team, and a list of tests recently worked on.
Jorell: Furthermore, we’re able to see daily contributions and login activity on a specific team, allowing team members to collaborate more efficiently. Users can also get a quick overview of their infrastructure setup. Lastly, on the page, you’ll see we’ve added a checklist to keep track of things to do.
Linto: We’ve found that overall, this update helps improve the user experience of the platform’s main dashboard, specifically in terms of navigation. We’ve moved the list of services from the main part of the page to be part of a collapsible sidebar, now. That way, the most important things are in your face first.
How can this impact the testing process?
Jorell: Well, in general, there’s an impact in the area of reporting and analytics. There’s a lot more offered to the user to analyze the testing results across projects and teams. Instead of having to navigate all the way to a specific test’s report, we can view those details directly on the dashboard.
Tim: It gives us a better general overview of the testing ecosystem. We can specifically target Web projects, Mobile projects, or API projects on the dashboard. Overall, we can see how the amount of time spent viewing and analyzing a larger amount of reports might be impacted.
What kind of possible improvements or extra features might we see added in the future?
Linto: Adding more customizable widgets is one thing we’ve brainstormed, like providing more choices for the user to make the dashboard their own and tailor it to their needs.
Jorell: For example, one user might not require such a large overview of an entire team or project, but rather something more granular. We want to enable users to customize their dashboards to help them become more efficient.
How might these updates help testers, developers, and business technologists? What value can this feature bring?
Tim: This is exactly where customization would come in handy! No matter what role you play, the dashboard can play to your needs. Testers and developers might quickly see the data on passing and failing rates in projects. But they can also get a quick view of the test infrastructure and its usage. Checklists also come in handy to keep track of tasks directly on the project.
Jorell: Business technologists could use the dashboard for more business-oriented or managerial tasks, such as checking on the health of projects and testing various applications. They can also get a good overview of team contributions and activity.
How do you see these updates impacting day-to-day operations across organizations?
Jorell: Well, in general, I would give a better overview of operations, allowing users to spend less time navigating around the platform to view specific reports and results.
Linto: A user can see the already recently worked on tests, and in that way, they can be prevented from recreating a test that is already existing. Then, they can just clone and reuse it.
Although nothing astronomical, these updates provide proof that Qyrus is an ever-evolving platform, constantly looking to improve the lives and day-to-day of testers using it everywhere. And besides that, we’re committed to keep improving to help you achieve your testing goals more efficiently. Progress never stops, and neither does Qyrus. Thanks for joining us this week, and we hope you enjoy the rest of your Friday!
As David Copperfield once said, “The magic lives in the performance!” Although we all know David Copperfield to be a magician, not a tester, the same can be said in the testing world, as well! Performance testing is such an important and integral part of testing an application. Measuring the time it takes for your webpage to load or the time it takes for some tasks to be completed is included in performance testing. However, today, we are here to talk a little bit about the performance testing of APIs. But, wait, there’s more! We’re going to be talking specifically about the performance testing of end-to-end API processes. Here to deliver more information for us today are our good friends Parth and Steve; without further ado, let’s delve in!
Tell us more about end-to-end API performance testing offered by Qyrus and its use cases.
Steve:
We have seen many people take advantage of our API Process Testing service, in which we enable users to stitch or chain together API tests in order to make a complete end-to-end flow. This gave users the kind of holistic testing they were looking for. With Qyrus, we can check the functionality of each individual API, but with this, we can also check that these APIs work together exactly as they should.
Parth:
Now, being able to test this process’ performance is a big step forward. Previously, we were able to see the basic response times for each API call in a process, but now we can get a much more granular view that we were never able to before.
Steve:
Exactly. We are, for example, able to get values back for the response time of the entire API flow, the response time per API, as well as the status code per API. This is tested over a certain thread count, or users accessing the same resource—or in this case, flow—concurrently.
Adding more tools and functionality to Qyrus is a never-ending task here. Going further into process testing, you can learn more about our individual API performance testing here from another Feature Friday. If interested, here are two more about web performance profiling and mobile performance profiling.
What is end-to-end API performance testing’s overall impact on the testing process?
Parth:
In general, the impact we see is a larger amount of test coverage. This is because the user is able to reuse these API Process tests that they created for functional purposes, but instead run them to test performance.
Steve:
Furthermore, users can now, in a literal sense, perform performance tests on these processes. Prior on Qyrus, you had to run performance tests on each functional API in order to get an idea of what the performance metrics were like. But still, you had an incomplete picture.
How might this feature help testers, developers, and business technologists? What value can this feature bring?
Parth:
Like Steve previously stated, a tester can now actually run performance tests across a whole process or end-to-end flow and can see the bigger picture, you might say.
Steve:
Beyond that, developers could test max stress levels for their APIs when they’re all connected in a flow and make adjustments from there. This can be helpful at catching performance flaws early on in the development process.
Parth:
And for business technologists, they can get better information about performance at a faster pace. These test results can be shared, emailed, or even downloaded.
Collaboration, although not an explicit feature on Qyrus, is a key quality that Qyrus upholds across the platform – whether that be collaboration during the test building phase, collaborating on test executions, or sharing reports and collaborating with other teammates that way. You can learn more about our collaborative efforts in one of our previous Feature Fridays.
How do you see this feature impacting day-to-day operations across organizations?
Steve:
Well, to start, as we mentioned before, users are now enabled to run these types of tests across entire end-to-end API flows. This would mean that day-to-day, testers no longer have to run individual process tests over and over again. Now, they can do it all from one place, and that includes functional testing, as well.
Parth:
Furthermore, no prior coding knowledge is required. It’s all been simplified down to a no-code experience where any user can understand what’s going on. As a last point, all tests here are just reused from our API Functional Testing section. Nothing has to be recreated, just reused and modified if necessary.
What might we expect to see improved about end-to-end API performance testing?
Steve:
Well, we’d like to see more performance metrics added for the user’s benefit. Things are still in progress here, and improvements never stop coming to the platform as a whole.
Parth:
Right. Some of these metrics might include ones that are currently present under our “Advanced Metrics” under API Performance Testing. This might include response latencies over time per API, hits per second, transactions per second, active threads over time, and a general summary tab where we can see max, min, and average response times and more.
If the number of features that we have across the platform isn’t magical, then I don’t know what is! Well, besides David Copperfield, Oh, and Fridays, those sure are magical! Speaking of, it must be Friday, since you’re reading this. Please have an enchanting weekend and enjoy the time off with family and loved ones. Don’t worry, though, next week we’ll pull some more fantastical features out of our hat for you to learn about! See you next week on our next iteration of Feature Friday!
There’s always room for improvement. That is true for just about everything in life, and that does not exclude testing. Innovation never sleeps, and testing has an ever-moving goalpost, so strive for continuous improvement rather than perfection. Every week, we post about some new feature or set of features that can help improve your testing in some way, and this week we are going to talk about our recent improvements to API test building on Qyrus. Joining us today are Adhiraj, Amy, and Jorell from our Chicago office to tell us more.
Tell us more about the recent updates to test building in the API solution.
Adhiraj:
The biggest update comes to our API Process Testing section. There’s a new UI update that has completely revamped how API process tests are chained together. This improves the user experience of those building these tests by making it simpler for them to see what connections are made.
Amy:
The goal of the new update was just that: to make things simpler. Instead of requiring the user to configure connections between APIs on a separate page. Users would go back and forth between two pages, and with this update, everything is done on the same page and in one place.
Jorell:
On top of that, a new navigation button has been added to aid in navigation between the different sections in API process testing. This helps reduce the number of clicks it takes to get to a certain page.
What is the overall impact these API updates have on the testing process?
Adhiraj:
Overall, these improvements help reduce the amount of time a user has to spend building these process tests. Similar to how going through a doorway and into another room can make you forget what you were going to do, the same can happen when it comes to navigating pages on a website.
Jorell:
Furthermore, these improvements can help improve test coverage through a better user experience and a reduced amount of time taken to build out a process test. That means testers can cover more at a faster pace. This also leads to a reduced amount of effort put forth to chain everything together in a large flow.
How might these API updates help testers, developers, and business technologists? What value can this feature bring?
Amy:
Well, for testers, their entire job just got easier. Making a process test is already not that difficult to do on the platform, but with these improvements and further down the line, testers should expect more smooth sailing ahead.
Adhiraj:
Because of this tool, the updates made to the test building mostly revolve around the tester, as this is a platform built just for them. However, developers can use API process testing to perform basic unit tests of the systems they build. The updates also help improve their lives when doing so.
Jorell:
In general, a business technologist would be able to better understand the connections between the APIs as well as how the data transfer is happening. Again, having to navigate from one screen to the next can be a hassle, and for less technical people, it can just make things downright hieroglyphic.
Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems?
Amy:
One big differentiator from some competitors is our completely cloud-based approach. Everything can be done from a browser and from anywhere, without anything being downloaded. But to further that, the whole point of these updates is to make our test building simpler than others.
Adhiraj:
In a traditional sense, a good deal of coding knowledge would be required in order to make a process test similar to what we’ve done here. And on top of that, it’s still a hassle, unless time is taken to build out a UI for a similar system. Even then, the time and resources put in just about outweigh the benefits coming out. Maintenance and upkeep are another problem, then.
How do you see these improvements impacting day-to-day operations across organizations?
Jorell:
Keeping testers on one page, easier navigation, better connections for better understanding, and reusability are some things that will impact a user’s day-to-day when using this platform, specifically the API section.
Amy:
Well, simply put, making the whole process a degree easier. Less time and effort means higher productivity and happier workers.
Adhiraj:
And on top of all that, there are about another 10 or so features that build off this one, taking things to another level with each one, making things even faster and more efficient. And we here at Qyrus never stop coming with more.
Improvement: whether that be faster executions, more robust reporting, or better test building, Qyrus is here to improve it all. API process testing is just one stop on our route to improving the overall user experience here on Qyrus. Besides just improving the user experience, we’re doing so much more! Come on and sign up for a Free Trial to see for yourself. Join us next week to learn about more improvements to be made in your testing ecosystem!
The holiday rush is officially over! With this holiday season now in the rearview mirror, it’s time to look forward to the road ahead and get prepared for an undoubtedly busy 2023. But don’t worry, Qyrus isn’t throwing on the breaks anytime soon when it comes to features! This week, we are joined by Daniel and Joyal from our Chicago Qyrus team to learn more about some new mobile native locator strategies that have been introduced to the Qyrus platform. Without further delay, let’s race into this topic!
Tell us more about this capability offered by Qyrus and its use cases.
Daniel:
Qyrus mobile testing now has support for 3 native locator strategies when users are building out their test scripts. There are two that are supported for iOS—class chain and predicate string—and one for Android: UIAutomator.
Joyal:
This is helpful for those mobile testers who are more experienced. Native locators can speed up test executions by improving the performance of locating the element. There are elements out there that cannot be found by using ID, name, accessibility ID, or XPath locator types.
Daniel:
Even though this strategy is the most common out there and platform-agnostic—that is to say, it works for both iOS and Android devices—it can be the most time-intensive choice. By choosing a native locator strategy, a tester can leverage the flexibility that an XPath can provide without incurring a performance penalty.
For the reader’s benefit, we have provided an example below:
Example of XPath on iOS: //XCUIElementTypeOther[@label=’login’)]
As a class chain, this XPath can look like this: **/XCUIElementTypeOther[label matches “login”]
But using a predicate string, it could look like this: label matches “login”
What is the overall impact this might have on the testing process?
Daniel:
We can see this having an impact during the test-building phase when users are creating and building up their catalog or suite of test scripts for execution. This can help expedite the test-building process since, to an experienced mobile tester, using something like a predicate string is much quicker than having to get an XPath for every element.
Joyal:
Not only that, but since we see faster run times, we can say there’s a definite impact on test executions. The new native locator strategies provide an overall speed boost to the testing process as a whole.
Qyrus is always looking to push the limit when it comes to developing new tools and strategies to help enable better testing across the board for everyone involved. This is not limited to different levels or types of testers, but also to less technical personnel.
How might these new native locator strategies help testers, developers, and business technologists? What value can this feature bring?
Joyal:
Well, as we mentioned before, an advanced tester might find the most use out of this feature. In general, it makes their testing experience easier. But besides that, using a predicate string also makes it easier for less technical users of Qyrus to understand what is being searched for. Seeing “label matches ‘login’” makes it much easier to understand what the test is looking for than a long, exhaustive XPath.
Daniel:
And for developers, they’d find use in this, much similar to a tester. It would make their unit testing and quick tests much easier to create, run, and maintain in the long run.
Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems?
Joyal:
There are a few competitors out there that do offer all these strategies already, but on Qyrus we are striving to make these strategies more usable for both experienced and newer testers.
Dan:
And when it comes to using these strategies outside of Qyrus, anyone can really do it when they’re scripting their own automated tests. It’s just that everything has to be done through code, whereas on the Qyrus platform, everything is no-code and simple to use.
Our features on Qyrus have the one goal of making testing more efficient, but that can be done in several ways. Speeding up the time it takes to build and execute tests, providing more insight into reporting, and enabling more intuitive test building are just some ways we are actively working to make testing more efficient.
How do you see these impacting day-to-day operations across organizations?
Dan:
Speed is really the main benefit of using these strategies. But there are some other advantages that can help to even further speed up day-to-day operations. “UIScrollable” can be used to automatically scroll the element if it is not in view, for example. This functionality is built into the locator strategy and is not possible with other strategies.
Joyal:
To further the topic of speed, the time taken to find elements during iOS testing is significantly reduced. For example, what might take an XPath strategy of 2.8 seconds to find an element can be done in 1.8 seconds with a predicate string and even quicker at 0.7 seconds using a class chain.
That wraps up this week’s Feature Friday. The drive for new and innovative testing strategies is greater than ever, and slowing down now could mean getting into a wreck in the future, so help protect yourself by switching to Qyrus as your testing platform! We hope that this weekend you take some time to slow down, stop, and enjoy some time off from your busy, racing weekly schedule. And then on Monday, maybe sign up for a Free Trial and check us out! Thanks again!
Notifications are everywhere in a person’s daily life nowadays. As per research done by the Pew Research Center, 97% of Americans own a cell phone of some kind, and 85% of Americans own a smartphone. This is astonishing considering that the last research done 10 years ago concluded that only 35% of Americans owned a smartphone. Not only that, but a third of high schoolers now own a smartphone.
With the evidence laid out in front of us like that, it’s a no-brainer that everyone everywhere is constantly getting notifications. And it’s about time that Qyrus joined in on that trend! Previously, we have talked about how we can give notifications via email to users to notify them about test executions, but now, we have a new feature that can enable Qyrus notifications in Teams and Slack channels! Joining us today are Milton and Kiwaun who’ll give us more insight into this topic.
Tell us more about the integrations with messaging apps offered by Qyrus and its use cases.
Kiwaun:
Yeah, so, basically what this feature enables users to do is set up Qyrus to deliver notifications to Microsoft Teams or Slack channels. This is a really simple feature, but one that can be considered super important for testers and developers.
Milton:
Email notifications are already a thing on Qyrus, but we all know how bloated our inboxes can get. Getting notifications for your Slack or Teams channels is much more convenient as a whole. That way, entire teams or multiple stakeholders can be notified instantly about test results. And lastly, if someone has those messaging apps on their mobile devices, they’ll also get these notifications on the fly.
Getting notifications on the fly is always helpful. Here at Qyrus, we seek to help. That is, it helps make testing more efficient, helps testers test smarter, and helps testers stay up-to-date with their testing landscape.
How might the integrations with messaging apps impact the testing process overall?
Kiwaun:
This feature only really has an impact on the reporting side of testing. The whole point is to get those notifications of test executions straight to your channel.
Milton:
But, overall, it can help in terms of effort reduction. Testers don’t have to manually log into Qyrus in order to view the report of an execution, but rather can just get that quick view of it as a notification in their Slack or Teams channels.
Like many features on Qyrus, this feature can be utilized by more than just testers. Qyrus helps to enable a better understanding of testing and the testing landscape that a company has by making everything more digestible when it comes to test building and even reporting and analytics.
How might this feature help testers, developers, and business technologists? What value can this feature bring?
Milton:
Obviously, testers would use this feature to get notifications straight to their messaging app channels, but developers can utilize this as well when they build and execute their unit tests on Qyrus.
Kiwaun:
Business technologists would get great snapshot information from these notifications, as well. They can stay up to date without having to get into the nitty-gritty of things or even navigate their way through the platform. They can get a great overview of what’s going on, all on the go.
Qyrus’ goal is to improve the day-to-day operations of everyone involved in the testing process. Our features are meant to make a lasting impression on how testing is done in an organization and impact how these action items are performed.
How do you see this feature impacting day-to-day operations across organizations?
Milton:
More than anything, this feature provides convenience so that the user does not have to log in and manually check tests every time they need to. That can be a waste of time, especially over a longer period of time.
Kiwaun:
On top of that, there are configurations that can be made that will help focus on what kind of notifications you will receive from Qyrus. This means that this is a tool for everyone.
Notifications surround us in almost every aspect of our everyday lives. Furthermore, notifications, in the future, will surely play an even larger role, as we can see a shift in cellphone and smartphone usage amongst Americans alone. Regarding Qyrus, we seek to further expand our abilities to notify users of their testing efforts and landscape. This is just one way in which we seek to further our capabilities. Thanks for joining us this week for Feature Friday. We hope you join us next week for more information on our myriad of features!
The year 2022 is now coming to a close and, with that, we come with our final installment of Feature Friday for 2022, as well. Over the last year, we have talked about numerous features and qualities of Qyrus that highlight just exactly how we improve testing. And, if you’ve been paying attention, you’ll realize that Qyrus is chock-full of useful tools and capabilities that improve all aspects of testing, ranging from the test-building phase to the test executions and, in the end, the reporting and analytics. And, along the way, we’ve made several small and large quality-of-life updates that aim to improve the smaller but still important aspects of day-to-day testing. So, today, we will take a stroll through memory lane and recap and highlight some features that augment different aspects of testing.
Features That Have Impacted Test Building
The aim of Qyrus is to enable testers to build tests in a more efficient manner. By reducing the amount of time it takes to build tests, the testing process as a whole has reduced its lifecycle significantly. There are many ways that we can help achieve this goal, but to highlight a few:
Mobile and Web Test Recorder
When it comes to building test scripts for mobile applications, Qyrus has a mobile recorder that enables users to build tests by recording user actions performed on a mobile device. It’s super simple and intuitive to use and is enabled by the click of a button. More advanced actions, like performing verifications, can also be recorded during this process. More information about our mobile recorder can be found here in this edition of Feature Friday.
And very much like our mobile recorder, Qyrus also has a web recorder. It does all the same great things that the mobile recorder does, allowing users to have test scripts built around recording their actions on a web page. The Feature Friday for web recorders can be found here and provides more information.
Inspect Mode
Qyrus also enables users to inspect elements on a mobile application. This means that more precise test building can be done. Instead of recording user actions, enabling the inspect mode gives users the ability to get locators of specific elements, as well as the ability to verify the existence of elements on a page. To learn more about inspect mode, you can find its Feature Friday here.
Reusing Test Scripts
Building, rebuilding, and rebuilding again is no way to go about creating your suite of test scripts. Qyrus enables users to reuse test scripts in multiple ways. This empowers testers to spend less time recreating some script that already exists out there. This can also help empower collaboration and teamwork. Click here to learn more about how reusing test scripts can help speed up testing.
Features That Have Impacted Test Execution
Once test building is out of the way, the continuous execution of test scripts is the next thing on the list. Comparing traditional Selenium testing to Qyrus is like comparing night and day when it comes to test executions. Qyrus already has all that one might need, and we’re here to highlight a few below:
Parallel Testing
Qyrus enables users to execute two tests at the exact same time. This already doubles our efficiency when it comes to test execution, but Qyrus can go even beyond that. Parallel testing in Qyrus gives users the ability to execute as many tests at the same time as their concurrency allows. This means that, if one has the resources, one can execute 5, 10, 20, or even 50 tests all at the same time. This means that Qyrus can scale to the needs of the client. Read more here about parallel testing.
Test Data Management
Test data management in Qyrus brings another testing tool into the fold. No longer do testers have to manage or create their own test data—or perhaps use a third-party tool for that—but instead it can all be done right on the Qyrus platform. Create test data manually, have Qyrus synthetically generate data for you, or grab data from an API call or database query. Click here to learn how test data management can augment testing today.
Parameterization
Utilize data-driven testing on Qyrus through the use of our parameterization feature. By selecting to parameterize specific steps in a script, a tester is able to take one script and have it cover multiple scenarios. As a simple example, imagine having a login script that can be parameterized to test not just one login, but the login of dozens or even hundreds of other accounts into the system. Through the use of test data management, parameterization becomes an even more versatile tool. Learn more about parameterization here.
Features That Have Impacted Reporting and Analytics
The most important thing, arguably, is how the reporting is generated by a testing system. Whether that be manually collecting screenshots of reports, keeping some spreadsheet to track testing progress, or using some other test management tool, reporting can oftentimes be fragmented and not adequate. On Qyrus, we automatically generate sharable reports that come with step-by-step analytics with screenshots and video evidence. However, that just scratches the surface as to what capabilities Qyrus has when it comes to reporting and analytics. Let’s take a look at a few features that augment this area:
Comparing API Reports
Although simple, this tool can be extremely useful in certain situations. Comparing API reports is a feature that Qyrus implemented to make life a bit easier for users who must constantly go back and forth between API reports. Although a small task, it can become rather tedious through repetition. This is a great example of how Qyrus takes into account user feedback and ways that we can help improve our platform to become even more all-encompassing when it comes to testing. Learn more here about comparing API reports and hear more from our team.
API Monitoring
Keeping up with the health of APIs, especially when there are a lot of them, can be quite a challenge. Ensuring that response times are in an acceptable range, that the API doesn’t go down every now and then, and that the responses are correct are all things that can take up a lot of time Qyrus has a useful tool that can do all of that for you and provide you with notifications about the health of your API. Read here about how API monitoring helps testers today.
Performance Profiling
Last but certainly not least is performance profiling. Qyrus is able to get performance profiling metrics for your mobile applications during test executions. This gives better insight for the tester into how an application might perform on different mobile devices or while performing different tasks. A slow or clunky application is not a good one, and Qyrus can help ensure the opposite of that for your applications. Click here to read more.
I hope that that stroll through memory lane helped jog your memory about a few of our testing capabilities and features. We’ve just scratched the surface here when it comes to that, however, and we still have so many more features to talk about in future editions! Qyrus is an ever-evolving platform that hopes to meet the needs of every tester across every type of testing. We’re like a one-stop shop when it comes to testing. Next year, we’ll touch on new features like Qyrus Bot, new updates to analytics and insights, as well as new updates to web, mobile, API testing, and so much more! New features are always just around the corner with Qyrus.
Thank you for joining us for our final edition of Feature Friday for 2022, and we hope you will join us for more next year! Happy holidays to everyone on behalf of the Qyrus team!
