SDET چیست؟ نقش، مهارت‌ها و مسیر شغلی مهندس تست

تیم پرداخت ۳۲۰۰ تست خودکار دارد، اما Pipeline چهل‌وهشت دقیقه طول می‌کشد، هر هفته چند تست ناپایدار Merge را متوقف می‌کند و برای فهمیدن علت Fail باید سه نفر Logها را کنار هم بگذارند. اضافه‌کردن ۵۰۰ اسکریپت دیگر این سیستم را بهتر نمی‌کند. مسئله کمبود «تعداد تست» نیست؛ مسئله معماری Testability، کیفیت Testware، داده و محیط، سرعت بازخورد و مالکیت Failure است. این همان جایی است که یک SDET توانمند باید اثر مهندسی ایجاد کند.

SDET معمولاً کوتاه‌شدهٔ Software Development Engineer in Test است: مهندسی که با کدنویسی، طراحی سیستم و دانش تست، ظرفیت تیم برای تولید سیگنال کیفیت سریع و قابل‌اعتماد را بالا می‌برد. او صرفاً «تستر دستی که Selenium یاد گرفته» یا «مالک همهٔ کیفیت» نیست. عنوان و دامنهٔ کار میان شرکت‌ها یکسان نیست؛ قرارداد نقش و خروجی مورد انتظار از خود عنوان مهم‌تر است.

اگر هدف شما تصویر بزرگ‌تر ورود و رشد در QA است، ابتدا نقشه راه مسیر شغلی QA را ببینید. این صفحه مالک نیت تخصصی «SDET چیست، چه خروجی‌ای دارد و چگونه برای آن آماده شویم» است.

SDET چیست و دقیقاً چه مسئله‌ای را حل می‌کند؟

تعریف عملی SDET

SDET یک نقش مهندسیِ متمرکز بر کیفیت و Testability است. «مهندسی» یعنی راه‌حل او باید Versioned، قابل‌بازبینی، قابل‌آزمون، قابل‌مشاهده، امن و قابل‌نگهداری باشد. «متمرکز بر تست» یعنی انتخاب راه‌حل از ریسک محصول، Oracle، سطح تست، داده، محیط و نوع بازخورد موردنیاز شروع می‌شود؛ نه از ابزار محبوب تیم.

خروجی ممکن است یک Library تست قرارداد، Fake سرویس بانکی، Fixture داده، Plugin گزارش، ابزار تشخیص Flaky، تغییر در API محصول برای تزریق Clock، یا طراحی Laneهای Pipeline باشد. نوشتن Test Case تنها یکی از شکل‌های کار است.

SDET چه چیزی نیست؟

• دپارتمان یا Gate جداگانه‌ای نیست که در انتهای Sprint کیفیت را «تأیید» کند.
• جایگزین Developer، Test Analyst، Product، Security، SRE یا کاربر نیست.
• مسئول خودکارکردن هر سناریوی دستی نیست.
• ضامن نبودن Defect در Production نیست؛ هیچ Test Suite چنین ضمانتی نمی‌دهد.
• لزوماً مدیر فنی یا Test Architect نیست؛ سطح اختیار باید در قرارداد نقش روشن شود.

چرا سازمان ممکن است این نقش را بسازد؟

وقتی کیفیت به یک مسئلهٔ مقیاس‌پذیری مهندسی تبدیل می‌شود—صدها Repository، سرویس‌های توزیع‌شده، Pipeline کند، محیط‌های پیچیده، دادهٔ حساس، Device Matrix یا Releaseهای پرتکرار—فردی با عمق هم‌زمان در Software Engineering و Testing می‌تواند گلوگاه مشترک تیم را حل کند. در تیم کوچک با معماری ساده، همین قابلیت ممکن است میان Developers و QA Engineers توزیع شود و عنوان SDET اصلاً لازم نباشد.

آیا SDET یک عنوان استاندارد جهانی است؟

عنوان شغلی با قرارداد نقش فرق دارد

نه. دو آگهی با عنوان SDET می‌توانند کارهای متفاوتی بخواهند: یکی توسعه‌دهندهٔ Platform تست، دیگری نویسندهٔ UI Automation و سومی Quality Engineer داخل Product Team. از کارفرما دربارهٔ درصد تقریبی Product code، Test code، Infrastructure، Exploration و Support بپرسید؛ Repositoryها، On-call، سطح تصمیم‌گیری و معیار عملکرد را نیز روشن کنید.

ریشهٔ تاریخی را نسخهٔ ابدی نقش ندانید

یک نوشتهٔ رسمی قدیمی در Google Testing Blog دربارهٔ Test Engineering مهندسان تست را توسعه‌دهندگانی علاقه‌مند به Testing معرفی می‌کرد که در تیم محصول Framework و Test system می‌ساختند. این منبع برای فهم ریشه و یک پیاده‌سازی سازمانی مفید است، اما تعریف یک شرکت در سال ۲۰۰۸ استاندارد استخدامی همهٔ شرکت‌ها در امروز نیست.

در Scrum، SDET Accountability جداگانه نیست

Scrum Guide رسمی فقط Developers، Product Owner و Scrum Master را به‌عنوان Accountabilityهای Scrum Team تعریف می‌کند؛ Specialists هم در مفهوم Developers قرار می‌گیرند. تیم Cross-functional است، Sub-team جدا ندارد و Developers با Definition of Done کیفیت را نهادینه می‌کنند. بنابراین SDET می‌تواند تخصصی درون تیم باشد، اما نباید به «پلیس کیفیت» یا صف تحویل بین Dev و QA تبدیل شود.

تفاوت SDET با QA Engineer، Automation Engineer و نقش‌های نزدیک

نام‌ها استاندارد نیستند؛ جدول زیر یک مدل گفت‌وگو است، نه قانون بازار کار. برای سنجش توانایی‌های مشترک QA نیز ماتریس ۱۴ مهارت تست نرم‌افزار را ببینید.

