یک تحلیلگر مالی با ابزار No-Code فرایند بازپرداخت هزینه را در دو روز ساخته است. فرم زیباست، Demo موفق است و Approval ایمیلی هم میرسد؛ اما مدیرِ جایگزین میتواند درخواست واحد دیگری را تأیید کند، Connector حسابداری پس از Timeout همان سند را دوباره میسازد و تغییر دستی Environment تولید در هیچ Repository ثبت نشده است. «کد کمی نوشتهایم» دربارهٔ این ریسکها چه میگوید؟ تقریباً هیچ.
تست Low-Code و No-Code همان تست نرمافزار است، با سطح انتزاع و مرز مسئولیت متفاوت. Test Basis فقط Source code نیست؛ پیکربندی، Formula، Workflow، Role، Data policy، Connector، Environment، Artifact و رفتار متغیر Platform نیز بخشی از محصولاند. این راهنما نشان میدهد QA چگونه بدون تبدیلشدن به Gatekeeper، برای این سطح تغییرپذیر شواهد قابلتصمیم بسازد.
Low-Code و No-Code دقیقاً چه معنایی دارند؟
این دو واژه یک استاندارد کیفیت یا دو دستهٔ کاملاً جدا نیستند. آنها طیفی از Abstraction را توصیف میکنند: بخشی از منطق با مدل بصری، Metadata، Expression، Template و Connector ساخته میشود و ممکن است Extension یا کد سفارشی نیز وجود داشته باشد. یک ابزار «No-Code» برای Maker میتواند در Runtime، Integration و Administration به تخصص فنی جدی نیاز داشته باشد.
- No-Code: مسیر اصلی ساخت برای کاربر هدف بدون نوشتن کد متنی طراحی شده، نه اینکه نرمافزار یا منطق اجرایی وجود ندارد؛
- Low-Code: مدلسازی بصری با امکان Expression، Script، Component یا Extension ترکیب میشود؛
- Citizen development: نرمافزاری که بخشی از آن را کاربران خارج از تیم توسعهٔ سنتی میسازند؛ این عنوان دربارهٔ مسئولیت و صلاحیت فرد بهتنهایی حکم نمیدهد؛
- Platform-generated artifact: Package، Metadata یا Runtimeای که Vendor میسازد یا اجرا میکند؛ همچنان Version، Dependency و رفتار قابلآزمون دارد.
بنابراین «کمکد» مساوی «کمریسک»، «ساده»، «امن» یا «سریع در کل چرخهٔ عمر» نیست. سرعت Prototype ممکن است بالا باشد، ولی Integration، Governance، Migration، Support و Exit هزینهٔ خود را دارند.
چه چیزی را Platform تست میکند و چه چیزی با شماست؟
گواهی، SLA یا Test داخلی Vendor میتواند دربارهٔ بخشی از Platform شاهد بدهد؛ اما صحت قانون کسبوکار، مجوز کاربران، ترکیب Connectorها و نتیجهٔ Workflow شما را اثبات نمیکند. یک قرارداد مسئولیت بنویسید:
| سطح | نمونه مسئولیت Platform/Vendor | نمونه مسئولیت تیم محصول |
|---|---|---|
| Runtime | زیرساخت سرویس و Patchهای اعلامشده | رفتار App روی نسخه/Region/License انتخابشده |
| Builder | Parser/Designer و قابلیتهای مستند | Formula، Config، Component و محدودیت استفاده |
| Identity | مکانیزم Authentication موجود | Role، Scope، Sharing، Service account و Recertification |
| Data | Storage/API قابلیتدار | Schema، Classification، Retention، Authorization و Reconciliation |
| Connector | Adapter و Operationهای مستند | انتخاب Scope، Mapping، Retry، Idempotency و Data egress |
| ALM | Environment/Package/Pipeline capability | Branch، Review، Promotion، Secret، Rollback و Owner |
| Quality evidence | Status/SLA/Release note | Risk coverage، Test result، residual risk و release decision |
مدل رهبری کیفیت با مالکیت روشن کمک میکند Whole-team quality به «همه مسئولاند، پس هیچکس پاسخگو نیست» تبدیل نشود. نام Vendor یا QA جای Owner ریسک کسبوکاری را نمیگیرد.
گام صفر: Inventory و مالک را پیدا کنید
اپلیکیشنی که سازمان از وجودش خبر ندارد، Test plan و Incident owner هم ندارد. Inventory حداقل باید App/Flow/Agent، Environment، Business owner، Technical owner، Maker، User population، Data classification، Connectorها، Identityها، Criticality، Last use/change، Platform/License و End-of-Life را ثبت کند.
برای نمونه، Power Platform Inventory امکان دیدن App، Flow، Environment، Owner و برخی استفادههای Connector را فراهم میکند و یافتن منابع متعلق به افراد درحالخروج را جزو کاربردهایش میداند. این یک قابلیت محصولی است؛ در هر Platform باید Coverage، Freshness و منابع خارج از Inventory را جدا بررسی کنید.
ریسکسنجی: هر App مسیر یکسان نمیخواهد
| Tier | نمونه | حداقل کنترل |
|---|---|---|
| T0 — آزمایش شخصی | Prototype با دادهٔ ساختگی و بدون کاربر دیگر | مالک، Expiry، ممنوعیت داده حساس و حذف امن |
| T1 — ابزار تیمی | یادآوری یا فرم داخلی برگشتپذیر | Peer review، Role check، Test data، Backup/export و Support |
| T2 — Business-critical | Approval مالی یا عملیات مشتری | Environment جدا، Versioned artifact، layered tests، recovery و On-call |
| T3 — حساس/تنظیمشده | PII، پول، سلامت یا تصمیم پراثر | Security/privacy/legal review، separation of duties، evidence retention و risk acceptance |
Tier را فقط از تعداد کاربر نسازید. Impact محرمانگی، تمامیت، Availability، اثر مالی/حقوقی، برگشتپذیری، وابستگی و Detectability را بسنجید. Prototype بهمحض ورود دادهٔ واقعی یا اتکای تیم میتواند Tier عوض کند.
کارت App؛ Test Basis مشترک
قبل از سناریوها، این کارت یکصفحهای را تکمیل کنید:
App / Flow / version / risk tier:
Purpose, users and prohibited uses:
Business owner / technical owner / support owner:
Data classes, residency, retention and deletion:
Roles, service identities and approval authority:
Tables, formulas, workflows and custom components:
Connectors, APIs, scopes, quotas and sandboxes:
Platform, environment, region and license assumptions:
SLI/SLO, audit and alert routes:
Deployment, rollback, restore and exit path:
Known gaps, residual risk, review date:
اگر Maker نتواند نتیجهٔ مورد انتظار، State، Failure و Evidence را توضیح دهد، Recorder بیشتر مشکل را حل نمیکند. برای طراحی Clock، Dependency، Fault، Reset و Oracle از قرارداد تستپذیری نرمافزار استفاده کنید.
سطح تغییر را فراتر از «کد» ببینید
Regression selection باید هر تغییری را که رفتار را عوض میکند ببیند:
- Screen، Control، Formula، Validation و Default value؛
- Workflow step، Branch، Timeout، Retry و Trigger؛
- Table/column/type/constraint، Migration و Seed/reference data؛
- Role، Sharing، Group، Service account و OAuth scope؛
- Connector operation، endpoint، schema، mapping و version؛
- Environment variable، connection reference، Secret و policy؛
- Custom code/component/library و transitive dependency؛
- Platform release، regional rollout، deprecation، license و quota؛
- Browser/device/locale/accessibility setting.
برای هر Release یک Change Manifest بسازید: Baseline، Diff، Artifact hash/version، Environment، Dependencies، Migration، Test selection، Approver و Rollback target. Screenshot Designer منبع حقیقت مناسبی برای Diff نیست.
سبد شواهد برای اپلیکیشن LCNC
| لایه | پرسش اصلی | نمونه Evidence |
|---|---|---|
| Static/config review | آیا Formula/Policy/Role/Secret الگوی خطرناک دارد؟ | Diff، rule output، peer decision |
| Logic/model | قانون و Transition درست است؟ | Decision table، property/invariant، formula test |
| Workflow/component | Branch/Retry/Error/Compensation چگونه عمل میکند؟ | state/event trace و side-effect oracle |
| Connector/integration | مرز واقعی و Failure protocol چیست؟ | contract، virtual service، sandbox، provider evidence |
| API/data | Schema، Authorization و State درستاند؟ | request/response + database/audit oracle |
| UI/journey | کاربر مجاز کار کامل را انجام میدهد؟ | role-specific E2E، accessibility/manual review |
| Non-functional | Capacity، security، privacy و recovery کافی است؟ | profile، threat evidence، restore drill |
| Production feedback | Outcome واقعی و Drift دیده میشود؟ | SLI، failed run، audit gap، support signal |
هیچ نسبت ثابتی میان این لایهها وجود ندارد. کوچکترین Boundary را انتخاب کنید که failure mechanism را حفظ میکند. UI recorder برای Retry یک Connector یا رکوردی که پس از Timeout دو بار ساخته میشود، Oracle کامل نیست.
بازبینی پیکربندی و Formula
Visual بودن منطق، نیاز به Review را حذف نمیکند. در Diff یا Export قابلخواندن این موارد را بررسی کنید:
- Default و implicit conversion، Blank/Null/Empty و Locale parsing؛
- Branch دستنیافتنی، شرط معکوس و مقایسهٔ String بهجای مقدار canonical؛
- Hard-coded ID، URL، Email، Secret، Environment یا Role؛
- Query/Filter بدون Scope کاربر یا بدون حد؛
- Expression تکراری و Ruleهای ناسازگار در Screen/Flow/Data layer؛
- Error پنهانشده، Fail-open و Success message پیش از Commit؛
- Trigger بازگشتی، Loop ناخواسته و Fan-out بیحد؛
- وابستگی به Control name یا ترتیب بصری بدون قرارداد.
Static checker یک Signal است. False positive/negative، Version rule و Suppression با Owner/Expiry را ثبت کنید؛ «بدون Warning» معادل رفتار درست نیست.
Workflow را به State machine تبدیل کنید
Flow موفق فقط مسیر سبز نیست. Stateهای Draft، Submitted، Pending-Manager، Pending-Finance، Approved، Rejected، Cancelled، Posted و Reconciliation-Failed را بنویسید. Event، Guard، Authority، Side effect و invariant هر Transition را مشخص کنید.
Retry و اثر جانبی
Timeout معلوم نمیکند درخواست در Provider Commit شده یا نه. این حالتها را جدا کنید:
- Fail پیش از ارسال؛
- Fail پس از ارسال و پیش از Commit؛
- Commit موفق و Ack گمشده؛
- Response نامعتبر پس از اثر؛
- Retry همزمان توسط کاربر و Platform؛
- Callback دیر، تکراری یا خارج از ترتیب.
Idempotency key، deduplication scope، Retry budget، backoff، cancellation و Compensation را در Contract بیاورید. Success را در منبع مستقل مثل Ledger/Accounting record بسنجید، نه فقط رنگ Run.
Approval و Delegation
ماتریس Role را با Requester، Manager، Delegate، Finance، Admin، Service identity و Suspended/Departed user بسازید. Self-approval، تغییر Approver پس از Submission، delegation expiry، approval از لینک Forwardشده، double click، concurrent decision و cancellation-after-approval را بررسی کنید.
Connector؛ مرز پرریسک پشت Drag-and-drop
هر Connector یک Dependency و مسیر خروج داده است. Contract آن حداقل این فیلدها را دارد:
- Service/operation/owner و Environment؛
- Authentication identity، OAuth scope و Secret rotation؛
- Endpoint، protocol، schema و version/deprecation؛
- Data classification، direction، residency و allowed egress؛
- Timeout، rate/concurrency limit و pagination؛
- Retry، idempotency و partial-side-effect semantics؛
- Error taxonomy و user/support message؛
- Sandbox/virtualization fidelity و Production probe؛
- Monitoring، SLA assumption، fallback و exit owner.
برای Contract، Sandbox و Failure testing از راهنمای تست یکپارچهسازی استفاده کنید. Mock «همیشه ۲۰۰» فقط Mapping ساده را میسنجد؛ Rate limit، Expired token، schema drift، timeout-after-commit و provider outage را حفظ نمیکند.
API و داده را پشت UI پنهان نکنید
حتی اگر Maker API را مستقیم ندیده باشد، Connector و Runtime معمولاً Request میفرستند. Test این سطح شامل موارد زیر است:
- Schema و type/required/additional field؛
- Authentication و object/record-level authorization؛
- Boundary، Unicode، Persian/Arabic digits و canonical money/time؛
- Pagination، filtering، sorting و large dataset؛
- Optimistic concurrency/version conflict؛
- Duplicate create، idempotent update و delete/restore؛
- Audit، retention و reconciliation.
راهنمای تست API طراحی Assertionهای HTTP، Contract، State، مجوز و CI را با جزئیات پوشش میدهد. UI success را با State یا Event مستقل تکمیل کنید.
امنیت: اعتماد کور به Platform کافی نیست
OWASP Citizen Development Top 10 در نسخهٔ فعلی خطرهایی مانند Blind Trust، Account impersonation، Authorization misuse، Sensitive-data leakage، component نامطمئن، Security misconfiguration، Asset-management failure و Logging/monitoring failure را برجسته میکند. این فهرست Risk catalog است، نه چکلیست اثبات امنیت.
Threat model را روی App، Data، Identity، Connector، Admin plane و Supply chain بسازید:
- آیا Maker یا Service account بیش از نیاز دسترسی دارد؟
- آیا پنهانکردن Control بهاشتباه Authorization تلقی شده است؟
- آیا کاربر با URL/API مستقیم رکورد دیگری را میخواند یا تغییر میدهد؟
- آیا Connector دادهٔ حساس را به گروه/سرویس نامجاز میفرستد؟
- آیا Secret در Formula، Export، Log یا Screenshot دیده میشود؟
- آیا Component/Template سفارشی Publisher، Version، provenance و EOL دارد؟
- آیا Audit قابلحذف/دستکاری یا بدون Correlation است؟
NIST SSDF 1.1 واژگان و Practiceهای امن را مستقل از مدل SDLC ارائه میکند؛ آن را برای Requirement، حفاظت Artifact، بررسی Component، پاسخ به Vulnerability و Supplier conversation به LCNC نگاشت کنید. Export و Metadata هم Artifact نرمافزاریاند.
تست فعال امنیتی نیازمند مجوز، Environment امن و مهارت مربوط است. فرایند Threat→Requirement→Evidence→Finding→Retest در راهنمای تست امنیت آمده است.
Data policy یک Guardrail است، نه اثبات حریم خصوصی
در نمونهٔ Power Platform، Data policies مایکروسافت Connectorها را در گروههای Business، Non-business یا Blocked دستهبندی و ترکیب بعضی گروهها را محدود میکنند. این کنترل به کاهش مسیرهای ناخواسته کمک میکند، اما Purpose limitation، حداقلسازی Field، محتوای Attachment، دسترسی Record، Retention یا Export انسانی را اثبات نمیکند.
سناریوهای تست Policy شامل Connector جدید، Custom connector، Environment خارج Scope، Policy precedence، تغییر گروه، App قدیمی، Export/import، Service account و Failure message است. Default برای Connector تازه باید آگاهانه انتخاب شود؛ «فعلاً طبقهبندی نشده» را معادل امن نگیرید.
ALM؛ اپلیکیشن بصری هم نسخه و Artifact میخواهد
راهنمای ALM مایکروسافت برای Power Platform Environmentهای Development/Test/Production، Solution برای انتقال Componentها، Source control و CI/CD را جدا میکند و Managed solution را برای محیطهای غیرتوسعه مطرح میکند. جزئیات در Vendorهای دیگر فرق دارد، اما سؤالهای اصلی ثابتاند:
- منبع حقیقت Repository است یا Production builder؟
- چه چیزهایی Export میشوند و چه چیزهایی بیرون Package میمانند؟
- Connection، Environment variable، Secret و Reference data چگونه Map میشوند؟
- Build Artifact چگونه Version/Hash و Sign/Provenance میگیرد؟
- چه کسی Promote میکند و آیا Maker دسترسی ویرایش مستقیم Production دارد؟
- Merge conflict در Form/Flow/Canvas چگونه حل و بازبینی میشود؟
- Platform release و deprecation چگونه Regression را Trigger میکند؟
برای هر Environment یک Manifest واقعی از Platform/Region، Solution/App/Flow version، schema، connection references، variables، policies، identities، license/capacity و external endpoints نگه دارید. الگوی کنترل Drift و Test data در راهنمای مدیریت محیط تست قابلاستفاده است.
Pipeline انتشار و Gateهای شواهد
- Export/unpack/validate و ثبت Artifact immutable؛
- Static/config/security rules با Suppression نسخهدار؛
- Formula/model و workflow component tests؛
- Connector contract/API/data migration tests؛
- Deploy به Test با Connection/variable mapping کنترلشده؛
- Role matrix، journey، accessibility و performance؛
- UAT روی Acceptanceهای مشخص، نه Demo آزاد؛
- Release memo، residual risk و تصمیم مالک؛
- Promotion همان Artifact، smoke و canary محدود؛
- SLI/alert، rollback/roll-forward و post-deploy verification.
معماری Laneهای سریع/کند و Failure policy در راهنمای Continuous Testing آمده است. اگر Platform قابلیت Source یا Pipeline کامل ندارد، محدودیت را ثبت و کنترل جبرانی—Export نسخهدار، Approval، Change freeze یا Snapshot—طراحی کنید.
Rollback و Restore را یکی نگیرید
- Rollback app/config: بازگشت Artifact و تنظیمات؛
- Schema rollback: ممکن است destructive یا ناممکن باشد؛ Migration روبهجلو لازم شود؛
- Data restore: بازگرداندن Dataset به Point زمانی، با اثر روی تغییرهای معتبر بعدی؛
- Connector recovery: Reconcile اثرهای خارجی که Restore محلی حذفشان نمیکند؛
- Credential recovery: Rotation/Reauthorization پس از رخداد یا جابهجایی Owner.
برای نمونه، مستند Backup و Restore محیط Power Platform نوع Environment، Retention و محدودیتهای Restore را مشخص میکند. وجود Backup کافی نیست؛ RTO/RPO، مجوز، زمان Restore، Connectionهای خارجی، Audit و Reconciliation را با Drill ایمن اثبات کنید.
تست UI، RTL و دسترسپذیری
Component آماده میتواند در ترکیب شما نام، نقش، Focus order یا Error semantics نادرست داشته باشد. Responsive preview نیز دستگاه، Zoom، Keyboard، Screen reader و browser واقعی نیست.
- Keyboard-only، visible focus، focus trap و ترتیب منطقی RTL؛
- Name/Role/Value، Label، Error association و Status message؛
- Zoom/Reflow، Contrast و Touch target؛
- Persian text، ZWNJ، mixed-direction ID/Email/IBAN و Copy/Paste؛
- رقم فارسی/عربی/لاتین با Parser صریح و Storage canonical؛
- تقویم نمایشی شمسی در برابر Instant/UTC و timezone Asia/Tehran؛
- IRR canonical در برابر نمایش تومان و جلوگیری از تبدیل دوباره؛
- PDF/Email/Notification/Export بهعنوان Channelهای مستقل.
WCAG 2.2 معیارهای آزمونپذیر و Technology-neutral ارائه میکند و خودش نیز تأکید دارد که ابزار خودکار همهٔ نیازها را پوشش نمیدهد. مسیر اجرایی فارسی و ترکیب تست دستی/خودکار در راهنمای تست دسترسپذیری آمده است.
عملکرد، Capacity، License و Quota
Response time تنها ریسک نیست. Query delegation، تعداد Row، Attachment، Connector fan-out، concurrent Flow، Pagination، Retry، Background job، License assignment و Request quota میتوانند Outcome را تغییر دهند.
برای نمونه، مستند Power Platform Request limits نشان میدهد درخواستهای Connector، Actionهای موفق/ناموفق، Retry و Pagination میتوانند در Allocation شمارش شوند. عدد و License ممکن است تغییر کند؛ در Release، Documentation version و Entitlement واقعی Tenant خود را ثبت کنید، نه عدد حفظشده از مقاله.
Workload model باید Journey mix، Arrival، Dataset size، Role، Connector latency و Background traffic را داشته باشد. p95/p99، Error/throttle ratio، Goodput، Queue age، retry amplification و Cost/license consumption را کنار Outcome بسنجید. از تست مخرب روی Tenant/Provider تولید بدون مجوز خودداری کنید.
ابزار Native تست چه چیزی را پوشش میدهد؟
قابلیتهای داخلی Platform برای Feedback سریع ارزشمندند، اما Scope آنها را دقیق بخوانید. در یک نمونهٔ مشخص، Power Apps Test Studio از Expression یا Recorder برای تست Canvas app استفاده میکند و State را میان Test caseهای یک Suite حفظ میکند؛ خود مستند نیز اتکای کامل به Automation را توصیه نمیکند.
سبد ابزار ممکن است ترکیبی باشد:
- Native formula/workflow/UI tests برای Feedback نزدیک Builder؛
- Static/config/solution checker برای Patternهای شناختهشده؛
- API/contract tests خارج UI برای مرزهای پایدارتر؛
- Service virtualization و Sandbox برای Failureهای Dependency؛
- External browser/mobile automation برای Journey و Accessibility؛
- Performance/security/data tooling برای پرسشهای تخصصی؛
- Production monitoring و audit برای Drift/Outcome واقعی.
Record-and-playback Maintainability یا Oracle قوی را تضمین نمیکند. Control rename، layout، state مشترک، test data، async wait و role context را مدیریت کنید. هر تست باید معلوم کند چه ریسکی را میسنجد و چه چیزی خارج Scope است.
امنیت را از چند زاویه ارزیابی کنید
راهنمای Security testing برای Power Platform workload ترکیب دید Inside-out و Outside-in، محیط جدا، فرایند تکرارپذیر و تست دستی در کنار Automation را پیشنهاد میکند. از این اصل عمومی استفاده کنید، اما ابزار و مجوز را با Platform خود تطبیق دهید.
| زاویه | پرسش |
|---|---|
| Maker/Admin | Config، Role، Secret، Policy و Artifact چگونه تغییر میکند؟ |
| User/attacker | آیا UI/API/Link/Connector اجازهٔ عمل غیرمجاز میدهد؟ |
| Data | چه کسی کدام Record/Field/Attachment را میبیند و خارج میکند؟ |
| Operations | Misuse/Leakage/Config drift چگونه Detect و پاسخ داده میشود؟ |
| Supplier | Platform/Template/Component incident، update و EOL چه قراردادی دارد؟ |
Runtime evidence و بازاعتبارسنجی
SaaS Platform بدون Deploy شما هم تغییر میکند. Release note، regional rollout، connector deprecation، policy، browser و identity provider میتواند Assumption را عوض کند. Triggerهای Retest/Recertification را تعریف کنید:
- App/Flow/Schema/Role/Policy/Connector change؛
- Platform wave یا Runtime version؛
- Quota/license/pricing یا geography change؛
- Security advisory یا Secret/certificate rotation؛
- Owner departure، support gap یا orphan detection؛
- Incident، error-rate/latency shift یا complaint pattern؛
- Data classification/retention/regulatory change؛
- Vendor deprecation یا Exit decision.
Telemetry شامل App/Flow/Operation/Correlation ID، version/environment، role cohort، connector outcome، retry/throttle، latency، business result و audit status باشد؛ PII و Secret را حذف کنید. نبود Log یا gap در Audit «موفقیت» نیست، Unknown است.
نمونهٔ ایرانی: فرایند بازپرداخت هزینه
این مثال ساختگی است و نتیجهٔ یک پروژهٔ واقعی را ادعا نمیکند. کارمند مبلغ، شرح و تصویر رسید را ثبت میکند؛ مدیر مستقیم و سپس مالی تأیید میکنند؛ Connector سند را در سیستم حسابداری میسازد و کارمند Notification میگیرد.
قرارداد داده و نقش
- مبلغ در Storage/API به IRR canonical و در UI با Label روشن به ریال یا تومان؛
- ورودی رقم فارسی/عربی/لاتین طبق Rule، بدون تغییر شناسه یا شماره حساب؛
- Event time به UTC و نمایش/Deadline با Asia/Tehran و تقویم اعلامشده؛
- Attachment با type/size/malware/privacy policy و دسترسی محدود؛
- Requester فقط رکورد خود، Manager فقط محدودهٔ سازمانی، Finance محدودهٔ مصوب؛
- Delegate دارای Scope و Expiry؛ Admin حق Business approval ندارد مگر Requirement صریح؛
- Service account حداقل Scope لازم و Rotation/Owner مستقل.
سناریوهای حیاتی
| سناریو | Oracle |
|---|---|
| کاربر «۱۵۰٬۰۰۰ تومان» را با رقم فارسی وارد میکند | یک تبدیل به IRR canonical؛ نمایش و Export واحددار |
| Manager لینک Approval را Forward میکند | Identity/record authorization مستقل از داشتن لینک |
| Delegate پس از Expiry پاسخ میدهد | رد تصمیم و Audit بدون تغییر State |
| Connector پس از ساخت سند Timeout میشود | Retry با Idempotency؛ دقیقاً یک سند حسابداری |
| دو Approver همزمان Approve/Reject میکنند | Version conflict و یک Transition معتبر |
| Schema حسابداری Field تازه میخواهد | Contract gate یا Quarantine؛ نه Drop خاموش |
| Quota در پایان ماه نزدیک سقف است | Throttle/backpressure، alert و عدم گمشدن درخواست |
| App rollback میشود | Schema/data سازگار و اثرهای خارجی Reconcile شوند |
شواهد تصمیم انتشار
Release memo باید Artifact/Environment، Role matrix، ۱۲ Rule مالی منتخب، Connector contract، Test data، Workflow transitions، Security/privacy evidence، p95/p99 و throttle profile، accessibility/RTL، restore/reconcile drill، Unknownها و residual risk را ثبت کند. Owner مالی—not QA—Authority و ریسک باقیماندهٔ فرایند را میپذیرد.
نقش QA در LCNC؛ نه حذف، نه پیشگویی
هیچ نتیجهٔ عمومی دربارهٔ حذف شغل، افزایش تقاضا یا «آیندهٔ قطعی» از نوع ابزار به دست نمیآید. نقش به Criticality، ساختار تیم، Platform، Regulation و قابلیت Maker بستگی دارد. QA میتواند در چهار سطح ارزش بسازد:
- Enablement: Template، مثال، Training و Self-check برای Maker؛
- Coaching: Risk، Acceptance، State/Oracle و Testability؛
- Engineering: Contract/API automation، data/environment، CI و observability؛
- Independent assurance: برای Riskهای حساس، بدون گرفتن تصمیم کسبوکار.
مهارت مفید شامل تحلیل دامنه، Data model/query، Workflow/state، Identity/authorization، API/Connector، ALM، Security/privacy، Accessibility، Observability و ارتباط است. Coding literacy برای Debug، Extension و Automation مفید است، اما سطح لازم باید از Job و Risk بیاید؛ نه از برچسب «تستر مدرن».
مدل عملیاتی Citizen Development
| نقش | مسئولیت |
|---|---|
| Maker | App card، logic/config، self-test، evidence و runbook |
| Business owner | Purpose، Tier، Rule، authority، funding و risk decision |
| Platform admin/CoE | Inventory، environment، policy، capacity، ownership و lifecycle |
| Data owner/privacy | Classification، access، retention، egress و deletion |
| Security | Threat model، guardrail، active-test authority و incident path |
| QA/quality engineer | Risk/evidence design، coaching، independent checks و gaps |
| Integration owner | Connector/API contract، sandbox، failure/reconciliation |
| Operations/support | SLI/alert، incident، recovery و user communication |
| Release/risk owner | Go/No-go/limited rollout و residual-risk acceptance |
Tier بالا Peer review و Independent evidence بیشتری میخواهد؛ T0 را با تشریفات T3 خفه نکنید. Guardrail خوب مسیر امن را آسان و استثنا را قابلردیابی میکند.
متریکهایی که تصمیم میسازند
- درصد Appهای فعال با Business/Technical owner و Review date؛
- Risk-tier coverage و تعداد T2/T3 ناشناخته؛
- درصد Releaseها با immutable artifact و environment manifest؛
- Role/connector/risk-evidence coverage، نه تعداد Test خام؛
- Change failure/rollback و restore/reconciliation success؛
- Connector error/throttle/retry amplification و outcome loss/duplicate؛
- Lead time تفکیکشده از waiting/rework، با Guardrail امنیت و Incident؛
- Orphaned apps، expired exceptions و unsupported dependencies؛
- Audit/telemetry gaps و Mean time to ownership؛
- Customer/task success برای Journeyهای مهم.
تعداد App، Automation percentage، Maker activity یا Pass rate بهتنهایی کیفیت نیست. Definition، denominator، source، freshness، cohort و gaming risk هر Metric را ثبت کنید.
دامهای رایج
- فرض اینکه No-Code یعنی بدون منطق، Dependency یا ریسک؛
- اعتماد به Platform certification بهعنوان گواهی App؛
- پیشبینی بازار/شغل با یک آمار تاریخدار و بیمنبع؛
- فرستادن Prototype با دادهٔ واقعی به Production؛
- نداشتن Inventory، Owner، Tier، Support یا EOL؛
- ویرایش مستقیم Production و Screenshot بهجای Source/Diff؛
- اتکا به UI recorder برای Workflow/Connector/State؛
- Mock همیشهموفق و ندیدن Timeout-after-commit؛
- Authentication بدون record-level authorization؛
- Service account شخصی یا Scope بیشازحد؛
- Data policy بهعنوان اثبات Privacy؛
- Default connector group بدون Review؛
- Retry بدون Idempotency/Compensation؛
- Rollback App بدون Schema/Data/External effects؛
- Backup بدون Restore/Reconciliation drill؛
- تست فقط با Admin یا بهترین License/Network؛
- Hard-code ریال/تومان، تاریخ یا Environment؛
- فرض دسترسپذیری از روی Component آماده؛
- تفسیر missing Audit/Telemetry بهعنوان Success؛
- Gate سنگین یکسان برای Prototype و فرایند مالی؛
- تبدیل QA به مالک همهٔ Riskها.
برنامهٔ ۳۰روزه
هفتهٔ اول: Inventory و Tier
App/Flowهای فعال را از Admin API و گفتوگو با واحدها جمع کنید. Owner، Purpose، Data، Connector، User و Last change را ثبت؛ منابع یتیم و T2/T3 ناشناخته را اولویتبندی کنید.
هفتهٔ دوم: Guardrail و App card
یک App critical را انتخاب کنید. مسئولیت Platform/App، Role/Service identity، Data policy، Environment، Change manifest و Support/Expiry را روشن کنید. مسیر Exception را Ownerدار و زماندار سازید.
هفتهٔ سوم: Evidence portfolio
Workflow را State model کنید؛ یک timeout-after-commit، یک negative authorization، یک schema drift و یک quota scenario اجرا کنید. Oracle مستقل، limitation و cleanup را ذخیره کنید.
هفتهٔ چهارم: ALM و Recovery
همان Artifact را از Test به Production-like منتقل و mappingها را Verify کنید. Rollback/restore/reconciliation را Drill، سپس SLI، Alert، Release memo و ۹۰-day recertification را فعال کنید.
چکلیست انتشار LCNC
- App در Inventory، دارای Owner، Tier و Review date است.
- Purpose، Users، prohibited use و Data classification روشناند.
- مرز مسئولیت Platform، App، Connector و Business ثبت شده است.
- Change manifest همهٔ Config/Role/Policy/Dependencyها را میبیند.
- Artifact نسخهدار از مسیر کنترلشده Promote میشود.
- Workflow state، retry، concurrency و compensation آزمودهاند.
- Connector contract شامل Scope، Limit، Failure و Egress است.
- Role matrix با تست منفی UI/API/Record تکمیل شده است.
- Secret/Service identity حداقل دسترسی، Rotation و Owner دارد.
- Data policy، retention، audit و deletion جدا ارزیابی شدهاند.
- Dataset/Quota/Throttle/License profile نماینده است.
- RTL، Persian/Arabic digits، IRR/toman و UTC/Tehran کنترل شدهاند.
- Keyboard/Screen reader/Zoom و خطاهای فرم بررسی شدهاند.
- Rollback، restore و external reconciliation تمرین شدهاند.
- SLI/Alert/Support و telemetry-gap semantics آمادهاند.
- Unknown و residual risk به مالک تصمیم نامبرده رسیدهاند.
پرسشهای متداول
آیا اپلیکیشن No-Code واقعاً به تست نیاز دارد؟
بله، اگر Outcome آن اهمیت دارد. No-Code فقط شیوهٔ Authoring را تغییر میدهد؛ Rule، Data، Identity، Workflow، Connector و Runtime همچنان میتوانند شکست بخورند. عمق تست باید از Risk tier بیاید؛ Prototype شخصی با فرایند مالی یک Gate ندارد.
آیا تستر برای LCNC باید برنامهنویسی بلد باشد؟
نیاز ثابت و عمومی وجود ندارد. تحلیل دامنه، Workflow، Data، Authorization و Evidence پایهاند. Coding literacy برای API/contract automation، Debug و Extension مفید یا در بعضی نقشها لازم است؛ اما Requirement شغل باید بر Platform و Risk واقعی نوشته شود، نه شعار.
آیا ابزار تست داخلی Platform کافی است؟
معمولاً فقط بخشی از شواهد را میسازد. ابزار Native برای Formula/UI/Feedback سریع خوب است، ولی ممکن است Connector failure، API authorization، performance، accessibility، recovery یا Production drift را کامل نبیند. Scope و limitation هر ابزار را با Risk map تطبیق دهید.
مهمترین تست امنیتی برای Low-Code چیست؟
یک پاسخ ثابت وجود ندارد، اما Authorization منفی، Service identity/OAuth scope، Data egress از Connector، Secret exposure، Config/policy و Audit معمولاً نقاط مهماند. از Threat model و Data flow شروع کنید؛ OWASP Top ۱۰ یک ورودی است، نه مدرک کامل امنیت.
چگونه Vendor lock-in را در تست مدیریت کنیم؟
Export format، Data portability، API/Connector contract، Artifact/version history، observability access، backup/restore، EOL و هزینه/زمان مهاجرت را پیش از Critical شدن App آزمایش کنید. یک Exit drill کوچک اجرا و Gapها را با Owner و تاریخ انقضا ثبت کنید؛ ادعای Portability را از بروشور نپذیرید.
جمعبندی: سطح انتزاع عوض شده، مسئولیت شواهد نه
Low-Code/No-Code میتواند ساخت برخی راهحلها را برای برخی تیمها سادهتر کند، اما کیفیت از Drag-and-drop تولید نمیشود. سازمان باید بداند چه Appهایی دارد، هرکدام چه ریسکی دارند، کدام کنترل با Platform است و کدام Outcome را خودش باید اثبات کند.
از یک App فعال شروع کنید: Owner و Tier را ثبت، Workflow را به State تبدیل، Connector را Contractدار و یک Timeout-after-commit را با Oracle مستقل اجرا کنید. اگر Artifact، Role matrix یا Recovery path ندارید، همان Gap از انتخاب ابزار تست تازه مهمتر است.
