Jira یک گزارش باگ ضعیف را خودکار به Evidence خوب تبدیل نمیکند و یک Workflow شلوغ نیز الزاماً کنترل بهتری نمیسازد. اگر فیلدها معنای مشترک نداشته باشند، Transitionها اختیار روشن نداشته باشند، Resolution با Status ناسازگار باشد یا Automation در سکوت داده را تغییر دهد، بورد سبز میتواند واقعیت را پنهان کند.
این راهنما Jira Cloud را برای QA بهصورت یک Flow قابل ممیزی طراحی میکند: Signal → Work item → Field contract → Triage → State transition → Verification → Disposition/Resolution → Closure → Learning. هر مرحله Owner، Authority، Evidence، Permission، Query و Audit record دارد. هدف «تبدیلشدن به تستر حرفهای با چند Gadget» نیست؛ هدف جلوگیری از گمشدن معنا بین گزارش، تصمیم و اجراست.
خلاصهٔ عملی: Jira برای QA چه چیزی باید فراهم کند؟
- هر Work item نوع، Scope، منبع، ریسک، Owner و Evidence قابلردیابی دارد.
- Status جای Flow را نشان میدهد؛ Resolution دلیل پایان را، و Priority ترتیب تصمیم را.
- Severity اثر مشاهدهشده است و با Priority، Urgency یا SLA یکی نیست.
- Transition فقط با Authority، ورودی، Validator، Action و Failure behavior روشن اجرا میشود.
- JQL مجموعهای را بازیابی میکند؛ حقیقت، KPI یا کیفیت محصول را بهتنهایی اثبات نمیکند.
- Automation باید Actor، Scope، Idempotency، Loop guard، Error path و Audit قابل نگهداری داشته باشد.
- Attachment و Comment بر اساس کمینهسازی، Permission، Security level و Retention مدیریت میشوند.
- تغییر Scheme/Field/Rule ابتدا در Sandbox مصنوعی آزموده، سپس با Migration و Rollback منتشر میشود.
مرز این راهنما با مدیریت نقص و گزارش باگ
| پرسش | مالک محتوا | خروجی |
|---|---|---|
| یک گزارش چگونه بازتولیدپذیر شود؟ | گزارش باگ قابل بازتولید | Reproduction Contract و Evidence |
| در جلسهٔ Triage چه تصمیمی گرفته شود؟ | جلسه تریاژ باگ | Disposition و Decision Packet |
| State Machine عمومی نقص چگونه باشد؟ | گردش کار نقص | State/Transition/Audit مستقل از ابزار |
| برنامهٔ سازمانی نقص، SLA و یادگیری چیست؟ | مدیریت نقص نرمافزار | Operating model و Governance |
| این قراردادها در Jira چگونه پیاده شوند؟ | همین مقاله | Field/Workflow/JQL/Automation/Permission/Audit runbook |
پس در این صفحه دوباره نسخهٔ عمومی «Summary + Steps + Expected/Actual» را جایگزین طراحی سیستم نمیکنیم. Jira لایهٔ اجرای قرارداد است؛ اگر قرارداد بیرون از ابزار مبهم باشد، Custom field بیشتر فقط ابهام را رسمی میکند.
دامنهٔ منابع رسمی و تغییر واژگان Jira
این متن در ۱۴ اوت ۲۰۲۶ با مستندات Jira Cloud بررسی شده است. Atlassian در صفحات فعلی از عبارتهایی مانند Work item و Space نیز استفاده میکند، درحالیکه بسیاری از تیمها و APIها هنوز Issue و Project میگویند. نام منو، قابلیت، Plan و رفتار Company-managed/Team-managed میتواند تغییر کند؛ قبل از اجرا Edition، نوع Space، نسخهٔ UI و Permission واقعی Instance را ثبت کنید.
مستند رسمی Ruleهای Workflow چهار خانوادهٔ Restriction، Request input، Validation و Action را توضیح میدهد. صفحهٔ ساخت Transition تأکید میکند Transition جهتدار است و باز/بستهبودن در Jira با مقدار Resolution ارتباط دارد، نه صرفاً نام Status. این قابلیتها Policy مناسب تیم شما را تعیین نمیکنند؛ آن Policy باید جدا تصویب و سپس پیاده شود.
Instance Contract را پیش از Configuration ثبت کنید
Jira Instance Contract instance-id / platform: Cloud / plan / observed-at space model: company-managed / team-managed / service space keys / work types / workflow schemes admin / space owner / data owner / security owner user classes and groups / guests / automation actors data classification / residency / retention policy approved integrations / apps / API clients business timezone / locale / calendar change window / sandbox / backup-export path review-at / expiry / correction owner
یک Screenshot از بورد، Configuration baseline نیست. Scheme، Context، Screen، Permission، Security level، Automation scope و Filter ownership را با شناسه یا Export مجاز ثبت کنید. Secret، Token و دادهٔ شخصی را داخل سند عمومی Configuration نگذارید.
Authority Matrix: چه کسی حق چه تصمیمی دارد؟
| عمل | پیشنهاددهنده | تصمیمگیر | مجری | شاهد پایان |
|---|---|---|---|---|
| Create defect | هر Reporter مجاز | — | Reporter/Integration | Contract حداقلی |
| Severity | QA/Support | Role توافقشده | Field editor | Impact evidence |
| Priority/Order | Triage participants | Product/Risk owner | Authorized role | Decision note |
| Accept fix for verification | Developer/CI | Workflow contract | Transition actor | Build/commit/deploy evidence |
| Verify behavior | QA/Reporter | Defined verifier | Verifier | Oracle + run evidence |
| Close/resolve | Verifier/Triage | Disposition owner | Authorized transition | Resolution + reason |
| Release despite residual risk | Triage | Release authority | Release owner | Risk acceptance |
QA ممکن است Verification را انجام دهد اما لزوماً صاحب Priority، Closure یا Release نیست. «تستر Done کند» فقط وقتی درست است که Authority contract همان را گفته باشد. نام فرد را با Role جایگزین نکنید؛ Absence، Delegation و Escalation هم باید تعریف شوند. برای بستن مسیر Request، Ack، Handoff و Escalation میان نقشها از توافق کاری تستر و توسعهدهنده استفاده کنید.
Signal چه زمانی Work item مستقل میشود؟
هر مشاهده الزاماً یک Bug ticket نیست. Signal میتواند سؤال Rule، Product feedback، incident، environment failure، security concern، test defect یا duplicate باشد. Intake rule تعیین کند چه چیز فوراً ثبت میشود، چه چیز ابتدا نیاز به containment خصوصی دارد و چه چیز به Work type دیگری میرود.
Intake Record signal-id / source / observed-at reporter class / contact route product / build / environment / tenant class observed behavior / expected source / uncertainty potential harm / affected scope / urgency data classification / security route candidate work type / duplicate search containment / next owner / review-by
Work type را بر اساس Flow انتخاب کنید
Bug، Story، Task، Incident، Security finding و Test debt میتوانند Field، Workflow و SLA متفاوت بخواهند. تعریف هر Work type باید Inclusion، Exclusion، مثال مرزی و Route داشته باشد. صرف اینکه Jira همه را Work item مینامد، معنای عملی آنها را یکی نمیکند.
Field Contract: هر فیلد یک تصمیم را پشتیبانی کند
Field Contract field-id / display name / semantic name question answered / decision consumer type / unit / allowed values / null meaning source / editor / validator / transition requirement context: spaces + work types screen placement / API name / smart-value path classification / visibility / retention default and migration rule quality query / owner / review-at
فیلد «Environment» اگر یک Text آزاد باشد شاید Chrome، مرورگر، prod، production و خالی را مخلوط کند. اگر برای Routing یا Metric مصرف میشود، Vocabulary محدود و Unknown صریح لازم است. Default نباید Missingness را پنهان کند؛ مقدار «Medium» خودکار برای Priority میتواند دادهٔ ساختگی بسازد.
Field Context و Screen دو قرارداد متفاوتاند
Context مشخص میکند Field برای کدام Space/Work type و با چه Optionهایی معنا دارد؛ Screen تعیین میکند چه زمانی دیده یا ویرایش میشود. Field سراسری با نام یکسان اما معنای متفاوت، گزارش و Automation را میشکند. Contextهای همپوشان، Optionهای حذفشده و Fieldهای مشابه را Inventory کنید.
حداقل Fieldهای Defect را از روی Decision بسازید
- Summary با Object/Condition/Observed signal، نه قضاوت کلی.
- Build/Version و Environment identity قابل بازتولید.
- Expected source و Actual observation جدا.
- Reproduction/evidence anchor یا دلیل عدم امکان.
- Impact/Severity با Scope و Confidence.
- Priority/Order با Decision owner و تاریخ.
- Component/Owner routing با Unknown مجاز.
- Security/Data classification پیش از Attachment.
- Related item/build/commit/deployment links با semantics مشخص.
- Resolution/Disposition reason و Verification evidence هنگام پایان.
تمام فیلدها را در Create اجباری نکنید. Intake سریع ممکن است Evidence ناقص داشته باشد؛ Transition به Triage یا Ready for Work میتواند Fieldهای بیشتری بخواهد. Progressive validation از رهاشدن گزارش یا جعل مقدار برای عبور از فرم جلوگیری میکند.
Summary را قابل جستوجو و بیاغراق بنویسید
الگوی نمونه: «[Checkout][IRR][duplicate callback] Ledger entry دوبار ثبت میشود». عبارت «سیستم خراب است» Object، Condition و signal ندارد. Summary باید از PII، Token و متن خطای حساس خالی باشد چون ممکن است در Email، Notification، Search یا Integration تکثیر شود.
Evidence را کمینه و قابل پیگیری نگه دارید
Screenshot همیشه لازم یا کافی نیست. برای Race، Log/Trace؛ برای State، Query/response؛ برای UI، تصویر/ویدیو؛ برای Rule، Source/acceptance criterion مفید است. Evidence باید Timestamp، Build، Environment، redaction، capture method و Chain-of-custody لازم را داشته باشد.
Evidence Manifest evidence-id / work-item key claim or observation supported captured-at / actor / method build / environment / dataset class hash / storage / access level redactions / reviewer retention / deletion owner limitations / expiry
Attachment یک مرز امنیتی است
پیش از پیوست، Token، Cookie، Header، Email، شماره تماس، کد ملی، دادهٔ تراکنش، دامنهٔ داخلی و Metadata را بررسی کنید. Crop یا Blur همیشه برگشتناپذیر نیست؛ نسخهٔ پاکسازیشده بسازید و اصل را در محل مجاز نگه دارید. دسترسی Work item، Download و Integration consumer را آزمون کنید.
راهنمای رسمی Permissionهای Jira Cloud Global، Space و Work-item security را از هم جدا میکند. Permission دیدن Space الزاماً مجوز دیدن هر Work item حساس نیست؛ Guest، App و Automation actor را هم در Threat model بیاورید.
Severity، Priority، Urgency و SLA را جدا کنید
| Construct | پرسش | مالک نمونه | Evidence |
|---|---|---|---|
| Severity | اثر مشاهدهشده چقدر است؟ | Risk/QA role | Harm، scope، workaround |
| Priority | نسبت به کارهای دیگر چه زمانی رسیدگی شود؟ | Product/Risk owner | Value، risk، cost، dependency |
| Urgency | مهلت واکنش چرا کوتاه است؟ | Incident/Service owner | Time sensitivity |
| SLA/SLO | تعهد پاسخ/حل چیست؟ | Service governance | Policy/contract/calendar |
Priority پیشفرض Jira قابل سفارشیسازی است؛ نام Critical/Major/Minor قانون جهانی نیست. تعریف، مثال مثبت/منفی، مرز، Override و review cadence را کنار Field contract نگه دارید.
Workflow را از State Machine مصوب بسازید
Workflow State Record status-id / semantic state / status category entry evidence / owner / permitted work exit decision / required fields allowed transitions and actors SLO clock behavior automation/integration side effects exception and escalation metric inclusion/exclusion
Open → In Progress → Done فقط یک نمونه است. Triage، Needs Info، Ready for Work، In Fix، Ready for Verification، Verified و Closed ممکن است مفید یا اضافی باشند. هر Status باید تفاوت تصمیمی داشته باشد؛ Statusی که Owner، entry/exit یا گزارش متفاوت ندارد احتمالاً Queue پنهان میسازد.
Status، Column و Status Category یکی نیستند
Board column میتواند چند Status را نمایش دهد و Mapping آن قابل تغییر است. انتقال Card میان Column همیشه همان Transition معنایی مورد انتظار نیست. وضعیتهایی که به ستون نامناسب Map شدهاند، Work in progress و Done را تحریف میکنند. Board filter و Sub-filter نیز ممکن است Work item را پنهان کنند.
Resolution دلیل پایان است، نه نام ستون
مستند رسمی Status، Priority و Resolution میگوید Status جای Work item در Workflow و Resolution نحوهٔ پایان آن را توصیف میکند. صفحهٔ مدیریت Resolution نیز نمونههایی مانند Fixed، Duplicate یا Could not replicate را توضیح میدهد. نام و معنا میتواند در Instance سفارشی شود.
Transition پایان باید Resolution مناسب را Set کند و Transition بازگشت آن را Clear کند؛ وگرنه Item در گزارشها Closed یا Unresolved اشتباه دیده میشود. Resolution به نام «Unresolved» نسازید؛ نبود مقدار خودِ حالت unresolved است. Before/after query و نمونهٔ Reopen را در تست Workflow بگنجانید.
Transition Contract را کامل بنویسید
Transition Contract transition-id / from / to / semantic action authorized roles / delegation input screen and editable fields conditions / validators / error messages post actions / events / notifications resolution set-or-clear behavior automation/integration consumers idempotency / retry / partial-failure behavior audit evidence / rollback transition
Restriction مشخص میکند چه کسی Transition را میبیند یا اجرا میکند؛ Input دادهٔ لازم را میگیرد؛ Validator پیش از تغییر State مانع ورودی نامعتبر میشود؛ Action پس از Transition اثر میگذارد. اگر Validator رد شود، Work item نباید به مقصد برود. Failure message باید اقدام بعدی را بگوید، نه فقط «خطا».
Ready for Verification بدون Build evidence ناقص است
Transition به Ready for Verification حداقل Fix reference، Build/deploy identity، Environment، scope و known limitations میخواهد. Comment «fix شد» Receiver را مجبور به حدس میکند. اگر Feature flag یا migration لازم است، وضعیت فعال و rollback آن نیز ثبت شود.
Verification و Closure را از هم جدا کنید
Verification پاسخ میدهد رفتار مورد ادعا در Build/Environment/Data مشخص مطابق Oracle شده است؛ Closure پاسخ میدهد Flow با Disposition و Authority لازم تمام شده است. QA میتواند Verification Pass دهد ولی Risk owner با residual risk، release یا زمان Closure تصمیم دیگری بگیرد.
Verification Record verification-id / work item / fix reference build / environment / dataset original reproduction result target-fault and adjacent checks oracle / evidence anchors pass / fail / blocked / inconclusive residual scope / regression gap verifier / verified-at / next route
Reopen یک شکست اخلاقی نیست؛ Transition با شاهد تازه است
Reopen باید Reason، Build، Evidence و تفاوت با Verification قبلی داشته باشد. ممکن است Fix ناقص، محیط اشتباه، Regression، همان Failure mechanism یا مسئلهای تازه باشد. اگر مسئله تازه Scope متفاوت دارد، Link و Work item جدید بهتر از بازکردن تاریخچهٔ نامرتبط است. «هر باگ یک Ticket» نیز قانون نیست؛ Atomicity را با Owner، Fix، deploy، verify و rollback بسنجید.
Disposition را با Comment آزاد جایگزین نکنید
Fixed، Duplicate، Cannot reproduce، Won’t do، By design، Deferred یا Data issue باید تعریف و Authority داشته باشند. «Rejected» بدون Reason، Source و Appeal route تعارض میسازد. Triage packet و تصمیم را طبق پروتکل مستقل ثبت و Jira را برای Trace آن پیکربندی کنید.
Duplicate یعنی یک Canonical owner و چند شاهد
قبل از Duplicate، Failure mechanism، Build، Component و Impact را مقایسه کنید. فقط مشابهبودن Summary کافی نیست. Canonical item باید مالک تصمیم باشد؛ Duplicate item منبع، Reporter، evidence و affected context خود را حفظ و به Canonical Link شود. Merge بیردیابی میتواند Population و اثر را کمبرآورد کند.
Link type باید Semantics داشته باشد
Blocks، is blocked by، relates to، duplicates، caused by، tests یا implements را بهجای هم استفاده نکنید. جهت، Expected consumer، ایجادکننده، validator و cleanup هر Link type را تعریف کنید. لینک Story به Bug بهتنهایی Coverage، علت یا Release inclusion را ثابت نمیکند.
Sub-task و Hierarchy را برای Ownership بهکار ببرید
تفکیک «تست Chrome» و «تست Firefox» به Sub-task فقط وقتی مفید است که Owner، State، Evidence یا Scheduling جدا داشته باشند. شکستن بیدلیل، WIP و گزارش را متورم میکند. Child closure نباید خودکار Parent outcome را ثابت فرض کند مگر Contract و Validator آن را پوشش دهد.
Board مشاهدهٔ Flow است، نه خود Flow
Filter، Column mapping، swimlane، quick filter و permission تعیین میکنند چه میبینید. یک Card ناپدیدشده ممکن است خارج از Filter باشد، نه Done. WIP limit باید Queue policy و exception داشته باشد. «هر صبح Ready for QA را چک کن» جای Pull policy، owner و SLO نیست.
Sprint عضویت است، نه Evidence کیفیت
وجود Bug در Sprint، ارتباط آن با Sprint goal یا کشفشدن در همان Sprint را خودکار ثابت نمیکند. Carry-over، added-after-start، reopened و out-of-scope را جدا کنید. QA نباید Story را صرفاً بهدلیل یک Bug به In Progress برگرداند؛ Link، acceptance policy و Authority تیم تعیینکنندهاند.
JQL را بهعنوان Query Contract مدیریت کنید
مستند رسمی Advanced search با JQL آن را زبان ساخت Query دقیق معرفی میکند؛ صفحهٔ JQL fields عملگرها، تابعها و محدودیت Fieldها را نسخهوار توضیح میدهد. Query syntax صحیح، معنای Field یا کاملبودن داده را اثبات نمیکند.
JQL Query Contract query-id / question answered JQL text / owner / saved-filter id field semantics and null policy space/work-type/timezone scope permission/viewer class expected positive/negative fixtures sample result reviewed-at known blind spots / performance limits consumers: board / dashboard / automation / export expiry / change trigger
سه JQL نمونه، با محدودیت صریح
project = PAY AND issuetype = Bug AND resolution IS EMPTY ORDER BY priority DESC, created ASC project = PAY AND status = "Ready for Verification" AND fixVersion IS NOT EMPTY ORDER BY updated ASC project = PAY AND resolution CHANGED TO Fixed AFTER -14d ORDER BY resolved DESC
این Queryها فقط Fixture آموزشیاند. نام Project، Work type، Status و Field در Instance شما متفاوت است. Query اول «همهٔ نقصهای واقعی باز» نیست؛ فقط Work itemهای قابلدیدن و منطبق را برمیگرداند. Permission، Missing field، Archive و ingestion gap را در نتیجه بنویسید.
Filter یک دارایی عملیاتی با Owner است
Personal filter را بیOwner به Board یا Automation حیاتی وصل نکنید. Owner، Editors/Viewers، Subscription، Consumer، Change log و fallback را ثبت کنید. حذف حساب سازنده، Rename Field یا تغییر Permission میتواند خروجی را بیصدا تغییر دهد.
Dashboard برای سؤال مشخص است، نه نمایش اعتبار QA
هر Gadget باید سؤال، Query، Cohort، Unit، timezone، refresh، missingness و Owner داشته باشد. تعداد Bug باز، کیفیت محصول نیست؛ میتواند با Release scope، Reporting behavior، Duplicate policy یا دسترسی تغییر کند. Pie chart جذاب، Construct ضعیف را نجات نمیدهد.
Metric Contract را قبل از Gadget بسازید
Metric Contract metric-id / decision / construct population / inclusion / exclusion event timestamps and timezone numerator / denominator / unit JQL or extraction version status/resolution semantics missing / duplicate / reopen handling segmentation / uncertainty / guardrail owner / review / anti-gaming note
Cycle time را با Status history و Clock تعریف کنید؛ Created→Resolved با Triage→Verified یکی نیست. Reopen، Waiting، migration و bulk update را مشخص کنید. Trend بدون تغییر Definition یا Query قابل مقایسه نیست.
Automation را مثل کد Production اداره کنید
Automation Rule Contract rule-id / purpose / owner / scope trigger and event cardinality conditions / branches / lookup queries actor / permissions / impersonation limits read fields / write fields / side effects smart values / null/default behavior idempotency key / loop guard / retry partial-failure and compensation notifications / audit / retention test fixtures / rollout / rollback / expiry
Ruleی که Priority را از Severity کپی میکند Policy میسازد، نه صرفاً صرفهجویی. Trigger میتواند چند بار برسد؛ Branch ممکن است N Work item را تغییر دهد؛ Actor ممکن است بیش از کاربر Permission داشته باشد. Blast radius و dry-run/log-only phase تعریف کنید.
Smart Value میتواند خالی یا حساس باشد
راهنمای رسمی Smart valueهای Automation Dot notation، Default و آزمون با Manual trigger/Log action را نشان میدهد. Field ناموجود میتواند مقدار خالی بدهد؛ Email یا Comment ممکن است PII داشته باشد. Null، escaping، list cardinality و access را با Fixture مثبت/منفی تست کنید.
Smart-value Probe rule version / fixture key expression / expected type/cardinality present / absent / null / malformed cases RTL/LTR and Persian digit cases escaped output / redaction result viewer and actor permissions audit-log sample / no-secret assertion decision: PASS / HOLD / REWRITE
Idempotency و Loop guard را عمداً آزمایش کنید
Rule نباید با Edit خود دوباره Trigger و Comment/Transition تکراری بسازد. Marker یا State check، actor exclusion، changed-from/to condition و correlation ID میتواند کمک کند، اما هر کدام Failure mode دارد. همان Event را دوبار Replay و نتیجهٔ نهایی را مقایسه کنید.
Audit log دائمی و کامل فرض نشود
مستند رسمی Automation audit log Trigger، وضعیت و Step detail را برای Debug نشان میدهد و در متن فعلی از نگهداری ۹۰روزهٔ Log سخن میگوید. Retention میتواند تغییر کند و Log الزاماً تمام Business evidence یا دادهٔ لازم برای ممیزی بلندمدت نیست. Export/Archive مجاز، حداقلسازی و حذف را مطابق Policy خود طراحی کنید.
Notification باید Route، Ack و Escalation داشته باشد
Email یا Mention زیاد Signal را خفه میکند. Event، Audience، Purpose، content classification، Ack expectation، quiet hours، fallback و unsubscribe/role handoff را مشخص کنید. Notification ارسالشده ثابت نمیکند پیام دیده، فهمیده یا تصمیم گرفته شده است.
Integration را با Data Contract ببندید
CI، Git، Chat، Test management و Monitoring ممکن است Work item بسازند یا تغییر دهند. Event ID، Schema/version، mapping، actor، permission، retry/backoff، idempotency، ordering، dead-letter/reconciliation و redaction لازم است. برای طراحی جزئیتر به یکپارچهسازی ابزارهای تست رجوع کنید.
Integration Receipt source / event-id / schema-version sent-at / received-at / correlation-id target work-item / mapping-version actor / action / before-after hash attempt / response / retry-after duplicate disposition / reconciliation redaction / audit URI / owner
Test management add-on را Jira ذاتی فرض نکنید
Jira Work tracking با Test repository/plan/execution/evidence/report یکی نیست. Marketplace app میتواند Work type، Field، Permission، storage، API و هزینه اضافه کند. Zephyr/Xray یا هر گزینهٔ دیگر را با نام برند انتخاب نکنید؛ راهنمای انتخاب ابزار مدیریت تست Hard Gate، PoC، TCO و Exit را جدا پوشش میدهد.
API و Bulk edit خطر شعاع اثر دارند
Query اول Count و نمونهٔ Dry-run بدهد؛ سپس Batch محدود با Idempotency و Receipt اجرا شود. Rate limit، pagination، partial failure، field context، permission و history را لحاظ کنید. Token کماختیار، rotation و revoke لازم است. تغییر هزار Work item با یک Script «اصلاح داده» نیست مگر Reconciliation و Rollback داشته باشد.
Configuration change را Migration بدانید
Jira Change Record change-id / problem / non-goals baseline schemes/fields/rules/filters affected spaces/work types/items/users/apps semantic mapping old → new data backfill / missing / conflict policy sandbox fixtures / test results rollout cohort / monitoring / stop rule rollback and irreversible steps communication / training / owner / review-at
Rename Status یا Option میتواند JQL، Dashboard، Automation، API mapping و Export downstream را بشکند. Delete/merge قبل از Consumer inventory و Data migration انجام نشود. تغییر Hierarchy یا Context ممکن است اثر گسترده یا غیرقابل برگشت داشته باشد؛ Preview و Vendor docs همان لحظه را بررسی کنید.
Sandbox باید Fixture و Oracle داشته باشد
- Work item کامل، ناقص، محرمانه و بدون Permission.
- هر Transition مجاز و غیرمجاز با Roleهای مختلف.
- Resolution set/clear و Reopen.
- Duplicate/Link direction و canonical owner.
- JQL مثبت، منفی، Null، timezone و permission.
- Automation present/null/malformed، replay و loop.
- Integration duplicate، out-of-order، rate-limit و partial failure.
- Bulk migration با conflict، stop و rollback.
- Persian text، ارقام، ZWNJ، URL و RTL/LTR.
- Attachment redaction، access و retention.
Sandbox نباید Snapshot خام Production با دادهٔ شخصی باشد. Fixture مصنوعی و حداقل لازم بسازید. Pass تنها وقتی است که State، Field، History، Notification، Audit و Query output مطابق Oracle باشند.
آزمون دسترسی را با ماتریس Role اجرا کنید
Access Matrix Probe viewer/actor role browse / create / edit / comment / attach / transition security-level visibility field visibility and editability filter/dashboard share automation/app/API access expected deny and error behavior observed result / evidence / reviewer
Admin view برای اثبات تجربهٔ کاربر کافی نیست. Least privilege و Negative test لازم است. Work item محرمانه نباید از Filter share، notification، smart value، export یا integration نشت کند.
شرایط ایران و دسترسی Cloud را تاریخدار نگه دارید
دسترسی Site، Login، Email، Marketplace، API، CDN، Payment و Support ممکن است با Provider، Plan، شبکه و زمان تفاوت داشته باشد. یک HTTP ۲۰۰ عمومی Eligibility سازمان یا امکان خرید/پشتیبانی را ثابت نمیکند. مسیر مجاز را با Terms، سازمان، Provider و تاریخ بررسی کنید؛ آدرس/هویت جعلی، حساب مشترک یا دورزدن کنترل نسخهٔ امن نیست.
AI و Rovo نباید بدون Review Configuration را تغییر دهند
اگر AI Summary، JQL، Automation یا Workflow پیشنهاد میدهد، Prompt/context، model/service، data boundary، proposed diff، reviewer و accepted/rejected change را ثبت کنید. خروجی ممکن است Field/Status موجود در Instance دیگری را فرض کند. Secret یا Work item حساس را بدون Policy به مدل ندهید؛ Apply نیازمند همان Sandbox، Authority و Rollback است.
آزمایشگاه آفلاین ایرانی SYN-JIRA-QA-IR-۰۱
برای آزمودن روش بدون دستزدن به Site واقعی، مدل حافظهای کاملاً ساختگی ساختیم: Space «پرداخت-نمونه»، Work itemهای خیالی PAY-۱۰۱ تا PAY-۱۲۴ و Journeyهای Checkout/Order/PaymentAttempt/PSP Stub/Callback/Ledger/Reconciliation. هیچ Jira site، User، Employee، Customer، Work item، Attachment، Automation run یا Release decision واقعی هدف نبود.
Fixture شامل IRR canonical، تومان صرفاً presentation، ارقام فارسی/عربی/لاتین، ی/ی و ک/ک، ZWNJ، RTL/LTR/Bidi، UTC، Asia/Tehran و جلالی صرفاً نمایشی بود. Token، Email، Domain، Screenshot و Actor همگی Dummy بودند. مدل به Atlassian، Marketplace، Email یا Product واقعی وصل نشد.
Configuration بد چه وعدهای میداد؟
نسخهٔ بد Jira را سازندهٔ خودکار شفافیت میدانست؛ هر Signal را Bug میکرد؛ Priority را از Severity کپی میکرد؛ Medium را Default میگذاشت؛ «هر باگ یک Ticket» و «همیشه Screenshot/video» را Rule میکرد؛ به QA اجازه میداد هر Fix را Done کند؛ Resolution را در Reopen پاک نمیکرد؛ Filter شخصی را به Board و Automation وصل میکرد؛ و نمودار Bug count را «کیفیت محصول» مینامید.
یک Rule با Actor ادمین روی هر Edit دوباره Trigger، Comment تکراری و Notification میساخت؛ Smart value خالی را «Unknown» پنهان میکرد؛ Attachment ساختگی حاوی Dummy token بود؛ JQL Permission blindness داشت و Audit retention دائمی فرض شده بود. Checker سطحی این شعارها را موفقیت دانست و بهاشتباه نوشت:
JIRA_AUTO_TRANSPARENCY_ONE_BUG_ONE_TICKET_ALWAYS_SCREENSHOT_QA_DONE_DASHBOARD_QUALITY_READY
Validator چرا HOLD-۹۱۰ داد؟
Validator مستقل، قطعی و بدون وابستگی خارجی دقیقاً ۹۱۰ کنترل یکتا را در ۷۰ گروه Identity، As-of، Platform، Edition، Space، Model، Role، Authority، Work item، Issue type، Field، Context، Screen، Permission، Security، Classification، Confidentiality، Evidence، Attachment، Redaction، Workflow، Status، Transition، Condition، Validator، Action، Resolution، Reopen، Triage، Priority، Severity، Disposition، Duplicate، Linkage، Hierarchy، Board، Column، WIP، Sprint، JQL، Filter، Dashboard، Metric، Automation، Trigger، Rule condition، Branch، Smart value، Actor، Idempotency، Loop، Audit، Retention، Notification، Integration، API، Rate limit، Schema، Mapping، Migration، Sandbox، Test، Rollback، Monitoring، Ownership، Review، Expiry، Correction، AI و Limits شمرد. ID فاقد Group یا تکراری رد شد.
HOLD-910 NO_REAL_JIRA_SITE_USER_EMPLOYEE_CUSTOMER_WORK_ITEM_ATTACHMENT_RELEASE_PASS
Hold دربارهٔ مهارت تستر یا کیفیت Jira نبود؛ Configuration fixture برای Flow audit آماده نبود. قاعدهٔ مستقل نبود Target واقعی را تأیید کرد. Validator امنیت Site، صحت Product، کاملبودن Evidence، Permission واقعی یا Release را اثبات نمیکند.
تعمیر Fixture و نتیجهٔ محدود
Instance/Authority/Field/Transition contractها Pin شدند؛ Severity از Priority جدا شد؛ Null قابل مشاهده ماند؛ Attachment پاکسازی و دسترسی منفی آزموده شد؛ Resolution در پایان Set و Reopen Clear شد؛ Filter service-owned و Query fixtureدار شد؛ Automation actor محدود، event marker و Loop guard گرفت؛ Smart valueهای null/malformed آزموده شدند؛ Replay نتیجهٔ واحد ساخت؛ Dashboard به سؤال/Population/Limit وصل شد؛ Migration dry-run و rollback گذشت.
READY_FOR_JIRA_QA_FLOW_AUDIT_REVIEW-0
صفر فقط یعنی در مدل مصنوعی فیلد کنترلنشده باقی نمانده است. تصمیم مجاز «آماده برای بازبینی Flow audit» بود، نه اثبات شفافیت، کیفیت محصول، صلاحیت فرد یا ایمنی هر Jira Instance.
۲۸ ضدالگوی Jira برای QA
- Jira خودکار شفافیت میسازد.
- هر Signal یک Bug است.
- هر Bug دقیقاً یک Ticket است.
- همیشه Screenshot یا Video لازم است.
- Priority همان Severity است.
- Default، Missing را پنهان میکند.
- نام Status معنای کافی دارد.
- Column همان State است.
- Done بدون Resolution درست است.
- Reopen بدون Clear resolution است.
- QA همیشه صاحب Closure است.
- Reject بدون Reason/Appeal است.
- Duplicate فقط با Summary تشخیص داده میشود.
- Link جهت و semantics ندارد.
- Sub-task برای هر Browser ساخته میشود.
- Sprint membership کیفیت را ثابت میکند.
- JQL syntax صحیح یعنی دادهٔ کامل.
- Filter شخصی Consumer حیاتی دارد.
- Dashboard Bug count کیفیت محصول است.
- Automation actor ادمین دائمی است.
- Rule Replay و Loop test ندارد.
- Smart value خالی با Default پنهان میشود.
- Audit log دائمی فرض میشود.
- Notification برابر دریافت تصمیم است.
- Integration بدون event receipt است.
- Bulk edit بدون Dry-run/Rollback است.
- Production data به Sandbox کپی میشود.
- AI diff بدون Review Apply میشود.
چکلیست ۴۸ نقطهای پیش از فعالسازی Flow
- Platform/Plan/Space model تاریخدار است.
- Owner و Admin جدا شدهاند.
- Authority matrix تصویب شده است.
- Work typeها Inclusion/Exclusion دارند.
- Intake و Security route روشن است.
- هر Field سؤال تصمیمی دارد.
- Null meaning تعریف شده است.
- Default دادهٔ ساختگی نمیسازد.
- Contextها همپوشانی ناخواسته ندارند.
- Screenها Progressive validation دارند.
- API/Smart-value path ثبت است.
- Summary دادهٔ حساس ندارد.
- Evidence manifest وجود دارد.
- Attachment redaction بازبینی شده است.
- Permission منفی آزموده شد.
- Work-item security از Space جداست.
- Severity/Priority/Urgency جدا هستند.
- هر Status معنای یکتا دارد.
- Entry/Exit evidence ثبت است.
- Column mapping بررسی شد.
- Transition جهت و Authority دارد.
- Input/Condition/Validator/Action روشناند.
- Error message اقدامپذیر است.
- Resolution در پایان Set میشود.
- Reopen Resolution را Clear میکند.
- Verification از Closure جداست.
- Disposition Reason/Owner دارد.
- Duplicate canonical/evidence را حفظ میکند.
- Link semantics و جهت دارد.
- Board filter Blind spot ثبت دارد.
- WIP exception و owner دارد.
- Sprint interpretation محدود است.
- JQL Query contract دارد.
- Positive/negative/null fixtures گذشت.
- Filter service owner دارد.
- Dashboard سؤال/Population/Limit دارد.
- Metric denominator/timezone روشن است.
- Automation actor کماختیار است.
- Smart value null/malformed آزموده شد.
- Replay و Loop guard گذشت.
- Partial failure جبران دارد.
- Audit retention و archive روشن است.
- Notification Ack/Escalation دارد.
- Integration event receipt دارد.
- API batch dry-run/reconciliation دارد.
- Migration Sandbox و stop rule دارد.
- Rollback واقعاً آزموده شد.
- Owner/monitor/review/expiry/correction ثبت است.
برنامهٔ ۳۰روزهٔ پیادهسازی بدون Site واقعی
روزهای ۱ تا ۳ Instance/Role/Authority؛ ۴ تا ۷ Work type/Field/Context/Screen؛ ۸ تا ۱۱ Workflow/Transition/Resolution/Reopen؛ ۱۲ تا ۱۴ Evidence/Privacy/Permission؛ ۱۵ تا ۱۷ JQL/Filter/Dashboard/Metric؛ ۱۸ تا ۲۱ Automation/Smart value/Replay/Audit؛ ۲۲ تا ۲۴ Integration/API/Notification؛ ۲۵ تا ۲۷ Sandbox/Migration/Rollback؛ ۲۸ Access review؛ ۲۹ Receiver handoff؛ ۳۰ Audit report/expiry. همهٔ Fixtureها ساختگیاند.
سوالات متداول Jira برای تستر و QA
آیا QA باید باگ رفعشده را به Done ببرد؟
نه بهصورت قانون عمومی. Authority matrix مشخص میکند چه کسی Verification و چه کسی Closure را انجام میدهد. Transition باید Build evidence، Oracle، Resolution و residual risk را طبق قرارداد بررسی کند.
Severity و Priority در Jira چه تفاوتی دارند؟
Severity اثر مشاهدهشده را مدل میکند؛ Priority ترتیب رسیدگی را در میان کارها. Jira Priority قابل سفارشیسازی است و Severity معمولاً Field قراردادی تیم است. کپی خودکار یکی به دیگری بدون Decision policy نادرست است.
آیا هر باگ باید یک Ticket جدا داشته باشد؟
Atomicity به Failure mechanism، Owner، Fix، Deploy، Verify و Rollback بستگی دارد. چند مشاهده با Cause و مسیر یکسان ممکن است یک Canonical item بخواهند؛ یک Summary مشابه با Cause متفاوت نباید بیدلیل Merge شود.
بهترین JQL برای باگهای باز چیست؟
Query جهانی نداریم. Work type، Space، Resolution semantics، Permission، Archive و Null policy Instance را وارد Query Contract کنید. نتیجه فقط Itemهای قابلدیدن و منطبق را نشان میدهد، نه تمام نقصهای واقعی محصول.
آیا Jira بهتنهایی برای مدیریت Test case کافی است؟
به نیاز شما بستگی دارد. Work tracking با Test repository، plan، execution، evidence و reporting یکسان نیست. Capability gap را بنویسید و Add-on یا ابزار مستقل را با Permission، integration، TCO و Exit در PoC بسنجید.
جمعبندی: Jira را حافظهٔ حقیقت ننامید؛ Flow قابل ممیزی بسازید
Jira فقط آنچه را تیم با Field، Workflow، Permission، Query و Rule طراحی و وارد کرده نگه میدارد. برای QA، ارزش آن زمانی شکل میگیرد که Signal به Work item درست Route شود، Evidence امن بماند، Authority و Transition قابل دفاع باشند، Resolution و Reopen معنا را حفظ کنند، JQL محدودیت خود را اعلام کند و Automation بدون Loop یا تغییر پنهان عمل کند.
قبل از فعالسازی، Contractها را بیرون از UI روشن کنید؛ در Sandbox مصنوعی Positive/Negative/Null/Permission/Replay/Migration را آزمایش کنید؛ Rollback را اجرا کنید و Owner، Audit، Expiry و Correction را ثبت کنید. خروجی حرفهای یک Dashboard زیبا نیست؛ زنجیرهای است که از مشاهده تا تصمیم و Closure را بدون اغراق، نشت داده یا گمکردن مسئولیت بازسازی میکند.
