You pay for the number of users that you're going to be utilizing. In order to scale up, you would have to pay for additional users, but for our use case, we're able to scale fairly easily.

We have a license for 500, but we're using half of that for our initial workflow.

For maintenance, as far as I'm aware, there's only one person really working on the maintenance of it and we only really have one user consistently using the software. He's a QA person. 

We don't have any plans to increase our usage. Even though we've had it for a while, we have a major push to start utilizing it more. I imagine we'll probably be using it and utilizing it across our QA team in the next year. We're in the process of determining whether we're going to keep it or not due to the fact that it is so expensive. That's why I've been researching alternatives for the RadView.

In order to scale up, it's really on the onus of the user of the product. We have a registration service for students, and we want to ensure that it would handle any registration loads. We pushed it to the target load, which is 3000 VCs, and we had to add more resources to the load machine, and also to the console component. We added more RAM and CPU in order to handle the target load, so we can drive it at the application test.

We upgraded from 2,000 to 6,000 users with no problems.

Not applicable – we have had no need to scale it significantly.

It scales very easily. You have to put together a file of how many test samples you want, and we pulled a sample that ranged from 5 to 20 and to 1500.

Scalability depends on what you want to do. For example, if you have your own way of scripting, in a specific language, then you need to have the documentation for it.