ابزارهای تست

اتوماسیون تست بدون کد؛ از Recorder تا PoC و CI

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

یک Recorder فرضی، مسیر پرداخت را در چند دقیقه ضبط کرد و Demo سبز شد. همان Flow پس از تغییر بی‌ضرر ID دکمه شکست؛ وقتی دو CTA هم‌نام روی صفحه آمدند اشتباه Pass شد؛ و در نسخه‌ای دیگر Toast موفقیت را دید، اما Order در Backend ساخته نشده بود. «بدون کد» زمان تایپ کد را کم کرده بود، نه نیاز به طراحی Locator، انتظار، Oracle و Evidence را.

اتوماسیون تست بدون کد می‌تواند ورود به Automation را سریع‌تر و مشارکت Domain expert را بیشتر کند؛ اما Codeless، Low-code، Record/Playback، Visual Flow، Model-based و AI-assisted یک چیز نیستند. انتخاب درست با تعداد بلوک‌ها یا کیفیت Demo مشخص نمی‌شود؛ باید تغییرپذیری محصول، False Pass/False Fail، نگهداشت، Git/Review، CI، امنیت، هزینه اجرا و امکان خروج را در PoC واقعی اندازه گرفت.

این راهنما رتبه‌بندی فروشنده نیست. نام ابزارها فقط برای توضیح الگوها و خواندن مستندات رسمی آمده‌اند. قابلیت، Plan، قیمت، Region، License، محدودیت Agent و دسترسی تجاری ممکن است تغییر کند؛ تصمیم نهایی را با Tenant آزمایشی، Dataset خودتان و قرارداد روز بگیرید.

پاسخ کوتاه: آیا اتوماسیون تست بدون کد واقعاً کار می‌کند؟

بله، اگر مسئله با Abstraction ابزار جور باشد، Flowها قابل بازبینی باشند، Testability محصول مناسب باشد و تیم برای Data، Oracle، CI و نگهداشت مالک مشخص داشته باشد. خیر، اگر انتظار دارید Recording خام به‌تنهایی یک Regression suite پایدار، امن و قابل‌حسابرسی بسازد.

معیار موفقیت این نیست که «یک تست بدون نوشتن کد ساخته شد». معیار بهتر این است که یک Portfolio نماینده، پس از تغییرهای عمدی و خطاهای واقعی، Verdict درست بدهد؛ تعمیرش قابل توضیح باشد؛ در Pipeline تکرارپذیر اجرا شود؛ و Artifact آن بدون وابستگی پنهان قابل Review و Export باشد.

اتوماسیون تست بدون کد چیست؟

Codeless Test Automation روشی برای ساخت Action، Data، Condition و Assertion از طریق Recorder، فرم، Keyword، مدل یا Canvas بصری است؛ بدون اینکه بیشتر کاربران برای مسیر عادی الزاماً Source code بنویسند. بااین‌حال Runtime، Driver، Locator engine، Agent، API و Extension زیر آن همچنان نرم‌افزارند.

مرز No-code و Low-code استاندارد رسمی ندارد

این دو واژه بیشتر برچسب بازارند تا Classification فنی. ابزاری ممکن است مسیر ساده را بصری بسازد، اما برای Loop پیچیده، API helper، Custom locator، Data setup یا Assertion اختصاصی به JavaScript، Groovy، Python یا Plugin نیاز داشته باشد. آن را در PoC بر اساس «درصد سناریوهای نیازمند Escape hatch» طبقه‌بندی کنید، نه نام صفحه محصول.

Record کردن با Test کردن یکی نیست

Recorder می‌تواند Interaction را Capture کند؛ Test علاوه بر Action به هدف، Precondition، داده کنترل‌شده، Expected outcome، Oracle مستقل، Cleanup و Evidence نیاز دارد. اگر فقط Login، Click و Toast ضبط شود، ممکن است Workflow اجرا شود اما اثر کسب‌وکاری غلط یا ناقص بماند.

شش خانواده ابزار را از هم جدا کنید

خانواده Artifact اصلی مزیت محتمل ریسک اصلی
Record/Playback گام و Locator ضبط‌شده شروع سریع و آموزش رفتار Flow خطی و Selector شکننده
Code Generator کد تولیدشده Bootstrap سریع با مسیر خروج به کد توهم آماده‌بودن خروجی خام
Keyword/Data-driven Low-code Keyword، Object repository و Data Reuse و مشارکت Tester پیچیدگی پنهان در Keyword سفارشی
Visual Flow Block/Connector/Subflow خوانایی برای نقش‌های متنوع Diff/Merge و Canvas بزرگ
Model-based Module/Model و Instance جداسازی منطق کسب‌وکار از اطلاعات فنی هزینه طراحی و Governance مدل
AI-assisted/Self-healing Flow به‌علاوه مدل Locator/Generation کاهش بخشی از Authoring/Repair تغییر بی‌صدا و False Pass

برای نمونه، مستندات رسمی Selenium IDE Runner نشان می‌دهد پروژه ضبط‌شده را می‌توان از خط فرمان و روی Grid اجرا کرد؛ این قابلیت با کیفیت معماری Flow یکسان نیست. Playwright Codegen نیز Action و Locator تولید می‌کند، اما خود مستند می‌گوید Locator تولیدشده را می‌توان ویرایش کرد؛ Codegen یک نقطه شروع کدنویسی است، نه محصول No-code.

در خانواده Low-code، Katalon Web Recorder Action و Object را Capture می‌کند و امکان استفاده از Keyword سفارشی دارد. در Model-based، مستند Tosca Modules Module را محل اطلاعات فنی و TestStep را مصرف‌کننده قابل‌استفاده‌مجدد آن معرفی می‌کند. در Visual Flow، Leapwork Flow Design منطق و Data flow را با Block و Connector می‌سازد و Version history را توضیح می‌دهد.

