QA, Testing & Observability

Manuální regresní testování je nejdražší způsob, jak zpomalit vývoj. QA tým, který před každým releasem 3 dny proklikává stejné scénáře, je bottleneck. Test automation přesouvá regresi do CI pipeline — běží při každém commitu, výsledek za minuty.

Test pyramid v praxi: Unit testy (70%) — rychlé, izolované, stovky za sekundy. Integrační testy (20%) — API kontrakty, databázové operace, message brokery. E2E testy (10%) — kritické business flows přes celý stack. Poměr není dogma, ale směr — více unit, méně e2e.

E2E framework: Playwright pro web (multi-browser, auto-waiting, network interception). Detox pro React Native, XCTest/Espresso pro nativní. Page Object Model pro maintainability. Visual regression testing (Percy, Chromatic) pro UI změny.

CI integrace: Testy běží v GitHub Actions / GitLab CI při každém push. Paralelizace pro rychlost — 500 testů za 5 minut, ne 45. Flaky test detection a karanténa — nestabilní test neblokuje pipeline, ale generuje alert. Test report s coverage trendy.

Contract testing: Pact pro API kontrakty mezi frontend a backend, mezi microservices. Provider ověřuje kontrakt v svém CI — breaking change se odhalí před merge, ne v integraci. Consumer-driven contracts pro nezávislé týmy.

Monitoring říká ŽE je problém. Observability říká PROČ. S monitoringem víte, že API je pomalé. S observability vidíte konkrétní trace: request prošel přes 6 služeb, bottleneck je query v order-service, která trvá 8s kvůli missing indexu. Fix za 5 minut místo 5 hodin.

Tři pilíře: Metriky (Prometheus) — číselné time-series, alerting na SLO. Logy (Loki, Elasticsearch) — strukturované eventy s kontextem. Traces (Jaeger, Tempo) — cesta requestu přes distribuovaný systém. Tři pilíře propojené — z alertu kliknete na relevantní trace, z trace na logy.

OpenTelemetry jako standard: Vendor-neutral instrumentace. Jeden SDK, export do jakéhokoliv backendu (Grafana stack, Datadog, New Relic). Auto-instrumentation pro populární frameworky (.NET, Java, Python, Node.js). Custom spans pro business logiku — vidíte nejen HTTP requesty, ale i „zpracování objednávky trvalo 3.2s”.

Dashboardy a alerting: Grafana dashboardy pro SRE (SLO burn rate, error budget), pro dev tým (deployment frequency, lead time, MTTR), pro business (konverze, revenue, active users). Alerting na symptomy (SLO violation), ne na příčiny (CPU > 80%). PagerDuty/OpsGenie integrace s eskalací.

Náklady pod kontrolou: Observability data rostou rychle. Sampling strategie (head-based, tail-based) pro traces. Log levels a retention policies. Metriky s vhodnou granularitou (ne každou sekundu pro vše). Typicky 60-80% úspora oproti „logujeme všechno”.

AI model bez evaluací je black box v produkci. Funguje? Možná. Lépe než minulý týden? Nevíte. Bezpečně? Doufáte. AI evaluace zavádějí měřitelnost — víte přesně, jak model performuje, kde selhává a kdy degraduje.

LLM evaluace: Precision, recall, faithfulness (hallucination rate), relevance, safety scoring. Evaluační datasety specifické pro doménu — ne generic benchmarky, ale reálné dotazy vašich uživatelů. Automatické evaluace přes LLM-as-judge (GPT-4 hodnotí odpovědi produkčního modelu) i human-in-the-loop.

Drift detection: Model quality se mění v čase — distribuce vstupních dat se posouvá, uživatelské chování se mění, svět se mění. Monitoring klíčových metrik s alertingem: pokud precision klesne o 5%, dostanete alert. Sliding window analýza pro detekci pozvolné degradace.

A/B testing modelů: Nový model vs. stávající. Traffic split 50/50, měření business metrik (konverze, user satisfaction, task completion) i technických (latence, cost per request). Statistická signifikance před rozhodnutím — ne „zdá se lepší”, ale „je lepší s p < 0.05”.

Evaluační pipeline: Automatizované evaluace v CI/CD — nový model musí projít eval suite před deploy do produkce. Quality gate: pokud precision < 0.85 nebo safety score < 0.95, deploy se zastaví. Regression testing — nový model nesmí být horší v žádné kategorii.

Tooling: LangSmith, Ragas, custom eval frameworks. Eval datasety verzované v Gitu. Výsledky v Grafana dashboardech vedle infrastrukturních metrik. Jeden pohled na health celého AI systému.

Zákazníci jsou nejhorší load testing nástroj. Když se dozvíte o performance problému z Twitteru, je pozdě. Load testing odhalí limity systému v kontrolovaném prostředí — víte přesně, kde je bottleneck a kolik headroom máte.

