تست نرم افزار, مدیریت تست

مدیریت محیط تست؛ راهنمای IaC، داده و Drift

انتشار در تاریخ توسط محمد عسکری

Regression کامل سبز است، اما Release در Production شکست می‌خورد. بررسی نشان می‌دهد Staging هنوز Feature flag قدیمی، Schema جدیدتر از Build، Cache خاموش و Sandbox درگاه با رفتار ساده‌شده داشته است. Test caseها الزاماً بد نبودند؛ محیط تست نسخه و رفتار قابل‌اعتماد نداشت و نتیجهٔ سبز دربارهٔ سیستم هدف ادعای بیش‌ازحد ساخته بود.

مدیریت محیط تست یا TEM فقط روشن نگه‌داشتن چند Server نیست. محیط، ترکیب نسخهٔ Application/Service، Infrastructure، Configuration، Feature flag، Schema، Dependency، Identity/Secret، داده، Network، Device، Observability، Tool و بازهٔ زمانی است. اگر یکی از این‌ها نامعلوم باشد، بازتولید Failure و تفسیر Result دشوار می‌شود.

این راهنما از Inventory و Environment Manifest تا IaC، Ephemeral/shared، Service virtualization، Test data، Drift، Health gate، رزرو، امنیت، Observability، Cost و Incident را با یک مثال پرداخت ایرانی پوشش می‌دهد. هدف «کپی کامل Production» نیست؛ محیطی است که برای Risk و Test مشخص، نماینده، قابل‌بازتولید، کنترل‌پذیر و قابل‌مشاهده باشد.

خلاصهٔ اجرایی مدیریت محیط تست

  • برای هر Environment یک Purpose، Owner، Consumer و Service level تعریف کنید.
  • Environment portfolio را بر اساس Test level/Risk بسازید؛ یک Staging برای همه کافی نیست.
  • نسخه‌های App/Service/Schema/Config/Data/Dependency را در Manifest ذخیره کنید.
  • Infrastructure/Configuration را تا حد مناسب به‌صورت Code و Reviewشده مدیریت کنید.
  • Declared، deployed، actual و target state را جدا و Drift را آشکار کنید.
  • Ephemeral و Shared را با Trade-off سرعت، Fidelity، Cost و Contention انتخاب کنید.
  • داده و Identity را Namespaceدار، حداقلی، مجاز و قابل Cleanup کنید.
  • Dependency واقعی/Sandbox/Virtual را صریح Label و Contract آن را Test کنید.
  • Health gate ماشینی قبل از Suite اجرا شود؛ «Pod سبز» کافی نیست.
  • هر Run به Environment ID/Manifest hash و Trace/Log قابل‌ردیابی وصل شود.
  • Lease، TTL، Quota، Budget و Cleanup owner داشته باشید.
  • Failure را Product/Test/Data/Environment/Dependency طبقه‌بندی و Unknown را پنهان نکنید.

محیط خوب «Fit for Purpose» است، نه همیشه مشابه کامل Production

ویژگی معنا ضدالگو
Representative Risk و رفتار مورد آزمون را به‌اندازه لازم بازنمایی می‌کند کپی ظاهری بدون Traffic/identity/dependency semantics
Reproducible نسخه/داده/Config قابل بازسازی یا Trace است Snowflake با تغییر دستی
Controlled تغییر، دسترسی، side effect و concurrency مهار شده‌اند همه Admin؛ shared data بدون namespace
Observable سلامت و رفتار با metric/log/trace قابل بررسی است فقط HTTP ۲۰۰ health endpoint
Recoverable Reset/restore/recreate و owner مشخص دارد «Restart کن شاید درست شود»
Economical ارزش Signal با هزینه/ظرفیت متناسب است محیط رهاشده یا کم‌منبع و غیرنماینده

محیط Performance ممکن است Scale، topology و noisy-neighbor نماینده بخواهد؛ محیط PR سرعت و ایزوله‌سازی؛ محیط Security مجوز و containment؛ محیط Mobile ماتریس Device/OS. «Parity» باید روی Dimensionهای مرتبط با Risk تعریف شود.

پرتفوی محیط‌ها را طراحی کنید