این مثال‌ها اثبات برتری یا تناسب نیستند؛ فقط نشان می‌دهند «بدون کد» چند معماری متفاوت دارد. نام محصول را پس از انتخاب خانواده مناسب وارد Shortlist کنید.

بدون کد یعنی بدون مهندسی نیست

پیچیدگی حذف نمی‌شود؛ جابه‌جا می‌شود:

  • از Syntax به ساختار Flow و قرارداد Component؛
  • از Page Object به Object repository یا Module؛
  • از Explicit code به تنظیم Wait، Retry و Error handling؛
  • از Function به Keyword/Subflow قابل‌استفاده‌مجدد؛
  • از Pull Request متنی به Review تصویری یا Artifact اختصاصی؛
  • از Package dependency به Agent/Plugin/Browser compatibility؛
  • از Runtime متن‌باز به License، Cloud minutes و Vendor lifecycle؛
  • از Debugger کد به Screenshot، DOM، Log، Network و Vendor trace.

اگر این لایه‌ها Owner، Naming، Review و Change control نداشته باشند، Citizen development به Repository بزرگی از Duplicate flow و Shared stepهای ناامن تبدیل می‌شود.

مرز این مقاله با راهنماهای دیگر

راهنمای اتوماسیون تست مالک تصمیم «چه چیزی را چرا خودکار کنیم» است. راهنمای انتخاب فریم‌ورک اتوماسیون معماری و PoC عمومی Framework را پوشش می‌دهد. مقاله حاضر فقط یک تصمیم را عمیق می‌کند: آیا Abstraction بدون کد/کم‌کد در تغییرات واقعی، Verdict قابل‌اعتماد و نگهداشت اقتصادی می‌دهد؟ برای Procurement، امنیت تأمین‌کننده، TCO و قرارداد خروج نیز از راهنمای انتخاب ابزار مدیریت تست به‌عنوان چارچوب مادر استفاده کنید.

چه زمانی No-code، Hybrid یا Code-first مناسب‌تر است؟

وضعیت گزینه محتمل شرط
Journeyهای پایدار، فرم‌محور و تکراری No-code/Model-based Oracle و CI مستقل تأیید شوند
Domain expert قوی، مهارت کدنویسی محدود Visual/Keyword Automation engineer برای Architecture/Review باشد
سناریوهای عادی بصری و چند Edge پیچیده Hybrid Low-code Escape hatch رسمی، Testable و Governed باشد
UI بسیار پویا، Protocol سفارشی یا Algorithm پیچیده Code-first Testability و Library کنترل‌پذیر لازم است
Desktop/SAP/Legacy چندفناوری Model/Visual تخصصی Compatibility در محیط واقعی ثابت شود
تیم مهندسی قوی و Review/Merge پرتعداد Code-first یا Hybrid سرعت Authoring تنها معیار نباشد
کار کوتاه‌عمر یا Prototype Recorder/Codegen Artifact موقت و تاریخ حذف داشته باشد

برای تیم تازه‌کار، ابزار بصری جای مهارت تست را نمی‌گیرد. نقشه راه QA Automation را برای HTTP، DOM، Locator، Git، CI و Debug به‌عنوان دانش پایه نگه دارید؛ کسی که Flow می‌سازد باید بتواند شکست محصول را از شکست Harness تشخیص دهد.

Problem Brief را پیش از Demo بنویسید

در یک صفحه این موارد را ثبت کنید:

  1. Product surface: Web، Mobile، Desktop، API، SAP، PDF یا Email؛
  2. Top journeys: پنج تا ده مسیر با Risk و Frequency؛
  3. Change profile: تغییر DOM، Copy، Design system، API و Release cadence؛
  4. Current baseline: زمان Authoring، Flake، Repair، Pipeline و Manual effort؛
  5. Team: Author، Reviewer، Runner operator و Platform owner؛
  6. Environments: Local، CI، Staging، Private network و Device lab؛
  7. Evidence: چه Verdict و Artifactی برای Release لازم است؛
  8. Constraints: Security، Region، License، Procurement و Deadline؛
  9. Non-goals: چه چیزی قرار نیست با UI یا No-code حل شود؛
  10. Success: معیار عددی در ۳۰/۹۰ روز.

مثال هدف قابل‌اندازه‌گیری: «ده Journey پرریسک Checkout در Chrome/Firefox، با کمتر از ۲٪ False alarm در ۳۰ اجرای تکراری، Median repair زیر ۲۰ دقیقه پس از سه تغییر عمدی، Evidence قابل لینک در CI و حداکثر ۱۵٪ Step نیازمند Custom code.»

Hard Gateهای ابزار Codeless را جدا کنید

شکست Hard gate با امتیاز بالای Recorder یا Dashboard جبران نمی‌شود:

  • پشتیبانی واقعی از Technology/Browser/Device و Versionهای شما؛
  • اجرای Headless/CLI/API در Runner خصوصی یا Cloud موردقبول؛
  • مدیریت Secret بدون Plain text در Flow/Log/Export؛
  • Locator قابل مشاهده و کنترل، با Failure امن در ابهام؛
  • Assertion و API/DB hook لازم برای Oracle بحرانی؛
  • Artifact قابل Review، Version، Backup و Restore؛
  • Branch/Parallel authoring بدون Lost update غیرقابل‌قبول؛
  • Evidence کافی برای Debug و Audit؛
  • API/CI integration با Error/Retry semantics روشن؛
  • Export کامل Test/Data/Result/Attachment یا Exit پذیرفتنی؛
  • دسترسی قانونی، تجاری و عملیاتی پایدار برای سازمان؛
  • TCO زیر سقف تصویب‌شده در Concurrency و حجم واقعی.

برای سازمان ایرانی، Availability را ادعا نکنید؛ Verify کنید

