نقش QA در پایداری دیجیتال؛ از Energy تا Carbon

تیم می‌گوید نسخهٔ جدید «۳۰٪ سبزتر» است چون CPU و حجم JavaScript کم شده. اما Test روی لپ‌تاپ دیگری اجرا شده، تعداد تراکنش دو برابر شده، Grid factor معلوم نیست، سخت‌افزار تازه خریده‌اند و Pipeline برای اثبات ادعا هر شب هزار تست اضافی اجرا می‌کند. آیا اثر کل کمتر شده؟ از این شواهد نمی‌دانیم.

نقش QA در پایداری دیجیتال صدور گواهی «سبز» نیست؛ ساختن زنجیره‌ای قابل‌بازبینی از ادعا تا تصمیم است: Outcome/Need → Functional unit → Boundary/Baseline → Workload/Environment → Measure/Estimate → Energy/Carbon/Resource evidence → Trade-off/Total impact → Decision/Monitor/Rebound. پایداری Planet، People و Prosperity دارد، اما هر محور Oracle و صاحب اختیار خودش را می‌خواهد.

پاسخ کوتاه: QA چگونه به پایداری دیجیتال کمک می‌کند؟

• ادعای «کم‌مصرف/کم‌کربن/بادوام/فراگیر» را به Claim محدود و قابل‌رد تبدیل می‌کند.
• Functional unit—مثلاً «یک پرداخت موفق و reconciled»—و حجم کل را جدا تعریف می‌کند.
• مرز Client، Network، CDN، Cloud، Storage، CI و Hardware را شفاف می‌کند.
• Proxy مانند CPU time، bytes و latency را از Energy و Carbon واقعی/برآوردی جدا گزارش می‌دهد.
• Baseline، workload، environment، warm-up، repetition و uncertainty را قابل‌مقایسه می‌سازد.
• Operational energy، carbon intensity برق و embodied allocation را مخلوط نمی‌کند.
• Efficiency به‌ازای واحد را کنار Total impact و Rebound ناشی از رشد تقاضا می‌خواند.
• Trade-off با Reliability، Accessibility، Security، Privacy، هزینه و کار تیم را Hard guardrail می‌کند.
• ادعای Vendor/Cloud/AI را با provenance، methodology، region/time و Gap ممیزی می‌کند.
• تغییر و Production را Monitor می‌کند و برای Regression، rollback/retirement/claim correction دارد.

Intent جست‌وجو و کلیدواژه‌ها

Intent اصلی اطلاعاتی/اجرایی است: «QA چگونه پایداری دیجیتال و Green Software را آزمایش و اندازه‌گیری کند؟» کلیدواژهٔ اصلی نقش QA در پایداری دیجیتال است. عبارت‌های مکمل: تست پایداری نرم‌افزار، Digital Sustainability Testing، Green Software Testing، تست مصرف انرژی نرم‌افزار، Software Carbon Intensity، اندازه‌گیری کربن نرم‌افزار، Energy Efficiency Testing، Functional unit نرم‌افزار، تست Carbon-aware، پایداری وب، تست سبز، Sustainable QA، مصرف انرژی CI/CD، ردپای کربن Cloud، Embodied Carbon سخت‌افزار، Rebound effect دیجیتال و جلوگیری از Greenwashing نرم‌افزار.

این مقاله مالک «اعتبارسنجی ادعای پایداری» است. برای Load/Stress/Scalability به راهنمای تست عملکرد، برای تست دسترس‌پذیری، تست امنیت نرم‌افزار و تست حریم خصوصی از صفحات تخصصی استفاده کنید؛ اینجا شواهد آن‌ها را در Trade-off پایداری وارد می‌کنیم، نه اینکه همه را یک Score کنیم.

پایداری دیجیتال را بی‌مرز تعریف نکنید

محور	سؤال تصمیمی	Evidence نمونه	خطای ادعا
Planet	انرژی، انتشار، آب، مواد و e-waste چگونه تغییر می‌کنند؟	meter/model/inventory/functional unit	bytes کمتر=carbon کمتر
People	چه کسی دسترسی، امنیت، اختیار یا burden دارد؟	a11y/privacy/safety/labour evidence	Feature سبز با Harm انسانی
Prosperity	Value، resilience، هزینه و قابلیت ادامه چگونه‌اند؟	TCO/operability/maintainability/exit	ROI تضمینی
Governance	Claim، Method، owner، correction و decision چیست؟	contract/provenance/audit/expiry	Dashboard بدون Authority

هر ویژگی خوب نرم‌افزار را «پایداری» ننامید؛ Scope واژه بی‌نهایت می‌شود و هیچ Claim قابل‌ردی باقی نمی‌ماند. Web Sustainability Guidelines فعلی W3C Planet/People/Prosperity و Systems thinking را برای Web مطرح می‌کند، اما صفحهٔ فعلی صریحاً Draft Group Note و Work in progress است؛ W3C Recommendation، معیار انطباق، قانون ایران یا اثبات کاهش Carbon نیست.

QA چه مسئولیتی دارد و چه ندارد؟

QA/TEVV انجام می‌دهد	QA به‌تنهایی انجام نمی‌دهد
Claim/metric/boundary review	تعیین هدف اقلیمی سازمان
experiment/reproducibility/uncertainty	انتخاب اخلاقی همهٔ Trade-offها
proxy/measurement validity checks	ساخت factor رسمی برق یا LCA سخت‌افزار
functional/non-functional guardrails	گواهی حسابداری GHG
regression/monitoring/failure evidence	مالکیت معماری/FinOps/Procurement
Gap/dissent/correction reporting	ادعای «Carbon neutral» یا قانونی
decision packet for authorities	تضمین نتیجهٔ اجتماعی/زیست‌محیطی

QA تسهیل‌گر Evidence است؛ Software engineer، SRE/Platform، Data/FinOps، Facilities/Cloud provider، Sustainability/LCA، Product، Accessibility، Security/Privacy، Procurement و Finance هرکدام بخشی از داده/کنترل و Authority را دارند. «QA نگهبان اصلی سلامت مالی/کربن» مسئولیت خیالی می‌سازد.

Sustainability Claim Contract

