ساخت پورتفولیوی QA؛ از Artifact تا Evidence

یک پوشه پر از اسکرین‌شات، Test Case و کد Playwright هنوز «پورتفولیوی QA» نیست. پورتفولیو وقتی قابل اتکا می‌شود که هر ادعای حرفه‌ای به یک Artifact قابل بررسی وصل باشد، منشأ و اجازه انتشارش روشن باشد، داده‌هایش واقعاً پاک‌سازی شده باشد و خواننده بداند این مدرک دقیقاً چه چیزی را ثابت نمی‌کند. این راهنما به‌جای فهرست‌کردن ابزارها، یک مسیر عملی برای ساخت QA Portfolio Evidence Case می‌دهد: Claim → Artifact → Provenance/Permission → Sanitization → Verification → Publication/Access → Review/Expiry.

هدف، تحت‌تأثیر قراردادن استخدام‌کننده با ظاهر شلوغ نیست؛ هدف این است که یک مخاطب مشخص بتواند با زمان محدود، سهم شما، کیفیت استدلال، امکان بازتولید و مرز محرمانگی را بسنجد. این مقاله مشاوره حقوقی نیست. قرارداد، NDA، حقوق کارفرما و مشتری، مالکیت فکری، مجوز نرم‌افزار، حریم خصوصی و قواعد افشا باید برای رابطه و حوزه قضایی واقعی توسط فرد صلاحیت‌دار بررسی شوند.

خلاصه عملی: قبل از انتشار این هفت سؤال را پاسخ دهید

• Claim: دقیقاً چه توانایی محدودی را ادعا می‌کنم؟
• Artifact: کدام خروجی قابل مشاهده از این ادعا پشتیبانی می‌کند؟
• Provenance: این خروجی را چه کسی، در چه زمینه‌ای و با چه ورودی‌هایی ساخته است؟
• Permission: اختیار نگهداری، تغییر و انتشار هر جزء از کجا آمده است؟
• Sanitization: چه داده، متادیتا و ترکیبی می‌تواند فرد، سازمان یا سیستم را بازشناسایی کند؟
• Verification: مخاطب چگونه می‌تواند اجرا، نتیجه یا منطق را بررسی کند؟
• Lifecycle: چه کسی دسترسی، بازبینی، انقضا، اصلاح و حذف را مدیریت می‌کند؟

پورتفولیو جای رزومه یا مصاحبه را نمی‌گیرد

رزومه تاریخچه فشرده، پورتفولیو مجموعه‌ای گزینش‌شده از شواهد و مصاحبه یک موقعیت نمونه‌برداری است. هیچ‌کدام به‌تنهایی «اثبات زنده مهارت»، پیش‌بینی قطعی عملکرد آینده یا تضمین استخدام نیست. یک Artifact ممکن است نشان دهد نویسنده در یک تمرین مشخص Oracle را تعریف کرده؛ اما لزوماً نشان نمی‌دهد همان کار را زیر محدودیت Production، در تیم واقعی یا در دامنه‌ای دیگر نیز انجام می‌دهد.

برای روایت هویت، مخاطب و حضور حرفه‌ای از راهنمای برند شخصی QA مبتنی بر شواهد استفاده کنید. مالکیت این مقاله متفاوت است: اینجا واحد تصمیم یک Evidence Case قابل انتشار است، نه ساخت برند شخصی.

اول مخاطب و تصمیم را تعریف کنید

یک صفحه برای همه معمولاً برای هیچ‌کس بهینه نیست. مشخص کنید مخاطب مدیر QA، مهندس SDET، مدیر محصول، Recruiter عمومی، مشتری فریلنس یا جامعه متن‌باز است؛ چه زمانی دارد؛ فارسی می‌خواند یا انگلیسی؛ و قرار است بعد از مشاهده چه تصمیمی بگیرد: دعوت به مصاحبه، بررسی کد، گفت‌وگو درباره یک Case Study یا صرفاً شناخت حوزه تخصص.

Audience Record حداقل این فیلدها را داشته باشد:

AudienceID | Role/Domain | Language | Expected decision
Time budget | Required depth | Access constraints
Needs | Likely questions | Excluded audience | Owner | ReviewDate

ادعا را کوچک، قابل مشاهده و ابطال‌پذیر بنویسید

