The Sentia method
1. Determine test plan
Depending on your needs, we determine what test is most suitable. This can vary from a stress tests, (continious) load tests to duration tests. We together define the frameworks in which the test is to be executed, resulting in an intake document and a test plan. These documents form the basis for the performance test that is to be executed. Among other things, they describe the planning schedule we will use, how and with what load the application will be tested, the requirements to be evaluated, and who is involved in the program.
2. Prepare test structure
After defining a test-plan, the test structure is prepared. The structure consists of three components: construction of the test infrastructure from which Sentia generates a load on the application, development of the test scripts with which the user actions are simulated, and the setting up of performance monitoring for the purpose of the analysis.
3. Environment tests
Sentia performs several environment tests before executing the main test: 1) A connection test to determine how many connections the application can handle per second; 2) a download test to determine how much bandwidth is available for the application; 3) a log-in test to determine the number of logged-in users that the application can handle. With these tests we validate the application environment to make sure the environment does not entail any limitations that affect the actual performance test.
4. Main test
The main test is intended to validate the test objectives. During this test the previously agreed load is generated and Sentia collects data about the end-user response times and errors. Based on the performance monitoring, metrics are also collected which provide insight into how the underlying infrastructure is responding to the generated load.
Within a few hours after the main test, we can determine whether or not the test goals have been reached. We will directly supply the preliminary results and conclusions. The Sentia performance consultant will then start an in-depth analysis in which the end user response is correlated with the performance monitoring. You will receive a report which details, besides whether or not the test goals were achieved, where possible bottlenecks in the application are and suggestions for improvement of these bottlenecks.
A re-test is a follow-up execution of the previously done performance test. In the case of unchanged functionality no effort will be required to prepare the performance test for the second time, such as the developing of scripts or the set-up of the test infrastructure. The re-test is meant to validate what the impact is of the changes you arranged after the main test.
You have a vision. We help you spark it into action.
Contact us using the option below or get in touch