وجود دکمه Sign up به معنی امکان استفاده پایدار نیست. پیش از Shortlist، Legal/Procurement باید Terms، Export-control، کشور حساب، روش پرداخت، Tax/Invoice، Download/Activation، Cloud region، پشتیبانی، Renewal و انتقال License را بررسی کند. Network team نیز Latency، DNS/TLS، Agent callback، Update server، CDN و Tunnel به محیط خصوصی را در همان شبکه واقعی آزمایش کند.

این بخش مشاوره حقوقی نیست و وضعیت فروشنده/تحریم/پرداخت ممکن است تغییر کند. نتیجه را با تاریخ، منبع، Account آزمایشی و مالک ریسک ثبت کنید. از دورزدن کنترل‌های قراردادی یا فنی به‌عنوان Architecture استفاده نکنید.

PoC باید Dataset و تغییر نماینده داشته باشد

یک Login ساده فقط Happy path Recorder را می‌سنجد. Dataset پیشنهادی:

  • دو Journey عادی و دو Journey منفی با Oracle کسب‌وکاری؛
  • Component مشترک مانند Login، Search و Checkout؛
  • یک iframe، Upload/Download، جدول پویا یا Shadow DOM در صورت کاربرد؛
  • تأخیر تصادفی، Animation، Loading و Eventual consistency؛
  • داده Unicode/RTL و مقدار Null/Boundary/Invalid؛
  • Browser/Device و Environmentهای واقعی؛
  • Secret، Test data setup و Cleanup؛
  • API یا DB check برای اثر نهایی؛
  • یک Failure زیرساخت و یک Failure محصول؛
  • تغییر عمدی Locator، Label، Layout و Business rule.

اسکریپت دو هفته‌ای PoC

  1. Baseline دستی/فعلی و Expected verdict هر Fixture را Freeze کنید.
  2. هر Candidate را با تیم خریدار و Dataset یکسان راه‌اندازی کنید.
  3. ده Flow را از صفر بسازید؛ زمان فعال Authoring را ثبت کنید.
  4. Component/Data/Environment را بدون Copy/Paste استخراج کنید.
  5. در Local و CI روی دو Browser/Agent اجرا کنید.
  6. ۳۰ Repeat با ترتیب تصادفی بگیرید و First-attempt result را حفظ کنید.
  7. DOM، Label، Timing، Failure و Business effect را عمداً تغییر دهید.
  8. False Pass، False Fail، Inconclusive و Root cause را مستقل برچسب بزنید.
  9. Flow مشترک را هم‌زمان در دو Branch/Workspace تغییر و Merge کنید.
  10. Secret rotation، Agent offline، API rate limit و License exhaustion را امتحان کنید.
  11. یک فرد دوم فقط با Artifactها Failure را Debug کند.
  12. Full export، Restore و اجرای حداقلی پس از خروج را تمرین کنید.
  13. امتیازها را فقط با Evidence ID و Rubric ثبت کنید.
  14. نتیجه را با TCO، Residual risk و Owner تصمیم ببندید.

Locator را به‌عنوان قرارداد Testability بسنجید

Selector تولیدشده را مخفی نکنید. برای هر Step باید معلوم باشد Target چگونه شناسایی می‌شود، چند Element Match شده، کدام Attributeها پایدارند و در Ambiguity چه رخ می‌دهد. اولویت عمومی چنین است:

  1. قرارداد کاربرمحور: Role، Label، Accessible name؛
  2. قرارداد تست صریح مانند Test ID پایدار؛
  3. رابطه Domain/Component با Scope روشن؛
  4. CSS/XPath کوتاه و کنترل‌شده در صورت اجبار؛
  5. Position، Class تزئینی یا XPath مطلق فقط با Risk پذیرفته‌شده.

راهنمای رسمی Locatorهای Playwright استفاده از Attributeهای کاربرمحور و قراردادهای صریح را برای پایداری پیشنهاد می‌کند. این یک Benchmark کدنویسی مفید برای PoC بصری است: آیا Candidate هم Target را خوانا، Unique و قابل Scope می‌سازد یا فقط XPath طولانی تولید می‌کند؟

Semantic locator هم مصون از تغییر نیست

ترجمه متن، تغییر Accessible name یا دو CTA هم‌نام می‌تواند Locator معنایی را بشکند. شکست آشکار در Target مبهم معمولاً بهتر از Click خودکار روی نزدیک‌ترین Element است. قرارداد نام‌گذاری، Test ID و Accessibility را Product/Dev/QA مشترکاً مدیریت کنند.

Wait و Retry را از Fixed Sleep جدا کنید

ابزار باید برای Visible، Stable، Enabled، Receives-event و اثر موردانتظار Condition-based wait داشته باشد. مستند Actionability و Auto-waiting پلی‌رایت نمونه‌ای شفاف از Checkهای پیش از Action و Assertionهای retryable ارائه می‌دهد؛ Candidate باید رفتار معادل خود را با Timeout، Log و علت Failure نشان دهد.

  • Sleep ثابت، زمان را هدر می‌دهد و Race را فقط جابه‌جا می‌کند؛
  • Retry بی‌قید، اولین Failure و Flake واقعی را پنهان می‌کند؛
  • Wait روی Spinner کافی نیست اگر اثر Backend هنوز Commit نشده باشد؛
  • Timeout باید به SLO/Contract مرتبط و در Artifact قابل مشاهده باشد؛
  • First attempt، Retry attempts و Final verdict را جدا ذخیره کنید.

Self-healing را با False Pass آزمایش کنید

Self-healing می‌تواند Repair locator را کم کند، اما سؤال بحرانی این است: آیا هنوز همان Intent را اجرا می‌کند؟ در مستند Auto Improve در Testim تغییر Locator با Revision و علامت Step قابل مشاهده می‌شود. چنین Provenanceای را در هر Candidate بخواهید: قبل/بعد Locator، Confidence، زمان تغییر، Run مؤثر، Approver و امکان Rollback.