محیط هدف Fidelity غالب چرخه عمر
Local/component Feedback سریع، debug Contract/logic؛ dependency محدود شخصی/کوتاه
Ephemeral PR integration تغییر و review نسخهٔ branch + template استاندارد ایجاد بر PR، TTL
Shared integration تعامل چند Service/Team active-version matrix و event flow ماندگار با booking/change
Staging/pre-production release rehearsal/system gate deployment/config/identity نزدیک هدف کنترل‌شده و نسخه‌دار
Performance load/capacity/resilience scale/topology/data distribution on-demand/window
Security scan/pentest/fuzz مجاز attack surface + containment ایزوله/Rule of Engagement
Device/browser lab compatibility/real hardware OS/browser/device/network pool/reservation
Production verification Observation/controlled verification واقعیت عملیاتی دائمی، سطح ریسک محدود

تست کنترل‌شده در Production مطلقاً ممنوع نیست، اما Authorization، blast radius، synthetic tenant، guardrail و rollback لازم دارد. راهنمای Shift-Right و Testing in Production سطح‌های ریسک و Entry gate را جدا توضیح می‌دهد.

Environment Manifest؛ شناسنامهٔ قابل‌نسخه‌گذاری

Environment ID / purpose / class: …
Owner / support / consumers: …
Lease / TTL / change window: …
IaC/config commit + state/workspace: …
Application/service/image versions: …
DB engine/schema/migration/backfill: …
Feature flags/runtime config: …
Dependency mode/version: real/sandbox/virtual …
Data snapshot/seed/label/retention: …
Identity/roles/secret references: …
Network/DNS/cert/egress: …
Devices/browser/locale/timezone: …
Observability endpoints/schema: …
Quota/budget/cost labels: …
Health evidence / last drift scan: …
Known differences from target: …
Reset/restore/cleanup runbook: …

Manifest باید هنگام اجرای Test snapshot شود؛ لینک به «نسخه latest» بعداً Evidence نیست. Result هر Run به Environment ID، Manifest hash، Build و Data namespace وصل شود.

چهار State را با هم اشتباه نگیرید

  • Declared state: آنچه Git/Template/Policy می‌گوید؛
  • Planned state: تغییر پیشنهادی برای Apply/Deploy؛
  • Deployed state: آنچه Pipeline می‌گوید اعمال کرده؛
  • Actual state: آنچه Runtime/API/Inventory اکنون نشان می‌دهد؛
  • Target environment state: Production یا هدف مقایسه در زمان مشخص.

Drift می‌تواند میان هر دو State رخ دهد. «IaC داریم» به معنی نبود Drift نیست؛ Console change، failed apply، default provider، mutating admission، manual hotfix و secret/config بیرونی می‌توانند State را تغییر دهند.

محیط باید در زمان تصمیم Pipeline آماده و قابل اعتماد باشد؛ طراحی Fast/slow lane و Feedback budget در راهنمای Continuous Testing در CI/CD مکمل این مدل است.

Infrastructure as Code با Review و State امن

راهنمای رسمی Microsoft دربارهٔ IaC تعریف زیرساخت در فایل نسخه‌دار و کاهش Snowflake environment را توضیح می‌دهد. مزیت‌های اصلی:

  • Code review و تاریخچهٔ تغییر؛
  • Template و parameter استاندارد؛
  • Provision/Destroy تکرارپذیرتر؛
  • Policy و validation قبل از Apply؛
  • ساخت Self-service با Guardrail؛
  • ارتباط Environment version با Test result.

اما Automation «خطای انسانی را حذف» نمی‌کند؛ خطای Template می‌تواند در مقیاس تکرار شود. Plan، review، policy، limited apply identity، canary و recovery لازم‌اند.

Plan با Apply فرق دارد

مستندات terraform plan می‌گوید Plan State/Config/Remote object را مقایسه و Action پیشنهادی را می‌سازد؛ خود Plan تغییر را اعمال نمی‌کند. Artifact Plan باید به Commit/Workspace/Provider version متصل، Review و در مدت معتبر Apply شود. Plan حاوی دادهٔ حساس را Artifact عمومی نکنید.

State امنیت و مالکیت می‌خواهد

  • Remote backend، encryption، access control و audit؛
  • Locking و جلوگیری از Apply هم‌زمان؛
  • Backup/version و recovery drill؛
  • Secret در State و output مدیریت شود؛
  • Import/move/replace با review؛
  • State محیط‌ها جدا و naming/ownership روشن.

Drift detection و Reconciliation

