Research Points

  1. Protecting Tenant Privacy
    Unlike the Infrastructure as a Service (IaaS) where multiple tenants share resources isolated through virtualization, SaaS tenants share the same virtual machine, storage and database . Users’ data are stored in a database as rows in tables that the tenants’ share. In that database the rowID is what distinguishes one row from the next. In this area, security concerns run high that misconfigured application code or an error in an access control list may put tenant information at risk of theft and misuse.
  2. Required updates to data model and the support of nosql database
    Being cloud based and implementing the SaaS model, supporting large numbers of concurrent users is important, but because app usage requirements are hard to predict, it’s just as important to dynamically support rapidly growing -or shrinking- numbers of concurrent users.
    Large numbers of users combined with the dynamic nature of usage patterns is driving the need for more easily scalable database technology. Relational technologies may not be the best solution to get the dynamic scalability and level of scale needed while also maintaining the performance that users demand.
    Many are turning to NoSQL for help.
    NoSQL databases have a different model from normal relational data model. For example, a document-oriented NoSQL database takes the data you want to store and aggregates it into documents using the JSON format.
    Aggregating this information may lead to duplication, but since storage is no longer cost prohibitive, the resulting data model’s flexibility, efficiency in distributing the resulting documents, and read and write performance improvement, make it an easy trade-off for cloud-based applications like TESTICIDE.
  3. Isolating tenants in term of performance, so that tenants that require high processing power does not affect the performance of other tenants
    As mentioned before -point 1. Protecting tenant privacy- in difference between IaaS and SaaS with multi-tenancy model, when working over the cloud, all tenants share the same resources regarding the memory and the computing power.
    Consider the case that one of the tenants has a lot of projects and is running a lot of tests, this tenant -Fat tenant- will consume most of the computing power and the memory which will slow down the execution of other tenants. All tenants will be affected by this fat tenant.So we need to figure out some method to isolate fat tenants from its neighbour thin tenants to keep the performance always high for all clients, or distribute computing power between running tenants equally.
  4. Load distribution to leverage cloud computing power to provide fast feedback test results, as UI and load testing consume high processing power
    To run UI tests, we need high processing power especially when running lots of tests at the same time like running a Regression test on the whole project which may take the whole day to get the results.
    An appealing solution for this problem is to distribute the running tests on multiple computing elements over the cloud and run tests concurrently so that the user can get the results of the running tests after about an hour not a whole day.A similar problem face load testing, where the available computation power affects the number of concurrent users per time period simulated in test run.
  5. Defining specifications for the domain specific language
    Define specifications and rules for a domain specific language that will fill the gap between the task of writing the test cases; which is done by the tester; and the task of writing the code that executes these test cases; which is done by the developer.
    This domain specific language will get benefit from the semantic features in web 3 and supported in HTML 5 to help the tester in controlling the page elements for the benefit of his test cases.
  6. Forming a Billing model for different customers
    The billing model for each account (company) should be built  taking these factors in consideration:

      1. Number of users per account
      2. Number of scenarios to be run
      3. Number of steps in each scenario
      4. Number of users to be simulated when performing load tests (if any)
      5. Computational power used

    These elements should be modelled in a business form that is equivalent to customer value.
    For example, a customer may not pay for computation power, but will pay for 10 test runs.

    So we need to study the analogous between business value and technical elements that affect total service cost to provide the customer with a customer value pricing model and make sure it is profitable at the same time.