Methods and tools for conducting tests
During tests we use commonly tested methods, which at the same time allow us to achieve optimal and reliable results. During tests we use open source tools Apache JMeter and Grafana Labs K6. Both tools are verified and well known by our engineers and work efficiently. Tests based on these tools guarantee achieving excellent results and lower price.
We are also running tests using commercial LoadRunner tools from Micro Focus (the tools were previously owned by HP). Our experience indicates that for environments designed to support very large numbers of users (more than 500,000 concurrent users) LoadRunner performs slightly better, offering higher performance than JMeter or K6.
We test not only websites, but also complex web applications such as online stores, finance and accounting systems, HR and payroll systems and all other applications.
We also test applications hosted on global vendor clouds: Microsoft Azure, Google Cloud Platform, Amazon AWS, Oracle Cloud considering the architecture of these platforms.
Types of tests
These are the most common tests which allow to check how the tested system behaves under heavy load. For the purposes of this type of testing we create various scenarios which allow for the simulation of a large number of users walking around the website and performing various activities: logging in, making payments, adding comments, validating data. We also measure page response time in order to identify elements for improvement.
To sum up: load testing allows you to verify whether the performance requirements defined in accordance with the principles described above are met. We generate the load according to our customer's requirements (we often help to define them on the basis of observations) and check whether the system meets the requirements of requests per second (Request Per Second RPS), response times, number of concurrent users and at the same time the error level is sufficiently low.
This type of testing allows you to determine the maximum number of users performing certain actions while maintaining the shortest acceptable page response time.
Our customers often want to know if a web application will respond quickly and efficiently with a large number of users accessing simultaneously. With this test, we help determine the threshold at which this time will be exceeded.
Thus, the customer knows very well under what conditions he will have to raise the parameters of the environment to keep the response time appropriate.
In summary: they are based on performance tests but the generated load is gradually increased to identify system limits and critical points. This test may need to be repeated multiple times after tuning relevant system parameters identified as bottleneck and cause of limitation.
Często zastanawiamy się jak i czy w ogóle tłumaczyć z języka angielskiego stress test. To faktycznie prowadzenie testów w warunkach skrajnych, których głównym celem jest załamanie systemu.
With this kind of testing you can find out if the application will throw errors on the screen, maybe so will behave the web server or database server. You will also find out if with this kind of testing the system will survive or will fail completely.
With this knowledge, our clients are able to prepare a disaster defense plan and a disaster recovery plan.
The purpose of these tests is to verify how the system will behave when generating a load at a given level for a long time. If an IT system is to operate in 24/7/365 mode, this test will surely show whether there are no memory leaks, queue congestion or server response time degradation.
Stability tests are often conducted for a long time, imitating the traffic generated by users. Tests can last for a few hours, days, weeks e.g.: a few weeks test allows to verify the stability of the online store behaviour.
In summary: stress testing verifies how a system behaves under heavy loads, over an extended period of time. During overload testing, a load above the requirements but at which the system still behaves properly (i.e., acceptable response times and error rates) is identified. The system is then subjected to this load for a long period of time (e.g., 8 hours, 24 hours, etc.).