یک تستر می‌گوید «Postman بلدم»؛ دیگری یک جریان سفارش را مدل می‌کند، مجوزها و حالت‌های خطا را می‌سنجد، Assertion کسب‌وکار می‌نویسد و یافته را به تصمیم انتشار وصل می‌کند. نام ابزار یکسان است، اما سطح مهارت تست نرم‌افزار یکسان نیست.

این راهنما به‌جای فهرست بلند فناوری‌ها، ۱۴ مهارت کارشناس QA را به رفتار قابل‌مشاهده تبدیل می‌کند. با ماتریس چهارسطحی، تمرین عملی و برنامه شش‌هفته‌ای می‌توانید شکاف واقعی خود را پیدا کنید؛ بدون اینکه تصور کنید هر تستر باید هم‌زمان متخصص Kubernetes، امنیت، عملکرد، موبایل و AI باشد.

قاعده اصلی: برای همه نقش‌های QA یک پایه مشترک بسازید—ریسک، طراحی تست، شواهد، ارتباط، HTTP، داده و Git—سپس بر اساس محصول و نقش هدف یک یا دو حوزه را عمیق کنید.

مهارت با ابزار چه تفاوتی دارد؟

ابزار وسیله انجام کار است؛ مهارت توان رسیدن به نتیجه در زمینه‌های مختلف. ممکن است رابط Jira یا Selenium تغییر کند، اما توان تحلیل ریسک، طراحی Oracle و تشخیص سیگنال نامعتبر ماندگارتر است.

برای هر مهارت سه نوع شاهد بخواهید:

  • دانش: مفهوم و Trade-off را توضیح می‌دهم؛
  • اجرا: روی نمونه واقعی خروجی قابل‌بررسی می‌سازم؛
  • قضاوت: می‌دانم چه زمانی این روش مناسب نیست و ریسک باقی‌مانده چیست.

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

ماتریس چهارسطحی مهارت‌های QA

سطح تعریف قابل‌مشاهده نوع شاهد
L1 — آشنایی واژگان و هدف را می‌فهمد و با راهنما کار می‌کند توضیح مثال و اجرای تمرین هدایت‌شده
L2 — کاربردی کار معمول را مستقل انجام و نتیجه را مستند می‌کند Artifact قابل‌اجرا با Scope روشن
L3 — مستقل ابهام و Trade-off را مدیریت و روش مناسب انتخاب می‌کند تصمیم مستدل، ریسک و بهبود قابل‌اندازه‌گیری
L4 — راهبر مسئله میان‌تیمی را حل، استاندارد می‌سازد و دیگران را رشد می‌دهد اثر سیستمی، Mentoring و سازوکار پایدار

L4 به معنی «استفاده از ابزارهای بیشتر» نیست. ممکن است یک Senior Product QA در تحلیل ریسک L4 و در Performance L1 باشد. ماتریس باید نقش‌محور باشد، نه مسابقه پرکردن همه خانه‌ها.

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

۱. شناخت محصول و تحلیل ریسک

تستر مؤثر از سؤال «چه چیزی کار نمی‌کند؟» به «کدام شکست برای چه کاربری و با چه اثری مهم است؟» می‌رسد. باید بتوانید هدف کاربر، جریان ارزش، وابستگی، فرض و محدودیت را استخراج کنید.

  • L1: تفاوت Risk، Issue و Defect را با مثال توضیح می‌دهد.
  • L2: برای یک Story نقشه ریسک و اولویت اولیه می‌سازد.
  • L3: Scope را با زمان/داده محدود تنظیم و ریسک باقی‌مانده را شفاف می‌کند.
  • L4: زبان مشترک ریسک را بین محصول، توسعه و عملیات برقرار می‌کند.

تمرین شاهد: برای لغو سفارش، پنج ریسک را با کاربر آسیب‌دیده، احتمال، اثر، سیگنال و اقدام پیشنهادی ثبت کنید.

۲. طراحی تست و مدل‌سازی

