https://virgool.io/feed/@baf مهندس تست و امنیت نرم افزار https://www.linkedin.com/in/behroozaghakhanian fa 2026-07-07 12:37:55 https://files.virgool.io/upload/users/85562/avatar/1L7jvZ.png?height=120&width=120 https://virgool.io/@baf https://virgool.io/@baf/bug-rkdxzxnerwhs تاریخ انتشار نسخه اصلی 9 آوریل, 2017یکی از کارهای روزانه  تیمهای نرم افزاری تصحیح باگهای گزارش شده است. گزارش هایی که یا از سمت مشتری و بخش پشتیبانی ایجاد میشود یا تست کنندگاه سیستم و یا خود برنامه نویسان. در واقع فرقی نمیکند که نرم افزار تولید شده در دوره رشد یا دوره بلوغ  و نگهداری خود باشد. باگها همیشه هستند و همیشه هم باید آنها را با توجه به الویتشان درست کرد. برای گزارش و پیگیری باگها هم سیستمهای یکپارچه رایجی مانند Jira، YouTrack  یا Zandesk وجود دارد که کار را برای بخش فنی و پشتیبانی ساده کرده اند. اما متاسفانه در موارد بسیاری این باگها پس از تصحیح، تایید و patch شدن به دست فراموشی سپرده میشوند ?یکی از فرایندهایی که در بخشهای فنی کارا و با سابقه وجود دارد، تحلیل باگها یا اصطلاحاً Defect Analysis است.  در این فرایند تیمهای نرم افزاری بجای فراموش کردن باگها در طول زمان، هر یک ماه در جلسهای دور هم مینشینند و باگهای گزارش شده در ماه گذشته را بازنگری، دسته بندی و تجزیه و تحلیل میکنند تا هم شناخت بهتری از وضعیت سیستم داشته باشند و هم علل اصلی ایجاد باگها یا اصطلاحاً Root Cause را با برنامه ریزی رفع کنند. روشهایی برای هم دو کار یعنی تحلیل باگ و تحلیل علل اصلی ایجاد باگ مانند Fishbone Diagram وجود دارد اما در چند خط پیش رو میخواهم تجربه شخصی خود در این مورد بنویسم.برای تحلیل باگها اولین کار ایجاد معیارهایی برای دسته بندی آنهاست. تعدادی از این دسته بندیها مانند نسخه نرم افزار و اولویت آن به طور پیشفرض در سیستمهای مدیریت باگ وجود دارد. اما میتوان موارد زیر را که برای تحلیل مهمتر است را به آن افزود:آیا این باگ قبلاً نیز گزارش و تصحیح شده؟باگ بخاطر نارسایی در کدام بخش از چرخه تولید نرم افزار رخ داده است؟ مشکل باگ بخاطر تعریف نادرست در نیازمندیها بوده یا در طراحی و پیاده سازی درست صورت گرفته و یا به خاطر نبودن محیط مناسب برای تست بوده است؟ حتی میتواند بخاطر اشکال در زمان نصب یا patch کردن رخ داده باشد.آیا این باگ انقدر مهم بوده است که روند انتشار عمومی نرم افزار را دچار اختلال کند؟ در واقع به نوعی Show Stopper بوده یا نه. بسیاری از شرکتها دوره مشخصی مانند یک هفته، یا یک ماه برای انتشار نسخه عمومی یا patch دارند که در رابطه مستقیم با قرارداد یا سطح سرویس با مشتری است. وجود این باگها معمولا بیانگر مشکلی جدی در سیستم است که حتی تستهای متعدد اتوماتیک و دستی هم در پیدا کردنشان موفق نبوده اند.باگ توسط چه بخش و در قالب چه تستی پیدا شده است؟ مهم است که باگ توسط مشتری پیدا شده باشد یا در جریان تست و یا توسط خود برنامه نویس. روند باید طوری باشد که باگها بیشتر ابتدا در فرایند تولید و بعد از آن در جریان تست ها مشخص بشوند.یکی از وظیفه های تست کننده در تیم نرم افزار میتواند تحلیل و دسته بندی باگها بر اساس معیارهای بالا و آوردن نتایج برای بررسی در جلسه ادواری تحلیل باگها باشد. حاصل این جلسات موارد زیر است:اولویت بندی مشکلات بر اساس تعداد و اهمیت باگهای گزارش شده در آن زمینه، پیدا کردن علل اصلی بودن این تعداد باگ و شروع فرایند تحقیق و تصحیحپیدا کردن ضعف در مرحله مشخص از چرخه تولید مانند تعریف نیازمندی ها و تلاش برای حل آن با قسمت مربوطه یا حتی رفع مشکل ارتباطی میان بخشهابازبینی تست های اتوماتیک و دستی. ممکن است به این نتیجه برسیم که وجود تعدادی از تستها سودی نداشته و در عوض تلاش کنیم تا تستهای دیگری را اضافه کنیم و یا محیطهای بیشتری را برای تست پوشش دهیم.انجام این فرایند در ماههای متمادی میتواند راهی باشد برای کاهش میزان مشکلات نرم افزار و شناخت بیشتر از وضعیت آن. بهروز بهروز Sat, 14 Dec 2019 17:27:27 +0330 https://virgool.io/@baf/stackify-%DB%8C%D8%A7-%DA%86%DA%AF%D9%88%D9%86%D9%87-%D8%B6%D8%B1%D8%A8%D8%A7%D9%86-%D9%82%D9%84%D8%A8-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%B1%D8%A7-%D8%A8%DA%AF%DB%8C%D8%B1%DB%8C%D9%85-azhgzwpx4t64 تاریخ انتشار نسخه اصلی مارس 6, 2017امروزه بسیاری از شرکتهای نرم افزاری خدمات خود را بر روی  cloud (نمیدونم واژه ابری معادل رایجی هست یا نه)  ارائه میکنند. در واقع مدل کسب کار به این صورت است که این شرکتها منابعی زیر ساختی مانند سخت  افزار، سیستم عامل و پایگاه داده را از شرکتهایی مانند آمازون یا مایکروسافت (IaaS) اجازه میکنند، نرم افزار خود را روی آن پیاده سازی میکنند و خدماتی خود را عمداً به صورت اشتراک به مشتری خود میفروشند (SaaS). با این کار یکی از مشکلات مهم صنعت نرم افزار یعنی عیب یابی و شبیه سازی باگها در محیط  برنامه نویسی به مراتب ساده تر میشود. به این معنا که شرکت تولید کننده نرم افزار بر روی محیط پیاده سازی (deployment) کنترل دارند و با استفاده از ابزارهای مانیتورینگ به طور مدائم عملکرد نرم افزار مانند میزان مصرف CPU یا حافظه کنترل میشود. اما گسترش خدمات cloud به این معنا نیست که شیوه قدیمی تر یعنی پیاده سازی on-premise را باید فراموش کرد. بسیاری از مشتری به دلایل امنیتی، کافی نبودن سرعت اینترت یا هزینه بر بودن تغییر، در صورت وجود خدمات cloud همچنان شیوه on-premise را که در واقع پیاده سازی نرم افزار در محیط سخت افزاری تحت کنترل مشتری است را ترجیح میدهند.شمایی که این مطلب را میخوانید احتمالاً سختی عیب یابی در محیط مشتری را چشیده اید. اتصال راه دور با دسترسیهای محدود، بررسی یا کپی کرده log ها و بعد هم تلاش برای شبیه سازی مشکل در محیط debug. به عنوان تست کننده ای که با برنامه نویسان در ارتباط نزدیک روزانه هستم بخش جمع آوری log ها و شبیه سازی باگ مشتری یکی از کارهای روزانه ام است. کاری که نیاز به همکاهنگی و مکاتبهای چند روزه با بخش پشتیبانی  دارد آن هم تنها برای گرفتن کمی اطلاعات بیشتر. در واقع کلا دردسر است ?یکی از آرزوهای هر تیم نرم افزاری که نرم افزارش چه روی cloud یا on-premise پیاده سازی میشود این است که profiling که   بر روی کامپیوتر خود دارند را برای محیطی راه دور که نرم افزار برروی آن قرار دارد هم داشته باشند. به  این معنا که بداند مثلا کدام درخواستهای وب query بیشتری را به پایگاه داده میزند، کدام متد ها بیشتر فراخوانده میشوند یا اینکه log خطاهای نرم افزارها  را با جزئیات بیشتری داشته باشند. Stackify راه حلی کلاینت-سروری است که این امکان را در اختیار تیم نرم افزاری قرار میدهد. این شرکت که در سال 2012 در امریکا تاسیس شده است با شعار محبوب این روزها یعنی «از توسعه دهندگان برای توسعه دهندگان» میخواهد به شما بگوید «WTF your code is doing» ? به این صورت که کلاینت آن بنام Retrace برروی سیستمها راه دور که نرم افزار شما روی نصب شده است قرار میگیرد و به عنوان یک profiler و جمع کننده log، داده ها را برای تحلیل و نمایش به سرور خود  یعنی Prefix میکند. البته Prefix را میتوان  طور مستقل به عنوان یک profiler پیشرفته بر روی محیط برنامه نویسی نصب کرد، هرچند Stackify ادعا میکند که راه حل اش تنها یه profiler یا devAPM (سیستم مدیریت کارایی نرم افزار) نیست و میتواند به طور هوشمند باگها سیستم را هم گزارش داده و با tracking پیشرفته نحوه رفع آنها را هم پیشنهاد دهد. در هر صورت اگر میخواهید بیشتر با آن آشنا شوید میتواند محیط زنده demo اش را در پیوند زیر مشاهده کنید:https://sandbox.stackify.com/Stacks/WebApps بهروز بهروز Sat, 07 Dec 2019 16:48:32 +0330 https://virgool.io/@baf/knowledge-ndlreifnm6ay تاریخ انتشار نسخه اصلی 20 فوریه, 2017عنوان این پست، سوالی است که هم مهندسان تست میپرسند و هم شرکتهایی که میخواهد آنها را استخدام کنند. اینکه  برای تست نرم افزار آیا لازم است که فرد به زبان برنامه نویسی نرم افزار تسلط داشته باشد یا اینکه اگر تنها محصول نرم افزاری را به عنوان یک کاربر پیشرفته بشناسد کافیست؟ در این یاداشت کوتاه سعی میکنم با توجه به مشاهدات خود در شرکتهای مختلف، آگهی های کاریابی و فرآیندهای مصاحبه تا حد توان به این سوال پاسخ دهم.Grace Brewster Murray Hopper seated at the input console for the UNIVAC Iپیشتر نوشته بودم زمانی که کیفیت و سرعت رساندن محصول به بازار (time to market) در بازار رقابتی امروز اهمیت پیدا کرد، شرکتهای کوچک و متوسط سعی کردند تا با استخدام نیروهای تست یا استفاده از کارکنانی که در استفاده از محصول نرم افزاری وارد بودند، عیب ها را به همراه بازخوردهای مناسب هر چه سریعتر و پیش از گزارش آن توسط مشتری، به تیم نرم افزاری منتقل کنند. این گونه تست ها اغلب به صورت غیرخودکار بود و بازخوردهای تست کننده نیز غیرفنی. به این صورت که برنامه نویسان میبایست بعداً با صرف زمان و آزمون و خطا موضوع گزارش شده را مورد بررسی قرار میدادند. با گسترش و محبوبیت شیوه Agile، موضوع تست و بازخورد سریع، از این هم مهمتر شد. تیمهای نرم افزاری کوچک شدند، continuous integration امکان کار تیمی بهتر و کوچکتر شدن چرخه انتشار (release cycle)  را فراهم کرد و بسیاری از تستها به صورت خودکار درآمدند. در این تغییر و تحول تست کنندگان هم باید مهارتها تازه یاد میگرفتند. سال 2010 بررسی بر روی آگهی های کاریابی برای مهندس تست در امریکا صورت گرفت که نشان میداد 80 درصد شرکتها به دنبال کسانی هستند که «حتماً» یا «بهتر است»برنامه نویسی بدانند. اما چرا درخواست برای مهندس تستی که برنامه نویسی میداند افزایش پیدا کرده است؟خودکار سازی تست: امروزه خودکار کردن تستهایی که برای کد کامپایل شده (تست جعبه سیاه و خاکستری) صورت میگیرد اغلب توسط مهندس تست نوشته میشود. در شرکتهایی نیز نوشتن unit test بر روی کد نیز به تست کنندها سپرده میشود. این موضوع باعث شده است که تست کننده حتی اگر مسلط به مهندسی نرم افزار و یا زبانهایی مانند Java یا C نیست ولی حداقل بتواند با Python یا مثلا Powershell اسکریپت نویسی کند و از ابزارهای خودکاری سازی مانند Selenium بهره بگیرد.منهدس تست به عنوان عضوی از گروه برنامه نویسی: با گسترش شیوه Agile، مهندس تست عضوی از گروه 3 تا 5 نفری است. به این معنا که هر روز در ارتباط دائم با آنهاست. این موضوع مستلزم آن است که سطح زبان فنی همه اعضا از جمله تست کننده نزدیک به یکدیگر باشد تا بتواند ارتباط موثرتری برقرار کرده و اصطلاحات فنی روزمره را متوجه شوند. همچنین  تست کننده باید بتواند به طور مثال با بررسی log ها، مانیتور کردن سرویسها و ترافیک شبکه اطلاعات دقیقتری از وضعیت سیستم در حالتها متفاوت ارائه دهد. این سطح از ارتباط فنی مسلماً برای افرادی که برنامه نویسی میدانند ساده تر است.هرچند داشتن مهارت فنی بالاتر و دانستن برنامه نویسی در بازار کار امروز فرصتهای بیشتری را پیش روی مهندسان تست قرار میدهد. ولی مسلماً شرط کافی نیست. از نظر من وظیفه بخش کنترل کیفی نرم افزار یا همان QA دادن بازخوردهای سریع و دقیق به تیم نرم افزارست. برای این منظور تست کنند میباید فردی باشد با تفکری منتقد و تحلیلی که بتواند مسائل مختلف سیستم را با موشکافی بررسی کند. داشتن دانش فنی و برنامه نویسی تنها کمکی است در این راستا. بهروز بهروز Wed, 04 Dec 2019 12:57:23 +0330 https://virgool.io/@baf/sikuli-ewncba2o0cau تاریخ انتشار نسخه اصلی 5 فوریه, 2017در پست گذشته در مورد ابزارهای اتوماسیون تست برنامه های دسکتاپ نوشتم. در این پست میخواهم در مورد یکی این ابزارها بنام Sikuli بیشتر توضیح بدهم. نکته اول اینکه Sikuli صرفاً برای اتوماسیون دسکتاپ نیست. این برنامه بر دو پایه استوار است. 1) الگوریتم تطبیق تصویر(Template Matching) موجود در OpenCV و 2) شبیه سازی رخدادهای موس و کیبورد با استفاده از java.awt.event.InputEvent. در نتیجه هر آنچیزی را که بر روی مانیتور است را تشخیص داده و میتواند اتوماتیک کند. اما به دلیل محبوبیت Selenium برای وب، استفاده از آن بیشتر محدود به دسکتاپ است. این برنامه قابل اجرا بر روی ویندوز، لینوکس و Mac بوده و فعلا سیستم عاملهای موبایل را رسماً پشتیبانی نمیکند. پروژه Sikuli ابتدا در دانشگاه MIT شروع شد اما از سال 2012 با دست کشیدن آغازکنندگاه آن، پروژه را برنامه نویسی بازنشسته  در آلمانی بنام RaiMan با عنوان تازه SikuliX ادامه داد و امروز هم جامعه برنامه نویسی نسبتاً خوبی بر روی GitHub در آن مشارکت میکنند. این برنامه IDE هم ارائه میکند که بسیار ساده و ابتدایی است و خوبی اصلی آن آسان کردن عملیات مربوط به تصویر مانند کپچر کردن و تشخیص offset یک تصویر است. وگرنه میتوان بسازگی API آن را در زبانهای مورد حمایت آن وارد و در IDE های پیشرفته مانند Eclipse یا PyCharm استفاده کرد.خود من کار با آن را با IDE خودش شروع کردم که میتوان در آن با استفاده از Python اسکریپ نوشت. Sikuli یکی از راه هایست که میتوان افرادی که تا بحال برنامه نویسی نکرده اند را به این کار علاقه مند کرد. IDE و منطق استفاده بسیار ساده ای دارد که بعد از یادگیری میتوان از طریق اضافه کردن کد های Python و وارد کردن ماژولهای Java آن را گسترش داد، به سیستم continues integration متصل کرد و به یک ابزار کارآمد برای اتوماسیون یا تست تمامی برنامه های وب و دسکتاپ تبدیل کرد. برای شخص من این ابزار آنجایی اهمیت بیشتری پیدا میکند که میخواهیم یکپارچگی سیستم از دید کاربر نهایی حفظ کنیم. به طور مثال در مورد برنامه های تحت وب، المانهایی وجود دارد که بعد از render شدن به دلایل مختلف از دید کاربر پنهان هستند ولی Selenium آنها را تشخیص میدهد. اما Sikuli تنها چیزی را تشخیص یا عملی را انجام میدهد که کاربر معمولی هم میتواند آن را تشخیص داده و عملی را روی آن انجام دهد. تست Sikuli که من بروی محصول نرم افزاری شرکتی در آن مشغول بکار هستم، نوشته ام نیز دقیقاً همین کار را انجام میدهد. یعنی تست یکپارچگی دیداری و عملکردی نرم افزار از دید کاربر نهایی. هر گونه تغییر برنامه ریزی نشده در ظاهر نرم افزار باعث شکست تست میشود.محیط توسعه Sikuliالبته این دقت در انجام تست نیز بی هزینه نیست. اول آنکه برای اجرای تست نیاز به کارت گرافیکی و مانیتور است. هر چند Sikuli را میتوان از طریق VNC نیز اجرا کرد. البته از آنجایی که راهکارهای ارائه شده توسط جامعه برنامه نویسان فعال چندان مورد استقبال قرار نگرفته است در نتیجه زیاد قابل اطمینان نیستند. بهروز بهروز Sat, 30 Nov 2019 17:09:11 +0330 https://virgool.io/@baf/desktop-automation-ftym8qxjcw8v تاریخ انتشار نسخه اصلی 22 ژانویه, 2017تا به امروز آنچه در مورد اتوماسیون تست نوشته ام مربوط به برنامه های تحت وب بوده است. شاید به این علت باشد که در دنیای امروز نرم افزار، تمرکز بیشتر بر روی توسعه برنامه وب و موبایل است. بسیاری از شرکتهای نرم افزاری که راه حلی مبتنی بر پلتفرمهای دسکتاپ داشته اند، با توجه به نیازهای بازار به شدت رقبتی امروز، پلتفرم خود را عوض کرده و اتوماسیون تست را هم برای بالا بردن کیقیت از ابتدا در چرخه تولید نرم افزار قرار میدهند. سالهایی که نرم افزارهای مبتنی بر دسکتاپ مانند برنامه های تحت ویندوز، مکینتاش، جاوا، فلش رواج داشت، طراحی و اجرای فرایند های تست چندان جدی گرفته نمیشد. برای همین امروز هم که نگاهی به ابزارهای تست دسکتاپ میاندازیم، اکثرا برنامه هایی ساده هستند که از ابتدا مانند macro ها در ویندوز، صرفاً برای اتوماتیک کردن کارهای تکراری استفاده میشدند. در واقع بر روی تعداد کمی از آنها میتواند عنوان ابزار تست را گذاشت. ابزارهایی که علاوه بر اتوماسیون، راهکارهای مناسبی برای assertion، پیاده سازی BDD یا تست های مبتنی بر داده و قابل استفاده بودن در زبانهای مختلف برنامه نویسی را داشته باشند. اتوماسیوت تست برنامه دسکتاپ و برنامه های تحت وب یا موبایل از اصول مشترکی پیروی میکنند، اما آنچه توسعه ابزارهای تست دسکتاپ را مشکل میکند پشتیبانی از فناوریهای متنوع مانند برنامه ای تحت dotNet، میتنی بر جاوا، فلش، WPF، لینوکس، MacOS و غیره است. در ادامه ابزارهایی اتوماسیون تست رایج در این زمینه را معرفی میکنیم:ابزار Sikuli: شاید شناخته شده ترین ابزار برای برنامه دسکتاپ و قابل استفاده در تمام پلتفرمها باشد. به این دلیل که مکانیزم تشخیص اش بر اساس تصویر است. در واقع شعار Sikuli این است که «هر چه را بر روی مانیتور میبینید اتوماتیک کنید». با این حال به خاطر محبوبیت ابزارهای مبتی بر Selenium برای وب و موبایل، استفاده از آن بیشتر معطوف به دسکتاپ شده است. برنامه ای رایگان با کد باز، ساده برای یادگیری، با امکان استفاده از در سایر زبانهای برنامه نویسی که خود مبتنی بر Jython است. Sikuli در نگاه اول ابزاری ابتدایی بنظر میآید. اما از آنجایی که میتوان از کلاسهای Java و Python در آن استفاده کرد، در عین حال ابزاری بسیار کاراست. از آنجایی که اساس کار این ابزار بر مبنی تشخیص تصویر است، یکپارچگی کد در محیط نوشتن و اجرا بسیار مهم است. مثلا اگر اندازه یک پنجره تغییر کند یا پشت پنجره ای دیگر مخفی شده باشد، تست منفی میشود. برای همین، به نظر من در سناریوهایی که یکپارچگی رابط گرافیکی مهم است Sikuli بسیار مناسب است.ابزار AutoIt: ابزاری است که ابتدا برای اتوماتیک کردن عملیات مختلف در برنامه های خود سیستم عامل ویندوز استفاده میشد. اما کم کم برای برنامه دیگر تحت ویندوز و هم تست آنها نیز استفاده شد. فرایند تشخیص عمداً از طریق win32 api و COM است. امکان ضبط و رکورد عملیات تست و تولید خودکار کد تست، کار با این ابزار را راحت میکند. ابزاری رایگان است که wrapper آن برای زبانهای مانند Python هم نوشته شده است. کمبود اصلی آن محدود بودن به ویندوز است و امکان استفاده از آن در Linux یا MacOS وجود ندارد.Run(&quotWinampInstall.exe&quot) WinWaitActive(&quotInstaller Language&quot) Send(&quot{ENTER}&quot) WinWaitActive(&quotWinamp Installer&quot) Send(&quot{ENTER}&quot) WinWaitActive(&quotWinamp Installer&quot, &quotLicense Agreement&quot) Send(&quot{ENTER}&quot) WinWaitActive(&quotWinamp Installer&quot, &quotChoose Install Location&quot) Send(&quotC:\Applications\Winamp&quot) Send(&quot{ENTER}&quot) WinWaitActive(&quotWinamp Installer&quot, &quotChoose Components&quot) Send(&quot{ENTER}&quot) WinWaitActive(&quotWinamp Installer&quot, &quotChoose Start Options&quot) Send(&quot{ENTER}&quot) WinWaitActive(&quotWinamp Installer&quot, &quotGet the Most Out of Winamp&quot) Send(&quot{TAB}{TAB}{SPACE}{TAB}{SPACE}{TAB}{SPACE}{TAB}{SPACE}&quot) Send(&quot{ENTER}&quot) WinWaitActive(&quotWinamp Installer&quot, &quotInstallation Complete&quot) Send(&quot{TAB}{SPACE}{ENTER}&quot)ابزار Code UI: ابزاری هست که در نسخه Enterprise برنامه Visual Studio قرار دارد. در نتیجه تیمهایی هم از آن استفاده میکنند که بر روی راه حل های تجاری مبتنی بر ویندوز کار میکنند. امکان ضبط مراحل تست و تولید اتوماتیک کد به صورت VBscript و #C هم در آن وجود دارد. علاوه بر این برای اتوماسیون تحت وب هم میتوان از آن استفاده کرد. هرچند برای پشتیبانی از Chrome و Firefox نیاز به افزونه های مجزا دارد. در کل میتوان گفت ابزاری است که در میان جامعه مایکروسافتی محبوبیت دارد.در ویدئو زیر میتوانید نحوه استفاده از آن برای تست برنامه ماشین حساب ویندوز را ببینید:https://www.youtube.com/watch?v=nSrV2DYx_cIعلاه و موارد بالا ابزارهای عمداً تجاری و بزرگی دیگری مانند TestComplete و QTP هم وجود دارند که از برنامه ای مبتنی بر دسکتاپ نیز پیشتیبانی میکنند. اما بتازگی تعدادی از برنامه نویسان مایکروسافت پروژه ای کوچک و کد بازی بنام WinAppDriver را آغاز کرده اند که ایده آن در واقع راه حلی مانند Selenium Webdriver است که برای سیستم برنامه تحت ویندوز، چه دسکتاپ و چه موبایل استفاده شود. در پست های آینده در مورد این ابزاز و همچنین Sikuli که در میان موارد نام برده محبوبیت بالاتری دارد، بیشتر مینویسم. بهروز بهروز Tue, 26 Nov 2019 13:43:11 +0330 https://virgool.io/@baf/browserstack-fh06yyvlqosa تاریخ انتشار نسخه اصلی 8 ژانویه, 2017یکی از دغدغه های مهم در تست نرم افزار، اجرای تست بر روی تمامی پلاتفرمهای پشتیبانی شده است. کاری که به علت تکراری بودن تست و گسترگی اجرا میبایست به صورت اتوماتیک انجام شود. نرم افزارهای تحت وب به علت تنوع فراوان در محیطهای اجرا یکی از پیچیده ترین نرم افزارها برای تست به حساب میایند. این تنوع شامل موارد زیر میشود:نرم افزار مرورگر مانند IE, Edge, FireFox, Opera, Safari, Chromeنسخه مرورگر: با توجه به حجم توسعه بالا در زمینه وب مرورگرها مدام برای پشتیبانی از استاندارها و پروتکهای مختلف بروز میشوند. در موارد زیادی نخسه های جدیدتر رفتار نسخه های پیشین را ندارند. بطور مثال نسخه ای ممکن است فایلهای فلش را به صورت پیشفرض بارگذاری نکند با مثلا یه سری security header را نشناسد.سیستم عامل: مهم است که مرورگر برای چه سیستم عاملی ( مثلا ویندوز، لینوکس، Mac OS، iOS یا اندروید) نوشته شده استوضوح تصویر یا Resolution ی که قرار است برنامه وب در آن نمایش داده شود.این تنوع یکی از چالشهای هر روز برنامه نویسان front-end و تست کننده هاست. هر چند امروز مرورگرهایی مانند Chrome میتوانند resolution های مختلف را شبیه سازی کنند ولی تست بروی مرورگرهای مختلف و مشکلتر از آن، سیستم عمل های مختلف همچنان چالشی بزرگ است.Emulator هایی مانند Android Emulator از گوگل یکی از راههای غلبه بر این پیچیدگی است ولی فراهم کردن سیستم عاملی مانند iOS یا Mac به صورت قانونی نیازمند خرید سخت افزار Apple است. این هزینه ها در صورت نیاز به پشتیبانی از نسخه های مختلف سیستم عامل ها یا تلفنهای همراه بالاتر هم میرود.از آنچه گفته شد میتوان نتیجه گرفت تنوع محیط تست و هزینه راه اندازی و نگهداری از آن دو چالش اصلی در تست نرم افزارهای تحت وب است.  در سالهای اخیر شرکتهای اینترنتی مختلفی اقدام به ارائه راه حلهایی آنلاین برای این مشکل داده اند:آنهایی که مانند Screenfly تنها resolution مدلهای مختلف موبایل، تبلت و دسکتاپ را فراهم میکنند.آنهایی که مانند Browserling نسخه های مختلف مرورگرها و سیستم عامل های مختلف را برای تست غیر اتوماتیک فراهم میکنند.آنهایی که علاوه بر موارد بالا امکان تست اتوماتیک و یکپارچگی با Continuous Integration را نیز فراهم میکنند.راه حل شرکت BrowserStack راه حلی است که جزو مورد سوم است. این شرکت که توسط مهندسان هندی در بمبئی (Mumbai) تاسیس شده است توانسته توجه شرکتهای بزرگی را به خود جلب کند. امکانات BrowserStack شامل:تست دستی بر روی تقریباً تمامی مرورگرها و بر روی سیستم عاملهای مختلفتست محلی یا local testing که امکان تست برنامه وب برروی سرورهای داخلی یا localhost را میدهد. این امکان کلیدی باعث میشود نرم افزار قبل از انتشار بروی سروی عمومی بر روی سرورهای تست و مهمتر از آن روی کامپیوتر خود فرد تست شود. به طور مثال میتوانید بعد از تغییری کوچک در کد جاوا اسکریپ وب و قبل از commit کردن، آن را روی localhost و بر روی نخسه های مختلف Chrome نصب شده بر نسخه های مختلف اندروید تست کنید.پشتیبانی از تست اتوماتیک: در این حالت سرورهای BrowserStack به عنوان Selenium Server عمل کرده و کد تست نوشته شده بر روی کامپیوتر شما را بروی محیطهای دلخواه شما اجرا میکنند.پشتیبانی از راه حلهای Continues Integration که این امکان را میدهد که تست های نوشته شده به طور اتوماتیک بعد از ارسال تغییرات در کد منبع اصلی (Main Repo) اجرا و بازخورد آن هرچه سریعتر به تیم داده شود.امکان Online Collaboration و به اشتراک گذاری تست های انجان شده با سایر همکاران.ضبط و آرشیو ویدئویی تست های اجرا شده جهت عیب یابی هایهرچند این راه حل برای برنامه نویسان و تست کنندهایی که سالهاست با مشکل تست بر روی محیطهای مختلف دست و پنجه نرم میکنند، به نوعی Dream comes true محسوب میشود ولی هزینه بالا یعنی 99 دلار در ماه به ازای هر نفر باعث میشود مدیران در انتخاب آن تردید زیادی داشته باشند.برای امتحان کردن این سرویس میتوانید یک حساب رایگان باز کنید و بخصوص سری به قسمت Automate و کدهای نمونه Selenium آن بزنید. بهروز بهروز Sun, 24 Nov 2019 18:36:06 +0330 https://virgool.io/@baf/%D8%A8%D8%A7%D8%B2%DB%8C-%D8%A8%D8%A7-%DA%A9%D9%84%D9%85%D8%A7%D8%AA-%D9%86%DA%AF%D8%A7%D9%87%DB%8C-%D8%A8%D9%87-%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D8%AA%D8%B3%D8%AA-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-icvahlapupvm تاریخ انتشار نسخه اصلی 26 دسامبر, 2016همین اول پست بگم که شخصاً میانه ای با استفاده از اصطلاحات و تعاریفی که میخواهم راجع به آنها بنویسم ندارم. هرچند نامگذاری بر روی روشهای مختلف تست نرم افزار، برای مستند سازی و استفاده از آن در ارتباطات ضروریست ولی تمرکز و بکاربردن مدام آنها در ارتباط  با افرادی که دانستن یا ندانستن این اصطلاحات تاثیری در کار روزمره شان ندارد، امری غیرضروری و حتی گمراه کننده است. مثلا اینکه به یک برنامه نویس بگویید که من میخواهم برنامه تو را به صورت gray-box تست سیستمی کنم یا به یک مدیر نرم افزار بگویید exploratory test  فلان قسمت برنامه با موفقیت انجام شد، در واقع اطلاعاتی اضافی ایست که کمکی به او نمیکند. ولی در هر صورت دانستن این تعاریف برای کسی که تست نرم افزار انجام میدهد مفید بوده و مانند زمینه های دیگر، به فرد دید بازتری نسبت به کارههای روزانه اش میدهد. در ادامه به تعدادی از این تعاریف و اصطلاحات -البته براساس تجربه شخصی و نه نوشته های ویکیپدیایی – اشاره میکنم.برای شناخت بهتر تستهای نرم افزاری میتوان آنها را به گروه هایی دسته بندی کرد. به طوری که  موارد ذکر شده در هر گروه میتواند  برخلاف همگروهی خود، با گروه دیگر همپوشانی داشته باشند.انواع تست از لحاظ دسترسی به کد نرم افزار:تست White-box: زمانی است که تست کننده دسترسی به کد نرم افزار دارد.تست Black-box: زمانی که تست کننده دسترسی به کد نرم افزار نداشته و معماری آن برایش اهمیتی نداشته باشد. در واقع میزان دسترسی او همانند یک کاربر معمولی از طریق interface  های کاربری است.تست Gray-box: این مورد برای خود من بییشتر پیش میآید، زمانی است که تست کننده دسترسی به کد ندارد اما از طریق  interface  غیرکاربری (مانند interface مخصوص debug و عیب یابی) سیستم را تست میکند. مثلا اگر برنامه ای براساس REST API است با دانستن route ها میتوان از طریق افزونه هایی در Chrome مانند Postman آن را تست کرد.انواع تست از لحاظ سطح انتزاع معماری سیستم:روش Unit Testing یا تست واحد که ناظر بر تست یک واحد نرم افزاری مانند یک  متد یا یک کلاس است.روش Integration Testing یا تست یکپارچگی که به معنای تست ارتباط میان واحدهای نرم افزاری از طریق رابط نرمافزاری یا Interface است.روش System Testing که بعد از آن معلوم میشود که آیا Function  مورد نظر که در ابتدای از تیم نرم افزاری درخواست شده بود  به صورت end to end کار میکند یا خیر.این تست ها در درون تیم نرم افزاری شامل برنامه نویس و تست کننده فنی نوشته و انجام میشود و بازخوردهای آن نیز در درون تیم تحلیل میشود. در این مراحل نه مشتری و نه مدیر نرم افزار هیچکدام نقشی ندارند.تست هایی که میتوان آنها را در ارتباط با مشتری و چرخه انتشار نرم افزار تعریف کرد:روش Acceptance Testing: این تست بررسی میکند که آیا Feature درخواستی از سمت مشتری مطابق با نیازمندی اوست یا خیر. این تست توسط خود مشتری یا فردی در ارتباط با او انجام میشود. توجه داشته باشید که در System Test الزاماً feature تست نمیشود بلکه function بررسی میشود. چیزی که ممکن است الزاماً در ارتباط مستقیم با مشتری نباشد. در واقع این دو با هم تفاوت ماهوی دارند و در یک گروه قرار نمیگیرند.روش Smoke Testing: تستی است سطحی که قبل از انتشار یک نسخه یا patch انجام میشود. البته این به معنای نبودن test case یا فی البداهه بودن نیست. در واقع تیم تست از قبل تست هایی را برای اطمینان از عدم پیشامد مشکلاتی مانند crash کردن یا کار نکردن سناریوهای ابتدایی آماده کرده است و آنها را قبل از انتشار نرم افزار یا patch به صورت اتوماتیک یا دستی انجام میدهد.روش Exploratory Testing:  این روش زمانی مطرح میشود که تیم نرم افزاری فرصتی برای نوشتن test plan، در آوردن سناریوها و یا اتوماتیک کردن ندارد و میخواهد افراد شرکت انفرادی یا دو به دو بنشینند و هر کدام برروی قسمتی از نرم افزار کار کنند. به این صورت که به انتخاب خود سناریوهایی که فکر میکنند کاربر آنها را انجام میدهد، انجام داده و یافته های خود را مستند کنند. این روش به صورت کاملا دستی انجام میشود. البته نیازی نیست این تست الزاماً قبل از انتشار نرم افزار انجام شود. در بعضی از شرکت ها این روش در غالب Mob testing به منظور آشنایی بیشتر کارکنان با نرم افزار و پیدا کردن bug های احتمالی انجام میشود.دسته بندی از لحاظ یکپارچی و پایداری سیستم:روش Regression Testing: خود این واژه به معنای بازگشت به حالت قبلی است. در تست این حالت قبلی وضعیتی است که نرم افزار به درستی عمل میکرده و وضعیت پایداری داشته است. در واقع زمانی که bug ی در سیستم رفع میشود، تست کننده باید اطمینان حاصل کند که نرم افزار به وضعیت پایدار قبل از بروز bug برگشته است یا خیر.روش Non-regression Testing: تستی است که بعد از اضافه شدن feature ی جدید برای اطمینان از اینکه عملکرد موفق آن انجام میشود. در واقع برخلاف regression سیستم دیگر نباید در وضعیت قبلی باشد.و در نهایت تقسیم بندی در رابطه با نیازمندیهای عملکردی و غیر عملکردی سیستم مانند تست امنیت، تست کاربری، تست استرس، تست تطبیقی با استاندارد یا پروتکلی خاص و غیره.همانطور که گفته شد یک تست میتواند ترکیبی از گروهای بالا باشد. مثلا یک تست امنیتی که به صورت دستی و در سطح سیستم به صورت gray-box انجام میگیرد. یا اینکه یک تست Acceptance همیشه در سطح سیستم و به صورت black-box انجام میشود. بهروز بهروز Sat, 16 Nov 2019 13:53:40 +0330 https://virgool.io/@baf/gherkin-cucumber-asweus3o23aj تاریخ انتشار نسخه اصلی 19 دسامبر, 2016در پست قبلی در مورد روش BDD در توسعه نرم افزار و علت به وجود آمدنش نوشتم. اینکه این روش دنبال کننده روش TDD است و به زبانی برای مستند سازی مجهز است که افراد مرتبط به یک پروژه نرم افزاری شامل مشتری، مدیر نرم افزار، برنامه نویس و تست کننده میتوانند به وسیله آن با یکدیگرارتباط داشته باشند. زبانی که  میبایست  از یک سو اصطلاحات یک حوزه کسب و کار بتوان در آن استفاده کرد و هم آنقدر ساده و منطقی باشد که بتوان آن را براحتی تبدیل به کد برنامه نویسی کرد. در این پست به معرفی Gherkin و SpecFlow به عنوان ابزارهای لازم برای پیاده سازی این روش در dotNet میپدازیم. اولین گروهی که به طور گسترده به پیاده سازی روش BDD و مستندسازی آن همت کردند، تیمی از برنامه نویسان Ruby بودند. آنها ابتدا Cucumber (خیار) و Gherkin (خیار ریز) را  به ترتیب عنوان framework و زبان ارتباطی فراگیر(ubiquitous language) معرفی و سپس مشابه Cubumber را برای زبانهای دیگر پیاده سازی کردند:این framework ها امکان آن را میدهند که سناریوهای تست که به زبان Gherkin نوشته و در فایلهایی بنام feature ذخیره شده اند را به صورت binding با کد تست یا step definition که میتواند به زبانهای مختلف باشد، پیوند زد و به وسیله Test Runner ها اجرا کرد.در Gherkin برای نوشتن سناریوهای تست، کلید واژهایی است که در ابتدای هر جمله میایند و سپس آن جمله را میتوان به یک function در کد تست bind کرد. علاوه بر این، پارامترهای تست را نیز میتوان از طریق این جملات به کد تست منتقل کرد. در زیر نمونه یک feature فایل شامل دو سناریو  برای امکان login را مشاهده میکنید:Feature: LogIn_Feature In order to access my account As a user of the website I want to log into the website Scenario: Successful Login with Valid Credentials Given User is at the Home Page And Navigate to LogIn Page When User enter and And Click on the LogIn button Then Successful LogIN message should display Examples: | username | password | | testuser_1 | Test@123 | | testuser_2 | Test@153 | Scenario: Successful LogOut When User LogOut from the Application Then Successful LogOut message should displayدر SpecFlow که پیاده سازی Cucumber برای dotNet است، این feature فایل را میتوان به صورت اتوماتیک به فایل step definition تبدیل کرد و سپس در هر کدام از function های تولید شده، کد تست که در اینجا Selenium است را اضافه کرد.namespace SpecFlowDemo.Steps { [Binding] public class LogIn_Steps { public IWebDriver driver; [Given(@&quotUser is at the Home Page&quot)] public void GivenUserIsAtTheHomePage() { driver = new FirefoxDriver(); driver.Url = &quothttp://www.store.demoqa.com&quot } [Given(@&quotNavigate to LogIn Page&quot)] public void GivenNavigateToLogInPage() { driver.FindElement(By.XPath(&quot.//*[@id='account']/a&quot)).Click(); } [When(@&quotUser enter (.*) and (.*)&quot)] public void WhenUserEnterAnd(string username, string password) { driver.FindElement(By.Id(&quotlog&quot)).SendKeys(username); driver.FindElement(By.Id(&quotpwd&quot)).SendKeys(password); } [When(@&quotClick on the LogIn button&quot)] public void WhenClickOnTheLogInButton() { driver.FindElement(By.Id(&quotlogin&quot)).Click(); } [When(@&quotUser LogOut from the Application&quot)] public void WhenUserLogOutFromTheApplication() { ScenarioContext.Current.Pending(); } [Then(@&quotSuccessful LogIN message should display&quot)] public void ThenSuccessfulLogINMessageShouldDisplay() { //This Checks that if the LogOut button is displayed true.Equals(driver.FindElement(By.XPath(&quot.//*[@id='account_logout']/a&quot)).Displayed); } [Then(@&quotSuccessful LogOut message should display&quot)] public void ThenSuccessfulLogOutMessageShouldDisplay() { ScenarioContext.Current.Pending(); } } }همانطور که مشاهده میکنید feature  فایل که به زبان Gherkin نوشته شده است میتواند محلی باشد برای بحث، تصمیم گیری و مستند سازی نیازمندیهای مشتری. فایلی  که میتواند مورد استفاده برنامه نویس و تست کننده هم قرار گیرد و به این صورت از دوباره کاری جلوگیری شود. امروزه استفاده از BDD در شیوه های Agile رو به گسترش است و این را میتوان از گسترش Cucumber برای زبانهای مختلف، قوی تر شدن فروم های آن و نیاز به آن در آگهی های شغلی متوجه شد. بهروز بهروز Thu, 14 Nov 2019 12:07:22 +0330 https://virgool.io/@baf/bdd-uiwawquilxyy تاریخ انتشار نسخه اصلی 6 دسامبر, 2016وقتی در دوره کارشناسی در مورد روشهای مختلف توسعه نرم افزار مثل DSDM , SSADM و RUP  میخواندیم، یکی از سوالایم همیشه این بود که افراد مختلف در یک شرکت که نقشهای مختلف را برعهده دارند چطوری با همدیگر ارتباط برقرار میکنند؟ آدمهای فنی و غیرفنی که دیدگاه و دایره لغات یکسانی ندارند چطور دچار سوء تفاهم نمیشوند؟ در واقع در روشهای بالا فازهای مختلف پروژه آنقدر از یکدیگر جدا و فاصله دار بودند که بنظر نمیرسید حتی زبانهای مدلینگ مثل UML هم کمک زیادی به ارتباط بهتر بکنند. زمانیکه شروع بکار کردم این قضیه بیشتر برایم روشن شد. احتمالا این تصویر معروف را همه دیده اید. درست است که خیلی تکراری شده و حقیقت دارد.وقتی در سوئد مشغول بکار شدم و روش Agile را از نزدیک دیدم. احساس کردم که این مشکل ارتباطی تا اندازه ای بهبود پیدا کرده است. علت آن هم کوچک شدن تیم ها، کوتاه شدن چرخه بازخورد (feedback loop) و سرعت بیشتر در تولید محصول است که باعث میشود فرکانس و تناوب ارتباط تیم برنامه نویسی با تست کننده، مدیر نرم افزار بیشتر شده و در نتیجه به زبان مشترک نزدیکتر شوند. اما مسئله ارتباط هنوز هم سر جای خود است و هر چند سال یکبار هم شیوه ای جدید برای بهبود آن معرفی میشود. در میان این شیوه ها آنهایی موفق هستند که ماندگاری بیشتری دارند. شرکتهای زیادی آنها را پیاده سازی میکنند. ابزارهای زیادی ایده و مدلشان را پیاده سازی میکنند و در کل Community قوی حول آنها شکل میگیرد. یکی از این روشها  Behavioral Driven Development  یا توسعه مبتنی بر رفتار است. BDD که در غالب Agile اجرا میشود را میتوان در ادامه TDD و تحت تاثیر DDD دانست. پس بهتر است قبل از رفتن به جزئیات، با این دو روش مفهوم آشنا شویم:روش Test Driven Development یا توسعه مبتنی بر تست مفهومی است که در سال 2003 مطرح شد و بر اساس آن ابتدا تست یک واحد نرم افزاری مانند یک متد قبل از خود آن نوشته میشود. کد نویسی در یک چرخه تا زمانی ادامه پیدا میکند که تست آن با موفقیت انجام (اصطلاحاً pass) شود. Unit Test هایی که امروز در اکثر پروژهای نرم افزاری نوشته میشود در واقع این مفهوم را پیاده سازی میکنند. JUnit در جاوا، NUnit در dotNet و unittest در Python نمونه های از این پیاده سازی هستند.روش Domain Driven Design یا طراحی مبتنی بر دامنه کسب و کار، مفهومی است که در سال 2004 مطرح شد که یکی از هدف های آن معرفی زبانی فراگیر (ubiquitous language) در یک زمینه تخصصی کسب و کار است تا نقشهای مختلف حاضر در چرخه تولید نرم افزار مانند برنامه نویس، تست کننده، مدیر نرم افزار و کاربر بتوانند بهتر و موثرتر با هم ارتباط برقرار کنند. واژه های استفاده شده در مستندها صریح و خالی از ابهام است و همگی بر سر مفهوم آنها توافق دارند. این واژه ها بر خلاف زبان رایج در میان برنامه نویسان تکنیکی نیستند بلکه مختص به یک حوزه کسب و کار است. مثلا شرکتی که در زمینه نرم افزارهای بورس یا مدیریت منابع انسانی فعالیت میکند واژگان خاصی استفاده میکند که با حوزه های دیگر متفاوت است. در واقع این روش از تیم تینیکی شرکت میخواهد که زبان تخصصی کسب و کار را یاد گرفته و در مستند سازی و ارتباطات روزانه  از آن استفاده کند.روش BDD که در سال 2006 معرفی شد هدف اش آن است که روش TDD را ادامه دهد ولی برخلاف زبان تکنیکی آن که در نوشتن unit test استفاده میشود زبانی فراگیر را معرفی کند که تمامی افراد سهیم در پروژه (stakeholders)  بتوانند از طریق آن با هم ارتباط برقرار و مستند سازی کنند. امروز برای این روش چهارچوبهای نرم افزاری در زبانهای مختلف برنامه نویسی وجود دارد.  Cucumber در  Ruby و SpecFlow در dotNet نمونه هایی از آن هستند. در پست بعدی در مورد جزئیات این روش بیشتر مینویسم و مثالهایی از SpecFlow میاورم. بهروز بهروز Tue, 12 Nov 2019 12:05:47 +0330 https://virgool.io/@baf/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%D8%A7%D9%86-%D8%AE%D9%88%D8%B4%D8%AD%D8%A7%D9%84-ba88kboyldby این نوشته میتوانست عنوانی مثل «چرا برنامه نویس باید کد خود را تست کند؟» داشته باشد.  به این خاطر که به شیوه با بهتر بگویم آسیبی در برنامه نویسی اشاره میکند که شاید در بسیاری از شرکتهای نرم افزاری پیشرفته سالهاست که دیگر دیده نمیشود. 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 در نظر گرفته شده است:برنامه نویس کد خود را تست کند.برنامه نویسی در همان تیم کد را تست کند.برنامه توسط تیم تست شرکت بررسی شود.برنامه برای تست به جایی غیر از شرکت فرستاده شود.این چهار درجه از جدایی برنامه نویسی و تست که انجام آن از بالا به پایین پرهزینه تر میشود بر این اصل بنا شده است که تست کننده هر چه بیشتر از برنامه نویس فاصله داشته باشد، برنامه را با ذهنی مستقل تر و نقادانه تر تست میکند. در اینجا باز هم مدیران نرم افزار هستند که باید با توجه به بودجه، تواناییهای داخلی، حساسیت نرم افزار و بازار مصرف برای استفاده از ترکیبی از موارد بالا تصمیم گیری کنند. بهروز بهروز Mon, 11 Nov 2019 11:43:08 +0330 https://virgool.io/@baf/mobtesting-sijizgqc0rxe تاریخ انتشار نسخه اصلی نوامبر 20, 2016نمیدانم شما هم مثل من تنها و با هدفونی در گوش کار میکنید یا اینکه دوست دارید با همکارتان با هم کد بزنید، ولی در هر صورت با گسترش و محبوب شدن شیوه های Agile در شرکتهای نرم افزاری، تیم ها هر چه بیشتر به سمت کار گروهی متمایل میشوند. Pair programming یکی از همین روشهای رایج با هم کار کردن است که شاید نیاز چندانی به توضیح نداشته باشد. دو برنامه نویس با هم پشت یک کامپیوتر مینشینند، فکرها را روی هم میگذارند و سعی میکنند باهم مسئله ای را حل کنند. ولی چند سالی است مفهوم جدیدی در Agile مطرح شده است بنام Mob programming و در ادامه آن Mob testing. برای فهم بهتر این دو بنظرم لازم است ابتدا دو مفهوم دیگه توضیح داده شود:Session on "User interfaces to statistical software" - Marguerite Ennis, Alan Myrvold, John Nash, Mary Walker-Smith.روش Strong-style pairing: این روش اولین بار سال 2014 توسط Lewellyn Falco مطرح شد. Lewellyn که برنامه نویس و مربی Agile است با مشاهده Pair programming مشکلاتی در آن دید. مثل اینکه کسی که مشاهده گر است نمیداند کنترل کننده به چه چیزی فکر میکند یا فردی که با تجربه تر است مدام کنترل دست اش هست و فرد کم تجربه تقریباً از بازی بیرون. یا اینکه برعکس بعضی وقتها سر کنترل کیبورد مشاجره پیش میاد. Lewellyn این مشکل ارتباطی را به این شکل حل کرد:هر فکری که از ذهن یک نفر بیرون میاد باید از طریق فردی دیگری به کامپیوتر منتقل شوددر این روش یک نفر اصطلاحاً نقشه خوان (navigator) میشود و به راننده (driver) که پشت کامپیوتر نشسته، میگوید که چکار کند. این کار تا مدت زمانی مشخص (حدود 15 دقیقه) ادامه دارد تا اینکه جاها عوض شود. با اینکار هر دو نفر به یک مقدار در برنامه نویسی شریک میشوند، فرد کم تجربه فرصت آموختن به صورت عملی پیدا میکند و فرد با تجربه نیز فرصتی دارد تا کار را با دید متفاوت نگاه کند.روش Mob: خود من اولین بار این واژه را در عنوان ویدئوهایی دیدم که در آنها افرادی با هم در یک مکان عمومی یک دفعه شروع میکنند به رقصیدن یا انجام دادن کارهای جالب دیگر. بقیه مردم هم میایستند و لذت میبرند. این واژه هم در دنیای نرم افزار به همین معنی است:افرادی در یک زمان و مکان مشخص، یک کار مشخص را با همدیگر از طریق یک کامپیوتر انجام دهند.در Mob programming، اعضای یک تیم برنامه نویسی (و در صورت وجود، tester با توانایی کد نویسی) در یک اتاق مینشینند و از طریق Strong-style pairing بر روی یک مسئله کار میکنند. به این صورت که driver پشت کامپیوتر نشسته و دستورات در بدون دخالت اجرا میکند. نفر دیگر در نقش نقشه خوان دستورات را میدهد و سایر اعضای تیم نظاره گر هستند، تا آنکه بعد از مدتی مشخص جاها عوض شود. قبل از عوض شدن جاها، در صورت لزوم افراد در مورد دستورات و کارهای انجام شده باهم گفتگو میکنند. تجربه شخصی من از مشاهده و انجام این شیوه با برنامه نویسان این است که 1) افراد تازه وارد به گروه فرصتی پیدا میکنند که هم با خلق و خو و نظرات بقیه آشنا شوند و هم کار را سریعتر یاد بگیرند. 2)علاوه بر آن این شیوه در ابتدای حل یک مسئله بسیار کمک میکند. بعد از آنکه راه حل پیدا شد. افراد با تقسیم کار، به طور جداگانه و با سرعت بیشتر پروژه را پیش خواهند برد.و اما Mob testing. با توضحات بالا تعریف این شیوه هم تفریباً مشخص است. اعضای یک تیم با همدیگر و به شیوه Strong-style pairing قسمتی از نرم افزار را تست کنند. ولی چند نکته در اینجا مهم است:نوع تست. بنظر من این شیوه برای انجام Exploratory testing مفید است. در مورد این شیوه در آینده بیشتر توضیح میدهم ولی خلاصه آن این است که تست به صورت دستی و black box روی قسمتی از نرم افزار به منظور شبیه سازی رفتار کاربر نهایی انجام میشود. بر خلاف تست های معمول که برنامه ریزی آن به صورت مفصل انجام و مستند میشود، در اینجا برنامه ریزی سریع و تمرکز بر روی اجرای تست و یادداشت بازخوردهاست. البته که mob testing میتواند به منظور نوشتن کد test (مثلا Selenium) و نوشتن unit تست هم باشد ولی من به شخصه به اینها عنوان mob programming میدهم.لازم نیست افرادی که در جلسه تست شرکت میکنند اعضای یک گروه باشند. تست Exploratory به شیوه mob این امکان را میدهد که افراد از سایر تیمها و حتی سایر بخشها در آن شرکت کنند تا بیشتر با نرم افزار آشنا شوند.مدت زمان جلسات نباید از حدود یک ساعت بیشتر شود.بهتر است جلسه در اتاق جدا (برای عدم ایجاد مزاحت برای سایر افراد) و با مانیتوری بزرگ انجام شد.مهم است که مشکلات پیدا شده در جریان تست یادداشت شوند. برای همین بهتر است یک tester در جلسه شرکت داشته باشد تا بتواند موارد پیدا شده را جمع آوری کند و بعد از جلسه، در صورتی که این موارد از قبل در سیستم Bug tracking ثبت نشده باشد، با مشورت مدیر نرمافزار آنها را اضافه کند.این شیوه هم مثل سایر شیوه ها مدت زمانی لازم دارد که در تیمهای نرم افزاری جا بیافتد و البته جا افتاده آن وابسته به میزان فشار کار و روحیه افراد دارد. از نظر بعضی مدیران این شیوه میتواند اتلاف وقت تلقی شود اما مسلما برای حل مسائل پیچیده و شکل گیری کار گروهی میان اعضا بسیار مفید است. بهروز بهروز Sat, 09 Nov 2019 17:36:40 +0330 https://virgool.io/@baf/automationyesorno-fybtnnmqe8mh تاریخ انتشار نسخه اصلی نوامبر 13, 2016همانطور که در پست مربوط به Web Automation نوشتم، خوب است که در مورد خود اتوماسیون تست هم صحبت بشود. اینکه چه زمانی تست را باید اتوماتیک کرد و چه زمانی به صورت دستی انجام داد؟ مزایا و معایب آن را با رسم شکل توضیح دهید؟ ?راستش این سوال خیلی کلی است و اگر جواب کلی بخواهید به آن بدهید، در واقع همه چیز برمیگردد به ویژگیهای آشکار شیوه اتوماتیک در برابر شیوه دستی انجام دادن کارها. این کار میتواند خط تولید یک خودرو باشد یا فرایند تولید نرم افزار. یک اتوماسیون کارآمد، کارها ساده را سریعتر، دقیقتر و درنهایت با هزینه کمتر انجام میدهد. در مقابل کار دستی برای فرایندهایی که نیاز به ویژگیهای انسانی مثل خلاقیت، دید بازتر و چند جانبه دارد مناسبتر است. در مورد تست نرم افزار هم این اصل کلی حکم فرماست ولی سختی کار زمانیست که مدیر نرم افزار یا مدیر فنی باید با توجه به عوامل مختلف دربکارگیری این دو روش انتخاب بهینه را انجام دهد. با توجه به مشاهداتم در محیط کار این عوامل را میتوانم به صورت زیر دسته بندی کنم:نوع تست از لحاظ نزدیکی به تجربه کاربر:تست میتواند در سطوح Unit و Integration یا سیستم و تست Acceptance باشد. نزدیکی به تجربه کاربر در این سطوح از تست به همین ترتیب افزایش میابد. اگر فرض را بر این بگیریم که کاربر نهایی نرم افزار انسان است،  شبیه سازی نحوه استفاده او از سیستم کار مشکلب است. در واقع در سطوح بالای تست بر خلاف سطوح پایین که تمرکزش بروی Function ها و کلاسها و interface هاست، دغدغه بر روی شبیه سازی همین تجربه کاربر با در نظر گرفتن پیچیدگی های رفتاری او است. پیچیدگی که با دریافت بازخورد مداوم از مشتری مدام در حال بروزشدن است. در این سطح،  طراحی و اجرای تست اتوماتیک دشوار و احتمالا ناکارآمد است. در حالی که در سطوح پایین اتوماتیک کردن تست شدنی و ناگزیر است.هزینه تست: آیا برای پیاده سازی تست اتوماتیک نیاز به خرید framework یا ابزاری گران است یا نوع رایگان آن موجود است؟ آیا برای نوشتن یا راه اندازی تست شرکت نیازمند آوردن متخصص ای پرهزینه است یا اینکه یکی از نیروی های حاضر با صرف مدتی میتواند مسئولیت آن را برعهده گیرد؟ برآوردی از میزان ارتقای کیفیت نرم افزار و بالارفتن رضایت مشتری وجود دارد که این هزینه ها را توجیه کند؟میزان چالاکی تولید: صحبت در مورد اتوماسیون در تست از زمانی زیاد بگوش میرسد که R&D اقدام به بکارگیری متدهای چابک یا Agile در تولید نرم افزار میکند. در روشهای چابک (که در پستی جداگانه در مورد آن خواهم نوشت)،  تست بر اساس بازخوردهای سریع و مداوم است. سرعت و مداومت هر دو نیازهایی است که از طریق اتوماسیون میتوان به آنها رسید. نیاز به اتوماسیون در شرکتی که هنوز به سمت روشهای چابک نرفته است کمتر احساس میشود.علاوه بر نقش عوامل بالا در تصمیم گیری، باید اضافه کرد که طراحی و پیاده سازی اتوماسیون تست فرایندی ادامه دار است. کد نوشته شده  باید با تغییرات سیستم یا بازخوردهای مشتری مدام بروز رسانی شود تا هم از گزارشات false positive جلوگیری شود و هم اطمینان کاذب از کیفیت ایجاد نشود. بسیار دیده شده که کدهای تست بعد از مدتی صرفاً برای زیبایی و اینکه گفته شود که کاری در مورد اتوماسیون انجام شده است همچنان اجرا میشوند درحالی که هیچ بازخوردی به برنامه نویس نمیدهند. متاسفانه برخی از تیمهای نرم افزاری با اتوماسیون به عنوان یک کالای لوکس و دهان پر کن برخورد میکنند. مهندسین QA یا برنامه نوسان برای آنکه مهارت خود را در کدنویسی نشان دهند، اقدام به اتوماتیک کردن تستهایی میکنند که از اساس باید به صورت دستی و توسط یک کاربر معمولی انجام شوند.برای من اتوماسیون تست به ذات امری ضروری نیست. هدف تست بالا بردن کیفیت نرم افزار از طریق بازخوردهای دقیق و سریع است. اتوماسیون تنها وسیله است برای رسیدن به این هدف. بهروز بهروز Fri, 08 Nov 2019 16:00:49 +0330 https://virgool.io/@baf/headless-p48tp0lax46j تاریخ انتشار نسخه اصلی نوامبر 5, 2016در پست قبل راجع به ابزارهای اتوماسیون تست برای برنامه های تحت وب نوشتم و اشاره کردم که webdriver از درایورهای مخصوص برای مرورگرهای متفاوت استفاده میکند. حالا دراین پست میخواهم درباره مرورگرهای headless و نقش آنها در Web automation توضیح بدهم. تفاوت مرورگر headless با سایر مرورگرها تنها نداشتن رابط کاربری گرافیکی یا GUI است که استفاده از آن توسط کاربر غیرحرفه ای را غیرممکن میکند. اما تمامی کارهای یک مرورگر گرافیکی مثل render کردن HTML به DOM (مهمترین اصل برای اتوماسیون وب) و تفسیر کدهای JavaScript را انجام میدهد. علاوه بر اتوماسیون وب این مرورگرها استفاده های دیگری مثل تست کارایی شبکه  یا حمله های DDoS دارند که همگی درواقع برپایه تکرار ارسال درخواست http و render پاسخ هاست.اما وقتی راجع به اتوماسیون تست وب صحبت میکنیم، این مرورگرها چه کمکی میکنند؟ مهمترین و شاید تنها مزیت آنها سرعتشان است. در این مورد مقایسه ای میان درایور PhanjomJS (یعنی GhostDriver) و درایورهای Firefox و Chrome انجام شده که نشان میدهد با اجرای تستی مشابه برروی سخت افزار واحد سرعتها به این صورت است:Firefoxdriver: 5.3sChromedriver: 2.9.sGhostdriver: 0.5sسرعت اجرا در تست زمانی اهمیت پیدا میکند که Continuous Integration برای release ها و بازخوردهای سریع تنظیم شده باشد که در آینده درباره اش بیشتر مینویسم. خب، با وجود چنین مزیتی پس چرا سهم این مرورگرها در اتوماسیون مانند سایر درایورها زیاد نیست. مهمترین علل را میشود به این صورت دسته بندی کرد:نوشتن تست: برای نوشتن تست نیاز است که برنامه نویس متناوباً از Inspect element یا ابزارهای دیگر برای شناسایی DOM در مرورگرها استفاده کند و headless ها فاقد آن هستند. این موضوع زمانی اهمیت بیشتری پیدا میکند که کسی که تست را مینویسد، برنامه نویس کد برنامه نباشد.تفسیر کدهای JavaScript: امروزه با پراستفاده شدن JavaScript در برنامه نویسی وب مثل استفاده از Bootstrap، مهم است که driver مورد استفاده در اتوماسیون از چه مفسر (interpreter) استفاده میکند و اگر مفسر مرورگر با آنچه در مرورگرهای مشهور استفاده میشود متفاوت باشد، ممکن است کد تست در زمان اجرا دچار خطا شود.ویژگیهای خاص مرورگر: اگر تست شامل استفاده از مثلا افزونه های مختص به یک مرورگر محبوب یا ویژگی منحصربفرد دیگری باشد، باز هم استفاده از مرورگر headless را که توسط کاربر عادی استفاده نمیشود، محدود میکندنگهداری و عیب یابی تست: تست را یک بار مینوسند و باید سالها از آن نگهداری کرد. در صورتی که تست به هرعلت دچار خطا شود، روند عیب یابی بدون رابط گرافیکی برای برنامه نویس بسیار دشوار خواهد بود.تمامی موارد بالا میتواند بکارگیری مرورگرهای headless را که توسط کاربر غیر حرفه ای استفاده نمیشود را محدود میکند.  در بسیاری از سناریو ها ما میخواهیم که تجربه واقعی استفاده از برنامه تحت وب نوشته شده را در تست شبیه سازی کنیم. نگاهی به بازار نشان میدهد که Chrome، FireFox و بیشترین سهم را دارند. در نتیجه کسانی که به دنبال شبیه سازی تجربه کاربر هستند به chromedriver یا  Firefoxdriver روی میاورند. ولی به هر صورت همیشه هم این نگاه در تست وجود ندارد.در دنیای مرورگرها، headless های فراوانی وجود دارند که تنوع آنها بیشتر به دو نکته باز میگردد: 1) زبان برنامه نویسی مورد حمایت و 2) تکنولوژی rendering  کد HTML و تفسیر JavaScript. در اینجا دو مرورگر را به اختصار توضیح میدهمدرمورد HtmlUnit میشه گفت اولین مرورگر headless است. با جاوا نوشته شده و عمدتاً در کد جاوا استفاده میشود. درایور آن  یعنی HtmlUnitdriver توسط webdriver مورد استفاده قرار میگیرد. مشکل اصلی اش محدودیت آن در تفسیرکدهای جاواست.فانتوم PhantomJS هم مرورگری است که با ++ C نوشته شود. تقریباً از تمامی زبانهای پرکاربرد استفاده پشتیبانی میکند و برخلاف HtmlUnit میانه خوبی هم با JavaScript دارد. درایور آن  توسط webdriver مورد استفاده قرار میگیرد. از آنجایی که بر اساس WebKit نوشته شده برای اتوماسیون Safari و پلاترمهای Apple مناسب تر است.من شخصا از آنجایی که  تا بحال نزدیکی به تجربه کاربر نهایی سیستم و نگهداری و عیب یابی تست برایم اهمیت داشته و خوشبختانه سرعت اجرای تست در محیط کارم مشکل ساز نشده است، سعی کردم از chromedriver و IEdriver استفاده کنم ولی اگر روزی لازم شد حتماً از PhantomJS استفاده میکنم ? در این ویدئو میتوانید با نحوه استفاده از آن در Python آشنا شوید. بهروز بهروز Thu, 07 Nov 2019 17:54:57 +0330 https://virgool.io/coderlife/webauthomation-evrtp7wharly تاریخ انتشار نسخه اصلی اکتبر 30, 2016وقتی تصمیم به نوشتن این پست گرفتم، اول فکر کردم که خب باید ابتدا در مورد نقش اتوماسیون در QA بنویسم، بعد از آن Test Automation برای برنامه تحت وب را بدون اشاره به جزییات فنی تعریف کنم و تازه بعد از آن بروم سراغ مقایسه ابزارها و Framework های موجود در این زمینه (که مثل خانواده خوشحال تو عکس هستند).  اما بعدش فکر کردم که مخاطب این وبلاگ که احتمالا یک برنامه نویس یا QA هست، حوصله خواندن تعاریف و بحثهای روش شناسی را نداشته باشد. پس بگذارید اول بروم سراغ مسائل کاربری و بعد از آن اتوماسیون در تست و صحبتهای کلی تر. امروزه بسیاری از شرکتهای نرم افزاری که راه کاره مبتنی بر Desktop دارند، به دلایل واضحی مثل هزینه کمتر توسعه و نگهداری، به سمت وب حرکت میکنند. در نتیجه نیاز به اتوماسیون تست برای این پلتفرم هم بیش از پیش احساس میشود. بطوریکه تعدادی از شرکتها بزرگ عنوانهای شغلی مثل Web Test Automation یا حتی Selenium Test Engineer دارند.اصلی که در تمامی ابزارهای اتوماسیون تست به صورت Black box مشترک است 1) خودکارسازی سناریوهایی (مثل ثبت نام، اضافه کردن به سبد خرید) است که قرار است کاربردر هنگام استفاده از نرم افزار انجام میدهد و 2) Assertion هایی که تعیین میکند که آیا تست با موفقیت انجام شده است یا خیر. مثلا آیا بعد از ثبت نام اسم کاربری در منو دیده میشود یا خیر.  در مورد وب، هر دو بخش احتیاج به locator هایی دارند که DOM object ها (مثل یک لینک) را در صفحات HTML شناسایی کنند و بروی آنها عملی مانند کلیک یا خواندن مقدار آن انجام دهند. در مقایسه میان ابزارهای اتوماسیون وب هم اصل بر توانایی آنها در تشخیص این object ها در مرورگرهای مختلف، سرعت انجام سناریوهای تست و binding هایی است که برنامه نویس بتواند در زبان مورد نظر از آن استفاده کند.در بین ابزارهای تست  Selenium webdriver امروزه به نوعی ابزار استاندار شده یا de facto بحساب میاید. ولی Selenium از ابتدا به این شکل نبوده است. Selenium 1.0 برای اجرای تستها نوشته شده در test client (برنامه ای که کدهای تست با استفاده از Selenium API در ان نوشته شده) بر روی مرورگر از برنامه ای مبتنی بر JavaScript بنام Selenium Core استفاده میکرد. در واقع Selenium Server ابتدا Core را به مرورگر تزریق و سپس دستورات نوشته در client را به آن منتقل میکند.مزیت این روش این بوده که Core قابل استفاده در تمام مرورگرهای رایج آن زمان یعنی FireFox، IE , Safari بوده است ولی مشکل آن تفاوت دستورات برای هرکدام از مرورگرها بود که ارتباط با object ها را مشکل میکرد. بطوری که برنامه نویس نمیدانست مثلا برای تایپ در یک text field در یک مرورگر از کدام تابع استفاده کند. علاوه بر این 0.Selenium 1 از مرورگرهای headless هم پشتیبانی نمیکرد (در مورد این مرورگرها در پستهای بعدی خواهم نوشت). اما با آمدن webdriver در Selenium این مشکلات تا اندازه زیادی حل شد: 1) Core حذف شد و هر مرورگری درایور مجزایی دارد که بجز IE و FireFox، باقی آنها توسط شرکتهای تولید کننده یا طرف سوم (3rd party) نوشته میشوند که مشهورترین آنها chromdriver، Selenroid و Edge webdriver هستند. Selenium نیز از طریق پروتکل JsonWire  با این درایورهای در ارتباط است. این کار پیچیدگی استفاده از توابع مختلف در Selenium API را برای برنامه نویسان برداشت. بطور مثال ()click بروی تمام مرورگرها ثابت است. 2) اگر مرورگر و test client هر دو روی یک ماشین باشند، Selenium Server قالب حذف است (در مورد نقش Selenium Server بیشتر خواهم نوشت) و دستورات مستقیماً برروی مرورگر انجام میشود. این کار اجرای تست را سریعتر میکند. 3) مرورگرهای headless هم پشتیبانی میشوند. جدایی از موارد بالا، webdriver  یک مشکل نسبتاً مهم دارد و آن سرعت پایین آن در اتوماسیون IE است که البته تلاشی چندانی هم در بهبود آن انجام نشده است. شاید به علت آنکه سهم IE به شدت در حال کاهش است و Edge هم در آینده جای آن را میگیرد.میران استفاده در ماه سپتامبر 2016اما در سالهایی که IE فراگیر بود این کند بودن مشکل مهمی محسوب میشد. یکی از ابزارهای اتوماسیون وب اما این مشکل را نداشت. Watir  ابزاریست که توسط توسعه دهندگان Ruby تولید شده و مورد استفاده قرار میگیرد. تفاوت آن با Selenium در استفاده از پروتکل OLE ساخت مایکروسافت برای ارتباط با IE و در واقع علت سریعتر بودن آن هم در اتوماسیون به همین پروتکل برمیگردد. برنامه نویسان مایکروسافتی هم از نسخه طراحی شده آن برای dotNET یعنی WatiN استفاده میکرند که از طریق Nugget قابل اضافه شده به پروژه بود. البته بعدها با فراگیر شدن دیگر مرورگرها مانند Chrome و برنامه های موبایلی، توسعه دهندگان Watir از webdriver هم در بسته خود استفاده کردند. یکی از مشکلات Watir این است که برای اجرای تست ها به صورت از راه دور یا grid راه حلی ساده یا اصطلاحاً out of box وجود ندارد اما دلیل اصلی عدم رقبت برنامه نویسان  به استفاده از Watir جامعه کوچک توسعه دهندگان (Ruby کارها)  و کاربران آن است که یافتن پاسخ برای سوالات رایج کاربران در اینترنت را بسیار سخت میکند. نبود پشتیبانی قوی باعث شد که بعد از 2009 نسخه دیگری از  WatiN بیرون داده نشود. در نتیجه برنامه نویسان dotNET  به Coypu  روی آوردند. این که Coypu چیست میتواند موضوع پست دیگری باشد ?از زمانی که webdriver حرف اول را در اتوماسیون تستهای برنامه تحت وب میزند، wrapper های بسیاری برایش نوشته شده است که استفاده از آن را در زبانهای برنامه نویسی مختلف ساده تر و آن را کاراتر کرده است. Protractor، Selenide و Coypu نمونه های از آنها هستند که هرکدام سعی در بهبود اتوماسیون در تکنولوژی های مختلف مثل Ajax یا AngularJS داشته اند. در آینده در مورد آنها بیشتر مینویسم. بهروز بهروز Wed, 06 Nov 2019 20:01:33 +0330 https://virgool.io/@baf/quality-assurance-b6cvyqkw5gh6 در سوئد عنوان مهندس تست نرم افزار یا Quality Assurance (تضمین کیفیت) نزدیک به دو دهه است که در شرکتهای نرم افزاری با اندازه کوچک و متوسط (حد اکثر 250 نفر پرسنل) مطرح شده است که علت آن میتواند گسترش کسب و کارهای خلاق و دانش بنیان از یک طرف و از طرفی دیگر رقابت این کسب و کارها در جذب مشتری در فضای بازار آزاد باشد. فضای رقابتی که در آن شرکتها وادار میشوند کیفیت محصول نرم افزار خود را هم  بخاطر بهبود تجربه مشتری (Customer Experience) و هم کاهش حجم کاری بخش خدمات پس از فروش و نتیجه کاهش هزینه ها، در سطح قابل قبولی نگه دارند. البته این توجه به کیفیت تنها محدود به استخدام مهندس تست نمیشود بلکه در کل منجر به بازبینی در فرایند های تولید نرم افزار و بالا بردن آگاهی و حساسیت  بخش تحقیق و توسعه (R&D)  میشود.در ابتدای این روند بهبود کیفیت، Quality Assurance عمداً محدود به انجام تستهای functional به صورت دستی میشد که بر اساس معیارهایی پذیرشی بود که مدیر نرم افزار قبل از کد نویسی در سر داشته یا مستند کرده است. در نتیجه کسی که این تستها را انجام میداد باید فردی باشد که میتوانست به اندازه یک کاربر حرفه ای از نرم افزار استفاده کند و البته کمی هم با محیط تست یعنی سیستم عامل و سخت افزار آشنایی داشته باشد. برای همین در آگهی های استخدام نوشته میشد تحصیلات مرتبط با کامپیوتر یک امتیاز است و نه الزام. این باعث میشد که تست کننده ها مانند غریبه های در R&D دیده شوند. چون هم توانایی فنی ارتباط با برنامه نویسها را نداشتند و هم مدت زمان نسبتاً زیادی طول میکشید که محدودیتها و معماری سیستم را یاد بگیرند و در نتیجه  گزارش باگهای اشتباه ندهد. علاوه براین تست کننده بخاطر عدم تسلط به اسکریپت نویسی نمیتوانست در صورت نیاز در فرایند خودکارسازی در مرحله تست سیستم (System Test) به صورت جعبه سیاه (Black box)، مشارکت کند و در نتیجه در صورت اصرار مدیر نرم افزار، خود برنامه نویس مجبور به یادگیری ابزار یا API تستی میشد که علاقه ای به آن نداشت و هم در مواردی این خودکارسازی را برای بخشی از نرم افزار انجام میداد که خود آن را نوشته بود. این مورد آخر که در آینده بیشتر در مورد آن مینویسم در بسیاری از اوقات محدود به تستهای happy path میماند و کیفیتی کاذب را نتیجه میدهد.این مشکلات در مجموع باعث میشود که برنامه نویسان بازخورد سریع و دقیقی از کیفیت کد خود نداشته باشند. در نتیجه رفته رفته مدیران فنی (CTO) به این فکر افتادند که تست کننده هایی استخدام کنند که هم تحصیلات مرتبط با علوم کامپیوتر داشته باشند و هم تا حد قابل قبولی توانایی درک کد نرم افزار شرکت و هم اسکریپت نویسی برای خودکارسازی تست را داشته باشند. ورود من به دنیای تست نرم افزار (سال 2012) مصادف با همین روند تغییر در شرکت های کوچک و متوسط بود. زمانی که هم از یک سو بخاطر پیش زمینه فکری برنامه نویس ها از مهندسین تست قبلی، باید توانایی فنی خود را  در R&D  ثابت میکردم و هم اینکه در نبود افراد با تجربه در زمینه استفاده از ابزارهای تست و خودکارسازی باید به تنهایی روش و ابزار مناسب را پیدا کرده و آن را یاد میگرفتم.  در پست بعدی در مورد یکی از این چالشها مینویسم. بهروز بهروز Tue, 05 Nov 2019 00:56:56 +0330