Feat: Rewrite test types explanations (#1136)

- More information
- Longer, repeated structure
- Updated images

Co-authored-by: Señor Performo - Leandro Melendez <[email protected]>
Co-authored-by: Pepe Cano <[email protected]>

Author: 3 people

.vale/Vocab/docs/accept.txt

@@ -45,6 +45,7 @@ APIs
 apm
 async
 backoff
+breakpoint
 browserified
 browserlist
 bundler

gatsby-node.js

@@ -1585,6 +1585,12 @@ const createRedirects = ({ actions }) => {
     isPermanent: true,
   });
 
+  createRedirect({
+    fromPath: '/test-types/introduction',
+    toPath: '/test-types/load-test-types/',
+    isPermanent: true,
+  });
+
   const redirects = {
     '/javascript-api/k6-http/cookiejar-k6-http':
       '/javascript-api/k6-http/cookiejar/',

src/data/markdown/translated-guides/en/06 Test Types/00 Introduction.md

@@ -0,0 +1,91 @@
+---
+title: 'Load test types'
+excerpt: 'A series of conceptual articles explaining the different types of load tests. Learn about planning, running, and interpreting different tests for different performance goals.'
+---
+
+Many things can go wrong when a system is under load.
+The system must run numerous operations simultaneously and respond to different requests from a variable number of users.
+To prepare for these performance risks, teams use load testing.
+
+But a good load-testing strategy requires more than just executing a single script.
+Different patterns of traffic create different risk profiles for the application.
+For comprehensive preparation, teams must test the system against different _test types_.
+
+![Overview of load test shapes](./images/chart-load-test-types-overview.png)
+
+## Different tests for different goals
+
+Start with smoke tests, then progress to higher loads and longer durations.
+
+The main types are as follows. Each type has its own article outlining its essential concepts.
+
+- [**Smoke tests**](../smoke-testing) validate that your script works and that the system performs adequately under minimal load.
+
+- [**Average-load test**](../load-testing) assess how your system performs under expected normal conditions.
+
+- [**Stress tests**](../stress-testing) assess how a system performs at its limits when load exceeds the expected average. 
+
+- [**Soak tests**](../soak-testing) assess the reliability and performance of your system over extended periods.
+
+- [**Spike tests**](../spike-testing) validate the behavior and survival of your system in cases of sudden, short, and massive increases in activity.
+
+- [**Breakpoint tests**](../breakpoint-testing) gradually increase load to identify the capacity limits of the system.
+
+<Blockquote mod="note" title="">
+
+In k6 scripts, configure your load in the [`options` object](/using-k6/k6-options/reference/) or using [Scenarios](/using-k6/scenarios). The workload configuration is separated from the logic of VUs.
+
+</Blockquote>
+
+## Test-type cheat sheet 
+
+The following table provides some broad comparisons.
+
+| Type       | VUs/Throughput        | Duration                   | When?                                                                                                            |
+|------------|-----------------------|----------------------------|------------------------------------------------------------------------------------------------------------------|
+| Smoke      | Low                   | Quick (seconds or minutes) | Every time new code or a change is done. It checks scripts, baseline system metrics, and deviations from changes |
+| Load       | Average production    | Mid (15-60 minutes)           | Often to check system maintains performance with average use                                                     |
+| Stress     | High (above average)  | Mid (15-60 minutes)           | When system may receive above-average loads to check how it manages                                              |
+| Soak       | Average               | Long (hours)               | After changes to check system under prolonged continuous use                                                     |
+| Spike      | Very high             | Quick (seconds to minutes)       | Rarely, when system risks sudden rush                                                                            |
+| Breakpoint | Increases until break | As long as necessary       | A few times to find the upper limits of the system                                                               |
+
+
+## General recommendations
+
+When you write and run different test types in k6, consider the following.
+
+### Start with a smoke test
+
+Start with a [smoke test](../smoke-testing).
+Before beginning larger tests, validate that your scripts work as expected and that your system performs well with a few users.
+
+After you know that the script works and the system responds correctly to minimal load,
+you can move on to average-load tests.
+From there, you can progress to more complex load patterns.
+
+### The specifics depend on your use case
+
+Systems have different architectures and different user bases. As a result, the correct load testing strategy is highly dependent on the risk profile for your organization. Avoid thinking in absolutes.
+
+For example, k6 can model load by either number of VUs or by number of iterations per second ([open vs. closed](https://k6.io/docs/using-k6/scenarios/concepts/open-vs-closed/)).
+When you design your test, consider which pattern makes sense for the type. 
+
+What's more, **no single test type eliminates all risk.** 
+To assess different failure modes of your system, incorporate multiple test types.
+The risk profile of your system determines what test types to emphasize:
+- Some systems are more at risk of longer use, in which case soaks should be prioritized.
+- Others are more at risk of intensive use, in which case stress tests should take precedence.
+
+In any case, **no single test can uncover all issues**.
+
+What's more, the categories themselves are relative to use cases. A stress test for one application is an average-load test for another. Indeed, no consensus even exists about the names of these test types (each of the following topics provides alternative names).
+
+### Aim for simple designs and reproducible results
+
+While the specifics are greatly context-dependent, what's constant is that you want to make results that you can compare and interpret.
+
+Stick to simple load patterns. For all test types, directions is enough: ramp-up, plateau, ramp-down.
+
+Avoid "rollercoaster" series where load increases and decreases multiple times. These will waste resources and make it hard to isolate issues.
+

src/data/markdown/translated-guides/en/06 Test Types/00 Load test types.md

@@ -1,74 +1,81 @@
 ---
 title: "Smoke testing"
 head_title: 'What is Smoke Testing? How to create a Smoke Test in k6'
-excerpt: "Smoke test is a regular load test, configured for minimal load. You want to run a smoke test as a sanity check every time you write a new
-script or modify an existing script. Let’s see an example."
+excerpt: "A Smoke test is a minimal load test to run when you create or modify a script."
 ---
 
-A smoke test is a test configured for minimal load.
+Smoke tests have a minimal load.
+Run them to verify that the script works well, the system functions under minimal load, and to gather baseline performance values.
 
-Each time you write a new test script, it's a good idea to run a smoke to test first, which helps you:
-- Verify that your test script doesn't have errors.
-- Verify that your system doesn't throw any errors when under minimal load.
+This test type consists of running tests with only one or a few VUs. Keep the number to 5 VUs or less.
+Exceeding 5 could turn the test into a mini-load test.
+Similarly, the test shouldn't have many iterations. 3 to 10 iterations should be enough (or an iteration duration with a short period).
 
-## Smoke testing in k6
+![Overview of a smoke test](images/chart-smoke-test-overview.png)
 
-The following script is a sample smoke test script to get you started.
-You can copy it, change the end points, and start testing.
-If you'd like to see more comprehensive script, check out our [example section](/examples).
+In some testing conversation, smoke tests are also called shakeout tests.
 
-<CodeGroup labels={["sample-smoke-test.js"]} lineNumbers={[true]} heightTogglers={[true]}>
+## When to run a Smoke test
 
-```javascript
-import http from 'k6/http';
-import { check, group, sleep, fail } from 'k6';
+Teams should run smoke tests whenever a test script is created or updated. Smoke testing should also be done every time the application code is updated.
 
-export const options = {
-  vus: 1, // 1 user looping for 1 minute
-  duration: '1m',
+It's a good practice to run a smoke test as a first step, with the following goals: 
 
-  thresholds: {
-    http_req_duration: ['p(99)<1500'], // 99% of requests must complete below 1.5s
-  },
-};
+- Verify that your test script doesn't have errors.
+- Verify that your system doesn't throw any errors (performance or system related) when under minimal load.
+- Gather baseline performance metrics of your system’s response under minimal load.
+- With simple logic, to serve as a synthetic test to monitor the performance and availability of production environments.
 
-const BASE_URL = 'https://test-api.k6.io';
-const USERNAME = 'TestUser';
-const PASSWORD = 'SuperCroc2020';
+## Considerations 
+
+When you prepare a smoke test, consider the following:
 
-export default () => {
-  const loginRes = http.post(`${BASE_URL}/auth/token/login/`, {
-    username: USERNAME,
-    password: PASSWORD,
-  });
 
-  check(loginRes, {
-    'logged in successfully': (resp) => resp.json('access') !== '',
-  });
+- **Each time you create or update a script, run a smoke test**
 
-  const authHeaders = {
-    headers: {
-      Authorization: `Bearer ${loginRes.json('access')}`,
-    },
-  };
+  Because smoke tests verify test scripts, try to run one every time you create or update a script. Avoid running other test types with untested scripts.
+
+- **Keep throughput small and duration short**
+  
+  Configure your test script to be executed by a small number of VUs (from 2 to 5) with few iterations (3 to 10) or brief durations (30 to 60 seconds).
+
+## Smoke testing in k6
 
-  const myObjects = http.get(`${BASE_URL}/my/crocodiles/`, authHeaders).json();
-  check(myObjects, { 'retrieved crocodiles': (obj) => obj.length > 0 });
+<CodeGroup labels={["smoke.js"]} lineNumbers={[]} showCopyButton={[true]}>
 
+```javascript
+import http from 'k6/http';
+import { check, sleep} from 'k6';
+
+export const options = {
+  vus: 3, // Key for Smoke test. Keep it at 2, 3, max 5 VUs
+  duration: '1m', // This can be shorter or just a few iterations
+};
+
+export default () => {
+  const urlRes = http.req('https://test-api.k6.io');
   sleep(1);
+  // MORE STEPS
+  // Here you can have more steps or complex script
+  // Step1
+  // Step2
+  // etc.
 };
 ```
 
 </CodeGroup>
 
-The VU chart of a smoke test should look similar to this.
-You want to use only 1 or 2 VUs.
-![Smoke test VU chart](./images/smoke-test.png)
 
-If your smoke test produces any errors,
-you should either correct the script or fix your environment before you continue.
+The following script is an example smoke test. You can copy it, change the endpoints, and start testing. For more comprehensive test logic, refer to [Examples](/examples).
+The VU chart of a smoke test should look similar to this. Again, a smoke test should use only 2 or 3 VUs and run for only a brief period.
+
+![The shape of the smoke test as configured in the preceding script](images/chart-smoke-test-k6-script-example.png)
+
+## Results analysis
+
+The smoke test initially validates that your script runs without errors. If any script-related errors appear, correct the script before trying any more extensive tests.
+
+On the other hand, if you notice poor performance with these low VU numbers, report it, fix your environment, and try again with a smoke test before any further tests.
 
-The k6 output should look similar to this:
-![Smoke test Terminal Output](./images/smoke-test-terminal-output.png)
+Once your smoke test shows zero errors and the performance results seem acceptable, you can proceed to other test types.
 
-Once your smoke test shows zero errors, you can go to the next step and execute a [load test](/test-types/load-testing) to assess the performance of your system.