Test Case خوب از تکنیک و مدل می‌آید، نه از حدس بی‌پایان. افراز هم‌ارزی، مقدار مرزی، جدول تصمیم، انتقال حالت و Pairwise را در مسئله مناسب به کار ببرید. راهنمای طراحی Test Case مثال‌های پایه را ارائه می‌کند.

  • L1: تکنیک‌ها را تشخیص می‌دهد.
  • L2: از Rule واقعی، تست مثبت/منفی/مرزی استخراج می‌کند.
  • L3: با کمینه‌سازی و Risk weighting پوشش معنادار می‌سازد.
  • L4: مدل مشترک و Review practice برای تیم ایجاد می‌کند.

تمرین شاهد: برای کد تخفیف یک Decision table کامل بسازید و Ruleهای ناممکن و Don’t Care را توضیح دهید.

۳. تست اکتشافی و مشاهده

تست اکتشافی توان یادگیری، طراحی و اجرا در یک جریان است. Charter، Oracle، Heuristic، یادداشت زمان‌دار و Debrief باعث می‌شوند نتیجه قابل‌توضیح باشد.

  • L1: تفاوت Exploratory، Ad-hoc و Scripted را می‌فهمد.
  • L2: یک Session محدود با Charter و گزارش اجرا می‌کند.
  • L3: مدل پوشش می‌سازد و مسیر را با یافته‌های تازه اصلاح می‌کند.
  • L4: Pairing، Coaching و برنامه Sessionهای ریسک‌محور را هدایت می‌کند.

تمرین شاهد: با الگوی تست اکتشافی ساختاریافته یک Session ۴۵دقیقه‌ای برای Search اجرا کنید و Observation را از Hypothesis جدا بنویسید.

۴. Oracle، شواهد و گزارش نقص

دیدن رفتار عجیب کافی نیست؛ باید مرجع انتظار، Build، محیط، داده و اثر را روشن کنید. Screenshot زیاد جای مراحل بازتولید و Log مرتبط را نمی‌گیرد.

  • L1: Actual و Expected را جدا می‌نویسد.
  • L2: Bug report قابل‌بازتولید با شواهد امن ثبت می‌کند.
  • L3: بین Product defect، Test defect، Data و Environment تمایز می‌گذارد.
  • L4: کیفیت Triage و Observability را در سطح تیم بهبود می‌دهد.

تمرین شاهد: یک نقص مبهم را با الگوی گزارش باگ بازنویسی کنید و اطلاعات شخصی را Mask کنید.

۵. ارتباط، همکاری و مدیریت تعارض

«مهارت ارتباطی» یک صفت رزومه نیست؛ رفتار قابل‌مشاهده است: سؤال روشن، خلاصه تصمیم، گوش‌دادن، بیان عدم‌قطعیت و تفکیک فرد از مسئله.

  • L1: یافته را بدون سرزنش بیان می‌کند.
  • L2: ریسک فنی را برای Product و Developer متناسب ترجمه می‌کند.
  • L3: اختلاف Severity/Priority را با شواهد و هدف حل می‌کند.
  • L4: گفت‌وگوی دشوار انتشار را تسهیل و تصمیم را ثبت می‌کند.

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

۶. یادگیری، تفکر انتقادی و شناخت محدودیت

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

  • L1: ادعا را از مشاهده و نظر جدا می‌کند.
  • L2: مستند رسمی را می‌خواند و یک نمونه کوچک بازتولید می‌کند.
  • L3: گزینه‌ها را با معیار و PoC مقایسه می‌کند.
  • L4: سازوکار یادگیری و اشتراک دانش پایدار می‌سازد.

تمرین شاهد: یک ادعای ابزار—مثلاً «کاهش نگهداری با Self-healing»—را به فرضیه، معیار، Guardrail و آزمایش دو‌هفته‌ای تبدیل کنید.

۷. دانش دامنه و زبان کسب‌وکار