Decision / user outcome / claim / non-goal
Planet, People, Prosperity or governance lens
Functional unit and total-volume reporting
System boundary / lifecycle stage / excluded sources
Baseline / alternative / counterfactual
Population/workload/mix/season/time/region
Hardware/software/config/data/environment identity
Measurement versus estimation methods
Energy source / carbon-intensity source / embodied method
Allocation / amortization / utilization assumptions
Metric/formula/unit/denominator/threshold/rationale
Warm-up/repetition/sample/uncertainty/missingness
Quality/reliability/security/privacy/accessibility guardrails
Rebound/induced demand/cost-shifting hypotheses
Owner / independent review / evidence expiry
Pass / Fail / Inconclusive / Unknown
Adopt / Adapt / Limit / Defer / Stop / rollback

نمونه Claim خوب: «برای workload نسخه‌دار Checkout و ۱۰هزار پرداخت موفق در Region/Window مشخص، Operational energy اندازه‌گیری‌شدهٔ Client+API boundary به‌ازای پرداخت حداقل ۱۵٪ کمتر است، بدون Regression در p95، success، accessibility یا duplicate payment؛ Total kWh نیز جدا گزارش می‌شود.» هنوز Carbon را بدون factor و embodied scope ادعا نمی‌کند.

Functional unit؛ مخرجی که معنی کسب‌وکاری دارد

Unit ضعیف	چرا ضعیف است؟	Functional unit بهتر
per request	retry/chattiness/value متفاوت	per successful reconciled payment
per page view	bot/cache/task mix	per completed eligible user task
per model call	token/model/quality متفاوت	per accepted task outcome at guardrail
per test	scope/fidelity/duration متفاوت	per decision-evidence packet or release
per server-hour	utilization/workload پنهان	per defined service unit + total
per user	active/inactive/usage متفاوت	per active user-task/window

Functional unit باید Outcome قابل‌مقایسه باشد. بهینه‌سازی با کاهش Quality یا حذف کاربران، unit را ظاهراً بهتر می‌کند. SCI نیز Carbon rate را نسبت به یک Functional unit گزارش می‌کند؛ Total emissions و سازمانی را جایگزین نمی‌کند. هر دو intensity و total را نگه دارید.

System boundary؛ Carbon حذف‌شده ممکن است فقط جابه‌جا شده باشد

User device / screen / radio / battery
Access network / ISP / mobile channel
DNS / CDN / edge / WAF
Load balancer / compute / serverless / containers
Database / cache / queue / object storage / backup
Observability / logs / analytics / security scanning
Third-party API / PSP / AI provider
Build / test / artifact / CI runners
Developer and test devices / device lab
Hardware manufacture / allocation / retirement / e-waste
Support / operations / incident / data retention
User behaviour / retries / induced demand / alternate channels

Client bundle کوچک‌تر ممکن است Server render و compute بیشتری مصرف کند؛ cache بیشتر storage/invalidations را بالا ببرد؛ compression CPU را با network جابه‌جا کند؛ Cloud migration utilization را بهتر ولی data transfer یا embodied allocation را بدتر کند. Boundary و excluded items را کنار نتیجه چاپ کنید.

Proxy، Energy و Carbon را از هم جدا کنید

سطح	Metric نمونه	چه می‌گوید؟	چه نمی‌گوید؟
Work	requests، bytes، tokens، instructions	کار/فعالیت تعریف‌شده	Energy مستقیم
Resource	CPU time، memory، storage، network	مصرف/اشغال Resource	کل Power/Carbon
Power	Watt در زمان	نرخ Energy	Carbon یا embodied
Energy	Joule/kWh	مصرف در Boundary/Window	شدت Carbon برق
Operational carbon	energy × carbon intensity	CO₂e مدل‌شدهٔ Operation	ساخت Hardware/کل سازمان
Embodied allocation	allocated manufacturing CO₂e	سهم روش‌شناسی‌شده	حقیقت بدون assumptions
Total impact	rate × volume + included totals	اثر در Boundary/Period	Harm خارج از Scope

Latency کمتر ممکن است از cache/parallelism با Energy بیشتر بیاید؛ CPU utilization بالاتر ممکن است کار مفید بیشتر یا Consolidation بهتر باشد. Memory آزادشده تا وقتی Hardware/Capacity/energy state عوض نشود، الزاماً Energy صرفه‌جویی نمی‌کند. Proxy را مفید ولی با نام درست گزارش کنید.

فرمول SCI و محدودیت کاربرد آن

Software Carbon Intensity specification که Green Software Foundation آن را به ISO/IEC ۲۱۰۳۱:۲۰۲۴ پیوند می‌دهد، شدت Carbon نرم‌افزار را با Operational emissions و embodied allocation نسبت به Functional unit صورت‌بندی می‌کند؛ در نمایش ساده: SCI = ((E × I) + M) / R. E انرژی، I شدت Carbon برق، M سهم embodied و R Functional unit است. برای اجرای رسمی باید متن نسخه/دامنه/روش استاندارد را دنبال کنید؛ این خلاصه Certification یا جایگزین GHG inventory نیست.

جزء	پرسش QA	خطر
E	Measured/estimated؟ چه Boundary و meter؟	double count یا missing source
I	location/time/marginal/average/source/version؟	factor نامربوط یا ادعای renewables
M	Hardware/LCA/allocation/lifetime/utilization؟	allocation دلخواه
R	Functional unit outcome/quality/volume؟	مخرج قابل‌بازی
Comparison	baseline/boundary/method ثابت‌اند؟	سیب و پرتقال
Total	rate×volume و excluded impacts چیست؟	Rebound پنهان

Offset را بهبود Engineering ننامید و avoided emissions را با footprint خود محصول خالص نکنید مگر روش حسابداری معتبر و گزارش جداگانه داشته باشید. «Hosted on renewable» نیز بدون instrument، location/time، residual mix و methodology ادعای کامل نیست.

Energy Measurement Contract

