docs(registry-operator): selected e2e testing framework (#20)

# Proposed Architectural Decision Record (mADR)

## Checklist

- [x] The context and problem statement are clearly articulated.
- [x] The considered options are listed with relevant links or
references.
- [x] The chosen option is clearly stated along with the rationale.
- [x] The mADR template is filled out accurately.
- [x] Any additional information or references are included.

<!-- Link to the discussion -->
Closes #6

Signed-off-by: Mateusz Urbanek <mateusz.urbanek.98@gmail.com>

docs/4-operator-mvp-roadmap → docs/4-operator-mvp-roadmap.md

@@ -17,6 +17,6 @@ Minimum Viable Product (MVP) refers to the initial version of a product that inc
 
 ## Decision Outcome
 
-Selected option: "Medium MVP" with default configuration, because empty operator scaffolding doesn't provide any project value from `Registry` perspective, but integration with protocols like `s3` and `filesystem` will be demanding and need a stable working fundations. 
+Selected option: *Medium MVP* with default configuration, because empty operator scaffolding doesn't provide any project value from `Registry` perspective, but integration with protocols like `s3` and `filesystem` will be demanding and need a stable working fundations. 
 
 As a descussion result the detailed `ROADMAP.md` is created in `registry-operator` repo.  

docs/5-docs-static-site-generator.md

@@ -4,7 +4,9 @@
 
 ## Context and Problem Statement
 
-[Describe the context and problem statement prompting the need for this mADR.]
+Effective documentation is paramount for the successful adoption and utilisation of the `registry-operator`, a robust tool tailored for managing CNCF Distribution Registry instances. As developers and DevOps teams engage with the `registry-operator`, they require comprehensive, easily accessible documentation to streamline deployment, scaling, and management tasks.
+
+The choice of documentation framework or static site generator is crucial to ensure that the documentation meets the needs of our users. Templating flexibility, support for custom scripts, and availability of extra plugins for enhancing functionality are key factors to consider in this decision-making process.
 
 ## Considered Options
 

docs/6-e2e-testing-framework.md

@@ -0,0 +1,22 @@
+# End-to-End Testing Framework
+
+[![](https://img.shields.io/badge/Discussion-6-green)](https://github.com/registry-operator/adr/issues/6)
+
+## Context and Problem Statement
+
+Ensuring the reliability and functionality of the registry-operator is essential to maintain a seamless experience for developers and DevOps teams utilizing CNCF Distribution Registry instances. End-to-end testing plays a critical role in validating the deployment, scaling, and management capabilities of the registry-operator across various scenarios.
+
+The selection of an appropriate end-to-end testing framework is paramount to establish robust testing standards and practices. Factors such as adherence to language idioms, support for testing complex workflows, community adoption, and extensibility are crucial considerations in this decision-making process.
+
+## Considered Options
+
+
+* [behave](https://github.com/behave/behave) (Python)
+* [Ginkgo](https://onsi.github.io/ginkgo/) and [Gomega](https://onsi.github.io/gomega/) (Go)
+* [pytest-bdd](https://github.com/pytest-dev/pytest-bdd) (Python)
+* [Radish](https://github.com/radish-bdd/radish) (Python)
+* [testing](https://pkg.go.dev/testing) (Go)
+
+## Decision Outcome
+
+Selected option: *pytest-bdd*, because it has great community support, integrates well with other *pytest* plugins, is well integrated with `*.feature` files.