دانش فنی بدون درک دامنه می‌تواند مهم‌ترین خطا را نبیند. در فروشگاه، سفارش، موجودی، تخفیف، پرداخت، تسویه و بازپرداخت یک مدل پیوسته‌اند؛ در HealthTech یا FinTech، قواعد و پیامدها متفاوت‌اند.

  • L1: واژگان و جریان اصلی دامنه را می‌شناسد.
  • L2: Rule و استثنا را به مثال تست تبدیل می‌کند.
  • L3: اثر مالی/عملیاتی و کنترل‌های متقاطع را تحلیل می‌کند.
  • L4: دانش ضمنی را به مدل و آموزش مشترک تبدیل می‌کند.

تمرین شاهد: جریان Order-to-Refund را رسم کنید و در هر State، مالک، Rule و Failure impact را بنویسید.

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

۸. وب، HTTP و API

برای محصول وب، Request/Response، Method، Header، Cookie، Cache، Status code، JSON، Authentication و Authorization را بفهمید. Postman یک ابزار است؛ مهارت، طراحی تست قرارداد، حالت و Rule کسب‌وکار است. مرور رسمی HTTP در MDN پایه مناسبی است.

  • L1: Request را در DevTools پیدا و اجزای آن را می‌خواند.
  • L2: تست مثبت، منفی، Schema و Business assertion می‌نویسد.
  • L3: مجوز، Idempotency، Concurrency و قرارداد بین سرویس‌ها را می‌سنجد.
  • L4: Strategy و Testability مرزهای سرویس را بهبود می‌دهد.

تمرین شاهد: برای یک API سفارش Collection تکرارپذیر با داده مستقل، Cleanup و گزارش بسازید؛ سپس آن را با اصول تست API بازبینی کنید.

۹. SQL، داده و کیفیت داده

SELECT، WHERE، JOIN، GROUP BY، NULL، Constraint و Transaction برای بسیاری از تسترها پایه کاربردی‌اند. در نقش Data/ETL، Lineage، Reconciliation، حجم، Schema evolution و Data quality عمیق‌تر می‌شوند.

  • L1: Query Read-only ساده را می‌خواند.
  • L2: اثر عملیات را با JOIN و Aggregate اعتبارسنجی می‌کند.
  • L3: Consistency، Isolation، Migration و Data lineage را تست می‌کند.
  • L4: کنترل کیفیت داده و Test data strategy میان‌تیمی می‌سازد.

تمرین شاهد: جمع اقلام، تخفیف و مبلغ پرداخت Order را با سه Query مستقل تطبیق دهید؛ روی داده مصنوعی و محیط مجاز.

۱۰. Git، خط فرمان و خواندن کد

حتی اگر نقش شما Manual باشد، Diff و Version control زمینه تغییر را نشان می‌دهند. Clone، Branch، Commit، Pull Request و دستورهای ساده Shell را تمرین کنید. کتاب رسمی Pro Git رایگان است.

  • L1: Repository را Clone و تاریخچه را می‌بیند.
  • L2: Artifact تست را در Branch تغییر و PR باز می‌کند.
  • L3: Diff را برای Impact analysis می‌خواند و تعارض ساده حل می‌کند.
  • L4: Workflow، Review و نگهداری Assetهای تست را استاندارد می‌کند.

تمرین شاهد: یک Bug fix کوچک را از Commit تا Test impact دنبال و تصمیم Regression را مستند کنید.

۱۱. برنامه‌نویسی و اتوماسیون تست

زبان را بر اساس Stack و نقش هدف انتخاب کنید. متغیر، شرط، تابع، ساختار داده، Exception، Module، Dependency و Unit test مهم‌تر از حفظ Syntax هستند. تست خودکار باید مستقل، خوانا، قابل‌تشخیص و متناسب با لایه باشد.

  • L1: کد ساده را می‌خواند و تغییر کوچک می‌دهد.
  • L2: Smoke پایدار با Setup/Cleanup و Assertion معنادار می‌سازد.
  • L3: معماری، Parallelism، Test data، Flaky و CI failure را مدیریت می‌کند.
  • L4: Platform یا Framework قابل‌استفاده تیمی با Governance می‌سازد.