Claim / functional unit / total volume
System boundary and meter/model coverage
Hardware/firmware/OS/kernel/power mode
Application/build/runtime/dependency/config versions
Data/workload/arrival/mix/concurrency/retry/cache state
Environment/region/instance/container/tenant allocation
Warm-up/steady-state/cool-down and idle baseline
Run order/randomization/repetition/sample size
Energy source/counter/device/model/calibration
Background jobs/thermal/fan/battery/network controls
Raw start/end counters and wraparound handling
Derived joule/kWh per unit + total
Noise/variance/interval/outliers/missing runs
Carbon factor source/time/location/version if applied
Embodied allocation method if applied
Quality/latency/error/security/accessibility guardrails
Reproduction packet / owner / expiry

یک اجرای قبل/بعد کافی نیست. تغییر ترتیب می‌تواند با warm cache، thermal throttling، background job یا autoscaling مخلوط شود. Interleaving/random order، چند تکرار و raw result لازم است. Statistical significance هم practical reduction یا total impact را ثابت نمی‌کند.

RAPL و ابزارهای اندازه‌گیری؛ Meter coverage را بنویسید

مستند رسمی Linux powercap/RAPL نشان می‌دهد energy counterها برای Zoneهای مشخص مانند CPU package/core/uncore در دسترس‌اند و حتی instantaneous power الزاماً ارائه نمی‌شود. بنابراین RAPL روی سخت‌افزار پشتیبانی‌شده، «برق کل لپ‌تاپ/شبکه/نمایشگر/Cloud» نیست. Counter wrap، sampling، zone، permissions و concurrent workload را مدیریت کنید.

روش	مزیت	Gap
External wall meter	کل دستگاه/PSU در Scope	دقت/رزولوشن/background
RAPL/powercap	counter نزدیک CPU package	coverage/hardware support
OS/mobile profiler	component/process insight	model/attribution/device
Cloud provider telemetry	service/region integration	allocation/opacity/version
Resource proxy model	CI-friendly/trend	Energy/Carbon تخمینی
Lab power analyzer	fidelity/precision بالقوه	هزینه/setup/representativeness
Vendor carbon dashboard	inventory convenience	method/boundary/comparability

Baseline و آزمایش قابل‌مقایسه بسازید

• Same outcome: نسخه‌ها باید نتیجهٔ کسب‌وکاری و quality guardrail برابر داشته باشند.
• Same workload: arrival، mix، payload، cache/retry و data volume ثابت یا مدل‌شده باشند.
• Same environment: hardware/instance/region/runtime/power mode مشخص باشد.
• Same boundary/method: meter zones، factor، embodied allocation و exclusions تغییر نکنند.
• Idle subtraction: فقط با تعریف و کنترل؛ idle shared را خودکار صفر نکنید.
• Warm/cold states: هر دو اگر در Production رخ می‌دهند گزارش شوند.
• Order/repetition: drift/thermal/background را با interleaving و raw data آشکار کنید.
• Uncertainty: point estimate را قطعیت ننامید؛ incomplete measurement را Inconclusive نگه دارید.

آزمایش ساختگی: Intensity بهتر، Total بدتر

برای نمایش تفاوت Rate و Total، یک اسکریپت Node.js بدون وابستگی روی چهار سناریوی نویسنده‌ساخته اجرا شد. فرمول سادهٔ مثال چنین است: operational = transactions × kWh/unit × gCO₂e/kWh؛ سپس embodied allocation اضافه و بر Transaction تقسیم می‌شود. همهٔ factorها فرضی‌اند.

{"name":"BASELINE","transactions":10000,"operationalKwh":8,"operationalGramsCo2e":3600,"embodiedGramsCo2eAllocated":900,"totalGramsCo2e":4500,"gramsCo2ePerTransaction":0.45}
{"name":"EFFICIENT_FIXED_DEMAND","transactions":10000,"operationalKwh":5,"operationalGramsCo2e":2250,"embodiedGramsCo2eAllocated":900,"totalGramsCo2e":3150,"gramsCo2ePerTransaction":0.315}
{"name":"EFFICIENT_HIGHER_DEMAND","transactions":20000,"operationalKwh":10,"operationalGramsCo2e":4500,"embodiedGramsCo2eAllocated":1400,"totalGramsCo2e":5900,"gramsCo2ePerTransaction":0.295}
{"name":"EFFICIENT_CLEANER_WINDOW","transactions":10000,"operationalKwh":5,"operationalGramsCo2e":900,"embodiedGramsCo2eAllocated":900,"totalGramsCo2e":1800,"gramsCo2ePerTransaction":0.18}

تقاضای ثابت: Efficiency و Total هم‌جهت‌اند

در EFFICIENT_FIXED_DEMAND، kWh به‌ازای Transaction از ۰٫۰۰۰۸ به ۰٫۰۰۰۵ می‌رسد؛ با factor و embodied ثابت، شدت از ۰٫۴۵ به ۰٫۳۱۵ gCO₂e و Total از ۴۵۰۰ به ۳۱۵۰ گرم افت می‌کند. این نتیجه صرفاً arithmetic فرض‌های مثال است.

تقاضای بیشتر: Rate بهتر، Total بالاتر

در EFFICIENT_HIGHER_DEMAND، شدت حتی ۰٫۲۹۵ gCO₂e/Transaction است، اما با ۲۰هزار Transaction و embodied فرضی بیشتر، Total به ۵۹۰۰ گرم می‌رسد—بالاتر از Baseline. این مثال «Efficiency باعث تقاضا شد» را ثابت نمی‌کند؛ فقط نشان می‌دهد Rate کمتر برای نتیجهٔ Total کافی نیست و Rebound/induced demand باید جدا بررسی شود.

زمان پاک‌تر: Carbon عوض می‌شود، Energy نه

EFFICIENT_CLEANER_WINDOW همان ۵ kWh سناریوی Fixed demand را دارد، اما factor فرضی از ۴۵۰ به ۱۸۰ gCO₂e/kWh رسیده و Operational carbon کم‌تر است. زمان/مکان می‌تواند Carbon را بدون کاهش Energy عوض کند؛ در مقابل shifting ممکن است latency، availability، data transfer یا user burden بسازد.

محدودیت سخت آزمایش

هیچ meter، workload واقعی، Grid ایران، Cloud، hardware LCA، uncertainty، PUE، network، client، storage، cooling، Scope ۱/۲/۳، location/market/marginal factor، causality، cost یا quality در این آزمایش وجود ندارد. Embodied allocation و factorها دلخواه‌اند. خروجی Benchmark، SCI رسمی، GHG inventory، ادعای محصول سبز یا راهنمای خرید/مهاجرت نیست؛ فقط mechanics مخرج و Total را نشان می‌دهد.

