![\"\"\/](\"https:\/\/lh5.googleusercontent.com\/skwPQrtzix1QwVMYTcYVELjC30aYwIrSU4WKGQLfjidDeFQacJTEN8UCrWf7988WD8Z3FQJtuNTYzkGXWf_rLLl5upOsxDFpacHBZScgn2_QpU1_Tl8uOXnC02A-G1olEm8ncehc1N8nXyAVCsjhUMsNCd2UikSGFh2paLSSKjDhVj-D3d2ghMomUA\")
<\/figure><\/div>\n\n\n\nTwo important Software Testing conferences will take place in Uruguay next December, which will do a great contribution to the field of continuous performance testing. Their names are WOPR29<\/a> and Quality Sense. What makes this so important? As a result of these kinds of events, software experts worldwide can network and share ideas, contributing to the development of quality software.\u00a0\u00a0<\/p>\n\n\n\n The small South American country of Uruguay, with a population of about 3.5 million, ranks among<\/strong> the top software exporters in the world<\/strong>. Financial Times<\/a> informed that \u201cmore than 1.000 software development companies\u201d operate in Uruguay, generating almost $1bn in exports, mostly to the US. That makes it one of the world\u2019s leading software exporters per capita.\u201d<\/p>\n\n\n\n Referring to Uruguay as the \u201cSilicon Valley of South America\u201d is starting to ring a bell. According to the Digital Rise Report 2021<\/a>, Uruguay was the top Digital Riser over the last three years in Latin America and the Caribbean. With progressive politics and amazing opportunities, this country has earned international recognition. <\/p>\n\n\n\n This report is prepared by the European Center for Digital Competitiveness every three years. It ranks the digital competitiveness of 140 countries with information from The World Economic Forum, World Bank, and the International Communications Union.<\/p>\n\n\n\n There is an ever-growing audience worldwide interested in learning more about performance testing and software quality. So here we are, digging into all of it through this saga that we named \u201cPerformance Testing In-Depth.\u201d <\/p>\n\n\n\n Since Abstracta is one of the most reliable testing companies in the region, we are proud to handle this task. Aiming to build bridges and broaden the knowledge about this huge practice that is enabling the creation of better and better software.<\/p>\n\n\n\n In this article, we focused on continuous performance testing practices, with the opinions of a panel of experts made up of Paul Holland, Andy Hohenner, and Eric Proegler, organizers of WOPR29; Roger Abelenda, Chief Technology Officer at Abstracta; Andr\u00e9i Guchin, Lead of Performance Hub at Abstracta; and Sofia Palamarchuk, a member of Abstracta’s management team and Apptim’s CEO.<\/strong><\/p>\n\n\n\n Andy Hohenner<\/strong>: That\u2019s part of what I hope to explore with this WOPR. There are practices like Observability testing, instrumenting test automation, synthetic testing\/monitoring, etc. But none of those give us the forward-looking at-scale performance data that old school load tests did.<\/p>\n\n\n\n Eric Proegler<\/strong>: For software under development, we want to know if we are making things better, or at least not making them worse. Calibrated (as opposed to \u201crealistic\u201d) loads can find information to confirm – and new information that we can get safely without risking brand and revenue. Verifying new architectures and component reworking at an early stage can be very valuable for baking good performance into the system. <\/p>\n\n\n\n In terms of scalability, load injection and assembled system testing can help us discover problems we don\u2019t really want to find later in Production. At a certain level of reliability, \u201cService Restart Engineering\u201d can get us to (an average of) two nines of uptime, but that\u2019s not enough for every context. Even when it is, point load effects should be explored, autoscaling is not immediate, and operations systems need verification as well. <\/p>\n\n\n\n Roger Abelenda: <\/strong>There are many practices that are relevant and may be used to assure the performance of a system under different loads. Andr\u00e9i Guchin: <\/strong>In order to complement Roger\u2019s answer, another practice that is relevant in continuous performance testing, and aligned with microservices architectures, is running performance testing for each system in isolation and in an integration fashion. As with functional tests, it is essential to test each component in isolation to verify it properly works and get fast feedback loops, through the usage of mocks or virtual services but it is also important in later steps to test integration with other systems to verify that the functionality or performance is not affected in the integrated environment due to networking, special scenario exercised in integration or other factors.<\/p>\n\n\n\n Also, having properly represented and reproducible environments for running such performance tests continually is of special importance, where infrastructure as code and disposable environments play a bigger role than they used to play in the past when performance tests were done in a one-off fashion. In contrast to the \u201ctraditional\u201d performance testing, for continuous performance testing, it\u2019s not so important to have a production-like environment to run the tests, but the capacity to reproduce exactly the same environment throughout the different sprints in order to have effective results comparisons.<\/p>\n\n\n\n Finally, having an appropriate user-friendly result report with all the important information to get useful performance-related conclusions it\u2019s something to keep in mind when running this kind of testing. Most of the time no one will be monitoring the tests as they are running, so it\u2019s essential to have a good report to understand later what happened.<\/p>\n\n\n\n Sof\u00eda Palamarchuk: <\/strong>In terms of performance testing during the SDLC (Software Development Life Cycle), there are different types of checks that can be done to ensure performance regressions are caught in time and addressed.<\/p>\n\n\n\n What type of performance testing is more relevant in CI depends on the end goal of the software under test and what is more critical for the business.<\/p>\n\n\n\n The minimum would be to automatically check the response time of all requests and the user experience of the main user flows. This requires analyzing performance across multiple environments (browsers, mobile devices, network connections, etc.). Because this is done in a continuous fashion (every time a new version of the software is released and goes through the CI pipeline), it is critical that these tests are automated, run in the same controlled environment, and are fast. As a result, we can detect performance degradation (regressions) earlier and take appropriate action.<\/p>\n\n\n\n Find more about the \u201cPerformance Testing In-Depth\u201d saga <\/strong>here<\/strong><\/a>. <\/strong><\/p>\n\n\n\n Would you like to join WOPR29? Find all the details and <\/strong>apply here<\/strong><\/a>. <\/strong><\/p>\n\n\n\n If you want to know more about Uruguay as a Digital Hub, we suggest you read this article<\/a>.<\/p>\n\n\n\n In need of a testing partner?<\/strong> Abstracta is one of the most trusted companies in software quality engineering. Learn more about our solutions<\/a>, and contact us<\/strong><\/a> to discuss how we can help you grow your business.<\/p>\n\n\n\n Follow us on <\/strong>Linkedin<\/strong><\/a> & <\/strong>Twitter<\/strong><\/a> to be part of our community!<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":" What practices are relevant in continuous performance testing today? We talked about this with an expert panel made up of Roger Abelenda, Andr\u00e9i Guchin, Sofia Palamarchuk, Paul Holland, Andy Hohenner, and Eric Proegler. Two important Software Testing conferences will take place in Uruguay next December,…<\/p>\n","protected":false},"author":61,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[32],"tags":[556,539,417],"yoast_head":"\n![\"WOPR29](\"https:\/\/lh4.googleusercontent.com\/5yHUllaI1l2D63dA8oez2r5ldK4jRY1iU2T0hekJmcHGqHRo2TiKJA1dHemsvByV0YoSHXf1lawG3PAYbv2pEIVI5JloAS2v6v1iQ2fKEluxikMMhwOPx8a2h0wwyLZ4tmjBuIFV4CoMxmYNX9RCKD1Vfbvq-Xl7fmUZ2Gg_ucbGRh0-mm-L8pedtw\")
– WOPR29\u2019s website says that synthetic usage injection can still provide predictive benefits that are difficult to achieve in any other way. In this context, what practices are relevant in continuous performance testing today?<\/em><\/strong><\/h4>\n\n\n\n
![\"Roger](\"https:\/\/lh6.googleusercontent.com\/ZRgpzFcZz-o8ym4LphmgR3oFuONtTFWfCJLj5dWbF8KxkDNQ-jkMi9r0NXw23GW6t6jX-J3M4DQXrWYvwCkTwD0GEcyjQrqedR6uKHgjuXTp8AA7DwS0J6y_oEvcedcYcqkDeEYxNkpz6TGIIXCR8UUDtdN_Nw3ELAHaiuZhyATbH0k7TeoqwZDkTA\")
Generating synthetic load is still relevant since it allows us to verify the performance of the application to anticipate potential future loads (for example for an upcoming event, like black Friday or some particular promotion event), analyze known profiles with proper preparation, and monitor in place and reproduce it in a simple way to evaluate adjustments to configuration or fixes in code, etc. In the context of continuous performance testing, generating synthetic loads allows us to verify the behavior of a system remains in acceptable ranges under a well-known scenario while the system itself changes on each iteration (either code, configuration, or infrastructure changes).
Additionally, other types of tests may be applied as resiliency testing (through chaos engineering), infrastructure scalability ramp up and down speed, etc.
I think the key practice in continuous performance testing is versioning performance scripts, and the closer the versioning to the code under test, the better (ideal: performance tests in the same repository as code under test). Keeping performance tests versioning close to code under test versioning allows us to easily track changes in both places, easy rollback in case of any potential issue and apply fixes to production code and easily verify it with the proper tests for such version. Moreover, it fosters collaboration between developers and performance testers (for example through code review practice), a truly cross-functional team, and not by 2 teams that try to sync on sprints.<\/p>\n\n\n\n