Over the years, time and time again, we have seen old, archaic work processes fall due to our progression in technology. Over time, everything has become more streamlined. Everything in one shape or form is faster or more efficient; whether it be in how the thing is made or processed to how it helps consumers. Software testing has been no exception to this rule, either. Over the years, we have seen software testing go from manual testing processes to automated, and now we are seeing a boom in codeless automation. Joining us today to talk more about the subject of codeless testing and how we do it on Qyrus are Steve and Brett from our Chicago team.
Tell us more about action types and what is offered by Qyrus. Also, mention their potential use cases.
Steve: First things first, actions in Qyrus are things that can be performed within a test script. This can be a thing such as mouse events where you would click on an element on a page, or input events where you set a text field on a page. Using actions, we build steps to our test scripts in Qyrus.
Brett: Steve already mentioned a few of the different action types we offer… mouse events and input events. But we offer so many more, including conditionals, alert handlers, browser window actions, and verifications, which lead to our dynamic data handling. Whether team members are new to automation or experts, these action types are simple to use, and comprehensive, allowing for a range of testing activities.
Steve: Under conditionals, you can have an if condition nested inside your test script. For example, if when the test script starts, you are already logged into the application, you can tell the script to first log yourself out before proceeding with the rest of the script. We can even do things like embedding test scripts within other test scripts using our action type, “execute the test case.”
What is the overall impact Qyrus has on the testing process through going codeless and using these abstracted action types?
Brett: I mean, honestly, the main impact is within the test-building process. Again, since we are essentially taking coding out of the equation, we can enable faster test building. There is a virtually nonexistent learning curve when transitioning to Qyrus, and with every release, we seek to simplify testing even further. Building out steps becomes as simple as filling out a form, as Qyrus displays all required fields per action type to be filled.
Steve: Yeah, overall, we see a large amount of time and effort saved when it comes to test building. You don’t need to know how to code at all in order to use our test-building system.
If you would like to learn more about how Qyrus is simplifying test building, you can read more about our web and mobile recorder tools that help enable testers to quickly and efficiently build out test scripts. Qyrus is all about scale, as well, and you can learn more about how we can then parameterize these tests to further scale our test coverage as well.
How might how Qyrus is changing test building help testers, developers, and business technologists? What value can it bring?
Brett: Well, again, since we are essentially trying to simplify test building, testers, devs, and business technologists would all find the action of test building more accessible. This especially goes for newer members of the team and newer testers in general.
Steve: Yeah, we’ve seen inexperienced users pick up testing in Qyrus very quickly. This goes for new testers, like Brett mentioned, but even non-technical people. And the wide array of action types pleases our testers at the forefront of automation and innovation, promoting the highest levels of test-building efficiency.
Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems?
Brett: Well, many competitors also use action types like we do here on Qyrus. However, they’re often geared toward testers and more technical users who already have technical knowledge. They use technical terminology, behind a complex user interface requiring a strong technical background or a difficult learning curve,. Whereas Qyrus designed these actions with keywords that would be easily identifiable for any user, and a simple-to-build, form-like user interface recognizable by all backgrounds, not only technical.
Steve: Right, and if you were to not use some competitor platform but rather code this out, you would have to build a framework from the ground up which requires immense overhead and specified engineers and technical resources. And what happens if a key developer of the framework or a large portion of the team happens to leave the organization. The issue with getting new members becomes terrifying. Not with Qyrus.
How do you see building tests like this impacting day-to-day operations across organizations?
Brett: So, I think we’re almost sounding like broken records, but the whole codeless building is really revolutionary when it comes to test building. We’ve built tests using Selenium and it definitely takes longer to set up and code out than it does using Qyrus. And that’s not even including the infrastructure and other pain points that are mitigated along the way
Steve: And, since all of the actions are put into simplified terms, you know what does what without having to constantly refer to documentation. It was always a pain having the documentation up in another tab or on a second screen and having to reference over. We aim to keep users going and keep the test building flowing.
And with that, we wrap up this week’s Feature Friday. We hope you learned a few things about Qyrus and how it can help enable faster and more efficient test building by leveraging our codeless test building. Action types are at the core of our codeless test building. As technology progresses, testing becomes ever more important and making sure quality assurance is held at a high standard can be achieved using Qyrus.
RPA Definition
Robotic Process Automation (RPA) is using technology and AI to mimic back-office human tasks. Through robotic software, RPA is able to perform repetitive tasks to help streamline business activities. RPA emulates human processes and can complete tasks like fill out forms, copy data, put data into new fields, etc. These features can have a range of applications within many different industries that deal with repetitive tasks.
RPA can either be end-to-end automation without human interaction at any step, or it can act as a helper and automate steps that don’t need human intervention. Manual processes like entering repetitive data or code are common places for inefficiency and human error, so utilizing RPA can help reduce errors and make testing more efficient. Why waste human labor on repetitive tasks, when a robot can do it for you?
RPA Example: Banking
In the rise of mobile banking, Robotic Process Automation Technology plays a key part in ensuring that banking features are working as efficiently as possible. Customer experiences are typically a critical part for success in many financial institutions. Users want to access their banking information and use banking features without dealing with setbacks and problems. Financial Institutions are often known for specific regulatory requirements, lengthy manual processes, and setbacks which result in poor customer service and lengthy service times.
RPA can help simplify banking activities and help enhance the overall efficiency for both the user and the business. The customer experience is crucial for any business, so it’s important to put proper RPA technologies in place to enhance accessibly and reduce any problems in relation to customer service.
Many industries, including banking, are adopting RPA tools to automate repetitive, time-consuming tasks, which is allowing many industries to enhance efficiency while reducing overall costs and time. RPA also has applications for other industries like: Manufacturing, Medical, Government, Education, Retail, etc. RPA can help simplify many aspects of business, no matter what industry or department.
What Features Can Help Improve RPA?
Qyrus offers a range of features and AI automation tools that help streamline testing capabilities. Testing is an area of business that is typically time consuming and repetitive, which is the perfect place to utilize RPA. Manual testing takes a lot of resources which can cause delays in the release of new products or processes. Some Qyrus features that utilize RPA include:
Healer: An advanced AI tool that users can enable before they execute their test scripts. It helps prevent test flakiness and brittleness. Through the use of Healer, testers can say goodbye to the days of scratching their head wondering why their working tests break. If Healer detects a failing test it attempts to remedy the cause and provide the user with feedback as to what went wrong during execution.
Rover: An autonomous exploratory testing solution using machine learning that is capable of generating tests without any human interaction. Rover can generate test steps, check for crashes, and even ensure reliability of apps.
Hawkeye: A tool that creates a difference map of Rover explorations for two different versions of an application. Easily comprehend added, changed, or removed screens and transitions across two versions of an application. Testers and developers no longer have try and remember how a process used to function.
Component Testing: Test business processes across different platforms (web, mobile, API) and applications (internal, external, CRM, finance, etc.) by reusing tests built in other Qyrus Test solutions. Using the component testing feature, testers can create complex and comprehensive tests that cover a wide range of cases and scenarios, all managed from one spot.
Qyrus is an ever-evolving and ever-expanding platform that seeks to continue to push the limits and boundaries of its current testing capabilities. Many more features and solutions exist on the Qyrus platform that lend a hand to RPA and automation as a whole.
Benefits of Robotic Process Automation
These are just a few of the automation and AI features that can help improve RPA. Robotic Process Automation is a stepping stone towards digital transformation. Manual processes, without the help of automation, are typically areas where inefficiency and human error occur.
By utilizing RPA, businesses can improve their capabilities and enhance efficiency so that time is not wasted in the testing phase. Instead, with the freed-up time and resources business can focus on creativity and other important business tasks that actually require human intelligence and decision making. Adopting RPA into everyday business tasks has many other benefits that include:
Increased Productivity: By automating tedious tasks, Testers can focus on more important business matters because automation can do it quicker and more accurately than humans can.
Consistency: Through automation, repetitive tasks can be performed consistently every time so businesses can reduce the errors that are typically found in manual testing.
Reduce Costs: Repeating manual tasks are much more time consuming compared to when they are automated. When a robot is doing these tasks quicker, it gives more time back to employees that can be more productive and creative in other important areas.
Produce Products Quicker: Tests scripts can be created at an accelerated rate with more accuracy. This means that products or services can be tested quicker and can be released to market much quicker compared to manual testing.
Reduce Risks: Automation and AI can identify, fix, and change errors without the intervention of a human. Repetitive tasks are typically where errors occur, so when RPA is involved, the errors are reduced and more quality tests are being created at an accelerated rate.
Conclusion
Robotic Process Automation has many benefits and when integrated correctly can greatly enhance overall business efficiency while reducing time and money. RPA is very accessible and has applications for every industry, even the smallest of business. Starting to automate early and utilizing RPA throughout the business process will set them apart from the businesses that ignore automation. RPA is the stepping stone to digital transformation and will greatly help all businesses in the long run.
Chicago knows this time of year. The temperature begins to pinball, foreshadowing the long-awaited summer. Regardless of fandom, team, or even interest in the sport, there is a buzz felt in the air as the collective whispers grow to bedlam, “Take me out to the ball game!”
Let’s ponder for a moment, what makes a ballgame so special? Is it the bright lights that glisten on the freshly trimmed grass, is it the faint aroma of hot dogs and popcorn that tickle the nose, or is it the flood of fans and friendly faces singing in unison during the 7th inning stretch? A baseball game is an accumulation of hundreds of individual pieces, of which the functionality is essential to the heart of the ballgame. This week’s Feature Friday is brought to you by Brett and Linto who will be discussing CI pipeline integrations, which, believe it or not, are more similar to a baseball game than you may think.
Tell us more about the CI pipelines and integrations offered by Qyrus, their use cases, and their impact on testing and QA processes.
Brett: I think a baseball game is the perfect example to think of when considering a pipeline. A baseball game has hundreds of different components like concession stands, the ticket booth, security, restrooms, seating, crowd management, the game itself, and more. A quality baseball game boils down to the optimization of all these processes.
Linto: Consider an online store or a delivery service mobile application. They have to handle customer requests, list their services and products, build a payment structure, etc. Pipelines allow users to build out complex scenarios, often testing multiple services and applications in sequence.
Brett: Think about it this way: prior to pipelines, testing the “ballgame” would require isolating and testing each individual component. Imagine making sure the hot dog stand was functioning properly, then the ticket booth, then the lights one by one. With pipelines, you can automatically trigger all of these pieces to be tested in sequence from a centralized location. Instead of testing all these processes individually, build different user journeys throughout the ballpark that encompass and test many of these processes.
What is the overall impact on the testing process when integrating a CI pipeline with Qyrus?
Brett: This feature largely impacts the testing process. Conceptually, any development, ranging from feature updates to entire application releases, can be integrated into pipelines during development. Then, anytime code is pushed, these pipelines can trigger these scripts to execute. This provides robust reports of comprehensive application functionality upon all releases.
Linto: Offering out-of-the-box pipeline integration with Azure DevOps, Bitrise, Concourse, Jenkins, and Team City, we have integrations with industry-leading CI/CD tools. Furthermore, as a cloud-based solution, creating custom integrations is easily achievable and has been implemented for past clients.
Brett: We see this as a powerful feature that promotes functionality and quality assurance upon the development and deployment of code. Comprehensive testing that is reusable and can be automatically triggered to verify application functionality immediately upon code enhancements and alterations can optimize the testing and QA lifecycle.
This is starting to make sense. Thinking of the ballgame as one big application, these pipeline integrations allow you to test entire “games” at a time, rather than having to isolate and test individual portions of the game. Connecting automated testing to your CI pipeline is a powerful feature in terms of usage and coverage, so we had to ask about similar features within the market.
Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems?
Linto: Testing solutions often offer integrations with common pipelines. That is not a unique feature. But, the silver lining usually sits within the functionality of these integrations. Qyrus enables test suites to be allocated as build steps within pipelines. Upon execution, Qyrus provides robust visual reporting and actual data feedback.
Brett: That’s correct. As many integrations allow you to run and provide a general pass/fail indicator, Qyrus goes the extra mile to offer step-by-step data, screenshots, and general test metrics, all located within comprehensive testing pipelines.
We’ve established the relevance of this feature and some unique qualities in relation to competition and similar industry tools, but testing and QA teams have multiple personas and skill sets that need addressing.
How might CI Pipelines help testers, developers, and business technologists? What value can they bring?
Brett: Testers find this feature useful because they integrate Qyrus scripts into build steps within pipelines. With robust pipelines testing user journeys and edge cases, Qyrus’ test building and infrastructure enhance the testing process and produce reports straight into already built pipelines. This mitigates the requirement of any migration, re-building, or custom requirements. Simply create these build steps and have on-demand, robust test execution and reporting at your fingertips.
Linto: Developers see the direct and indirect benefits of this feature. As developers build and release new application features, they can simultaneously test these features, import, and integrate these scripts into pipelines. This not only promotes a shift left in the quality assurance lifecycle but also mitigates the need to rebuild tests on a separate platform. Build out tests and pipelines once and have the ability to execute upon command.
Brett: Even if developers are isolated from the testing and QA lifecycle and don’t directly work with the feature, they can find confidence in the fact that upon commit of new applications, updates, and features, the pipeline’s scripts are automatically triggered for comprehensive functionality and UI testing.
Linto: Business technologists also find value in the visual aspects of this feature. Being able to follow different pipelines and journeys with clear pass/fail indicators and screenshots for each step allows business analysts to fully understand application functionality and easily navigate business requirements, release cycles, and other required business processes.
A very interesting use case across different personas, this feature is valuable across QA and testing teams.
How do you see CI pipelines impacting day-to-day operations across organizations?
Linto: Simple test building, comprehensive execution and coverage options, and robust reporting, all quickly integrated into existing pipelines, mitigating any excess resource requirements. I think this feature speaks for itself.
Brett: And with integrations across Web, Mobile, and API testing, the feature becomes more relevant as testing demands increase. Considering clients with hundreds of tests, prior to pipelines and easy integrations, each script would have to be executed manually or scheduled on our platform. Doing this, every execution can add up to extensive resources and time.
That concludes this week’s Feature Friday with Brett and Linto about CI pipeline integrations offered within the Qyrus testing platform. After going through the purpose of pipelines, the relevance of integrations, and how Qyrus integrations are both unique and impactful within the testing and QA lifecycle, we can conclude that applications are not far off from baseball games. Utilizing Qyrus’ CI pipeline integrations can optimize the experience of all users—or, in this case, make a ballgame into a memory.
What do testers do when they need to cover dozens or even hundreds of different scenarios in a short amount of time? Writing a new test script for each scenario is a time-consuming process and quite literally a maintenance nightmare. Well, what if we told you there’s a solution to our problem, and that solution is called data driven testing? Some of you might already know a bit about it, but Qyrus’ implementation of data driven testing includes parameterizing certain steps in a test script to then allow data to be fed into those steps. We call this parameterization. And the last time we talked about parameterization was nearly half a year ago in one of our initial Feature Friday blog posts. Today, we’re joined by Adhiraj and Kiwaun to hear about the updates made to parameterization.
Tell us more about the parameterization offered by Qyrus and its use cases.
Adhi: Parameterization on Qyrus essentially allows users to utilize data-driven testing in their testing process. Test data can be pulled directly from a file or table that will then be fed into the corresponding test steps in the script during runtime.
Kiwaun: Overall, it allows users to test a large amount of scenarios using a single test case, promoting reusability as well as easier maintenance. Each row that’s in the datasheet represents a different test case.
For those that have read the previous post mentioned before about parameterization, we’d encourage you to read a bit about it before continuing on. Next, we’ll hear about the awesome updates made to our feature.
Tell us more about what’s new with parameterization?
Adhi:
The biggest update to our parameterized testing is our ability to create these tables directly on the Qyrus platform itself.
Kiwaun:
And, we’ve made it so it’s an easy process that’s done right alongside test building and on the exact same page. This enables the user to be more productive as they don’t have to go around to different screens or pages in order to fill in this information.
Adhi:
And, the really cool thing is that you can actually connect this to the test data management section in Qyrus. We’ve talked about our test data management feature in the past, and you can read more about it here. But essentially, this also allows users to auto-generate data in these tables for use during execution. We’ve really tried to tie all aspects of Qyrus together.
These new updates really highlight the importance of data-driven testing and how that can help users scale and increase coverage of test cases and scenarios. Qyrus is constantly looking to improve and update features to keep up with client requirements and advancements in the automated testing area.
What is this feature’s overall impact on the testing process?
Adhi:
Parameterization has an impact in all major areas of testing, including test building, execution, and the following reporting. And, with the advent of test data management and tying it into parameterization, even maintenance is something that is impacted here.
Kiwaun:
In terms of test coverage, the value of parameterization cannot be understated. The whole idea behind data driven testing is to push test coverage and also make it more efficient to do so in the process. We also want to make it easier overall, which can provide cost and effect reduction.
How might parameterization help testers, developers, and business technologists? What value can this feature bring?
Adhi:
Testers would use this to push their test coverage, as we just mentioned. But besides that, it can help them specifically target what data and data sets to be used in testing for specific test cases and scenarios to be executed.
Kiwaun: Devs might use this to help them in building and running unit tests, but this is a tester-focused feature. The great thing, however, is that it makes this type of testing more accessible to those users who aren’t proficient in testing whatsoever. This can enable even less technical people, like business technologists, to be able to perform data-driven testing themselves.
Making testing simple is Qyrus’ mission. Through making testing simpler, we can make testing faster. Parameterization and data-driven testing can sound complicated, but with Qyrus it is made simple.
Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems?
Kiwaun:
Prior to our parameterization as a whole, users would have to create multiple test scripts to cover these different scenarios. With parameterization, this isn’t an issue. But, even more importantly, with the updates that have been brought forward – including test data management – it has even more value than before.
Adhi: And, ultimately, competitors don’t have the same level of test data management that we do – especially now. But if we’re looking at this from a pure coding standpoint – data-driven testing is achievable. It’s definitely nothing new. But, what’s the real question is, how easy is it? Given Qyrus, it’s really easy.
How do you see parameterization impacting day-to-day operations across organizations?
Kiwaun: In terms of day-to-day, our parameterization and data-driven testing is extremely easy and would speed up test building and coverage. Test cases are all executed under one report and presented back as such.
Adhi:
And the days of coding day-in and day-out are gone! The codeless approach of Qyrus takes the coding out of testing and makes it simple. Even filling out these parameterized files or using the onboard test data management is simple.
Data-driven testing is essential to efficient testing. It is not easy to scale test coverage while also keeping up with the agile process of software development. Qyrus always seeks to keep updating their features, as well as adding new features. Keeping up with the testing requirements of our clients and the ever-evolving world of testing is a core goal of Qyrus. These updates to parameterization are just an example of how Qyrus is an ever-evolving testing platform.
As applications become a medium for business progress and success, Quality assurance processes have never been more essential. From the developer down to the primary user and back, quality assurance teams ensure functionality and user experience through consistent testing practices. Regardless of the practice, manual or automated, coded or solution architecture implementations, the fundamentals of Quality assurance rely on collaboration. The best QA teams have engineers, test architects, developers, and business analysts that are in tune with feature implementations, release cycles, and required application functionality. This week’s Feature Friday discusses one of the pillars of Quality Assurance, collaboration. Despite much to talk about with Qyrus’ all in one automated testing platform, Dan and Tim will discuss something more fundamental in how Qyrus enhances collaboration and communication throughout the development and deployment lifecycles, leading to higher quality applications with faster release times.
Tell us more about collaborative testing offered by Qyrus and its use cases.
Dan:
Qyrus has a lot to offer when it comes to collaborative testing and helping enable testing teams to be more collaborative not only within their own team but also with the organization as a whole. Some of these features include the ability to lock scripts from being modified, the ability to download, share, and email reports to anyone.
Tim:
On top of that, everyone can have access to each other’s tests. This also enables more collaborative test building among team members. Testers can work off of each other by copying or cloning tests created by other members in order to further their testing. This helps promote reusability in the testing environment. And, everything being done from the cloud enables better management as a whole. Our test repository also promotes better organization amongst team members.
Dan:
This is also very helpful with handoffs. Giving quick project access or sharing reports provides immediate clarity simplifying knowledge transfer of test requirements and data. Regardless of where your colleague is located, everything is consistent on a singular platform.
What kind of impact on the testing process does collaborative testing have?
Tim:
The biggest impact is going to be seen in the area of maintenance. Because everything is on the cloud and centralized in one area, there is less maintenance seen on the side of the testers. And, overall, all of our collaborative features provide impact in almost all aspects and areas of testing.
Dan:
The key, obviously, is to promote collaboration which in turn can help in other aspects such as cost and effort reduction as well as an increase in test coverage overall. A well-oiled machine works with extreme speed and efficiency, and a testing ecosystem is no exception.
How might collaborative testing help testers, developers, and business technologists? What value can collaborative testing bring?
Tim:
Testers would be the primary beneficiary of the collaborative testing process. These features help enable teams to better communicate and collaborate. And in a similar fashion to testers, developers in turn would become more collaborative. But more importantly is that these two teams, although separate, will become more effective when communicating and collaborating together. No longer do developers have to waste time in setting up testing environments and developers can unit test their applications early on in the process.
Dan:
And in terms of business technologists, they would become more engrained in the testing and development process because of their ability to just log in and check out what’s going on. On top of that they can download reports as well as PDF generated reports which can help them understand if the stakeholder requirements are being met.
Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems?
Dan:
Straight off the bat, if the competitor doesn’t have a cloud-native platform, they’re already leagues behind us in terms of collaboration and testing. As seen with our competitors, it’s not as seamless of an onboarding situation when it comes to adding new members to their teams. With Qyrus, everything is done practically instantly and set up with the click of a button.
Tim:
And prior to Qyrus or any testing platform, users would have to use something like Git or other 3rd party applications in order to have a collaborative testing environment. The biggest thing is sharing these tests with other members of the team – whether it be for review, helping another team member, or as a continuation of the testing process – everything is easily accessible.
Dan:
The last thing anyone wants is a fragmented testing ecosystem. This can lead to breaks in the process and issues later on down the road. Furthermore, the users and environment setup and maintenance required for all QA team members to have required access can quickly become a nightmare. Everything being in one spot is not only convenient but also helps with collaboration and onboarding.
How do you see collaborative testing on Qyrus impacting day-to-day operations across organizations?
Tim:
By the nature of making the testing process more collaborative, things become easier within a team and their communication with each other. Locking certain scripts can prevent them from being meddled with on accident. Furthermore, small testing teams can script a rather large amount of test cases in a relatively short amount of time.
Dan:
If you think about it, test coverage as a whole will increase, making testers busier day-to-day, but all for a good reason. Lastly, reusability is promoted, so we might see a decrease in time spent doing repetitive tasks or scripting things already scripted.
If the idea is to promote the highest quality application, in the fastest time, it is essential that developers, testers, and business analysts not only have access to all application and release information, but transparency and collaboration throughout the entire development, Quality assurance, and deployment lifecycle. Qyrus enables the highest levels of collaboration through a cloud native platform. With the ability to quickly spin up user instances, sharable reporting, test building/cloning, and restricted access settings, Qyrus has created the perfect environment for professionals across businesses to co-create and release high quality, customer centric, applications into the market.
It’s Friday, and, after all, isn’t the whole point of the week the weekend? Before we jump into that, we’re here to bring you another installment of Feature Friday! This week, we are discussing our inspect mode feature for use in our mobility testing. This week, we are lucky enough to have three amazing experts from our Qyrus team to shed some light on inspect mode for both Android and iOS devices. Without further to do, let’s hop right in!
Tell us more about inspect mode offered by Qyrus and its use cases.
Brett:
Inspect mode is a feature offered with mobility testing in Qyrus. Its essential usage is to assist users in finding locator values of elements on their applications. It also helps with verifying these locator values. If a user wants to verify that the value works on a given page of an application, it will show the user where it is on the page.
Jorell:
The way it works is a user can activate the mode on any given page of their application. Afterwards, any object they click on the device will be highlighted and the locator value populated in the step builder.
Milton:
The inspect mode gives a wide variety of locator types to use. Given the values are present for the selected object, Qyrus will provide XPaths, names, among other typical and standard value types.
Inspect mode already seems like an interesting feature from those statements alone. Qyrus seeks to make testing easier for everyone at every step of the testing process. We asked the group to tell us more about the impact we see from using inspect mode.
What is inspect mode’s overall impact on the testing process?
Jorell:
Inspect mode really only impacts test building, as it doesn’t have too much to do with test execution or reporting.
Milton:
I agree, overall, it helps reduce the amount of effort required to build these tests. Instead of having to manually inspect the XML of the app, you can now just use this built-in feature while you’re test building! No interruptions at all, whatsoever and I can easily choose any attribute.
How might inspect mode help testers, developers, and business technologists? What value can this feature bring?
Milton:
I’d say that in general, this feature is much more targeted towards testers and developers. However, business technologists would be able to much more easily navigate and even build simple tests quickly and ensure accessibility standards are met. Like we mentioned earlier, it simplifies test building greatly.
Brett:
For testers, we’ve already mentioned how it could be useful in their test building activities.
Jorell:
Developers also will find use in using inspect mode. Where it really starts to come into play is when we have multiple versions of an application. Developers could use this to inspect the applications and the elements within. That way, they can verify locators the different versions of their applications.
Inspect mode certainly has its strengths. Already seeing how much value this simple feature can bring, we wanted to learn more about exactly how this feature evolved the process. We wanted to know a bit more about how something similar would have been achieved before the introduction of this feature.
Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems?
Brett:
So, yes, there are similar things out there to our inspect mode. However, none come close to the holistic experience from speed to the depth of information that you would receive on Qyrus. Most other similar features aren’t as complete as ours. One example is giving visual feedback in the form of highlighting the element on the live device stream. Another would be the automatic detection of multiple usable locator value types.
Milton:
And, Qyrus easily transfers those values over to the step builder, as well for quick automation. This allows us to take this one feature and incorporate it with others to help form that holistic test automation experience on Android and iOS devices from building to execution to reporting.
How do you see inspect mode impacting day-to-day operations across organizations?
Jorell:
We mentioned this a bit earlier, but essentially it would change how testers currently get these values completely. Originally, testers would have to manually comb through the XML tree and even create XPaths manually in order to get these values. This would involve a lot of back-and-forth between the testing app, the testing platform/framework, and the actual executions/reporting.
Brett:
And, 3rd party tools aren’t needed anymore in order to inspect elements on an application. Everything being integrated into a single platform brings a lot of bonuses. As Jorell said, you’ll see a lot less back-and-forth and in general higher productivity.
With the conclusion of this week’s Feature Friday, the beginning of the end – the weekend that is – starts. Enjoy it while you can, because it seems that the only thing that travels faster than light itself is weekends! So, it’s Friday, time to go out and make stories for Monday!
Friday? More like Fri-YAY! The weekend is here and our time to unwind and relax is nigh. Call the pizza place, get some soda, pop in a movie, whatever it is you like to do to relax. However, before we do, we’d like to thank you for joining us for this weeks’ Feature Friday! This week Adhiraj and Parth join us from our Chicago Qyrus team to give us a little bit of an insight to Qyrus’ web recorder tool. Whether you’re still at the office or kicking up your feet at home – or kicking your feet up at the office – let’s get into it!
Tell us more about the web recorder offered by Qyrus and its use cases.
Adhiraj: The Qyrus web recorder is an extension that we offer on Google Chrome. It helps users record their steps and actions in the Chrome web browser. It’s quite helpful in how fast it allows us to build tests out, especially if it’s primarily navigational. Afterwards, it just imports straight into Qyrus and is editable and executable right away.
Parth: The recorder does go even further, though. You can do some dynamic data handling as well as the basic verifiers from the recorder tool, as well. It’s not just limited to navigational actions. And the local browser execution allows for you to execute these tests you’ve built locally.
Well, doesn’t this sound familiar? Just the other week, we covered Qyrus’ mobile test recorder and its capabilities. Many similar advantages exist between the two. So, let’s dive deeper and learn more about the web recorder.
What is the web recorder’s overall impact on the testing process?
Adhiraj: Well, mainly, it has the most impact on test build ing. I mean, it’s a recorder, after all. So it takes the need of having to manually build these steps out of the equation. And that’s stating something, because prior to codeless test building like on Qyrus, it would take even more of an effort to build a simple test.
Parth: That’s right. Essentially, it takes Qyrus test building to another level. It was easy before, but now it’s even easier. And with things becoming easier, it can save a lot of resources in terms of working hours spent writing and building test scripts.
Adhiraj: I’d even say that it can help with overall test coverage in the same manner. With building becoming faster, coverage can increase. The recorder prevents testers from having to write long lines of code.
How might the web recorder help testers, developers, and business technologists? What value can this feature bring?
Parth: Well, obviously, this feature is a great thing for testers. It can cut building time down in half if used. On top of that, the tests you build using the recorder can be extremely complex. However, sometimes we see that more technical users prefer to go at it in a more manual fashion due to their expertise in the matter already. With that, we see less technical users taking more advantage of this tool.
Adhiraj: I’d agree with Parth on that. I mean it really is a fast and effective way to build out complex test scripts. But with regards to developers, they can use it to also build their unit tests. And with business technologists, we see them taking advantage of this tool to build out tests of their own. It’s pretty easy!
Parth: Developers can also build tests on localhost apps! In that way, testers already have a few baseline tests for when the app is in QA or staging. And, this extension also allows users to make localhost API calls.
That’s fascinating. All of the benefits that come from the web recorder are evident. This feature makes a lot of sense to have, and leads us to ask Adhiraj and Parth…
Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems?
Adhiraj: Well, it is true that other recorders exist out there, but none that can offer the same capabilities that the rest of Qyrus does. Along with the tests you record, the reports you get back are unparalleled. The information, visual reporting, and logs provided are great.
Parth: And many other recorders out there don’t work out of the box like ours does. All that’s required is to download an extension on Chrome! We also plan to extend our recorder to other browsers, as well. And if you wanted to make your own recorder, well that’d take a lot of coding and prior knowledge.
Very well, other tools like this do exist out there, but it’s obvious from the points Adhiraj and Parth made that none are as versatile and powerful as ours. When looking at the bigger picture, the overall testing process, it’s evident that our web recorder (combined with powerful reporting capabilities, etc.) is a pack leader.
How do you see the web recorder impacting day-to-day operations across organizations?
Parth: As we’ve mentioned before, it definitely makes test building easier. So, you’d probably see a typical tester spend a lot less time on test building in their day-to-day operations. Not only that, but a significant less amount of manpower would be required to complete the same tasks.
Adhiraj: All that’s really required is knowledge of the platform being tested.
Parth: Yeah, overall it really saves time and money. These resources can be spent in other areas of the business, whether that be more focusing on user experience or expanding and improving applications.
Is that pizza I’m smelling, or is it just the weekend getting to me? We won’t keep you guys any longer than necessary! Thanks for joining us on this week’s Feature Friday! We hope that you learned quite a bit about the power of our web recorder feature that we have on Qyrus. Take a look for yourself and start a free trial this weekend! (Or on Monday, we wouldn’t blame you!)
Join us next week for more exciting news and information on features!
They say the difference between a good city and a great city comes not with wealth, infrastructure, or capital, but with transportation. Quality public transportation, dedicated bike lanes, a solid bussing infrastructure, and a maintained train system, all connect people across cities allowing for events, ideas, and movements to thrive. There is a very similar parallel within a testing solution. Seamless integrations are the buses and trains that interconnect the aspects of quality assurance, creating an efficient and scalable process. This week’s Feature Friday focuses on Qyrus’ out of the box integration with Xray, and we are joined by Steve and Brett to hear more.
Tell us more about the Xray integration offered by Qyrus, and its use cases.
Brett: Xray is a test management tool from Atlassian with Jira Integrations. Qyrus provides the ability to link tests with Xray issues. With this feature, users can quickly manage their test cases at different stages of development. Reporting is then available on Qyrus as well as Jira.
Steve: The first target group would be companies that already have test management with Xray and want the ability to run the tests using Qyrus. The second target group includes users that have no test case management. With ease, the user can choose a Qyrus script and automatically add it to Xray enabling both Qyrus’ test automation and Xray test management benefits with ease.
A quick integration can offer a robust or targeted solution. Therefore, it is always important to figure out how this feature can impact quality assurance as a whole, rather than just one aspect of the cycle.
What is this feature’s overall impact on the testing process?
Brett: The overarching value of the feature comes with the synergy of testing and reporting and test case management. To be specific, if the cases are already on Xray, we can swiftly map a given Qyrus script to its accompanying Xray issue and environment, making a seamless path for management and execution.
Steve: Also, if you have already existing suites in Qyrus but do not have test case management and proper issue management, you can also quickly integrate Qyrus suites into Xray, quickly creating environments to log and manage any issues across test cases.
How might this integration help testers, developers, and business technologists? What value can this feature bring to them?
Steve: A tester would build the tests out on Qyrus and then link those tests to Xray issues. In the case where Xray issues are not currently being used, the tester can create and link from the Qyrus UI and automatically create Xray environments that can then be used for test cases and defect management.
Brett: A developer would primarily log Xray issues, allowing the tester to link those issues with Qyrus scripts. The developers have the ability create these issues during their development phase, providing unit testing and ultimately enabling a shift left.
Steve: A business technologist can go through Qyrus tests and visual reports and log defects straight to Xray. This allows business technologists to take a step into the testing and development realm, while still utilizing their expertise.
Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems?
Steve: Before Xray integration was added to Qyrus, a tester would achieve this functionality by only using Xray. The tester would run their scripts on Xray and get valuable information on the status of a regression suite but no individual step executions or results. The user would have to enlist another testing platform for per-step executions and manually relay the issues and changes to Xray.
Seemingly unique, helpful, and consistent throughout the overall testing process, is this a one-time use feature, or is this something that will be used on a daily level to impact organizations and processes?
How do you see this integration impacting day-to-day operations across organizations?
Steve: Daily users will find themselves leveraging Xray’s high-level designs with Qyrus’ step-by-step execution and reporting capabilities. This way, testers can develop scripts in accordance with Xray environments and keep their entire QA process in tandem.
Brett: Not only are you streamlining the QA process, but you are also utilizing the power of two quality solutions. Not only will you find tests, executions, and reporting on Qyrus, but those reports are also relayed on Xray which maintains organization and manages defects.
Just like any major city, connected resources share power and value. In a similar manner, connecting testing and test case management solutions with seamless integrations can make the most of differing features and expertise to amplify the quality assurance process. Not just Xray integration, Qyrus offers a range of integrations straight out of the box! Be sure to tune in next week to learn more about Qyrus!
In volleyball, if you see slow feet on the middle blocker, you push the set to the pins. In basketball, if the center is big and tall but slow to shift, you run the pick-and-roll. In football, if the safety and linebacker are crowding the line, you run a hard count and get rid of the football. These intricacies are visible only to those who deeply understand the systems and processes at work. Similar intricacies are found throughout the application development and the QA lifecycle, especially as applications begin to grow. One said example, after multiple client and industry requests, and also the topic of this week’s feature Friday is document verification. Containing a mass industry appeal, applications often utilize documents, PDFs, and Excel files, to maintain data and run business processes. In this week’s Feature Friday, we interviewed Steve and Parth who will discuss more about how automated testing can play a role in verifying and maintaining business-centric files and documents.
Tell us more about document verifications offered by Qyrus and their use cases.
Steve: Document verifiers are action types that we have on Qyrus that allow users to verify data on documents and files, such as PDF documents and Excel files. You can do things like verify the downloaded file names and file types, and do verifications on tables in the Excel file, as examples.
Parth: It’s something that we were specifically asked to bring to the platform from a client. They wanted to make these verifications on certain documents, and we were able to turn the feature around for them. Specifically, it targets use cases that require testers to verify the data on the documents and files and typically compares those values to those seen on the UI.
What is the overall impact that this feature has on the testing process?
Parth: This feature affects the entire testing process in terms of test building, execution, and reporting. Obviously, it brings to the floor something that Qyrus was not able to do prior, as this was a feature request. This allows Qyrus to be more versatile in the kinds of testing and assertions it can make.
Steve: Yes, specifically, it increases test coverage and allows for better testing using automation. Previously, these tasks were typically part of a manual process. By automating a lot of these processes, it helps with cost and effort reduction. That’s really the goal here at Qyrus, to make things easier for the user in an effort to cause a ripple that can grow into a wave.
How might document verifications help testers, developers, and business technologists? What value can this feature bring?
Parth: For testers, performing verifications on documents can be a tricky and troublesome task. Honestly, it’s something that’s relegated to manual processes, as we’ve just mentioned. For testers and developers, they could use this to automate those processes. Testers might find more use out of this feature than developers, though.
Steve: Yeah, it’s definitely a tester-focused feature. But the beauty of Qyrus is that we try to make testing as easy as possible. Making testing more accessible is beneficial in many ways. Not to stray away from the question, but essentially, developers and business technologists can be empowered to test. It also helps in terms of technical knowledge.
Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems?
Steve: Well, before this feature on Qyrus these documents could be verified through a manual process. The cost incurred due to this cannot be understated. If they wanted to automate it, a skilled automated tester would be required, and a testing framework written.
Parth: Competitors have features for verifying PDF and Excel data, but it also requires coding knowledge, though to a lesser degree than what we just mentioned in terms of having to build your own testing framework. However, there is still a learning curve. With Qyrus these verifications are built-in action types, allowing you to build automated tests and verify documents as required, using Qyrus’ low-code no code interface.
Steve: The cool thing with Qyrus compared to competitors is that everything is done on the Cloud. For some competitors that do these types of verifications, they require the tester to download the file to their local machines and designate a file path. Making everything seamless is one of our priorities.
How do you see this feature impacting day-to-day operations across organizations?
Parth If there are existing testing processes for this type of testing, then there’s no doubt that day-to-day operations will see a large change. Firstly, manual processes are eliminated and turned into some weekly, biweekly, or monthly maintenance, depending on the requirements.
Steve: Not only that, but these types of tests can be reused across many test scripts. Qyrus promotes reusability in that fashion, and we try to engrain our platform with a degree of simplicity that enables faster testing and more robust reporting. Essentially, everything speeds up, and quality is assured.
Are there any potential improvements we can expect out of this feature?
Steve: Yeah, essentially, we would want to verify content on even more file types. Currently, we only do PDFs and Excel files. We plan on extending our coverage to rich text files and Word documents, with more to come.
Applications are becoming more functionality-dense. Requiring more integrations, file types, and sizes, alongside managing multiple different files for internal and data requirements. These processes are either intense manual efforts or left untested. This is because automation solutions that test code do not extend to other file types that are business-centric. Qyrus allows business-relevant application and document testing with the ability to automate document verification and testing. Automating a range of document verifications and requirements, which are part of essential business processes, increases efficiency, quality of development, and business process implementation. Join us next week to learn more about the Qyrus features that elevate testing and QA processes.
Curiosity, opportunity, perseverance… not only are these names of a few of the legendary Mars rovers, but they are also the same aspects that kickstarted and inspired our amazing Rover AI here at Qyrus. Seeking to push the boundaries of software testing through automation, the developers here at Qyrus have coded a tool that changes how we build and execute mobile tests. We’re joined today by Dan and Amy from the Chicago Qyrus team to learn more about it and its capabilities.
Tell us more about Rover offered by Qyrus and its use cases.
Amy: From a high level, it is a reinforcement learning bot that traverses your mobile app and records its journey. You can use these traversals to also build and export mobile test scripts on Qyrus! Overall, it’s an all-encompassing mobile app testing tool. It allows you to visually test user interfaces automatically and without the need for human interaction.
Dan: We see some users compare test coverage on their mobile applications by comparing the traversal to their currently built test scripts to find any isolated, or not tested, portions of the application. It also gives the testers an idea of what kind of possible flows there are in their app that they may have not even been aware of. And as Amy mentioned, after a traversal you can use the flow chart it generates to build test scripts in a fast and efficient manner.
The ability to see the various user journeys that can take place can give testers and developers a deeper understanding of the mobile application. There are various ways that it can impact the testing and overall software development lifecycle (SDLC).
What is Rover’s overall impact on the testing process?
Amy: The largest areas we see the impact in are test building and reporting. Firstly, as we have mentioned, you can build test scripts using the Rover report.However, even more important is the analysis you get back after it traverses your app. Everything comes back as a large flow, navigating from page to page in order to visualize the navigational flows users can take.
Dan: Not only do you get that back, but you also get mobile device performance metrics back, as well. And with these benefits, we see an overall increase in test coverage as well as moderate effort reduction. And obviously, with those two areas, we can see a cost-benefit when it comes to utilizing Rover for the testing of your mobile apps.
How might this help testers, developers, and business technologists? What value can this feature bring?
Dan: For a tester, it would help them find tests that they might have never thought of. Again, since it’s traversing your app, navigational flows may pop up that testers might not have encountered before. They’ll find use in the test builder, as well. Developers can benefit from using the performance data to see where potential improvements can be made in the app.
Amy: Specifically for business technologists, we can see them utilizing it to keep track of the health of their apps. Since it will discover and identify broken links, incorrect navigation, and general changes to the app, it can provide a lot of insight necessary for business technologists to perform their work.
Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems?
Amy: Well, talking about competitors, they might have some similar tools, but nothing as complete and robust. Again, it can help you determine other test cases and scenarios that might have not been covered in the original test planning.
Dan: Directly from the same screen, you can then build a test script simply by clicking through the report. It also lends a hand in UI/UX observations, since you can then see how each screen or page interacts with another. Page transitions are also included.
Amy: And prior to this feature on Qyrus, a tester would have to manually make test scripts. This is a time-consuming process that can take up a lot of working hours and as a result resources. Also, there was no real easy way to analyze the UI/UX of a mobile app. Screenshots are captured by default on Qyrus, but not processed by Rover.
In such a short while, mobile test building and execution have come leaps and bounds in terms of efficiency and quality. From a day-to-day perspective, how might things be affected?
How do you see this impacting day-to-day operations across organizations?
Amy: Well, it would make your day-to-day easier because of the analysis that’s given in reports. The amount of utility that is given cannot be understated. The performance metrics can give testers great insight with little to no effort on their end. Again, it’s all automated and driven by an AI.
Dan: And instead of having to manually build test scripts day-to-day, they can use the reports, as stated before. But honestly, testers might find themselves super busy because of their ability to quickly increase the test coverage of your ecosystem.
It is a tool that can change the way your team builds, executes, and analyzes tests and mobile applications. Qyrus as a whole brings so much to the table already, and with powerful AI tools like Rover and Healer the possibility for improvement is even greater. Thanks for joining us for this Feature Friday and learning more about our impressive Rover AI. Join us next week to learn more about how performance profiling works on Qyrus.
Jerin Mathew
Manager
Jerin Mathew M M is a seasoned professional currently serving as a Content Manager at Qyrus. He possesses over 10 years of experience in content writing and editing, primarily within the international business and technology sectors. Prior to his current role, he worked as a Content Manager at Tookitaki Technologies, leading corporate and marketing communications. His background includes significant tenures as a Senior Copy Editor at The Economic Times and a Correspondent for the International Business Times UK. Jerin is skilled in digital marketing trends, SEO management, and crafting analytical, research-backed content.