Carbon intensity برق؛ Factor را با زمان و مکان نسخه‌دار کنید

Factor	سؤال	کاربرد محتمل	خطر
Average/location-based	میانگین Grid در منطقه/بازه چیست؟	Inventory/Trend طبق Method	زمان/اثر حاشیه‌ای پنهان
Marginal	بار اضافه با کدام تولید پاسخ می‌گیرد؟	تصمیم shifting/consequence	model availability/uncertainty
Market-based	قرارداد/Instrument چه claimی می‌دهد؟	Corporate reporting طبق قواعد	برابر دانستن با برق فیزیکی لحظه‌ای
Provider-specific	Scope/method/region/service چیست؟	Cloud estimate	opacity/non-comparability
Forecast	برای زمان آینده چه تخمینی است؟	carbon-aware scheduling	forecast error/version
Fallback/default	وقتی Factor نداریم چه می‌کنیم؟	bounded estimate	عدد جهانی بی‌منبع

نسخهٔ رسمی PDF از GHG Protocol Scope ۲ Guidance برای برق خریداری‌شده، روش‌های location-based و در شرایط مربوط market-based را با قواعد گزارش‌دهی جدا می‌کند. این راهنما در فرایند بازنگری است و برای Corporate inventory نوشته شده؛ انتخاب Factor پروژهٔ نرم‌افزار، ادعای ایران یا SCI را خودکار تعیین نمی‌کند. Source، version، timestamp، geography، method و fallback را در Evidence Pack ثبت کنید.

Carbon-aware scheduling را با Guardrail تست کنید

Carbon-aware Job Contract
Job / functional outcome / deadline / priority
Deferrable, interruptible and movable boundaries
Region/time options and prohibited locations
Forecast/factor source/version/freshness/confidence
Data residency / privacy / security / sovereignty
Network transfer / replication / cache impacts
Queue / retry / preemption / duplicate-work behavior
Latency / SLA / user burden / accessibility guardrails
Capacity / reliability / incident / disaster-recovery impact
Energy and carbon before/after + total volume
Cost/currency/quota/provider constraints
Fallback when signal/provider/network is unavailable
Owner / stop / rollback / expiry

Backup، Batch analytics یا بعضی CI jobها شاید قابل‌انتقال زمانی باشند؛ پرداخت، Alarm یا مسیر دسترس‌پذیری اضطراری معمولاً نیستند. انتقال Region می‌تواند Data residency، latency، egress و replication را بدتر کند. Carbon signal فاسد/کهنه نباید availability را از بین ببرد؛ safe fallback و deadline لازم است.

Embodied Carbon و سخت‌افزار؛ عمر و Utilization را پنهان نکنید

تصمیم	Benefit احتمالی	اثر جابه‌جا‌شده	آزمون
خرید سرور کارآمدتر	Energy/unit کمتر	ساخت/حمل/e-waste	break-even scenarios + LCA source
تعویض موبایل قدیمی	speed/battery	exclusion + embodied	minimum-device support
Scale out	latency/reliability	idle capacity/hardware	utilization/reserve/total
Consolidation	utilization بهتر	blast radius/contention	resilience/noisy-neighbour
Short retention	storage کمتر	audit/recovery/legal risk	restore/incident/applicability
Compression	network/storage کمتر	CPU/client battery	end-to-end energy/outcome
Longer support	کمترشدن forced upgrade	maintenance/security cost	patch/compatibility/exit

Embodied allocation به lifetime، utilization، share و منبع LCA وابسته است. افزایش عمر دستگاه می‌تواند خرید را عقب بیندازد، اما اگر patch امنیتی یا تجربهٔ دسترس‌پذیر ممکن نباشد Trade-off دارد. QA سناریوهای compatibility/security/performance را می‌سازد؛ Procurement/Sustainability/Finance روش و تصمیم را مالک‌اند.

Cloud و Serverless: صورت‌حساب، Energy meter نیست

Signal Cloud	کاربرد	محدودیت
vCPU/instance seconds	Activity/utilization proxy	shared hardware/power state
GB-hours/storage	capacity activity	replication/media/embodied
Requests/invocations	work count	duration/memory/retry/value
Data transfer	network activity/cost	end-to-end energy model
Billing/cost	economic signal	price ≠ energy/carbon
Provider carbon report	allocated estimate	scope/method/granularity/version
PUE	facility overhead ratio	software attribution/embodied/grid
Renewable claim	procurement/accounting evidence	physical hourly supply/avoided impact

Autoscaling down، rightsizing و حذف idle resources می‌توانند هزینه/فعالیت را کم کنند، اما Reliability reserve و traffic burst را آزمایش کنید. Serverless صفر Instance مدیریت‌شده برای تیم است، نه صفر Server. هزینه کمتر در Region دیگر ممکن است Carbon، latency، data sovereignty یا خروج از ایران را بدتر کند.

Web و Frontend: Byte budget را به Task متصل کنید

Web Sustainability Test Packet
Page/route/user task and eligible population
Cold/warm/repeat visit and cache policy
HTML/CSS/JS/font/image/video bytes by source
Request count / third parties / tracking / failures
Main-thread CPU / long tasks / memory / battery proxy
Device/network profiles common to users
Server/CDN/cache/revalidation boundary
Render/interactivity/task-success/accessibility guardrails
Localization/RTL/font/subset and data-saver behavior
Ad/consent/privacy/security behavior
Energy/carbon method if claimed—not byte proxy alone
Total traffic and revisit/induced-use estimate
Baseline/version/raw trace/uncertainty/owner

تصویر و Video مناسب، lazy loading، cache، حذف Third-party و فونت بهینه می‌توانند Byte/CPU را کاهش دهند؛ ولی Placeholder نامفهوم، متن ناخوانا، حذف Caption، کیفیت ناکافی یا consent bypass قابل‌قبول نیست. Lighthouse performance score یا Website Carbon estimate را Carbon حقیقت/Compliance ننامید؛ Method، assumed traffic/grid و exclusions را آشکار کنید.

