1. Measuring End User Experience

In terms of understanding your system behavior and ensuring it supports your day-to-day business operations, measuring the end users’ experience is crucial. This is what Scapa TPP is designed to do. It measures and records the end user experience as well as the server side experience for each user, not just a random sample, enabling you to identify performance issues easily and quickly and attribute them to specific layers of the system – the application(s), desktop delivery (e.g. Citrix or VMware issue), or network stack.

By measuring both the end user and server experience metrics and the server side performance metrics, you can identify performance problems attributable to network issues between a user’s desktop and the back end system in seconds. This is essential in quantifying the experience of users in different geographical locations, in multiple offices.

In addition to end user metrics, Scapa TPP’s advanced logging capabilities (again, for each and every user) deliver additional insight into environments, helping pinpoint the issues when performance is poor by providing answers to questions such as:

– is it the same hosted virtual desktop that has issues?
– is it the same user?
– at what point did the user fail in the login sequence?

This level of detail is invaluable in proving what is and is not at fault with a badly behaved system.

2. Steady State Analysis

It can often be the case that Thin Client or VDI system behavior is unpredictable and user experience is not constant. This can only be revealed when analyzing the system at steady state. It is imperative, therefore, that tests can be run at a fixed load for a period of time, before adding additional load. It is also crucial that the ‘login’ portion of the test can be isolated from the ‘main’ load/stress/capacity test. Observing the behavior of your system in steady state with Scapa TPP, will give you the information you need to understand how the system will continue to behave. Simply adding load every few seconds (as some other tools do) does not constitute a proper test and diagnostic solution as the system is always in a transient state.

Steady-state analysis is, therefore, an indispensable component of testing, diagnosis and for performing ‘what if?’ scenarios, for example:

what if there are 100 users on my system, running workload A at a transactional load of N activities per minute, then another 150 users log in and go on to run workload B at a transactional load of N activities per minute?

In this instance, with Scapa TPP, we can easily identify the cause and effect of one workload type on another – we can see both the steady state AND transient state within a single test.

3. Transient, Start-Up or Warm-Up State Analysis

In many Thin Client and VDI systems, the steady state as described above (see 2) will not be achieved until sometime after the system is started or initiated. This initial situation is often identified as a transient state, start-up or warm-up period. Scapa TPP is capable of testing this transient state to enable you to understand your system behavior and avoid taking risks on the reliability of your mission-critical applications.

4. Providing Custom Workflows and Test Scenarios

In addition to live interaction with tests, Scapa TPP is flexible enough to allow the tester to use pre-prepared custom workflows and custom automated test scenarios. This is made easy with the Scapa Control Sequences (macros) which allows the tester to define a workload model to suit any particular workflow and application mix.

5. A Complete Understanding of the Performance and Scalability Characteristics of the System

Scapa TPP provides unrivaled insight into the particular performance and scalability characteristics of any application running on a Thick Client, Thin Client, VDI or other server side computing system by correlating the end user experience (e.g., how long did it take for the user to see the ‘Save As’ Dialog?), with the server side experience (how long did it take for the server to generate the ‘Save As’ Dialog?) and server side metrics, such as %CPU Utilization, Memory Utilization etc. Other useful measurements could be, e.g. how long does it take for a query to return data in your application under test (such as JD Edwards/SAP/Oracle Forms etc.), and how long does it take to send an email via your email system?

6. Combining Live and Predefined Tests to Include Data from Various Geographical Locations

Scapa TPP provides the ability to run live interactive tests (where the user load can be increased and decreased) with real time results alongside predefined, scheduled ‘canned’ tests (via Scapa Control Sequences – see 4). These Scapa Control Sequences are invaluable when running benchmark tests and for introducing load at pre-determined intervals. This allows scope for, for example, ‘follow the sun’ style tests, where users from different offices in different time zones are added to the test.

7. Concurrent Log In Capability

The ability to truly login many users concurrently per load injector is a must for login storm testing. Scapa TPP provides true, concurrent login capability, from each load injector via the Scapa Engine, for Citrix, Microsoft and VMware View clients. Whereas other tools will limit you to logging in a single user every 30-60 seconds per load injector, it is not uncommon to login 20 users at a time per Scapa Load Injector.

8. “Headless” Log In via a Web Broker

To enable concurrent log in capabilities when using a web broker, Scapa TPP gives you a ‘headless’ login capability for Citrix, VMware View, Microsoft RDS and other sessions via a Web broker, without the use of a GUI web browser. This includes headless support for both Citrix Web Interface and Citrix Store front broker, thus enabling true login concurrency per Scapa load injector (see 7).

9. Distributable Engine Manages Messaging and Synchronization from Multiple Locations

With Scapa TPP’s powerful, distributable Engine technology, we maintain a centralized communication channel between the client and its running server side sessions in order to control the user, send and receive messaging and synchronization logic from each running user from multiple locations, simultaneously. Other tools simply launch sessions providing limited interactive ability to control the test dynamically at run time or via a pre-defined macro. The highly scalable and optimized, multi-threaded Scapa Engine technology is built with C (programming language) and enables Scapa TPP to be virtually CPU insignificant on both the client and server side, enabling tests to scale to hundreds of thousands of users.

10. Test User Recovery- Maintaining load under functional failure

Automatic recovery is crucial when running tests. When testing poorly behaved systems or applications that functionally fail under concurrent load, it is imperative that the failing user can stop running the test script and restart the automated GUI test script, then perform a cleanup operation before running the main scripted activity. All this without logging the user out of the server side session. It is also imperative that if a user becomes disconnected or logged off the system during testing, that user should be automatically logged back in to the system (to maintain the requested load and steady state). This level of capability is missing in other solutions but with Scapa TPP, this, along with the ability to ‘log back’ information to the central location about the running of the test and issues at a per-user basis, is available.

OK, we did say that there are many more than ten reasons …so here are a couple of them:

11. Minimal Storage Space Requirements for Test Results

Scapa TPP provides full access to all test results via SQL to the embedded relational database, thereby requiring minimal results storage space.

12. Test Data Control

Scapa TPP also provides flexible, dynamic and centralized control of test data which allows the most complex data driven applications to be tested, independent of user distribution and population. The appropriate data is supplied to the running test script at runtime from this central management of test data.