این نوشته میتوانست عنوانی مثل «چرا برنامه نویس باید کد خود را تست کند؟» داشته باشد. به این خاطر که به شیوه با بهتر بگویم آسیبی در برنامه نویسی اشاره میکند که شاید در بسیاری از شرکتهای نرم افزاری پیشرفته سالهاست که دیگر دیده نمیشود. Happy path در واقع روشی ابتدایی در برنامه نویسی است که در آن برنامه نویس ابتدا خواسته های که یک feature مانند صفحه احزار هویت یک وب سایت، باید تامین کند را بررسی میکند و سپس کد آن را طوری مینوسید که خواسته های عملکردی (functional) برآورده شود. یعنی به نام کاربری و رمزعبور صحیح اجازه دسترسی میدهد. در واقع تمرکز برنامه نویس برروی برآورده کرده عمکلرد منطقی است. Happy path نیز همین انجام use case اولیه است. برنامه نویس حتی میتواند برای کدی خود unit test نیز به صورت happy هم بنویسد. مثلاً User:aa Password:Complic@ted را قبول و چیزی غیر از آن را رد کند. ولی خب، مگر این به تنهایی تست کاملی است؟ این کد بر روی سخت افزار و تنظیمات مشخص وب سرور قرار است به چه میزان درخواست همزمان پاسخ دهد؟ در صورتی که یک Fuzzer شروع به بمباران آن با attack vector های مختلف کرد، عکس العمل آن چیست؟ آیا تلاشهای موفق و ناموفق را برای بررسی های آینده log میکند؟
این موضوع که شاید برای عده ای بسیار ابتدایی بنظر برسد درواقع exception ها، condition error ها و نیازهای غیرعملکردی مانند امنیت، سادگی استفاده یا کارایی را در نظر نمیگیرد. اما با این وجود happy path حتی در میان برنامه نویسان و تست نویسان با تجربه هم دیده میشود. برای خود من بارها پیش آمده که قسمتی از نرم افزار با وجود داشتن تست های اتوماتیک در سطوح مختلف باز هم به خاطر موارد پیش پا افتاده در محیط مشتری دچار مشکل شده است. ولی بررسی های بعدی نشان میدهد که این تست ها happy path بوده و روشهای مختلفی که ممکن است کاربر در تجربه روزانه یا به اشتباه از آن استفاده کند را پوشش نداده است. Crash ها نرم افزاری حاصل همین شیوه غلط است. اما آیا happy path تا اندازه ای ذاتی و برخواسته از شیوه تفکر یک برنامه نویس نیست؟ یک برنامه نویس میخواهد کدی را بنویسد که فقط نیاز عملکردی یا functional درخواست کننده را برآورده کند. در نظر او کاربر تنها قرار است از نرم افزار به شیوه ای که او در ذهن دارد استفاده کند. قرار نیست کسی نرم افزار را هک کند. قرار نیست افراد زیادی در آن واحد از آن استفاده کنند. قرار نیست RAM ها پرشوند، سرعت شبکه پایین بیاید.قرار نیست شرکت بخاطر bug های نرم افزار مشتری را از دست بدهد. در واقع برنامه نویس قصه ما یک انسان خوشحال است ?
هرچند با پیشرفت برنامه نویسی و رقابتی شدن هرچه بیشتر بازار، برنامه نویسان هم امروزه بیشتر به فکر بالا بردن کیفیت کدهای خود هستند ولی در هر صورت شیوه تفکر happy path در برنامه نویسی به ذات وجود دارد. در کتاب مرجع ISTQB چهار سطح از لحاظ جدایی برنامه نویس و تست کننده از یکدیگر در مواجهه با happy path در نظر گرفته شده است:
این چهار درجه از جدایی برنامه نویسی و تست که انجام آن از بالا به پایین پرهزینه تر میشود بر این اصل بنا شده است که تست کننده هر چه بیشتر از برنامه نویس فاصله داشته باشد، برنامه را با ذهنی مستقل تر و نقادانه تر تست میکند. در اینجا باز هم مدیران نرم افزار هستند که باید با توجه به بودجه، تواناییهای داخلی، حساسیت نرم افزار و بازار مصرف برای استفاده از ترکیبی از موارد بالا تصمیم گیری کنند.
