Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overview, reorganize into micro and macro phases #7

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 20 additions & 15 deletions Modules/High-level overview of the load testing process.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,21 +7,8 @@ In the last section, you learned what load testing is, how it differs from perfo
- Executing load tests
- Analysis of load testing results

For clarity, these activities are shown as distinct phases here; however, in practice, they often overlap. Like the application-release process, the testing process should be continuous and Agile, with each small increment building upon previous work, growing more and more robust over time.

![Continuous Testing Snowball](../images/continuous-testing-snowball.png)


Just like application code, a test starts slowly. At the mountain's peak, the test is in its simplest form. You can think of an early-stage test as primarily **risk-based**: testing at this level is a reaction to probable failures. These tests are written specifically to prevent failure in an application's most critical components, and there might not be enough time for anything else.

As testing matures within the project, it may start to include **regression**. Now that all the high-risk areas are covered, teams have time to make tests a bit more backward-compatible and preventative, and they write tests to see if new code breaks past functionalities.

The Continuous Testing Snowball gathers speed as the team grows along with the test suite, focusing on **automating** more and more parts of the testing process with every iteration or sprint. A repeatable framework is established. In this stage, the snowball is at its fastest speed.

At the bottom of the slope, continuous testing has evolved testing to such an extent that the team can expand its focus from addressing specific defects to increasing overall **reliability and confidence** in the application's ability to withstand unexpected events. The framework is made even more robust with more exploratory types of testing like Chaos Engineering.

The focus of Continuous Testing is on organically and iteratively evolving the testing suite in parallel with the application, starting with something small with the goal of making enough incremental changes until it is more robust.

In practice, these phases often overlap, and they happen iteratively, occuring in cycles across a broader, more gradual shift towards increasingly robust testing.
Like the application-release process, the testing process should be continuous and Agile, with each small increment building upon previous work.

## Planning for load testing

Expand Down Expand Up @@ -89,6 +76,24 @@ Without ensuring that load testing is done continuously, load testing can become

As the testing suite grows in maturity and scope, teams should naturally create more efficient frameworks for running tests, managing notifications, analyzing results, and reporting. In this way, testing can start very simply, usually around the most critical or high-risk functionalities of the application, then evolve and improve organically along with the application.

## Maturing test aims: from risk-based to reliability

These preceding phases happen in iterations, and the goals of the testing-suite mature as the organization gains momentum.

![Continuous Testing Snowball](../images/continuous-testing-snowball.png)

Early-stage tests are often primarily **risk-based**: testing at this level is a reaction to probable failures. These tests are written specifically to prevent failure in an application's most critical components, and there might not be enough time for anything else.

As testing matures within the project, it may start to include **regression**. Now that all the high-risk areas are covered, teams have time to make tests a bit more backward-compatible and preventative, and they write tests to see if new code breaks past functionalities.

The Continuous Testing Snowball gathers speed as the team grows along with the test suite, focusing on **automating** more and more parts of the testing process with every iteration or sprint. A repeatable framework is established. In this stage, the snowball is at its fastest speed.

At the bottom of the slope, continuous testing has evolved testing to such an extent that the team can expand its focus from addressing specific defects to increasing overall **reliability and confidence** in the application's ability to withstand unexpected events. The framework is made even more robust with more exploratory types of testing like Chaos Engineering.

The focus of Continuous Testing is on organically and iteratively evolving the testing suite in parallel with the application, starting with something small with the goal of making enough incremental changes until it is more robust.



## Test your knowledge

### Question 1
Expand Down