kubeshop · jfermi · Feb 8, 2024
@@ -1,5 +1,20 @@
 # Gitops Testing with ArgoCD
 
+Tools like ArgoCD are used to do the heavy lifting of keeping your Kubernetes cluster in sync with your Git repository; as soon as a difference is detected between Git and your cluster, it is deployed to ensure that your repository is the source-of-truth for your runtime environment.
+
+## Benefits of the GitOps Approach
+
+- Since your tests are included in the state of your cluster you are always able to validate that your application components/services work as required.
+- Since tests are executed from inside your cluster there is no need to expose services under test externally purely for the purpose of being able to test them.
+- Tests in your cluster are always in sync with the external tooling used for authoring
+- Test execution is not strictly tied to CI but can also be triggered manually for ad-hoc validations or via internal triggers (Kubernetes events).
+- You can leverage all your existing test automation assets from Postman, or Cypress (even for end-to-end testing), or … through executor plugins.
+
+Conceptually, this can be illustrated as follows:
+
+![GitOps Flow](../img/git-ops-flow.jpeg)
+
+
 The following is a step-by-step walkthrough to test the automated application deployment and execution of Postman collections in a local Minikube cluster.
 
 Let’s start with setting things up for our GitOps-powered testing machine!

@@ -1,5 +1,20 @@
 # GitOps Testing with Flux
 
+Tools like Flux are used to do the heavy lifting of keeping your Kubernetes cluster in sync with your Git repository; as soon as a difference is detected between Git and your cluster it is deployed to ensure that your repository is the source-of-truth for your runtime environment.
+
+## Benefits of the GitOps Approach
+
+- Since your tests are included in the state of your cluster you are always able to validate that your application components/services work as required.
+- Since tests are executed from inside your cluster there is no need to expose services under test externally purely for the purpose of being able to test them.
+- Tests in your cluster are always in sync with the external tooling used for authoring
+- Test execution is not strictly tied to CI but can also be triggered manually for ad-hoc validations or via internal triggers (Kubernetes events)
+- You can leverage all your existing test automation assets from Postman, or Cypress (even for end-to-end testing), or … through executor plugins.
+
+Conceptually, this can be illustrated as follows:
+
+![Flux Flow](../img/flux-flow.png)
+
+
 ## Tutorial
 
 The following is a step-by-step walkthrough to test the automated application deployment and execution of Postman collections in a local Kind cluster.

@@ -17,11 +17,11 @@ To leverage webhooks, you need to ensure that the platform that you want to send
 
 You can create a webhook from the dashboard, use the CLI, or create it as a custom resource. Before we show how it’s done, let’s understand a few scenarios where Webhooks in Testkube shine:
 
-- Incident Management & Response: Webhooks can be used to create incidents and alert on-call teams when a critical test fails. This ensures a timely response and avoids any potential disruption due to failures and bugs. With Testkube, you can configure incident management tools like PagerDuty and OpsGenie to receive alerts based on critical events for your tests.
+- Incident Management & Response: Webhooks can be used to create incidents and alert on-call teams when a critical test fails. This ensures a timely response and avoids any potential disruption due to failures and bugs. With Testkube, you can configure incident management tools like [PagerDuty](https://www.pagerduty.com/) and [OpsGenie](https://www.atlassian.com/software/opsgenie) to receive alerts based on critical events for your tests.
 
-- Communication and Collaboration: You can configure Webhooks in Testkube to send alerts to your teams in your communication tool. This will notify your team of any critical event that needs attention and attend to it before the issue escalates. Some of the popular communications tools like Slack and MS Teams can be configured to receive alerts from Testkube.
+- Communication and Collaboration: You can configure Webhooks in Testkube to send alerts to your teams in your communication tool. This will notify your team of any critical event that needs attention and attend to it before the issue escalates. Some of the popular communications tools like [Slack](https://slack.com/) and [MS Teams](https://teamsdemo.office.com/#/) can be configured to receive alerts from Testkube.
 
-- Monitoring and Observability: Webhooks can also be used to send alerts and notifications to your monitoring and observability tools like Prometheus and Grafana. This provides visibility into your tests, alerts you, and ensures that timely corrective actions can be taken.
+- Monitoring and Observability: Webhooks can also be used to send alerts and notifications to your monitoring and observability tools like [Prometheus](https://prometheus.io/) and [Grafana](https://grafana.com/). This provides visibility into your tests, alerts you, and ensures that timely corrective actions can be taken.
 
 
 ## Creating a Webhook

@@ -2,6 +2,8 @@ import Admonition from "@theme/Admonition";
 
 # OWASP Zed Attack Proxy Executor
 
+In today’s software development landscape, ensuring the security of your applications is one of the most important yet often overlooked tasks. With the increasing adoption of containerization and Kubernetes for app deployment, it becomes crucial to strengthen your applications against vulnerabilities and attacks. One effective tool that can aid in this endeavor is [OWASP Zed Attack Proxy (ZAP)](https://www.zaproxy.org/). 
+
 Starting from version 1.12, Testkube has a dedicated executor for running ZAP tests. All you need to do is populate a file with the necessary parameters and create a Testkube test.
 
 Default command for this executor is `<pythonScriptPath>`, which will be calculated based on the test type.