نقش	تمرکز غالب	خروجی نمونه	مرزی که باید روشن شود
SDET	Testability و سیستم بازخورد مهندسی	Framework، Test API، Fixture، Pipeline، Diagnostic	مالک کیفیت کل محصول نیست
QA/Test Engineer	ریسک، رفتار محصول و شواهد تصمیم	مدل ریسک، Exploration، Test Design، گزارش کیفیت	ممکن است کدنویسی عمیق هم داشته باشد
Test Automation Engineer	راهکار و دارایی اتوماسیون	Suite، Runner، Integration و گزارش	در بعضی سازمان‌ها عملاً همان SDET است
Software Engineer	قابلیت محصول و سلامت Codebase	Production code و تست‌های آن	کیفیت کد خود را واگذار نمی‌کند
Test Architect	معماری و Governance چندتیمی	Reference architecture و Roadmap	ممکن است Individual Contributor ارشد باشد
SRE/Platform Engineer	Reliability و Platform delivery/operation	SLO، Deployment platform، Observability	هم‌پوشانی دارد، اما مأموریت اصلی متفاوت است

SDET در برابر تستر دستی

تقابل «SDET فنی» با «تستر دستی غیر‌فنی» مدل ضعیفی است. Exploration، مصاحبه با کاربر، Accessibility با Assistive Technology و ارزیابی Usability کارهای انسانی و تخصصی‌اند. SDET باید کار تکراری مناسب Machine را مهندسی کند و فضای بیشتری برای قضاوت انسانی بسازد، نه اینکه ارزش Testing را با میزان کدنویسی رتبه‌بندی کند.

SDET در برابر QA Engineer

QA Engineer ممکن است دامنه‌ای گسترده‌تر یا حتی فنی‌تر داشته باشد. تفاوت را با Artifact و Outcome بسنجید: آیا نقش انتظار دارد Production-grade Library بسازد، Product code را برای Testability Refactor کند و Failureهای Distributed را Debug کند؟ اگر بله، دامنه به SDET نزدیک است. اگر تمرکز بر Risk analysis، Exploration و Release evidence باشد، دامنه به Test Engineering نزدیک‌تر است؛ هر دو می‌توانند هم‌پوشانی داشته باشند.

SDET در برابر Automation Engineer

Automation Engineer می‌تواند دقیقاً همان مسئولیت‌ها را داشته باشد. در مدل محدودتر، او Suiteهای موجود را پیاده‌سازی می‌کند؛ SDET علاوه بر Script، معماری محصول و Test Solution، Developer Experience، CI economics و Diagnostic را تغییر می‌دهد. این تمایز را در Job Description تعریف کنید، نه در فرض ذهنی.

SDET در برابر Software Engineer

هر Developer باید برای تغییر خود Unit/Component test، Review و Observability مناسب بسازد. SDET این مسئولیت را پس نمی‌گیرد؛ ابزار، Pattern، Coaching و Infrastructure می‌دهد تا انجام آن آسان و قابل‌اعتماد شود. اگر همهٔ تست‌ها فقط در Backlog فرد SDET باشند، Feedback دوباره به صف بیرونی تبدیل می‌شود.

SDET در برابر Test Architect

Architect معمولاً تصمیم‌های چندتیمی، استانداردها، Integration با Platform و Evolution roadmap را هدایت می‌کند. Senior SDET ممکن است همین نقش را انجام دهد، اما عنوان ارشد به‌تنهایی اختیار معماری ایجاد نمی‌کند. Decision Record و Owner تصمیم را شفاف کنید.

SDET در برابر SRE و Platform Engineer

SRE اعتمادپذیری سرویس در Operation را با SLO، Incident response و Engineering مدیریت می‌کند؛ Platform Engineer مسیر تحویل Self-service می‌سازد. SDET می‌تواند Release test، Fault injection، Synthetic probe یا Test platform بسازد، اما تغییر Production و Experiment باید Guardrail، مجوز و Owner عملیاتی داشته باشد.

قرارداد نقش SDET را چگونه تعریف کنیم؟

Mission پیشنهادی

افزایش توان تیم برای تشخیص سریع و قابل‌اعتماد ریسک تغییر، از طریق Testability محصول، Testware مهندسی‌شده، داده و محیط قابل‌بازتولید، Diagnostic غنی و توانمندسازی Developers و Testers.

Outcomeهای قابل انتظار

• زمان رسیدن سیگنال متناسب با Lane و تصمیم کوتاه‌تر شود.
• نرخ Failureهای غیرمحصولی و زمان Triage کاهش یابد.
• ریسک‌های مهم در سطح مناسب و با Oracle روشن پوشش داده شوند.
• تست روی Laptop و CI رفتار قابل‌بازتولیدتری داشته باشد.
• تغییر Suite به یک نفر وابسته نباشد و تیم بتواند آن را نگهداری کند.
• شواهد Release به Build، Environment، Data و Revision قابل‌ردیابی باشد.

Non-goalهای ضروری

• رسیدن به ۱۰۰٪ Automation یا Code Coverage.
• بیشینه‌کردن تعداد Test Case یا Bug.
• مالکیت انحصاری همهٔ تست‌ها و Failureها.
• ساخت Framework اختصاصی بدون مسئلهٔ اثبات‌شده.
• Gate کردن Release صرفاً با یک درصد Pass.

وظایف SDET؛ از طراحی تا شواهد Release

۱. تبدیل ریسک به طراحی تست

SDET با Product، Developer، Tester، Security و Operations ریسک را به Condition→Event→Impact تبدیل می‌کند. سپس Level، Type، Technique، Oracle، Data و Environment مناسب را انتخاب می‌کند. سناریوی گران E2E نباید جای Unit یا Contract test ارزان‌تر را بگیرد.

۲. طراحی برای Testability

Dependency injection، Clock/Random/ID قابل‌کنترل، API پایدار، Event correlation، State inspection امن، Feature flag، Test hook محدود و Log ساختاریافته نمونه‌اند. Test hook نباید Authorization را دور بزند یا در Production در دسترس عموم باشد.

۳. مهندسی Test Automation Solution

راهکار شامل Architecture، Runner، Library، Data، Environment adapter، Reporting، Versioning و Upgrade policy است؛ نه فقط Test script. ISTQB CTAL-TAE 2.0 نیز دامنهٔ Test Automation Engineering را از تحلیل SUT و انتخاب راهکار تا Architecture، Maintainability، CI/CD، گزارش، Verification زیرساخت و Continuous Improvement دنبال می‌کند.

