%% Last Updated: - [[2021-03-30]] %% Entry criteria are conditions that you need to be fulfilled before the testing actually begins. It’s a good idea to have these conditions communicated beforehand so that everyone is clear on what needs to be set up before you can do your job. For nonfunctional testing, there are several general conditions you might want to include in your entry criteria. ## Functional testing Load testing cannot realistically be carried out until at least the core functionality has been tested and high-severity defects have been fixed. Depending on the kind of load test you want to execute, you may also want to specify that [[User Acceptance Testing (UAT)]] has been executed, as there’s no point doing an end-to-end load test with 1000 users if it doesn’t work for one user. ## [[Production-like environment|Environment]] Nonfunctional testing has stricter requirements for an environment than does functional testing, and you may have to champion this cause. For load testing, it is not enough to have an application staging environment that is a virtual machine that is a quarter of the size of the production environment. It’s important to get as close to a production-like environment as possible in terms of capacity (memory, CPU), codebase (the actual build that will be deployed), and integrations with other environments or servers (if within test scope). Load testing is not linear: a response time of 5 seconds on a server with half the capacity of the production server does not necessarily equate to a response time of 2.5 seconds in production. Once you have as close a copy of the production environment as possible, keep in mind that it’s still a clean copy, which may not be realistic. If there are databases in production, how much data do they contain? The application server may respond differently when your test database is empty compared to when it must contend with gigabytes of data in the production database. This is also the time to think about your load injectors. Will they be on-premises, or in the cloud? A good entry criterion is the availability of the machines in the right network and with the right tools installed. If you’re using commercial tools, license provisioning should be a criterion. What sort of capacity will your load testing scripts require? Monitoring tools that you use during execution will also fall under environment criteria, but we’ll discuss that a little bit more in detail later. ## Application Teams Involved Load testing is a team activity. When a load test involves multiple application teams, it’s important to request availability of key persons on those teams during the test. Often as load testers, we are seen as working independently, but the truth couldn’t be farther from that. Load testing is a team sport. We need support from: - business analysts who will be able to tell us how things are expected to work and what the current priorities are - developers whom we can consult when poorly performing code needs to be optimised - functional testers who can show us how the application works - DevOps engineers who can help us provision and monitor servers and many more! There should be a test schedule drafted with the input of all key resources. ## [[Test Data]] Test data should be examined in conjunction with the determination of the key business processes to be tested. For example, if part of the requirements involves testing user logins, where will the user credentials come from?