قواعد Fail-safe پیشنهادی

  • برای Payment، Delete، Permission و Approval، Healing بدون Review را غیرفعال کنید؛
  • اگر بیش از یک Target معتبر است، Fail یا Inconclusive بدهید؛
  • Healing نباید Assertion یا Business outcome را تغییر دهد؛
  • تغییر خودکار فقط در Branch/Revision قابل بازبینی ثبت شود؛
  • نرخ Healing، Rollback و Wrong-target را Metric کنید؛
  • مدل/Telemetry ارسالی، Retention و Data boundary را Security بررسی کند.

راهنمای هوش مصنوعی در تست نرم‌افزار مرز پیشنهاد AI و Evidence مستقل را عمیق‌تر توضیح می‌دهد. Prompt یا Confidence بالا Oracle نیست.

Oracle مهم‌تر از Recorder است

برای هر Journey، خروجی را در چند لایه تعریف کنید:

  • UI: وضعیت، پیام، Row یا Navigation درست؛
  • API: Status و Payload با Semantic درست؛
  • State: Order/Payment/Inventory دقیقاً یک‌بار تغییر کرده؛
  • Side effect: Event/Email/Ledger موردنیاز ایجاد شده؛
  • Absence: Duplicate charge، Secret leak یا رکورد اضافی وجود ندارد؛
  • Time: اثر در Window قراردادی قابل مشاهده است.

Toast موفقیت فقط Observation رابط است. برای طراحی Source، Comparator، Tolerance و Verdict سه‌حالته به راهنمای Test Oracle رجوع کنید. یک Tool عالی با Oracle ضعیف، False Pass را سریع‌تر تولید می‌کند.

آزمایش اجرایی: Recorder خام در برابر Flow معنایی

برای قابل‌لمس‌شدن معیارها، یک شبیه‌سازی قطعی با Node.js ۲۴.۱۸.۰ ساختیم. پنج Fixture نماینده همان Checkout فرضی‌اند: Baseline، تغییر ID، دو CTA هم‌نام، دیر Enabled شدن و Toast بدون ساخته‌شدن Order. Expected verdict پیش از اجرای Flow ثبت شد.

Recorder فرضی با #pay-now، یک Tick انتظار ثابت و Assertion روی Toast کار می‌کند. Flow معنایی Target یکتای role=button/name=پرداخت را می‌خواهد، تا چهار Tick Enabled شدن را Condition-based صبر می‌کند و ایجاد Order را Oracle نهایی می‌گیرد. این کد موتور هیچ Vendorی را شبیه‌سازی نمی‌کند؛ یک Mutation harness برای طراحی PoC است.

const fixtures = [
  { name: "v1_baseline", expected: "pass", id: "pay-now", count: 1, enabledAt: 0, order: true },
  { name: "v2_dom_refactor", expected: "pass", id: "checkout-submit", count: 1, enabledAt: 0, order: true },
  { name: "v3_ambiguous_cta", expected: "fail", id: "pay-now", count: 2, enabledAt: 0, order: true },
  { name: "v4_async_enable", expected: "pass", id: "pay-now", count: 1, enabledAt: 3, order: true },
  { name: "v5_missing_business_effect", expected: "fail", id: "pay-now", count: 1, enabledAt: 0, order: false },
]

function recorder(f) {
  if (f.id !== "pay-now") return ["fail", "selector_not_found"]
  if (f.enabledAt > 1) return ["fail", "fixed_wait_expired"]
  return ["pass", "ui_toast_only"]
}

function semantic(f) {
  if (f.count !== 1) return ["fail", "ambiguous_target"]
  if (f.enabledAt > 4) return ["fail", "condition_timeout"]
  if (!f.order) return ["fail", "order_not_created"]
  return ["pass", "business_oracle_satisfied"]
}

خروجی واقعی آزمایش

fixture expected recorder semantic
v1_baseline pass pass(ui_toast_only;correct) pass(business_oracle_satisfied;correct)
v2_dom_refactor pass fail(selector_not_found;false_fail) pass(business_oracle_satisfied;correct)
v3_ambiguous_cta fail pass(ui_toast_only;false_pass) fail(ambiguous_target;correct)
v4_async_enable pass fail(fixed_wait_expired;false_fail) pass(business_oracle_satisfied;correct)
v5_missing_business_effect fail pass(ui_toast_only;false_pass) fail(order_not_created;correct)
recorder correct=1/5 false_pass=2 false_fail=2
semantic correct=5/5 false_pass=0 false_fail=0

این نتیجه چه چیزی را ثابت نمی‌کند؟

این Sample کوچک، عملکرد هیچ ابزار واقعی، سرعت Team یا نرخ خرابی Production را ثابت نمی‌کند. احتمال‌ها و UI واقعی شبیه‌سازی نشده‌اند. نتیجه فقط نشان می‌دهد PoC باید Expected verdict و Mutationهای Locator/Timing/Ambiguity/Business effect داشته باشد؛ اگر فقط Baseline اجرا شود، هر دو رویکرد سبز دیده می‌شوند.

Maintainability را با تغییر عمدی اندازه بگیرید

پس از سبزشدن اولیه، این Mutationها را تزریق کنید:

  1. ID/Class/DOM nesting را بدون تغییر رفتار عوض کنید؛
  2. Label انگلیسی را فارسی و ترتیب RTL را اصلاح کنید؛
  3. Component را به iframe یا Shadow root منتقل کنید؛
  4. Loading را از ۱۰۰ میلی‌ثانیه به توزیع ۰٫۲ تا ۴ ثانیه ببرید؛
  5. دو Element مشابه ایجاد کنید؛
  6. API موفق با Toast موفق ولی Commit ناقص برگردانید؛
  7. Shared login یا Checkout component را یک‌بار تغییر دهید؛
  8. Browser/Agent را Upgrade کنید؛
  9. Environment variable و Secret را Rotate کنید؛
  10. یک Dependency را Timeout یا Rate-limit کنید.