Mobile و Edge: Battery، Radio و Offline

رفتار	اثر محتمل	سناریوی تست
Polling	radio wake/network/server work	interval/background/poor network
Push/batch	fewer wakeups	delay/loss/privacy/provider
Location/sensor	battery/privacy	permission/rate/background/off
Retry sync	duplicate work/data	offline/flap/backoff/idempotency
On-device inference	Cloud transfer کمتر	battery/device support/model update
Cloud inference	device workload کمتر	network/cloud/data/latency
Large update	network/storage/forced upgrade	delta/update failure/rollback
Long support	device lifetime/access	security/performance/compatibility

Battery percentage یک meter دقیق Energy نیست و شرایط باتری/دما/OS اثر دارد. Device profiler، external power measurement و repeated task می‌توانند Evidence متفاوت بدهند. Offline-first گاهی Network را کم و Resilience را زیاد می‌کند، اما sync conflict، storage، data deletion و stale information را اضافه می‌کند.

Data، Storage و Retention؛ «ذخیره ارزان است» کافی نیست

• Data inventory: dataset/log/backup/index/replica/cache و owner/purpose.
• Lifecycle: create→hot/warm/cold→archive→delete با restore evidence.
• Retention: نیاز عملی/حقوقی/امنیتی در برابر storage/processing/privacy.
• Duplication: semantic copy، retry، orphan، snapshot و cross-region replica.
• Query: scan volume، index، materialization و result reuse با freshness guardrail.
• Format/compression: storage/network در برابر compute/compatibility.
• Observability: cardinality/sample/redaction بدون از دست‌دادن incident evidence.
• Deletion: primary، replica، cache، search، backup policy و Vendor.
• Recompute: ذخیرهٔ artifact در برابر هزینهٔ تولید دوباره.
• Growth: total GB/object/query و rate per functional outcome هر دو.

Retention کوتاه همیشه پایدارتر نیست؛ ممکن است Audit/Recovery را از بین ببرد و Recompute پرهزینه بسازد. Retention طولانی نیز Carbon/هزینه/Privacy/attack surface دارد. Contract را با Data/Legal/Security/SRE بسازید و restore/delete را عملاً تست کنید.

AI workload؛ Token کمتر فقط یک Proxy است

تصمیم	Proxy/Benefit	Guardrail/اثر جابه‌جا‌شده
مدل کوچک‌تر	compute/token کمتر	quality/error/retry/harm
Prompt کوتاه‌تر	input tokens کمتر	ambiguity/output/retries
Cache پاسخ	inference کمتر	staleness/privacy/tenant isolation
Batching	utilization بهتر	latency/fair scheduling
Quantization	memory/compute کمتر	slice quality/hardware support
RAG filtering	context کمتر	missing evidence/recall
On-device	network/cloud کمتر	battery/embodied/device exclusion
Human fallback	unsafe output کمتر	labour/workload/delay

Provider معمولاً Joule/embodied/region factor کافی نمی‌دهد؛ token، latency و cost فقط activity proxy هستند. Functional unit را «یک پاسخ» نگذارید اگر پاسخ نادرست retry یا Harm می‌سازد؛ outcome پذیرفته‌شده با quality/safety guardrail بهتر است. برای ارزیابی Harm و Governance به تست اخلاقی هوش مصنوعی وصل شوید.

CI/CD و خودِ تست‌ها هم Workload دارند

Test Pipeline Sustainability Contract
Decision evidence required per change/risk
Trigger and affected-change selection logic
Test/lane/runner/container/artifact identity
Functional unit: release/change/evidence packet—not raw test count
Queue/setup/execution/retry/idle/teardown time
CPU/memory/storage/network/activity and meter/model coverage
Cache/artifact/data retention/restore policy
Flaky/retry/quarantine/diagnosis/escaped-risk guardrails
Parallelism versus total work and peak capacity
Local/shared/cloud runner region/provider/factor
Security/secret/isolation/supply-chain requirements
Schedule/shifting/fallback/deadline
Energy/carbon intensity + total volume when defensible
Quality/risk/feedback-time/cost/team-health countermetrics
Owner / expiry / retire-or-redesign rule

تعداد Test کمتر هدف نیست؛ Evidence کافی با کار کمتر هدف است. Eliminate duplicate/obsolete tests، انتخاب بر اساس change/risk، cache امن، teardown، right-size runner و کنترل Flake می‌توانند Work را کم کنند. Parallelism duration را کاهش می‌دهد اما Total compute را الزاماً کم نمی‌کند. قواعد Pipeline در راهنمای تست مداوم مالک جزئیات‌اند.

Static analysis و Maintainability را Green label نکنید

Complexity، duplication، dependency age، coverage و warning count ممکن است فرضیهٔ Maintainability یا Efficiency بسازند؛ Carbon مستقیم نیستند. Refactor «تمیز» می‌تواند runtime بدتر، build سنگین‌تر یا dependency بیشتری بسازد. هشدارهای تحلیل استاتیک کد را با Rule/version/severity/suppression/false-positive و runtime evidence مدیریت کنید.

Economic/operability claim	Evidence سالم‌تر	سوءبرداشت
Maintaining cheaper	change sample + touch/lead/rework/run cost	lines/complexity alone
Technical debt reduced	named obligation/interest/risk retired	warning count پایین
Longer life	support/upgrade/security/exit evidence	age بالا
Resilient	failure/recovery/capacity/restore tests	uptime گذشته
Lower TCO	build/run/support/vendor/exit range	Cloud bill ماه اول
Faster change	comparable flow distribution	commit/deploy count

ادعای «صدها برابر ارزان‌تر بودن باگ زودهنگام» را حذف کنید. Cost به نوع Defect، escape، detectability، architecture، rollback، downtime، rework و opportunity بستگی دارد. بودجه و Optionها را در راهنمای بودجه‌بندی QA با range و uncertainty بسنجید.

People guardrails: پایداری نباید کاربران را حذف کند