Typy testů: Load test (expected traffic), stress test (2-3× expected), spike test (náhlý nárůst), soak test (konstantní zátěž 24-72h pro memory leaky a connection pool exhaustion). Každý typ odhalí jiný problém. Neděláme jen „hodíme na to 1000 uživatelů” — simulujeme reálné vzorce chování.

k6 jako primární nástroj: JavaScript scripty, CI/CD integrace, Grafana dashboardy. Scripty verzované v Gitu vedle aplikačního kódu. Thresholds definované jako code — test failne, pokud P95 latence > 200ms nebo error rate > 1%. Distribuovaný load z více regionů pro globální aplikace.

Profiling a bottleneck analýza: Load test je jen začátek. Důležité je pochopit PROČ systém nedosahuje cíle. APM profiling (async profiler, dotTrace), database query analysis (slow query log, execution plans), resource monitoring (CPU, memory, network, disk I/O). Identifikujeme top 3 bottlenecky a fixujeme je.

Baseline a trending: Každý release porovnáváme s baseline. Performance regression detection automaticky v CI. Trend dashboard — latence P95 roste o 5ms s každým releasem, za 6 měsíců bude problém. Lepší to řešit teď než pak.

Capacity planning: Z load testů extrapolujeme: kolik uživatelů zvládneme na aktuální infrastruktuře? Kolik stojí škálování na 2×? Na 10×? Data-driven rozhodování o infrastruktuře, ne odhady.

Incidenty se stávají. Důležité je, co děláte potom. Organizace, které nemají incident response proces, improvizují pod stresem. Výsledek: dlouhý MTTR, chybná komunikace, opakování stejných chyb. Stavíme procesy, které fungují i v neděli v noci.

Severity framework: SEV1 (business impact, zákazníci postiženi) → okamžitá eskalace, war room, 15-min status updates. SEV2 (degradovaný výkon) → on-call reaguje do 30 min. SEV3 (minor issue) → řeší se v business hours. SEV4 (cosmetic) → backlog. Jasná pravidla, žádné debaty o severitě v průběhu incidentu.

Runbooky: Step-by-step postupy pro top 15-20 incidentů. „API vrací 500” → check health endpoints → check database connectivity → check recent deployments → rollback if needed. Runbook není esej — je to checklist. Aktualizujeme po každém post-mortem.

On-call: Rotace (typicky týdenní), primární + sekundární on-call. PagerDuty/OpsGenie s intelligent routing. Eskalační matice — pokud primární nereaguje do 5 minut, notifikace sekundárnímu. Kompenzace za on-call — lidé, kteří se budí v noci, si zaslouží uznání.

Blameless post-mortem: Do 48 hodin po SEV1/SEV2. Timeline incidentu, root cause, contributing factors, action items s vlastníky a deadliny. Žádné „kdo za to může” — místo toho „co změníme, aby se to neopakovalo”. Sdílení learnings across organizací. Post-mortem databáze jako knowledge base.

Chaos engineering: Controlled failure injection v produkci. Vypnutí instance, zvýšení latence, simulace network partition. Ověření, že failover a degradation mechanismy fungují. Netflix-style Game Days kvartálně.

Quality gate je automatický strážce. Kód, který nesplňuje quality standard, se nedostane do produkce. Žádné výjimky, žádné „deploynu to a opravím později”. Gate je nemilosrdný, ale spravedlivý — pravidla jsou jasná a známá předem.

Statická analýza: SonarQube / SonarCloud pro code quality (code smells, duplicity, complexity), security (OWASP Top 10, CWE), coverage. Quality profiles per projekt — jiné standardy pro nový kód vs. legacy. Nový kód musí mít coverage > 80%, zero critical issues. Postupné zpřísňování pro existující codebase.

Security gates: Dependency scanning (Snyk, Dependabot) — známé CVE v závislostech blokují deploy. Container image scanning (Trivy) — vulnerable base images. SAST (static application security testing) integrovaný do CI. Secrets detection (GitLeaks) — žádné credentials v kódu.

Performance gates: Automatizovaný load test v CI (subset, 5 minut). Pokud P95 latence vzroste o >10% oproti baseline, deploy se zastaví. Bundle size check pro frontend — nový dependency nesmí přidat víc než 50KB bez explicitního review. Lighthouse score pro web performance.

Deployment gates: Canary deployment s automatickou evaluací. Metriky (error rate, latence) porovnány s baseline. Pokud degradace > threshold, automatický rollback. Progressive delivery — gate na každém kroku (5% → 25% → 50% → 100%).

Culture: Quality gates fungují, jen pokud je tým přijme. Není to nástroj managementu pro kontrolu — je to safety net pro vývojáře. Gate by měl chytit to, co code review přehlédne. False positive rate pod 5% — jinak tým začne gaty ignorovat.