تمرین شاهد: یک تست API یا UI کوچک را در CI اجرا، Artifact شکست را ذخیره و Flaky را از Product failure جدا کنید. راهنمای اتوماسیون تست برای انتخاب کاندید و لایه مفید است.

۱۲. CI/CD، محیط و Observability

تستر لازم نیست همیشه مهندس DevOps باشد، اما باید Build، Artifact، Environment، Configuration، Secret، Container، Pipeline و Log/Metric/Trace را در حد نقش خود بفهمد.

  • L1: نتیجه Job و Artifact شکست را پیدا می‌کند.
  • L2: تست را در Pipeline اجرا و Variable/Secret را درست مصرف می‌کند.
  • L3: Lane، Gate، Retry policy و محیط تکرارپذیر طراحی می‌کند.
  • L4: Feedback architecture و Ownership میان‌تیمی را بهبود می‌دهد.

تمرین شاهد: یک Pipeline سه‌مرحله‌ای Build→Smoke→Report بسازید و رفتار Fail، Timeout و Infra error را مستند کنید.

۱۳. کیفیت‌های غیرکارکردی: عملکرد، امنیت و دسترس‌پذیری

همه تسترها باید ریسک پایه را تشخیص دهند؛ تخصص عمیق نقش جداگانه می‌خواهد.

  • Performance: Workload، p95/p99، Throughput و Saturation؛
  • Security: Authentication/Authorization، Input، Session، Secret و Threat؛
  • Accessibility: Keyboard، Focus، Name/Role/Value، Contrast و Screen reader؛
  • Usability: هدف کاربر، مشاهده، Task success و خطای تعامل.

L2 عمومی: ریسک‌های رایج را تشخیص و مورد مشکوک را به متخصص Escalate می‌کند.
L3 تخصصی: مدل، محیط، ابزار و تحلیل عمیق همان حوزه را مستقل انجام می‌دهد.

برای امنیت، استفاده از اسکنر بدون مجوز کافی یا ایمن نیست. قواعد و دامنه را در راهنمای تست امنیت ببینید. برای دسترس‌پذیری، WCAG ۲.۲ از W3C مرجع رسمی است.

۱۴. AI-assisted Testing و ارزیابی سیستم AI

مهارت مفید، Prompt‌نویسی نمایشی نیست؛ تعریف Use case، Golden set، Oracle مستقل، Privacy، Evaluation و Fallback است.

  • L1: محدودیت Hallucination و نشت داده را می‌فهمد.
  • L2: از AI روی داده پاک‌سازی‌شده برای پیش‌نویس کم‌خطر استفاده می‌کند.
  • L3: Precision/Recall، Drift، Prompt injection و Regression evaluation را طراحی می‌کند.
  • L4: Governance، Audit و Rollout مرحله‌ای AI را هدایت می‌کند.

تمرین شاهد: یک خروجی AI را با Golden set و نرخ اصلاح ارزیابی کنید؛ سپس چک‌لیست هوش مصنوعی در تست نرم‌افزار را روی آن اجرا کنید.

کدام مهارت‌ها برای نقش من اولویت دارند؟

مسیر پایه ضروری عمق پیشنهادی شاهد مناسب
Product / Manual QA ریسک، طراحی، اکتشاف، گزارش، API/Data دامنه، Usability، Mobile یا Accessibility Session report و Test summary یک Feature
Automation / SDET همه پایه‌ها + کدنویسی و Git Architecture، CI، API/UI و Observability Pipeline پایدار با Failure diagnosis
Performance ریسک، HTTP، داده و مشاهده‌پذیری Workload، آمار، زیرساخت و Profiling گزارش p95/Throughput همراه با Bottleneck evidence
Security وب/API، Linux، شبکه و Threat thinking AppSec، Code review یا Penetration testing مجاز Finding امن با Risk، evidence و Retest
Mobile محصول، API، اکتشاف و گزارش Android/iOS، Device، Network، App lifecycle ماتریس Device/OS و Sessionهای اختلال
QA Lead / Manager قضاوت ریسک و ارتباط عمیق Strategy، Coaching، Metrics و ظرفیت بهبود سیستمی، نه تعداد باگ تیم

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