بهینه‌سازی	Harm محتمل	Guardrail
حذف تصویر/ویدئو	درک/زبان/آموزش کمتر	task comprehension + alternatives
فونت/asset محدود	RTL/خوانایی/زبان	Persian/Arabic glyph/a11y
Timeout/کم‌کردن Session	کاربر کند/معلول حذف	adjustable timing/save state
Device minimum بالا	forced upgrade/digital divide	compatibility/degradation
Low-data mode	Feature/اطلاعات ناقص	equivalent task outcome
کم‌کردن Logging	امنیت/اعتراض/Incident کور	risk-based observability
Region shifting	privacy/latency/access	residency/security/SLA
Automation	labour burden/deskilling	work design/oversight/non-ranking

Accessibility، Security و Privacy را «ستون اجتماعی» نامیدن کافی نیست؛ نیازمند استاندارد، Risk و آزمون تخصصی‌اند. ابزار خودکار WCAG conformance را تضمین نمی‌کند؛ Performance سبز نیز Permission یا Data minimization را ثابت نمی‌کند. Hard guardrailها را به‌خاطر چند گرم تخمینی Fail نکنید.

Trade-off Record؛ جابه‌جایی اثر را قابل‌تصمیم کنید

Sustainability Trade-off Record
Decision / options / no-change alternative
Functional outcome and affected population
Planet/People/Prosperity impacts per option
Mechanism, boundary, measurement and evidence quality
Intensity and total impacts / rebound hypothesis
Quality/security/privacy/accessibility/reliability guardrails
Cost/time/currency/vendor/operability/exit ranges
Who benefits / who bears burden / consent or authority
Unknowns / missing sources / disagreements
Reversibility / pilot / stop / rollback / remedy
Decision owner / reviewers / rationale / expiry
Post-decision monitor and claim correction

Trade-off را با Weighted score دلخواه دفن نکنید. بعضی کنترل‌ها Hard gate هستند؛ بعضی هدف بهینه‌سازی؛ بعضی Unknown. QA گزینه و Evidence را روشن می‌کند، اما Product/Sustainability/Security/Accessibility/Finance/Legal مطابق اختیار خود تصمیم می‌گیرند.

Greenwashing و Claim review

ادعا	سؤال ممیزی	نسخهٔ محدودتر
۳۰٪ سبزتر	چه Metric/boundary/unit/baseline؟	۳۰٪ CPU-time کمتر در workload X
Carbon neutral	inventory/reduction/offset/method/period؟	claim رسمی با assurance جدا
Zero-carbon Cloud	location/time/market instrument/Scope؟	provider-reported factor/method
Eco mode	چه چیزی کم و چه چیزی degrade می‌شود؟	bounded resource mode + guardrails
Sustainable by design	کدام practice و Evidence؟	specific decisions/results
Paperless=green	digital/hardware/use/lifecycle comparison؟	no broad environmental claim
AI optimized	AI workload/retry/quality included؟	measured proxy change
Renewable hosted	instrument/location/period/quality؟	disclosed procurement claim

هر ادعا باید scope، methodology، date، baseline، unit، exclusions، source، uncertainty و expiry داشته باشد. Marketing نباید Proxy را Carbon، intensity را Total یا Provider allocation را causal reduction ترجمه کند. اگر Claim بعداً نادرست شد، Correction/withdrawal و downstream update لازم است.

سناریوی ایرانی: Checkout بازارگاه در نوروز

یک بازارگاه خیالی می‌خواهد Checkout نوروز را «پایدارتر» کند: Polling وضعیت پرداخت را به webhook+reconciliation تغییر دهد، payload را کم کند و Test suite را Risk-selective اجرا کند. هدف باید پرداخت درست/قابل‌بازیابی باشد، نه Request کمتر به هر قیمت. همهٔ اعداد/هویت‌ها فرضی‌اند و هیچ factor برق ایران یا PSP واقعی استفاده نمی‌شود.

Iranian Checkout Sustainability Contract — fictional
Functional unit: one successful, reconciled payment outcome
Total window: defined Nowruz campaign traffic and retries
Identity: Order / Payment Attempt / PSP / idempotency key
Baseline: versioned polling interval, payload, retries and CI lanes
Boundary: mobile client + API + queue + database + observability;
  PSP, access network, hardware embodied excluded unless added
Planet proxies: requests, bytes, CPU-time, DB queries, runner minutes
Energy: only if meter/model coverage is documented
Carbon: only with dated/location-bound factor and stated method
Financial oracle: Order + Payment + Ledger + Outbox + Reconciliation
Critical faults: timeout before/after commit, user retry,
  duplicate/late/out-of-order callback, unknown status
Locale: canonical IRR + explicit displayed toman; Persian/Arabic/Latin digits
Time: UTC instant + Asia/Tehran + Jalali presentation version
People guardrails: low-end device, slow network, RTL, a11y, privacy, security
Data: synthetic IDs; no PAN/CVV2/OTP/token/real phone
Decision: intensity + total + quality + cost + rebound evidence

Polling را حذف نکنید؛ Protocol را ایمن بازطراحی کنید

کاهش Request با webhook می‌تواند Server/client work را کم کند، اما Callback گم‌شده، دیر، تکراری یا out-of-order و قطع اینترنت رخ می‌دهد. Status endpoint کم‌دفعات به‌عنوان fallback، exponential backoff، idempotency و Reconciliation لازم‌اند. Success فقط UI «پرداخت شد» نیست؛ Ledger/Order/Outbox باید همگرا باشند.

Low-data و Low-end را همراه Accessibility بسنجید

Bundle و تصویر کمتر روی شبکه/دستگاه ضعیف مفید است، ولی Captcha، OTP، خطا و وضعیت پرداخت باید با Screen reader، Keyboard، Contrast، zoom و فارسی RTL قابل‌استفاده بمانند. timeout طولانی‌تر برای دسترس‌پذیری ممکن است Session resource را تغییر دهد؛ Security و access را Hard guardrail نگه دارید و Trade-off را ثبت کنید.

ریال، تومان و Reconciliation را قربانی Byte نکنید

مبلغ canonical با IRR ذخیره و تومان واحد نمایش مشتق‌شده و صریح است. فشرده‌کردن schema نباید unit، status، payment attempt یا traceability را مبهم کند. حذف Logهای حساس/تکراری خوب است؛ حذف Evidence لازم برای duplicate payment، incident یا اعتراض نیست. Retention را Risk-based تعیین کنید.

محدودیت زیرساخت و Factor در ایران

