🐊 تست نرم‌افزار، شروع...

Post Image

🐊 تست نرم‌افزار، شروع...


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


🤓 چطوری شروع کنیم؟

آیا کسی که عادت به ورزش نداره، ولو اینکه دانش‌آموخته‌ی رشته تربیت‌بدنی باشه، می‌تونه با روزی ۵ کیلومتر دویدن شروع کنه؟ خیر. تست‌نویسی هم نیاز به مقدمات و آمادگی داره. خود تست‌نویسی، مقدمات و آمادگی، نیست! بلکه فکر کردن به چگونه تست کردن، مقدمه است.


خیلی از تست‌ها الزاما کمکی به آزمودن نرم‌افزار برای دنیای واقعی نمی‌کنه، شاید تعدادشون هم زیاد باشه، ولی کیفیت ندارن. یعنی واضحات رو تست می‌کنن. یا در شرایط ایده‌آل و دور از واقعیات تست می‌کنن و همه چیز گُل و بلبل در میاد!


لذا قبل از اینکه چیزی رو تولید کنیم اول فکر کنیم که چه احتمالاتی برای اون بخشی که می‌خوایم توسعه بدیم مترتبه؟ بعد از اینکه یک لیست تهیه کردیم (حالا توی ذهنمون یا به شکل بهترش روی کاغذ یه شکل باز هم بهترش روی نرم‌افزار) بشینیم اولویت بدیم که کدوم احتمال رخداد و سطح اثرگذاری بالاتری داره؛ و فرض کنیم قراره فقط ۳ یا ۵ تست بنویسیم و بابت هر ایرادی که پیدا بشه پولی بپردازیم یا سوزنی پشت دستمون بخوره یا فلفلی توی دهنمون بریزن یا بی‌حیثیتمون کنن (منظورم اینه که جدی بگیریمش 😁)


با تعداد تست کم، ولی مهم تمرین کنیم! بله؛ با ۱ یا ۳ یا ۵ تست نوشتن، درسته که شما به coverage متوسط هم نمی‌رسید، ولی درست مثل با یک بارفیکس شروع کردنه... اگه عادت شه، اون وقت به ۳ تا و ۵ تا و ۱۰ تا و... هم می‌رسه. دقت کنید دوباره می‌گم، خودمون رو گول نزنیم، تست مزخرف و بدیهی نوشتن نه یکیش ارزشمنده نه میلیان‌ها میلیانش... این دوره‌ای که قراره خودتون رو عادت بدید و فرهنگ‌سازی کنید، مهم‌ترین چیز، تمرین و ممارست است، سر جدتون شوآف و توهم TDD و... ۴۰ روز به تعویق بندازین.


تعداد تست کم، ولی با اهمیت و اولویت بالا (اگر بلدید ولی عادت به تست‌نویسی ندارید، پیشنهاد من بین ۳ تا ۵ تا است و بس. اگر علاوه بر عادت نداشتن، دانش هم ندارید، فقط ۱) سنگ بزرگ نشونه نزدنه.


✨ ممارست، و تمرین و یادگیری مداوم، رمز پیشرفته.


تویوتا سال در دهه ۱۹۳۰ و ۱۹۴۰ با تولیدات ساده، بعضا الهام‌گرفته یا مهندسی معکوس و... از فورد و شورولت شروع کرد تا بتونه ۱۹۵۰ کار طراحی اولین خودرو تماما تویوتا رو ادامه بده و تا امروز دست از ممارست و بهبود «تدریجی، ولی مداوم» برنداشته. هر اصلاحی من‌جمله «تست‌محور نوشتن نرم‌افزار» از این قاعده خارج نیست...


* عکس: میز آقای Shoichiro Toyoda در موزه لومن، در شهر لاهه، هلند


مطلب بعدی: TDD چیه و چجوری شروع کنیم و ترمینولوژی‌اش؟


مطالب بعدترش: روش‌های شبیه‌سازی وابستگی‌ها؛ جاسازی تست در CI/CD، تست‌های E2E و ، Integration، تست‌های Behavior و کاربرد ابزارهای هوش‌مصنوعی در تست...


💬 اگه یادتون رفته، یادآوری کنم که نظر و پیشنهاد بدید 😁