Slide 1

Slide 1 text

qaware.de Quadratisch. Praktisch. Gut. K8s-native Quality Assurance mit Testkube Mario-Leander Reimer [email protected] @LeanderReimer

Slide 2

Slide 2 text

2 Mario-Leander Reimer Principal Software Architect @LeanderReimer #cloudnativenerd #qaware #gernperDude

Slide 3

Slide 3 text

Holistic Continuous Delivery is not so easy! QAware | 3 Continuous Delivery Low Risk Releases Less Rework Fast Time to Market Better Products Lower Costs Happier Teams Happier Users Loosely Coupled Architectures Maintainable Code Empowered Teams Continuous Security from Day 1 Test Automation Continuous Integration GitOps Deployment Automation Monitoring and Alerting

Slide 4

Slide 4 text

Holistic Software Product Quality is a lot of work! QAware | 4 Software Product Quality (ISO 25010) ● Modularity ● Reusability ● Analysability ● Modifiability ● Testability Maintainability ● Confidentiality ● Integrity ● Non-repudiation ● Authenticity ● Accountability Security ● Adaptability ● Installability ● Replaceability Portability ● Co-existence ● Interoperability Compatibility ● Maturity ● Availability ● Fault Tolerance ● Recoverability Reliability ● Time Behaviour ● Resource Utilization ● Capacity Efficiency ● Completeness ● Correctness ● Appropriateness Functional Suitability ● Operability ● Learnability ● UI Aesthetics ● Accessibility Usability

Slide 5

Slide 5 text

Product Assembly Line

Slide 6

Slide 6 text

Monolithic, linear CI/CD pipelines are suboptimal and will result in delayed feedback and long release cycles. QAware | 6 Usually delayed until the end of sprint or the release. Which one first? Functionality vs. Performance vs. Security?

Slide 7

Slide 7 text

A microservice architecture with many downstream dependencies is complex and really hard to test. QAware | 7 Cluster Microservice A Microservice B Microservice C External System X External System Y Team A Team C Team B Unknown

Slide 8

Slide 8 text

Why not run (non)-functional tests against a cloud-native microservice architecture continuously or triggered on the cluster itself?

Slide 9

Slide 9 text

Core Principles and Concepts of a Product Assembly Line ■ Separation of Concerns – Do one thing, and do one thing well. – Separate and explicitly model distinct development lifecycle phases: Build, CI, Deploy, E2E Test, … ■ Choreography over Orchestration – Codified or configured downstream dependencies in the pipelines and triggers must be avoided. – The product assembly line (PAL) is event-driven: time-based, commit based, deployment-based, release-based, on-demand ■ Hollywood Principle: Don’t call us. We call you! – Loose coupling. Tests and Suites do not need knowledge about components or environments – Instead the individual application build / deployment pipelines trigger the tests via events ■ GitOps Principles – All e2e product tests as well as all components are GitOps managed. Auditable. Versioned. Easy Time Travel (e.g. revert to previous version) – Current BOM (Bill of Material) can be determined via individual state repositories ■ Holistic Quality – Single source of (quality) truth. All relevant quality attributes are aggregated. QAware | 9

Slide 10

Slide 10 text

Conceptual PAL Architecture QAware | 10 Packages Package publish update Run deploy watch Deploy watch Dev GitOps Build push Checkout Build Test Quality Package Dev Test (E2E, NFA) trigger test Tests

Slide 11

Slide 11 text

Hello Testkube. Your friendly cloud-native testing framework for Kubernetes QAware | 11 ■ Testkube natively integrates test orchestration and execution into Kubernetes and your CI/CD or GitOps pipeline ■ Avoids vendor lock-in for test orchestration and execution in CI/CD pipelines ■ Makes it possible to decouple test execution from build processes; test engineers should be able to run specific tests whenever needed ■ Makes it easy to run any kind of tests - functional, load/performance, security, compliance, etc. in your clusters, without having to wrap them in docker-images or providing network access ■ Provides a modular architecture for adding new types of tests and executors ■ https://github.com/kubeshop/testkube

Slide 12

Slide 12 text

Testkube Architecture and Concepts QAware | 12 https://kubeshop.github.io/testkube/architecture

Slide 13

Slide 13 text

kubeshop/testkube lreimer/hands-on-testkube

Slide 14

Slide 14 text

Architectural fitness functions continuously validate the (non)-functional requirements of a system. QAware | 14 https://www.thoughtworks.com/de/radar/techniques/architectural-fitness-function

Slide 15

Slide 15 text

Some Architectural Fitness Function Examples QAware | 15 https://www.thoughtworks.com/de/insights/articles/fitness-function-driven-development describe "Performance" do it "completes a transaction in under 2 seconds" do expect(k6.check_transaction_round_trip_time()).to < 2 end it "has less than 10% error rate for 10000 transactions" do expect(k6.check_error_rate_for_transactions(10000)).to < .1 end end describe "Security" do describe “Static Analysis” do it "should not have plaintext secrets in codebase" do expect(code.has_secrets_in_codebase()).to_not be(true) end end describe “Dynamic Analysis” do it "should not have any of the OWASP Top 10" do expect(zap.has_owasp_top_10_vulnerabilities()).to be(false) end end end

Slide 16

Slide 16 text

Conceptual PAL Architecture QAware | 16 Packages Package publish update Run deploy watch Deploy watch Dev GitOps Build push Checkout Build Test Quality Package Dev Test (E2E, NFA) trigger test Tests Quality Cockpit report PO report Build Status Code Quality Test Results fitness promote ?

Slide 17

Slide 17 text

qaware.de QAware GmbH Aschauer Straße 32 81549 München Tel. +49 89 232315-0 [email protected] twitter.com/qaware linkedin.com/company/qaware-gmbh xing.com/companies/qawaregmbh slideshare.net/qaware github.com/qaware