Factor لحظه‌ای/منطقه‌ای معتبر، Cloud telemetry یا hardware LCA ممکن است در دسترس نباشد. Proxy را Carbon قطعی ننامید؛ source/gap/range را گزارش و Measurement maturity را مرحله‌ای کنید. تحریم، VPN، پرداخت ارزی، Cloud region، latency، data residency، Provider exit، قطعی برق/شبکه و ظرفیت نوروز می‌توانند گزینهٔ ظاهراً کم‌کربن را غیرقابل‌اعتماد یا غیرقابل‌دسترسی کنند.

Production Monitoring و Rebound

Signal	سؤال	Countermetric/Gap
Energy/intensity per unit	Efficiency drift کرده؟	total volume/outcome mix
Total kWh/CO₂e	اثر دوره بیشتر شده؟	growth/coverage/factor
Requests/bytes/CPU/storage	Work کجا جابه‌جا شده؟	proxy/meter boundary
Retry/failure/abandon	Efficiency کاذب از Quality loss؟	reconciliation/missing users
Device/network slice	Burden به کاربر منتقل شده؟	telemetry/privacy/sample bias
Capacity/utilization/idle	resource provisioning مناسب است؟	reserve/reliability
CI work/retry	Evidence cost رشد کرده؟	escaped risk/feedback time
Cost	Economic shift چیست؟	price/currency ≠ carbon
Adoption/demand	Rebound/induced use رخ داده؟	causality/seasonality

همبستگی Feature و Traffic، Rebound causal را ثابت نمی‌کند؛ کمپین، فصل، قیمت و تغییر Population دخیل‌اند. Scenario range، pre/post با Control مناسب و mechanism evidence کمک می‌کنند. حتی بدون اثبات علیت، Total بالاتر باید در تصمیم دیده شود. Rebound را بهانهٔ عدم بهینه‌سازی نکنید؛ Demand و Value را هم مدیریت کنید.

Sustainability Evidence Pack

Sustainability Evidence Pack
Decision / claim / audience / non-goal
Functional unit + total volume/window
System/lifecycle boundary + explicit exclusions
Baseline/options/config/workload/data identity
Raw proxy/energy/activity measurements
Meter/model/factor/LCA sources and versions
Operational/embodied formulas and allocations
Rate and total results with uncertainty/missingness
Warm/cold/order/repetition/environment controls
Quality/reliability/security/privacy/accessibility evidence
People/prosperity impacts and burden distribution
Cost/currency/provider/region/exit assumptions
Rebound/induced demand hypotheses and observations
Contradictory evidence / unresolved gaps / dissent
Claim wording allowed and prohibited
Decision/owner/expiry/monitor/rollback/correction

Dashboard جای Pack را نمی‌گیرد. Raw data، Method و exclusions باید قابل‌ردگیری باشند. Result مربوط به Intel laptop را به ARM mobile یا shared Cloud تعمیم ندهید. اگر ابزار/Provider Method تغییر کرد، trend break را علامت بزنید و تاریخچه را بازنویسی نکنید.

Gate چندمحوره برای Release و Claim

Gate	Evidence	Hard stop نمونه	Authority
Claim validity	unit/boundary/method/source	Proxy به‌عنوان Carbon	QA/Sustainability
Functional quality	outcome/oracle/regression	پرداخت/داده غلط	Product/Service
Reliability	load/failure/recovery/capacity	availability unsafe	SRE/Operations
Security/privacy	threat/data controls	critical exposure	Security/Privacy
Accessibility/people	representative user evidence	essential path exclusion	Product/A11y
Planet	rate+total+embodied/rebound scope	claim unsupported؛ ممکن است Release نه	Sustainability/Product
Prosperity	TCO/operability/vendor/exit	unowned/unsupportable	Finance/Operations
Governance	owner/monitor/correction/expiry	claim بی‌صاحب	Decision owner

Fail شدن Environmental Claim ممکن است انتشار Feature را متوقف نکند، اما Marketing claim باید حذف/محدود شود؛ برعکس Security یا Financial-integrity hard stop می‌تواند Release را متوقف کند. Claim approval و Product release دو تصمیم مرتبط ولی مستقل‌اند. Authority را پیشاپیش تعیین کنید.

Metricهای سالم و Countermetricها

Signal	تعریف عملی	Countermetric/Non-use
Claim reproducibility	rerun در Contract تعریف‌شده	تعداد benchmark
Boundary coverage	included activity share + exclusions	اجبار درصد کاذب
Energy per functional unit	measured/modelled و versioned	quality + total
Total energy/carbon	period/volume/method	business growth mix
Measurement uncertainty	range/source sensitivity	پاداش precision جعلی
Resource displacement	client/network/server/CI shifts	یک لایه محلی
Guardrail health	functional/a11y/security/reliability	aggregate score
Rebound review	volume/behavior/capacity hypothesis	ادعای causality سریع
Claim correction time	unsupported claim withdrawn/updated	سرکوب findings
Retirement/exit	resource/data/vendor removal evidence	asset count

CPU، memory، requests، bytes، test count، server count، Cloud cost، PUE، renewable percentage، Lighthouse score یا carbon-estimator score را KPI فردی یا Truth واحد نکنید. پاداش «کاهش Carbon» بدون Boundary می‌تواند Logging، Accessibility، Security یا workload را دست‌کاری کند.

برنامهٔ ۳۰روزهٔ Pilot

بازه	کار	خروجی
روز ۱–۵	Outcome/claim/owner/boundary inventory	Sustainability Claim Contract
روز ۶–۱۰	functional unit/baseline/workload/proxies	comparable experiment plan
روز ۱۱–۱۵	meter/model/factor/uncertainty PoC	Measurement Contract + gaps
روز ۱۶–۲۰	rate+total+guardrail experiment	raw Evidence Pack
روز ۲۱–۲۵	rebound/trade-off/production tabletop	options/stop/rollback/correction
روز ۲۶–۳۰	cross-functional evidence review	Adopt/Adapt/Limit/Defer/Stop + expiry

