{"id":3754,"date":"2026-08-20T13:18:17","date_gmt":"2026-08-20T13:18:17","guid":{"rendered":"https:\/\/loadfocus.com\/blog\/2026\/08\/volume-testing-in-software-testing"},"modified":"2026-09-23T20:02:38","modified_gmt":"2026-09-23T20:02:38","slug":"volume-testing-in-software-testing","status":"publish","type":"post","link":"https:\/\/loadfocus.com\/blog\/2026\/08\/volume-testing-in-software-testing","title":{"rendered":"What is Volume Testing in Software Testing?"},"content":{"rendered":"<span class=\"span-reading-time rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\"><\/span> <span class=\"rt-time\"> 6<\/span> <span class=\"rt-label rt-postfix\">minutes read<\/span><\/span><p class=\"lead\" class=\"lead\"><!-- pn-tldr --><\/p>\n<h2>Key takeaways<\/h2>\n<ul>\n<li>Volume testing increases the amount of DATA, not the number of users. That is what separates it from load testing.<\/li>\n<li>Most volume failures are queries that were fine against a small table and are not fine against a large one.<\/li>\n<li>Test at several data sizes rather than one. The shape of the curve is the finding, not any single number.<\/li>\n<\/ul>\n<h2>The quick answer<\/h2>\n<p>Volume testing measures how a system behaves as the volume of data it holds grows. The user count stays realistic; the database, the file store and the queues get large. It answers a question load testing cannot: does this application still work in two years, when the tables have a hundred times more rows in them?<\/p>\n<h2>What is volume testing in software testing?<\/h2>\n<p>Volume testing is a performance test where the variable is stored data. You seed the system with a realistic quantity of records, then run the same operations you always run and watch what happens to response times, memory and disk.<\/p>\n<p>The failures it finds are specific and they rarely appear in any other kind of test. A query with no index returns instantly against ten thousand rows and takes thirty seconds against ten million. A report that builds its result set in memory works until the result set no longer fits. A page that loads every record to count them is fast on an empty system and unusable on a full one.<\/p>\n<p>None of these are visible in a load test, because a load test usually runs against a small seeded database. You can put a thousand concurrent users through an empty system and see excellent numbers.<\/p>\n<h2>Volume testing vs load testing vs stress testing<\/h2>\n<p>The three are routinely confused because all of them are performance tests. The difference is what you vary.<\/p>\n<ul>\n<li><strong>Load testing<\/strong> varies the number of concurrent users at an expected level, and asks whether the system copes with the traffic you predict.<\/li>\n<li><strong>Stress testing<\/strong> pushes the user count past that level to find where it breaks and how.<\/li>\n<li><strong>Volume testing<\/strong> holds users roughly constant and varies the data, asking whether the system copes with the scale it will eventually hold.<\/li>\n<\/ul>\n<p>A system can pass all the load testing you throw at it and still fail in production eighteen months later, because the load never changed and the data did. For the user-count side of the picture, see <a href=\"https:\/\/loadfocus.com\/blog\/2026\/05\/load-testing-vs-stress-testing\">load testing vs stress testing<\/a> and <a href=\"https:\/\/loadfocus.com\/blog\/2026\/08\/spike-testing-in-performance-testing\">spike testing<\/a>.<\/p>\n<p>Volume testing is also often confused with <a href=\"https:\/\/loadfocus.com\/glossary\/what-is-scalability-testing\">scalability testing<\/a>. Scalability testing asks how well the system grows when you add resources or traffic. Volume testing asks what happens to the same system as its data grows. The two overlap, but a volume test deliberately keeps the infrastructure and the traffic fixed.<\/p>\n<h2>What actually breaks under data volume<\/h2>\n<ul>\n<li><strong>Missing or unused indexes.<\/strong> The most common finding by a wide margin. The query plan changes as the table grows and a scan replaces a seek.<\/li>\n<li><strong>Unbounded result sets.<\/strong> Anything that loads a whole table to filter or count it in application code.<\/li>\n<li><strong>Pagination that counts.<\/strong> Showing &#8220;page 1 of N&#8221; requires counting every row, and that cost grows with the table.<\/li>\n<li><strong>Report and export paths.<\/strong> These are usually written against a development dataset and never revisited.<\/li>\n<li><strong>Storage that grows quietly.<\/strong> Logs, audit tables, soft-deleted rows and attachment stores fill disks that nobody is watching.<\/li>\n<li><strong>Backup and restore windows.<\/strong> Restores get slower with data and only get tested during an incident.<\/li>\n<\/ul>\n<h2>A volume testing example<\/h2>\n<p>Take an online shop with an order history page and an admin search over all orders. Today the orders table holds about 50,000 rows. The business expects that to reach 2 million within two years.<\/p>\n<p>A volume test for this system could look like this:<\/p>\n<ol>\n<li>Generate realistic orders at three sizes: 50,000 (today), 2 million (the two-year plan) and 10 million (well beyond it). Spread them over thousands of customers, many dates and several statuses, the way real orders are.<\/li>\n<li>At each size, run the same load test: a fixed number of virtual users browsing order history, searching orders in the admin and placing new orders.<\/li>\n<li>Compare the p95 response time of each operation across the three runs.<\/li>\n<\/ol>\n<p>A typical result: order history stays nearly flat because it is indexed by customer, so each page reads a few rows whatever the table size. The admin search, which filters on a column with no index, grows far faster than the data and becomes unusable at the largest size. Placing an order gets slightly slower as the indexes it updates grow. That second line is the finding, and the fix is usually a single index or a rewritten query, found before a customer hits it.<\/p>\n<h2>How to run a volume test<\/h2>\n<p>Seed the system with data that looks like production, not with a million copies of the same record. Realistic distribution matters, because a table where every row has the same value indexes very differently from one where values are spread out.<\/p>\n<p>Then run the same set of operations at several data sizes. Current volume, the volume you expect in a year, and something well beyond it. Keep the user load constant across all three so the only thing changing is the data.<\/p>\n<p>Measure the operations users actually perform: the main list views, the search, the exports, the busiest API endpoints. Include at least one write path, because inserts slow down as indexes grow too.<\/p>\n<p>Report percentiles rather than averages for each operation. A few very slow queries at the largest data size can hide inside a healthy-looking average; <a href=\"https:\/\/loadfocus.com\/blog\/2013\/07\/what-is-response-time-in-performance-testing\">what response time is and how to measure it<\/a> explains why p95 is the number to watch.<\/p>\n<h2>Volume testing tools<\/h2>\n<p>A volume test needs three things, and they are usually different tools:<\/p>\n<ul>\n<li><strong>Something to generate data.<\/strong> Faker libraries (available for Python, JavaScript, Java and most other languages) produce realistic names, addresses and dates. Databases can also generate rows themselves, for example PostgreSQL&#8217;s <code>generate_series<\/code>, which is much faster than inserting through the application.<\/li>\n<li><strong>Something to drive the operations.<\/strong> <a href=\"https:\/\/loadfocus.com\/jmeter-load-testing\">Apache JMeter<\/a> and <a href=\"https:\/\/loadfocus.com\/k6-load-testing\">k6<\/a> scripts can run the same user journeys at a constant number of virtual users against each data size, and both can read CSV test data so each virtual user searches for different records instead of hitting the same cached row.<\/li>\n<li><strong>Something to explain the result.<\/strong> The database&#8217;s own query plans (<code>EXPLAIN<\/code>) and slow query log show which query stopped using an index. Server metrics show memory and disk growing with the data.<\/li>\n<\/ul>\n<p>With <a href=\"https:\/\/loadfocus.com\">LoadFocus<\/a> you can run those JMeter or k6 scripts from the cloud with no load generators to manage, upload CSV or JSON data files for dynamic test data, and compare each run with the previous one, which is exactly the comparison a volume test is built on. To try the load side first, run a <a href=\"https:\/\/loadfocus.com\/free-load-test\">free load test<\/a> against your site or a <a href=\"https:\/\/loadfocus.com\/free-api-load-test\">free API load test<\/a> against an endpoint.<\/p>\n<h2>Reading the result<\/h2>\n<p>You are looking for the shape of the curve rather than any single measurement.<\/p>\n<h3>Linear growth<\/h3>\n<p>Response time rising in proportion to the data is usually acceptable and predictable. You can plan for it.<\/p>\n<h3>Non-linear growth<\/h3>\n<p>Response time rising much faster than the data is the finding. It nearly always points at a specific query rather than at general slowness, and it is usually cheap to fix once identified.<\/p>\n<h3>A cliff<\/h3>\n<p>Performance that is level and then collapses at a particular size normally means something stopped fitting: an index no longer in memory, a cache no longer holding the working set, a result set no longer fitting in a buffer.<\/p>\n<h2>What good looks like<\/h2>\n<p>A system that passes volume testing has response times that grow predictably and slowly with data, and no operation whose cost is proportional to total table size when it should be proportional to the page being shown. The practical target is that the curve at ten times today&#8217;s data is still inside your acceptable response time, because that is the horizon you can plan around.<\/p>\n<p><!-- pn-faq --><\/p>\n<h2>Frequently Asked Questions<\/h2>\n<h3>Is volume testing the same as load testing?<\/h3>\n<p>No. Load testing varies the number of concurrent users; volume testing varies the amount of stored data. A system can pass one and fail the other, which is why both exist.<\/p>\n<h3>How much data should I test with?<\/h3>\n<p>At least the volume you expect within your planning horizon, and ideally several multiples so you can see the shape of the curve. One measurement at one size tells you the current cost, not how it grows.<\/p>\n<h3>Can I use copied production data?<\/h3>\n<p>Only if it is anonymised properly. Real records in a test environment are a data protection problem, and test environments are usually less protected than production. Generated data with a realistic distribution avoids the issue.<\/p>\n<h3>What is an example of volume testing?<\/h3>\n<p>Seeding an orders table at today&#8217;s size, the size expected in two years and a much larger size, then running the same load test at each size and comparing response times. An operation that slows down far faster than the data grows, such as a search on an unindexed column, is the typical finding.<\/p>\n<h3>What tools are used for volume testing?<\/h3>\n<p>A data generator such as a Faker library or the database&#8217;s own functions, a load testing tool such as JMeter or k6 to run the same operations at each data size, and the database&#8217;s query plans and slow query log to explain what got slower.<\/p>\n<h3>How is volume testing different from scalability testing?<\/h3>\n<p>Scalability testing checks how the system performs as you add traffic or resources. Volume testing keeps traffic and infrastructure fixed and grows only the stored data, to find operations whose cost rises with the size of the data.<\/p>\n<p><!-- pn-related-reading --><\/p>\n<h2>Related reading<\/h2>\n<ul>\n<li><a href=\"https:\/\/loadfocus.com\/blog\/2018\/11\/what-is-stress-testing-in-software-testing\">What is Stress Testing in Software Testing?<\/a><\/li>\n<li><a href=\"https:\/\/loadfocus.com\/blog\/2013\/07\/what-is-throughput-in-performance-testing\">What is Throughput in Performance Testing?<\/a><\/li>\n<li><a href=\"https:\/\/loadfocus.com\/blog\/2013\/07\/what-is-response-time-in-performance-testing\">What is Response Time in Performance Testing?<\/a><\/li>\n<li><a href=\"https:\/\/loadfocus.com\/blog\/2026\/08\/endurance-testing-soak-testing\">What is Endurance Testing (Soak Testing)?<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p><span class=\"span-reading-time rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\"><\/span> <span class=\"rt-time\"> 6<\/span> <span class=\"rt-label rt-postfix\">minutes read<\/span><\/span>Key takeaways Volume testing increases the amount of DATA, not the number of users. That is what separates it from load testing. Most volume failures are queries that were fine against a small table and are not fine against a large one. Test at several data sizes rather than one. The shape of the curve&#8230;  <a href=\"https:\/\/loadfocus.com\/blog\/2026\/08\/volume-testing-in-software-testing\" class=\"more-link\" title=\"Read What is Volume Testing in Software Testing?\">Read more &raquo;<\/a><\/p>\n","protected":false},"author":0,"featured_media":3755,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9],"tags":[],"class_list":["post-3754","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-load-testing"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/loadfocus.com\/blog\/wp-json\/wp\/v2\/posts\/3754","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/loadfocus.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/loadfocus.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/loadfocus.com\/blog\/wp-json\/wp\/v2\/comments?post=3754"}],"version-history":[{"count":1,"href":"https:\/\/loadfocus.com\/blog\/wp-json\/wp\/v2\/posts\/3754\/revisions"}],"predecessor-version":[{"id":3956,"href":"https:\/\/loadfocus.com\/blog\/wp-json\/wp\/v2\/posts\/3754\/revisions\/3956"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/loadfocus.com\/blog\/wp-json\/wp\/v2\/media\/3755"}],"wp:attachment":[{"href":"https:\/\/loadfocus.com\/blog\/wp-json\/wp\/v2\/media?parent=3754"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/loadfocus.com\/blog\/wp-json\/wp\/v2\/categories?post=3754"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/loadfocus.com\/blog\/wp-json\/wp\/v2\/tags?post=3754"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}