«در تست حرفه‌ای هستم» یا «ذهنیت کیفیت دارم» قابل ممیزی نیست. ادعای بهتر می‌گوید: «در تمرین آفلاین Checkout نسخه ۱.۲، حالت timeout پس از commit را از timeout پیش از commit جدا کردم و برای جلوگیری از ثبت تکراری، Oracle و Evidence قابل بازپخش ساختم.» دامنه، نسخه، نقش، عمل، خروجی و محدودیت در خود ادعا دیده می‌شوند.

ClaimID | AudienceID | Capability | Context/Version
My role and contribution | Observable action | ArtifactRefs
Verification method | Limitations | NotClaimed | ValidUntil | Owner

Capability را با نام ابزار اشتباه نگیرید

«Jira، Postman، Selenium» فقط نام ابزار است. Capability می‌تواند ساخت Oracle، مدل‌کردن ریسک، طراحی پوشش، تشخیص ابهام، حفظ قابلیت بازتولید، تفسیر نتیجه، مدیریت Unknown یا توضیح trade-off باشد. ابزار، زبان و Framework را کنار نسخه و دلیل انتخاب بیاورید؛ اما تعداد لوگوها را معیار بلوغ نکنید.

ماتریس Claim–Artifact از ویترین تصادفی جلوگیری می‌کند

برای هر ادعا حداقل یک مدرک و برای هر مدرک یک دلیل حضور ثبت کنید. اگر یک Artifact برای پنج ادعای نامرتبط استفاده شده، احتمالاً ادعاها بیش از حد کلی‌اند. اگر یک مدرک هیچ Claim ندارد، حذف آن تجربه خواندن را بهتر می‌کند.

ادعا	Artifact	مشاهده‌پذیری	محدودیت
اولویت‌بندی ریسک	Risk model + تصمیم Scope	فرض، احتمال، اثر و انتخاب	تمرین ساختگی، نه محصول واقعی
گزارش‌نویسی باگ	Bug Report بازتولیدپذیر	محیط، Steps، Oracle، Evidence	شدت کسب‌وکاری تأیید نشده
اتوماسیون قابل نگهداری	کد + Run + Failure diagnosis	راه‌اندازی و نتیجه قابل تکرار	مقیاس Production آزموده نشده
تصمیم‌گیری زیر عدم قطعیت	Decision log	گزینه‌ها، evidence و Unknown	تصمیم سازمانی واقعی نیست

Artifact با Evidence یکی نیست

فایل Test Plan یک Artifact است. فقط وقتی برای یک Claim مشخص evidence محسوب می‌شود که ارتباطش با ادعا، منشأ، نسخه، تمامیت، شیوه بررسی و محدودیت روشن باشد. اسکرین‌شات سبز تست، اجرای صحیح سناریو، پوشش مناسب، نبود flaky behavior یا کیفیت محصول را به‌تنهایی ثابت نمی‌کند.

چه Artifactهایی ارزش نمایش دارند؟

• Case Study کوتاه با مسئله، قیدها، گزینه‌ها، تصمیم، نتیجه و آموخته؛
• Test Plan نسخه‌دار همراه با Risk–Scope trace؛
• Test Caseهایی که boundary، equivalence، state و Oracle را نشان دهند؛
• Bug Report با امکان بازتولید، Evidence و Unknown؛
• Exploratory charter، note و debrief بدون ادعای پوشش کامل؛
• کد اتوماسیون با README، fixture، dependency lock و خروجی اجرای قابل بررسی؛
• گزارش performance یا accessibility همراه با محیط، workload و محدودیت؛
• Decision log یا retrospective که اصلاح فرض و پاسخ به failure را نشان دهد.

برای ساخت خود هر نوع خروجی، از مالکان موضوعی استفاده کنید: گزارش باگ بازتولیدپذیر، Test Plan زنده، طراحی Test Case مؤثر و Evidence در اتوماسیون تست. این مقاله روش اجازه‌دادن و انتشار آن‌ها را پوشش می‌دهد، نه جزئیات کامل تولیدشان را.

Provenance: خواننده باید بداند این خروجی از کجا آمده است

برای هر Artifact منشأ را ثبت کنید: تمرین کاملاً ساختگی، پروژه شخصی، مشارکت متن‌باز، تکلیف آموزشی، کار تیمی یا نمونه مشتق از کار استخدامی. نام‌بردن «Case Study» بدون این تفکیک می‌تواند مخاطب را به نتیجه غلط درباره تجربه واقعی برساند.