یک مسیر محدود و پرتکرار را انتخاب کنید؛ کل شرکت را در ماه اول Carbon-account نکنید. اگر Energy meter یا factor معتبر ندارید، با Proxy شفاف و بدون Claim Carbon شروع کنید. Maturity یعنی بهترشدن روش/Boundary و تصمیم، نه ساختن عدد پرجزئیات با دادهٔ ضعیف.

۲۰ ضدالگوی پایداری دیجیتال در QA

• QA به‌عنوان ضامن آیندهٔ پایدار.
• هر Quality attribute به‌عنوان Sustainability.
• CPU/Memory/bytes کمتر مساوی Carbon کمتر.
• Latency کمتر مساوی Energy کمتر.
• Cost Cloud کمتر مساوی اثر محیطی کمتر.
• Functional unit بدون outcome/quality.
• Intensity بهتر بدون Total volume.
• یک run قبل/بعد روی محیط متفاوت.
• RAPL به‌عنوان برق کل سامانه.
• Factor جهانی/کهنه برای ایران یا Region دیگر.
• Operational carbon بدون embodied/exclusion.
• Renewable/offset به‌عنوان Engineering reduction.
• PUE/Provider dashboard به‌عنوان software truth.
• Serverless به‌عنوان server-free.
• Carbon shifting بدون residency/reliability.
• Test کمتر بدون Evidence/risk guardrail.
• حذف Logging/Retention بدون incident/appeal.
• حذف Feature/asset به قیمت Accessibility.
• Score ابزار به‌عنوان Green certification.
• Claim بدون owner/expiry/correction.

چک‌لیست ۲۰‌نقطه‌ای تصمیم

1. Outcome، Claim، audience و non-goal مشخص‌اند.
2. Planet/People/Prosperity lens صریح است.
3. Functional unit و Total window تعریف شده‌اند.
4. Boundary/lifecycle/exclusions قابل‌مشاهده‌اند.
5. Baseline/options/workload مقایسه‌پذیرند.
6. Hardware/software/data/config identity ثبت است.
7. Proxy، Energy و Carbon جدا گزارش می‌شوند.
8. Meter/model coverage و calibration/limits روشن‌اند.
9. Factor location/time/method/source/version دارد.
10. Embodied allocation/lifetime/utilization صریح است.
11. Warm-up/order/repetition/noise کنترل شده‌اند.
12. Raw data، formula، unit و uncertainty حفظ می‌شوند.
13. Intensity و Total هر دو گزارش می‌شوند.
14. Rebound/induced demand بررسی شده است.
15. Resource displacement بین لایه‌ها ثبت است.
16. Quality/reliability/security/privacy/a11y hard guardrail دارند.
17. Cost/currency/provider/region/exit در Scope‌اند.
18. Production monitor/alert/owner وجود دارد.
19. Rollback/retirement/claim correction تمرین شده‌اند.
20. Decision authority، dissent و expiry ثبت شده‌اند.

جمع‌بندی: پایداری یک ادعاست؛ Evidence می‌خواهد

کد سبک، Cloud bill کمتر و Performance بهتر می‌توانند سرنخ‌های ارزشمند باشند، اما به‌تنهایی Energy یا Carbon کمتر را ثابت نمی‌کنند. پایداری دیجیتال یک مسئلهٔ سیستمی است: Outcome، حجم، Client/Network/Cloud/Hardware، زمان/مکان برق، embodied impact، کاربران، قابلیت ادامه و Rebound با هم تصمیم را می‌سازند.

QA بهترین اثر را وقتی دارد که Claim را محدود کند، Functional unit و Boundary بسازد، روش را قابل‌بازتولید کند، Proxy را صادقانه نام ببرد، intensity را کنار Total بگذارد و Trade-offها را پنهان نکند. خروجی حرفه‌ای ممکن است «کاهش اندازه‌گیری شد»، «فقط Proxy بهتر شد»، «Evidence ناکافی است» یا «Claim باید پس گرفته شود» باشد.

پرسش‌های متداول دربارهٔ QA و پایداری دیجیتال

آیا کاهش CPU و حجم شبکه یعنی Carbon کمتر؟

نه لزوماً. آن‌ها Resource/Activity proxy هستند. Energy به hardware، utilization، power state، workload و Boundary وابسته است؛ Carbon نیز factor برق در زمان/مکان و embodied allocation می‌خواهد. کاهش یک لایه ممکن است کار را به Client/Server/Network دیگری منتقل کند. Proxy را با نام خودش و Carbon را فقط با Method گزارش کنید.

Software Carbon Intensity یا SCI چیست؟

SCI روشی برای گزارش Operational و سهم embodied Carbon نسبت به Functional unit نرم‌افزار است و به ISO/IEC ۲۱۰۳۱:۲۰۲۴ پیوند دارد. Rate را می‌سنجد، نه Total footprint کامل سازمان. Boundary، E/I/M/R، source، allocation و نسخه لازم‌اند؛ این مقاله اجرای رسمی استاندارد یا Certification ارائه نمی‌کند.

برای شروع تست انرژی نرم‌افزار چه چیزی لازم است؟

یک Outcome و Functional unit محدود، Baseline/workload ثابت، محیط نسخه‌دار، meter یا model با coverage روشن، warm-up/repetition/raw data و guardrail کیفیت لازم است. ابتدا Joule/kWh یا Proxy را درست بسنجید؛ اگر Carbon factor معتبر ندارید، ادعای CO₂e نکنید.

آیا Cloud یا Serverless ذاتاً پایدارتر است؟

خیر. utilization و autoscaling می‌توانند بهتر شوند، اما Region، grid، idle reserve، replication، data transfer، Provider allocation، embodied hardware، reliability و demand مهم‌اند. Serverless مدیریت Server را پنهان می‌کند، حذف نمی‌کند. گزینه‌ها را با Functional outcome، rate، total و guardrail مقایسه کنید.

آیا پایداری همیشه هزینهٔ بلندمدت را کاهش می‌دهد؟

تضمینی وجود ندارد. بعضی اقدام‌ها Energy و Cloud cost را کم می‌کنند؛ بعضی meter، migration، redundancy، support یا سخت‌افزار هزینه می‌افزایند. نرخ ارز، تحریم، capacity، incident، exit و opportunity cost نیز اثر دارند. TCO را با range، baseline و countermetric بسنجید؛ شعار «بازده بسیار بالا» نسازید.