راهنمای رسمی Terraform دربارهٔ Drift هشدار می‌دهد تغییر دستی می‌تواند State/Configuration/Actual را ناسازگار کند و Reconcile نامحتاطانه حتی Resource را بازسازی یا حذف کند. Drift workflow:

  1. Detect با read-only inventory/plan/health assessment؛
  2. Classify: intentional emergency، unauthorized، provider default، failed rollout یا stale template؛
  3. Assess impact بر Test validity و داده؛
  4. Freeze یا mark environment degraded؛
  5. انتخاب source of truth: import actual، revert manual یا update template؛
  6. Review و Reconcile با backup/stop/owner؛
  7. Health gate و impacted tests را دوباره اجرا کنید؛
  8. Manifest و change record را Update کنید.

Auto-remediation بدون Impact analysis می‌تواند Environment و Evidence درحال‌استفاده را نابود کند.

Container و Kubernetes؛ Isolation را فرض نکنید

Container packaging و scheduling را آسان می‌کند، اما Kernel، node، network، volume، registry و control plane مشترک‌اند. Image یکسان نیز با Config/Secret/Data/Architecture متفاوت رفتار دیگری دارد.

Namespace مرز نام‌گذاری است، نه Sandbox کامل

مستندات Kubernetes Namespaces می‌گوید Namespace گروه Resourceها را Scope می‌کند، اما Node، PersistentVolume و بعضی Objectها cluster-scoped هستند. بنابراین برای محیط PR فقط Namespace کافی نیست:

  • RBAC و Service account حداقلی؛
  • NetworkPolicy برای ingress/egress؛
  • ResourceQuota و LimitRange؛
  • Pod/container security policy/admission؛
  • Secret isolation و external secret scope؛
  • Storage class/PV/backup/cleanup؛
  • DNS/FQDN و جلوگیری از cross-namespace اشتباه؛
  • Node/runtime isolation متناسب Threat model.

ResourceQuota رسمی Kubernetes مصرف تجمعی Resource/Object را در Namespace محدود می‌کند؛ اما Contention موجود یا Resourceهای ازقبل‌ساخته را خودکار حل نمی‌کند. Quota با Capacity planning و Monitoring مکمل است.

Ephemeral در برابر Shared environment

معیار Ephemeral Shared
Isolation تغییر بالاتر در صورت Namespace/Account درست تداخل نسخه/داده محتمل
سرعت شروع وابسته به Provision/cache اگر سالم و آزاد باشد سریع
Fidelity یکپارچگی ممکن است Dependency مجازی/کوچک باشد Topology چندتیمی واقعی‌تر
Cost قابل‌کنترل با TTL؛ burst بالا Idle cost و queue/booking
Debug ممکن است زود Destroy شود State ماندگار ولی آلوده
Governance Template/policy/expiry booking/change/freeze/reset

Ephemeral contract

  • ایجاد از Commit/Template مشخص؛
  • Unique ID، Owner، PR و cost label؛
  • Readiness و seed before test؛
  • TTL و extension policy؛
  • Artifact export پیش از destroy؛
  • Cleanup idempotent و محدود به Namespace/Account؛
  • Orphan sweeper با dry-run/allowlist؛
  • Failure quarantine کوتاه با budget.

Shared contract

  • Reservation/priority و maximum lease؛
  • active-version matrix و compatibility؛
  • change calendar/freeze و announcement؛
  • test-run namespace/data isolation؛
  • maintenance/patch/reset owner؛
  • health status و degraded banner؛
  • conflict/escalation path؛
  • baseline restore بین Campaignها.

Service virtualization و Dependency ladder

نوع مزیت خطر
Stub/Fake سریع، قطعی، Failure قابل‌ساخت Behavior drift و Oracle ساده‌شده
Mock Interaction expectation در Component Coupling به implementation
Service virtualization State/protocol/scenario غنی‌تر مدل پرهزینه و نیازمند owner
Vendor sandbox Contract نزدیک Provider SLA/data/limit و تفاوت Production
Real dependency بیشترین fidelity آن مرز هزینه، side effect، availability و داده

هر Dependency mode در Manifest و Test report Label شود. Virtual service باید Contract version، Scenario، state transition، latency/error profile و Owner داشته باشد. Consumer/provider Contract و active-version gates در راهنمای تست میکروسرویس‌ها توضیح داده شده‌اند.

Sandbox معادل Production نیست

Sandbox درگاه ممکن است Fraud، settlement، callback retry، timeout و error distribution واقعی را ساده کند. آنچه پوشش نمی‌دهد صریح بنویسید و برای Risk باقی‌مانده از Contract، simulation و Production observation مجاز استفاده کنید.

