On my current job, we are developing an application that uses WebRTC technology.
And we want to test the work of our application with 30 users in real time -- a conference call with video, sound, and microphone (and everything must work). We know that we can do it by real users (real users connected to our application).
Question is: How to test our requirement if we don't have such a number of real persons? Maybe exists some tool for that.
Thanks.
You'll need a Selenium Grid.
And you'll need to build the automation part on your own on top of it.
Alternatively, you can check out https://testrtc.com -- it enables automating 100's of browsers and more with a focus on WebRTC based services.
I am the co-founder, so take this with a grain of salt
That said, I am not aware of any other commercial tool or otherwise that makes this as simple and straightforward
You have two peer-reviewed IEEE scientific articles that were written on WebRTC testing state of the art this year. They both list and compare several solutions including but not limited to testRTC cited in the other answer.
On July 2017, "WebRTC Testing: Challenges and Practical Solutions" was published in an IEEE venue by the Kurento / Twilio team, and lead by the Spanish researchers that did not join Twilio but went on to start ElasTest, a millions-Euros, EU-funded project that looks very promising but is still in alpha stage.
http://ieeexplore.ieee.org/document/7992926/.
On September 2017, "Real-time communication testing evolution with WebRTC 1.0" was published in Principles, systems and Applications of IP Telecommunication by the CoSMo team behind the original Temasys infrastructure, the symphony solution, and the new Google Testing Engine (KITE). It is a full paper about the state of the art Before google decided to go for KITE, and include a thorough review of all possible testing layers, and existing solutions. There are many solutions to do what you want today. If you need an on-premise solution, and/or test mobile browser, and/or test native apps, IoT, ... AFAIK testRTC.com will not help you, however good for other aspects.
http://ieeexplore.ieee.org/document/8169751/.
You might want to read both articles, and citation therein before you make your choice.
Disclaimer: I am the original author of that last publication.
Related
Ok this is more informative question than on a coding question. However this is a two part question.
When building the flavors for example an MP3 player.. you would have free and premium. I started designing a flavor app of an MP3 player to start learning Flavors and Build variants.
What i am trying to understand is when building the flavor is all of the design for the flavors built in Project then each flavor is specific. Premium features for Premium and free features for free. I understand that.
However what i am not understanding about the design is when i design my login with firebase how do i call the flavor thats appropriate. For testing purposes lets forget firebase. Here is an example:
MainActivity has two buttons. One will point to the free and the other paid. So if i press the free button do provide an intent that points to the flavor as this:
val i = Intent(......buildConfig.flavors.free)
Or would i place the package name in where the buildConfig would go. This is not actual code this is just an example.
Keep in mind i have never built a flavored app. So this is a learning point for me.
My original idea was have a free version as default with an in app purchase. You use the in app purchase and if the purchase is successful then the premium would take effect.. the only differences in the actual deaign would be those premium features are enabled.
So the first question would be: Is there really a difference between same design flavors versus in app purchases?
The second question is: when building a flavor app with the same design. Do you have to use flavors, example Free/paid, if the design never changes.
Like i said this is a learning process and all my apps on google play is just a flavorless app with adMob banner ad. So i an wanting to venture out to a more simple aspect than having two apps on google play one app for the free and another app for premium.
I think it would be easier to do flavors. However i have never done a flavored app and all the research i have done does not give clear instructions. They all stop after the gradel file implementation.
So any direction would help with is flavors a must or is it more headache to deal with in my case for learning purposes versus real world application.
hi i'm currently looking at some new cisco phone systems and something on the wish list is a click to open account on our intranet.
I've been advised to look into tapi so I wondered if this worked with teams so I could create and test a solution.
i cant find any sample code younger than 4 years old so also wondered if this is fading out with the newer wave of unified comms
The current trend in the unified comms is moving to proprietary interfaces. TAPI does not really have decent facilities to deal with the addition of chat and video channels anyway. While some vendors seem to be willing to keep supporting it for some time, most seem to be designing new API's from the ground up (Teams Graph, Cisco WebEx, Alcatel Rainbow,...)
Specifically to your question: no, Teams does not support TAPI and there seems to be no intention to ever do so. None of Microsoft previous UC solutions (Skype for Business, Lync, Office Communication Server) did either.
If you don't want to develop/test straight onto your production Cisco, you may be able to get a VM version of the PBX with a trial/temporary license for software development purposes through a Cisco partner.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed last year.
Improve this question
I am Test Automation engineer and recently got opportunity to explore RPA tool blueprism. After exploring I found it similar to UI automation tools supporting various technologies. Can anyone tell me what value RPA adds compare to traditional tools. I was interested to see how it can use 'intelligence' but couldn't find any feature.
Can expert in this forum help me understand what RPA can do which traditional tool can not do ?
I see similar questions but they do not give any answers I am looking for.
Thanks,
Nilesh
The technological challenges of RPA and automation tools are quite similar. RPA and testing products differ in their user experience and reporting. While testing tools often offer features to assess risk or create testing data, RPA tools have bigger focus on bot creation and user data storage.
The main difference between the two very similar techniques Test (Process) Automation and Robotic Process Automation is the Goal. Almost all the points contained in the previous posts are, in my modest opinion, consequences of the goal of both techniques:
With a Test (Process) Automation tool you want to test an application or system under test. I.e.: Want to find bugs or to prove that the quality of the application has reached a certain level. The Test Process Automation will in general run in a test environment. If something goes wrong with your test automation code or tool breaking completely down the test environment, it is not that bad: You can reset the environment and have not hurt anyone.
With a RPA tool you want to implement a real life business process. The robot works in a productive environment. If something goes wrong you may really hurt someone, i.e. damage productive data or environment. The robot does the work of a user, not just simulates it. Therefore, the robot must be "save". It must also be possible to understand what the robot exactly did with the job it got.
I hope, this help to clarify.
PS: I include the word "Process" in the context of testing, because initializing or resetting a test environment, providing secondary data, booting a system under test, running a test, collecting results, comparing actual with expected results, creating reports for test management or DevOps is usually a process you automate using some kind of "Test Process Automation" not just Test Automation.
on a less official and serious note, RPA is a marketing term for a Test Automation Robot pumped up with some kind of a Workflow Editor and some remoting Technologies
We were using standard Test Automation Robots(UFT, Selenium etc) to do some RPA with the backlash that the automated workflow was rather coded than visualized and we had to have some effort invested into the infrastructure to support scaling. (launching them en-masse and automatically)
What does it solve?
- As mentioned above, visualising worfklows and scaling - although here it has limitations
What are the weak points?
The Test Automation Robot wrapped inside the RPA can be very limited - in many cases they are less mature than state of the art TA Robots.
The promise of record & replay and drag & drop your workflow. As always - we are not yet there
It solves a problem in a way it shouldn't be solved; The GUI is for the user the APIs are for the software (or call them robots in this case). These problems should be solved by writing integrations between systems or extending existing APIs (safer, cheaper, much more reliable etc)
RPA platforms provide you a singular place where various different type of applications can be automated.
These platforms fundamentally will try to consolidate and formalize the automation effort in an enterprise. and here the word "enterprise" is key.
for small businesses where they want to automate some task/s the intern can be asked to quickly build up something. no one cares what technology or tools were used. maybe he likes python, and someone else likes VBA. so a single task may be automated using several different technologies. no one cares as long as it works. the intern leaves and the next intern figures something new...
RPA platforms on the other hand are a larger "formal" effort that will try to automate tasks that otherwise require a lot of FTE (full time employee) count to accomplish. typical RPA use cases are repetitive tasks that humans are doing all day without using much brain. think of extracting each line item from a PO (purchase order) and putting it in an excel spreadsheet and then posting it on some internal application. now imagine a single guy doing this maybe for 100s of POs a day.
You cannot imagine how uneven the IT landscape in most of the enterprises is. old applications that were either built in house a long time ago or versions that arent being updated by the vendor any more. the bigger problem is when these applications do not have any integration points, so these RPA platforms provide the lease invasive (changes to old applications or upgrading even)
i can go on all day about RPA, do let me know if you have any follow up qns. i work for one of these RPA platforms, maybe i will be able to help.
There are many flavours of RPA.
Blueprism is not an ideal example of what modern RPA should look like, consider checking out Automation Anywhere or UiPath (both offer Community Edition you could download and try for free).
While technological differences may not be that vast (and indeed RPA vendors are now looking at test automation as a market for their products), biggest differences are in the ways the platforms are engineered, to name a few:
Security-oriented approach, RPA platform is designed to make sure it could handle important data responsibly.
Design for ease of use for non-technical people. Selenium is great but you need to know how to program to use it. UiPath requires easy drag-and-drop for the same things.
Working with unstructured data inputs, like OCR'ing documents and acting on them
ML integration, for decision making or extra capabilities. E.g. NLP stuff, sentiment analysis, helping OCR recognize new document formats etc.5. Integration with third-party like chat bots or BPM
Analytical and monitoring capabilities, to make sure that you know how long your bots take to do their work and to help them if they fail
Easy of use should not be discarded:
With RPA it's a half an hour job to receive a request by mail, take data from SAP, build pivot in Excel and upload to a website in JSON format. Could you do that in other tools? Sure! Is that as easy? Usually no.
So you could do poor man RPA with Selenium or AutoIT or bash or PowerShell, it will just be not as easy and will provide less capabilities while requiring more effort every step of the way. And if you do it properly you'll end up replicating one of the RPA platforms anyway.
Also in RPA there is usually but not always central coordination mechanism (ala Selenium Grid) to orchestrate several robots (up to 10k in UiPath case) to make sure they act in sync, have some sort of work queue, shift their workload, deploy processes to them etc. This makes all the difference for enterprise usage scenarios.
RPA and UI Automation tools have some technical features that intersect. For example;
UI Component utilization: These tools may utilize a UI screen image-based approach, OS platform frameworks (i.e. Microsoft Accessibility Frameworks), or technology-centric platforms extension (i.e Chrome or Firefox extension)
End-2-End application driving: These tools have the capabilities to drive applications to complete their duties. For example, log in to an application and get some data and shift to other legacy applications and enter data.
Screen scraping: These tools have screen scraping features to retrieve some data on screens there other techniques are not applicable.
3rd party application integration: Also these tools can integrate web services or databases to get data and use these in their application usage scenarios.
...
As you see lots of features these RPA and UI Automation tools share. But, the main concept is here not technology but application methodology. In this point of view, RPA Tools
Designed to drive real-life business flow in the production environment.
May have some cognitive power to complete human-exhibit tasks (i.e. document analysis, high OCR capability, pattern recognition)
Can work attendant and unattended
Doesn’t require any programming language knowledge. That non-technic staff can easily use and learn.
Contrast to below: for implementing complex flows, gaining scalability, achieve seamless integration to Third-Party application, and native integration of external technology into your business flows (i.e. third party microblog sentence classification A.I. library that you developed your own) Some RPA tools (Voodoo RPA) have their own Embedded Development Environment (EDE) for programmers.
Invented for doing the high-value repeatable task in 7/24 in reliable and secure manners
Enhanced workflow management, impersonation, and logging capabilities
In sum, RPA tools developed to easily implement high-volume repetitive tasks in a business environment but UI automation developed to test the application's UI and verify business rules suited for the baseline paradigm.
The main difference is a type of task we can automate using traditional
automation and RPA:
Traditional automation is mainly used to automate test cases of applications/products.
RPA is mainly used to automate business processes.
If we talk in terms of coding knowledge then traditional automation required more coding knowledge in comparison to RPA.
Traditional automation can either support desktop app automation or web app automation at a time without integration of 3rd party
tools. whereas RPA can support both web and desktop app automation.
I want to do my final year project on augmented reality geo-localization,
Please tell me, from where to start ?
what technology to learn ?
what are recruitments to development this kind of application ?
If you want to perform Geo-Localisation and use GPS, I wouldn't recommend using Unity. It's arbitrary coordinate system can be a bit confusing and difficult to make an app using GPS that's reliable enough.
For Augmented Reality, you can't use anything like Oculus Rift or Google Cardboard, because those are Virtual Reality headsets and have no way of allowing the user to see the real world. Augmented Reality peripherals are things like Microsoft Hololens or Google Glass, neither of which are commercially available but there are cheap knock offs that are. AR can also of course be used on any mobile device, since they all have a camera built-in and chips powerful enough to process all the tracking data.
As for making an actual app, the best thing you can do is have a go. Analyse your market, see where the gaps are. If you want to make an app for a specific OS that isn't cross-platform, I would recommend learning some Objbective-C (for iOS) or Java (for Android), if you don't know any already.
For cross-platform, I would say something like Xamarin would be useful for making an app on both the major OSes, it was recently made free by Microsoft and you can essentially make one app in C# that works across all devices.
For the Augmented Reality itself, there are frameworks out there that can be used for your purposes. Things like Kudan, Vuforia, Wikitude, etc. Some of them offer free versions of their software. You can use these to deal with all the tracking and projection side of things so you don't have to go about creating your own AR engine.
The best thing to do is probably to sit down for a few minutes, or hours, and think about what you're going to do. Figure out what you want the end result to look like, then work backwards and think about the best way to achieve that goal. Eventually you will arrive at the language and engine you want to use to make your life as easy as possible and then you can get started learning from tutorials online and getting your app out into the world.
you can check my tutorial about geo-based augmented reality solution on Android: https://www.netguru.co/blog/augmented-reality-mobile-android
I have presented there the basics and how to start with simple implementation.
Well a good starting point would be to ask yourself few questions:
What type of devices, you plan to work on(oculus rift, google cardboard, Microsoft Hololens, web etc)?
Augmented Reality is achievable in both Web-Context and Application-context. Which route do you want to go for?
Depending on these questions, if you choose to do a normal application based on a device, then depending on the device(Oculus Rift, Google Cardboard, Microsoft Hololens), you would need to grab their specific developer kits and learn how to develop apps using the documentation. For Oculus rift and Microsoft Hololens, you would need the respective Headsets inorder to make an app in that, but If it comes to google cardboard, all you need is you mobile phone with a good processing power.
There is another way to work on augmented reality applications, that is by doing a Web Application using some amazing javascript libraries like Awe.js, Three.js and JSARToolkit.
You can google about them and find out more.
One of the more accessible ways to learn Augmented reality is Project Tango.
Devices are around $500 last I checked and you can use a free version of Unity + Project Tango's free plugin:
https://developers.google.com/project-tango/
Which ever hardware you pick I'd recommend checking out Unity3D as it seems to be the platform of choice for AR/VR at the moment. There are other options... this just provides the most flexibility based on all of the platforms it supports.
Side note: I have no affiliation with Project Tango and am in fact working on another platform... but it isn't as accessible at the moment.
There are a couple of questions on Stackoverflow asking whether x (Ruby / Drupal) technology is 'enterprise ready'.
I would like to ask how is 'enterprise ready' defined.
Has anyone created their own checklist?
Does anyone have a benchmark that they test against?
"Enterprise Ready" for the most part means can we run it reliably and effectively within a large organisation.
There are several factors involved:
Is it reliable?
Can our current staff support it, or do we need specialists?
Can it fit in with our established security model?
Can deployments be done with our automated tools?
How easy is it to administer? Can the business users do it or do we need a specialist?
If it uses a database, is it our standard DB, or do we need to train up more specialists?
Depending on how important the system is to the business the following question might also apply:
Can it be made highly available?
Can it be load balanced?
Is it secure enough?
Open Source projects often do not pay enough attention to the difficulties of deploying and running software within a large organisation. e.g. Most OS projects default to MySql as the database, which is a good and sensible choice for most small projects, however, if your Enterprise has an ORACLE site license and a team of highly skilled ORACLE DBAs in place the MySql option looks distinctly unattractive.
To be short:
"Enterprise ready" means: If it crashes, the enterprises using it will possibly sue you.
Most of the time the "test", if it may really be called as such, is that some enterprise (=large business), has deployed a successful and stable product using it. So its more like saying its proven its worth on the battlefield, or something like that. In other words the framework has been used successfully, or not in the real world, you can't just follow some checklist and load tests and say its enterprise ready.
Like Robert Gould says in his answer, it's "Enterprise-ready" when it's been proven by some other huge project. I'd put it this way: if somebody out there has made millions of dollars with it and gotten written up by venture capitalist magazines as the year's (some year, not necessarily this one) hottest new thing, then it's Enterprise-ready. :)
Another way to look at the question is that a tech is Enterprise-ready when a non-tech boss or business owner won't worry about whether or not they've chosen a good platform to run their business on. In this sense Enterprise-ready is a measure of brand recognition rather than technological maturity.
Having built a couple "Enterprise" applications...
Enterprise outside of development means, that if it breaks, someone can fix it. I've worked with employers/contractors that stick with quite possibly the worst managing hosting providers, data vendors, or such because they will fix problems when they crop up, even if they crop up a lot it, and have someone to call when they break.
So to restate it another way, Enterprise software is Enterprisey because it has support options available. A simple example: jQuery isn't enterprisey while ExtJS is, because ExtJS has a corporate support structure to it. (Yes I know these two frameworks is like comparing a toolset to a factory manufactured home kit ).
As my day job is all about enterprise architecture, I believe that the word enterprise isn't nowadays about size nor scale but refers more to how a software product is sold.
For example, Ruby on Rails isn't enterprise because there is no vendor that will come into your shop and do Powerpoint presentations repeatedly for the developer community. Ruby on Rails doesn't have a sales executive that takes me out to the golf course or my favorite restaurant for lunch. Ruby on Rails also isn't deeply covered by industry analyst firms such as Gartner.
Ruby on Rails will never be considered "enterprise" until these things occur...
From my experience, "Enterprise ready" label is an indicator of the fear of managers to adopt an open-source technology, possibly balanced with a desire not to stay follower in that technology.
This may objectively argued with considerations such as support from a third party company or integration in existing development tools.
I suppose an application could be considered "enterprise ready" when it is stable enough that a large company would use it. It would also imply some level of support, so when it does inevitable break.
Wether or not something is "enterprise ready" is entirely subjective, and undefined, and rather "buzz word'y".. Basically, you can't have a test_isEnterpriseReady() - just make your application as reliable and efficient as it can be..