Using the correct types of Citrix testing are the secrets to successfully delivering systems which do what they are supposed to do.
Many projects fail because the level of testing undertaken simply isn't sufficient. With most of these failures caused by a heavy reliance on using acceptance testing as the sole form of testing.
Whilst the acceptance tests can give a good idea of whether the system delivers what the customer wants. It doesn't guarantee the stability or usability of the system. It's like building a new car and relying solely on successful User Acceptance Tests (UAT) to prove whether the car is ready to be sold to customers.
No car manufacturer would ever rely on just UAT as their only form of testing. They know that the consequences of not conducting other tests will result in many costly lawsuits. Likewise acceptance testing shouldn't be the only testing done in a Citrix project.
"It took me less than an hour to turn their Citrix farm pear shaped!"
I've seen many instances where an organizations Citrix server farm is deemed to be ready for go-live after undergoing a successful UAT. It's only after I've carried out further testing do problems start to surface and things suddenly start to turn pear shaped.
Fortunately if these issues are discovered before the Citrix farm has actually gone 'live' into production, the costs in rectifying these issues can be minimal.
However, some organizations get hit with huge costs when problems which could easily have been fixed in testing, appear in the 'live' production environment. Once the problem has passed into the 'live' production environment the costs of fixing the problem will increase substantially.
"I don't need to do all this other testing, I work for a small company. Only the big companies need to do this stuff!"
Testing is important for any business irrespective of size. Smaller companies are more at risk from the failure to adequately test, as they generally don't have the resources to cope when things start to go wrong. They also tend to design Citrix systems to severe cost and time constraints.
Whilst in a large organisation a Citrix farm may have a secondary reduced capacity site (for example 60% of primary site) which can used for Disaster Recovery should any outages occur at the primary site. Or may even run with a 'live-live' configuration whereby they have twice the expected capacity, so should one of their data centres go down, the other can cope satisfactorily.
A smaller company may just have one site with no additional servers available to take the load should servers start to fail. Such a scenario could put many smaller businesses out of business should they be unfortunate to be struck by outages and failures.
Testing Citrix infrastructure is essential but more importantly testing the end to end infrastructure will provide greater reassurance in any project. As I stated on my homepage, when things do start to go wrong, the first port of call for blame in the majority of implementations is Citrix. This isn't very surprising, as Citrix is the final tier, the presentation tier, the link between the systems and the users.
It's the most visible part of the thin client system, with it's client software, web interfaces, program neighbourhood agents etc. So when something unexpected happens, the angry mob gathers seeking vengeance on the Citrix team.
To make things worse many of the accusers generally don't appreciate how Citrix works and as such this can make it doubly difficult to apportion blame away from Citrix to actually where it is due.
There is nothing worse than being badgered about an application problem when it's got nothing to do with Citrix.
Proper testing allows us to not only develop a stable usable system but to prove that any issues being experienced are related to Citrix or, are not related to Citrix. Trying to argue your case without evidence is only going to make it more difficult to prove that Citrix is not the issue and something else is causing the problems.
The starting point of any testing involves functional testing, sometimes this is referred to as module testing or even system testing.
It's important to conduct Citrix end to end testing as this will determine whether the backend systems are a bottleneck and if so, this will affect Citrix usability.