Test data، Identity و Secret

محیط بدون Data contract قابل‌اعتماد نیست. راهنمای مدیریت داده تست تفاوت Synthetic، Masking، Pseudonymization و Subset را شرح می‌دهد. در TEM این Lifecycle را اضافه کنید:

  1. Purpose و minimum fields؛
  2. Source/provenance/consent/authorization؛
  3. Generate/mask/subset و quality validation؛
  4. Seed با version/checksum؛
  5. Namespace per tenant/run؛
  6. Refresh و schema compatibility؛
  7. Retention/cleanup/re-identification review؛
  8. Audit و deletion در snapshot/backup/artifact.

Identity matrix

  • Roleهای واقعی، denied path و cross-tenant؛
  • Service account جدا برای Runtime/Deploy/Test؛
  • هیچ Credential Production در Test؛
  • Secret reference، نه value، در Manifest؛
  • short-lived credential و rotation؛
  • least privilege و audit؛
  • test account expiry/cleanup.

پایگاه داده، Schema و Reset

Container تازه با Database state قدیمی Environment تازه نیست. Manifest باید engine/version، migration، schema، seed/backfill و compatibility را ثبت کند. Fresh migrate و upgrade-from-supported-version هر دو لازم‌اند.

  • Migration checksum و ترتیب؛
  • Backward/forward compatibility در rolling window؛
  • Backup/restore/PITR برای Environment مربوط؛
  • Data invariant بعد seed/reset؛
  • Transaction/queue/cache state cleanup؛
  • Clone masking و retention؛
  • Reset idempotent و scope-safe.

راهنمای تست پایگاه داده Migration، Backfill، Integrity، concurrency و Restore را از «بالا آمدن DB» جدا می‌کند.

Health gate: محیط قبل از Test باید خودش Test شود

Health check فقط CPU یا HTTP ۲۰۰ نیست. Gate ماشین‌خوان باید پیش از Suite اجرا و Evidence آن کنار Result ذخیره شود.

لایه Health contract
Version Build/image/service/schema/flag مطابق Manifest
Dependency DNS/TLS/auth/contract و required mode
Data seed checksum، invariant، namespace و freshness
Capacity CPU/memory/disk/queue/connection budget
Observability trace/log/metric ingest و correlation
Clock/locale timezone/NTP/calendar/encoding
Security role/secret expiry/network policy و no-prod credential
Side effect email/SMS/payment/storage sink به Sandbox/allowlist

اگر Health gate Fail است، Test را «Product failed» نکنید. Run باید Environment-blocked شود؛ اما تکرار Blocker یک Improvement item با Owner/SLA است، نه Excuse نامحدود.

Observability برای بازتولید و Triage

OpenTelemetry Traces، Metrics، Logs و Baggage را به‌عنوان Signalهای قابل‌هم‌بستگی معرفی می‌کند. محیط تست باید Semantic نزدیک هدف داشته باشد، حتی اگر Retention/Sampling/Scale متفاوت است.

  • Run ID، Build، Environment ID، Tenant و Trace ID؛
  • Structured log با schema، نه صرفاً JSON؛
  • Span در مرز Service/Queue/DB/PSP؛
  • Metric health و resource saturation؛
  • Clock sync و timezone؛
  • Artifact link در Failure؛
  • Redaction PII/secret/token؛
  • Retention متناسب Debug و Privacy.

افزودن Telemetry می‌تواند رفتار/هزینه را تغییر دهد؛ overhead و sampling را بسنجید. محیط Performance باید تنظیمات Observability نماینده یا اختلاف مستند داشته باشد.

Environment change management

هر تغییر یک Event قابل‌ردیابی

  • Requester/owner و دلیل؛
  • Environment/Component/Version؛
  • Plan/diff و risk؛
  • Window و consumers متأثر؛
  • Backup/rollback؛
  • Approval policy؛
  • Health/verification؛
  • Notification و Manifest update.

قانون برای تغییر دستی اضطراری

در Incident ممکن است Hotfix دستی لازم شود. آن را ممنوع فرضی نکنید؛ Break-glass identity، audit، expiry، owner و الزام Back-port به Code/Config داشته باشید. Environment پس از تغییر تا Reconcile/Health باید «degraded/drifted» علامت بخورد.

Availability، Booking و Support model