ArtifactID | Type | Title | SourceContext | Fictional/Real/Mixed
CreatedBy | Contributors | MyContribution | Inputs | Tools/Versions
OriginalCreatedAt | EvidenceCapturedAt | Transformations
SourceRefs | IntegrityRef | PermissionRef | SanitizationRef

سهم فردی را در کار تیمی دقیق بنویسید

«ما تست کردیم» سهم شما را مبهم و «من ساختم» ممکن است کار دیگران را تصاحب کند. جدا کنید: مسئله را چه کسی تعریف کرد، شما چه بخش‌هایی را طراحی یا اجرا کردید، چه تصمیم‌هایی نیازمند تأیید بود، چه چیزی توسط همکار یا ابزار/AI تولید شد و نسخه نهایی چگونه بازبینی شد. نام همکار را فقط با مبنای روشن و حداقل لازم منتشر کنید.

Permission Gate پیش از Sanitization می‌آید

پاک‌سازی، مجوز خلق نمی‌کند. حتی اگر نام و لوگو حذف شوند، ممکن است نگهداری یا انتشار ساختار، کد، داده، screenshot، log، سؤال مصاحبه، سند داخلی، طراحی مشتری یا مشتق آن ممنوع باشد. قرارداد کاری، NDA، سیاست امنیتی، IP assignment، تعهد مشتری، مجوز داده و اجازه اشخاص را جداگانه بررسی کنید. «خودم فایل را نوشته‌ام» مساوی «حق انتشار دارم» نیست.

PermissionID | ArtifactID | RightNeeded[retain,copy,modify,publish]
Owner/RightsHolder | Basis[own-work,written-consent,license]
Contract/Policy refs | Scope | Audience | Territory | Channel
Conditions | Attribution | Revocation/Expiry | Reviewer | Decision
Unknowns | EvidenceRef | CheckedAt

سه حالت ایمن‌تر برای منبع Artifact

• ساختگی از صفر: دامنه، برند، داده، شناسه و رویداد کاملاً fictional و بدون تقلید نزدیک از مشتری واقعی؛
• پروژه شخصی تحت مالکیت روشن: ورودی‌ها و dependencyها نیز از نظر حق استفاده بررسی شده‌اند؛
• مشارکت عمومی با مجوز و قواعد مشارکت روشن: فقط همان مواد عمومی و سهم ثبت‌شده خودتان، با attribution و محدودیت مجوز.

«سایت از اینترنت باز می‌شود» اجازه تست فعال، اسکن، ساخت حساب انبوه، دورزدن کنترل یا انتشار آسیب‌پذیری نیست. پیش از هر آزمایش روی سامانه شخص ثالث، محدوده مجاز و قواعد افشا را بررسی کنید؛ راهنمای مجوز تست و Contract Stack این مرز را باز می‌کند.

متن‌باز بودن را از عمومی بودن جدا کنید

دیدن کد در یک repository عمومی، به‌خودی‌خود اجازه بازتولید، تغییر و توزیع خارج از شرایط پلتفرم نمی‌دهد. راهنمای رسمی GitHub درباره مجوز repository توضیح می‌دهد که بدون license، قواعد پیش‌فرض حق‌نشر اعمال می‌شوند. LicenseID، نسخه، فایل/بخش مشمول، attribution، notice، source offer، trademark و compatibility را ثبت کنید؛ برای تصمیم حقوقی واقعی از متخصص کمک بگیرید.

برای ممیزی dependency، obligation و record از راهنمای مجوز ابزار تست متن‌باز استفاده کنید. درج یک فایل LICENSE برای کدی که حق صدور مجوزش را ندارید، مشکل مالکیت را حل نمی‌کند.

Sanitization فقط Blur و تغییر نام نیست

عبارت‌هایی مانند «فین‌تک پیشرو»، تاریخ رخداد، مبلغ، topology، نام feature، سبک UI و جزئیات یک failure می‌توانند در ترکیب، سازمان یا incident را بازشناسایی کنند. Blur ناقص ممکن است قابل برگرداندن یا از thumbnail، OCR، متن جایگزین و نسخه قبلی قابل استخراج باشد. داده را در source حذف یا با داده ساختگی مستقل بازسازی کنید؛ سپس خروجی نهایی را دوباره export و inspect کنید.

Data Inventory را قبل از انتشار کامل کنید