برای مرز اقتصادی و انتخاب Candidate، راهنمای اتوماسیون تست چیست را ببینید؛ این مقاله نقش مهندس را توضیح می‌دهد، نه اینکه هر کار را نامزد اتوماسیون بداند.

۴. ساخت Feedback loop در CI/CD

Fast lane برای Compile/Static/Unit/Component، Laneهای Integration/Contract و Laneهای Event-driven برای E2E/Performance/Security طراحی می‌شوند. Failure policy، Timeout، Retry، Quarantine، Artifact، Trigger و Owner باید صریح باشند. DORA دربارهٔ Test Automation بر بازخورد سریع، همکاری Tester و Developer، Suite قابل‌اعتماد و بهبود پیوسته تأکید دارد؛ نه واگذاری همهٔ تست‌ها به یک گروه بیرونی.

برای معماری کامل Lane و Gate، طراحی Continuous Testing در CI/CD را مطالعه کنید.

۵. مدیریت داده و محیط قابل‌بازتولید

Seed، Factory، Namespace، Cleanup، TTL، Schema version، Secret reference و Environment manifest بخشی از Testware هستند. SDET باید بتواند Run را با همان Build/Config/Data بازسازی کند و میان Product، Data، Environment و Dependency failure فرق بگذارد. کپی Production به محیط تست، راه پیش‌فرض نیست.

۶. Diagnostic و Failure triage

یک Fail مفید باید Test ID، Attempt، Commit، Build، Environment، Dataset، Timestamp، Correlation ID، Expected/Actual و Artifact داشته باشد. SDET Failure را فوراً «Bug محصول» نمی‌نامد؛ با Taxonomy و شواهد علت محتمل را محدود می‌کند و برای Unknown مالک پیگیری تعیین می‌کند.

۷. پوشش تست غیرخودکار و اکتشافی

SDET می‌تواند Charter بسازد، ابزار Capture تولید کند یا Risk area را برای Exploration آماده کند. تست اکتشافی ساختاریافته مکمل Automation است: Machine تکرار دقیق را انجام می‌دهد و انسان دربارهٔ رفتار تازه، ارزش، ابهام و Oracle ناقص یاد می‌گیرد.

۸. Enablement و Coaching

Template Repository، Example، Pairing، Review checklist، Office hour و Migration guide باعث می‌شوند تیم خودش تست بنویسد و Debug کند. هدف «تیم وابسته به SDET» نیست؛ هدف کاهش هزینهٔ انجام رفتار باکیفیت برای همه است.

۹. امنیت و حریم خصوصی Testware

Test code هم کد است: Dependency و Secret، دسترسی Cloud، Artifact، Log و Dataset می‌توانند مسیر نشت یا Supply-chain risk باشند. کمترین دسترسی، Secret manager، Redaction، Retention، Dependency pinning و Review امنیتی را در Definition of Done راهکار قرار دهید.

یک روز کاری SDET چگونه می‌گذرد؟ مثال بازپرداخت بانکی

فرض کنید Marketplace ایرانی بعد از Callback بانک، درخواست بازپرداخت را در Queue می‌گذارد. گزارش Production می‌گوید برخی Callbackهای تکراری دو Refund ایجاد کرده‌اند. هدف تیم افزودن Idempotency key است.

پیش از کدنویسی: Risk و Testability

• Invariant: هر Payment فقط یک Refund موفق برای یک Idempotency key دارد.
• ریسک: Duplicate، Reorder، Late event، Timeout و Race میان دو Worker.
• نیاز Testability: Clock کنترل‌شده، Fake gateway، مشاهدهٔ Event ID و State transition.
• Oracle: وضعیت Ledger، تعداد Call به Gateway و Event خروجی؛ نه فقط HTTP ۲۰۰.

هنگام طراحی: سؤال‌های مهندسی

Idempotency در API، Database یا Consumer enforce می‌شود؟ Transaction boundary کجاست؟ اگر Gateway موفق شود ولی ثبت محلی Timeout دهد چه می‌کنیم؟ Correlation ID در Log و Trace عبور می‌کند؟ Migration با رکوردهای قدیمی چگونه رفتار می‌کند؟ این سؤال‌ها قبل از نوشتن UI test، معماری را قابل‌آزمون‌تر می‌کنند.

هنگام پیاده‌سازی: Layer مناسب

• Unit: State machine و policy بازپرداخت با Clock/Fake.
• Component: Repository واقعی و Unique constraint در Container.
• Contract: شکل Command/Event و compatibility نسخه‌ها.
• Integration: Fake/Sandbox بانکی برای Timeout و Duplicate callback.
• E2E: یک Journey بحرانی از درخواست کاربر تا وضعیت نهایی، نه تمام ترکیب‌ها.

در Pipeline: Evidence و Failure policy

Unit/Component در Pull Request، Contract پس از Build و Integration در Environment آماده اجرا می‌شوند. E2E کند می‌تواند پس از Deploy به Staging یا Event-driven باشد. Retry فقط برای جمع‌کردن Evidence است؛ Pass شدن Attempt دوم، Attempt اول را پاک نمی‌کند و Test مشکوک وارد Quarantine با Owner و تاریخ انقضا می‌شود.

پس از Release: یادگیری از Production

Metric و Trace مشخص می‌کند Duplicate callback واقعاً چند بار و در کدام مسیر رخ می‌دهد. Incident یا Near miss به Regression test در پایین‌ترین Level ممکن تبدیل می‌شود. Monitoring جای Test را نمی‌گیرد و Test نیز رفتار ناشناختهٔ کاربران را کامل پیش‌بینی نمی‌کند.

مثال کد: از وابستگی پنهان تا طراحی قابل‌آزمون

طراحی شکننده

export async function refund(orderId: string) {
  const now = new Date();
  const payment = await globalDb.payments.find(orderId);
  return globalGateway.refund(payment.amount, now);
}

Clock، Database و Gateway پنهان‌اند؛ Fail می‌تواند از Timezone، Network یا State باقی‌مانده باشد. تست برای شبیه‌سازی Timeout و تکرار Call کنترل کمی دارد.