برای هر Mutation، Time-to-detect، Verdict accuracy، تعداد Asset آسیب‌دیده، Active repair time، Review time و Re-run را ثبت کنید. «Self-healed» بودن فقط یک Event است؛ باید معلوم شود درست Heal شده یا نه.

Reuse را با Blast Radius بسنجید

Subflow/Module مشترک Duplication را کم می‌کند، اما تغییر آن می‌تواند صدها Test را بشکند. هر Component باید Contract، Version، Owner، Consumer list، Compatibility rule و Deprecation window داشته باشد. تغییر Breaking ابتدا روی Consumerهای منتخب و سپس کل Suite اجرا شود.

نسبت Shared step بالا لزوماً خوب نیست. یک Login component عمومی که Role، MFA، Locale و Environment را در Conditionهای تو در تو پنهان کرده، ممکن است از چند Component کوچک دشوارتر باشد.

Git، Diff، Merge و Review را روی Artifact واقعی امتحان کنید

علامت Git integration کافی نیست. مستند Git در Katalon Studio نمونه‌ای از اتصال پروژه به Git است؛ در PoC خودتان باید کیفیت Artifact را بسنجید:

  • آیا Diff می‌گوید کدام Action/Locator/Expected تغییر کرده؟
  • فایل Binary/Generated noise دارد یا Review انسانی ممکن است؟
  • دو Author می‌توانند یک Flow مشترک را بدون Lost update Merge کنند؟
  • Rename/Move تاریخچه را حفظ می‌کند؟
  • Secret یا Token وارد Repository/Export نمی‌شود؟
  • Rollback دقیق Flow، Object و Data ممکن است؟
  • Branch protection و Approval واقعاً enforce می‌شود؟

اگر Versioning داخل Vendor است، Export دوره‌ای و Restore test را هم بخواهید. Screenshot نسخه جای Diff معنایی را نمی‌گیرد.

CI/CD باید First-class باشد، نه دکمه Run

Runner باید با Exit code درست، Environment/Secret injection، Tag/filter، Timeout، Parallelism، Retry policy، Artifact upload و Result API در Pipeline کار کند. مستند REST API در Leapwork نمونه‌ای از Trigger و دریافت Result برای CI/CD است؛ PoC باید Error path، Authentication، API version و Controller/Agent failure را نیز اجرا کند.

برای طراحی Stage، Rule، Artifact و Failure handling از راهنمای تست خودکار در GitLab CI استفاده کنید. هیچ تست UI پرهزینه‌ای نباید بدون Strategy روی هر Commit کپی شود: Smoke سریع در PR، Regression موازی در Nightly و Journeyهای Release-critical در Gate مناسب قرار گیرند.

Concurrency را با License واقعی بسنجید

گاهی Parallel execution از نظر فنی ممکن است اما License seat/agent/cloud-minute محدودش می‌کند. Queue time، Warm-up، Agent provisioning، Browser startup، Artifact upload و Retry هزینه Pipeline را می‌سازند. آزمایش را با Concurrency قراردادی انجام دهید، نه Trial ویژه Demo.

Flake را با Retry سبز نشویید

برای هر Attempt این طبقه‌بندی را نگه دارید: Product failure، Harness/locator، Test data، Environment/dependency، Infrastructure، Allowed nondeterminism یا Evidence ناکافی. First-attempt failure از Final pass حذف نشود. راهنمای تست سیستم‌های غیرقطعی برای Seed، Repeat، Confidence و Verdict سه‌حالته چارچوب دقیق‌تری می‌دهد.

Metric مناسب شامل First-attempt pass rate، Retry recovery rate، Unique flaky tests، Mean/median repair و Quarantine age است. Pass rate نهایی پس از سه Retry می‌تواند یک Suite غیرقابل‌اعتماد را سالم نشان دهد.

Test Data و Secret را بخشی از Flow نکنید

  • Credential، Token، National ID و Card data در Step/Log/Screenshot Plain text نباشد؛
  • Test data با ID یکتا Provision و در پایان Reconcile/Cleanup شود؛
  • Environment-specific value از Configuration کنترل‌شده بیاید؛
  • Parallel run روی Account/Order مشترک Race نسازد؛
  • Masked Production data فقط با مجوز، Minimization و Retention روشن استفاده شود؛
  • Fixture version به Run manifest پیوند بخورد؛
  • Failure قبل از Cleanup، Orphan data را با Job جبرانی جمع کند.

Debuggability را به یک همکار ناآشنا بسپارید

Author نباید تنها کسی باشد که Failure را می‌فهمد. Evidence مطلوب شامل Step timeline، resolved locator، DOM/Accessibility snapshot، Screenshot/Video، Console، Network، API correlation ID، Environment/Agent/Browser version، Data ID، Retry history و تغییر Self-healing است. یک Reviewer دوم باید فقط با این بسته، Failure layer و اقدام بعدی را در زمان هدف تعیین کند.

ضبط Video دائمی می‌تواند PII/Secret را نشت دهد و Storage را گران کند. Capture را Risk-based، Masked و دارای Retention بسازید؛ Evidence بیشتر همیشه Evidence بهتر نیست.

Security و Privacy را در Runtime واقعی بررسی کنید

Data flow را رسم کنید: Author machine→Repository/Cloud→Controller→Agent→Browser/Device→AUT→Artifact store→Analytics/AI. برای هر مرز، Data class، Encryption، Identity، Role، Retention، Region، Subprocessor، Audit و Delete/Export را مشخص کنید.