• نام، ایمیل، موبایل، شناسه ملی، آدرس، تصویر و صدای شخص؛
• نام سازمان، مشتری، vendor، دامنه، hostname، IP، URL داخلی و tenant؛
• account، token، cookie، API key، credential، certificate و secret؛
• شماره سفارش، تراکنش، کارت، حساب، مبلغ و داده مالی؛
• source code، query، schema، log، stack trace، config و architecture؛
• ticket، chat، email، comment، commit author و metadata؛
• زمان، مکان، ترکیب رخدادها و quasi-identifierهای قابل اتصال؛
• اطلاعات امنیتی، آسیب‌پذیری، exploit path و کنترل‌های دفاعی.

برای Purpose، حداقل‌سازی، داده ساختگی و خطر بازشناسایی به راهنمای حریم خصوصی داده تست رجوع کنید. «PII پیدا نشد» به‌تنهایی به معنی بی‌خطر بودن محتوا نیست.

فایل پنهان هم بخشی از سطح انتشار است

PDF properties، EXIF، نام لایه، comment، hidden sheet، speaker note، revision، track changes، filename، Git author email، branch، commit message، issue، CI log، artifact، package و source map را بررسی کنید. لینک share ممکن است sibling file یا history را آشکار کند. Preview و thumbnail پلتفرم نیز باید با حساب ناشناس آزمایش شود.

حذف secret از آخرین commit کافی نیست

طبق راهنمای رسمی حذف داده حساس از repository در GitHub، داده می‌تواند در history، clone، fork، cached view و Pull Request باقی بماند. اگر secret واقعی افشا شد، اول آن را revoke/rotate و رخداد را از مسیر امنیتی مدیریت کنید؛ بازنویسی history یک عملیات هماهنگ و دارای side effect است، نه دکمه جادویی بازگشت انتشار.

Sanitization Record باید قابل بازبینی باشد

SanitizationID | ArtifactID | SourceVersion | OutputVersion
DataInventoryRef | DirectIdentifiers | QuasiIdentifiers | Secrets
Confidential/IP/Security items | Transformations | Synthetic replacements
Metadata/history/thumbnail/OCR checks | Reidentification scenarios
ResidualRisk | Reviewer | Decision | Evidence | CheckedAt

به‌جای نگهداری فایل اصلی حساس کنار نسخه عمومی، یک pipeline یک‌طرفه و repeatable بسازید. منبع محرمانه را وارد مخزن شخصی روزمره نکنید؛ مجوز نگهداری آن نیز جداست. اگر برای پاک‌سازی نیاز دارید فایل محرمانه را روی سرویس ثالث upload کنید، همان انتقال می‌تواند افشا باشد.

ساختگی‌بودن را صریح و قابل رؤیت اعلام کنید

روی صفحه و داخل Artifact بنویسید: «تمرین کاملاً ساختگی و آفلاین؛ هیچ مشتری، کارفرما، سامانه یا داده واقعی را بازنمایی نمی‌کند.» صرف تغییر نام شرکت کافی نیست. داده، event، architecture، timing، screenshot و روایت باید مستقل ساخته شوند. اگر الگو از تجربه عمومی شما الهام گرفته، سطح abstraction و review لازم را ثبت کنید.

یک آزمایشگاه فارسی و آفلاین برای پورتفولیو بسازید

Case نمونه SYN-QA-PORTFOLIO-01 یک Checkout ساختگی با Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation جعلی است. هیچ شبکه، Production، شرکت، مشتری، کارفرما، نام شخص، سفارش، پرداخت، بانک، حساب، کارت، token، credential یا پول واقعی ندارد. مبالغ fictional با واحد IRR ثبت و «تومان» فقط در presentation با برچسب تبدیل نمایش داده می‌شود.

Dataset باید رقم فارسی/عربی/لاتین، ی/ی، ک/ک، نیم‌فاصله، RTL/LTR و Bidi؛ UTC و Asia/Tehran و تاریخ جلالی صرفاً نمایشی؛ timeout پیش و پس از fake commit، retry، duplicate، late و reordered event را پوشش دهد. هدف نمایش طراحی Evidence است، نه شبیه‌سازی شبکه بانکی ایران یا ادعای امنیت، انطباق یا آمادگی Production.

Case Study را حول تصمیم بنویسید، نه قهرمان‌سازی

