Hi
we are expanding one of our projects in a major bank to include access via mobile devices. We are evaluating a few tools - inc. perfecto mobile, experitest and deviceanywhere.
From our initial evaluation perfecto and device anywhere cover a larger set of handsets inc feature phones. Experitest on the other hand is strong and simple to operate with smartphones(iphone, android etc).
Can anyone share experience from using these tools for large scale projects? we are mainly concerened re stability, ability to work with QTP and support considerations (support for new devices etc).
I have used DeviceAnywhere extensively. Perfecto, not that much, after a pretty dissapointing trial period. DA has support/add-ins for QTP and QC. Perfecto does not cover QC. Perfecto is not faster than DA, since most of their devices are in Israel, and not the US. DA has a few datacenters in the US and abroad, hence you have a better chance to get better performance. DA has an pretty long list of Enterprise and Carrier customers...while Perfecto seems like a very small company. Compare their website quality-it's pretty obvious which one looks more professional...You should try them both and make up your mind...
I have used all 3 platforms many times
Only Perfecto Mobile and DA are robust enough for real testers (at least for enterprise level).
DA have more devices but Perfecto are 100% web based, faster and MUCH cheaper. Both offer automation environments with pros and cons but Perfecto offers QTP integration and enhanced security solutions
Conclusion - both systems good, Perfecto cheaper, Perfecto much better for enterprises engaging in mobile testing.
Guido
Think of coupling a standard software remote control product with a standard software test robot (like QTP).
As an alternative, and being a mostly device-independent, but bitmap-dependent solution, you could use one of the many remote controls to bring the mobile's display contents to the desktop. Then, you'd "click around" in that remote control window using you favourite test robot.
Stupid that sounds? Well, it has its strong and its weak points:
If QTP is set for you, you'd be stuck on bitmap synchronization, no other useful GUI properties would be visible. However, if you have some QTP know-how on board, you could reuse all the know-how for test management integration via QC, test data addressing, and so on, scripting "art" like wait-for-the-right-thing, convert bitmaps to text, and so on. You could even "in real time" verify the results displayed on the mobile to stuff in the corporate backend, or research expected results in some central database after doing some transaction on the mobile -- all that would be easy since your test robot runs as part of the IT infrastructure all the time, so it has easy access to those resources. And those accesses could be done with all the comfort we got used to on PC-based test robots, like for example QTP's database checkpoint.
The positive aspect would be: Using such a scenario, you are largely independent of the mobile's technical details, and could support a lot of different devices by just using different sets of expected bitmaps. (Provided the workflows are exactly the same, which of course is not always the case.)
If you don't have to buy an extra test robot, this solution might be unbeatable cheap. Most Windows mobile devices for example can be used with Microsoft's free remote control, and there are lots of commercial vendors offering remote control functionality for a variety of devices in one package.
Also, you could develop test scripts using emulators emulating the mobile device, because the test robot would not know the difference between a display being fetched from the real thing, or being shown by the emulator.
I've done all that with various remote controls and PDA/smartphone devices, using CitraTest or QTP as the test robot. I was very happy not having to mess around with yet-another-specialized tool, or even more than one of them, each with their own language, or methodology.
Biggest hurdles besides the ones already mentioned were:
find a remote control that is versatile, fast and reliable
find a way to let the mobile use its "normal" communication path (for example, cellular connection) for all applications while, for performance reasons (and to minimize side effects), the remote control is connected through a direct connection (USB, propretiary synch cable, network...whatever the mobile supports).
create a scripting "standard" which is sufficiently exact to keep test robot and mobile app execution synchronized while avoiding re-capturing expected bitmap for all supported devices too often (this can be partly automated)
timing problems -- when you are on the bitmap level, it is hard to tell if you waited "long enough" for some message to appear, disappear, or whatever.
cover exotics like "app continues only after you took a photo with the mobile camera". Generally speaking: Control the built-in periphery (what a contradiction...) of the mobile (in my case, I had to make the barcode scanner "see" specific images -- quite difficult and usually very device-dependent to automate)
It's feasable, though, and such a solution can be very stable and realiable, with a sufficient grade of cost-efficiency in terms of test maintenance effort (depending on what changes how frequently in the app-to-test, of course).
jQuery runs a lot of tests automatically on both feature phones and smart phones, maybe you can use their test system. As a side note, check if jQuery mobile is for you, it seems very cool.
To the best of my knowledge Perfecto Mobile has made some major improvments to its offering and currently offers some major benefits over the others, including price. In the last few months they've added popular devices like Lenovo nePaone. You can see the full list om their website:www.perfectomobile.com. Since they use differentontrol technology than Device Anywhere they are capabable of supporting new devices really quickly. Regarding stability and QTP they also have many advantages over the others. For instance, tools to record your own specific user scenarios and test them repeatedly across devices - this is a great automation tool for large scale projects.
If you are testing bank application you should consider the security issue.
How do you protect your application and application data. Once you release a phone, someone else can get control over it.
My recommendation is to use the on-site capabilities I believe all the above solutions have.
Related
I consider to use GTK+ with Broadway backend for development of device control application.
Device is with functionality similar to broadband modem/router (I intentionally selected example which is familiar for all :-) ).
Device should be controlled remotely via web browser.
My concern is about performance of such control. I'm afraid that Broadway may be a bottleneck.
Probably I'm wrong but even in simple pilot I built it looks not so good.
It will be very appreciated to have your inputs based on real experience.
Thanks a lot
I've used broadway to deploy gtk+3 apps for multiple projects - usually in cases where the client's desktop is locked down, or people are stuck on Windows. Broadway performs significantly better than VNC or RDP.
There are solutions to the single-user nature of a broadway application. For example, I've developed a partial solution: http://tesla.duckdns.org/transparent-proxy-for-broadway-gtk3-html5-backend/ ... if you want security, you need to implement a login page, cookie setting, and port redirection based on a cookie. The example code is commented as such. I've been meaning to complete all this, but every time I've done it, it's been in a highly custom way for particular clients - not something that I can really open-source.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
A medical practice has approached us about using Filemaker as a fully-fledged EMR system with a HEAVY emphasis on using iPads to enter patient records, photos, digital signatures etc which can obviously be accessed on desktops as well. Ultimately they would like such a system to replace their current EMR and takeover all billing operations, patient scheduling and so forth. They only use Macs in their practice.
We have very little experience with Filemaker but found this discussing the Pros and Cons of it however it seems that Filemaker has come a long way since 2009 when that question was asked...
So overall I'm just trying to work out if Filemaker is suitable for such an application or what would be the pros and cons of using a combination of FMP12 and FM Go.
(Sorry if I've done anything wrong - first question...)
Thanks!
As a FileMaker Developer myself, I would say go for it. I agree with Mikhail - You WILL see results faster than any other platform. You can make changes yourself easily and live or you can get a FileMaker developer - just like you would need to get a developer for any application.
With an off-the-shelf application, they tend to be quite inflexible, however I am sure there are systems out there that allow some customisation.
FileMaker is a very capable product. We have written many applications for vertical markets, such as law firms and even a Harley Street plastic surgeon who gathers patient data on an iPad and even sketches the suggested surgery on a picture of the patient.
For those who think FileMaker is a baby, have a look at http://www.businessmancrm.com - this is a full ERP system used all over the world. This is not an advert, but a demonstration of what is possible with FileMaker.
Dollar for dollar, FileMaker will win hands down... and when it comes to time frames, there is no contest. We are open minded - We constantly look for other products to develop applications for ourselves and customers and we have not found anything more viable just yet.
Pros:
Extremely quick environment
Cross platform
Integrate other SQL data sources into application
ODBC Support
Remote Access
Can be run from a USB stick if needed!
Thousands of developers around the world
Large community
FileMaker Inc. have made a profit every single quarter since existence, therefore are stable and do have the backing of Apple!
Reasonable Cost
Make changes yourself
Easy to backup, supports incremental backup
Easy to secure and encrypt data on a network
Supports terminal server
FMGo is free
Cons
High level language (not low level with layout object control) - However does support plugins
Requires FileMaker client (unless a web application/interface is built in PHP or using IWP - Instant Web Publishing)
Proprietary Database (however can easily link into MySQL, MSSQL and Oracle)
Honestly, not worth it.
It's a very clunky front-end for a database.
If you do decide to pick it up your basically stuck with paying a Filemaker developer for the rest of its existence.
One of my clients at the moment has had it for the last ~6+? years after only being with them for the last 8 months i'm trying very hard to push them away from it and onto a newer system.
I can suggest looking at Mastercare EMR, Profile and MMEX.
FileMaker is perfectly capable of it, of course, and I expect you'll be getting first results much faster than with any other approach, especially with the iPad. There's quite a few EMRs out there written in FileMaker. There are downsides, of course; it was always targeted to end users so it ended up fairly inconventional from a common programmer's point of view. Many programmers dislike this. Being end-user it suffers from many simplifications (well, not exactly suffers, actually; this makes development faster as there's fewer choices), but people always want something special so there's a huge number of workarounds to overcome these simplifications. These workarounds vary from relatively harmless to very hairy ones.
For example, to sign documents on iPad you need to add a webviewer control pointed to a generated HTML page via the "data:" protocol. The page is going to have a JavaScript that captures user's touches, paints them on a canvas, and serializes this into a string. Later a script will capture the string, store it in a FileMaker field, and change the generated HTML to use this string so the JavaScript can redraw the signature. This one is relatively simple and since the functionality cannot be obtained in any other way, it's in wide use; there's even a commercial module for around $300. A complex app may consists of dozens of such workarounds; anyone who is not a FileMaker developer won't be able to understand why you need a webviewer to capture a signature or why you use a strange contraption of invisible tabs to display what looks like a simple pop-up list. I.e. it's not like you read a book and work from there; be ready to read quite a few blogs and frequent forums and mailing lists.
That said, it's a good product nonetheless with unique capabilities (that iPhone/iPad client, for one); paired with a good developer it can be very powerful.
Having developed an EMR system at a recent position for 3 years, I can tell you from experience that the requirements for a true EMR system may quickly outgrow the scope of what is easy to do in FileMaker. A few really big, important EMR features come to mind immediately:
Insurance Eligibility verification: is there going to be a way to hit all of the major payers' web services or a third party aggregator to verify insurance eligibility from the iPad?
Insurance Card OCR: sure you can snap a photo of an insurance card, but now you have back office staff typing that information in from an image. We implemented OCR of insurance cards in our EMR and it was a huge cost and time saver.
Security / Privacy concerns: HIPAA compliance is a big deal, and is FileMaker suitably transparent to be compliant? Is there any way to audit who looks at a record? How is the data transferred across the wire?
E-prescribing: All modern EMR's support electronic prescriptions, which carries a complex set of rules and implementation details along with it, I would want to be certain FileMaker could be integrated with an e-prescribing gateway before proceeding.
My main concern with using any off the shelf, cross platform tool to approach a problem as big and complex as an EMR would be getting painted into a corner down the road, having invested a bunch of time and money into a solution that may leave you unable to implement a feature or requirement, whereas paying the up front price of developing a native iOS app (and web apps and whatever else you need to integrate with) would eliminate that possibility, but obviously cost more.
I'm working for a company that has an established application written in VB6. The application is stable and continues to provide the company with good income. However, it is beginning to show its age and noises are been made to port to a more modern platform such as .Net.
Since this is hardly ever a cut and dry decision I would appreciate input on when it is a good time to port a long standing application to a modern platform.
Some of the pros and cons that I have already worked through:
In favor of porting
Finding skills for an old programming language becomes harder and more expensive
Support from the platform vendor ends at some point
Leveraging modern programming practises on the old platform becomes harder or impossible
Rewriting provides the opportunity to improve existing practises
Moving to a modern platform is motivating for the development team
Moving to a modern platform provides marketing opportunities
Against porting
"If its not broken don't fix it"
The cost of rewriting versus the return
Risks associated with the transition from the old to the new application
Upskilling existing software engineers
Some related StackOverflow questions:
What makes code legacy?
When do you say that the code is Legacy code?
One of the things to consider is that porting an application can get more and more expensive over time. I have seen applications writen in 'ancient' languages that were very well developed. But, as happens many times, all the domain knowledge was in the code and in the heads of the developers, not in up-to-date documents.
So in situations like this porting means not only rewriting in the new sparkly language but also reverse-enginering the specs and picking the, hopefully available, brains of the developers. This becomes harder and harder over time.
An other thing is that 'porting' is hardly ever as easy as the Migration Wizard want us to believe. Many wizards produce a half-baked solution that is still constructed according to the constructs and features common to the 'legacy' environment and will hardly be using the new features and possibilities. This might not seem that bad but if you leave it at that level you are in fact making it very hard for developers that know the 'new' language to understand the code and make porting to the next platform or language even harder. That is what I call LEGACY in capitals. Dragging useless stuff around for decades.
The optimal moment to start porting, from a developer's point of view, was yesterday.
The optimal moment to start porting, from a manager's point of view, is tomorrow.
The optimal moment to start porting, from a competitor's point of view, is never.
There are a lot of other considerations to evaluate: opportunity cost (what else could we be doing), capacities for extensibility and growth (what else does the application need to do/be), sustainability with other moving parts (DB upgrades, OS upgrades), etc. The list goes on and on.
Specific to VB6, I would evaluate what limitations are in the way of product progress vs. moving up to the current .Net framework. Ask yourself -- is this really an IF scenario, or a WHEN scenario?
From a general standpoint, the worst time to port an application is when you HAVE to port it. Your situation sounds like an ideal time to begin code migration -- before it becomes a necessity. Given your legacy product's profitability for your company, any situation where you're forced to move to migrate brings pressures around deadlines, scope, etc.
All things considered, your situation sounds like an ideal time to port up to the .Net Framework, well before it becomes necessary.
Echoing jro and especially Erno,
Upgrade before there is a crisis.
Upgrade before the developers move on to other places where they have a chance at working on a modern framework.
Upgrade while the developers that built the original program are still around.
No competent developer will accept a pure porting job, it is not a career enhancing move. But the existing developers will be happy to learn the latest framework as part of a porting effort.
VB6 was released in 1998. March 31, 2008 Microsoft EOL'ed all VB6 support. Your company is so far into the danger zone with this code, it isn't funny.
To add some perspective,
Netscape was still an independent company and they just release Netscape 4.
Clinton was still president
The internet was still a new concept
Intel had just released their hot new Pentium II running at 450 Mhz
The Matrix was still filming
Google hadn't been founded (it was later in the year)
At some point, the company will be forced to upgrade the app because the operating system will no longer support the apis.
You should leave this company. It is career death to stay.
Update because Cody thinks "I am an individual developer":
#Cody -- Rethink your assumptions. I run my own company. Without fail, every time we have slipped behind the last stable release of a platform, catching up has been incredibly painful and expensive. The latest pain point is we are on dojo 0.4.3 and Tapestry 4. T4 and dojo 0.4.3 have this mutual interdependency that we are separating (slowly). Moving to Tapestry5 and/or jquery or even just to the more recent version of dojo is very slow and very painful. The porting has taken over a year because it has to be this long stretched process to keep other development moving along.
The choices are :
stay stuck on the old library
forever (with the problems around
finding/attracting talent),
try to run dual-mode (old/new) code (code doesn't always cooperate,
or freeze development on large chunks of the product during the
port
So far we have been doing a combination of #2 and #3.
Being on old version of either dojo or tapestry means that we have lost the ability of the community to support us and help us with the problems. The advantage of a framework is that other people are doing work that solves your problems. Nobody is solving any VB6 problems any more. Microsoft will not even take money to solve VB6 problems.
The OP's company is completely on their own. Note: that Google was just founded the year VB6 was released. I would suspect that VB6 knowledge has been disappearing from the web and that each year a Google search about any programming problem the OP's company makes will return fewer and fewer results.
This is a business viability risk.
The happy talk about MS supporting VB6 forever and ever is not a good idea. All it takes is some SVP at Microsoft saying: "We can ship the next Windows version in time to make Christmas if the teams do not have to fix these issues that affect only VB6. We will issue a Service Pack later." At some point this can and will happen.
A competitor can come along and introduce a competing product using the latest tools faster ( because the large pool of libraries available when using the latest frameworks.) The OP's company has lost the ability to be nimble because the latest tools and libraries no longer support VB6. (A 13! year old framework!!)
This is another business viability risk.
The fact that this needs to be explained to anyone is a huge, huge warning flag to any developer with any experience who is interviewing at the OP's company.
This reduces the quality and quantity of the talent pool enormously.
Not being able to attract quality talent is another business risk.
The original OP should bail.
Its not just Microsoft and will the Windows support the app. What about things like printers? or displays? Epson is under no obligation to release printer drivers that support a VB6 application.
What happens when the print function stops working for customers on their latest cool 4G-enabled printer?
What happens when customers try to use the app on the now-standard 2000x4000 display and the fonts look all goofy?
What happens when Adobe starts having Adobe Reader advise that the PDF file version should be upgraded?
Seeing a warning dialog popup, not being able to print, use the latest display well, etc will result in customers quietly moving to competitors. They will not even bother to tell the OP's company that they are doing this.
The OP should move on before the layoffs hit.
I'm looking for a way to give out preview or demo versions of our software to our customers as easy as possible.
The software we are currently developing is a pretty big project. It consists of a client environment, an application server, various databases, web services host etc.
The project is developed incrementally and we want to ship the bits in intervals of one to two months. The first deliveries will not be used in production. They have the puropse of a demo to encourage the customers to give feedback.
We don't want to put burden on the customers to install and configure the system. All in all we are looking for a way to ease the deployment, installation and configuration pain.
What I thought of was to use a virtualizing technique to preinstall and preconfigure a virtual machine with all components that are neccessary. Our customers just have to mount the virtual image and run the application.
I would like to hear from folks who use this technique. I suppose there are some difficulties as well. Especially, what about licensing issues with the installed OS?
Perhaps it is possible to have the virtual machine expire after a certain period of time.
Any experiences out there?
Since you're looking at an entire application stack, you'll need to virtualize the entire server to provide your customers with a realistic demo experience. Thinstall is great for single apps, but not an entire stack....
Microsoft have licensing schemes for this type of situation, since it's only been used for demonstration purposes and not production use a TechNet subscription might just cover you. Give your local Microsoft licensing centre a call to discuss, unlike the offshore support teams they're really helpful and friendly.
For running the 'stack' with the least overhead for your clients, I suggest using VMware. The customers can download the free VMware player, load up the machines (or multiple machines) and get a feel for the system... Microsoft Virtual PC or Virtual Server is going to be a bit more intrusive and not quite the "plug n play" solution that you're looking for.
If you're only looking to ship the application, consider either thinstall or providing Citrix / Terminal services access - customers can remotely login to your own (test) machines and run what they need.
Personally if it's doable, a standalone system would be best - tell your customers install vmware player, then run this app... which launches the various parts of your application stack (maybe off of a DVD) and you've got a fully self contained demo for the marketing guys to pimp out :)
You should take a look at thinstall(It has been bought by vmware and is called thinapp now), its an application virtualizer.
It seems that you're trying to accomplish several competing goals:
"Give" the customer something.
Simplify and ease the customer experience.
Ensure the various components coexist and interact happily.
Accommodate licensing restrictions, both yours and the OS vendor's.
Allow incremental and piecewise upgrades.
Can you achieve all of these by hosting the back end (database, web server, etc.) and providing your customers with a CD (or download) that contains the client? This will give them the "download/upgrade experience" that goes along with client software, without dealing with the complexity of administering the back end.
For a near plug-and-play experience, you might consider placing your demo on a live linux or Windows CD. Note: you need a licensed copy of Windows for the latter.
Perhaps your "serious" customers might be able to request their own demo copies of the back end as well; they'd be more amenable to the additional work on their part.
As far as OS licenses, if your vendor(s) of choice aren't helpful, you might consider free or open-source alternatives such as FreeDOS or linux.
Depending on if you can fit all the needed services into a single OS instance or not...
Vmware Ace or whatever they're calling it nowadays will let you deliver single virtual machines under strict control, with forced updates, expiration and whatnot. But it sounds easier to just set up a demo environment and allow remote access to it.
The issue here I guess is getting several virtual machines to communicate under unknown circumstances - if one is not enough?
An idea then is to ship a physical server preconfigured with virtualisation and whatever amount of virtual servers needed to demonstrate the system.
Using trial versions of the operating system might be good enough for the licensing dilemma - atleast Windows Server is testable for 60 days, extendable to 240 when registering.
Thinstall is great for single apps, but not an entire stack....
I didn't try it yet, but with the new version of thinstall you are able to let different thinstalled application communicate.
But I guess you're right a vm-ware image would be easier
Most of the work I do is with what could be considered enterprise Web applications. These projects have large budgets, longer timelines (from 3-12 months), and heavy customizations. Because as developers we have been touting the idea of the Web as the next desktop OS, customers are coming to expect the software running on this "new OS" to react the same as on the desktop. That includes easy to manage automatic upgrades. In other words, "An update is available. Do you want to upgrade?" Is this even a realistic expectation? Can anyone speak from experience on trying to implement this feature?
At my company we have enterprise installations ranging into the thousands of seats. If we implemented an auto-upgrade, our customers would mutiny!
Large installations have peculiar issues that don't apply to small ones. For example, with 2000 users (not all of whom are, let us say, the most sophisticated of tool users), tool-training is a big deal: training time, internal demos, internal process documents, etc.. They cannot unleash a new feature or UI change without a chance to understand how it fits in their process and therefore what their internal best practices are and how to communicate that to their users.
Also when applications fail, it's the internal IT team who are responsible. Therefore, they want time to install a new version in a test area, beat it up, and deploy on a Saturday only when they're good and ready.
I can see the value in making minor patches more easy to install, particularly when the patch is just for a bug-fix and not for anything that would require retraining, and if the admins still get final say over when it's installed. But even then, I don't believe anyone has ever asked for this! Whether because they don't want it or they are trained to not expect it, it doesn't seem worth it.
Well, it really depends on your business model but for a lot of applications the SaaS model can end up biting you. It's great for a lot of things but for some larger applications the users are not investing as significant amount up front and could possibly move to something else before you've made any money.
See
http://news.zdnet.com/2424-9595_22-218408.html
and here
http://www.25hoursaday.com/weblog/2008/07/21/SoftwareAsAServiceWhenYourBusinessModelBecomesAParadox.aspx
for more information
One of the primary reasons to implement an application as a web application is that you get automatic upgrades for free. Why would users be getting prompted for upgrades on a web app?
For Windows applications, the "update is available, do you want to upgrade?" functionality is provided by Microsoft using ClickOnce, which I have used in an enterprise environment successfully -- there are a few gotchas but for the most part it is a good way to manage automatic deployment and upgrade of Windows apps.
For mobile apps, you can also implement auto-upgrades, although it is a little trickier.
In any case, to answer your question in a broad sense, I don't know if it is expected that all enterprise apps should make upgrading easy, but it certainly is worth the money from an IT support standpoint to architect them to allow for easy upgrading.
If you're providing a hosted solution, I wouldn't bother. Let the upgrade happen silently (perhaps with a notice that you did it). If you're selling an application that's hosted on their servers, let the upgrade decision be made by a single owner, not every user of the app.