موضوع Policy
Request purpose، versions، duration، data، capacity
Priority release risk/incident/regulatory، نه مقام درخواست‌کننده
Reservation start/end، owner، extension و conflict
Change freeze campaign/benchmark window و emergency path
Support hours، response/restore target و escalation
Status ready/degraded/maintenance/unavailable + cause
Release cleanup/health/cost/artifact confirmation

پورتال Self-service زمانی ارزش دارد که Template curated، Policy، Quota و owner داشته باشد. Azure Deployment Environments نمونه‌ای از Catalog template و Governance برای محیط‌های Development/Test است؛ استفاده از هر Vendor باید با PoC، lock-in، data flow و Cost بررسی شود.

امنیت محیط تست

  • Network segmentation و egress allowlist؛
  • SSO/MFA/RBAC و least privilege؛
  • no shared admin و no production secret؛
  • patch/vulnerability/config scanning؛
  • artifact/backup/log encryption و retention؛
  • supply-chain review برای image/module/plugin؛
  • internet exposure inventory و expiry؛
  • test endpoint banner/allowlist بدون افشای جزئیات؛
  • Rule of Engagement برای DAST/fuzz/performance؛
  • Incident detection/response و forensic evidence.

محیط Test «کم‌اهمیت» نیست؛ ممکن است Source، schema، Credential و دادهٔ نزدیک واقعیت داشته باشد. راهنمای تست امنیت Threat model، سطح‌های آزمون و Evidence امن را پوشش می‌دهد.

Performance environment و مدل بار

Scale یکسان با Production همیشه ممکن یا لازم نیست، اما نسبت‌ها و Bottleneckها باید قابل‌تفسیر باشند:

  • Instance/CPU/memory/storage/network class؛
  • Topology، autoscaling و quota؛
  • Dataset cardinality/skew/history؛
  • Cache warm/cold و CDN؛
  • Dependency/stub latency/error؛
  • background job و noisy neighbor؛
  • observability overhead؛
  • load generator capacity/location؛
  • تفاوت‌ها و مدل Extrapolation.

Threshold روی محیط نصف‌اندازه بدون مدل، Production SLO را ثابت نمی‌کند. راهنمای برنامه تست عملکرد Workload، SLO، percentile و stop condition را تعریف می‌کند.

Failure taxonomy؛ محیط با Defect محصول قاطی نشود

Class مثال Owner نخستین
Product Expected business behavior شکسته Product engineering
Test Selector/oracle/fixture غلط Test owner
Data collision، stale seed، invalid state Data/TEM + test
Environment wrong version، capacity، config drift TEM/platform
Dependency Sandbox/vendor unavailable/changed Integration owner
Unknown Evidence ناکافی Triage owner؛ SLA کوتاه

Rerun نتیجه را Classify نمی‌کند. First-run و final outcome هر دو نگه داشته شوند. Environment issue تکراری باید Problem record و بهبود داشته باشد؛ حذف از Product defect به معنی بی‌اهمیت بودن نیست.

مثال عملی: محیط تست بازپرداخت فروشگاه ایرانی

Purpose و معماری

  • Checkout، Order، Payment، Refund و Ledger با Version مشخص؛
  • PostgreSQL schema/migration، Redis و event broker؛
  • Sandbox درگاه + callback simulator برای timeout/duplicate/out-of-order؛
  • دو Tenant مصنوعی و حساب‌های Roleدار؛
  • UI تومان، Ledger ریال؛ timezone تهران و جلالی/میلادی؛
  • Trace correlation از API تا event/DB؛
  • email/SMS sink محلی، نه مخاطب واقعی؛
  • egress فقط به Endpointهای Allowlist.

Manifest Run

env: refund-pr-4821 / TTL 8h
commits/images: checkout…, payment…, refund…
schema: migration 20260806_03
flags: refund_retry_v2=true
PSP: sandbox contract v… + simulator profile duplicate-callback
data: seed refund-v7 / tenant run-4821
locale: fa-IR / Asia-Tehran / IRR ledger / IRT UI
trace: collector endpoint… / retention 48h
health hash: …

Health gate

  1. Service/image/schema/flag با Manifest برابر؛
  2. DB invariant و seed checksum سبز؛
  3. PSP sandbox و simulator mode قابل‌تشخیص؛
  4. Callback DNS/TLS و signing key Test معتبر؛
  5. Queue/consumer lag زیر Budget؛
  6. دو Tenant از هم مجزا؛
  7. Trace/log/metric با Run ID قابل جست‌وجو؛
  8. SMS/email/payment side effect فقط Sandbox؛
  9. Cleanup dry-run فقط Namespace خود را می‌بیند.