مرزهای قابل‌کنترل

type RefundDeps = {
  clock: { now(): Date };
  payments: { find(id: string): Promise<Payment> };
  gateway: { refund(key: string, amount: number): Promise<Receipt> };
};

export function createRefundService(deps: RefundDeps) {
  return {
    async refund(orderId: string, idempotencyKey: string) {
      const payment = await deps.payments.find(orderId);
      if (payment.refunded) return payment.receipt;
      return deps.gateway.refund(idempotencyKey, payment.amount);
    },
  };
}

تست رفتار، نه جزئیات پیاده‌سازی

test("reuses the idempotency key for a retry", async () => {
  const calls: string[] = [];
  const service = createRefundService({
    clock: { now: () => new Date("2026-08-06T12:00:00Z") },
    payments: { find: async () => ({ amount: 1250000, refunded: false }) },
    gateway: {
      refund: async (key) => {
        calls.push(key);
        return { status: "accepted" };
      },
    },
  });

  await service.refund("order-42", "refund-order-42");
  expect(calls).toEqual(["refund-order-42"]);
});

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

Unique constraint، Transaction، دو Worker هم‌زمان، Recovery پس از Crash، قرارداد Gateway و Migration را ثابت نمی‌کند. SDET خوب Scope هر Test را می‌نویسد و با چند Level مکمل Evidence می‌سازد. Coverage عددی جای این استدلال را نمی‌گیرد.

معماری Test Automation که SDET باید بفهمد

لایه‌های راهکار

1. Intent: Risk، Requirement، Charter یا Contract.
2. Test: Arrange/Act/Assert و Oracle.
3. Domain DSL/Flow: زبان کسب‌وکار بدون جزئیات Driver.
4. Adapter: API client، Page/Component، DB helper و Message driver.
5. Infrastructure: Runner، Container، Device، Data و Environment.
6. Evidence: Result، Trace، Log، Screenshot و Report.

اصل پایین‌ترین Level مناسب

اگر همان Fault را Unit test دقیق و سریع پیدا می‌کند، UI E2E برای آن ارزش کمتری دارد. اما Test pyramid قانون تعداد ثابت نیست؛ Architecture و ریسک تعیین می‌کند. راهنمای رسمی Microsoft دربارهٔ Shift-left با Unit tests بر Testability، Reliability، Test code به‌عنوان Product code و مسئولیت Code owner تأکید می‌کند.

Hermeticity و مرز واقع‌گرایی

Test کاملاً جدا سریع و قابل‌بازتولید است، اما integration واقعی را کمتر می‌بیند. Test واقعی‌تر Dependency و Failure mode بیشتری وارد می‌کند. Contract، Container، Service virtualization، Sandbox و E2E نقاط مختلف این طیف‌اند. نام Test باید سطح و Dependency را صادقانه بیان کند.

Configuration و Version identity

نتیجه بدون Commit SHA، Build، Config، Schema، Browser/Driver، Dataset و Environment قابل تفسیر نیست. Testware و Product باید compatibility contract داشته باشند؛ Upgrade ابزار بدون ثبت نسخه می‌تواند False failure یا Blind spot بسازد.

Verification خود Test system

Golden test، Mutation sample، Seeded fault، Contract test برای Adapter و Self-test زیرساخت نشان می‌دهند Test واقعاً Fault موردنظر را می‌بیند. سبز ماندن Suite ممکن است نتیجهٔ اجرا نشدن Test، Assertion ضعیف یا Report ناقص باشد.

SDET در CI/CD چه چیزی را مالک یا تسهیل می‌کند؟

Fast lane

Compile، Lint، Static analysis، Unit و Componentهای سریع باید Feedback پیش از Context switch بدهند. Budget زمانی محلی تعریف کنید؛ عدد جهانی برای همهٔ Repositoryها وجود ندارد. Fail این Lane معمولاً Merge را متوقف می‌کند، مگر Exception ثبت‌شده با Expiry.

Slow و Event-driven lane

Integration سنگین، E2E، Cross-browser، Performance، Security scan و Recovery drill بر اساس Trigger، Risk و هزینه زمان‌بندی می‌شوند. همه را در یک Job طولانی نریزید. Artifact Build باید Immutable و در همه Laneها یکسان باشد.

Failure ownership

Class	مثال	اقدام
Product	Oracle رفتار اشتباه را نشان می‌دهد	Developer/Team تغییر Triage می‌کند
Test	Locator یا Assertion غلط	Owner Testware اصلاح می‌کند
Data	Fixture ناقص یا مصرف‌شده	Factory/Reset و Contract داده اصلاح می‌شود
Environment	نسخه یا Capacity نامعتبر	Environment owner Manifest/Health را اصلاح می‌کند
Dependency	Sandbox بانک در دسترس نیست	Fallback/Virtualization/Retry policy بررسی می‌شود
Unknown	شواهد کافی نیست	Run حفظ، Diagnostic افزوده و Owner تعیین می‌شود

Retry و Quarantine

Retry درمان Flaky نیست. Attempt history را حفظ کنید، احتمال Failure را با Sample کافی بسنجید و Quarantine را با دلیل، Owner، Ticket، تاریخ ورود و Expiry ثبت کنید. Test قرنطینه‌شده باید Visibility داشته باشد و Coverage gap آن با Risk acceptance یا پوشش جایگزین مدیریت شود.

راهبرد، نه انباشت ابزار

برای Charter، انتخاب Candidate، TCO، Pilot و Scale از قالب عملی استراتژی اتوماسیون تست استفاده کنید. SDET باید بتواند تصمیم Build/Buy/Adapt را با PoC و Exit strategy دفاع کند.

Observability و Debugging برای SDET

سه سؤال پایهٔ هر Fail

1. دقیقاً چه Build، Configuration، Data و Environment اجرا شد؟
2. Expected و Actual در کدام Boundary واگرا شدند؟
3. چه Evidence می‌تواند Product/Test/Data/Environment/Dependency را تفکیک کند؟

Log، Metric و Trace هر کدام چه می‌گویند؟

