در این دوران که دورههای آموزشی و مقالههای روز به شدت کم شدن، با هزینه بسیار زیاد تونستم یک دسترسی کوچک به تلگرام داشته باشم و صفحات وب برخی از مقالهها رو دانلود کنم
امیدوارم بتونم هر روز تعدادی برای شما در اینجا منتشر کنم، سعی میکنم مقالههایی رو پیدا کنم برای همه زیرشاخههای دوستان مهندس نرمافزار و مهندسان کامپیوتر مناسب باشه
اگر مقاله یا بلاگی داشتید، خوشحال میشم توی پیامرسان بله(به آیدی mhselfs) برام ارسال کنید که هم ترجمه و هم منتشر کنم
لازم میدونم یادآوری کنم که در ترجمه این متن از هوشمصنوعی ChatGPT کمک گرفته شده، پس این متن هم بدون ایراد نخواهد بود
در این دوران که دورههای آموزشی و مقالههای روز به شدت کم شدن، با هزینه بسیار زیاد تونستم یک دسترسی کوچک به تلگرام داشته باشم و صفحات وب برخی از مقالهها رو دانلود کنم
امیدوارم بتونم هر روز تعدادی برای شما در اینجا منتشر کنم، سعی میکنم مقالههایی رو پیدا کنم برای همه زیرشاخههای دوستان مهندس نرمافزار و مهندسان کامپیوتر مناسب باشه
اگر مقاله یا بلاگی داشتید، خوشحال میشم توی پیامرسان بله(با آیدی ویرگول یکی هستش) برام ارسال کنید که هم ترجمه و هم منتشر کنم
وقتی میگوییم «کیفیت نرمافزار» یا فقط «کیفیت»، فکر میکنیم همه متوجه منظور ما میشوند. مشکل اینجاست که اگر از چند نفر مختلف در یک تیم توسعه نرمافزار (از جمله ذینفعان) بپرسید کیفیت نرمافزار چیست، احتمالاً چند پاسخ متفاوت دریافت خواهید کرد.
پس واقعاً کیفیت چیست؟ به نظر من، کیفیت نرمافزار یعنی میزان تناسب یک محصول با هدفی که برای آن ساخته شده است. اما این موضوع بسیار وابسته به زمینه است؛ اینکه «تناسب» را چگونه تعریف کنیم و «هدف» را چه بدانیم. برخی میگویند کیفیت یعنی اینکه یک محصول نرمافزاری چقدر نیازهای کاربران و ذینفعان را برآورده میکند یا چه میزان ارزش ارائه میدهد. این میتواند شامل موارد مختلفی باشد، مثل قابلیت اعتماد، یا اینکه افراد بتوانند بدون سردرگمی و ناراحتی از آن استفاده کنند.
برای بسیاری از افراد، موضوع بزرگ کیفیت «نبود باگ» است؛ همان چیزهای مزاحمی که باعث میشوند نرمافزار آنطور که باید کار نکند. اما همهی ما باگهای اولویت ۴ را دیدهایم؛ آنها تاثیری روی عملکرد اصلی نرمافزار ندارند و سالها در بکلاگ باقی میمانند بدون اینکه هرگز رسیدگی شوند. آیا این به معنای بیکیفیت بودن نرمافزار است؟
در نهایت، کیفیت فقط دربارهی خود کد نیست، بلکه دربارهی کل تجربهی کاربر، ارزشی که برای کسبوکار ایجاد میکند، و اینکه چقدر خوب مشکلی را که در ابتدا برای حل آن طراحی شده، برطرف میکند. البته به شرط اینکه از ابتدا مشکل را درست شناسایی کرده باشیم. کیفیت یک نگاه جامع است که دیدگاههای مختلف را ترکیب میکند تا بتوانیم چیزی را تشخیص دهیم که واقعاً مفید و خوب ساخته شده است.
خب، تعریف کیفیت که آسان بود. کارمان تمام شد. یا نه؟
ببین، اگرچه این تعریف بخش زیادی از موضوع را پوشش میدهد، اما فاصلهی زیادی با کل ماجرا دارد. کیفیت نرمافزار یک موجود پیچیده و چندوجهی است که بسته به اینکه از چه کسی بپرسید و علاقهی اصلی او چیست، تفسیرهای مختلفی دارد.
یک مدیر محصول ممکن است کیفیت را «برآورده کردن نیازهای بازار و دستیابی به پذیرش بالای کاربر» تعریف کند.
یک کاربر ممکن است بگوید «برای من کار میکند و مشکلم را حل میکند.»
یک توسعهدهنده که کد را مینویسد احتمالاً بیشتر به ساختار داخلی و قابلیت نگهداری کد اهمیت میدهد.
همهی این دیدگاهها معتبرند و همگی در چیزی که ما کیفیت نرمافزار مینامیم نقش دارند. کیفیت یعنی ایجاد تعادلی میان همهی این نظرات تا محصولی ساخته شود که نه تنها خوب کار کند، بلکه ارزش واقعی و حس خوبی به کاربرانش بدهد.
کیفیت نرمافزار به میزان انطباق نرمافزار با نیازمندیها و برآوردهکردن نیازهای کاربران اشاره دارد. تعریف رسمی IEEE این است: «توانایی یک محصول نرمافزاری برای برآوردهکردن نیازهای بیانشده و تلویحی وقتی در شرایط مشخص استفاده میشود.»
تعریف دیگر IEEE بیان میکند که کیفیت نرمافزار وابسته است به «میزانی که نیازمندیهای تعریفشده، نیازها، خواستهها و انتظارات ذینفعان را بهدرستی بازتاب میدهند.» نرمافزار باکیفیت نرمافزاری است که نیازمندیهایش را برآورده میکند، و این نیازمندیها باید دقیقاً بازتابدهنده نیازهای واقعی ذینفعان باشند. کیفیت یعنی همراستایی نرمافزار با نیازمندیهای رسمی و همچنین نیازهای حقیقی کاربران.
در مهندسی نرمافزار، کیفیت نرمافزار به دو مفهوم مرتبط اما متفاوت اشاره دارد:
کیفیت عملکردی نرمافزار بیان میکند که نرمافزار چقدر با طراحی یا نیازهای عملکردی و مشخصات خود سازگار است. این ویژگی همچنین به عنوان تناسب نرمافزار برای هدفی که برای آن ساخته شده یا میزان رقابتپذیری آن در بازار به عنوان محصولی ارزشمند توصیف میشود. یعنی اینکه «آیا نرمافزار درست ساخته شده است؟»
کیفیت ساختاری نرمافزار بیان میکند که نرمافزار چقدر نیازهای غیرعملکردی را که برای تحویل درست قابلیتهای عملکردی لازم است، برآورده میکند؛ مانند پایداری یا قابلیت نگهداری. این بیشتر دربارهی «این است که آیا نرمافزار همانطور که باید، کار میکند؟»
مدل کیفیت، بخش اصلی یک سیستم ارزیابی کیفیت محصول است. مدل کیفیت مشخص میکند کدام ویژگیهای کیفیت هنگام ارزیابی یک محصول نرمافزاری در نظر گرفته میشوند.
کیفیت یک سیستم یعنی میزان برآوردهکردن نیازهای بیانشده و تلویحی ذینفعان مختلف، و بنابراین ایجاد ارزش. نیازهای ذینفعان (مثل عملکرد، امنیت، نگهداری و غیره) همان چیزهایی هستند که در مدل کیفیت ارائه میشوند و مدل، کیفیت محصول را به ویژگیها و زیرویژگیها دستهبندی میکند.
مدل کیفیت محصول در ISO / IEC 25010 شامل نه ویژگی کیفی است که در تصویر مربوطه نمایش داده میشود. توضیحات بیشتر از طریق لینکی که در بخش «اطلاعات بیشتر» مقاله آمده، قابل مطالعه است.
کیفیت، یا در اینجا «کیفیت نرمافزار»، یکی از آن کلماتی است که همه از آن استفاده میکنند. معنیاش معمولاً همان لحظه زیر سؤال نمیرود، اما میتواند معانی بسیار متفاوتی داشته باشد.
معمار مهندسی کیفیت و نویسنده، Suman Bala، از مثال جالبی دربارهی یک تخت پادشاهی و یک صندلی مدرسه استفاده میکند تا توضیح دهد چرا زمینه، هنگام فکر کردن به کیفیت، اهمیت حیاتی دارد. هزینهی این دو شیء اختلاف فاحش دارد. جنس، پیچیدگی و طراحی آنها هیچ شباهتی به هم ندارد. اما در زمینهی مناسب خودشان، کیفیت هر دو قابل مقایسه است.
تخت نرم و لوکس با تزئینات زیاد، که فقط چند بار استفاده میشود، در زمینهی خود کاملاً مناسب است. صندلی سخت و سادهی فلزی و پلاستیکی که دهها هزار بار استفاده میشود، در محیط مدرسه کاملاً مناسب است چون باید ارزان، مقاوم و حتی قابلچیدن باشد. این دو شیء کاملاً متفاوتاند، اما هر دو ارزشمندند.
در نرمافزار هم کیفیت میتواند وابسته به عوامل بسیار مختلفی باشد و داشتن یک تعریف واحد بیشتر میتواند مانع باشد تا کمک. یک توسعهدهنده ممکن است کیفیت را کد تمیز بدون «بوی بد» بداند. یک تستر ممکن است طیف وسیعی از ویژگیها را بررسی کند، از انطباق با نیازمندیها تا دسترسپذیری و کاربرپذیری. یک کاربر نهایی شاید فقط چیزی بخواهد که «کار کند».
جرالد، دانشمند کامپیوتر، مهندس، نویسنده و تأثیرگذار در حوزه توسعه نرمافزار بود که بر جنبههای انسانی ساخت نرمافزار تمرکز داشت. او کیفیت را «ارزش برای کسی» تعریف میکرد؛ تعریفی که بعدها با عبارتهایی مثل «برای چه کسی» و «در چه زمانی» کاملتر شد. حتی با درنظرگرفتن زمینه، کیفیت همیشه یک معیار ثابت نیست، بلکه چیزی است که توسط انسانها و هدفها شکل میگیرد. چیزی که برای یک گروه اهمیت دارد ممکن است برای گروه دیگر بیمعنی باشد، و همین دلیل است که کیفیت نرمافزار همیشه نیازمند گفتوگوی دائمی است.
استوارت یک مهندس نرمافزار با تمرکز بر تست و کیفیت است. او طرفدار تست تیمی و ابتکارات متنباز است. او در یک پست لینکدین در سال ۲۰۲۴، تست نرمافزار را اینگونه تعریف کرد: «کاوش و کشف رفتارهای مورد انتظار و غیرمنتظره در نرمافزاری که میسازیم و تأثیر این رفتارها بر ارزش محصول—برای مشتریان و کسبوکار.»
او سپس کیفیت را «نبود اصطکاک غیرضروری» تعریف کرد و نوشت: «این دو تعریف، با هم، به من کمک میکنند تصمیمهای سریع و مفیدی دربارهی اینکه چه چیزی را تست کنم و بر اساس آن تست، چه چیزی نیاز به بهبود دارد، بگیرم.»
این دیدگاه نشان میدهد که احساسات میتوانند برای یک فرد، شاخص اصلی کیفیت باشند.
دن یک رهبر حوزه کیفیت نرمافزار با بیش از ۲۰ سال تجربه و تعهد جدی به اشتراک دانش است. او مدل «تست مداوم در DevOps» را ایجاد کرده است.
در یک پست وبلاگ در سال ۲۰۱۹، او چهار اصل مطلق کیفیت از فیلیپ کرازبی را در زمینهی نرمافزار بررسی کرد.
اولین اصل کرازبی این بود: «کیفیت یعنی انطباق با نیازمندیها.» و چون کرازبی در حوزه تولید فعالیت میکرد، انطباق با نیازمندیها بخش بنیادی کیفیت است.
دن به این نتیجه رسید که نرمافزار تعریف گستردهتری میطلبد و این اصل را اینگونه بازنویسی کرد: «کیفیت یعنی درستی و خوبی در ارتباط با ارزش ذینفعان.»
در نهایت، اینکه کیفیت نرمافزار در زمینهی شما چه معنایی دارد، چیزی نیست که من یا هر کس دیگری بتواند برایتان تعیین کند.
کیفیت وابسته به زمینه است: هدف، محدودیتها، زمان، و افرادی که درگیر هستند. هیچ چکلیست جهانی وجود ندارد.
نکته مهم این است که بدانید کیفیت در موقعیت شما یعنی چه، چگونه اندازهگیری میشود، و برای چه کسی اهمیت واقعی دارد.
برخی افراد بازخورد مشتری را مهمترین شاخص کیفیت میدانند، برخی دیگر عملکرد نرمافزار را قبل از هر چیز مشاهده و پایش میکنند.
بسیاری هم به دنبال معیارهای کمی هستند.
سؤالهایی میپرسند مانند:
«یادگیری ویژگی جدید چقدر طول میکشد؟»
یا
«از چه مقیاسها یا ابزارهایی برای اندازهگیری کیفیت میتوانیم استفاده کنیم؟»
روش توصیف یا اندازهگیری کیفیت نرمافزار به عواملی بستگی دارد که در اختیار دارید. از این فرایند لذت ببرید.
عالی است، تمام شد! یا شاید نه… بیایید ادامه بدهیم.
تا اینجا دیدیم که تعریف کیفیت چندان ساده نیست. بنابراین بیایید کمی سختترش کنیم.
وقتی دربارهی کیفیت صحبت میکنیم باید تصویر کامل را ببینیم: اینکه چقدر خوب کار میکند، کاربر چه چیزی میبیند، عملکرد آن چگونه است، و آیا باگ آزاردهندهای وجود دارد یا نه.
مثلاً در یک اپلیکیشن بانکداری، کیفیت نرمافزار یعنی اینکه بتوانید بهراحتی پول انتقال دهید، سریع موجودی را ببینید، و احساس کنید تراکنشها امن هستند.
اما کیفیت فنی به لایههای درونیتر نرمافزار میپردازد.
این کیفیت دربارهی کد، طراحی، و میزان سهولت درک نرمافزار توسط توسعهدهندگان دیگر است.
برای درک بهتر، این مثال را در نظر بگیر:
یک خودرو میتواند کیفیت نرمافزاری عالی داشته باشد—اطلاعات دقیق میدهد، شما را مطمئن از A به B میرساند، و امکانات مورد نیازتان را فراهم میکند.
اما کیفیت فنی آن به مهندسی زیر کاپوت مربوط است: طراحی موتور، استحکام شاسی، و کارایی اجزای داخلی.
حتی اگر داخل خودرو راحت باشید و موزیک عالی پخش شود، اما در کنار جاده خرابی کرده باشید، اولین فکری که نمیکنید این است که «این یک خودروی باکیفیت است.»
خراب شدن تجربهای است که هیچکس آن را کیفیت نمینامد.
شما میتوانید محصولی با کیفیت فنی بالا اما کیفیت نرمافزار پایین داشته باشید.
مثلاً نرمافزاری با کد تقریباً بینقص، معماری زیبا، و تست واحد عالی.
اما اگر مشکل کاربر را حل نکند، استفاده از آن دشوار باشد، یا عملکرد اصلیاش را ارائه ندهد، کیفیت نرمافزار آن پایین است—even اگر کدش یک اثر هنری باشد.
یا برعکس:
نرمافزاری ممکن است فوقالعاده محبوب باشد و یک مشکل بزرگ را حل کند (کیفیت نرمافزار بالا)، اما کد داخلی آن آشفته، پر از بدهی فنی و کابوس توسعهدهندگان باشد (کیفیت فنی پایین).
هر دو مهماند، و بهطور ایدهآل باید برای رسیدن به سطح مناسب هر دو تلاش کنیم.
ایدهی کیفیت در حال تکامل است. دیگر کیفیت به عنوان چیزی که در انتهای چرخه توسعه «بررسی» میشود، دیده نمیشود. ما اکنون در حال پذیرش «کیفیت مستمر» هستیم. این به معنای ایجاد کیفیت از ایدهی اولیه تا مرحلهی انتشار و فراتر از آن است. این امر به ایجاد فرهنگی کمک میکند که در آن همه، نه فقط یک تیم اختصاصی، در طول توسعه به کیفیت فکر میکنند و در آن مشارکت دارند.
اینجاست که «مربیگری کیفیت» وارد میشود. یک مربی کیفیت، بین تیم و محصول نهایی قرار نمیگیرد. او منتظر نمیماند تا باگها را در انتها پیدا کند. وظیفهی او این است که در کنار تیم کار کند تا تفکر کیفی زودتر و بیشتر بروز کند. مربیان، تیمها را توانمند میسازند تا کیفیت را بهتر درک کنند، مشکلات بالقوه را زودتر شناسایی کنند و از ابتدا راهحلهای قوی بسازند.
تصور کنید تیمی در حال ساخت یک ویژگی جدید است. یک مربی کیفیت ممکن است جلسهای را برای بررسی نحوهی تعامل کاربران با آن اجرا کند و به تیم کمک کند تا قبل از نوشتن کد، موارد خاص و باگهای احتمالی را در نظر بگیرند. او ممکن است تکنیکهای تست جدید را معرفی کند، به راهاندازی حلقههای بازخورد بهتر کمک کند، یا تیم را در بهبود اتوماسیونشان راهنمایی نماید. هدف، ارتقاء توانایی و طرز فکر کل تیم نسبت به کیفیت است، به طوری که کیفیت به بخشی ذاتی از نحوهی کار روزانهی آنها تبدیل شود.
اخیراً، شاهد تغییری از تستکنندگان به عنوان «نگهبانان» (gatekeepers) به سمت مسئولیتپذیری کل تیم برای کیفیت بودهایم. این تغییر، بازتابی از پیشرفتی است که در دنیای نرمافزار مشاهده کردهایم.
تاریخچه: به طور سنتی، «تضمین کیفیت» یا «QA» اغلب به وظیفهای اشاره داشت که عمدتاً بر تأیید مطابقت نرمافزار با نیازمندیها تمرکز میکرد، و اغلب در انتهای پروژه تحت فشار زمانی قرار میگرفت. معمولاً تستکنندگان در دپارتمانهای کاملاً مجزا از توسعهدهندگان قرار میگرفتند و وظیفهشان پیدا کردن باگها پس از اتمام کار توسعهدهندگان بود. در تمام این مدت، آنها با نزدیک شدن به مهلت انتشار (که اغلب مصنوعی بود) تحت فشار بودند. هر مشکلی که پیدا میشد میتوانست باعث اختلاف شود، زیرا توسعهدهندگان «کارشان را تمام کرده و به سراغ کار جدیدی رفته بودند».
اگرچه تست نرمافزار همیشه ارزشمند بوده است، رویکرد «آخرین تست» (test last) اغلب باعث ایجاد شکاف (silos)، تأخیر در انتشار و دامن زدن به ذهنیت «ما (تستکنندگان) در مقابل آنها (توسعهدهندگان)» میشد. شاید اصطلاح «پرتاب شدن از بالای دیوار» (thrown over the fence) را شنیده باشید که به نرمافزاری اشاره دارد که بدون جزئیات یا همکاری به تستکنندگان داده میشد. اما حقیقت این است که ارائهی نرمافزار عالی، همیشه هدف همه بوده است.
امروزه: شاهد گرایش روزافزون شرکتها به سمت «ذهنیت مهندسی کیفیت» (quality engineering mindset) هستیم. این اصطلاح، رویکردی فعالانهتر و یکپارچهتر به کیفیت را نشان میدهد. مهندسان کیفیت صرفاً باگ پیدا نمیکنند، بلکه در پیشگیری از آنها نقش اساسی دارند. آنها در تیمهای محصول چندوظیفهای (cross-functional) کار میکنند و با طراحان، مدیران محصول و توسعهدهندگان همکاری میکنند. مهارتهای آنها به شکلدهی طراحی محصول، تأثیرگذاری بر معماری و اطمینان از لحاظ شدن کیفیت در هر مرحله کمک میکند. یک شاخص کلیدی، کشف اخیر MoT است که ۸۰ درصد از افراد (تستکنندگان) خود را «مهندس کیفیت» معرفی میکنند.
این تغییر رویکرد توسط عوامل متعددی هدایت میشود:
تست در مراحل اولیه (Shift Left Testing): تیمها به طور فزایندهای از این رویکرد استفاده میکنند، به این معنی که فعالیتهای مرتبط با کیفیت از خیلی زودتر شروع میشوند. مهندسان کیفیت در نوشتن استوریهای کاربر (user stories)، تعریف معیارهای پذیرش (acceptance criteria) و راهاندازی حلقههای بازخورد قوی و فرصتهای همکاری دخیل هستند. این بدان معناست که احتمال شناسایی باگها در مراحل اولیه، زمانی که رفع آنها ارزانتر و آسانتر است، بیشتر میشود.
ذهنیت پیشگیرانه: این یک تغییر از ذهنیت واکنشی به سمت یک ذهنیت فعال، مهندسی-محور است، که در آن همه مالکیت مشترکی در ارائهی محصولی با کیفیت بالا را بر عهده میگیرند.
کیفیت نرمافزار بسیار فراتر از صرفاً نبود باگهای شناسایی شده است. این یک مفهوم بسیار گسترده است که شامل همهچیز، از کمال فنی تا لذت کاربر میشود. در حالی که کیفیت فنی بر استحکام عملکردهای درونی تمرکز دارد، کیفیت نرمافزار نگاهی جامعتر به کل تجربهی کاربر و تأثیر تجاری آن دارد.
برای برخی افراد، کیفیت یک عمل یا یک شیء نیست؛ بلکه عادتی است که نه تنها در آنچه تولید میکنیم، بلکه در نحوهی همکاری برای تولید آن نیز ساخته میشود. ما میدانیم که درست مانند دسترسی دیجیتال و امنیت، باید از ابتدا به آن فکر کنیم، زیرا افزودن آن در مراحل بعدی بسیار پرهزینهتر است.
چرخش صنعت به سمت «کیفیت مستمر»، که توسط «مربیگری کیفیت» ترویج میشود، و حرکت از «تضمین کیفیت» به «مهندسی کیفیت»، یک تغییر بنیادین را برجسته میکند. ما به سمت مسئولیتپذیری فعالانه، درونیشده و مشترک برای کیفیت در سراسر چرخهی عمر توسعهی نرمافزار (SDLC) حرکت میکنیم و اطمینان حاصل میکنیم که نه تنها نرمافزار کاربردی، بلکه محصولات ارزشمندی میسازیم که برای همه کارآمد هستند.
از گواهینامهی مبانی تست نرمافزار، بخش ۵، درس ۶:
به طور خلاصه، کیفیت میتواند دستنیافتنی باشد و معانی کاملاً متفاوتی برای افراد مختلف داشته باشد. مهم است که درک مشترکی از معنای کیفیت در زمینهی تست و پروژه خود به دست آوریم.
میتوانید نقلقولها و تئوریهای زیادی در مورد کیفیت پیدا کنید، اما در اینجا چند نکته وجود دارد که هنگام بحث در مورد کیفیت باید در نظر داشت:
کیفیت ذهنی است و برای درک در هر مورد به زمینه نیاز دارد.
کیفیت مسئولیت کل تیم است، نه فقط تستکننده.
کیفیت در یک تیم میتواند معانی متفاوتی داشته باشد.
ساخت چیز درست: اطمینان حاصل کنید که ارزش را برای شرکت و کاربران ارائه میدهد.
ساختن چیز درست (به نحو درست): از طریق بازنگریها (retrospectives) و بهبودهای تعاملی، روشهای کاری خود را به طور مداوم بهبود بخشید.
کیفیت را میتوان با تعامل و بازخورد مشتری اندازهگیری کرد. مشتریان راضی به معنای محصول با کیفیت هستند.