Failure scenario

در تست Callback تکراری دو Ledger effect دیده می‌شود. پیش از ثبت Product defect، Manifest نشان می‌دهد Payment v5 و Refund v7 ترکیب پشتیبانی‌شده‌اند؛ Trace دو Consumer effect را نشان می‌دهد؛ Health data collision را رد می‌کند. حال Evidence برای Product failure معتبرتر است. اگر Version matrix اشتباه بود، Run Environment-invalid و پس از اصلاح دوباره اجرا می‌شد.

Cleanup

Artifact/Trace لازم Export، Test credential Revoke، Tenant namespace حذف، Queue/DB state همان Run پاک، Environment Destroy و cost/cleanup result ثبت می‌شود. حذف گسترده با wildcard یا shared table بدون Scope مجاز نیست.

Cost و FinOps محیط تست

Cloud خودکار ارزان‌تر نیست. Idle environment، overprovision، log retention، egress، device minutes و commercial license هزینه می‌سازند.

Metric Decision Guardrail
Provision lead time p50/p95 Cache/template bottleneck؟ security scan حذف نشود
Ready/healthy availability کدام class قابل‌اعتماد نیست؟ HTTP uptime تنها کافی نیست
Environment-blocked time اثر بر Flow/Release؟ classification ثابت
Cost per environment/run کدام TTL/size بهینه؟ Fidelity/trace حفظ شود
Idle/orphan age چه چیزی خاموش/حذف شود؟ artifact/evidence export
Quota saturation capacity/priority؟ team starvation
Drift age کدام محیط invalid است؟ emergency change context
Reset/recovery time Runbook واقعاً کار می‌کند؟ data integrity

کنترل هزینه

  • Owner/project/purpose/expiry label اجباری؛
  • TTL و scheduler خاموشی برای workload مناسب؛
  • right-size با data، نه کم‌منبع‌کردن کور؛
  • quota/budget/alert و cost anomaly؛
  • shared cache/registry با isolation؛
  • retention tier برای log/artifact؛
  • orphan sweeper با allowlist و recovery؛
  • showback برای تصمیم، نه تنبیه تیم.

انتخاب ابزار TEM

قابلیت پرسش PoC
Provision/IaC Template/version/plan/policy/state/rollback؟
Catalog/self-service curated template، approval، owner، TTL؟
Booking/orchestration shared conflict، priority، freeze و notification؟
Data seed/mask/subset/namespace/cleanup/audit؟
Virtualization protocol/state/error/contract/version؟
Observability manifest/run/trace/log/metric correlation؟
Drift/config read-only detect، diff، approval و reconcile؟
FinOps label/budget/quota/TTL/cost per run؟
Security RBAC/secret/data flow/audit/offline/proxy؟
Exit template/state/data/result export و vendor lock-in؟

هیچ پلتفرم واحدی الزاماً همهٔ این‌ها را بهتر انجام نمی‌دهد. Stack ممکن است Git/IaC، CI، Kubernetes/Cloud، data tooling، virtualization، observability و portal داشته باشد. روش PoC/TCO/Exit در راهنمای انتخاب ابزار تست اتوماسیون برای TEM هم قابل‌تطبیق است.

ملاحظات ویژه تیم‌های ایرانی

  • Registry/module/provider/image از CI داخل ایران و Proxy قابل‌دریافت و Mirror است؟
  • Cloud/SaaS/Device lab از نظر Account، تحریم، پرداخت و قرارداد پایدار و مجاز است؟
  • Template/State/Source/Trace/Data به چه Region/Vendor می‌رود؟
  • PSP Sandbox نیازمند IP allowlist، VPN سازمانی یا callback public است؟
  • SMS/OTP/email به Sink مصنوعی می‌رود و شمارهٔ واقعی مصرف نمی‌کند؟
  • IRR/IRT، فارسی/RTL، ی/ی، ک/ک، موبایل +۹۸/۰۹ و تاریخ جلالی پوشش دارند؟
  • Timezone تهران و تغییرات تاریخی Offset در Container/DB/JVM یکسان است؟
  • License و نرخ ارز با تاریخ در Cost model ثبت شده است؟
  • Fallback self-hosted و export در صورت قطع Vendor وجود دارد؟
  • دورزدن کنترل سرویس یا Binary ناشناس Plan B محسوب نمی‌شود.