سؤال‌های Security PoC

  • SSO/MFA/RBAC و Service account چگونه اعمال می‌شوند؟
  • Author می‌تواند Secret را ببیند یا فقط Reference می‌گذارد؟
  • Agent با چه Privilege و Network egressی اجرا می‌شود؟
  • Plugin/Extension چگونه Signed، Updated و Audited است؟
  • Screenshot/DOM/Prompt/Log به Cloud یا مدل AI ارسال می‌شود؟
  • Tenant، Project و Environment isolation چگونه تست می‌شود؟
  • Delete و Retention شامل Backup/Artifact/Model data می‌شود؟
  • Audit log چه Eventهایی را ثبت و چه کسی می‌تواند تغییر دهد؟
  • API key rotation و Revocation در Run فعال چه رفتاری دارد؟
  • Vendor incident یا Agent compromise چه Runbookی دارد؟

گواهی یا صفحه Trust جای Threat model و Tenant test را نمی‌گیرد. برای Flow پرداخت، امکان مشاهده Secret یا تغییر Assertion توسط نقش نامجاز را عمداً آزمایش و Audit event را Reconcile کنید.

Escape hatch را مزیت مطلق حساب نکنید

Custom code انعطاف می‌دهد، اما Surface نگهداشت، Dependency، Security و Skill را برمی‌گرداند. برای هر Extension ثبت کنید:

  • چرا Block/Keyword استاندارد کافی نبود؛
  • Language/runtime/version و Dependencyها؛
  • Unit test و Contract test؛
  • Input/output/error semantics؛
  • Secret/PII boundary؛
  • Owner، Reviewer و Upgrade policy؛
  • Fallback و Removal condition.

نسبت Flowهای نیازمند Custom code، تعداد Extensionهای بدون تست و Failureهای ناشی از آن‌ها را بسنجید. اگر بیشتر Journeyهای بحرانی از Escape hatch عبور می‌کنند، شاید ابزار فقط یک IDE پیچیده‌تر دور کد ساخته باشد.

Performance، Scale و Cost را با Unit واقعی محاسبه کنید

«تعداد تست» واحد کافی نیست. طول Journey، Browser/Device، Video، Data setup، Retry، Parallelism و Agent startup روی هزینه اثر دارند. Run mix ماهانه را بسازید:

Monthly execution cost =
  cloud minutes
  + private agents/infrastructure
  + author/reviewer/admin seats
  + artifact storage and retention
  + integration and support
  + failed-run investigation
  + upgrade and exit reserve

سپس Load کوچک و نماینده بگیرید: ۱۰، ۵۰ و ۲۰۰ Flow با همان Browser mix و Artifact policy. Queue، P50/P95 duration، Failure under concurrency، Agent saturation، API rate limit و Cost per trusted verdict را ثبت کنید. هدف، سریع‌ترین Runner نیست؛ Verdict قابل‌اعتماد با هزینه پذیرفتنی است.

Exit را قبل از ورود تمرین کنید

Full export باید بیش از نام Test باشد. این اقلام را Sample و Count کنید:

  • Folder/tag/requirement relation و Test metadata؛
  • Step، Locator/Object/Module و Shared component؛
  • Data set، Environment config بدون Secret value؛
  • Custom keyword/code و Dependency manifest؛
  • Result، Attempt، Screenshot/Video/Log و Audit history؛
  • User/owner/approval و Version history؛
  • Stable external ID و Timestamp/encoding؛
  • API schema، pagination و rate-limit behavior.

Export را Parse کنید، Count/Hash و Relationها را Reconcile کنید، سه Flow را در مقصد یا Harness مستقل بازسازی و زمان/اتلاف را ثبت کنید. PDF Report خروج داده نیست. Backup اختصاصی Vendor نیز تا وقتی Restore مستقل یا قراردادی اثبات نشده، Exit نیست.

Scorecard ارزیابی ابزار بدون کد

پس از عبور از Hard gate، Weightها را پیش از دیدن نتیجه Freeze کنید. نمونه برای یک تیم Web/Mobile:

محور وزن Evidence موردنیاز
Verdict accuracy و Oracle ۱۸ Mutation run و False Pass/Fail
Maintainability ۱۵ Repair time و Blast radius
Technology fit ۱۲ Journeyهای سخت روی محیط واقعی
CI/Execution/Scale ۱۰ Pipeline، concurrency و failure path
Version/Review/Collaboration ۱۰ Diff، Merge و Rollback exercise
Debug/Evidence ۸ Second-person diagnosis
Security/Privacy ۱۰ Tenant/role/secret/audit test
Extensibility ۵ Escape-hatch implementation
Exit/Portability ۵ Export/restore/rebuild rehearsal
TCO/Commercial access ۷ سه‌سال هزینه و دسترسی Verifyشده

Rubric صفر تا پنج

  • ۰: ناموجود یا Hard gate شکست‌خورده؛
  • ۱: ادعای فروشنده/اسلاید بدون اجرای Buyer؛
  • ۲: Happy path محدود با Workaround سنگین؛
  • ۳: سناریوی نماینده Pass با محدودیت مستند؛
  • ۴: Failure/change/scale هم Pass و Evidence قابل Review؛
  • ۵: چندمحیطی، تکرارپذیر، Governed و Exit آزموده‌شده.

امتیاز ۴٫۶ نباید شکست Secret management یا Wrong-target healing را پنهان کند. Gate ابتدا، Weighted score بعد، Residual risk و Decision owner در انتها.

Sensitivity analysis جلوی وزن‌سازی برای برنده را می‌گیرد

سه سناریوی وزن بسازید: سرعت Authoring، Reliability/Control و Cost. اگر Winner با تغییر کوچک وزن عوض می‌شود، تصمیم Fragile است؛ Contract کوتاه‌تر، Pilot محدودتر یا Evidence بیشتر لازم دارید. اگر یک Candidate فقط با حذف هزینه Admin برنده می‌شود، TCO ناقص است.