• Context: مسئله ساختگی، نسخه، state و محدودیت؛
• Question: چه ابهام یا ریسکی باید بررسی شود؟
• Options: چه مسیرهایی داشتید و چرا یکی انتخاب شد؟
• Test model: state، input، Oracle، coverage و stop rule؛
• Execution: run identity، environment و evidence؛
• Finding: Fact، interpretation، uncertainty و impact فرضی؛
• Decision: نتیجه محدود و اقدام بعدی؛
• Reflection: چه چیزی شکست، چه چیزی اصلاح شد و چه چیزی Unknown ماند؟

شواهد شکست از پنج اسکرین‌شات سبز ارزشمندتر است

نسخه اولیه، فرض اشتباه، flaky run، false positive یا آزمایش نامعتبر را با توضیح اصلاح نمایش دهید. این کار توانایی یادگیری و کنترل evidence را بهتر از نتیجه بی‌نقص نشان می‌دهد. البته failure ساختگی را تجربه واقعی جا نزنید و از انتشار داده حساس برای «اصالت» استفاده نکنید.

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

• هدف، audience، scope و not-in-scope؛
• وضعیت fictional/real/mixed و منشأ؛
• نسخه runtime، OS/container، dependency lock و seed؛
• دستور setup، run، expected output و cleanup؛
• Test IDs، fixture، Oracle و mapping به Claim؛
• Known limitations، unsupported paths و troubleshooting؛
• License، attribution، contribution/security/contact policy؛
• آخرین verified commit، verified date و owner.

Verification را به «روی سیستم من کار می‌کند» محدود نکنید

نسخه‌ها و hash را pin کنید؛ محیط تازه بسازید؛ setup را از حساب یا machine دیگر اجرا کنید؛ نتیجه مورد انتظار و failure mode را ثبت کنید؛ و evidence را به RunID وصل کنید. CI سبز فقط اجرای workflow تعریف‌شده را نشان می‌دهد. coverage، assertion quality، نبود race، امنیت، performance یا correctness کسب‌وکار ادعای جداگانه می‌خواهند.

VerificationID | ArtifactID/Version/Hash | EnvironmentID
SetupSteps | Command | Fixture/Seed | Expected | Observed
RunID | Log/Report refs | IndependentReviewer | Result
FailureModes | Limitations | VerifiedAt | ValidUntil

AI و Template را پنهان نکنید

اگر AI، دوره، template، starter repository یا کد شخص دیگری در خروجی نقش داشته، منبع و سهم را متناسب با قواعد آن اعلام کنید. prompt یا گفت‌وگوی محرمانه را منتشر نکنید. مشخص کنید چه چیزی تولید شد، چه کسی بررسی کرد، چه خطاهایی پیدا شد و شما چه تصمیمی گرفتید. polish ماشینی بدون verification evidence توانایی شما را ثابت نمی‌کند.

گزارش حرفه‌ای هم Evidence را محدود می‌کند

راهنمای گزارش‌دهی OWASP WSTG بر ساختار گزارش و پوشاندن داده احتمالاً حساس مانند گذرواژه و اطلاعات شخصی تأکید دارد. این منبع مجوز تست یا انتشار نمی‌دهد و masking را به تضمین ناشناس‌ماندن تبدیل نمی‌کند؛ اما یادآوری خوبی است که کیفیت گزارش شامل کنترل evidence نیز هست.

Publication Gate را مستقل از کیفیت فنی نگه دارید

ممکن است Artifact از نظر فنی عالی اما برای انتشار ممنوع باشد؛ یا انتشارش مجاز اما Evidence ضعیف باشد. Gate انتشار حداقل Permission، Sanitization، Security، Accuracy، Attribution/License، Accessibility، Audience/Access، Lifecycle و owner approval را جداگانه می‌سنجد. وضعیت‌ها را Pass/Fail/Unknown/NotApplicable با دلیل ثبت کنید؛ Unknown را به Pass تبدیل نکنید.

PublicationID | ArtifactVersion | Audience/Channel | Visibility
PermissionDecision | SanitizationDecision | SecurityDecision
AccuracyDecision | License/AttributionDecision | AccessibilityDecision
AccessDecision | Retention/Expiry | Reviewer(s) | PublishedAt
Rollback/Correction URL | FinalState[Hold/Approved/Withdrawn]

عمومی، محدود و خصوصی را آگاهانه انتخاب کنید