Runbook خرابی محیط تست

  1. Runهای جدید را Pause و Status را Degraded/Unavailable کنید.
  2. Timestamp، affected environments/tests و last known good را ثبت کنید.
  3. Health/manifest/drift/capacity/dependency/data را بررسی کنید.
  4. Evidence را پیش از Restart مخرب حفظ کنید.
  5. Owner و Incident severity متناسب اثر Release تعیین کنید.
  6. Recover: rollback/recreate/restore/failover طبق Runbook.
  7. Health gate و smoke/invariant را اجرا کنید.
  8. Runهای invalid را Label و Scope rerun را مشخص کنید.
  9. Root/contributing factors و action را با expiry پیگیری کنید.
  10. Availability/cost/forecast و Manifest را Update کنید.

برنامهٔ ۳۰روزه بهبود TEM

هفتهٔ اول: Inventory و Ownership

  • Environmentها، consumer، owner، purpose و cost را فهرست کنید.
  • Manifest حداقلی و status taxonomy بسازید.
  • Production differences و Riskهای هر class را ثبت کنید.
  • Environment-blocked baseline و failure class را اندازه بگیرید.

هفتهٔ دوم: Code و Health

  • یک Environment پرتکرار را IaC/config version کنید.
  • Plan/review/state/secret و drift scan را تنظیم کنید.
  • Health gate نسخه/data/dependency/observability بسازید.
  • Result را به Manifest hash وصل کنید.

هفتهٔ سوم: Data، Isolation و Lifecycle

  • Run namespace، seed/checksum و cleanup امن بسازید.
  • یک Ephemeral Pilot با TTL/quota/cost label اجرا کنید.
  • Shared booking/change/freeze policy را تعریف کنید.
  • Dependency mode و Contract version را Label کنید.

هفتهٔ چهارم: Pilot و Recovery

  • Release واقعی را از provision تا destroy اجرا کنید.
  • Drift و dependency failure کنترل‌شده تزریق کنید.
  • Recovery/reset و Artifact export را تمرین کنید.
  • Scale/Refactor/Stop و roadmap ۳۰/۶۰/۹۰روزه تعیین کنید.

اشتباه‌های رایج در مدیریت محیط تست

  • Staging = Production: Scale/config/data/identity/dependency تفاوت دارد.
  • IaC = بدون Drift: Actual/state/default/manual change نادیده است.
  • Automation = بدون خطا: خطای Template در مقیاس تکثیر می‌شود.
  • Container = Isolation کامل: Kernel/node/network/volume مشترک است.
  • Namespace = Security boundary: cluster-scoped object و RBAC/Network باقی است.
  • Pod Ready = محیط سالم: version/data/contract/trace بررسی نشده است.
  • Sandbox = Provider واقعی: error/state/SLA و business flow ساده است.
  • Cloud = ارزان: idle/egress/log/license و orphan پنهان‌اند.
  • داده Production کپی شود: Privacy، retention و blast radius خطر دارد.
  • Secret در Manifest: شناسنامه به نشت Credential تبدیل می‌شود.
  • Rerun روی محیط خراب: Failure class و Signal پنهان می‌شود.
  • Shared بدون booking: نسخه/data تیم‌ها به هم آسیب می‌زنند.
  • Ephemeral بدون artifact: Failure با Destroy غیرقابل‌بازتولید می‌شود.
  • Cleanup گسترده: Run/tenant دیگر حذف می‌شود.
  • تست Production مطلقاً ممنوع/آزاد: Risk level و authority حذف می‌شود.
  • یک محیط برای همه Testها: Fidelity و Cost نامتناسب است.

چک‌لیست نهایی مدیریت محیط تست

  • هر محیط Purpose، Class، Owner، Consumer و Status دارد.
  • Environment portfolio با Test risk/level متناسب است.
  • Manifest نسخهٔ App/Schema/Config/Data/Dependency را ثبت می‌کند.
  • Result به Environment ID و Manifest hash وصل است.
  • IaC/config در Git، Review و Policy دارد.
  • State امن، Lock، Backup و recovery دارد.
  • Drift میان declared/deployed/actual/target آشکار می‌شود.
  • Ephemeral دارای Owner/PR/TTL/quota/cost/cleanup است.
  • Shared دارای booking/version matrix/freeze/reset است.
  • Namespace با RBAC/NetworkPolicy/Quota/Secret تکمیل شده است.
  • Dependency real/sandbox/virtual و Contract version Label شده است.
  • Data purpose/source/mask/seed/namespace/retention/cleanup دارد.
  • هیچ Production secret یا مقصد واقعی ناخواسته وجود ندارد.
  • DB migration/schema/backfill و reset قابل‌ردیابی‌اند.
  • Health gate نسخه/data/dependency/capacity/telemetry را می‌سنجد.
  • Trace/log/metric با Run ID هم‌بسته و Redact شده‌اند.
  • Change/Break-glass دارای audit، expiry و Back-port است.
  • Failure taxonomy Product/Test/Data/Environment/Dependency/Unknown دارد.
  • Performance difference و extrapolation مستند است.
  • Cost/idle/orphan/drift/recovery metric به Decision وصل است.
  • Runbook خرابی و Restore/Recreate عملاً تمرین شده است.