Score خام را کنار Confidence نگه دارید. امتیاز ۴ با پنج Run Demo برابر امتیاز ۴ با ۳۰ Run، سه Mutation و دو Reviewer نیست. Evidence quality، Sample size و تاریخ را به هر Cell پیوند دهید.

مثال PoC برای Checkout ایرانی

یک فروشگاه فرضی با پرداخت داخلی را در نظر بگیرید. هدف فقط Click روی «پرداخت» نیست؛ باید این قراردادها سنجیده شوند:

  • نمایش و Parse رقم فارسی، عربی و لاتین؛
  • تومان در UI و ریال Canonical در API/Ledger؛
  • RTL، Accessible name و دو CTA عادی/اقساطی؛
  • Redirect به PSP و بازگشت با Success/Decline/Cancel؛
  • Timeout پیش و پس از Commit؛
  • Callback تکراری، دیررس و خارج از ترتیب؛
  • Refresh/Back/Double-click بدون Duplicate charge؛
  • تاریخ تهران/UTC و مرز روز؛
  • Order، Payment، Inventory و Ledger قابل Reconcile؛
  • Network profile داخل ایران و Agent در محیط خصوصی.

هشت Mutation اجباری مثال

  1. ID دکمه عوض شود، Accessible contract ثابت بماند؛
  2. دو دکمه نام یکسان پیدا کنند؛
  3. Enabled شدن بین ۰٫۲ تا ۴ ثانیه متغیر شود؛
  4. Toast بیاید اما Order ثبت نشود؛
  5. PSP پس از Commit Timeout کند؛
  6. Callback دوبار و با فاصله برسد؛
  7. مبلغ تومان/ریال ده‌برابر اشتباه نمایش یابد؛
  8. رقم عربی و نیم‌فاصله در نام/آدرس وارد شود.

Flow قابل‌اعتماد باید در Mutation دوم Fail-safe، در سوم Condition-based، در چهارم با Oracle Backend Fail و در پنجم/ششم با Idempotency/Reconciliation Verdict درست بدهد. Screenshot سبز به‌تنهایی Evidence پرداخت نیست.

Operating Model تیم را طراحی کنید

نقش مسئولیت
Domain/Test designer Risk، Scenario، Data و Expected outcome
Automation engineer Architecture، Component، Locator، CI و Extension
Developer Testability contract، API hook و Root cause
Platform owner Agent، Upgrade، License، Backup و Access
Security/Privacy Data flow، Secret، Role، AI و Retention
Reviewer Intent، Oracle، Diff و Evidence
Decision owner Residual risk، TCO و ادامه/توقف Pilot

Citizen tester باید امکان ساخت داشته باشد، نه اختیار بی‌مرز انتشار. Template، Approved component، Naming، Review threshold و Production-like access را بر اساس Risk سطح‌بندی کنید.

Definition of Done برای یک Flow

  • هدف/Risk و Owner دارد؛
  • Precondition/Data/Cleanup مشخص است؛
  • Locator خوانا، Unique و دارای Contract است؛
  • Wait شرطی و Timeout دلیل‌دار است؛
  • Oracle اثر کسب‌وکاری را می‌سنجد؛
  • Failure محصول و Harness قابل تفکیک است؛
  • Local و CI اولین‌بار Pass شده‌اند؛
  • حداقل یک Mutation مرتبط را پشت سر گذاشته؛
  • Artifact بدون Secret/PII غیرضروری است؛
  • Reviewer مستقل تأیید کرده؛
  • Tag/Lane/Retry/Quarantine policy دارد؛
  • Dependency و تاریخ Review بعدی ثبت است.

متریک‌های سالم و Guardrailها

  • Median active authoring time برای Scenario نماینده؛
  • Verdict accuracy روی Fixtureهای ازپیش‌برچسب‌خورده؛
  • False Pass و False Fail به‌تفکیک Layer؛
  • First-attempt pass و Retry recovery؛
  • Median/P90 repair time پس از Mutation؛
  • Blast radius هر Shared component؛
  • درصد Step با Fixed sleep، brittle locator یا Oracle UI-only؛
  • درصد Flow نیازمند Custom code؛
  • Wrong-target/Healing review/rollback rate؛
  • Pipeline queue/duration و Cost per trusted verdict؛
  • Second-person diagnosis time؛
  • Quarantine age و Ownerless assets؛
  • Export completeness و Restore success.

تعداد Testهای ساخته‌شده و Pass rate نهایی به‌تنهایی قابل بازی‌اند. اگر Author برای رشد Coverage هزار Flow کم‌ارزش ضبط کند یا Retry همه‌چیز را سبز کند، Dashboard موفق و محصول بی‌اطمینان می‌شود.

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

روز ۱ تا ۵: قرارداد و Baseline

Problem brief، Hard gate، ده Journey، Fixture، Expected verdict، Data classification، Team، Metric و Weight را Freeze کنید. Access تجاری/فنی و شبکه واقعی را Verify کنید.

روز ۶ تا ۱۲: ساخت Buyer-operated

Candidateها را با Dataset یکسان بسازید. زمان فعال را جدا از آموزش/Vendor help ثبت کنید. Component، Data، Environment، Oracle و CI را ایجاد کنید؛ Video Demo فروشنده Evidence اصلی نباشد.

روز ۱۳ تا ۲۰: تغییر و شکست

۳۰ Repeat، Browser/Agent دوم، ده Mutation، Retry، Self-healing، Agent offline، Secret rotation، Concurrent edit و Second-person debugging را اجرا کنید. First attempt را حفظ کنید.

روز ۲۱ تا ۲۶: Governance و Exit

Role، Review، Branch، Audit، Backup، Full export، Reconciliation و Rebuild حداقلی را امتحان کنید. License/Concurrency و TCO سه‌ساله را با Usage واقعی محاسبه کنید.