وب‌سایت، PDF، GitHub، ویدیوی خصوصی و لینک زمان‌دار فقط delivery channel هستند. برای هر Artifact کمترین visibility لازم را انتخاب کنید. لینک unlisted محرمانگی یا احراز هویت نیست؛ recipient می‌تواند آن را forward کند. public repository ممکن است fork، archive یا mirror شود و حذف بعدی نسخه‌های دیگر را لزوماً حذف نمی‌کند.

دسترسی را از نمایش حرفه‌ای قربانی نکنید

مخاطب نباید برای دیدن نمونه، حساب اجباری بسازد یا permission مبهم درخواست کند. heading واقعی، ترتیب خواندن، contrast، focus، متن لینک توصیفی، alt مناسب، caption/transcript و نسخه متنی خروجی‌های تصویری را فراهم کنید. راهنمای W3C WAI برای طراحی دسترس‌پذیر نقطه شروع است، نه گواه انطباق خودکار.

زبان فارسی و انگلیسی را برای مخاطب ایرانی مدیریت کنید

عنوان و خلاصه فارسی را طبیعی بنویسید و اصطلاح انگلیسی را بار اول داخل پرانتز بیاورید. code، URL و command را LTR و متن را RTL نگه دارید. تاریخ مطلق با timezone و در صورت نیاز معادل میلادی/جلالی مشخص باشد. «تومان» را بدون برچسب تبدیل کنار IRR نگذارید. نسخه انگلیسی را ترجمه کلمه‌به‌کلمه نکنید؛ audience و claim آن را دوباره تعریف کنید.

صفحه اصلی پورتفولیو چه ساختاری داشته باشد؟

• یک معرفی دوخطی: نقش هدف، حوزه و نوع Evidence؛
• سه تا پنج Claim مهم، نه فهرست تمام ابزارها؛
• برای هر Claim یک Card با Artifact، سهم، verification و محدودیت؛
• فیلتر بر اساس Manual/API/Automation/Performance/Accessibility فقط اگر محتوا کافی است؛
• صفحه About/Resume جدا از Evidence Caseها؛
• روش تماس کم‌داده و بدون افشای اطلاعات غیرضروری؛
• تاریخ آخرین بازبینی، availability و correction route.

کمیت مناسب: سه Case قوی بهتر از سی فایل بی‌زمینه

تعداد ثابت و جهانی وجود ندارد. coverage را بر اساس نقش هدف بسنجید. برای Junior می‌توان یک پروژه fictional عمیق را به Plan، Case، Bug و Retrospective شکست؛ اما نباید آن را چهار تجربه مستقل شمرد. برای Senior، تنوع تصمیم، constraint، شکست و ownership مهم‌تر از تنوع لوگوی ابزار است.

معیار انتخاب Artifact

• ارتباط مستقیم با نقش و Claim؛
• سهم فردی قابل تفکیک؛
• حق نگهداری و انتشار روشن؛
• ریسک بازشناسایی و افشای قابل قبول؛
• Verification کم‌اصطکاک؛
• نمایش reasoning، نه فقط نتیجه؛
• محدودیت و Unknown صریح؛
• هزینه نگهداری و انقضای قابل مدیریت.

پورتفولیوی Junior بدون تجربه رسمی

یک محصول و داده کاملاً ساختگی بسازید، Specification کوتاه بنویسید، ambiguityها را ثبت کنید و از Risk تا Evidence پیش بروید. می‌توانید روی برنامه‌ای که خودتان ساخته‌اید یا sandbox صریحاً مجاز کار کنید. روی سایت عمومی تصادفی تست فعال انجام ندهید و «باگ واقعی» نسازید تا صفحه جذاب‌تر شود. تمرین آموزشی را با برچسب آموزشی و سهم مدرس/template نمایش دهید.

پورتفولیوی Senior و Lead

صرف کد بیشتر، seniority را نشان نمی‌دهد. evidence مناسب می‌تواند rationale یک strategy، trade-off پوشش و زمان، تعریف quality signal، طراحی incident exercise، اصلاح flakiness، migration decision یا outcome یک بهبود فرآیندی باشد. برای کار واقعی، permission و abstraction سخت‌گیرانه‌تر لازم است؛ از بیان عدد، ساختار و داستانی که سازمان را قابل شناسایی می‌کند پرهیز کنید.

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