مستندات Signals در OpenTelemetry Signalها را خروجی‌هایی برای توصیف فعالیت System معرفی می‌کند. Log برای Event و Context، Metric برای روند و توزیع و Trace برای مسیر یک Request میان سرویس‌ها مفید است. افزودن همهٔ Signalها بدون Correlation، Redaction و Retention صرفاً Noise و هزینه می‌سازد.

Test ID تا Trace ID

Run ID و Test ID را در Header/Message metadata عبور دهید؛ Trace ID را در Result ذخیره کنید؛ Log حاوی Secret، Token بانکی، شماره کارت یا داده هویتی نباشد. برای Parallel test، Namespace داده مانع مخلوط‌شدن Evidence می‌شود.

اعتمادپذیری فراتر از Pre-production

فصل رسمی Testing for Reliability در Google SRE تفاوت Testهای سنتی و Production، هزینه Levelهای مختلف و نقش Testing در کاهش عدم‌قطعیت تغییر را توضیح می‌دهد. Production probe، Canary یا Fault injection باید مجوز، Blast radius، Stop condition و Rollback داشته باشد؛ SDET به‌تنهایی اجازهٔ آزمایش مخرب روی کاربر ندارد.

مهارت‌های لازم برای SDET؛ ماتریس شایستگی به‌جای فهرست ابزار

۱. Programming و Computer Science

حداقل یک زبان را تا سطح Production code یاد بگیرید: Type system، Error handling، Concurrency، I/O، Package management، Profiling و Debugger. Data structure و Algorithm برای مصاحبه کافی نیست؛ باید بتوانید API خوانا، تست‌پذیر و امن طراحی و Review کنید.

۲. Test analysis و Test design

Equivalence، Boundary، Decision table، State transition، Pairwise، Risk-based و Exploratory را به مسئله وصل کنید. ابزار بدون Oracle فقط Action را تکرار می‌کند. توان توضیح «این Test چه چیزی را ثابت نمی‌کند» نشانه بلوغ است.

۳. Software architecture و Testability

Dependency boundary، Sync/Async messaging، Transaction، Idempotency، Cache، Consistency، Failure mode و Contract را بفهمید. تغییر برای Testability نباید Encapsulation یا Security را قربانی کند.

۴. Automation design

Separation of concerns، Composition، DSL، Adapter، Fixture، Pattern، Configuration، Parallelism، Reporting و Migration را تمرین کنید. Framework سفارشی زمانی ارزش دارد که مسئلهٔ تکرارشونده را با TCO بهتر از راهکار موجود حل کند.

۵. CI/CD و Configuration management

Git، Build، Artifact، Container، Pipeline-as-code، Secret، Cache، Matrix، Trigger و Rollback را بشناسید. هدف حفظ Green build با Failure صادقانه است، نه مخفی‌کردن Fail برای Dashboard سبز.

۶. Data، Database و Environment

SQL، Transaction isolation، Schema migration، Factory، Synthetic data، Masking، Cleanup و Namespace ضروری‌اند. در سیستم ایرانی، Unicode فارسی/عربی، نیم‌فاصله، ارقام، مبلغ ریالی/تومانی، Calendar و Timezone را Domain concern بدانید.

۷. API، Event و Distributed systems

HTTP semantics، Authentication/Authorization، Schema/Contract، Queue، Retry، Backoff، Dead-letter، Duplicate و Out-of-order event را بفهمید. E2E تنها راه آزمون Microservice نیست.

۸. Observability و Diagnostic

Structured log، Metric distribution، Trace، Correlation و Artifact capture را برای یک سؤال طراحی کنید. مهارت Debug از سرعت نوشتن Selector ارزشمندتر است، چون Cost شکست را کم می‌کند.

۹. Security و Privacy

Threat modeling مقدماتی، SAST/SCA/Secret scan، Least privilege، Safe test data و Responsible disclosure را بیاموزید. راهنمای تحلیل استاتیک کد برای QA نشان می‌دهد چگونه Signal ابزار را به Finding قابل‌تصمیم تبدیل کنید.

۱۰. Communication و Influence

Design doc، ADR، Code review، Incident note، Coaching و گفت‌وگوی ریسک بخشی از کارند. SDET بدون اختیار رسمی باید Trade-off را با Evidence توضیح دهد و میان سرعت Feedback، Fidelity، Cost و Risk توافق ایجاد کند.

سطوح رشد SDET را چگونه تعریف کنیم؟

سطح	دامنه	رفتار قابل مشاهده	شاهد ارتقا
Junior/Associate	یک Component یا Journey	Test قابل‌اعتماد می‌نویسد، Failure را بازتولید و Review feedback را اعمال می‌کند	PR، Test design و Run evidence روشن
Mid-level	یک Service/Feature area	Layer را انتخاب، Fixture/Adapter طراحی و Pipeline را Debug می‌کند	کاهش زمان/نویز با Baseline معتبر
Senior	چند Component یا Team	Architecture و Migration را هدایت، Risk trade-off را تسهیل و دیگران را توانمند می‌کند	Adoption پایدار بدون وابستگی شخصی
Staff/Principal	Platform/Organization	Capability مشترک، Governance سبک، Economics و چندساله Roadmap را شکل می‌دهد	اثر چندتیمی و Outcome محصول/تحویل
Lead/Manager	People و Portfolio	Priority، Hiring، Coaching و Operating model را مدیریت می‌کند	سلامت تیم و سیستم، نه Heroics فردی

ارتقا با Tool count اتفاق نمی‌افتد

دانستن ده Framework بدون حل مسئلهٔ پیچیده، شواهد سطح بالاتر نیست. دامنه، ابهام، استقلال، کیفیت تصمیم، اثر پایدار و توانمندسازی دیگران را بسنجید.

مسیر Individual Contributor و مدیریت جداست

Senior SDET مجبور نیست Manager شود. Staff/Principal می‌تواند با معماری، Platform و Influence رشد کند. Manager نیز باید People system بسازد، نه اینکه بهترین Debugger تیم باقی بماند.

تخصص‌های جانبی

Mobile، Performance، Security، Data/ML، Accessibility، Reliability و Developer Productivity مسیرهای تخصصی‌اند. یک پایهٔ مشترک بسازید و سپس بر اساس Product domain یک عمق انتخاب کنید.