سوالات متداول مدیریت محیط تست

مدیریت محیط تست یا TEM چیست؟

فرایند طراحی و ادارهٔ چرخهٔ عمر Environmentهای تست است: Inventory، Purpose، Provision، Version/Config، Data/Identity، Dependency، Booking، Health، Observability، Security، Cost، Drift، Reset و Decommission؛ به‌طوری که Result برای Risk موردنظر قابل‌اعتماد و بازتولید باشد.

آیا محیط تست باید کاملاً مشابه Production باشد؟

کپی کامل معمولاً ممکن یا اقتصادی نیست. Dimensionهای مرتبط با Risk باید نماینده باشند: برای Performance، Scale/topology/data؛ برای Security، surface/control؛ برای PR، version/isolation. تفاوت‌ها، اثر و residual risk را در Manifest/Test report ثبت کنید.

Ephemeral بهتر است یا Shared environment؟

هیچ‌کدام جهانی بهتر نیست. Ephemeral isolation و branch fidelity می‌دهد اما provision/cost/debug lifecycle دارد؛ Shared integration واقعی‌تر می‌دهد اما contention/drift/booking می‌خواهد. پرتفوی ترکیبی با Contract جدا معمولاً عملی‌تر است.

چطور بفهمیم Failure از محیط است یا محصول؟

Health gate و Manifest را پیش از Test قفل، Version/Data/Dependency/Telemetry را بررسی و Failure را با last-known-good یا محیط تازه مقایسه کنید. Evidence باید Classification را پشتیبانی کند. Rerun تنها دلیل Environment issue نیست و Unknown باید Owner/SLA داشته باشد.

آیا استفاده از داده Production در محیط تست مجاز است؟

پیش‌فرض امن Synthetic یا Subset کنترل‌شده است. اگر دادهٔ عملیاتی واقعاً لازم باشد، مجوز، حداقل‌سازی، Masking/Pseudonymization، دسترسی، Retention، re-identification risk و حذف از Snapshot/Backup/Artifact باید بررسی شوند. Copy خام و نامحدود انتخاب قابل‌قبولی نیست.

منابع و یادداشت بازبینی

IaC و کاهش Snowflake با Microsoft DevOps؛ Plan/Drift semantics با مستندات رسمی Terraform؛ Namespace/ResourceQuota با Kubernetes؛ Observability signal با OpenTelemetry؛ و Catalog محیط‌های IaC با Azure Deployment Environments تطبیق داده شده‌اند. آخرین بازبینی محتوایی: ۱۵ مرداد ۱۴۰۵. Tool/Cloud/Provider capability و قیمت تغییر می‌کند؛ نسخه، Contract، data flow و دسترسی روز را پیش از Standardization دوباره بررسی کنید.

جمع‌بندی: محیط تست قابل‌اعتماد «جایی که برنامه بالا می‌آید» نیست؛ یک Artifact نسخه‌دار با Purpose، Manifest، Health، Data boundary، Owner و Lifecycle است. Environment را برای Risk طراحی کنید، Drift را آشکار کنید، Result را به State دقیق وصل کنید و هزینه/امنیت/بازیابی را از روز اول وارد Contract کنید.

محمد عسکری

محمد هستم، توسعه‌دهنده وب با بیش از ده سال تجربه در برنامه‌نویسی سمت سرور و کاربر. به یادگیری و اشتراک‌گذاری دانش علاقه‌مندم و اخیراً تمرکزم را روی حوزه تست نرم‌افزار گذاشته‌ام تا تجربیاتم را در این زمینه نیز به اشتراک بگذارم و به درک بهتر کیفیت نرم‌افزار کمک کنم.

دیدگاهتان را بنویسید