روز ۲۷ تا ۳۰: تصمیم

Gate، Score، Confidence، Sensitivity، Residual risk و Owner را مرور کنید. نتیجه می‌تواند Adopt، Hybrid، Extend pilot یا Reject باشد. Pilot شکست‌خورده که هزینه بزرگ‌تر را زود آشکار کند، خروجی موفق است.

۱۵ ضدالگو در اتوماسیون تست بدون کد

  1. انتخاب با کوتاه‌ترین Demo؛
  2. برابرگرفتن Record با Test design؛
  3. XPath مطلق و Position بدون Contract؛
  4. Fixed sleep به‌جای Condition؛
  5. Assertion فقط روی Toast/URL؛
  6. Self-healing بی‌Revision و Review؛
  7. Retry تا سبزشدن؛
  8. Copy/Paste Flow به‌جای Component محدود؛
  9. Shared component غول‌پیکر با Blast radius نامعلوم؛
  10. Plain-text Secret در Step/Log؛
  11. Binary artifact بدون Diff/Merge exercise؛
  12. CI روی License/Agent Trial؛
  13. Custom code بدون Unit test/Owner؛
  14. محاسبه TCO فقط با قیمت Seat؛
  15. خرید پیش از Full exit rehearsal.

چک‌لیست نهایی انتخاب

  • □ No-code/Low-code/Model/Recorder class روشن است.
  • □ Problem brief و Baseline عددی Freeze شده‌اند.
  • □ Hard gateها پیش از Demo تصویب شده‌اند.
  • □ دسترسی تجاری/فنی از ایران Verify شده است.
  • □ PoC با Dataset و Script یکسان Buyer-operated است.
  • □ Locator/Wait/Retry قابل مشاهده و کنترل‌اند.
  • □ Oracle فراتر از UI effect طراحی شده است.
  • □ Mutationهای DOM/Timing/Ambiguity/Business اجرا شده‌اند.
  • □ False Pass/False Fail و First attempt ثبت شده‌اند.
  • □ Self-healing Provenance و Fail-safe دارد.
  • □ Git/Diff/Merge/Review روی Artifact واقعی تست شده‌اند.
  • □ CLI/API/CI/Parallel/Agent failure اجرا شده‌اند.
  • □ Secret/Data/Artifact/AI boundary بررسی شده است.
  • □ Custom extension تست و Owner دارد.
  • □ Debug همکار دوم در زمان هدف ممکن است.
  • □ TCO با Run mix و Concurrency واقعی محاسبه شده است.
  • □ Full export/restore/rebuild Reconcile شده است.
  • □ Score/Confidence/Sensitivity/Residual risk ثبت‌اند.

سؤالات متداول اتوماسیون تست بدون کد

آیا ابزار بدون کد جایگزین Automation Engineer می‌شود؟

معمولاً نه. ممکن است Authoring مسیرهای عادی را به Tester/Domain expert نزدیک کند، اما Architecture، Locator contract، Oracle، Data، CI، Security، Debug، Upgrade و Governance همچنان مهارت مهندسی می‌خواهند. نقش Engineer از تایپ Step به طراحی سیستم Automation جابه‌جا می‌شود.

بهترین ابزار اتوماسیون تست بدون کد کدام است؟

پاسخ جهانی ندارد. بهترین Candidate باید Hard gateهای شما را پاس کند و روی Journey، تغییر، Failure، CI، Security و Exit خودتان Evidence بدهد. رتبه عمومی یا Feature count بدون Dataset نماینده تصمیم خرید نیست.

آیا Self-healing همیشه Flaky Test را کم می‌کند؟

می‌تواند بخشی از شکست Locator را کم کند، اما ممکن است Target اشتباه را انتخاب و False Pass بسازد. Provenance، Confidence، Ambiguity handling، High-risk opt-out، Review و Oracle مستقل لازم‌اند. Flake ناشی از Data، Environment یا Product race با Healing Locator حل نمی‌شود.

آیا Record and Playback برای Regression کافی است؟

برای Prototype یا مسیر کم‌ریسک شاید نقطه شروع باشد. Suite پایدار به Component، Data، Wait شرطی، Oracle، Failure classification، CI، Review و نگهداشت نیاز دارد. Recording خام را Generated draft تلقی کنید، نه Definition of Done.

چگونه بین No-code و Code-first تصمیم بگیریم؟

همان Scenarioها را در یک PoC محدود بسازید و Authoring، Verdict accuracy، Repair after change، Review/Merge، CI، Debug، Security، Escape-hatch share، TCO و Exit را مقایسه کنید. انتخاب Hybrid نیز معتبر است؛ Flow عادی می‌تواند بصری و Oracle/Setup پیچیده کدنویسی‌شده باشد، مشروط به Governance روشن.

جمع‌بندی

واقعیت اتوماسیون تست بدون کد میان دو شعار «همه می‌توانند تست بسازند» و «Recorder همیشه بد است» قرار دارد. Abstraction مناسب می‌تواند سرعت شروع، مشارکت Domain و Reuse را بهتر کند؛ Abstraction نامناسب فقط Complexity را پشت Canvas، Agent و License پنهان می‌کند.

در آزمایش کنترل‌شده، Baseline هر دو Flow سبز بود؛ فقط پس از تزریق تغییر ID، Target مبهم، Timing و اثر Backend تفاوت آشکار شد. بنابراین تصمیم را با تعداد Step یا Demo نگیرید. Hard gate، Fixture ازپیش‌برچسب‌خورده، Mutation، Oracle مستقل، First-attempt evidence، Repair time، CI، Security، TCO و Exit را اندازه بگیرید؛ سپس ابزاری را انتخاب کنید که تیم بتواند رفتار و شکست آن را توضیح دهد.

محمد عسکری

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

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