** There is probably some confusion here as I have been with Scapa Technologies for close to 15 years and have been part of the product development ever since but did not understand what was being refereed to as a "Scapa beta".
Some background information may be useful to avoid any misinterpretations (even if probably too detailed :-) - Scapa Technologies was founded in 1998 and product development started with a flexible platform for testing and performance validation. It was designed to be generic and provide a framework for adding support for different protocols and applications. - After covering few "essentials" like HTTP, ODBC, mapi... first application support was added and it was for Essbase OLAP performance testing. Focus was very much on simplification, automation and optimisation of the test creation process and this approach and some of the methodologies "leaked" to later products. User transactions with the system were being captured, parametrised and processed to create valid tests. - Scapa tests are always created as a transactional (data linked) sequence of API or protocol calls making them hard to distinguish from real users, but much easier to control. - Some 13 years ago we opened up a Scapa API to allow our partners to add support for additional technologies and applications but no results came from that and development of the Scapa product was done fully in house ever since. - First Scapa product for Remedy testing came out some 10 years ago, allowing automatic test creation based on user interaction with the systems through Remedy user tool (AR system API). We have worked with BMC to get all that was needed to recreate user transactions in a test. - Scapa is using a standard client to capture transactions and also acts as a client to gather application and form data from the server needed in the process of crating the valid transactional sequence or Scapa test. This was not a trivial development effort (even though we already had a stable platform to work on) as it took number of development man years to make the whole process correct, practical and simple for end users. - Over the years parts of the Scapa Remedy product were completely rewritten (speed optimisation to allow very large number of users to be simulated from a modest hardware) - In the last 10 years Scapa for Remedy was used to test, validate, optimise and maintain number of systems of various size including some of the largest Remedy deployments (largest one that I have been involved with was designed for user support of some 20 million customers). - As the User Tool has been phased out Scapa Remedy technology, methodology and knowledge was used to replicate in the Mid Tier space what we have already done for User Tool allowing side by side (User Tool + Mid Tier) or pure Mid Tier testing. - Few other technologies were added to Scapa suite over time, probably most relevant one being support for thin client (Citrix, RDP, VMWare) but also allowing "client - server" testing using real clients (User Tool, custom clients or web browser). This permits client side GUI to be driven through a series of user actions (mouse clicks or key presses) instead http protocol or api. One thing that I would agree with is that blasting "random" API calls at server would never accurately recreate transactional nature of user interaction with Remedy system and therefore is of little or no use. Scapa however was never going in that direction. Armen Avedisijan Scapa Technologies _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