چگونه خودارزیابی کنیم؟

به خودتان از روی اعتمادبه‌نفس امتیاز ندهید. برای هر خانه این پنج ستون را پر کنید:

مهارت سطح هدف شاهد فعلی شکاف تمرین بعدی
API L2 Collection سفارش با ۱۲ Assertion Cleanup و Authorization matrix ناقص سه Role و اجرای مستقل در CI
گزارش نقص L2 چهار Bug report در Demo Build و اثر کسب‌وکار نامشخص بازنویسی با Triage review
Git L2 Commit مستقیم روی main Branch/PR/Review یک PR کوچک با README

قواعد امتیازدهی سالم

  • Course تمام‌شده شاهد اجرا نیست.
  • سال سابقه سطح مهارت را خودکار تعیین نمی‌کند.
  • یک پروژه کپی‌شده استقلال را ثابت نمی‌کند.
  • شاهد باید Scope، تصمیم، محدودیت و نتیجه داشته باشد.
  • بازخورد Reviewer از امتیاز خوداظهاری معتبرتر است.
  • سطح هدف را بر اساس نقش انتخاب کنید؛ L4 برای همه خانه‌ها لازم نیست.

پروژه جامع برای سنجش چند مهارت

برای یک فروشگاه Demo، جریان ثبت‌نام تا بازپرداخت را انتخاب کنید:

  1. Risk map و جریان حالت بسازید؛
  2. یک Decision table و چند تست مرزی طراحی کنید؛
  3. Session اکتشافی با گزارش اجرا کنید؛
  4. سه Bug report با Artifact پاک‌سازی‌شده بنویسید؛
  5. API را با Role و تست منفی بررسی کنید؛
  6. داده را با Query Read-only تطبیق دهید؛
  7. یک Smoke کوچک را در CI اجرا کنید؛
  8. Test summary با ریسک باقی‌مانده و پیشنهاد انتشار بنویسید.

برای زمینه ایران، callback تکراری/دیررس درگاه، ارقام فارسی، RTL، تاریخ شمسی، شماره موبایل مصنوعی و دسترسی ناپایدار سرویس بیرونی را در Scope قرار دهید. هیچ تست بار، امنیتی یا داده واقعی را بدون مجوز استفاده نکنید.

برنامه شش‌هفته‌ای تقویت مهارت‌ها

هفته ۱: ریسک و طراحی تست

یک Feature را مدل کنید؛ تکنیک و پوشش را توضیح دهید. خروجی: Risk map و Test design reviewشده.

هفته ۲: اکتشاف و گزارش

دو Charter اجرا و یک Bug را کامل بازتولید کنید. خروجی: Session report و Bug report امن.

هفته ۳: HTTP، API و داده

Request را از UI تا API و داده دنبال کنید. خروجی: Collection و Queryهای تطبیق.

هفته ۴: Git و اتوماسیون کوچک

یک Smoke را نسخه‌بندی و در Pull Request بازبینی کنید. خروجی: Repository با README و گزارش.

هفته ۵: CI، Log و یک ریسک غیرکارکردی

تست را در Pipeline اجرا و یک Fail را با Log تحلیل کنید. یک بررسی امنیت/عملکرد/دسترس‌پذیری مجاز اضافه کنید.

هفته ۶: جمع‌بندی و Teach-back

Test summary بنویسید، ده دقیقه ارائه کنید و از Reviewer بخواهید یک تصمیم و یک شکاف را نقد کند. برنامه دوره بعد را بر اساس بازخورد، نه ترند ابزار، انتخاب کنید.

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

  • در هر دوره یک مهارت هسته‌ای و یک مهارت تخصصی انتخاب کنید.
  • ۷۰٪ زمان را صرف ساختن و بازخورد، ۲۰٪ مطالعه و ۱۰٪ اکتشاف ابزار کنید.
  • دفترچه تصمیم نگه دارید: چه چیزی آزموده شد، چه چیزی جواب نداد و چرا.
  • از مستند رسمی و پروژه کوچک شروع کنید؛ Tutorialهای متعدد را انباشته نکنید.
  • هر سه ماه ماتریس را با تغییر نقش و محصول بازبینی کنید.
  • «نه» گفتن به ابزار نامرتبط، خود یک مهارت اولویت‌بندی است.

