همیشه به خاطر می آورم , زمانی که برنامه نویس بودم و یا به عنوان رهبر تیم توسعه نرم افزار فعالیت می کردم با مقوله تست برنامه مشکل داشتیم . نرم افزار که توسعه می دادیم یا اصلا تست نمی شد و یا اگر هم می شد به صورت دستی توسط خود برنامه نویس ها یا یک سری افراد متفرقه مانند اسپانسر پروژه تست می گردید که چندان روش با اعتباری نبود. معمولا برنامه ای که پر از باگ باشد مستعد از دست دادن مشتری هست و از دست دادن مشتری مصادف با عصبانیت مدیران شرکت خواهد شد . برنامه نویس ها معمولا علت باگ های زیاد برنامه را فقدان نقش Tester در تیم توسعه اعلام می کنند و فکر می کنند اگر کسی با عنوان Tester به تیم توسعه اضافه شود , تمام مشکلات حل خواهد شد و البته آنها متعقد هستند که تست برنامه به هیچ وجه وظیفه برنامه نویس نیست .
بنده به دو دلیل با تئوری بالا مخالف هستم و عقیده دارم باز هم اگر Tester به تیم توسعه اضافه گردد دوباره برنامه ها پر از باگ خواهند بود : 1- Tester خوب در ایران وجود ندارد و یا خیلی کم است 2- Tester نمی تواند تمام آزمایش های لازم را انجام بدهد و آزمایشات کامل زمانی می تواند اتفاق بیفتید که برنامه نویس هم تست نماید .
البته بنده لزوم بودن Tester را در تیم های توسعه نرم افزار نفی نمی کنم بلکه اعتقاد دارم زمانی باید Tester به تیم توسعه ملحق شود که فرهنگ مناسبی نسبت به تست در تیم توسعه و سازمان نهادینه شده باشد .
تمام مطالبی که در بالا ذکر شد پیش گفتاری برای بحث اصلی مقاله می باشد که نرم افزار و یا محصول در محیط چابک چگونه تست می شود و چه نقش هایی برای این منظور نیاز است .
به طور کلی Agile دید مثبت و خوبی نسبت به تست دارد و کلا این مقوله در ارزش ها و اصول بیانیه توسعه چابک پیش بینی شده است . اصل 9 بیانیه توسعه چابک اشاره غیر مستقیمی به لزوم تست دارد .TDD روشی می باشد که در متدهای Agile به عنوان روش تست معرفی شده است .
همانطور که در مقالات قبلی در مورد TDD عرض شد در این روش اول تست ها نوشته می شوند و بعدا براساس تست های نوشته شده , کدها تولید می شوند . شاید بپرسید که فرق ندارد که تست در اول نوشته شود و یا در آخر , بالاخره هدف ایجاد تست برای نرم افزار می باشد و حتی شاید در ایجاد تست در آخر راحتتر و بهتر عمل کنیم ؟
مزیت اصلی نوشتن تست در اول و قبل از کد نویسی این می باشد که ما به اندازه و تمیز کد خواهیم نوشت . فقط هدف از کدنویسی پاس کردن تست ها می باشد و به عبارت دیگر می توان گفت که برادر ما می خواهیم رفع تکلیف کنیم با پاس کردن این تست ها , کمتر کد بنویس با ضواید کم که فقط این تست ها پاس شود . مزیت دیگر نوشتن تست قبل از کدنویسی ایجاد یک الگو و هدف برای کدنویسی می باشد . یعنی ما دقیقا می دانیم که فقط هدف ما نوشتن این تکه کد برای پاس کردن این تست با این مضمون می باشد و این دوباره باعث Refactoring خواهد شد .ولی اگر تست در آخر نوشته شود کمی تست ها متفاوت خواهند شد : زیرا ما برای کدهایی که ایجاد شده تست می نویسیم و در واقع کدهای نوشته شده فرمانده و الگوی تست نویسی خواهند شد در حالی که شاید کد نوشته شده درست نیست , یعنی انتظار مشتری بر آورده نشده است و پس تست این قسمت که دقیقا معلوم نیست انتظار مشتری را بر آورده می کند یا نه چه فایده ای می تواند داشته باشد ؟
پاراگراف بالایی که به صورت مختصر بیان گردید در چندین پست قبلی در مورد TDD که نوشته شده بود به صورت کامل شرح داده شده بود و هدف یادآوری مختصری در مورد لزوم TDD بود . هدف اصلی این نوشته تببین و ایجاد الگوی عملی در محیط های Agile جهت تست محصول می باشد . ولی قبل از پرداخت به الگوی تست لازم است یک مرتبه بالاتر رفته و به هدف Agile برسیم .
هدف Agile ارائه ارزش های مورد نیاز تجارت , کسب و کار مشتری طی یک محصول نرم افزاری می باشد . بحث از ارزش گردید , یعنی هدف ما ارائه و فقط ارائه ارزش ها مورد انتظار مشتری می باشد . ارزش مشتری همان User Story هایی می باشد که آن ها را در اول و یا طی پروژه جمع آوری می نماییم . مثلا : ” کاربران سیستم باید در هنگام ثبت نام از رمز عبور امن (Secure) استفاده نمایند” : این می تواند یک ارزش یا User Story برای مشتری باشد ; ولی در تعریف Agile گفتیم که : ” هدف ما ارائه و فقط ارائه ارزش ها مورد انتظار مشتری می باشد ” . ما ارزش را به صورت یک User Story بیان کردیم ولی انتظار مشتری را از این ارزش بیان نکردیم . به عبارت ساده تر این ارزش چه ویژگی هایی باید داشته باشد تا نیاز مشتری برآورده شود؟
برای وضوح بیشتر به این مثال توجه نمایید : فرض کنید ما یک مشتری داریم که او می خواهد یک کارخانه اتومبیل سازی راه بیندازد و ما هم راه انداز کارخانه هستیم . در فاز تحلیل و یا در راه اندازی کارخانه در می یابیم که برای کارخانه نیاز به لیفت تراک می باشد . این یک ارزش برای کارخانه می تواند باشد . اما مشتری اذعان دارد که این لیفت تراک باید بتواند در یک نقطه 360 درجه بچرخد و باید بتواند بارهای بالای 20 تن را بردارد . این ها هم ویژگی های این ارزش می توانند می باشند . زمان تحویل لیفت تراک ما باید تست بکنیم ببینیم که آیا این لیفت تراک می تواند این باید ها را پاس کند ؟ به این حالت اصطلاحا Acceptance Test می گویند .
پیاده سازی یک ارزش در محیط چابک می تواند به صورت زیر می باشد :
- ارزش یا User Story شناسایی می شود و مستند می شود.
- ویژگی های ارزش شناسایی و مستند سازی می شود.
- هر کدام از ویژگی های یک ارزش به صورت تست هایی پیاده سازی می شوند.
- ارزش بر اساس الگوی تست موجود کد نویسی می شود .
همانطور که مستحضر می باشید گام های بالا همان گام های TDD می باشند ولی این گام های وظیفه چه کسی می باشد ؟
- گام اول – ارزش یا User Story شناسایی می شود و مستند می شود : وظیفه کل تیم توسعه می باشد .
- گام دوم – ویژگی های ارزش شناسایی و مستند سازی می شود : وظیفه Tester های تیم و توسعه دهندگان می باشد .
- گام سوم و چهارم- وظیفه برنامه نویسان عزیز می باشد .
داشتن تست برای هر ویژگی بسیار سودمند و با ارزش می باشد که در محیط چابک اگر تست نباشد کار تقریبا امکان پذیر نخواهد بود . یکی از ارزشها و شعارهای اصلی توسعه چابک “قبول و پذیرایی از تغییرات” است . بنده به صراحت عرض می کنم که اگر تست نداشته باشید این شعار قابل انجام نخواهد بود . بدلیل اینکه هر تغییر ویرانی هایی را بدنبال خواهد داشت . اگر تا به حال برنامه نوشته باشید و محصول توسعه داده باشید باید به خاطر بیاورید که در هر تغییر (جزئی و یا کلی) قسمت هایی از برنامه درست و قسمت هایی از برنامه ویران شده است . اگر تست داشته باشیم , در هر تغییر می توانیم بعد از اعمال تغییرات تمام تست ها را اجرا نماییم , اگر کدی در یک جایی ویران شده باشد , تست آن قسمت پاس نخواهد شد و قرمز رنگ خواهد شد , پس می توان به راحتی از ویران کردن دیگر بخش ها مطلع شد و تصحیحات لازم را به موقع و قبل از ارائه آن به مشتری انجام داد .
چابک شوید , TDD کار کنید , تغییرات را با آغوش باز پذیرا باشید و چابک بمانید .
یاشیاسیز
نرم افزار http://www.axosoft.com رو می خواستم پیشنهاد بدم به دوستان که خیلی جامع و کامل هستش. البته اگه دوستان هم ابزاری معرفی کنند که چه بهتر.
سلام
در خصوص تست باید عرض کنم من خودم یک تستر بودم ولی متاسفانه در ایران به این موقعیت توجه چندانی نمیشود و یک تستر یک توسری خور است .سوالی که مطرح میشود و نیازی که من با آن در طول فرایند عملیاتی کردن یک نرم افزار بزرگ مواجه بودم لزوم داشتن یک متدولوژی یا توسه جهت برخورد با مشکلات عملیاتی کردن نرم افزار است با وجود تمام توصیه ها باز هم شما در انتقال نرم افزار به سایت مشتری خصو صا در نرم افزار های فرایند محور با مشکلات زیادی مواجه هستید که باعث بروز مشکلاتی میشود.
1-نرم افزار پر از باگ است و درست کار نمیکند و شما باید تحویل دهید
2-کاربران نسبت به فرایندهای جدید مقاومت میکنند
3-ارتباط تیم عملیاتی سازی با تیم توسعه معمولا خوب نخواهد بود
حال می خواستم ببینم آیا یک متدلوژی یا روش جهت غملیاتی سازی نرم افزار که توصیه های فکری عملی و رفتاری مناسب در برخورد با چالشهای بحث عملیاتی سازی وجود دارد یا نه
متدلوژی خاصی فقط برای چالش های عملیاتی سازی وجود ندارد ولی Agile می تواند تمام چالش ها را در تمام مراحل مدیریت نماید .
مطالب وبلاگتون خیلی عالی بود جند تا سوال داشتم ازتون 1- آیا TDD شیوه تست در اسکرامه یا نه TDD یک شیوه تسته که در اسکرام هم استفاده می شه ؟
2- آیا در اسکرام روش های خاصی برای تست وجود داره
خیلی دوست دارم در مورد تست خودکار هم اگه مطالبی بدارین من با test compelete کار کردم ام دوست دارم در مورد ابزارهای دیگه هم بدونم
ممنون میشم ار لطفتون
TDD روش اسکرام نیست، ولی توصیه می شود که برای بالا بردن کیفیت و تغییر پذیری استفاده بشود. اسکرام روش خاصی رو پیشنهاد نکرده است. چشم حتما در اولین فرصت مطالب بیشتری در مورد تست خواهم نوشت
سلام من نیاز به مطالبی در مورد روش تست- محصولات تولید شده و کنترل پیشرفت پروژه با scrum , xp دارم. ممنون میشم اگه کمکم کنید. فوری….
سلام
تستر خوب هم در ایران هست.
https://www.mohandespishegan.com/