Can anyone please compare all the features of MS-Visual Studio Load Test tool and JMeter tool?
Here I already got few comparions with both,
Price
JMeter: free and open source
MSVS: Test Professional costs around $2000 per developer.
OS supported
JMeter: any
MSVS: Windows only
Protocols supported
JMeter: HTTP, FTP, JDBC, SOAP, TCP, JMS, SMTP, POP3, IMSP
MSVS: HTTP
But I need a comparison rather than this, Also I need to prove JMeter is worthy and better than MS-VisualStudio Load Test.
The main reason of choosing JMeter is that JMeter is being actively developed and supported and Visual Studio 2019 is the last version to support Coded UI and Load Testing features, they will be removed from the next releases.
So if you are looking for a load testing tool which will live at least several years - go for JMeter.
You're being disingenuous on the protocols supported. MSVSLT supports any protocol supported in Visual Studio, which includes all standard protocols for client server, web, even raw sockets mode.
Both are developer tools built for use by Developers.
It is true that Microsoft is abandoning the performance testing market with their tools. This should be eye opening on how Microsoft views the importance of performance testing in their developer community.
Price is the absolutely last criteria you should be looking at for a delivery item on performance testing. Why? Because you can get a lot of cheap tools/free tools which may not exercise your interface, may not support your monitoring needs, will not support your analysis and reporting needs, and are flat out unusable on your reference platform and by your intended user population.
Start with your analysis and reporting. This is where the value is added. Running the load test is simply a controlled model for the production of timing records and resource measurements This will provide a subset of tools that meet your business mission goals.
Next, look at your environment, for a list of tools which will collect resource measurements while your test is running.
Once you have a subset of tools that meet your business mission needs and your technical environment needs, then take a very keen look at your intended user population. You may have the most effective tool on the planet, but if your team isn't capable of delivering high value, then you as well be deploying the least effective tool. Your return on effort will be about the same.
Lastly, look at license model. If you have no authority to authorize based upon price, then you should also lack the authority to reject based upon price. Pass or reject on technical and mission capabilities.
Related
Microsoft are pushing their ALM (Application Lifecycle Management) tools such as TFS very hard but often gloss over the fact that major features are only available for managed (.Net) code. eg: Intellitrace is c# and VB-only
Are there any benefits to using Lab Management with a pure native application?
We have two major apps, one with a Java UI and the other MFC. There have been suggestions that the Lab Manager will be broadly rolled-out in the company but I have strong doubts that we will gain anything.
According to this March 2011 table of test automation support, Java is not supported and MFC only for basic controls.
[edit] Prior to the latest vNext release, we couldn't use their TestManager for unit tests unless we wrap our C++ code in .Net layers with C++/CLI unit tests.
So it seems that none of the various ways of testing code can be used for our apps.
Absolutely! Lab Management could help out quite a bit for all sorts of non-.NET applications. It's great for setting up development or test environments made up of multiple machines. You can use the data collectors with Microsoft Test Managers to collect rich data from each of the machines in your environments when you are running test cases or performing exploratory testing. Whenever you find a bug, you can file a bug and each of the data collectors on each of the machines in the environment under test will be queried and attached to a pretty nice bug report for you. You can snapshot, rollback, etc. You can automate test runs and deployments of builds to environments.
You can use Lab Management even with shared or dedicated environments per testers. If your environments require it, you could even use network isolation between the environments to make sure clones of the environments don't cause problems with other clones.
Lab Management also helps if you need to test your apps against multiple configurations. Imagine you need to test your MFC or Java app on Windows XP, Vista, Server 2003, etc. You could spin up individual environments with the different configurations and test against each of them appropriately. Microsoft Test Manager can keep track of pass/fail results for your test cases in each of those configurations as well.
You're absolutely right though. Certain data collectors that come out of the box won't work well or not at all with non-.NET applications. However, the data collector system is completely extensible. If there is something you want to automatically gather, you can create your own custom data collector for use in Lab Management.
There's a lot you can take advantage in Lab Management with testing against non-.NET applications.
Unit tests for native C++ are supported in Visual Studio 11 so there is no need for wrappers. see this article. http://msdn.microsoft.com/en-us/library/hh270864(v=VS.110).aspx
I have requirement of preparing an in-house Project Management and accounting app using Microsoft Dynamics. My requirements are similar to what explained in the below page:
http://community.dynamics.com/product/crm/f/117/p/54453/98182.aspx
Can someone suggest that should we use ERP or CRM? And which one to use i.e. SL, GP, NAV, AX? And why?
CRM is probably the first choice to eliminate. Project management is usually an internally facing application, while CRM is by definition, externally facing. Secondly, if you need to maintain budgets, Dynamics CRM doesn't have anything built in for this (a general ledger for example).
As for the others, each will have its own costs and the extent of support you can get for any of them will vary depending on where your business is located. In some areas you may be able to get good SL support but no NAV or AX for example.
As for one you may not have considered, have you considered Project Server / SharePoint? If you need really heavy weight PM capability, Project may be your best bet. SharePoint can do some PM stuff. There's at least one book around by Dux Raymond Sy, published by O'Reilly. He's also done at least one webcast. Both are based on SharePoint 2007.
HTH
Of the Dynamics ERP products, SL is the one most focused on the project management (i.e. Project Accounting) space. CRM doesn't have a lot of project management capabilities built in, but is probably the most customisable and extendable of the dynamics range.
If you're after something that needs to cover the financial aspect of PM (e.g. billing, tracking costs etc) then you should look at the ERP options. If you're not worried about the financial side, then building a custom solution within CRM might be an option.
Came across this thread in a search I was doing. Hope Sukhminder Singh is still listening...
Sounds like you shouldn't abandon Dynamics CRM, a tool which your organization has tried and tested for nurturing customer satisfaction and turning it into ongoing revenue. On the other hand, you need to maintain a smooth accounting and billing relationship with the same customers - and for that, you'll need an ERP solution. As ccellar suggested NAV can do that, or even SharePoint, as suggested by Mike. I'll hazard a guess your organization already has SharePoint, too.
Now, what about the integration? You know, devising an effective, scalable, and future-proof way for getting MS folk to "talk" is quite a challenge! Also, you need a solution that places stress on human, as well as system workflows. The human factor can be decisive in time-critical projects.
Sukhminder, are you going to be coding solutions on either end? That's one way to go, though often, that option comes with high overheads: dragged-out coding projects, functionality that can be difficult to maintain, and even harder to modify, and serious concerns when one of the systems is upgraded or replaced.
From another angle--are you considering BPM? I'd urge you to.
BPM (Business Process Management) software suites are becoming an increasingly practical and mainstream option as an organization's central integration hub. BPM lets you rapidly map out and control mission critical processes involving multiple systems (as in your scenario). BPM lets you visualize the players, processes and apps over time, and when it comes to adjusting, remapping, and remodeling your workflows, you may have to do some coding, but a large part of the work can be done by experienced, non-programmer BPM users.
There are a bunch of vendors out there, each with its own pros and cons. For the job of connecting MS CRM and MS ERP/Sharepoint, here are 3 candidates I have come across.
Kofax's TotalAgility BMP integrates between Dynamics CRM and SharePoint, by leveraging SharePoint capabilities. The solution obviates elaborate coding by supporting workflows, rules, and user screens. It "orchestrates" processes between itself and other MS and products, most notably SharePoint, CRM, Lync, Visio, Outlook. They enable "in-flight" process change and dynamic BPM, so that down-time on your production is minimal. See the data sheet.
Sequence Business Process Management from PNMsoft. Provides integration with systems from many vendors. The forte is on human-centric processes, with a strong bent for Microsoft products. Sequence lets you integrate with existing systems using wizard-based connectors. When your organization changes, Sequence lets you "hot-swap" your business processes fast, without down time in your production.
MuleSoft's CRM-ERP integration. Their strong point is application integration, for connecting (legacy) systems from a range of vendors, including SAP, Oracle, Salesforce.com, and MS. The Mule ESB is a lightweight integration platform. It comes with a library of connectors to quickly create connectivity with all systems and services, whether on-premise or in the cloud. When adding or modifying an endpoint, you can easily update your integrations to reflect the change.
HTH some....
I'd start off at the Microsoft Dynamics site and explore what each product has on offer. They even have an ERP selector tool for you to try out with just a few questions. Why not contact Microsoft yourself and they could provide a list of potential partners that work in your area - it will be an important decision and they would better guide you through the selection process.
After a few projects which also had an accounting part, I would not recommend to use Dynamics CRM (at least for the accounting part). That's not what it's meant for and you have to spend much effort to get to a level of Dynamics NAV for example.
On the other side: why not combine both systems and use their strenghts.
The question says it all, we know most of the hosted web-based UI prototyping tools out there, but we would like to have ours hosted on our own internal servers, preferably with on-line multi-user collaboration functionality (i.e. users modifying the prototype, making comments, etc. in parallel).
Any suggestions will be appreciated.
Sketchflow (in the top-end version of Expression Blend from Microsoft) meets almost all your criteria. It ain't cheap, but it is very powerful.
The deployment package of a Sketchflow build can just be placed on an internal server (no IIS required to deploy).
Multiple users can overlay their comments and pen drawings over the top of the screens. Their feedback is packaged as a unit and sent back. All feedback can then be loaded back into the Expression Blend project and the feedback from 1 or more users viewed overlaid on the correct screens.
It does not meet your multiple-user authoring requirement though, but as they say "too many cooks...".
Most tools are either desktop based or hosted. Seen very few which offer a downloadble multi user version. iRise is one choice with the editor as a desktop product and a centralized server for sharing among users. The budget is typically from $50K to $250K. A similar option exists for Serena composer as well, not sure of the price though.
Both iRise and Serena are not real collaborative tools, the central server is only for sharing the finished prototypes and getting feedback.
If the requirement is for a completely web based multi user tool then 10screens can be an option - http://www.10screens.com. The same product available on the site in a hosted mode can be downloaded and installed on your own servers.
Microsoft Team System appears to be a great platform for process-oriented systems implementation, however if you strip out access for the BAs, PM and Business Users and just purely use it within a Dev team does it have any more value than just using Visual Studio Professional, SourceSafe, a Defect Tracking Tool and a continuous integration server like CruiseControl or TeamCity?
Yes. Every replacement technology you've mentioned is something that is supported by the Team System package (either in this release or the next). All of these components are designed to integrate and work with each other in TFS. This is a high priority of the TFS team for all components. The result is a set of features which in most cases seamlessly integrate with each other.
I'm not familiar with several of the other projects you mentioned but it's unlikely that they integrate as well with each other as the corresponding TFS components. This is not to say they have no integration or perform poorly as products. Just that they are not designed ground up to work with each other. Hence the interaction will not be as crisp as the TFS components.
Is this valuable enough to continue using TFS? Don't know because it would be highly dependent on how much you value this integration.
One of the big selling points for TFS for my team is the coherency it provides to our overall product life cycle. We do allow BAs, PMs and Business Users to have certain levels of access to TFS, but even if we did not, the product would still be of great value to use. The ability to manage our workflows within TFS and enforce consistency across the development team is great.
Some of the features that TFS provides that we use: security, reporting, work flow management, integrated builds, email alerts, branching / merging.
Could you pull it off with a hodge-podge of other tools? Probably, but it wouldn't be as easy to manage and maintain and you probably wouldn't be able to pull out the kind of data necessary for reporting and tracking the way you can with TFS.
On a sidenote, if your counting on Visual SourceSafe as your repository I would highly suggest looking elsewhere. From personal and business experience, I can attest that it cannot be counted on as a stable/robust repository.
My thoughts.
Sure it has value. There are a ton of client features only in the Team SKUs (don't let the name fool you -- they are primarily just the new "super premium" kitchen-sink versions, that also have the nice bonus of including a server CAL for TFS.) Exact specs available here: http://www.microsoft.com/visualstudio/en-us/products/teamsystem/default.mspx
Looking specifically at the collaboration features, again there's clear value in a system whose components were design to "just work" with each other. The setup is streamlined (though it has a ways to go); the UIs are consistent and accessible from each other; the backend feeds a unified reporting/analysis service. If you have a large team, the overall perf/scalability also far exceeds what the typical OSS suite is capable of at the moment.
The question is whether it's worth the $$ to you. Why use Visual Studio Professional instead of SharpDevelop? Why SourceSafe instead of Git? Why not Notepad and specially labeled folders?
All of the commercial products are commercial for a reason (ok, maybe not SourceSafe!). If you want something with a broad feature set, tight integration, well-defined support & testing lifecycle, good fit & finish, etc then it's usually worthwhile to spend the $$ and let your development staff get on with their work. If you don't mind doing setup & troubleshooting yourself, switching between several applications as part of the development workflow, losing the ability to query & report on team statistics as a whole, etc then by all means go open source -- many OSS dev tools are very solid nowadays.
My organisation is in the final stages of acquiring CRM 4.0 for use as a general purpose software development platform. The company who is selling it to us has convinced upper management that CRM will solve all our productivity problems and make software development as easy as point and click. (They don't read Brooks.)
Having resigned to the fact that I can't stop CRM from being foisted upon us developers, I have been doing research on how to manage the complexities of large scale CRM development.
I have so far identified the following complexities that need to be addressed:
CRM seems wholly incompatible with basic configuration management practices.
Keeping the black box CRM database in bidirectional synchronisation with external LOB systems is both very hard and critical to project success.
What other complexities must I take into account when building a large scale CRM application?
What limitations does CRM have as a development platform?
Edit: This topic provided additional insight.
I've worked with MS CRM 3.0 and now 4.0 here's my take:
Whenever possible focus on standard best practices. Don't get overly confused by what CRM is doing or wants you to do.
Don't be afraid to break what's "supported" by MS. With some caveats on 2 major factors - will your company let you think outside the box to solve problems and do customizations/integrations that are not officially supported? - and are you comfortable enough with .Net, SQL, javascript etc to weave through their code and implement what you need?
I have sometimes banged me head 100 times trying to do something in a "supported" fashion when one small tweak to a js file here or a small db modification there gave me what I needed.
If constant data integration with other LOB apps is critical you should consider a 3rd party tool like Scribe (http://www.scribesoft.com/). It's not cheap but can basically get you 90% of the way when it comes to integrating with your other LOB apps.
As a general rule, MS CRM is great at contact management - doing things like tracking appointments, doing mail merges, etc. Could you use it as your core HR system - probably. Finance system - maybe a bit more difficult. The further you go from it's core competency of performing contact management the more custom work you'll have to do. The more custom work you have to do the more you should consider if MS CRM is the right solution to that problem.
I know you're likely well underway into your deployment of Dynamics CRM, but just a few quick tips:
I'd avoid making unsupported changes purely because it becomes too hard to track the changes eventually. Since Dynamics CRM allows developers to make C# Plugins and access to web services, it's usually unnecessary to make unsupported changes for anything non-trivial. Plus you run the roulette of having to hide changes from MS if you have to call their support. I know many people will include external javascript files (jquery, etc) and other somewhat benign changes, but try to mentally stop yourself when an unsupported edit involves anything non-visual.
Look into the phrase Microsoft Dynamics Xrm, there are several books on the subject that are excellent, http://www.thecrmbook.com/ is particularly good because it comes with some nice custom code to use with your CRM.
Source Control your customizations xml's and don't let people touch the database, also, Google Halan CRM tool, and use it for scripting out CRM customizations and javascript files. Easier than writing custom powershell scripts to do the same job.
Transaction Support
If your application require transaction support from the underlying platform, Dynamics CRM is not the correct choice. The reason is because currently Dynamics CRM SDK web service doesn't support transaction.
The reference thread is here : Does MSCRM web-service support database transactions?
Since you would like to utilize Dynamics CRM as a platform, that means all the business logic should utilize Dynamics CRM SDK Web Services as data access layer. But imagine without the transaction support and you're invoking a series of web service calls as a unit of work, and one of the web service calls fails. That means you potentially will encounter data integrity issue.
Configuration
Usually i create a custom entity called Configuration, which will store all the necessary related configuration for the current CRM application. After it has been created, you can use Dynamics CRM SDK Web Service to read all the necessary configurations from the Configuration custom entity