اشتباه‌های رایج در توسعه مهارت QA

  • مساوی‌گرفتن «تسلط» با نصب یا اجرای یک Tutorial؛
  • یادگیری Framework پیش از فهم طراحی تست و Oracle؛
  • تلاش برای متخصص‌شدن هم‌زمان در همه شاخه‌ها؛
  • نوشتن «دقت بالا» به‌عنوان صفت بدون سازوکار Review؛
  • نادیده‌گرفتن ارتباط و دانش دامنه به نفع ابزار؛
  • تست امنیت یا بار روی سامانه دیگران بدون مجوز؛
  • انتشار Secret یا داده شخصی در پورتفولیو؛
  • استفاده از تعداد Test Case و Bug به‌عنوان معیار سطح فرد؛
  • چسباندن سال به مهارتی که باید با شواهد نقش به‌روز شود.

چک‌لیست مهارت یک QA قابل‌اتکا

  • می‌تواند هدف و Risk را پیش از نوشتن تست روشن کند.
  • برای مسئله، تکنیک و Oracle مناسب انتخاب می‌کند.
  • Observation، Hypothesis و Decision را جدا ثبت می‌کند.
  • API و داده را در حد نقش خود می‌فهمد.
  • Artifact را نسخه‌بندی و اجرای آن را تکرارپذیر می‌کند.
  • Fail محصول، تست، داده و زیرساخت را Triage می‌کند.
  • ریسک را برای مخاطب فنی و کسب‌وکار ترجمه می‌کند.
  • محدودیت، Scope تست‌نشده و عدم‌قطعیت را پنهان نمی‌کند.
  • در یک حوزه متناسب با نقش عمق دارد.
  • یادگیری را با آزمایش و بازخورد به خروجی تبدیل می‌کند.

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

مهم‌ترین مهارت تست نرم‌افزار چیست؟

یک مهارت منفرد کافی نیست. تحلیل ریسک و طراحی تست پایه تصمیم‌اند؛ ارتباط، شواهد و سواد فنی آن تصمیم را قابل‌اجرا می‌کنند. اولویت دقیق به محصول و نقش شما بستگی دارد.

آیا هر تستر باید برنامه‌نویسی بلد باشد؟

سطح لازم یکسان نیست. خواندن منطق و ساخت ابزار کوچک برای بیشتر نقش‌ها مفید است؛ Automation/SDET به عمق بیشتری نیاز دارد. برای نقش Product QA ممکن است تحلیل دامنه و اکتشاف در اولویت بالاتری باشد.

مهارت Manual Testing منسوخ می‌شود؟

«Manual» مجموعه‌ای از فعالیت‌های انسانی متفاوت است. اجرای تکراری کم‌ارزش ممکن است خودکار شود، اما مشاهده، اکتشاف، قضاوت ریسک و ارزیابی تجربه به کار انسانی نیاز دارند. بهتر است مهارت را با نتیجه تعریف کنید، نه برچسب Manual.

از کجا بفهمم در یک مهارت L2 یا L3 هستم؟

L2 کار معمول را مستقل و مستند انجام می‌دهد. L3 در ابهام، روش و Trade-off را انتخاب می‌کند، ریسک باقی‌مانده را توضیح می‌دهد و نتیجه‌اش فراتر از یک Task منفرد اثر دارد. از Reviewer شواهد مشخص بخواهید.

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

نسخه عمومی وجود ندارد. ۲۰ آگهی نقش هدف را نمونه‌برداری کنید و مسئولیت‌های تکرارشونده را با ماتریس خود تطبیق دهید. در محصولات وب، API، SQL، Git و توان ارتباطی معمولاً پایه‌های قابل‌انتقال‌اند؛ اما صنعت و Stack تعیین‌کننده‌اند.

جمع‌بندی

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

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