اثر SDET را با چه معیارهایی بسنجیم؟

Time to useful feedback

از Commit یا Trigger تا نخستین Signal قابل‌اقدام را با Median و p95 بسنجید و Laneها را جدا کنید. Average می‌تواند Tail کند را پنهان کند.

Signal trust

نسبت Failureهایی که Product defect واقعی، Test defect، Environment/Data issue یا Unknown بوده‌اند را با Definition ثابت دنبال کنید. هدف صفرکردن همهٔ Failureها نیست؛ هدف کاهش Noise و Unknown و افزایش تشخیص است.

Detection level و escaped risk

Faultهایی که در E2E/Production کشف می‌شوند بررسی کنید آیا می‌توانستند در Unit/Component/Contract زودتر پیدا شوند. هر Escape الزاماً تقصیر تست نیست؛ Requirement، Architecture، Review، Environment و Operation نیز علت دارند.

Maintainability و flow

زمان اصلاح Test پس از تغییر محصول، Queue time Review، Age تست‌های Quarantine، هزینه Compute و زمان Triage را بسنجید. Test count و Line coverage فقط Diagnostic محلی‌اند.

Team capability

درصدی از تیم که می‌تواند Test را اجرا، Failure را Debug و تغییر مرتبط را Review کند؛ Bus factor، زمان Onboarding و Adoption Template را ببینید. این معیار را برای رتبه‌بندی تنبیهی افراد استفاده نکنید.

ضدالگوهای رایج در نقش SDET

کارخانه اسکریپت

Backlog با «خودکارکردن همهٔ Test caseها» پر می‌شود و هیچ Risk/TCO ندارد. راه اصلاح: Candidate rubric، حذف پوشش تکراری و Pilot با معیار خروج.

مالک انحصاری کیفیت

Developer کد را «برای تست» تحویل می‌دهد و منتظر Gate می‌ماند. راه اصلاح: Test کنار Product code، Code-owner accountability، Pairing و Definition of Done مشترک.

Framework‌سازی برای رزومه

Wrapperهای متعدد روی ابزار استاندارد Debug و Upgrade را سخت می‌کنند. راه اصلاح: کمترین Abstraction لازم، ADR، Benchmark، Exit plan و مستندات مصرف‌کننده.

سبزکردن Dashboard با Retry

Failure اول پاک می‌شود و Pass attempt آخر گزارش می‌شود. راه اصلاح: Attempt history، Flaky policy، Quarantine محدود و Report دوگانهٔ Product confidence/Test health.

درصد اتوماسیون به‌عنوان KPI

تیم سناریوهای کم‌ارزش را زیاد می‌کند تا عدد رشد کند. راه اصلاح: Risk coverage، Feedback time، Signal trust و Maintenance cost.

جداکردن SDET از Product context

تیم مرکزی ابزار می‌سازد اما Journey، Data و Failure واقعی را نمی‌شناسد. راه اصلاح: Embedded rotation، Product feedback، Consumer-driven roadmap و Support contract.

Hero debugging

فقط یک نفر Test lab را می‌فهمد و شب‌ها Build را نجات می‌دهد. راه اصلاح: Runbook، Self-service diagnostic، Pairing، Ownership map و حذف دانش پنهان.

چه زمانی سازمان به SDET نیاز دارد و چه زمانی نه؟

نشانه‌های Fit

• مشکل مشترک Testability یا Test infrastructure چند تیم را کند کرده است.
• Automation موجود زیاد اما غیرقابل‌اعتماد یا گران است.
• Distributed system به Data/Environment/Observability تخصصی نیاز دارد.
• Developerها برای نوشتن تست درست Platform و Coaching کم دارند.
• Roadmap روشن و Sponsor برای کار زیربنایی وجود دارد.

نشانه‌های Non-fit

• مدیر فقط می‌خواهد Testing را از Developerها پس بگیرد.
• موفقیت با تعداد Script یا Defect سنجیده می‌شود.
• برای Testability یا CI هیچ ظرفیت Product engineering اختصاص نمی‌یابد.
• نقش اختیار تغییر Codebase ندارد اما مسئول نتیجه شناخته می‌شود.
• یک QA عمومی برای تیم کوچک کافی است و مسئلهٔ مقیاس وجود ندارد.

Embedded، Platform یا Hybrid؟

مدل	مزیت	ریسک	Guardrail
Embedded	Context و Feedback نزدیک	تکرار راهکار میان تیم‌ها	Guild و Components مشترک
Central Platform	Scale و استاندارد مشترک	فاصله از Product	Product discovery و SLO مصرف‌کننده
Hybrid	Platform مشترک + متخصص در تیم	ابهام مالکیت	RACI و Support contract

Pilot پیش از استخدام گسترده

یک Problem statement مانند «p95 بازخورد Pull Request از ۲۵ به زیر ۱۲ دقیقه با نرخ Unknown زیر ۵٪» تعریف کنید. Baseline، یک Team، یک Quarter، Guardrail و تصمیم Scale/Revise/Stop داشته باشید. عدد هدف باید از وضعیت خود سازمان بیاید، نه نسخهٔ عمومی این مقاله.

Job Description سالم برای SDET

Context را قبل از فهرست ابزار بنویسید

نوع محصول، Architecture، Team topology، Release cadence، ریسک اصلی، وضعیت فعلی Test system و مسئله‌ای که نقش باید حل کند را توضیح دهید. «تسلط به Selenium، Cypress، Playwright، Appium، JMeter و ده Cloud» بدون Context معمولاً فهرست آرزوست.

Responsibilities نمونه

• طراحی و پیاده‌سازی Testability و Automation برای Journeyهای پرریسک.
• بهبود Feedback loop و Diagnostic در CI/CD.
• تعریف Data/Environment contract و Failure taxonomy با Ownerها.
• Review کردن Product/Test code و Coaching تیم.
• اندازه‌گیری Outcome و مدیریت Test technical debt.

Must-have را از Preference جدا کنید

Must-have می‌تواند کدنویسی Production-grade، Test design، Debug، Git/CI و ارتباط باشد. زبان/Framework خاص فقط وقتی Must-have است که زمان Onboarding یا محدودیت Product آن را توجیه کند. Preferenceها را برای حذف نامزدهای توانمند به Gate پنهان تبدیل نکنید.

