فرض کنید یک قطعه یا خودرو ماهها در مرحله طراحی و توسعه بوده و حالا قرار است برای آزمون استاندارد به آزمایشگاه ارسال شود. اگر نتیجه آزمون نشان دهد یکی از الزامات برآورده نشده است، مسئله فقط هزینه همان آزمون نیست؛ ممکن است نمونه جدید لازم باشد، طراحی تغییر کند، قطعه دوباره ساخته شود و بخشی از برنامه پروژه به تعویق بیفتد. طبیعی است که در چنین شرایطی تیم مهندسی بخواهد پیش از رسیدن به آزمون نهایی، تا حد ممکن از وضعیت محصول مطلع باشد.
یکی از ابزارهایی که میتواند در چنین موقعیتی استفاده شود Pre-Test یا پیشآزمون است. هدف Pre-Test این نیست که نتیجه آزمون رسمی را از قبل مشخص کند یا قبولی محصول را تضمین کند؛ هدف اصلی این است که پیش از ورود به مرحلهای که نتیجه رسمی یا تصمیم مهم پروژه به آن وابسته است، اطلاعات بیشتری درباره عملکرد محصول به دست آوریم، ریسکهای قابل شناسایی را بررسی کنیم و در صورت نیاز فرصت اصلاح طراحی یا نمونه را داشته باشیم. همین تفاوت در هدف، مرز اصلی میان Pre-Test و آزمون رسمی را شکل میدهد.
Pre-Test چیست؟
Pre-Test را میتوان یک ارزیابی یا آزمون مقدماتی دانست که پیش از آزمون اصلی یا رسمی و با هدف کسب اطلاعات درباره عملکرد نمونه انجام میشود. بسته به پروژه، Pre-Test ممکن است بسیار نزدیک به روش آزمون نهایی باشد یا فقط بخشی از شرایط و پارامترهای مهم آن را بازتولید کند. میزان شباهت به آزمون رسمی باید بر اساس هدف Pre-Test تعیین شود، نه اینکه صرفاً هر آزمایش اولیهای را Pre-Test بنامیم.
برای مثال، اگر تیم توسعه یک صندلی خودرو نگران باشد که یک ناحیه از ساختار در آزمون بارگذاری عملکرد مناسبی نداشته باشد، ممکن است پیش از آزمون نهایی نمونهای را تحت شرایط مرتبط بررسی کند تا رفتار سازه، تغییر شکل یا Failure Mode احتمالی مشخص شود. در پروژه دیگری ممکن است هدف Pre-Test بررسی عملکرد یک سیستم در چند Configuration مختلف باشد تا تیم مهندسی قبل از انتخاب Configuration نهایی داده بیشتری برای تصمیمگیری داشته باشد.
بنابراین Pre-Test یک قالب ثابت برای همه محصولات ندارد. گاهی تقریباً همان Setup آزمون اصلی با نمونه توسعهای استفاده میشود، گاهی فقط بخشی از بارگذاری یا شرایط آزمون بررسی میشود و گاهی هدف صرفاً مقایسه دو طراحی است. چیزی که Pre-Test را تعریف میکند هدف توسعهای و مقدماتی آن است.
آزمون رسمی چه تفاوتی با Pre-Test دارد؟
در آزمون رسمی، محصول بر اساس مرجع، روش، شرایط و معیارهایی که برای فرآیند مربوط تعریف شدهاند ارزیابی میشود و نتیجه میتواند در ارزیابی انطباق، تأیید محصول یا سایر تصمیمهای رسمی مرتبط مورد استفاده قرار گیرد. در چنین آزمونی، هویت و Configuration نمونه، روش آزمون، تجهیزات، شرایط محیطی، ثبت دادهها و نحوه گزارش نتیجه اهمیت مشخصی دارند و اگر فعالیت در دامنه تأیید صلاحیت آزمایشگاه انجام شود، الزامات مربوط به آن دامنه نیز باید رعایت شوند.
Pre-Test معمولاً انعطاف بیشتری دارد، زیرا هدف اصلی آن تولید اطلاعات برای تصمیمگیری مهندسی است. تیم پروژه ممکن است بخواهد آزمون را زودتر متوقف کند، پارامترهای بیشتری ثبت کند، بعد از مشاهده یک رفتار خاص نمونه را بررسی کند یا چند Configuration را با یکدیگر مقایسه کند. چنین انعطافی در مرحله توسعه میتواند بسیار ارزشمند باشد، اما همین موضوع یکی از دلایلی است که نتیجه Pre-Test را نباید بهطور خودکار معادل نتیجه آزمون رسمی دانست.
| Pre-Test | آزمون رسمی |
|---|---|
| هدف اصلی، شناخت رفتار محصول و کاهش ریسک پروژه است | هدف، ارزیابی محصول بر اساس الزامات و فرآیند تعریفشده است |
| میتواند متناسب با سؤال مهندسی پروژه طراحی شود | باید شرایط و روش مورد استناد را رعایت کند |
| نمونه میتواند در مرحله توسعه باشد | نمونه باید با الزامات فرآیند مربوط سازگار باشد |
| امکان بررسی چند طراحی یا Configuration وجود دارد | Configuration مورد آزمون باید مشخص و قابل ردیابی باشد |
| نتیجه عمدتاً برای تصمیمگیری توسعهای استفاده میشود | نتیجه میتواند مبنای ارزیابی رسمی یا تصمیم مرتبط قرار گیرد |
| قبولی در آن تضمینکننده نتیجه آزمون رسمی نیست | نتیجه بر اساس شرایط همان آزمون و معیارهای مربوط گزارش میشود |
آیا Pre-Test باید دقیقاً مطابق استاندارد انجام شود؟
نه همیشه؛ پاسخ به هدف Pre-Test بستگی دارد. اگر هدف این باشد که تیم پروژه تخمین نزدیکتری از رفتار محصول در آزمون نهایی داشته باشد، منطقی است شرایط Pre-Test تا حد ممکن به روش مورد استناد نزدیک باشند. اما اگر سؤال مهندسی محدودتر است—برای مثال مقایسه دو طراحی یا شناسایی نقطه شروع تغییر شکل—ممکن است اجرای کامل تمام مراحل استاندارد ضرورتی نداشته باشد.
با این حال، هرچه Pre-Test از شرایط آزمون اصلی فاصله بگیرد، باید در تفسیر نتیجه محتاطتر بود. اگر Fixture متفاوت باشد، سرعت بارگذاری تغییر کند، نمونه Configuration دیگری داشته باشد یا بخشی از شرایط استاندارد حذف شود، نتیجه همچنان میتواند برای توسعه محصول ارزشمند باشد اما دیگر نباید بدون تحلیل به نتیجه آزمون اصلی تعمیم داده شود. بنابراین پیش از انجام Pre-Test بهتر است مشخص شود کدام بخشهای آزمون اصلی باید بازتولید شوند و کدام تغییرات برای هدف مهندسی پروژه قابل قبول هستند.
چه زمانی انجام Pre-Test ارزش دارد؟
Pre-Test بیشترین ارزش را زمانی ایجاد میکند که هزینه کشف مشکل در آزمون اصلی زیاد باشد و هنوز امکان اصلاح محصول وجود داشته باشد. اگر نمونه نهایی بسیار گران است، ساخت نمونه جدید زمان زیادی میبرد، آزمون ماهیت مخرب دارد یا دسترسی به تجهیزات آزمایشگاهی محدود است، شناسایی یک ضعف طراحی در مرحله مقدماتی میتواند از هزینه و تأخیر قابل توجهی جلوگیری کند.
در پروژههایی که طراحی جدید است، تغییرات مهمی نسبت به محصول قبلی ایجاد شده، ماده یا تأمینکننده تغییر کرده یا تیم مهندسی درباره Margin طراحی اطمینان کافی ندارد، Pre-Test نیز میتواند اطلاعات مفیدی فراهم کند. همچنین اگر محصول در مراحل توسعه قرار دارد و هنوز چند گزینه طراحی در حال مقایسه هستند، انجام ارزیابی مقدماتی ممکن است به انتخاب Configuration مناسبتر برای ادامه توسعه کمک کند.
اما Pre-Test نباید صرفاً به این دلیل انجام شود که «همیشه قبل از آزمون اصلی یک پیشآزمون انجام میدهیم». هر فعالیت آزمون باید سؤال مشخصی را پاسخ دهد. اگر طراحی بهخوبی شناخته شده، شواهد کافی وجود دارد و ریسک آزمون پایین است، ممکن است Pre-Test ارزش زمانی و مالی چندانی ایجاد نکند.
چه زمانی Pre-Test ممکن است لازم نباشد؟
انجام آزمون بیشتر همیشه به معنی تصمیم مهندسی بهتر نیست. اگر محصول تغییر بسیار محدودی داشته و اثر آن تغییر با شواهد معتبر قبلی، تحلیل یا Verification مناسب پوشش داده شده باشد، ممکن است اجرای یک Pre-Test کامل ضرورتی نداشته باشد. در پروژهای دیگر، هزینه Pre-Test ممکن است تقریباً به اندازه آزمون اصلی باشد و نمونه نیز به تعداد کافی موجود باشد؛ در چنین شرایطی باید دید اطلاعات اضافهای که Pre-Test ایجاد میکند واقعاً ارزش هزینه و زمان آن را دارد یا خیر.
تصمیم مناسب بهتر است بر اساس ریسک، بلوغ طراحی، هزینه شکست، تعداد و ارزش نمونهها، میزان شناخت محصول و پیامد زمانی مردودی در آزمون اصلی گرفته شود. به همین دلیل Pre-Test را باید یک ابزار مدیریت ریسک مهندسی دانست، نه یک مرحله اجباری و ثابت در تمام پروژهها.
آیا قبولی در Pre-Test، قبولی آزمون رسمی را تضمین میکند؟
خیر. حتی اگر Pre-Test بسیار نزدیک به روش رسمی انجام شده باشد، نتیجه آن نباید بهعنوان تضمین قبولی آزمون بعدی تفسیر شود. نمونه مورد استفاده ممکن است متفاوت باشد، Toleranceهای تولید میتوانند اثر بگذارند، شرایط آزمون یا Setup ممکن است تفاوت داشته باشند و حتی اگر همه این موارد کنترل شوند، نتیجه یک نمونه بهتنهایی نمیتواند تمام تغییرات احتمالی محصول را پوشش دهد.
این موضوع بهخصوص زمانی مهم است که Pre-Test روی یک Prototype یا نمونه دستساز انجام شده باشد اما آزمون رسمی روی نمونهای با سطح بلوغ بالاتر یا Configuration متفاوت انجام شود. ممکن است Prototype به دلیل تقویت موضعی، روش ساخت متفاوت یا قطعات غیرتولیدی رفتاری نشان دهد که دقیقاً نماینده محصول بعدی نیست. بنابراین نتیجه Pre-Test باید همراه با شناخت دقیق Configuration و سطح بلوغ نمونه تحلیل شود.
اگر Pre-Test ناموفق باشد، آیا این اتفاق بدی است؟
لزومی ندارد. در واقع یکی از اهداف Pre-Test این است که مشکل را زمانی آشکار کند که هنوز امکان اصلاح وجود دارد. اگر یک نمونه توسعهای در Pre-Test رفتار نامناسبی نشان دهد، تیم مهندسی میتواند Failure Mode را بررسی کند، علت را پیدا کند و پیش از ورود به آزمون اصلی طراحی را اصلاح کند. از این زاویه، یک Pre-Test ناموفق که اطلاعات مفیدی تولید کرده میتواند برای پروژه ارزشمندتر از آزمونی باشد که فقط نتیجه Pass/Fail ارائه کرده اما درباره رفتار طراحی اطلاعات چندانی نداده است.
نکته مهم نحوه استفاده از داده است. اگر پس از شکست فقط نمونه تقویت شود تا آزمون بعدی را پشت سر بگذارد، بدون اینکه علت اصلی مشکل شناخته شود، ارزش مهندسی Pre-Test کاهش پیدا میکند. بهتر است نتیجه به Requirement، طراحی و Failure Mode مرتبط شود و مشخص شود تغییر پیشنهادی دقیقاً چه مسئلهای را برطرف میکند و آیا روی سایر ویژگیهای محصول اثر دارد یا خیر.
Pre-Test چه ارتباطی با Validation و Verification دارد؟
Pre-Test، Validation و Verification سه اصطلاح مترادف نیستند. Verification و Validation اهداف مهندسی هستند، در حالی که Testing یکی از روشهایی است که میتواند برای ایجاد شواهد در این فرآیندها استفاده شود. Pre-Test نیز نوعی فعالیت آزمون مقدماتی است که بسته به هدف پروژه میتواند به Verification یا Validation کمک کند.
برای مثال، تیم مهندسی ممکن است در مرحله Design Verification از یک Pre-Test برای بررسی اولیه Requirement مقاومتی استفاده کند و قبل از آزمون نهایی ضعف احتمالی طراحی را شناسایی کند. در پروژهای دیگر، یک Pre-Test میتواند بخشی از فعالیتهای Validation باشد و برای بررسی رفتار محصول در شرایط نماینده کاربرد استفاده شود. بنابراین جایگاه Pre-Test را هدف آزمون و سؤال مهندسی پروژه تعیین میکند.
اگر میخواهید تفاوت این مفاهیم را دقیقتر بررسی کنید، در مقاله «Validation و Verification چیست؟ تفاوت صحهگذاری و تصدیق در صنعت خودرو» درباره جایگاه Testing در V&V و تفاوت اهداف این دو فرآیند توضیح دادهایم.
یک مثال واقعی؛ Pre-Test صندلی خودرو
فرض کنیم یک صندلی جدید در حال توسعه است و تیم مهندسی قرار است عملکرد آن را در برابر الزامات مقاومتی مربوط بررسی کند. قبل از ارسال نمونه نهایی برای آزمون، تحلیلها نشان دادهاند یک ناحیه از Frame ممکن است Margin محدودی داشته باشد. یکی از گزینهها این است که مستقیماً نمونه نهایی ساخته و آزمون شود؛ گزینه دیگر این است که ابتدا یک نمونه توسعهای در یک Pre-Test مناسب بررسی شود تا رفتار واقعی ساختار بهتر شناخته شود.
در Pre-Test ممکن است تیم پروژه علاوه بر دادههای اصلی، روی تغییر شکل ناحیه موردنظر تمرکز کند، رفتار نمونه را در مراحل بارگذاری مشاهده کند و بعد از آزمون محلهای تغییر شکل یا شکست را بررسی کند. اگر ضعف طراحی تأیید شود، اصلاح میتواند پیش از ساخت نمونه بعدی انجام شود. وقتی طراحی به بلوغ مناسب رسید، نمونه مربوط به آزمون اصلی با Configuration و مدارک مشخص آماده خواهد شد.
برای مشاهده اطلاعات آزمون مرتبط با استحکام صندلی میتوانید صفحه آزمون استحکام صندلی خودرو – ECE R17 را در وبسایت تات بررسی کنید. وجود صفحه آزمون به این معنی نیست که هر Pre-Test الزاماً باید عیناً مطابق R17 انجام شود؛ هدف و شرایط Pre-Test باید متناسب با نیاز پروژه تعریف شوند.
آیا میتوان نمونه Pre-Test را برای آزمون رسمی هم استفاده کرد؟
پاسخ به نوع آزمون، شرایط Pre-Test و وضعیت نمونه بستگی دارد. اگر Pre-Test باعث بارگذاری، تغییر شکل، فرسودگی، باز و بسته شدن یا هر تغییری در ویژگیهای مؤثر نمونه شده باشد، استفاده مجدد از آن ممکن است نتیجه آزمون بعدی را تحت تأثیر قرار دهد. در آزمونهای مخرب، نمونهای که آسیب دیده معمولاً دیگر نمیتواند بدون بررسی بهعنوان نماینده شرایط اولیه موردنیاز برای آزمون بعدی در نظر گرفته شود.
حتی در Pre-Testهای غیرآسیبزا نیز باید بررسی شود آیا سابقه استفاده از نمونه روی نتیجه آزمون اصلی اثر دارد یا خیر. تصمیم نباید صرفاً با نگاه ظاهری گرفته شود؛ ممکن است قطعه بدون آسیب قابل مشاهده، تحت تنش یا سیکلهایی قرار گرفته باشد که رفتار بعدی آن را تغییر دادهاند. به همین دلیل، برنامه نمونهها باید پیش از شروع Pre-Test مشخص کند کدام نمونهها توسعهای هستند و کدام نمونهها برای آزمون اصلی رزرو شدهاند.
Configuration نمونه در Pre-Test چقدر اهمیت دارد؟
اگر هدف Pre-Test پیشبینی رفتار آزمون رسمی باشد، Configuration نمونه اهمیت زیادی پیدا میکند. تفاوت در ماده، ضخامت، محل اتصال، روش جوشکاری، Fixture، نرمافزار، قطعات جانبی یا حتی Revision طراحی میتواند نتیجه را تغییر دهد. هرچه نمونه Pre-Test از نمونه نهایی فاصله بیشتری داشته باشد، تعمیم نتیجه به محصول نهایی نیازمند احتیاط بیشتری است.
در مراحل اولیه توسعه ممکن است استفاده از Prototype کاملاً منطقی باشد؛ هدف آن مرحله شاید شناخت Failure Mode باشد، نه پیشبینی دقیق نتیجه نهایی. اما باید این محدودیت در گزارش و تصمیم مهندسی ثبت شود. عبارتی مانند «Pre-Test موفق بود» بدون ذکر اینکه چه نمونهای، با چه Revision و تحت چه شرایطی آزمون شده، اطلاعات کافی برای تصمیمگیری بعدی ایجاد نمیکند.
Pre-Test چگونه میتواند هزینه پروژه را کاهش دهد؟
صرف انجام Pre-Test هزینه پروژه را کاهش نمیدهد؛ اگر بدون هدف مشخص انجام شود حتی میتواند هزینه اضافی ایجاد کند. ارزش اقتصادی زمانی شکل میگیرد که Pre-Test احتمال کشف دیرهنگام یک مشکل پرهزینه را کاهش دهد. اگر شکست در آزمون اصلی به معنی ساخت نمونه جدید، رزرو دوباره آزمایشگاه، تغییر Tooling یا تأخیر در Milestone پروژه باشد، شناسایی همان مشکل در یک نمونه توسعهای میتواند ارزش قابل توجهی ایجاد کند.
به همین دلیل بهتر است پیش از تصمیم به Pre-Test سه چیز مشخص شوند: چه ریسکی را میخواهیم کاهش دهیم، نتیجه آزمون چه تصمیمی را تغییر خواهد داد و هزینه کشف مشکل در مرحله بعد چقدر است؟ اگر پاسخ روشنی برای این سؤالها وجود نداشته باشد، شاید Pre-Test فعالیت مناسبی برای پروژه نباشد.
برای یک Pre-Test مفید چه چیزهایی باید از قبل مشخص شوند؟
قبل از شروع، هدف آزمون باید به یک سؤال مهندسی روشن تبدیل شود. استاندارد یا روش مرجع، بخشهایی که قرار است بازتولید یا شبیهسازی شوند، Configuration و Revision نمونه، Setup و Fixture، پارامترهای اندازهگیری، شرایط توقف آزمون و نحوه تحلیل نتیجه بهتر است از قبل مشخص باشند. اگر هدف مقایسه چند طراحی است، شرایط آزمون نیز باید بهاندازه کافی کنترلشده باشند تا تفاوت مشاهدهشده واقعاً به طراحیها مربوط باشد.
در پروژههایی که قرار است بعد از Pre-Test وارد آزمون رسمی شوند، برنامه نمونهها نیز اهمیت زیادی دارد. تعداد نمونه، امکان استفاده مجدد، ترتیب آزمونها و زمان لازم برای اصلاح طراحی و ساخت نمونه جدید باید در برنامه دیده شوند. برای آمادهسازی نمونه آزمون نیز مقاله «قبل از ارسال خودرو یا قطعه به آزمایشگاه چه چیزهایی باید بررسی شود؟» جزئیات مربوط به استاندارد، Configuration، مدارک، Fixture و تفاوت نمونههای Validation، Type Approval و CoP را توضیح میدهد.
آیا آزمایشگاه میتواند Pre-Test را طراحی کند؟
آزمایشگاه میتواند در تعریف روش اجرایی آزمون و بررسی امکان انجام آن نقش داشته باشد، اما سؤال اصلی Pre-Test باید از نیاز پروژه بیاید. تیم توسعه باید بداند چه Requirement، ریسک یا Failure Modeای نیازمند بررسی است و نتیجه قرار است چه تصمیمی را پشتیبانی کند. بعد از مشخص شدن این هدف، میتوان درباره Setup، روش اندازهگیری و شرایط مناسب آزمون تصمیم گرفت.
در پروژههایی که هنوز استانداردهای قابل اعمال، برنامه آزمون یا روش مناسب ارزیابی مشخص نشده است، خدمات مهندسی و مشاوره تات میتواند برای بررسی الزامات، برنامهریزی آزمون و پشتیبانی فنی فرآیند صحهگذاری مورد استفاده قرار گیرد. این خدمات به معنی تضمین نتیجه آزمون رسمی نیست؛ هدف، کمک به تعریف و برنامهریزی بهتر فعالیتهای فنی پروژه است.
نتیجه Pre-Test را چگونه باید تفسیر کرد؟
یکی از اشتباهات رایج این است که نتیجه Pre-Test فقط با دو کلمه Pass و Fail ثبت شود. اگر هدف آزمون توسعه محصول است، اطلاعاتی که درباره رفتار نمونه به دست آمدهاند میتوانند از خود نتیجه نهایی مهمتر باشند. محل شروع تغییر شکل، روند نیرو و جابهجایی، شرایط فعال شدن یک سیستم، Failure Mode و تفاوت میان نمونههای مختلف میتوانند اطلاعاتی باشند که تصمیم طراحی بعدی را شکل میدهند.
گزارش Pre-Test بهتر است مشخص کند چه نمونهای با چه Revision و Configuration آزمون شده، چه شرایطی با آزمون اصلی یکسان یا متفاوت بودهاند، چه دادههایی ثبت شده و نتیجه تا چه محدودهای قابل تعمیم است. چنین مستندی بعداً کمک میکند تیم پروژه نتیجه یک نمونه توسعهای را اشتباهاً به Configuration دیگری نسبت ندهد.
Pre-Test باید ریسک را کم کند، نه فقط یک آزمون دیگر به پروژه اضافه کند
ارزش Pre-Test در تعداد آزمونهای انجامشده نیست؛ در اطلاعاتی است که پیش از یک تصمیم پرهزینه در اختیار تیم پروژه قرار میدهد. اگر یک پیشآزمون بتواند ضعف طراحی را زودتر آشکار کند، Configuration مناسبتر را مشخص کند یا نشان دهد محصول هنوز برای آزمون اصلی آماده نیست، میتواند از ساخت نمونه اضافی، تکرار آزمون و تأخیر پروژه جلوگیری کند. در مقابل، Pre-Test بدون سؤال مشخص و بدون برنامه استفاده از نتیجه، فقط یک فعالیت اضافی خواهد بود.
به همین دلیل، پیش از تصمیم به انجام Pre-Test بهتر است پرسیده شود: چه چیزی را هنوز درباره محصول نمیدانیم، این عدم اطمینان چه ریسکی برای آزمون اصلی ایجاد میکند و نتیجه Pre-Test قرار است چه تصمیمی را تغییر دهد؟ اگر پاسخ این سه سؤال روشن باشد، میتوان روش و نمونه مناسب را انتخاب کرد و Pre-Test را به بخشی هدفمند از فرآیند توسعه تبدیل کرد؛ نه نسخه غیررسمی و تکراری آزمونی که قرار است بعداً دوباره انجام شود.