This is harder than you might expect because it's hard to tell whether a passing test is a false positive (i.e. the test passed, but it should have failed).
It's also hard to convey to the testing system what is an acceptable level of change in the UI - what the testing system thinks is ok, you might consider broken.
There are quite a few companies out there trying to solve this problem, including my previous employer https://rainforestqa.com
Rainforest QA is an on-demand QA solution. It’s our mission to enable development teams to deliver bug-free software while moving at the speed of continuous delivery. We are truly a global team, allowing us to bring together the best and most diverse talent. Our commitment to the distributed team model and to our company values has earned us multiple culture and workplace awards (https://www.rainforestqa.com/about) and helped us build a diverse team of individuals working toward the same goal: change the way QA is done.
The post mentions "Remote Global", but are you sure about that ?
I've applied two weeks ago but was rejected for location reasons:
Below is the exact feedback I received:
> Thanks so much for taking the time to apply to work with us. However, because of your location we are unable to move forward with your candidacy at this time. If your circumstances changes in the future, please feel free to apply again.
Rainforest QA is an on-demand QA solution. It’s our mission to enable development teams to deliver bug-free software while moving at the speed of continuous delivery. We are truly a global team, allowing us to bring together the best and most diverse talent. Our commitment to the distributed team model and to our company values has earned us multiple culture and workplace awards (https://www.rainforestqa.com/about) and helped us build a diverse team of individuals working toward the same goal: change the way QA is done.
The "+n" syntax is not standards compliant, from the tail info page (on fedora 19):
On older systems, the leading '-' can be replaced by '+' in the obsolete option syntax with the same meaning as in counts, and obsolete usage overrides normal usage when the two conflict. This obsolete behavior can be enabled or disabled with the '_POSIX2_VERSION' environment variable (*note Standards conformance::).
There is a more important benefit to using the -prinf '1' approach - which is that it won't miscount the result if any of the filenames contain newlines.
I've used the c7000's, and HP didn't require us to use professional services to install them.
I haven't had any problems with the mezzanine cards, but I do have problems with the VirtualConnect Flex-10 - applying configuration changes seemed to take an increasingly long time the more devices in the configuration. The other big annoyance with the VC is that the blade needs to be off to add more virtual NICs - so now I normally just add them all when I provision the blade and leave them disconnected.
The c7000's also seem quite picky about the versions of firmware installed on the various components.
I believe you can chain several c7000's together for management to reduce the pain a little. And you can always invest in HP's management software.
A plus for the c7000's is the flexibility of the blades: you can get HPUX versions (if you're unlucky enough to need HPUX), half and double height versions. Using the different sized blades does require some planning, as they impose some constraints - but even with this it does introduce some flexibility.
I used Dell's bladecenters a few years ago and they were okay, I know IBM/Fujitsu/ have them as well, so I wouldn't say there is no competition in the market.
I played with a UCS system (just one chassis) in our lab (~6-12 months ago), and I can't say I was hugely impressed. The documentation wasn't what I expect given my experience with Cisco's switch gear, and we had to update the firmware a couple of times to get past bugs. Maybe this is no longer the case. I didn't play with the API.
It's my understanding that if you want to do multihop FCoE then you have to stick with the same vendor for your switches, due to the different ways they implement FCoE.
IMHO I think the UCS cost is a big turnoff, maybe if you're in a huge environment (100's of chassis) the API is enough of a win to overcome the high cost - or maybe you can get a big enough discount.
WRT to Cisco staying in the market, I think they will for two reasons. The first is it increases their ability to sell more switch gear - you want FCoE or better link utilisation then, you need data center ethernet, which means you need new switches - and Cisco can now sell you both. Secondly it allows them to push FCoE and disrupt the FC market, which means they can sell more switches again.
It's also hard to convey to the testing system what is an acceptable level of change in the UI - what the testing system thinks is ok, you might consider broken.
There are quite a few companies out there trying to solve this problem, including my previous employer https://rainforestqa.com