Update the Load test types to mention common scenarios (#1204)

* Test types: rewrite note

* Update `smoke tests` to include `mini-load` tests

* Update test types based on common use cases

* Edit `spike testing`

Author: ppcano

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

@@ -34,7 +34,7 @@ The main types are as follows. Each type has its own article outlining its essen
 
 <Blockquote mod="note" title="">
 
-In k6 scripts, configure load in the [`options`](/using-k6/k6-options/reference/) object with [Scenarios](/using-k6/scenarios) (or the [`stages` shortcut](/using-k6/k6-options/reference/#stages)). This separates workload configuration from iteration logic.
+In k6 scripts, configure the load configuration using [`options`](/get-started/running-k6/#using-options) or [`scenarios`](/using-k6/scenarios). This separates workload configuration from iteration logic.
 
 </Blockquote>
 
@@ -44,12 +44,12 @@ 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                                                               |
+| [Smoke](/test-types/smoke-testing)      | Low                   | Short (seconds or minutes) | When the relevant system or application code changes. It checks functional logic, baseline metrics, and deviations |
+| [Load](/test-types/load-testing)       | Average production    | Mid (5-60 minutes)           | Often to check system maintains performance with average use                                                     |
+| [Stress](/test-types/stress-testing)     | High (above average)  | Mid (5-60 minutes)           | When system may receive above-average loads to check how it manages                                              |
+| [Soak](/test-types/soak-testing)       | Average               | Long (hours)               | After changes to check system under prolonged continuous use                                                     |
+| [Spike](/test-types/spike-testing)      | Very high             | Short (a few minutes)       | When the system prepares for seasonal events or receives frequent traffic peaks                                                                            |
+| [Breakpoint](/test-types/breakpoint-testing) | Increases until break | As long as necessary       | A few times to find the upper limits of the system                                                               |
 
 
 ## General recommendations

src/data/markdown/translated-guides/en/06 Test Types/01 Smoke Testing.md

@@ -5,19 +5,19 @@ excerpt: "A Smoke test is a minimal load test to run when you create or modify a
 ---
 
 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.
+Run them to verify that the system works well under minimal load and to gather baseline performance values.
 
-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).
+This test type consists of running tests with a few VUs — more than 5 VUs could be considered a mini-load test. 
+
+Similarly, the test should execute for a short period, either a low number of [iterations](/using-k6/k6-options/reference/#iterations) or a [duration](/using-k6/k6-options/reference/#duration) from seconds to a few minutes maximum.
 
 ![Overview of a smoke test](images/chart-smoke-test-overview.png)
 
 In some testing conversation, smoke tests are also called shakeout tests.
 
 ## When to run a Smoke test
 
-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.
+Teams should run smoke tests whenever a test script is created or updated. Smoke testing should also be done whenever the relevant application code is updated.
 
 It's a good practice to run a smoke test as a first step, with the following goals: 
 
@@ -37,7 +37,7 @@ When you prepare a smoke test, consider the following:
 
 - **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).
+  Configure your test script to be executed by a small number of VUs (from 2 to 20) with few iterations or brief durations (30 seconds to 3 minutes).
 
 ## Smoke testing in k6
 
@@ -67,7 +67,7 @@ export default () => {
 
 
 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 VU chart of a smoke test should look similar to this.
 
 ![The shape of the smoke test as configured in the preceding script](images/chart-smoke-test-k6-script-example.png)
 

src/data/markdown/translated-guides/en/06 Test Types/02 Load Testing.md

@@ -32,7 +32,7 @@ When you prepare an average-load test, consider the following:
     To find this, look through APMs or analytic tools that provide information from the production environment. If you can't access such tools, the business must provide these estimations.
 * **Gradually increase load to the target average.**
 
-  That is, use a _ramp-up period_. This period usually lasts 1, 2, 5, or 10 minutes. A ramp-up period has many essential uses:
+  That is, use a _ramp-up period_. This period usually lasts between 5% and 15% of the total test duration. A ramp-up period has many essential uses:
     * It gives your system time to warm up or auto-scale to handle the traffic.
     * It lets you compare response times between the low-load and average-load stages.
     * If you run tests using our cloud service, a ramp up lets the automated performance alerts understand the expected behavior of your system.

src/data/markdown/translated-guides/en/06 Test Types/03 Stress testing.md

@@ -17,7 +17,7 @@ In some testing conversation, stress tests might also be called rush-hour, surge
 ## When to perform a Stress test
 
 Stress tests verify the stability and reliability of the system under conditions of heavy use.
-Systems may receive higher than usual workloads on unusual moments such as process deadlines, paydays, rush hours, ends of the workweek, and many other isolated behaviors that might combine to create high-load events.
+Systems may receive higher than usual workloads on unusual moments such as process deadlines, paydays, rush hours, ends of the workweek, and many other behaviors that might cause frequent higher-than-average traffic.
 
 ## Considerations
 

src/data/markdown/translated-guides/en/06 Test Types/06-spike-testing.md

@@ -3,26 +3,26 @@ title: 'Spike testing'
 excerpt: 'Spike tests simulate moments of short, extreme load'
 ---
 
-A spike test verifies whether the system survives and performs under sudden and massive rushes of utilization. It is one of the least common tests.
+A spike test verifies whether the system survives and performs under sudden and massive rushes of utilization.
 
 Spike tests are useful when the system may experience events of sudden and massive traffic.
-Examples of such events include ticket sales (ComicCon, Taylor Swift), product launches (PS5, fashion apparel), sale announcements (Super Bowl ads), process deadlines (tax declaration), and seasonal sales (Black Friday, Christmas, St.Valentine).
+Examples of such events include ticket sales (Taylor Swift), product launches (PS5), broadcast ads (Super Bowl), process deadlines (tax declaration), and seasonal sales (Black Friday). Also, spikes in traffic could be caused by more frequent events such as rush hours, a particular task, or a use case.
 
 Spike testing increases to extremely high loads in a very short or non-existent ramp-up time.
 Usually, it has no plateau period or is very brief, as real users generally do not stick around doing extra steps in these situations. In the same way, the ramp-down is very fast or non-existent, letting the process iterate only once.
 
-This test usually includes very different processes than the previous test types, as these processes often aren't part of an average day in production. A recommendation is to automate the processes with heavy demand during the event. It may also require adding, removing, or modifying processes on the script that were not in the average-load tests.
+This test might include different processes than the previous test types, as spikes often aren't part of an average day in production. It may also require adding, removing, or modifying processes on the script that were not in the average-load tests.
 
 Occasionally, teams should revamp the system to allow or prioritize resources for the high-demand processes during the event.
 
 ![Overview of a spike test](images/chart-spike-test-overview.png)
 
 ## When to perform a spike test
 
-Spike testing is the least frequent test type. This test must be executed when the system expects to receive a sudden rush of activity, which is not a common behavior on most platforms.
+This test must be executed when the system expects to receive a sudden rush of activity.
 
 
-When the system expects this type of behavior, the spike test helps identify how the system will behave and if it will survive the sudden rush of load. The load is considerably above the average and frequently focuses on a different set of processes than the other test types.
+When the system expects this type of behavior, the spike test helps identify how the system will behave and if it will survive the sudden rush of load. The load is considerably above the average and might focus on a different set of processes than the other test types.
 
 
 ## Considerations
@@ -31,13 +31,13 @@ When preparing for a spike test, consider the following:
 
 * **Focus on key processes in this test type.**
 
-    Generally, the processes triggered are different from the other test types.
+    Assess whether the spike in traffic triggers the same or different processes from the other test types. Create test logic accordingly.
 * **The test often won't finish.**
 
-    Errors are common under these scenarios
+    Errors are common under these scenarios.
 * **Run, tune, repeat.**
 
-    When your system is at risk of spike events, the team must run a spikes test and tune the system several times
+    When your system is at risk of spike events, the team must run a spikes test and tune the system several times.
 * **Monitor.**
 
     Backend monitoring is a must for successful outcomes of this test.
@@ -87,5 +87,5 @@ A spike test gets its name from the shape of its load when represented graphical
 
 Some performance metrics to assess in spike tests include pod speeds, recovery times after the load rush, time to return to normal, or the behavior on crucial system processes during the overload.
 
-Finding how the system responds (if it survives) to the sudden rush helps to optimize it to guarantee that it can perform during a real event. Often the load is so high that the whole system may have to be optimized to deal with the key processes. In these cases, repeat the test until the system confidence is high.
+Finding how the system responds (if it survives) to the sudden rush helps to optimize it to guarantee that it can perform during a real event. In some events, the load is so high that the whole system may have to be optimized to deal with the key processes. In these cases, repeat the test until the system confidence is high.
 

src/data/markdown/translated-guides/en/06 Test Types/07-breakpoint-testing.md

@@ -27,7 +27,7 @@ Teams execute a breakpoint test whenever they must know their system's diverse l
 * If current resource consumption is considered high
 * After significant changes to the code-base or infrastructure.
 
-How often to run this test type depends on the risk of reaching the system limits and the number of changes and code additions.
+How often to run this test type depends on the risk of reaching the system limits and the number of changes to provision infrastructure components.
 
 Once the breakpoint runs and the system limits have been identified, you can repeat the test after the tuning exercise to validate how it impacted limits. Repeat the test-tune cycle until the team is satisfied.