تیستن جامعه مهندسین تست نرم‌افزار ایران
نوشته های مرتبط
یک نرم‌افزار به واسطه مشخصه‌های آن مفهوم می‌یابد. مشخصه‌هایی که هر یک باید تحت سنجش کیفیت قرار بگیرند. طبق استاندارهای ISO از جمله ISO 9126 و ISO 25010 پارامترهای کیفی و به تبع آن نوع نیازمندی‌های یک نرم‌افزار تبیین شده‌اند. به عنوان نمونه ISO 9126، انواع نیازمندی‌ها/پارامترهای کیفی یک نرم‌افزار را به دو دسته و شش زیردسته تقسیم‌بندی می‌کند:
- Functional
- Functionality
- Non-Functional
- Reliability
- Usability
- Efficiency
- Portability
- Maintainability
غالب اوقات و در اکثر شرکت‌ها همه نگران Functionality محصول تولید شده هستند، و تمرکز تمام ذینفعان روی کارکرد(Functionality) صحیح سیستم است. وقتی کارکرد(Functionality) صحیح در سیستم تائید شد، معمولا کسی با کیفیت این کارکرد صحیح کاری ندارد، مگر آنکه صدای مشتری یا برخی ذینفعان در آید. مثلا مشتری می‌گوید سیستم درست کار می‌کند اما کند(مصداق Efficiency ضعیف) است؛ یا سیستم درست کار می‌کند اما کار کردن با آن سخت(مصداق Usability پایین) است.
معمولا همیشه تصور بر این است که آنچه باعث ایراد در کارکرد(Functionality) بخشی از سیستم می‌شود، Functionality نادرست همان بخش و یا Functionality نادرست یک بخش تاثر گذار(از همان سیستم یا سیستم دیگر) در بخش مذبور است.
بسیاری از اوقات توسعه‌دهندگان و یا تسترها با مشکلات عجیب و غریبی در Functionality درگیر می‌شوند، که هر چه روی آن تمرکز می‌کنند، متوجه دلیل آن نمی‌شوند، و یا مدت زیادی، زمان صرف می‌کنند تا علت را کشف کنند. بسیاری از اوقات این مشکلاتٍ به همان صورت ناگهانی‌ای که بروز کرده‌اند، به صورت ناگهانی و خود بخود نیز رفع می‌شوند.
با اینکه در اکثر موارد این مشکلات به دلیل تاثیر گذاری Functionality سیستم‌های خارج از کنترل ما، بر روی سیستم هدف بروز می‌کنند، اما در برخی موارد هم دلیل این موضوع اصلا ارتباطی به Functionality ندارد، و در کمال تعجب مشخصه‌های ضعیف Non-Functional هستند که تاثیر نادرستی روی Functionality می‌گذارند. فهم این موضوع که این مشکلات عجیب و غریب، چه زمان منشا Functional و چه زمان منشا Non-Functional دارند نسبتا سخت است، و معمولا به مرور زمان و با شناخت رفتار یک سیستم توسط افراد باتجربه روی آن سیستم، قابل تشخیص است. حتی بسیار پیش می‌آید، زمانیکه این مشکلات تشخیص داده می‌شوند، پیدا کردن منشا دقیق آنها در کد و ساختار سیستم آن بسیار بسیار پیچیده باشد. حتی برخی اوقات این مسائل به مدت زیادی لاینحل می‌مانند، و در معدود مواردی، تا زمان بازنشستگی علت Failure(نارسایی سیستم) مذبور کشف نشده باقی می‌ماند، و تیم توسعه مجبور است با آن بسازد و بسوزد.
هر چند که تاثیر مشکلات Non Functional در کارکرد(Functionality) صحیح سیستم اغلب نادیده گرفته می‌شود، و بسیاری از کدنویسان اصلا به آن فکر نمی‌کنند و آنرا جز اولیت‌های بررسی حساب نمی‌کنند، اما باید پذیرفت که احتمال رخ دادن چنین اتفاقاتی به صورت جدی وجود دارد.
قصد داریم برای روشن‌تر شدن موضوع مثالی بزنیم. با اینکه طبق نظر ISO 9126، سیستم‌های نرم‌افزاری مشتمل بر ۵ مشخصه Non-Functional هستند، اما به منظور سنگین نشدن مقاله، صرفا برای یکی از مشخصه‌های Non-Functional مثال می‌زنیم. در این مثال افزایش Load روی یک سیستم می‌تواند باعث ایراد در صحت Functionality شود. شایان ذکر است که موضوعات مرتبط با Load در زمره مسائل Efficiency دسته‌بندی می‌شوند.
شرح مثال
۱- فرض کنید سیستم ما دارای یک صفحه با عنوان “Page 1” است که در آن یک Text Box با عنوان A وجود دارد. این صفحه مسئول ارسال فیلد اطلاعاتی A به Server است، که بر اساس مقدار آن و محاسبات صورت گرفته با مقدار A فیلد دیگری با عنوان B مقداردهی می‌شود. البته در نظر داشته باشید که فیلد B قبل از اینکه با مقدار محاسبه شده پر شود، با یک مقدار پیشفرض Initialize شده است. نکته‌ای که در این محاسبه و تولید مقدار برای فیلد B وجود دارد، این است که مقدار فیلد B در سریعترین حالت ظرف ۰٫۲۳ ثانیه محاسبه می‌شود، و در شرایط پیک عملیاتی ۴٫۵۴ ثانیه برای محاسبه آن زمان صرف می‌شود.
۲- با فشردن دکمه “Submit” در تصویر بالا دو عملیات به صورت همزمان رخ می‌دهد:
- آغاز عملیات تولید مقدار برای فیلد B
- بارگذاری صفحه‌ای با عنوان “Page 2” که در تصویر ذیل نمایش داده شده است
در صفحه “Page 2” نیز عملیات ورود اطلاعات توسط کاربر انجام می‌شود، و در آخر با فشردن کلید “Submit” فیلد دیگری با عنوان C محاسبه می‌شود. اما در اینجا یک نکته حائز اهمیت است و آن وجود یک چک باکس در پایین صفحه “Page 2” با عنوان “Optional Calculation” است. ورود اطلاعات به این صفحه و سپس تیک کردن این چک باکس و پس از آن فشردن دکمه “Submit” منجر به تغییر فرمول محاسبه فیلد C می‌شود، که تبعا مقداری متفاوت از حالتی که در آن چک باکس تیک نمی‌شود، تولید خواهد شد. با تیک کردن این چک باکس فیلد C به جای محاسبه مستقل، به صورت وابسته و بر اساس فیلد B محاسبه خواهد شد، و این یعنی مقدار فیلد B در مقدار نتیجه شده فیلد C تاثیر مستقیم خواهد داشت.
نکته: از آنجاییکه این سیستم یک سیستم قدیمیست و برخی از کاربران آن نیز مدت طولانی با این سیستم مشغول به کار بوده‌اند، لذا به دلیل تبحر حاصل شده می‌توانند ورود اطلاعات صفحه “Page 2” را ظرف ۳٫۵ ثانیه انجام دهند.
اکنون شرایطی را تصور کنید، که ما در زمان پیک کاری قرار داریم، و این یعنی محاسبه فیلد B به مدت ۴٫۵۴ ثانیه طول می‌کشد. یک کاربر حرفه‌ای نیز ورود اطلاعات در صفحه “Page 2” را پس از تیک کردن چک باکس “Optional Calculation”، ظرف ۳٫۵ ثانیه انجام داده و کلید Submit را می‌زند.
در این شرایط چه اتفاقی می‌افتد؟
از آنجاییکه طی مدت ۳٫۵ ثانیه هنوز تولید مقدار برای فیلد B انجام نشده است(چون تولید آن ۴٫۵۴ ثانیه زمان نیاز دارد)، بنابراین مقدار فیلد C بر اساس مقدار پیشفرض B محاسبه می‌شود، و این در حالیست که فیلد B برای تکمیل محاسبه، به ۱٫۰۴ ثانیه زمان بیشتر نیاز دارد تا بدین ترتیب روی مقدار پیشفرض ذخیره شود. این موضوع باعث می‌شود که پس از بررسی فیلد C مشخص شود، که مقدار آن بر اساس مقدار جاری فیلد B حساب نشده است، و به همین دلیل یک Functional Failure اعلام شود.
در این مثال به خوبی مشاهده کردید که افزایش Load روی سیستم که منجر به کندی آن شده بود، توانست عاملی برای ایجاد Failure در Functionality سیستم شود.
نتیجه
به یاد داشته باشیم که مشکلات عجیب و غریب سیستمی هم بی دلیل نیستند، و قطعا یک فاکتور داخلی، خارجی یا محیطی عامل آنهاست. به علاوه باید به خاطر داشته باشید که برای رفع این مشکلات نباید فقط جنبه Functional سیستم را بررسی کرد؛ گاهی اوقات Non Functionality مقصر ایجاد این Failureهاست.