تمرین استخدامی امن و منصفانه

یک Repository کوچک بدون Secret و داده واقعی بدهید: یک Test flaky، API کم‌Testable و Pipeline کند. از نامزد بخواهید سؤال بپرسد، Risk را مدل کند، یک تغییر محدود پیاده کند و Trade-off را توضیح دهد. Rubric را پیشاپیش تعریف و زمان Take-home را محدود کنید. برای آمادگی عمومی نیز ۳۰ سؤال مصاحبه QA با جواب و تمرین را ببینید.

چگونه SDET شویم؟ نقشه یادگیری مبتنی بر شاهد

مرحله ۱: پایهٔ تست و برنامه‌نویسی

یک زبان، Git، CLI، Unit testing، Debugger، HTTP و SQL را در یک پروژه واقعی ترکیب کنید. هدف تمام‌کردن Course نیست؛ باید PR قابل‌خواندن، Test design و Failure analysis ارائه کنید.

مرحله ۲: یک Service را در چند Level تست کنید

برای API سفارش Unit، Component، Contract و یک E2E کوچک بسازید. توضیح دهید هر Level چه Faultی را زودتر می‌گیرد، چه Dependency دارد و چه چیزی را ثابت نمی‌کند.

مرحله ۳: آن را در CI قابل‌اعتماد کنید

Container/Fixture، Parallel safety، Artifact، JUnit report، Retry policy و Cache را اضافه کنید. یک Failure عمدی Seed کنید تا نشان دهید Pipeline واقعاً Gate می‌کند و Report به علت نزدیک می‌شود.

مرحله ۴: System thinking و Enablement

ADR بنویسید، Baseline بگیرید، یک Bottleneck را بهبود دهید و Migration guide بسازید. از شخص دیگری بخواهید بدون کمک شما Repository را اجرا و Failure را Debug کند؛ این آزمون خوبی برای Developer Experience است.

نمونه‌کار SDET چه چیزهایی داشته باشد؟

پروژه ۱: API و Contract

یک سرویس سفارش کوچک با Unit/Component/Contract، Idempotency و Negative authorization بسازید. README شامل Architecture، Risk map، Run command و Scope evidence باشد.

پروژه ۲: UI کم اما معنادار

سه Journey بحرانی با Locator معنایی، Data مستقل، Screenshot/Trace در Fail و Browser matrix محدود بسازید. پنجاه Test تکراری ارزش بیشتری از سه Test قابل‌اعتماد ندارد.

پروژه ۳: Pipeline و Diagnostic

Fast/Slow lane، Artifact immutable، Report، Quarantine demo و Failure taxonomy پیاده کنید. Commit history باید نشان دهد چرا Design تغییر کرده است.

چه چیزی را منتشر نکنیم؟

Token، Credential، Endpoint خصوصی، داده کاربر، کد کارفرما، Screenshot حساس و Interview question محرمانه را در GitHub قرار ندهید. Synthetic data بسازید و License Dependencyها را رعایت کنید.

ملاحظات بازار کار و محصول در ایران

عنوان‌ها را با شرح کار تطبیق دهید

در آگهی‌های فارسی ممکن است SDET، QA Automation، Test Automation Engineer یا QA Engineer کار مشابهی بخواهند. جست‌وجو را به یک عنوان محدود نکنید و در مصاحبه Contract نقش، Code ownership، On-call، مدل تیم و معیار موفقیت را بپرسید.

محدودیت دسترسی و Supply chain

Registry، Container image، Browser binary، SaaS device farm یا Cloud ممکن است به‌دلیل شبکه، پرداخت یا سیاست Vendor ناپایدار باشد. Dependency mirror مجاز، Cache، Artifact repository، Lockfile، License و مسیر جایگزین را طراحی و در Disaster mode تمرین کنید.

فارسی، RTL و Domain محلی

Unicode normalization، ی/ک عربی و فارسی، نیم‌فاصله، BiDi، فونت، ارقام، تومان/ریال، تاریخ شمسی/میلادی، Timezone تهران و شماره موبایل را Test Data و Oracle واقعی بدانید. از Regexهای بیش‌ازحد محدود برای نام و نشانی پرهیز کنید.

پرداخت و داده حساس

Sandbox بانک را با قرارداد، Timeout، Callback تکراری، Signature نامعتبر و Reconciliation مکمل کنید. داده Production را به Laptop یا Public CI نبرید؛ Log و Trace را Redact و Retention را محدود کنید.

همکاری Remote و رزومه

Design note کوتاه، Commit کوچک، Issue روشن، Demo ضبط‌شده و مستندات انگلیسی/فارسی Evidence بهتری از Tool list هستند. عدد حقوق یا «تقاضای قطعی» بدون دادهٔ زمان‌دار ارائه نکنید؛ آگهی واقعی، سطح، شهر/Remote، نوع قرارداد و مزایا را در زمان تصمیم مقایسه کنید.

هوش مصنوعی چه تغییری در کار SDET می‌دهد؟

کاربردهای کمکی

تولید Draft تست از Schema، خلاصه Failure، پیشنهاد Boundary، ساخت Synthetic example و تبدیل Log به Hypothesis می‌تواند زمان Exploration را کم کند. خروجی باید Review، Compile/Run و با Oracle مستقل ارزیابی شود.

ریسک‌ها

Hallucination API، Assertion ظاهراً معتبر، نشت کد/داده، License ambiguity، Testهای هم‌شکل و Automation bias خطرند. Secret یا داده کاربر را به سرویس تأییدنشده نفرستید و Policy سازمان را رعایت کنید.

مهارتی که مهم‌تر می‌شود

Problem framing، Test oracle، Architecture، Debugging و ارزیابی Evidence مهم‌تر می‌شوند. سرعت تولید کد اگر Noise، Duplicate و Maintenance debt بسازد Outcome مثبت نیست.

برنامهٔ ۹۰روزه برای ورود یا شروع نقش SDET

روزهای ۱ تا ۳۰: Baseline و یک Slice