• پورتفولیو را «اثبات قطعی مهارت» نامیدن؛
• کپی سند شرکت و فقط حذف لوگو؛
• نام‌گذاری «یک فین‌تک پیشرو» برای پروژه قابل شناسایی؛
• Blur کردن secret به‌جای revoke و incident response؛
• انتشار log، HAR، video یا screenshot بدون inventory؛
• پاک‌کردن فایل از آخرین commit و فراموش‌کردن history/fork/cache؛
• فرض اینکه public یعنی open source یا مجاز برای تست؛
• گذاشتن License روی محتوایی که مالک آن نیستید؛
• نسبت‌دادن خروجی تیم به خود؛
• پنهان‌کردن سهم AI، template یا course؛
• فهرست ابزار بدون Claim و Artifact؛
• اسکرین‌شات سبز بدون RunID، Oracle و limitation؛
• Case Study قهرمانانه بدون شکست و Unknown؛
• مخزن غیرقابل اجرا با dependency شناور؛
• لینک Drive باز با دسترسی به پوشه والد؛
• PDF دارای comment، metadata یا revision پنهان؛
• لینک unlisted به‌عنوان کنترل محرمانگی؛
• وب‌سایت زیبا اما غیرقابل استفاده با کیبورد/موبایل؛
• ادعای قانونی «NDA-safe» بدون review؛
• انتشار بدون owner، تاریخ بازبینی، expiry و correction route.

Validator ساختگی: چرا ظاهر حرفه‌ای کافی نیست؟

برای این راهنما یک fixture وابسته‌نبودن به شبکه با Node.js ساخته شد. checker سطحی دید: پنج Artifact، repository عمومی، README، badge سبز و screenshotهای blurشده؛ بنابراین به‌اشتباه PROFESSIONAL_PORTFOLIO_VERIFIED داد. ممیزی ساختاری ۳۸۱ کنترل یکتا در گروه‌های Identity، Audience، Claim، Artifact، Provenance، Contribution، Permission، Contract، License، Data، Sanitization، Reidentification، Metadata/History، Security، Verification، Reporting، Publication، Access، Accessibility، Lifecycle، Correction و Limits را بررسی کرد و نتیجه HOLD-381 شد.

یک قاعده مستقل نیز تأیید کرد fixture هیچ کارفرما، مشتری، شخص، repository، سیستم یا تصمیم استخدام واقعی ندارد. پس از pin شدن تمام کنترل‌های داستانی، نتیجه فقط READY_FOR_QA_PORTFOLIO_EVIDENCE_REVIEW-0 بود؛ نه اثبات مهارت، مالکیت، اجازه قانونی، محرمانگی، ناشناس‌بودن، امنیت، صحت، دسترس‌پذیری، آمادگی Production یا شایستگی استخدام.

چک‌لیست ۲۴ مرحله‌ای پیش از انتشار

• Audience و decision را ثبت کرده‌ام.
• هر Claim محدود و observable است.
• هر Claim به Artifact نسخه‌دار وصل است.
• هر Artifact دلیل حضور دارد.
• fictional/real/mixed روشن است.
• Provenance و ورودی‌ها ثبت شده‌اند.
• سهم من از تیم جدا شده است.
• AI/template/third party attribution دارد.
• حق retain/copy/modify/publish جداگانه بررسی شده است.
• NDA/contract/policy/customer duty مرور شده است.
• License و obligation هر جزء ثبت شده است.
• مجوز تست سامانه ثالث روشن است.
• Data Inventory کامل شده است.
• direct و quasi-identifier بررسی شده‌اند.
• secretها revoke/rotate شده‌اند، نه فقط blur.
• metadata/history/comment/thumbnail/OCR بررسی شده‌اند.
• سناریوی reidentification و residual risk ثبت شده است.
• Artifact در محیط تازه بازتولید شده است.
• نتیجه، limitation و NotClaimed کنار evidence دیده می‌شوند.
• لینک و permission با حساب ناشناس آزموده شده‌اند.
• موبایل، کیبورد، heading، contrast و متن جایگزین بررسی شده‌اند.
• کمترین visibility لازم انتخاب شده است.
• Owner، retention، expiry و review trigger مشخص‌اند.
• راه اصلاح، withdrawal و حذف منتشر شده است.

پایلوت ۳۰ روزه بدون داده یا سامانه واقعی

