فانفلوئنانگلیسی برای برنامه‌نویس‌ها؛ توضیح باگ و جلسه‌ی فنی
برای برنامه‌نویس‌ها: باگ رو دقیق به انگلیسی توضیح بده، blocker و code review رو مدیریت کن و گزارش ۳۰ ثانیه‌ای رو به یک issue کوتاه تبدیل کن.
وقتی به انگلیسی توی جلسهٔ فنی می‌گی The page is broken، هم‌تیمی هنوز نمی‌دونه کدوم صفحه، بعد از چه کاری و با چه نشانه‌ای مشکل داشته. به‌جای شروع از حدسِ علت، بگو کجا و چه کار کردی، واقعاً چی دیدی، انتظار داشتی چی بشه، چه چیزی رو بررسی کردی و الان از تیم چه کمکی می‌خوای. این پایهٔ خوبی برای انگلیسیِ کاربردیِ برنامه‌نویس‌ها در گزارش باگ و گفت‌وگوی کاریه.
مثلاً در یک اپلیکیشنِ کاملاً خیالی، صفحهٔ تنظیمات حساب رو در نظر بگیر. جواب مبهم اینه: The profile page is broken. I think it's a backend problem. ولی این چند جملهٔ تألیفی دقیق‌تر می‌گن چه اتفاقی افتاده:
On the profile settings page, Save stays disabled after I select weekly alerts. I expected it to become available. So far, I've only checked this in my test account; I haven't confirmed the cause. Could someone try the same change?
این باگ، حساب تست و انتظارِ رفتار ساختهٔ نویسنده برای آموزش هستند؛ هیچ مشکلِ واقعی یا آزمایشِ انجام‌شده‌ای رو گزارش نمی‌کنن. همین مثال یک فرقِ مهم داره: «دکمه غیرفعاله» مشاهده است؛ «حتماً backend خرابه» حدسِ تأییدنشده. تمام جمله‌ها، تمرین‌ها و گفت‌وگوهای انگلیسیِ این مقاله تألیفی‌اند و از نمونه‌های مستندات یا مقاله‌های دیگه کپی نشده‌اند.
وقتی باگ رو توضیح می‌دی، از مشاهده شروع کن؛ بعد سراغ فرضیه برو
برای انگلیسیِ فنی، لازم نیست شش اصطلاح سخت پشت هم بگی. این «نردبانِ شواهد» یک روشِ تمرینیِ خودمونه، نه قالبِ رسمی GitHub، Jira یا قانونِ همهٔ تیم‌ها. بسته به شنونده ممکنه دو پله رو تو یک جمله خلاصه کنی.
- کجا و بعد از چی؟ (Where/when): صفحه، نقش کاربر، عملِ انجام‌شده و شرطِ مهم. It happens after I choose the weekly option on the settings page.
- چی دیدم و چی انتظار داشتم؟ (Observed/expected): دو چیز رو جدا بگو. Save remains inactive; I expected to be able to confirm the new setting. انتظار باید از رفتارِ مورد نظرِ واقعی بیاد؛ اگر مطمئن نیستی از صاحب تصمیم بپرس.
- اثر و دامنهٔ شناخته‌شده (Impact/scope): این مشکل برای کاربر چه کاری رو متوقف می‌کنه و خودت دقیقاً کجا دیدی؟ I can't save the new choice in my test flow; I don't know whether live users see it.
- چی رو واقعاً بررسی کردم؟ (Checked): فقط کاری رو بگو که انجام شده. I checked the same step in my local test account. اگر هنوز آزمایش نکردی از گذشتهٔ انجام‌شده استفاده نکن.
- علتِ احتمالی، با برچسبِ احتمال (Hypothesis): اگر لازم بود I suspect the change isn't being detected, but I haven't verified that. این با «علت قطعاً مشخصه» یکی نیست.
- سؤال یا اقدامِ بعدی (Ask/next step): یک درخواستِ قابل انجام بده: Could you try the same steps on another test device and tell me what you see? تا توافق نشده، صاحبِ کار یا موعد نهایی اعلام نکن.
برای سرنخ‌های فنی مثل متنِ خطا هم همین مرز مهمه. در مرجع خطاهای JavaScript در MDN، نام و پیامِ خطا به‌عنوان سرنخ برای بررسی مطرح می‌شن؛ اما متنِ یک خطا همیشه علتِ مشکل رو روشن نمی‌کنه. از این منبع هیچ پیامِ خطا یا کدی رو اینجا کپی نکردیم. وقتی هنوز ریشهٔ مشکل پیدا نشده، با انگلیسیِ مطمئن وانمود نکن پیداش کرده‌ای.
شش حرکتِ گفتاری برای گزارش باگ، blocker و تصمیم فنی
هر کارت یک موقعیتِ مشخصِ تیم توسعه رو آموزش می‌ده؛ مثال‌ها کوتاه، انگلیسی و کاملاً نویسنده‌ساخته هستند. به‌جای حفظ‌کردنِ کارت، رفتار یا ریسکِ واقعیِ خودت رو جاش بذار.
۱. «چی دیدم» رو از «چی باید می‌دیدم» جدا کن
Original practice example
When I choose weekly alerts on the profile page, the Save button stays disabled. I expected it to become available so I could save the change.
stays disabled رفتارِ دیده‌شده است و I expected... انتظاره. دربارهٔ یک اپِ خیالی حرف می‌زنیم که قرار بوده این انتخاب قابل ذخیره باشه؛ این جمله هیچ علتِ فنی‌ای رو اثبات نمی‌کنه.
برای باگِ واقعیِ خودت، از رفتارِ قابل دیدن شروع کن. اگر هنوز نمی‌دونی انتظارِ صحیحِ محصول چی بوده، به‌جای ساختنِ requirement بپرس What should happen after this step?
۲. محدودهٔ چیزی رو بگو که واقعاً بررسی کردی
Original practice example
So far, I've only seen this in a local test account after changing the alert setting. I haven't tried the same flow on another device.
So far و only محدودهٔ مشاهده رو روشن می‌کنن. از «توی حساب تست دیدم» نمی‌شه نتیجه گرفت «همهٔ کاربران مشکل دارن». این حساب و باگ هم سناریوی تألیفی‌ان.
وقتی مطمئنی با چند قدم می‌تونی دوباره نشانه رو ببینی، می‌تونی از I can reproduce it when... استفاده کنی؛ برای یک مشاهدهٔ تک‌باره بهتره بگی I observed it once when...
۳. حدسِ علت رو با برچسبِ حدس بیان کن
Original practice example
My current hypothesis is that the page isn't detecting the changed setting, but I haven't confirmed the root cause.
My current hypothesis یعنی «فرضِ فعلیِ من». root cause یعنی علتِ ریشه‌ایِ مشکل؛ دیدنِ یک نشانه یا متنِ خطا، به‌تنهایی تأییدش نمی‌کنه.
اگر هنوز بررسیِ کد، داده یا لاگ رو انجام ندادی، نگو The backend is definitely broken. در مکالمهٔ واقعی ممکنه اصلاً لازم نباشه فرضیه رو مطرح کنی؛ مشاهده و سؤالِ بعدی کفایت می‌کنه.
۴. توی استندآپ، blocker رو به یک درخواست تبدیل کن
Original practice example
I reviewed the settings flow yesterday. Today I'm checking why the Save control stays inactive, but I need the intended behavior confirmed. Could someone from product clarify it?
جمله از «دیروز چه کاری کردم» به «الان کجا گیر دارم» و بعد «از تیم چه چیزی می‌خوام» می‌رسه. blocked فقط گزارشِ مشکل نیست؛ اگر می‌تونی، وابستگیِ مشخص رو نام ببر.
فقط از reviewed، fixed یا tested وقتی استفاده کن که همان کار واقعاً انجام شده. این قالب، قانون اجباریِ همهٔ تیم‌های agile نیست.
۵. در code review، نگرانی رو به تست وصل کن
Original practice example
I see why moving the retry check earlier could simplify the flow. I'm concerned it might skip a valid second attempt. Could we test that case before deciding?
اول منطقِ پیشنهادِ همکار رو می‌فهمی، بعد یک ریسکِ احتمالی رو می‌گی و یک آزمایشِ مشخص پیشنهاد می‌دی. might یعنی هنوز نتیجه ثابت نشده؛ این مثال هیچ رفتارِ واقعیِ retry رو گزارش نمی‌کنه.
وقتی review واقعی داری، با یک سناریوی شکست یا سؤالِ قابل بررسی مخالفت کن. لازم نیست همیشه بگی «شما اشتباه می‌کنی» یا بدون داده ادعا کنی نسخهٔ تو سریع‌تره.
۶. trade-off رو با یک معیارِ تصمیم‌گیری توضیح بده
Original practice example
A simpler first screen could require an extra request later. We haven't measured the effect, so could we compare both options before choosing?
trade-off یعنی به دست آوردنِ یک مزیت در برابر هزینه یا محدودیتِ احتمالیِ دیگه. اینجا «درخواستِ بیشتر» یک احتمالِ طراحی است، نه benchmark ثبت‌شده. عبارتِ haven't measured مرز دانسته‌ها رو روشن می‌کنه.
بپرس تیم باید بین چه چیزهایی تصمیم بگیره: سادگیِ مسیرِ کاربر، تعداد درخواست‌ها یا رفتارِ واقعیِ اندازه‌گیری‌شده؟ تا تست نکرده‌ای، هیچ گزینه‌ای رو «قطعاً سریع‌تر» معرفی نکن.
تو گفت‌وگوی واقعی تیم، سؤال بعدیِ همکار چیه؟
یک توضیحِ خوب فقط خوب به نظر نمی‌رسه؛ باید بشه بهش سؤالِ قابل بررسی اضافه کرد. این هفت دیالوگِ خیالی دربارهٔ گزارش باگ، کمک‌خواستن، استندآپ، review و ریسکِ تصمیم‌اند. هیچ‌کدوم لاگ، تست، incident یا مسئلهٔ واقعیِ یک شرکت نیستند.
1. QA می‌گه «ذخیره نمی‌شه»؛ دقیقاً کدوم علامت؟
در یک نرم‌افزارِ خیالی QA رفتارِ صفحهٔ پیش‌نویس رو مبهم توصیف کرده. هنوز علت معلوم نیست.
Original practice dialogue
QA: The note doesn't seem to save.
Developer: Does the Save button stay inactive, or does the note disappear after you reopen the page?
QA: It looks saved at first, but the new text isn't there when I reopen the note.
Developer: Thanks, that helps. Could you tell me which action you take right before reopening it?
«پیام موفقیت نمی‌آد» با «مقدار بعد از بازکردن عوض شده» یک نشانه نیست. پرسشِ توسعه‌دهنده دنبالِ رفتارِ مشاهده‌شده و مرحلهٔ قبل از اون می‌ره، نه یک علتِ از پیش محکوم‌شده.
2. برای کمک گرفتن، محدودهٔ بررسی رو صادقانه بگو
این نمونه فقط یک محیط آزمایشیِ خیالی رو توصیف می‌کنه؛ هیچ API یا لاگِ واقعی از جایی برداشته نشده.
Original practice dialogue
Developer: The upload preview keeps spinning after I select an image in our test environment.
Teammate: Have you checked whether other file types behave the same way?
Developer: Not yet. I've only tried the image flow. Could you help me decide which safe request details we should check next?
Teammate: Let's first agree on the exact steps and what we can inspect.
«در یکی از حالت‌ها دیدم» رو به «برای همهٔ فایل‌ها خراب است» تبدیل نکن. از همکار درخواستِ بررسیِ مشخص داشته باش و اگر لاگ یا دادهٔ تست حساسه، اطلاعات شخصی، توکن و رمز رو در پیام عمومی نذار.
3. در گزارشِ کوتاهِ تیم، «انجام دادم» با «حل شد» فرق داره
یک آپدیتِ فرضی برای یک گفت‌وگوی کاریِ روزانه، نه آموزشِ کاملِ Scrum.
Original practice dialogue
Team lead: What's the current status of the notification setting?
Developer: I reviewed the control states. The Save button still looks inactive in the test flow.
Team lead: What's holding up the next step?
Developer: I need confirmation of the intended behavior before I change it. Could we ask product to clarify that?
فعلِ reviewed یعنی بررسی کردم؛ هنوز fixed نگفته‌ای. Blocker رو به یک پاسخ یا تصمیمِ مشخص وصل کن، بدون اینکه زمانِ تحویل بسازی.
4. پیشنهادِ reviewer رو می‌فهمی ولی دربارهٔ یک ریسک سؤال داری
یک سناریوی خیالی از PR که در اون اثرِ پیشنهاد هنوز تست نشده.
Original practice dialogue
Reviewer: Could we move this retry check to an earlier step?
Developer: That may simplify the path. I'm wondering whether it could also block a valid retry.
Reviewer: Which case are you concerned about?
Developer: The second attempt after a temporary interruption. Could we test that path before merging?
نگفتی «پیشنهادت غلطه» و ادعا نکردی ریسک حتماً رخ می‌ده. با یک حالتِ قابل آزمایش گفت‌وگو رو جلو می‌بری؛ نتیجهٔ تست رو از قبل گزارش نمی‌کنی.
5. دربارهٔ trade-off با طراح یا محصول حرف می‌زنی
تصمیم طراحی در این گفت‌وگو هنوز اندازه‌گیری یا تصویب نشده.
Original practice dialogue
Designer: Could we show fewer controls on the first screen?
Developer: Possibly, but that approach may need an extra request after the user opens the next section.
Designer: Would that make the flow slower?
Developer: I don't know yet. Could we agree on what to measure and compare the alternatives?
درخواستِ بیشتر همیشه به معنای تجربهٔ بدتر نیست. I don't know yet ضعف نیست؛ فرقِ تحلیلِ احتمال با نتیجهٔ اندازه‌گیری‌شده رو نگه می‌داره.
6. آپدیتِ حادثه: دامنهٔ ناشناخته رو عمومی نکن
در محیط تستِ خیالی، برچسب وضعیت بعد از عوض‌کردنِ تب تازه نمی‌شه. هیچ داده‌ای از کاربران واقعی نداریم.
Original practice dialogue
Team lead: What can we confirm about the stale status label?
Developer: In one test account, the status text didn't refresh after I switched tabs. I haven't verified whether it affects the live service.
Team lead: Do we know the cause?
Developer: Not yet. I'm checking the steps we can reproduce and will share what we actually confirm.
از یک نشانهٔ تستی به «همهٔ کاربران مشکل دارند» یا «علت پیدا و حل شد» نپر. این فقط آموزشِ جمله‌بندیِ دقیقِ آپدیت است، نه دستورالعمل مدیریت incident واقعی.
7. تغییرِ کد انجام شده، ولی تأییدِ رفع باگ هنوز نه
توسعه‌دهنده باید بین انجام تغییر و نتیجهٔ تأییدشده فرق بذاره.
Original practice dialogue
Colleague: Is that settings issue fixed now?
Developer: I've changed the relevant UI behavior, but I haven't rechecked the second device yet.
Colleague: So should we call it resolved?
Developer: Not yet. I'd rather confirm the affected flow before saying it's resolved.
I've changed... دربارهٔ کاریه که کردی؛ It's resolved دربارهٔ وضعیتِ نتیجه. این دو رو بدون بررسی به یک معنی استفاده نکن.
چند عبارت کوتاه که واقعاً به یک کار می‌چسبن
فهرستِ صدتا اصطلاح لازم نیست. این جمله‌های کوتاه، هرکدوم یک کارِ ارتباطی انجام می‌دن. موقعیتِ استفاده‌شون مهم‌تر از حفظِ تک‌تکشونه:
- بازتولیدِ قابل اتکا: I can reproduce it when I switch tabs while the preview is open. فقط وقتی استفاده کن که خودت بتونی با همان شرایط دوباره نشانه رو ببینی. اگر تنها یک بار دیدی، بگو I observed it once after switching tabs.
- رفتارِ مورد انتظار: The expected behavior is that the selected option remains saved after I reopen the page. وقتی انتظار واقعاً مشخصه.
- محدودهٔ نامعلوم: I've only checked the test environment; the wider impact is still unknown. با یک مشاهده، کل کاربران رو درگیر اعلام نکن.
- فرضیهٔ باز: One possible cause is the update step, but I haven't ruled out other explanations. ممکنه، نه قطعاً.
- درخواستِ نگاه دوم: Could you sanity-check the steps I used to reproduce this? در لحنِ غیررسمیِ تیم فنی، sanity-check یعنی از یک نفر بخوای یک بررسیِ سریع و مستقل انجام بده؛ لازم نیست همه جا همین اصطلاح رو به کار ببری.
- ریسکِ طراحی: The trade-off may be simpler navigation at the cost of an additional request. Should we compare the two options? بدون معیار یا تست، نتیجهٔ نهایی نساز.
عبارت‌هایی مثل intermittent رو برای مشکلِ گاه‌وبی‌گاه به کار ببر فقط وقتی واقعاً چند بار رفتارِ متفاوت دیده‌ای؛ flaky در بعضی تیم‌ها بیشتر برای تست‌هایی به کار می‌ره که گاهی رد می‌شن و گاهی قبول، نه هر باگِ نامعلوم. همین‌طور I changed the code به معنیِ I confirmed the fix works نیست.
اول اثرِ کاربر رو بگو؛ بعد اصطلاحِ implementation رو باز کن
وقتی مخاطبت QA یا محصوله، توضیح رو از چیزِ قابل مشاهده شروع کن: After I select the new alert option, I can't save the choice. اگر با همکارِ فنی متخصص و دربارهٔ علتِ احتمالی حرف می‌زنی، می‌تونی بعداً بگی I suspect the form may not be updating its changed state, but I need to verify it. دومی حدس است و اولی علامت. در راهنمای نوشتن برای مخاطب در Google Technical Writing هم روی انتخابِ توضیح متناسب با دانسته‌های مخاطب تأکید می‌شه؛ این یک راهنمای نگارشی است، نه آمارِ بهره‌وری یا اثباتِ علمیِ تمرین ما.
اگر هم‌تیمی گفت It doesn't save، اول مشخص کن «پیامِ تأیید نمی‌آد»، «دکمه کار نمی‌کنه» یا «مقدار بعد از بازکردن برمی‌گرده»؛ بعد سؤالِ مناسبِ backend یا frontend رو بساز. پنج اسم فایل یا اصطلاحِ معماری، بدون یک نشانهٔ قابل مشاهده، طرف مقابل رو به اصلِ مسئله نزدیک نمی‌کنه.
دو موقعیتِ انتخاب پاسخ: قبل از دیدنِ تحلیل، بلند بگو
این‌ها تمرینِ تشخیص و مکالمه‌اند، نه آزمون استخدام یا ارزیابیِ رسمی کد. اول پاسخِ خودت رو بگو؛ بعد هر بخش رو باز کن. سناریوها و رفتارِ نرم‌افزارها کاملاً ساختگی‌اند.
موقعیت اول: فایلِ گزارش دانلود نمی‌شه
در یک برنامهٔ فرضی، بعد از انتخابِ بازهٔ تاریخ، دکمهٔ Download هیچ واکنشی نشون نمی‌ده. فقط با یک حسابِ تست بررسی کردی و هنوز علت رو نمی‌دونی. کدوم پیام برای هم‌تیمی مفیدتره؟
A: Downloads are broken. The server is down, so someone needs to fix the backend.
B: On the reports page, Download doesn't respond after I choose a date range. I expected a file prompt. I've only checked my test account. Could you try that path?
کدوم گزارش شواهد و حدس رو جدا می‌کنه؟ بازش کن
B زمینه، عمل، مشاهده، انتظارِ فرضی و دامنهٔ بررسی رو جدا کرده، سپس یک سؤالِ مشخص پرسیده. A بدون شواهد علت رو به سرور نسبت می‌ده. البته اگر دربارهٔ رفتارِ مورد انتظار مطمئن نیستی، باید بپرسی What should the download action do here? و اون رو از خودت نسازی.
نوبت تو: یک باگِ واقعی و غیرمحرمانه از کار خودت رو انتخاب کن. فقط جملهٔ اول رو با «کجا + بعد از چه اقدامی + چه علامتی» بساز؛ هیچ علتِ فنی اضافه نکن.
موقعیت دوم: توی code review با یک پیشنهاد موافق نیستی
در PR فرضی، reviewer می‌خواد نتیجهٔ تب قبلی در حافظهٔ موقت نگه داشته بشه. تو نگران نمایشِ وضعیتِ قدیمی هستی، اما هنوز تست نکردی. کدوم پاسخ قابل گفت‌وگوتره؟
A: You're wrong. My approach is obviously faster, so we should keep it.
B: I see why caching that value may help. I'm concerned it could show an older status after the user switches tabs. Could we test that case before deciding?
کدوم جواب اختلافِ نظر رو به بررسی مشترک تبدیل می‌کنه؟
B نظرِ همکار رو درست بازتاب می‌ده، نگرانی رو با could به‌عنوان احتمال بیان می‌کنه و یک سناریوی تست می‌سازه. A هم‌تیمی رو متهم می‌کنه و سریع‌تر بودن رو بی‌هیچ اندازه‌گیری قطعی می‌دونه. B هم به معنیِ اثباتِ وجودِ باگ یا کاراییِ راه‌حل نیست.
نوبت تو: یکی از تصمیم‌های فنیِ خودت رو انتخاب کن و با جملهٔ My concern is ... . Could we test ... ? یک ریسکِ مشخص و یک بررسیِ قابل اجرا پیشنهاد بده.
تمرینِ اصلی: یک باگ رو در ۳۰ ثانیه بگو، بعد چهار جمله بنویس
حالا از یک نمونهٔ واقعی، قابل توضیح و بدون دادهٔ محرمانه از کار خودت استفاده کن. اگر چنین نمونه‌ای نداری، یکی از باگ‌های خیالیِ همین صفحه رو برای تمرین انتخاب کن و روشن بگو تمرینیه.
- نسخهٔ گفتاری: در حدود ۳۰ تا ۴۵ ثانیه بگو کجا/بعد از چی باگ رو دیدی، واقعاً چی رخ داد، انتظار چی بود، در چه محدوده‌ای بررسی کردی و دقیقاً چه کسی یا چه تستی رو از تیم می‌خوای. این زمان فقط پیشنهادِ تمرین شخصیه، نه قانونِ جلسه‌های فنی.
- یک جمله رو دقیق‌تر کن: It doesn't work رو با یک فعل و نشانهٔ قابل دیدن جایگزین کن؛ مثلاً The button stays inactive after the setting changes.
- نسخهٔ نوشتاری: همون حقایق رو در سه تا پنج جملهٔ کوتاه برای issue یا comment بنویس؛ مشکل رو با کپی‌کردنِ کورکورانهٔ قالبِ یک ابزار گزارش نکن. مستندات رسمی GitHub Issues توضیح می‌ده issues می‌تونن برای پیگیری باگ و درخواست‌ها استفاده بشن؛ اینجا قصد نداریم فرم، template یا مراحلِ UI اون رو کپی کنیم.
نمونهٔ نوشتاریِ کاملاً تألیفی برای همان برنامهٔ فرضی:
On the preferences screen, Save remains disabled after I select weekly alerts. In this example, it should let the user confirm the new choice. I've checked the flow only in a local test account, and the root cause is still unknown. Could someone verify the same action in another test environment?
توی نسخهٔ شفاهی، شنونده باید بتونه سؤالِ بعدی بپرسه. توی نسخهٔ نوشتاری، همکار باید بتونه بفهمه از کجا شروع به بررسی کنه. اگر یک داده یا پیامِ خطا رو از روی حافظه حدس می‌زنی، یا روشن بگو «مطمئن نیستم» یا از متن حذفش کن. هرگز گذرواژه، توکن، اطلاعاتِ شخصیِ مشتری، لینک‌های خصوصی یا لاگِ خامِ محرمانه رو داخل تمرین/issue عمومی نذار.
تمرینِ ۱۰ دقیقه‌ای برای گزارش و بازنویسیِ خودت
این روتین یک تمرینِ ساختهٔ نویسنده است، نه روشِ اثبات‌شدهٔ افزایش بهره‌وری یا شرطِ تیم‌های توسعه. اگر می‌خوای، فقط صدای خودت رو خصوصی ضبط کن و به حرفِ دیگران بدون رضایت دسترسی یا ضبط نداشته باش.
- دقیقهٔ اول: یک باگِ غیرمحرمانه و معلوم یا یک مثالِ فرضی انتخاب کن؛ اسم کاربر و جزئیات حساس رو حذف کن.
- دقیقهٔ دوم: محل و یک اقدامِ مشخص رو بنویس: دقیقاً بعد از کدوم تغییر یا کلیک اتفاق افتاد؟
- دقیقهٔ سوم: رفتارِ دیده‌شده رو از رفتارِ مورد انتظار جدا کن؛ اگر انتظار مشخص نیست، یک سؤال دربارهٔ requirement بساز.
- دقیقهٔ چهارم: اثرِ شناخته‌شده و دامنهٔ بررسی رو محدود کن: فقط test account؟ فقط یک بار؟ بخش‌های دیگه هنوز بررسی نشده؟
- دقیقهٔ پنجم: فقط بررسیِ انجام‌شده رو بگو؛ فرضیهٔ علت رو با I suspect... مشخص کن یا فعلاً حذف کن.
- دقیقهٔ ششم: یک بار گزارشِ ۳۰ تا ۴۵ ثانیه‌ای رو بلند بگو و در پایان یک درخواستِ روشن اضافه کن.
- دقیقهٔ هفتم: نقشِ QA رو بازی کن: Where did you see it, and what did you try? کوتاه و فقط با دادهٔ واقعی جواب بده.
- دقیقهٔ هشتم: نسخهٔ نوشتاریِ سه تا پنج جمله‌ای رو برای یک issue/comment تمرینی بساز؛ هیچ قالب یا کدِ واقعی رو کپی نکن.
- دقیقهٔ نهم: در نقش reviewer، یک ریسکِ احتمالی و یک تستِ پیشنهادی رو بدون قطعیتِ ساختگی بیان کن.
- دقیقهٔ دهم: پنج موردِ زیر رو بررسی و فقط یک ادعای بیش‌ازحد یا جملهٔ مبهم رو تعمیر کن.
بعد از گفتن و نوشتنِ گزارش، چی رو چک کنم؟
این چک‌لیست صرفاً تمرینِ دقت در ارتباطِ فنیه؛ جایِ تست، بازبینی امنیتی، اولویت‌بندی واقعی یا روشِ گزارش‌دهیِ پروژهٔ خودت رو نمی‌گیره.
یک سؤال فنیِ خوب برای مکالمهٔ بعدی
اگه از این صفحه فقط یک حرکت نگه داری، این باشه: به‌جای Something is broken با When I ..., I observed ... . I expected ... . I've only checked ... . Could you ...? جوابِ واقعیِ خودت رو بساز. اگه علت رو نمی‌دونی، اضافه کن I haven't confirmed the cause yet.
حالا یک مورد از کارِ غیرمحرمانهٔ خودت رو بردار و همون رو یک‌بار شفاهی و یک‌بار در چند جملهٔ مکتوب توضیح بده. هدفِ این تمرین «پرزرق‌وبرق حرف‌زدن» نیست؛ اینه که مخاطبت بدونه چی دیدی، چی هنوز معلوم نیست و قدمِ بعدیِ قابل بررسی چیه.