• Product journey، Architecture و Failureهای اخیر را بخوانید.
• زمان Pipeline، Failure taxonomy، Quarantine age و Cost تقریبی را Baseline کنید.
• یک Risk slice انتخاب و Testability gap را ثبت کنید.
• یک تغییر کوچک End-to-end با Review تیم تحویل دهید.

روزهای ۳۱ تا ۶۰: بهبود سیستم

• Fixture/Data namespace و Evidence schema را استاندارد کنید.
• یک Flaky cluster را با Root cause، نه Retry کور، کاهش دهید.
• Fast/Slow lane و Owner Failure را روشن کنید.
• Runbook و Pairing برای دو عضو تیم اجرا کنید.

روزهای ۶۱ تا ۹۰: سنجش و تصمیم

• Baseline و After را با همان Definition مقایسه کنید.
• Guardrailها مانند Compute cost و Escaped risk را کنترل کنید.
• Adoption، Debt و Support load را گزارش کنید.
• برای Scale/Revise/Stop یک ADR و Roadmap سه‌ماهه بدهید.

نمونه گزارش پایان ۹۰ روز

p95 بازخورد PR از ۲۶ به ۱۴ دقیقه رسید؛ سهم Failureهای Unknown از ۱۸٪ به ۷٪ کاهش یافت؛ هزینه Compute دوازده درصد بالا رفت و دو Risk مهم هنوز فقط در E2E پوشش دارند. پیشنهاد: Parallelization را قبل از افزودن Browserهای بیشتر بهینه کنیم، Owner دو تست Quarantine را تعیین و Contract test سرویس پرداخت را در Sprint بعد اضافه کنیم.

این اعداد صرفاً مثال‌اند؛ Baseline و هدف هر سازمان باید از دادهٔ خودش بیاید.

چک‌لیست تصمیم برای فرد و سازمان

برای نامزد شغلی

• آیا می‌توانم یک Failure ناشناخته را نظام‌مند Debug کنم؟
• آیا نمونه‌کار من Test design و Trade-off را نشان می‌دهد یا فقط Tool syntax؟
• آیا Product code و Test code را با معیار مشابه Review می‌کنم؟
• آیا می‌توانم Scope و محدودیت Evidence را توضیح دهم؟
• آیا نقش واقعی شرکت با هدف شغلی من هم‌خوان است؟

برای Hiring manager

• Problem statement و اختیار نقش روشن است؟
• کیفیت مسئولیت مشترک تیم باقی می‌ماند؟
• Outcome و Guardrail داریم یا فقط KPI حجمی؟
• زمان برای Testability، Debt و Enablement رزرو شده است؟
• مدل Embedded/Platform و Support contract روشن است؟

پرسش‌های متداول درباره SDET

آیا برای SDET شدن مدرک علوم کامپیوتر لازم است؟

الزام جهانی نیست؛ آگهی هر شرکت متفاوت است. اما باید شایستگی معادل در Programming، Debugging، Architecture پایه، Test design، Git و CI را با نمونه‌کار و تجربه نشان دهید. مدرک جای Evidence عملی را نمی‌گیرد و نبود آن نیز نیاز به یادگیری بنیادها را حذف نمی‌کند.

آیا SDET فقط تست خودکار انجام می‌دهد؟

خیر. Automation بخش مهمی است، اما Testability، Risk analysis، Exploration، Data/Environment، Observability، Failure triage، Code review و Coaching نیز می‌توانند جزو نقش باشند. نسبت این کارها باید در قرارداد شغلی مشخص شود.

تفاوت SDET و QA Automation چیست؟

عنوان‌ها در بازار یکسان استفاده نمی‌شوند. مدل مفید این است که SDET را دارای دامنهٔ عمیق‌تر Software Engineering و Testability بدانیم، اما فقط شرح کار، اختیار Repository و Outcome واقعی شرکت تفاوت را ثابت می‌کند.

برای شروع Java بهتر است یا Python یا TypeScript؟

زبانی را انتخاب کنید که در Product/بازار هدف شما استفاده می‌شود و با آن می‌توانید Production-grade code بنویسید. Type system، Error handling، Concurrency، Package management، Test framework و Debugger از نام زبان مهم‌ترند. پس از عمق در یک زبان، انتقال به زبان دوم آسان‌تر است.

آیا SDET باید تست دستی و اکتشافی بلد باشد؟

بله، چون بدون فهم Testing، Automation ممکن است فقط Actionهای سریع بدون Oracle و Risk rationale تولید کند. لازم نیست همهٔ فعالیت‌های دستی را خود او انجام دهد، اما باید بداند چه چیزی به قضاوت انسانی نیاز دارد و چگونه Automation از Exploration پشتیبانی می‌کند.

منابع و حدود این راهنما

منابع رسمی استفاده‌شده

• Google Testing Blog: یک نمونهٔ تاریخی از Test Engineering سازمانی
• Scrum Guide: Accountabilities و مسئولیت مشترک کیفیت در Scrum Team
• ISTQB CTAL-TAE ۲.۰: دامنهٔ جاری Test Automation Engineering
• DORA: Test Automation، بازخورد سریع و مسئولیت تیم
• Microsoft DevOps و Azure Well-Architected: Shift-left، Testability و Test asset quality
• Google SRE: Testing برای Reliability و عدم‌قطعیت تغییر
• OpenTelemetry: مفاهیم Signalهای Observability

راهنمای جاری Azure Well-Architected دربارهٔ راهبردهای Testing بر پوشش لایه‌ای، مالکیت Test asset و مدیریت Test debt تأکید دارد. این اصول برای طراحی نقش مفیدند، اما هیچ منبعی عنوان و شرح شغل همهٔ شرکت‌ها را استاندارد نمی‌کند.

تاریخ و شیوه بازبینی

بازبینی محتوایی: مرداد ۱۴۰۵. عنوان‌های شغلی، Toolchain، شرایط دسترسی Vendor و بازار استخدام تغییر می‌کنند؛ شرح کار و مستندات نسخهٔ همان زمان را مرجع تصمیم قرار دهید. ادعاهای حقوق، تقاضا و صرفه‌جویی بدون Dataset و بازهٔ زمانی معتبر در این راهنما عمداً حذف شده‌اند.