روز ۱ تا ۵: Role، Audience، سه Claim و ماتریس Claim–Artifact را برای آزمایشگاه fictional بنویسید. روز ۶ تا ۱۲: یک Case Study، یک Bug Report و یک Automation Evidence بسازید. روز ۱۳ تا ۱۸: Provenance، Permission و License record را با حالت‌های داستانی کامل کنید. روز ۱۹ تا ۲۳: Sanitization pipeline و reidentification review را روی داده کاملاً جعلی تمرین کنید. روز ۲۴ تا ۲۷: بازتولید مستقل، accessibility و دسترسی ناشناس را بسنجید. روز ۲۸ تا ۳۰: Publication Gate، expiry و correction drill را اجرا کنید.

خروجی پایلوت باید یک بسته کوچک، دقیق و قابل حذف باشد؛ نه مخزن اطلاعات شغلی واقعی. پس از ۳۰ روز، Artifact بدون Claim، Claim بدون Evidence، لینک شکسته، dependency ناپایدار، permission نامعلوم و صفحه بدون owner را Hold کنید.

قالب نهایی QA Portfolio Evidence Case

CaseID/Version/Owner | Audience/Decision | Claim(s)/NotClaimed
Artifact(s)/Hash | Fictional-Real-Mixed | Provenance/Contribution
Permission/Contract/License refs | Data inventory/Sanitization
Reidentification/Residual risk | Verification/Run evidence
Report/Limitations/Unknowns | Publication channel/Visibility/Access
Accessibility | PublishedAt | ReviewTriggers/ValidUntil
Correction/Withdrawal/Delete route | Approvals | FinalState

جمع‌بندی: پورتفولیوی خوب، ادعای محدود و شواهد مسئولانه دارد

ساخت پورتفولیوی QA با انتخاب WordPress، GitHub یا PDF شروع نمی‌شود. از مخاطب و Claim شروع کنید، Artifact مناسب بسازید، Provenance و سهم را روشن کنید، Permission را پیش از پاک‌سازی بسنجید، Sanitization را تا metadata و history ادامه دهید، بازتولید و محدودیت را نشان دهید و انتشار را با access، expiry و correction مدیریت کنید. بهترین نمونه کار، بیشترین جزئیات را افشا نمی‌کند؛ کمترین شواهد لازم را با بیشترین قابلیت بررسی ارائه می‌دهد.

سؤالات متداول درباره ساخت پورتفولیوی QA

آیا کارشناس Junior بدون سابقه رسمی به پورتفولیو نیاز دارد؟

می‌تواند مفید باشد، اما تنها راه اثبات مهارت و شرط همگانی استخدام نیست. یک آزمایشگاه کاملاً ساختگی با Claim محدود، Test Evidence و Reflection بسازید؛ آن را تجربه مشتری یا محصول واقعی معرفی نکنید.

آیا می‌توانم سند پروژه قبلی را با حذف نام شرکت منتشر کنم؟

حذف نام به‌تنهایی کافی نیست. ابتدا حق نگهداری، تغییر و انتشار را از نظر قرارداد، NDA، IP، داده و تعهدات ثالث بررسی کنید؛ سپس reidentification، metadata و history را ممیزی کنید. وقتی مبنا نامعلوم است، نمونه موجود را Hold کنید و نسخه fictional مستقلی از صفر بسازید.

آیا repository عمومی GitHub یعنی کد متن‌باز است؟

خیر. عمومی‌بودن امکان مشاهده را فراهم می‌کند، اما حقوق استفاده، تغییر و توزیع به license و شرایط مرتبط وابسته است. مجوز هر dependency و اختیار خودتان برای صدور مجوز را نیز بررسی کنید.

وب‌سایت شخصی بهتر است یا PDF و GitHub؟

به audience، نوع Artifact، دسترسی و ریسک انتشار بستگی دارد. وب‌سایت می‌تواند index و روایت بدهد، GitHub کد و history را نشان دهد و PDF نسخه ثابت ارائه کند. هیچ کانالی ذاتاً حرفه‌ای‌تر یا ایمن‌تر نیست؛ کمترین visibility و کمترین اصطکاک لازم را انتخاب کنید.

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

تقویم ثابت به‌تنهایی کافی نیست. یک بازه متناسب با ریسک تعیین کنید و triggerهایی مانند تغییر نقش هدف، نسخه dependency، مجوز، قرارداد، دسترسی، داده، لینک، ادعا یا کشف افشا را اضافه کنید. Artifact منقضی باید برچسب بخورد، اصلاح یا withdraw شود.