چرخه توسعه نرم افزار (SDLC) چیست؟ بررسی مراحل و مدل‌های SDLC

توسعه یک نرم‌افزار موفق فقط به نوشتن کد و ساخت یک محصول قابل اجرا محدود نمی‌شود. پیش از آنکه یک نرم‌افزار به دست کاربر برسد، فعالیت‌هایی مانند برنامه‌ریزی، تحلیل نیازمندی‌ها، طراحی، توسعه، تست، استقرار و نگهداری انجام می‌شوند. اگر این فعالیت‌ها بدون یک فرآیند مشخص و هماهنگ انجام شوند، احتمال بروز مشکلاتی مانند ابهام در نیازمندی‌ها، افزایش هزینه، تأخیر در تحویل و کاهش کیفیت نرم‌افزار بیشتر خواهد شد.

برای مدیریت این فرآیند، از مفهومی به نام چرخه توسعه نرم افزار (Software Development Life Cycle یا SDLC) استفاده می‌شود. SDLC مجموعه‌ای از مراحل و فعالیت‌هاست که تیم برای تبدیل یک ایده یا نیاز کسب‌وکار به یک نرم‌افزار قابل استفاده و سپس نگهداری و بهبود آن طی می‌کند.

یکی از بخش‌های مهم چرخه توسعه نرم افزار، تست نرم افزار (Software Testing) است. با این حال، تست نباید صرفاً فعالیتی در پایان فرآیند توسعه در نظر گرفته شود. در رویکردهای مدرن، فعالیت‌های مرتبط با کیفیت و تست می‌توانند از مراحل اولیه مانند تحلیل نیازمندی‌ها آغاز شوند و در مراحل مختلف چرخه توسعه ادامه پیدا کنند.

در این مقاله ابتدا با مفهوم SDLC و مراحل چرخه توسعه نرم افزار آشنا می‌شویم، سپس مدل‌های مختلف SDLC مانند Waterfall، V-Model و Agile را بررسی می‌کنیم و در طول مقاله خواهیم دید که تست نرم افزار و نقش تستر در هر مرحله از این چرخه چیست.

SDLC چیست؟ | چرخه توسعه نرم افزار چیست؟

SDLC مخفف Software Development Life Cycle و به معنی چرخه توسعه نرم افزار است. SDLC به یک چارچوب یا فرآیند ساختاریافته برای توسعه، تحویل و نگهداری نرم افزار گفته می‌شود که مجموعه‌ای از مراحل مشخص را برای تبدیل یک نیاز یا ایده به یک نرم افزار قابل استفاده تعریف می‌کند.

به زبان ساده، چرخه توسعه نرم افزار مشخص می‌کند یک نرم افزار از زمانی که ایده یا نیاز اولیه آن شکل می‌گیرد تا زمان توسعه، تست، انتشار و نگهداری، چه مراحلی را طی می‌کند.

این چرخه معمولاً شامل فعالیت‌هایی مانند برنامه‌ریزی، تحلیل نیازمندی‌ها، طراحی، توسعه، تست، استقرار و نگهداری است. البته تعداد مراحل، نام آن‌ها و نحوه اجرای آن‌ها می‌تواند بر اساس مدل توسعه و شرایط پروژه متفاوت باشد.

برای مثال، فرض کنید یک شرکت قصد دارد یک فروشگاه اینترنتی ایجاد کند. قبل از اینکه کدنویسی آغاز شود، باید مشخص شود کاربران چه امکاناتی نیاز دارند، سیستم چگونه طراحی خواهد شد و چه منابعی برای توسعه آن لازم است. پس از پیاده‌سازی نیز نرم افزار باید تست شود، در محیط واقعی مستقر شود و در ادامه برای رفع مشکلات و اضافه کردن قابلیت‌های جدید نگهداری و به‌روزرسانی شود. مجموعه این فعالیت‌ها بخشی از چرخه توسعه نرم افزار (SDLC) را تشکیل می‌دهند.

آیا SDLC فقط برای برنامه نویسی است؟

خیر. یکی از تصورات اشتباه درباره SDLC این است که چرخه توسعه نرم افزار فقط به مرحله کدنویسی (Coding) مربوط می‌شود.

در واقع، کدنویسی تنها یکی از مراحل این چرخه است. پیش از آن، فعالیت‌هایی مانند برنامه‌ریزی، تحلیل نیازمندی‌ها و طراحی انجام می‌شوند و پس از توسعه نیز فعالیت‌هایی مانند تست، استقرار و نگهداری ادامه پیدا می‌کنند.

به همین دلیل، SDLC یک دید کلی نسبت به فرآیند تولید و تکامل نرم افزار ارائه می‌دهد و فقط به فعالیت‌های تیم توسعه محدود نمی‌شود.

آیا SDLC همیشه یکسان است؟

خیر. چرخه توسعه نرم افزار یک فرآیند کاملاً ثابت و یکسان برای همه پروژه‌ها نیست.

مدل‌های مختلف توسعه نرم افزار، مانند Waterfall، V-Model، Iterative و Agile، مراحل SDLC را به شکل‌های متفاوتی اجرا می‌کنند. برای مثال، در Waterfall مراحل معمولاً به شکل متوالی دنبال می‌شوند، در حالی که در Agile بسیاری از فعالیت‌های توسعه و تست به صورت تکرارشونده و مستمر انجام می‌شوند.

بنابراین بهتر است SDLC را به عنوان یک چارچوب کلی برای سازمان‌دهی فرآیند توسعه نرم افزار در نظر بگیریم، نه یک دستورالعمل ثابت که تمام تیم‌ها باید دقیقاً به یک شکل اجرا کنند.

ارتباط SDLC با تست نرم افزار

تست نرم افزار یکی از فعالیت‌های مهم در چرخه توسعه است و نقش آن فقط پیدا کردن باگ (Bug) پس از پایان کدنویسی نیست. تستر می‌تواند از مراحل اولیه مانند تحلیل نیازمندی‌ها در فرآیند توسعه مشارکت داشته باشد و با بررسی نیازمندی‌ها، شناسایی ابهام‌ها و توجه به ریسک‌های کیفیت، به پیشگیری از مشکلات کمک کند.

به همین دلیل، در ادامه مقاله علاوه بر بررسی مراحل مختلف چرخه توسعه نرم افزار، نقش تست و تستر را نیز در هر مرحله بررسی خواهیم کرد.

چرا چرخه توسعه نرم افزار اهمیت دارد؟

توسعه نرم افزار یک فرآیند پیچیده است و معمولاً افراد و تیم‌های مختلفی در آن مشارکت دارند. اگر این فرآیند بدون برنامه‌ریزی و ساختار مشخص انجام شود، احتمال بروز مشکلاتی مانند ابهام در نیازمندی‌ها، دوباره‌کاری، افزایش هزینه، تأخیر در تحویل و کاهش کیفیت محصول بیشتر می‌شود.

چرخه توسعه نرم افزار (SDLC) با ایجاد یک چارچوب مشخص، کمک می‌کند فعالیت‌های مربوط به توسعه نرم افزار به شکل منظم‌تر انجام شوند. در هر مرحله، هدف، فعالیت‌ها و خروجی‌های مشخصی وجود دارد و اعضای تیم می‌توانند درک بهتری از وظایف و مسئولیت‌های خود داشته باشند.

مهم‌ترین مزایای SDLC

کاهش ریسک پروژه:
بررسی نیازمندی‌ها، طراحی، ریسک‌های فنی و سایر عوامل در مراحل مختلف کمک می‌کند مشکلات احتمالی زودتر شناسایی شوند.

کنترل بهتر زمان و هزینه:
وقتی مراحل و فعالیت‌های پروژه از ابتدا مشخص باشند، برنامه‌ریزی منابع، زمان و هزینه ساده‌تر خواهد بود.

افزایش کیفیت نرم افزار:
SDLC کمک می‌کند کیفیت محصول در طول فرآیند توسعه مورد توجه قرار گیرد و فعالیت‌هایی مانند بررسی نیازمندی‌ها و تست نرم افزار در زمان مناسب انجام شوند.

کاهش دوباره‌کاری:
شناسایی زودهنگام ابهام‌ها و مشکلات می‌تواند از انتقال آن‌ها به مراحل بعدی و ایجاد هزینه بیشتر برای اصلاح جلوگیری کند.

بهبود همکاری تیمی:
تیم‌های مختلف مانند محصول، کسب‌وکار، توسعه و تست می‌توانند بر اساس یک فرآیند مشخص با یکدیگر همکاری کنند.

اهمیت SDLC از دید تست نرم افزار

از دید یک تستر (Tester)، یکی از مهم‌ترین مزایای SDLC این است که کیفیت نرم افزار می‌تواند از همان مراحل اولیه مورد توجه قرار گیرد.

برای مثال، اگر یک نیازمندی (Requirement) مبهم یا ناقص باشد، تستر می‌تواند آن را پیش از شروع توسعه شناسایی و برای رفع ابهام مطرح کند. این کار معمولاً بسیار ساده‌تر از زمانی است که همان ابهام پس از پیاده‌سازی نرم افزار و در مرحله تست مشخص شود.

بنابراین، نقش تستر در SDLC فقط اجرای مورد تست (Test Case) و پیدا کردن باگ نیست. تستر می‌تواند در مراحل مختلف چرخه توسعه، با شناسایی ریسک‌ها و مشکلات کیفیت، به پیشگیری از نقص‌ها (Defect) و بهبود کیفیت محصول کمک کند.

در بخش بعدی، مراحل مختلف چرخه توسعه نرم افزار (SDLC) را بررسی می‌کنیم و می‌بینیم در هر مرحله چه فعالیت‌هایی انجام می‌شود و تست نرم افزار چه نقشی دارد.

مراحل چرخه توسعه نرم افزار چیست؟

چرخه توسعه نرم افزار از مجموعه‌ای از مراحل تشکیل می‌شود که تیم برای تبدیل یک ایده یا نیاز اولیه به یک نرم افزار قابل استفاده و سپس نگهداری و بهبود آن طی می‌کند.

اگرچه مراحل SDLC ممکن است بر اساس مدل توسعه، نوع پروژه و روش کار تیم با یکدیگر تفاوت داشته باشند، یک ساختار رایج برای چرخه توسعه نرم افزار شامل مراحل زیر است:

1. برنامه‌ریزی (Planning)
2. تحلیل نیازمندی‌ها (Requirement Analysis)
3. طراحی (Design)
4. توسعه (Development)
5. تست (Testing)
6. استقرار (Deployment)
7. نگهداری (Maintenance)

به صورت ساده می‌توان این چرخه را به شکل زیر در نظر گرفت:

Planning → Requirements → Design → Development → Testing → Deployment → Maintenance

البته این ترتیب نباید به این معنا باشد که تمام پروژه‌های نرم افزاری دقیقاً همین مراحل را به صورت خطی و یک‌بار طی می‌کنند. در برخی مدل‌های توسعه، مانند Agile و Iterative، این فعالیت‌ها بارها در چرخه‌های کوتاه تکرار می‌شوند.

برای مثال، ممکن است یک تیم ابتدا مجموعه‌ای از نیازمندی‌ها را تحلیل کند، بخشی از نرم افزار را طراحی و توسعه دهد، آن بخش را تست و منتشر کند و سپس در تکرار بعدی (Iteration) قابلیت‌های جدیدی به محصول اضافه کند.

نمای کلی مراحل SDLC

مرحله	هدف اصلی
Planning	مشخص کردن هدف، محدوده (Scope)، منابع، زمان و ریسک‌های پروژه
Requirement Analysis	شناسایی و تحلیل نیازهای کاربران و کسب‌وکار
Design	مشخص کردن ساختار و نحوه عملکرد سیستم
Development	پیاده‌سازی نرم افزار و تبدیل طراحی به کد
Testing	بررسی نرم افزار و شناسایی نقص‌ها و مشکلات
Deployment	استقرار و در دسترس قرار دادن نرم افزار برای کاربران
Maintenance	رفع مشکلات، بهبود سیستم و اضافه کردن تغییرات و قابلیت‌های جدید

نقش تست در مراحل مختلف SDLC

یکی از نکات مهم درباره چرخه توسعه نرم افزار این است که تست نرم افزار الزاماً به مرحله Testing محدود نمی‌شود.

برای مثال، تستر می‌تواند در مرحله تحلیل نیازمندی‌ها، قابل تست بودن نیازمندی‌ها را بررسی کند؛ در مرحله طراحی درباره قابلیت تست (Testability) سیستم بازخورد بدهد؛ در زمان توسعه برای آماده‌سازی موارد تست و داده‌های تست فعالیت کند و پس از پیاده‌سازی، تست‌ها را اجرا و نقص‌ها را گزارش کند.

بنابراین، مرحله‌ای که در SDLC با عنوان Testing شناخته می‌شود اهمیت زیادی دارد، اما فعالیت‌های مرتبط با کیفیت و تست می‌توانند در بخش‌های مختلف چرخه توسعه حضور داشته باشند.

در ادامه، هر یک از مراحل چرخه توسعه نرم افزار را به صورت جداگانه بررسی می‌کنیم و علاوه بر فعالیت‌های اصلی هر مرحله، نقش تست نرم افزار و تستر را نیز در آن مرحله توضیح خواهیم داد.

مرحله اول SDLC: برنامه‌ریزی (Planning)

Planning یا مرحله برنامه‌ریزی معمولاً نقطه شروع چرخه توسعه نرم افزار است. در این مرحله مشخص می‌شود که قرار است چه محصولی ساخته شود، چرا به آن نیاز است و برای توسعه آن چه منابع و امکاناتی مورد نیاز خواهد بود.

هدف از برنامه‌ریزی این نیست که تمام جزئیات نرم افزار از همان ابتدا مشخص شوند؛ بلکه تیم باید بتواند یک تصویر اولیه از هدف، محدوده (Scope)، منابع، زمان، هزینه و ریسک‌های پروژه به دست آورد و درباره امکان‌پذیری اجرای آن تصمیم‌گیری کند.

در مرحله Planning چه فعالیت‌هایی انجام می‌شود؟

بسته به نوع پروژه و روش توسعه، فعالیت‌های این مرحله می‌تواند متفاوت باشد، اما معمولاً موارد زیر مورد توجه قرار می‌گیرند:

• مشخص کردن هدف و چشم‌انداز محصول
• شناسایی نیاز اولیه کسب‌وکار یا کاربران
• تعیین محدوده اولیه پروژه
• تخمین زمان و هزینه
• شناسایی منابع مورد نیاز
• بررسی امکان‌پذیری پروژه (Feasibility)
• شناسایی ریسک‌های اولیه
• تعیین اعضای تیم و مسئولیت‌های کلی
• انتخاب رویکرد یا مدل مناسب برای توسعه

برای مثال، فرض کنید یک شرکت قصد دارد یک فروشگاه اینترنتی ایجاد کند. در مرحله Planning ممکن است مشخص شود که هدف پروژه ایجاد بستری برای فروش آنلاین محصولات است، چه منابعی برای اجرای پروژه در اختیار تیم قرار دارد، چه زمانی برای عرضه نسخه اولیه در نظر گرفته شده و چه ریسک‌هایی ممکن است اجرای پروژه را تحت تأثیر قرار دهند.

نقش تستر در مرحله Planning چیست؟

ممکن است تصور شود که تستر فقط زمانی وارد پروژه می‌شود که نرم افزار آماده تست باشد؛ اما در یک فرآیند توسعه مناسب، ملاحظات مربوط به کیفیت می‌توانند از همان مرحله Planning مورد توجه قرار بگیرند.

تستر یا اعضای تیم QA می‌توانند با توجه به نوع محصول و ریسک‌های پروژه، مواردی مانند موارد زیر را بررسی کنند:

• ریسک‌های مرتبط با کیفیت محصول
• نیازهای اولیه برای تست
• پیچیدگی و قابلیت تست سیستم
• محیط‌ها و ابزارهای مورد نیاز برای تست
• محدودیت‌های احتمالی در داده‌های تست
• نیاز به تست خودکار (Automation Testing)
• الزامات خاص مانند تست کارایی (Performance Testing) یا تست امنیت (Security Testing)

برای مثال، اگر قرار است نرم افزاری برای تعداد زیادی کاربر همزمان طراحی شود، تست کارایی (Performance Testing) می‌تواند از همان مراحل اولیه به عنوان یک نیاز مهم در نظر گرفته شود و به مراحل پایانی پروژه موکول نشود.

خروجی مرحله Planning چیست؟

خروجی دقیق این مرحله به روش مدیریت و مدل توسعه پروژه بستگی دارد، اما معمولاً شامل اطلاعاتی درباره هدف پروژه، محدوده اولیه، منابع، زمان‌بندی، هزینه، ریسک‌ها و امکان‌پذیری پروژه است.

این اطلاعات در مراحل بعدی SDLC مبنایی برای تصمیم‌گیری‌های دقیق‌تر قرار می‌گیرند.

نکته: Planning در تمام پروژه‌ها لزوماً یک مرحله طولانی و جداگانه نیست. در مدل‌هایی مانند Agile، برنامه‌ریزی می‌تواند به صورت مستمر و در سطح‌های مختلف انجام شود و با تغییر نیازمندی‌ها یا شرایط پروژه به‌روزرسانی شود.

پس از مشخص شدن جهت کلی پروژه، مرحله بعدی تحلیل نیازمندی‌ها (Requirement Analysis) است؛ جایی که نیازهای کاربران و کسب‌وکار با جزئیات بیشتری بررسی و مشخص می‌شوند.

مرحله دوم SDLC: تحلیل نیازمندی‌ها (Requirement Analysis)

پس از مشخص شدن هدف و مسیر کلی پروژه، تیم وارد مرحله تحلیل نیازمندی‌ها (Requirement Analysis) می‌شود. در این مرحله مشخص می‌شود که نرم افزار دقیقاً چه مسئله‌ای را باید حل کند و چه قابلیت‌ها و ویژگی‌هایی باید داشته باشد.

نیازمندی (Requirement) بیان‌کننده چیزی است که نرم افزار باید ارائه دهد یا شرایطی است که سیستم باید برآورده کند. این نیازمندی‌ها می‌توانند از کاربران، مشتریان، صاحبان کسب‌وکار، قوانین و مقررات یا سایر ذی‌نفعان پروژه به دست بیایند.

هدف Requirement Analysis فقط جمع‌آوری فهرستی از قابلیت‌ها نیست؛ بلکه نیازمندی‌ها باید بررسی، تحلیل و تا حد امکان به شکلی شفاف، دقیق، قابل فهم و قابل تست تعریف شوند.

در مرحله Requirement Analysis چه فعالیت‌هایی انجام می‌شود؟

بسته به پروژه و روش توسعه، فعالیت‌های این مرحله می‌تواند متفاوت باشد، اما معمولاً موارد زیر انجام می‌شوند:

• شناسایی نیازهای کاربران و کسب‌وکار
• جمع‌آوری و مستندسازی نیازمندی‌ها
• تحلیل و اولویت‌بندی نیازمندی‌ها
• شناسایی وابستگی‌ها و محدودیت‌ها
• بررسی ابهام‌ها و تناقض‌های موجود
• مشخص کردن شرایط و قوانین کسب‌وکار
• تعریف معیارهای پذیرش (Acceptance Criteria) در صورت نیاز
• بررسی امکان پیاده‌سازی نیازمندی‌ها
• بررسی قابل تست بودن نیازمندی‌ها

برای مثال، فرض کنید نیازمندی یک فروشگاه اینترنتی این باشد:

«کاربر باید بتواند محصول مورد نظر خود را به سبد خرید اضافه کند.»

این نیازمندی در نگاه اول ساده است، اما هنوز جزئیات زیادی مشخص نشده است. مثلاً:

• اگر محصول موجود نباشد چه اتفاقی باید بیفتد؟
• آیا کاربر مهمان هم می‌تواند محصول را به سبد خرید اضافه کند؟
• حداکثر تعداد مجاز از یک محصول چقدر است؟
• اگر کاربر چند بار روی دکمه افزودن کلیک کند چه اتفاقی باید بیفتد؟
• آیا قیمت محصول باید همان لحظه به سبد خرید منتقل شود؟

بررسی این موارد در مرحله Requirement Analysis می‌تواند از ایجاد ابهام و اختلاف برداشت در مراحل بعدی جلوگیری کند.

نقش تستر در Requirement Analysis

تستر یکی از اعضایی است که می‌تواند در بررسی نیازمندی‌ها نقش مهمی داشته باشد. تستر نباید صرفاً منتظر بماند تا نیازمندی به کد تبدیل شود و سپس به دنبال باگ بگردد.

یکی از مهم‌ترین فعالیت‌های تستر در این مرحله، بررسی قابلیت تست (Testability) یا قابل تست بودن نیازمندی‌ها است.

تستر می‌تواند سؤالاتی مانند این موارد مطرح کند:

• آیا نیازمندی به اندازه کافی واضح است؟
• آیا شرایط پذیرش آن مشخص شده است؟
• آیا می‌توان بر اساس آن مورد تست (Test Case) طراحی کرد؟
• رفتار سیستم در شرایط نامعتبر مشخص شده است؟
• آیا حالت‌های مرزی تعریف شده‌اند؟
• آیا نیازمندی با سایر نیازمندی‌ها تناقض دارد؟
• آیا معیار مشخصی برای تعیین موفقیت یا شکست وجود دارد؟

برای مثال، اگر نیازمندی این باشد:

«صفحه پرداخت باید سریع باشد.»

این نیازمندی برای تست مناسب نیست، زیرا مشخص نیست منظور از «سریع» دقیقاً چیست.

اما اگر گفته شود:

«صفحه پرداخت باید در شرایط عادی حداکثر طی ۲ ثانیه بارگذاری شود.»

اکنون یک معیار مشخص و قابل اندازه‌گیری وجود دارد که می‌توان آن را تست کرد.

چرا شناسایی مشکلات در Requirement مهم است؟

مشکلاتی که در نیازمندی‌ها ایجاد می‌شوند، ممکن است به مراحل بعدی منتقل شوند و در نهایت به طراحی، کدنویسی و تست آسیب بزنند.

فرض کنید یک نیازمندی از ابتدا مبهم باشد و توسعه‌دهنده بر اساس یک برداشت آن را پیاده‌سازی کند، در حالی که منظور واقعی کسب‌وکار چیز دیگری بوده است. ممکن است این اختلاف زمانی مشخص شود که قابلیت توسعه داده شده و تستر آن را بررسی می‌کند.

در این حالت، اصلاح مشکل ممکن است به تغییر نیازمندی، طراحی و کد نیاز داشته باشد.

به همین دلیل، بررسی نیازمندی‌ها در مراحل اولیه می‌تواند از دوباره‌کاری و افزایش هزینه اصلاح مشکلات جلوگیری کند.

خروجی Requirement Analysis چیست؟

خروجی این مرحله بسته به روش توسعه و نوع پروژه متفاوت است، اما معمولاً شامل مجموعه‌ای از نیازمندی‌های تحلیل و تأییدشده است که مشخص می‌کنند نرم افزار چه رفتارها و قابلیت‌هایی باید داشته باشد.

این نیازمندی‌ها در مراحل بعدی مبنایی برای طراحی، توسعه و تست نرم افزار قرار می‌گیرند.

برای تستر نیز نیازمندی‌ها یکی از منابع اصلی برای طراحی فعالیت‌های تست هستند. بر اساس همین نیازمندی‌ها می‌توان سناریو تست (Test Scenario)، مورد تست (Test Case) و داده تست (Test Data) را طراحی کرد.

بنابراین، هرچه نیازمندی‌ها واضح‌تر و قابل تست‌تر باشند، احتمال برداشت اشتباه و ایجاد نقص (Defect) در مراحل بعدی نیز کاهش پیدا می‌کند.

نکته: Requirement Analysis به این معنا نیست که تمام نیازمندی‌های یک نرم افزار باید از همان ابتدای پروژه برای همیشه ثابت و نهایی شوند. در مدل‌هایی مانند Agile، نیازمندی‌ها می‌توانند در طول تکرارها (Iterationها) تکمیل، اصلاح و اولویت‌بندی شوند.

پس از مشخص شدن نیازمندی‌ها، مرحله بعدی طراحی نرم افزار (Design) است؛ در این مرحله مشخص می‌شود نرم افزار چگونه باید ساخته شود تا نیازمندی‌های تعریف‌شده را برآورده کند.

مرحله سوم SDLC: طراحی نرم افزار (Design)

پس از تحلیل و مشخص شدن نیازمندی‌های نرم افزار، نوبت به مرحله طراحی (Design) می‌رسد. در این مرحله مشخص می‌شود نرم افزار چگونه باید ساخته شود تا بتواند نیازمندی‌های تعریف‌شده را برآورده کند.

اگر Requirement به این سؤال پاسخ دهد که «نرم افزار چه کاری باید انجام دهد؟»، مرحله Design بیشتر به این سؤال پاسخ می‌دهد که «نرم افزار چگونه باید این کار را انجام دهد؟»

طراحی نرم افزار می‌تواند بخش‌های مختلفی از سیستم را شامل شود؛ از معماری کلی نرم افزار گرفته تا طراحی پایگاه داده (Database)، رابط‌های برنامه‌نویسی کاربردی (API)، رابط کاربری و نحوه ارتباط اجزای مختلف سیستم با یکدیگر.

در مرحله Design چه فعالیت‌هایی انجام می‌شود؟

فعالیت‌های این مرحله به نوع و پیچیدگی پروژه بستگی دارد، اما معمولاً موارد زیر مورد توجه قرار می‌گیرند:

• طراحی معماری نرم افزار
• مشخص کردن اجزا (Components) و ماژول‌ها (Modules)
• طراحی ساختار پایگاه داده (Database)
• طراحی APIها و نحوه ارتباط سرویس‌ها
• طراحی رابط کاربری (UI)
• مشخص کردن ارتباط بین اجزای سیستم
• انتخاب فناوری‌ها و ابزارهای مورد نیاز
• بررسی ملاحظات امنیتی و کارایی
• بررسی محدودیت‌ها و ریسک‌های فنی

برای مثال، در یک فروشگاه اینترنتی ممکن است در مرحله Design مشخص شود که اطلاعات محصولات و سفارش‌ها چگونه در پایگاه داده ذخیره شوند، بخش رابط کاربری چگونه با بخش Backend ارتباط برقرار کند و API مربوط به افزودن محصول به سبد خرید چگونه طراحی شود.

نقش تستر در مرحله Design

نقش تستر در این مرحله بیشتر از اجرای تست‌های عملی است. تستر می‌تواند طراحی سیستم را از دید کیفیت (Quality) و قابلیت تست (Testability) بررسی کند.

قابلیت تست (Testability) به این موضوع اشاره دارد که سیستم تا چه اندازه برای تست کردن مناسب است. طراحی‌ای که قابلیت تست مناسبی داشته باشد، معمولاً امکان شناسایی و بررسی رفتارهای مختلف سیستم را ساده‌تر می‌کند.

برای مثال، اگر یک سیستم به شکلی طراحی شده باشد که اجزای آن وابستگی‌های بسیار زیادی به یکدیگر داشته باشند، تست کردن هر بخش به صورت مستقل می‌تواند دشوار شود. در مقابل، طراحی مناسب و تفکیک مسئولیت‌ها می‌تواند تست اجزای مختلف را ساده‌تر کند.

تستر می‌تواند در این مرحله درباره موضوعاتی مانند موارد زیر بازخورد ارائه دهد:

• آیا اجزای مختلف قابلیت تست مستقل دارند؟
• آیا APIها برای تست قابل دسترسی هستند؟
• آیا سیستم ثبت گزارش (Logging) مناسبی برای بررسی خطاها دارد؟
• آیا وابستگی‌های بین اجزا تست را دشوار می‌کنند؟
• آیا نیازهای کارایی و امنیت در طراحی در نظر گرفته شده‌اند؟
• آیا امکان ایجاد داده تست مناسب وجود دارد؟

یک مثال ساده از Testability در Design

فرض کنید یک سیستم فروشگاهی برای ثبت سفارش، چندین عملیات را به صورت کاملاً وابسته به یکدیگر انجام می‌دهد و هیچ رابط یا API مشخصی برای دسترسی مستقل به بخش‌های مختلف وجود ندارد.

در چنین شرایطی، تستر ممکن است برای بررسی یک قابلیت ساده مجبور باشد کل فرآیند خرید را اجرا کند.

اما اگر سیستم به شکل مناسب طراحی شده باشد، ممکن است بتوان بخش‌های مختلف مانند محاسبه قیمت، اعمال تخفیف، موجودی کالا و ثبت سفارش را تا حد امکان مستقل بررسی کرد.

این موضوع باعث می‌شود طراحی مناسب، علاوه بر مزایای فنی، فرآیند تست نرم افزار را نیز ساده‌تر و قابل اطمینان‌تر کند.

خروجی مرحله Design چیست؟

خروجی مرحله طراحی می‌تواند شامل موارد مختلفی مانند معماری سیستم، طراحی پایگاه داده، طراحی رابط کاربری، مشخصات API، ساختار اجزا و نحوه ارتباط بخش‌های مختلف سیستم باشد.

این خروجی‌ها در مرحله بعد به عنوان مبنایی برای پیاده‌سازی نرم افزار مورد استفاده قرار می‌گیرند.

نکته: Design الزاماً یک مرحله کاملاً ثابت و یک‌باره نیست. در روش‌هایی مانند Agile و Iterative، طراحی می‌تواند همزمان با توسعه و بر اساس نیازمندی‌ها و بازخوردهای جدید تکمیل یا اصلاح شود.

پس از مشخص شدن نحوه ساخت نرم افزار، تیم وارد مرحله توسعه (Development) می‌شود؛ جایی که طراحی‌ها به کد و اجزای قابل اجرا تبدیل می‌شوند.

مرحله چهارم SDLC: توسعه نرم افزار (Development)

پس از مشخص شدن نیازمندی‌ها و طراحی سیستم، مرحله توسعه (Development) آغاز می‌شود. در این مرحله، تیم توسعه طراحی‌ها و نیازمندی‌های مشخص‌شده را به یک نرم افزار واقعی و قابل اجرا تبدیل می‌کند.

به زبان ساده، اگر در مرحله Requirement مشخص شده باشد که نرم افزار چه کاری باید انجام دهد و در مرحله Design مشخص شده باشد که چگونه باید ساخته شود، در مرحله Development این طراحی‌ها به کد و اجزای واقعی نرم افزار تبدیل می‌شوند.

در مرحله Development چه فعالیت‌هایی انجام می‌شود؟

فعالیت‌های این مرحله به نوع پروژه و فناوری‌های مورد استفاده بستگی دارد، اما معمولاً شامل موارد زیر است:

• نوشتن و پیاده‌سازی کد
• ایجاد و توسعه اجزا (Components) و ماژول‌ها (Modules)
• پیاده‌سازی پایگاه داده و منطق دسترسی به داده‌ها
• پیاده‌سازی APIها
• توسعه رابط کاربری
• اتصال اجزای مختلف به یکدیگر
• بررسی کد (Code Review)
• ساخت (Build) و ایجاد نسخه‌های قابل اجرا
• اجرای تست‌های اولیه مانند تست واحد (Unit Testing)

توسعه نرم افزار معمولاً یک فعالیت یک‌باره نیست. در پروژه‌های واقعی، کد به تدریج توسعه پیدا می‌کند و با انجام تغییرات جدید، بخش‌های مختلف سیستم نیز ممکن است اصلاح یا تکمیل شوند.

نقش تستر در مرحله Development

در نگاه سنتی ممکن است تصور شود که تستر پس از پایان کامل توسعه وارد پروژه می‌شود؛ اما در بسیاری از تیم‌های مدرن، فعالیت‌های مرتبط با تست از زمان توسعه نیز در جریان هستند.

تستر می‌تواند همزمان با توسعه برای موارد زیر آماده شود:

• بررسی نیازمندی‌ها و طراحی‌های مرتبط با قابلیت
• طراحی سناریو تست و مورد تست
• آماده‌سازی داده تست
• آماده‌سازی محیط تست
• بررسی تغییرات جدید و تأثیر آن‌ها بر بخش‌های موجود
• هماهنگی با توسعه‌دهنده درباره رفتار مورد انتظار سیستم

این کار باعث می‌شود پس از آماده شدن قابلیت، فرآیند تست سریع‌تر و منظم‌تر انجام شود.

تست در زمان Development

تست نرم افزار فقط به اجرای تست توسط تیم QA محدود نمی‌شود. در مرحله Development نیز ممکن است تست‌های مختلفی توسط توسعه‌دهنده یا سایر اعضای تیم انجام شوند.

یکی از مهم‌ترین نمونه‌ها تست واحد (Unit Testing) است. در تست واحد، بخش‌های کوچک و مستقل نرم افزار، مانند یک تابع (Function) یا متد (Method)، بررسی می‌شوند تا مشخص شود رفتار آن‌ها مطابق انتظار است.

همچنین فعالیت‌هایی مانند بررسی کد (Code Review) و تست ایستا (Static Testing) می‌توانند به شناسایی مشکلات پیش از اجرای نرم افزار کمک کنند.

البته نوع و میزان این فعالیت‌ها به فرآیند توسعه، ساختار تیم و پروژه بستگی دارد.

ارتباط توسعه‌دهنده و تستر

همکاری مناسب بین توسعه‌دهنده و تستر در این مرحله اهمیت زیادی دارد. تستر می‌تواند سؤالات و ابهام‌های مربوط به رفتار مورد انتظار سیستم را با توسعه‌دهنده مطرح کند و توسعه‌دهنده نیز می‌تواند درباره نحوه پیاده‌سازی و محدودیت‌های فنی توضیح دهد.

برای مثال، اگر تستر هنگام بررسی یک قابلیت متوجه شود که یک حالت خاص در نیازمندی مشخص نشده است، بهتر است این موضوع پیش از اجرای تست نهایی با تیم بررسی شود.

این همکاری می‌تواند از ایجاد برداشت‌های متفاوت و نقص‌های قابل پیشگیری جلوگیری کند.

خروجی مرحله Development چیست؟

خروجی این مرحله معمولاً شامل کد، اجزا، ماژول‌ها و نسخه‌های قابل اجرای نرم افزار است که بر اساس نیازمندی‌ها و طراحی‌های انجام‌شده توسعه یافته‌اند.

پس از آماده شدن نسخه مورد نیاز برای ارزیابی، نرم افزار وارد مرحله تست (Testing) می‌شود تا رفتار و کیفیت آن در برابر نیازمندی‌ها و معیارهای مورد انتظار بررسی شود.

نکته: پایان Development به معنای پایان فعالیت‌های توسعه نیست. در مدل‌هایی مانند Agile، توسعه و تست در تکرارهای مختلف بارها انجام می‌شوند و نرم افزار به صورت تدریجی تکامل پیدا می‌کند.

در مرحله بعد به یکی از مهم‌ترین بخش‌های SDLC از دید یک تستر می‌رسیم: مرحله تست نرم افزار (Testing).

مرحله پنجم SDLC: تست نرم افزار (Testing)

پس از اینکه بخشی از نرم افزار توسعه پیدا کرد و نسخه‌ای قابل ارزیابی در اختیار تیم قرار گرفت، نوبت به تست نرم افزار (Software Testing) می‌رسد. در این مرحله، نرم افزار بررسی می‌شود تا مشخص شود آیا رفتار آن با نیازمندی‌ها و نتایج مورد انتظار مطابقت دارد یا خیر.

هدف تست فقط پیدا کردن باگ (Bug) نیست. تست نرم افزار به تیم کمک می‌کند تا مشکلات، ریسک‌ها و رفتارهای غیرمنتظره سیستم را شناسایی کند و اطلاعات لازم برای تصمیم‌گیری درباره کیفیت و آمادگی محصول در اختیار تیم قرار دهد.

البته در عمل، فعالیت‌های مرتبط با تست می‌توانند پیش از این مرحله نیز آغاز شده باشند. برای مثال، تستر می‌تواند در مرحله تحلیل نیازمندی‌ها، ابهام‌ها و مشکلات مربوط به قابل تست بودن نیازمندی‌ها را شناسایی کند. بنابراین، مرحله Testing را نباید به این معنا در نظر گرفت که تمام فعالیت‌های تست برای اولین بار در این نقطه آغاز می‌شوند.

در مرحله Testing چه فعالیت‌هایی انجام می‌شود؟

فرآیند تست بسته به نوع پروژه، روش توسعه و نوع نرم افزار متفاوت است، اما فعالیت‌هایی مانند موارد زیر معمولاً در آن انجام می‌شوند:

• بررسی نیازمندی‌ها و معیارهای پذیرش
• طراحی سناریوهای تست
• طراحی موارد تست
• آماده‌سازی داده‌های تست
• آماده‌سازی محیط تست
• اجرای تست‌ها
• ثبت و گزارش باگ‌ها
• تست مجدد پس از رفع باگ
• تست بازگشتی پس از اعمال تغییرات
• بررسی نتایج و گزارش وضعیت تست

برای مثال، فرض کنید در نیازمندی یک فروشگاه اینترنتی مشخص شده باشد که کاربر باید بتواند محصول را به سبد خرید اضافه کند. تستر می‌تواند حالت‌های مختلفی مانند افزودن یک محصول موجود، افزودن محصول ناموجود، رسیدن تعداد محصول به حد مجاز و تلاش برای افزودن تعداد بیشتر از حد مجاز را بررسی کند.

تستر در مرحله Testing چه کاری انجام می‌دهد؟

در این مرحله، تستر نرم افزار را از جنبه‌های مختلف بررسی می‌کند تا مشخص شود آیا سیستم رفتار مورد انتظار را دارد یا خیر.

بسته به نوع پروژه، تستر ممکن است تست‌های مختلفی را انجام دهد، از جمله:

• تست عملکردی (Functional Testing) برای بررسی قابلیت‌های نرم افزار
• تست غیرعملکردی (Non-Functional Testing) برای بررسی ویژگی‌هایی مانند کارایی، امنیت و قابلیت استفاده
• تست رابط کاربری (UI Testing)
• تست API
• تست یکپارچه‌سازی (Integration Testing)
• تست سیستم (System Testing)
• تست بازگشتی (Regression Testing)
• تست مجدد (Retesting)

البته همه این تست‌ها لزوماً در تمام پروژه‌ها و در یک مرحله مشخص از SDLC انجام نمی‌شوند. نوع تست‌ها بر اساس نیازمندی‌ها، معماری سیستم، ریسک‌ها و روش توسعه انتخاب می‌شود.

ثبت و مدیریت باگ

اگر تستر رفتاری مغایر با نیازمندی یا رفتار مورد انتظار سیستم پیدا کند، آن را به عنوان باگ یا نقص (Defect) ثبت می‌کند.

یک گزارش باگ مناسب معمولاً اطلاعاتی مانند موارد زیر را در اختیار تیم قرار می‌دهد:

• عنوان مشکل
• مراحل بازتولید
• نتیجه مورد انتظار
• نتیجه واقعی
• محیط تست
• شدت و اولویت مشکل
• شواهدی مانند تصویر یا ویدئو، در صورت نیاز

پس از رفع مشکل توسط تیم توسعه، تستر معمولاً تست مجدد (Retesting) انجام می‌دهد تا بررسی کند آیا همان مشکل برطرف شده است یا خیر.

همچنین اگر تغییر انجام‌شده بتواند روی بخش‌های دیگر نرم افزار تأثیر بگذارد، ممکن است تست بازگشتی (Regression Testing) انجام شود تا مشخص شود قابلیت‌های قبلی همچنان به درستی کار می‌کنند.

آیا تست نرم افزار فقط پیدا کردن باگ است؟

خیر. یکی از برداشت‌های اشتباه درباره تست نرم افزار این است که وظیفه تستر فقط پیدا کردن باگ و گزارش آن است.

تست نرم افزار در واقع فرآیندی برای ارزیابی کیفیت محصول و کاهش ریسک است. تستر با اجرای تست‌ها، بررسی رفتار سیستم و ارائه اطلاعات درباره مشکلات و ریسک‌های موجود، به تیم کمک می‌کند تصمیم آگاهانه‌تری درباره وضعیت محصول بگیرد.

برای آشنایی جامع‌تر با مفاهیم، فرآیندها و انواع تست نرم افزار، می‌توانید مقاله آموزش تست نرم افزار را مطالعه کنید.

خروجی مرحله Testing چیست؟

خروجی تست بسته به پروژه و فرآیند تیم می‌تواند شامل موارد مختلفی باشد، از جمله:

• نتایج اجرای تست‌ها
• گزارش باگ‌ها
• وضعیت رفع مشکلات
• گزارش وضعیت تست
• اطلاعات مربوط به ریسک‌های باقی‌مانده
• اطلاعات مورد نیاز برای تصمیم‌گیری درباره انتشار نرم افزار

در نهایت، نتیجه تست می‌تواند به تیم کمک کند مشخص کند آیا نسخه مورد بررسی با معیارهای تعریف‌شده برای ادامه فرآیند، انتشار یا استقرار مطابقت دارد یا خیر.

نکته: موفقیت در تست به معنی اثبات نبود هیچ باگی در نرم افزار نیست. تست می‌تواند وجود مشکلات را آشکار کند، اما نمی‌تواند به طور قطعی ثابت کند که یک نرم افزار هیچ نقصی ندارد.

پس از انجام فعالیت‌های لازم و آماده شدن نسخه برای انتشار، نرم افزار وارد مرحله استقرار (Deployment) می‌شود؛ مرحله‌ای که در آن نرم افزار در محیط مقصد قرار می‌گیرد و در اختیار کاربران یا مشتریان قرار می‌گیرد.

مرحله ششم SDLC: استقرار نرم افزار (Deployment)

پس از توسعه و انجام تست‌های لازم، نرم افزار در صورت آماده بودن برای انتشار وارد مرحله استقرار (Deployment) می‌شود. در این مرحله، نسخه مورد نظر نرم افزار در محیط مقصد قرار می‌گیرد تا برای کاربران، مشتریان یا سایر مصرف‌کنندگان سیستم قابل استفاده باشد.

استقرار می‌تواند به شکل‌های مختلفی انجام شود. برای مثال، یک برنامه وب ممکن است روی سرور قرار گیرد، یک برنامه موبایل در فروشگاه نرم‌افزاری منتشر شود یا یک نرم افزار سازمانی در زیرساخت داخلی شرکت نصب و فعال شود.

در مرحله Deployment چه فعالیت‌هایی انجام می‌شود؟

فعالیت‌های استقرار به نوع نرم افزار و زیرساخت پروژه بستگی دارند، اما معمولاً شامل موارد زیر هستند:

• آماده‌سازی محیط مقصد
• انتقال نسخه جدید نرم افزار
• اعمال تنظیمات مورد نیاز
• اجرای فرآیند انتشار
• به‌روزرسانی پایگاه داده در صورت نیاز
• بررسی وضعیت سرویس‌ها پس از استقرار
• بررسی اولیه عملکرد نرم افزار
• نظارت بر سیستم پس از استقرار
• بازگشت به نسخه قبلی در صورت بروز مشکل جدی

در پروژه‌هایی که از تحویل مداوم و استقرار مداوم (Continuous Delivery / Continuous Deployment) استفاده می‌شود، فرآیند استقرار می‌تواند تا حد زیادی خودکار باشد.

نقش تستر در مرحله Deployment

تست در مرحله استقرار نیز می‌تواند ادامه داشته باشد. یکی از فعالیت‌های رایج در این مرحله، انجام تست دود (Smoke Testing) پس از انتشار نسخه است.

هدف تست دود این است که بررسی شود قابلیت‌های اصلی و حیاتی نرم افزار پس از استقرار همچنان در وضعیت قابل استفاده قرار دارند.

برای مثال، در یک فروشگاه اینترنتی ممکن است پس از استقرار نسخه جدید، تستر یا تیم مربوطه بررسی کند که:

• سایت به درستی در دسترس است.
• کاربران می‌توانند وارد حساب خود شوند.
• محصولات نمایش داده می‌شوند.
• امکان افزودن محصول به سبد خرید وجود دارد.
• فرآیند ثبت سفارش با مشکل جدی مواجه نیست.

اگر یکی از قابلیت‌های حیاتی سیستم پس از استقرار با مشکل جدی مواجه باشد، ممکن است ادامه تست یا انتشار نسخه متوقف شود تا مشکل بررسی و برطرف شود.

تفاوت Deployment و Release

استقرار (Deployment) و انتشار (Release) مفاهیم مرتبطی هستند، اما همیشه دقیقاً یکسان نیستند.

Deployment به قرار دادن یک نسخه نرم افزار در یک محیط مشخص اشاره دارد، در حالی که Release بیشتر به در دسترس قرار دادن یک قابلیت یا نسخه برای کاربران مربوط می‌شود.

برای مثال، ممکن است یک قابلیت در محیط تولید مستقر شود اما هنوز برای تمام کاربران فعال نشده باشد. در چنین شرایطی Deployment انجام شده، اما Release عمومی آن قابلیت ممکن است در زمان دیگری انجام شود.

بعد از استقرار چه اتفاقی می‌افتد؟

استقرار به معنی پایان چرخه توسعه نرم افزار نیست. پس از قرار گرفتن نرم افزار در محیط واقعی، ممکن است کاربران با مشکلات جدیدی مواجه شوند یا نیازهای جدیدی شکل بگیرد.

به همین دلیل، نرم افزار وارد مرحله نگهداری (Maintenance) می‌شود؛ مرحله‌ای که در آن مشکلات برطرف می‌شوند، تغییرات مورد نیاز اعمال می‌شوند و قابلیت‌های جدید به محصول اضافه می‌شوند.

نکته: در بسیاری از پروژه‌های مدرن، مرز مشخصی میان Development، Testing و Deployment وجود ندارد و این فعالیت‌ها می‌توانند به صورت مداوم و تکرارشونده انجام شوند. این موضوع به‌خصوص در روش‌هایی مانند Agile و رویکردهای CI/CD اهمیت بیشتری پیدا می‌کند.

در بخش بعدی، آخرین مرحله رایج چرخه توسعه نرم افزار یعنی نگهداری (Maintenance) را بررسی می‌کنیم.

مرحله هفتم SDLC: نگهداری نرم افزار (Maintenance)

پس از استقرار نرم افزار، چرخه توسعه به پایان نمی‌رسد. نرم افزار پس از انتشار همچنان باید پشتیبانی، اصلاح، به‌روزرسانی و بهبود داده شود. این فعالیت‌ها در مرحله نگهداری (Maintenance) انجام می‌شوند.

نرم افزار در محیط واقعی ممکن است با شرایطی مواجه شود که در زمان توسعه پیش‌بینی نشده بودند. همچنین نیازهای کاربران و کسب‌وکار تغییر می‌کنند، مشکلات جدیدی شناسایی می‌شوند و ممکن است قابلیت‌های جدیدی مورد نیاز باشند.

بنابراین، Maintenance را می‌توان مرحله‌ای دانست که در آن نرم افزار پس از انتشار، برای حفظ کیفیت، رفع مشکلات و سازگار شدن با نیازهای جدید بهبود پیدا می‌کند.

در مرحله Maintenance چه فعالیت‌هایی انجام می‌شود؟

فعالیت‌های نگهداری به نوع نرم افزار و نیازهای پروژه بستگی دارند، اما معمولاً شامل موارد زیر هستند:

• شناسایی و رفع باگ‌ها
• اصلاح مشکلات گزارش‌شده توسط کاربران
• بهبود عملکرد و کارایی نرم افزار
• اضافه کردن قابلیت‌های جدید
• به‌روزرسانی نرم افزار و وابستگی‌های آن
• سازگار کردن نرم افزار با تغییرات محیطی
• بهبود امنیت سیستم
• بهبود قابلیت استفاده و تجربه کاربری
• بررسی تأثیر تغییرات بر بخش‌های موجود

برای مثال، ممکن است پس از انتشار یک فروشگاه اینترنتی مشخص شود که برخی کاربران هنگام پرداخت با خطا مواجه می‌شوند. تیم توسعه باید مشکل را بررسی و اصلاح کند و سپس نسخه اصلاح‌شده را دوباره تست و مستقر کند.

انواع فعالیت‌های نگهداری نرم افزار

نگهداری نرم افزار می‌تواند دلایل مختلفی داشته باشد. برخی از مهم‌ترین آن‌ها عبارت‌اند از:

نگهداری اصلاحی (Corrective Maintenance):
برای شناسایی و رفع مشکلات و باگ‌هایی انجام می‌شود که پس از استفاده از نرم افزار مشاهده شده‌اند.

نگهداری تطبیقی (Adaptive Maintenance):
زمانی انجام می‌شود که نرم افزار باید با تغییرات محیطی یا فناوری سازگار شود. برای مثال، تغییر سیستم‌عامل، پایگاه داده یا سایر اجزای زیرساخت می‌تواند نیاز به چنین تغییراتی ایجاد کند.

نگهداری تکمیلی (Perfective Maintenance):
برای بهبود نرم افزار، افزایش کیفیت یا اضافه کردن قابلیت‌هایی انجام می‌شود که ارزش بیشتری برای کاربران یا کسب‌وکار ایجاد می‌کنند.

نگهداری پیشگیرانه (Preventive Maintenance):
با هدف کاهش احتمال بروز مشکلات آینده انجام می‌شود. برای مثال، بازسازی بخشی از کد، کاهش پیچیدگی یا بهبود ساختار سیستم می‌تواند احتمال ایجاد مشکلات آینده را کاهش دهد.

نقش تستر در مرحله Maintenance

هر تغییری که در نرم افزار ایجاد می‌شود می‌تواند روی بخش‌های دیگری از سیستم نیز تأثیر بگذارد. به همین دلیل، تست در مرحله نگهداری اهمیت زیادی دارد.

تستر ممکن است پس از یک تغییر، فعالیت‌هایی مانند موارد زیر را انجام دهد:

• بررسی باگ اصلاح‌شده
• انجام تست مجدد (Retesting) برای اطمینان از رفع مشکل
• انجام تست بازگشتی (Regression Testing) برای بررسی بخش‌های مرتبط
• اجرای تست‌های عملکردی
• بررسی قابلیت‌های جدید
• بررسی تأثیر تغییرات بر بخش‌های موجود
• انجام تست‌های غیرعملکردی در صورت نیاز

برای مثال، فرض کنید باگی در فرآیند پرداخت یک فروشگاه اینترنتی اصلاح شده است. تستر ابتدا همان مشکل را دوباره بررسی می‌کند تا مطمئن شود اصلاح شده است. سپس ممکن است بخش‌هایی مانند ورود به حساب کاربری، سبد خرید و ثبت سفارش را نیز بررسی کند تا مشخص شود تغییر انجام‌شده باعث ایجاد مشکل جدیدی نشده است.

آیا Maintenance به معنی فقط رفع باگ است؟

خیر. یکی از برداشت‌های اشتباه درباره نگهداری نرم افزار این است که این مرحله فقط برای رفع باگ‌های موجود است.

در واقع، نرم افزار ممکن است بدون وجود هیچ باگ شناخته‌شده‌ای نیز به تغییر و بهبود نیاز داشته باشد.

برای مثال:

• کاربران ممکن است قابلیت جدیدی درخواست کنند.
• قوانین کسب‌وکار ممکن است تغییر کنند.
• یک فناوری قدیمی ممکن است نیاز به جایگزینی داشته باشد.
• الزامات امنیتی جدید ممکن است ایجاد شوند.
• تعداد کاربران سیستم ممکن است افزایش پیدا کند و نیاز به بهبود کارایی ایجاد شود.

بنابراین، Maintenance بخش مهمی از تکامل نرم افزار است و می‌تواند تا زمانی که محصول مورد استفاده قرار می‌گیرد ادامه داشته باشد.

خروجی مرحله Maintenance چیست؟

خروجی این مرحله می‌تواند شامل نسخه‌های اصلاح‌شده، به‌روزرسانی‌شده یا بهبود‌یافته نرم افزار باشد.

هر تغییر مهم ممکن است دوباره نیازمند تحلیل، طراحی، توسعه، تست و استقرار باشد. به همین دلیل، چرخه توسعه نرم افزار در عمل یک مسیر کاملاً خطی نیست؛ بلکه پس از انتشار یک نسخه، تغییرات جدید می‌توانند چرخه را دوباره وارد مراحل مختلف کنند.

برای مثال:

Maintenance → Requirement → Design → Development → Testing → Deployment

این چرخه می‌تواند بارها تکرار شود تا نرم افزار با نیازهای جدید کاربران و کسب‌وکار هماهنگ باقی بماند.

نکته: مرحله Maintenance را نباید مرحله‌ای در نظر گرفت که فقط در پایان عمر نرم افزار انجام می‌شود. در بسیاری از نرم افزارهای واقعی، نگهداری و بهبود محصول بخش قابل توجهی از طول عمر آن را تشکیل می‌دهد.

با بررسی هفت مرحله اصلی، اکنون تصویر کلی از چرخه توسعه نرم افزار (SDLC) داریم. اما یک سؤال مهم باقی می‌ماند: آیا واقعاً تست فقط یکی از این هفت مرحله است؟

آیا تست فقط یکی از مراحل SDLC است؟

با توجه به ساختاری که برای چرخه توسعه نرم افزار (SDLC) بررسی کردیم، ممکن است این سؤال مطرح شود:

اگر Testing یکی از مراحل SDLC است، آیا تستر فقط در همین مرحله فعالیت می‌کند؟

پاسخ خیر است.

در برخی مدل‌های سنتی توسعه، تست به عنوان مرحله‌ای مشخص پس از Development در نظر گرفته می‌شود؛ اما در رویکردهای مدرن، فعالیت‌های مرتبط با کیفیت و تست می‌توانند از مراحل اولیه چرخه آغاز شوند و در مراحل مختلف ادامه پیدا کنند.

به بیان ساده، Testing یکی از مراحل مهم SDLC است، اما کیفیت نرم افزار فقط در مرحله Testing ساخته نمی‌شود.

تست می‌تواند از مرحله Requirement آغاز شود

یکی از مهم‌ترین نقاط مشارکت تستر، مرحله تحلیل نیازمندی‌ها (Requirement Analysis) است.

تستر می‌تواند نیازمندی‌ها را از نظر قابل تست بودن (Testability) بررسی کند و مواردی مانند ابهام، تناقض، شرایط نامشخص و حالت‌های مرزی را مطرح کند.

برای مثال، اگر نیازمندی این باشد:

«سیستم باید در زمان مناسب پاسخ دهد.»

این نیازمندی برای تست مناسب نیست؛ زیرا مشخص نیست «زمان مناسب» دقیقاً چه مقداری است.

تستر می‌تواند این ابهام را مطرح کند تا نیازمندی به یک معیار قابل اندازه‌گیری تبدیل شود؛ برای مثال:

«سیستم باید در شرایط عادی حداکثر طی ۲ ثانیه پاسخ دهد.»

در این حالت، یک مشکل احتمالی پیش از رسیدن پروژه به مرحله توسعه شناسایی شده است.

تست در مرحله Design

در مرحله طراحی (Design) نیز تستر می‌تواند درباره قابلیت تست (Testability) سیستم بازخورد ارائه دهد.

برای مثال، تستر می‌تواند بررسی کند که:

• آیا اجزای سیستم قابلیت تست مستقل دارند؟
• آیا رابط‌های برنامه‌نویسی کاربردی (API) مورد نیاز برای تست قابل دسترسی هستند؟
• آیا امکان ایجاد داده تست مناسب وجود دارد؟
• آیا سیستم اطلاعات و گزارش‌های کافی برای بررسی خطاها تولید می‌کند؟
• آیا وابستگی بین اجزای سیستم، تست را دشوار نمی‌کند؟

شناسایی چنین مشکلاتی در مرحله طراحی می‌تواند هزینه و پیچیدگی تست را در مراحل بعدی کاهش دهد.

تست در مرحله Development

در زمان توسعه (Development) نیز فعالیت‌های مرتبط با کیفیت ادامه دارند.

تستر می‌تواند همزمان با توسعه، سناریوهای تست، موارد تست و داده‌های تست را آماده کند و درباره رفتار مورد انتظار قابلیت‌های جدید با تیم توسعه همکاری داشته باشد.

از طرف دیگر، فعالیت‌هایی مانند تست واحد (Unit Testing)، بازبینی کد (Code Review) و سایر روش‌های بررسی نرم افزار نیز می‌توانند در همین مرحله به شناسایی مشکلات کمک کنند.

تست در مرحله Testing

البته مرحله‌ای که در SDLC با عنوان Testing شناخته می‌شود همچنان اهمیت بسیار زیادی دارد.

در این مرحله، نرم افزار به شکل عملی مورد ارزیابی قرار می‌گیرد و تستر می‌تواند بر اساس نیازمندی‌ها و ریسک‌های پروژه، تست‌های مختلف را اجرا کند.

فعالیت‌هایی مانند طراحی و اجرای تست، ثبت باگ، تست مجدد، تست بازگشتی و گزارش وضعیت تست ممکن است در این مرحله انجام شوند.

فرآیند کامل چرخه تست و جزئیات فعالیت‌های تست در STLC موضوع مقاله‌ای جداگانه است؛ بنابراین در اینجا تمرکز ما بر جایگاه تست در چرخه کلی توسعه نرم افزار است.

بنابراین، مرحله Testing را نباید حذف کرد؛ بلکه باید آن را یکی از نقاط مهم فعالیت‌های تست و ارزیابی کیفیت در یک چرخه گسترده‌تر در نظر گرفت.

تست پس از Deployment نیز ادامه پیدا می‌کند

حتی پس از استقرار (Deployment) نیز فعالیت‌های مرتبط با تست می‌توانند ادامه داشته باشند.

برای مثال، پس از انتشار نسخه جدید ممکن است تستر یا تیم QA بررسی‌های اولیه‌ای را در محیط مربوط به انتشار انجام دهد تا مطمئن شود قابلیت‌های اصلی سیستم همچنان قابل استفاده هستند.

همچنین اگر پس از انتشار یک باگ شناسایی و اصلاح شود، تستر باید نسخه اصلاح‌شده را دوباره بررسی کند و در صورت نیاز تست‌های بازگشتی انجام دهد.

یک نگاه ساده به نقش تست در SDLC

اگر بخواهیم نقش تست را در چرخه توسعه نرم افزار به شکل ساده نمایش دهیم، مراحل اصلی را می‌توان این‌گونه در نظر گرفت:

Planning → Requirement → Design → Development → Testing → Deployment → Maintenance

اما فعالیت‌های مرتبط با کیفیت می‌توانند در تمام این مراحل حضور داشته باشند:

Quality & Testing → → → → → → →

یعنی تستر فقط زمانی که نرم افزار آماده اجرا شده است وارد پروژه نمی‌شود، بلکه می‌تواند در مراحل مختلف چرخه توسعه برای پیشگیری از مشکلات، شناسایی ریسک‌ها و ارزیابی کیفیت مشارکت داشته باشد.

چرا این رویکرد اهمیت دارد؟

هرچه یک مشکل دیرتر در چرخه توسعه شناسایی شود، معمولاً اصلاح آن می‌تواند به زمان، هزینه و دوباره‌کاری بیشتری نیاز داشته باشد.

برای مثال، اگر یک ابهام در Requirement پیش از توسعه شناسایی شود، ممکن است فقط با اصلاح همان نیازمندی برطرف شود. اما اگر همان ابهام پس از توسعه و تست مشخص شود، احتمالاً نیاز به تغییر Requirement، Design و Code و سپس اجرای مجدد بخشی از تست‌ها وجود خواهد داشت.

به همین دلیل، مشارکت تستر در مراحل اولیه می‌تواند به پیشگیری از Defect، کاهش دوباره‌کاری و افزایش کیفیت نرم افزار کمک کند.

نکته مهم: این موضوع به این معنا نیست که تستر باید در تمام تصمیم‌های فنی پروژه نقش اصلی داشته باشد. نقش و میزان مشارکت Tester در SDLC به ساختار تیم، مدل توسعه، نوع محصول و ریسک‌های پروژه بستگی دارد.

بنابراین، پاسخ دقیق به سؤال این بخش این است:

Testing یکی از مراحل اصلی SDLC است، اما فعالیت‌های مرتبط با تست و کیفیت می‌توانند در تمام چرخه توسعه نرم افزار حضور داشته باشند.

در بخش بعدی به سراغ مدل‌های مختلف SDLC می‌رویم و بررسی می‌کنیم که چرا با وجود مراحل مشابه، پروژه‌های مختلف می‌توانند این مراحل را به شکل‌های متفاوتی اجرا کنند.

مدل‌های مختلف SDLC

تا اینجا دیدیم که چرخه توسعه نرم افزار (SDLC) شامل فعالیت‌هایی مانند برنامه‌ریزی، تحلیل نیازمندی‌ها، طراحی، توسعه، تست، استقرار و نگهداری است.

اما یک سؤال مهم وجود دارد:

آیا تمام تیم‌های نرم افزاری این مراحل را دقیقاً به یک شکل انجام می‌دهند؟

خیر.

SDLC یک چارچوب کلی برای سازمان‌دهی فرآیند توسعه نرم افزار است، اما نحوه اجرای این مراحل می‌تواند بر اساس نوع پروژه، نیازهای کسب‌وکار، میزان تغییرات مورد انتظار، ریسک‌های پروژه و ساختار تیم متفاوت باشد.

به رویکردهایی که مشخص می‌کنند مراحل مختلف SDLC چگونه، با چه ترتیبی و با چه میزان تکرار انجام شوند، معمولاً مدل‌های توسعه نرم افزار (Software Development Models) گفته می‌شود.

چرا مدل‌های مختلف SDLC وجود دارند؟

پروژه‌های نرم افزاری شرایط یکسانی ندارند.

برای مثال، در یک پروژه ممکن است نیازمندی‌ها از ابتدا کاملاً مشخص باشند و تغییرات بسیار کمی در طول توسعه اتفاق بیفتد. در چنین شرایطی، یک رویکرد مرحله‌ای و نسبتاً قابل پیش‌بینی می‌تواند مناسب باشد.

در پروژه‌ای دیگر، ممکن است نیازهای کاربران به مرور مشخص شوند و تیم مجبور باشد بر اساس بازخورد کاربران، محصول را مرتباً تغییر دهد. در چنین شرایطی، یک رویکرد تکرارشونده (Iterative) و انعطاف‌پذیر می‌تواند انتخاب مناسب‌تری باشد.

بنابراین، هدف مدل‌های مختلف SDLC این است که تیم بتواند فرآیند توسعه را متناسب با شرایط پروژه سازمان‌دهی کند.

چند مدل معروف SDLC

مدل‌های مختلفی برای توسعه نرم افزار وجود دارند که برخی از شناخته‌شده‌ترین آن‌ها عبارت‌اند از:

• مدل آبشاری (Waterfall)
• مدل V یا V-Model
• مدل تکرارشونده (Iterative)
• مدل افزایشی (Incremental)
• مدل مارپیچی (Spiral)
• مدل چابک (Agile)

این مدل‌ها الزاماً به این معنا نیستند که هرکدام مجموعه مراحل کاملاً متفاوتی دارند. بسیاری از آن‌ها از همان فعالیت‌های اصلی SDLC استفاده می‌کنند، اما نحوه ترتیب، تکرار و ارتباط بین این فعالیت‌ها متفاوت است.

تفاوت اصلی مدل‌های SDLC چیست؟

برای درک بهتر، فرض کنید مراحل اصلی پروژه این‌ها باشند:

Requirement → Design → Development → Testing → Deployment

در مدلی مانند Waterfall، این مراحل معمولاً به صورت نسبتاً متوالی انجام می‌شوند و خروجی یک مرحله مبنای مرحله بعد قرار می‌گیرد.

اما در یک رویکرد Agile، همین فعالیت‌ها می‌توانند در چرخه‌های کوتاه بارها تکرار شوند:

Requirement → Design → Development → Testing → Deployment

سپس برای بخش دیگری از محصول، چرخه بعدی آغاز می‌شود.

بنابراین، تفاوت مدل‌های SDLC بیشتر در نحوه اجرای چرخه است، نه صرفاً در نام مراحل آن.

انتخاب مدل SDLC به چه عواملی بستگی دارد؟

هیچ مدل SDLC واحدی وجود ندارد که برای تمام پروژه‌ها بهترین گزینه باشد.

در انتخاب یک مدل، عواملی مانند موارد زیر می‌توانند مورد توجه قرار گیرند:

• میزان مشخص بودن نیازمندی‌ها
• احتمال تغییر نیازهای کسب‌وکار
• اندازه و پیچیدگی پروژه
• سطح ریسک پروژه
• الزامات قانونی و مستندسازی
• میزان نیاز به بازخورد سریع کاربران
• ساختار و تجربه تیم
• نوع محصول و صنعت
• محدودیت‌های زمانی و بودجه
• اهمیت کیفیت و ریسک‌های احتمالی

برای مثال، پروژه‌ای با الزامات ثابت و کنترل‌شده ممکن است به رویکردی متفاوت از یک محصول دیجیتال با تغییرات سریع و بازخورد مداوم کاربران نیاز داشته باشد.

آیا انتخاب مدل SDLC روی تست نرم افزار هم تأثیر دارد؟

بله.

مدل انتخاب‌شده می‌تواند زمان‌بندی، نحوه برنامه‌ریزی و شیوه اجرای فعالیت‌های تست را تحت تأثیر قرار دهد.

برای مثال، در یک مدل مرحله‌ای ممکن است بخش زیادی از فعالیت‌های تست پس از توسعه انجام شود؛ در حالی که در Agile، تست معمولاً در همان چرخه‌های کوتاه توسعه انجام می‌شود و تستر می‌تواند به صورت مستمر با تیم همکاری کند.

به همین دلیل، یک تستر باید علاوه بر تکنیک‌های اجرای تست، درک مناسبی از مدل توسعه و فرآیند SDLC نیز داشته باشد.

در ادامه، سه مدل مهم و پرکاربرد را با جزئیات بیشتری بررسی می‌کنیم:

1. Waterfall؛ یک مدل مرحله‌ای و متوالی
2. V-Model؛ مدلی که ارتباط میان مراحل توسعه و فعالیت‌های تست را پررنگ‌تر می‌کند
3. Agile؛ رویکردی تکرارشونده و انعطاف‌پذیر که توسعه و تست را در چرخه‌های کوتاه انجام می‌دهد

در ابتدا به سراغ مدل آبشاری (Waterfall) می‌رویم.

مدل آبشاری (Waterfall) در SDLC

مدل آبشاری (Waterfall) یکی از شناخته‌شده‌ترین مدل‌های توسعه نرم افزار است. در این مدل، مراحل توسعه معمولاً به صورت متوالی و مرحله‌به‌مرحله انجام می‌شوند و خروجی هر مرحله، مبنایی برای ورود به مرحله بعد قرار می‌گیرد.

نام Waterfall یا «آبشاری» از همین ساختار گرفته شده است؛ یعنی فرآیند توسعه مانند جریان آب از یک مرحله به مرحله بعد حرکت می‌کند.

یک نمایش ساده از این مدل به شکل زیر است:

Requirement → Design → Development → Testing → Deployment → Maintenance

در رویکرد کلاسیک Waterfall، تیم معمولاً تلاش می‌کند پیش از ورود به مرحله بعد، فعالیت‌های اصلی مرحله فعلی را تکمیل و خروجی‌های آن را تا حد امکان نهایی کند.

مراحل مدل Waterfall

مراحل دقیق Waterfall می‌توانند بسته به تعریف سازمان یا منبع متفاوت باشند، اما معمولاً شامل فعالیت‌هایی مانند موارد زیر هستند:

1. نیازمندی‌ها (Requirements)
2. طراحی (Design)
3. توسعه (Development)
4. تست (Testing)
5. استقرار (Deployment)
6. نگهداری (Maintenance)

برای مثال، ابتدا نیازمندی‌های سیستم مشخص می‌شوند. سپس تیم بر اساس آن‌ها طراحی را انجام می‌دهد. پس از تکمیل طراحی، توسعه نرم افزار انجام می‌شود و در ادامه نسخه توسعه‌یافته برای تست در اختیار تیم تست قرار می‌گیرد.

ویژگی اصلی Waterfall چیست؟

مهم‌ترین ویژگی Waterfall، ترتیب نسبتاً خطی و متوالی مراحل است.

در این مدل، معمولاً انتظار می‌رود بخش قابل توجهی از نیازمندی‌ها و تصمیم‌های مهم پروژه در مراحل اولیه مشخص شوند.

به همین دلیل، تغییرات بزرگ در مراحل پایانی می‌توانند هزینه و پیچیدگی بیشتری ایجاد کنند.

برای مثال، فرض کنید پس از پایان Development مشخص شود که یکی از نیازمندی‌های اصلی اشتباه تحلیل شده است. اصلاح چنین مشکلی ممکن است فقط به تغییر یک بخش از Code محدود نشود و نیازمند بازگشت به Requirement و Design و سپس انجام مجدد بخشی از Development و Testing باشد.

جایگاه تست در Waterfall

در Waterfall، Testing معمولاً پس از Development انجام می‌شود.

به همین دلیل، در نگاه سنتی ممکن است تستر زمانی وارد فرآیند شود که بخش عمده‌ای از نرم افزار توسعه پیدا کرده باشد.

اما این موضوع به این معنا نیست که تستر نباید پیش از مرحله Testing فعالیتی داشته باشد.

یک تیم حرفه‌ای می‌تواند تستر را از مراحل اولیه درگیر کند تا تستر بتواند:

• نیازمندی‌ها را بررسی کند.
• ابهام‌های موجود را شناسایی کند.
• قابل تست بودن نیازمندی‌ها را بررسی کند.
• سناریوهای تست را آماده کند.
• موارد تست را طراحی کند.
• داده‌های تست را آماده کند.
• محیط تست را برنامه‌ریزی کند.

بنابراین، حتی در Waterfall نیز می‌توان فعالیت‌های آماده‌سازی تست را پیش از رسیدن رسمی پروژه به مرحله Testing آغاز کرد.

مزایای Waterfall

Waterfall در شرایط مناسب می‌تواند مزایایی داشته باشد.

ساختار مشخص: مراحل پروژه و ترتیب انجام فعالیت‌ها نسبتاً واضح هستند و اعضای تیم می‌دانند پروژه در چه مرحله‌ای قرار دارد.

مستندسازی مناسب: در بسیاری از پروژه‌های مبتنی بر Waterfall، مستندات نقش مهمی دارند و می‌توانند برای پروژه‌هایی که نیازمند کنترل و مستندسازی دقیق هستند مفید باشند.

برنامه‌ریزی قابل پیش‌بینی‌تر: اگر نیازمندی‌ها نسبتاً ثابت باشند، برنامه‌ریزی زمان و منابع می‌تواند ساده‌تر باشد.

مناسب برای پروژه‌های با نیازمندی‌های پایدار: اگر تغییرات در طول پروژه کم باشند و بخش زیادی از نیازمندی‌ها از ابتدا مشخص باشند، ساختار مرحله‌ای Waterfall می‌تواند قابل استفاده باشد.

معایب Waterfall

در مقابل، Waterfall محدودیت‌هایی نیز دارد.

انعطاف‌پذیری کمتر در برابر تغییرات: اگر نیازمندی‌ها در طول پروژه تغییر کنند، اعمال این تغییرات می‌تواند دشوار و پرهزینه باشد.

بازخورد دیرهنگام: در برخی پروژه‌ها ممکن است کاربران یا مشتریان تا مراحل نسبتاً پایانی محصول واقعی را مشاهده نکنند. در نتیجه، برخی مشکلات یا اختلاف برداشت‌ها دیر شناسایی می‌شوند.

ریسک بیشتر در پروژه‌های نامشخص: اگر در ابتدای پروژه اطلاعات کافی درباره نیازهای واقعی کاربران وجود نداشته باشد، تصمیم‌های اولیه ممکن است بعداً نیازمند تغییر شوند.

احتمال کشف دیرهنگام برخی مشکلات: اگر تست عملی عمدتاً پس از Development انجام شود، بعضی مشکلات ممکن است نسبتاً دیر شناسایی شوند.

Waterfall برای چه پروژه‌هایی مناسب‌تر است؟

Waterfall معمولاً زمانی می‌تواند گزینه مناسبی باشد که:

• نیازمندی‌ها نسبتاً ثابت و مشخص باشند.
• تغییرات مورد انتظار کم باشند.
• پروژه نیازمند مستندسازی و کنترل دقیق باشد.
• الزامات قانونی یا قراردادی مشخصی وجود داشته باشد.
• امکان برنامه‌ریزی نسبتاً دقیق از ابتدا وجود داشته باشد.

البته مناسب بودن یک مدل به شرایط واقعی پروژه بستگی دارد و نمی‌توان گفت Waterfall همیشه برای یک نوع خاص از پروژه بهترین انتخاب است.

یک مثال ساده

فرض کنید یک سازمان قصد دارد نرم افزاری برای مدیریت یک فرآیند مشخص داخلی ایجاد کند و قوانین و نیازمندی‌های آن از قبل به‌خوبی مشخص شده‌اند.

در چنین شرایطی ممکن است تیم ابتدا تمام نیازمندی‌ها را تحلیل و مستند کند، سپس طراحی را انجام دهد، بعد وارد Development شود و در ادامه نرم افزار را به تیم Testing تحویل دهد.

در این حالت، ساختار مرحله‌ای Waterfall می‌تواند به تیم کمک کند فرآیند را با مراحل و خروجی‌های مشخص مدیریت کند.

اما اگر در طول پروژه مشخص شود که کاربران نیازهای کاملاً متفاوتی دارند، تغییر این نیازمندی‌ها در یک فرآیند کاملاً آبشاری می‌تواند دشوارتر باشد.

نکته: Waterfall به این معنا نیست که هیچ بازگشتی به مراحل قبلی وجود ندارد. در پروژه‌های واقعی ممکن است در صورت شناسایی مشکل یا تغییر مهم، تیم به مراحل قبلی بازگردد؛ اما ساختار اصلی مدل همچنان بر اجرای نسبتاً متوالی مراحل استوار است.

Waterfall از دید یک Tester

برای یک تستر، شناخت Waterfall اهمیت زیادی دارد؛ زیرا در این مدل معمولاً بخش زیادی از برنامه‌ریزی تست بر اساس نیازمندی‌ها و طراحی‌هایی انجام می‌شود که پیش از شروع Testing مشخص شده‌اند.

تستر باید از همان مراحل اولیه تا حد امکان نیازمندی‌ها را بررسی کند و سپس بر اساس آن‌ها سناریوهای تست، موارد تست و داده‌های تست را آماده کند.

در مرحله Testing نیز تستر باید بررسی کند که نرم افزار توسعه‌یافته با نیازمندی‌ها و معیارهای مورد انتظار مطابقت دارد.

بنابراین، اگرچه Testing در Waterfall معمولاً یک مرحله مشخص پس از Development است، مشارکت تستر می‌تواند از مراحل اولیه چرخه توسعه آغاز شود.

مدل بعدی که ارتباط بسیار جالبی میان مراحل توسعه و مراحل تست ایجاد می‌کند، V-Model است؛ مدلی که برای درک جایگاه تست در SDLC اهمیت ویژه‌ای دارد.

مدل V-Model در SDLC

V-Model یا مدل V یکی از مدل‌های توسعه نرم افزار است که ارتباط میان مراحل توسعه و فعالیت‌های تست را به شکل مشخصی نشان می‌دهد.

نام این مدل از شکل کلی آن گرفته شده است. در یک طرف V، فعالیت‌های مربوط به تحلیل و طراحی قرار می‌گیرند و در طرف دیگر، فعالیت‌های مربوط به تست قرار دارند.

نمای ساده V-Model را می‌توان به شکل زیر در نظر گرفت:

Requirements → System Design → Architecture Design → Module Design

و سپس:

Module Testing → Integration Testing → System Testing → Acceptance Testing

البته جزئیات و نام‌گذاری مراحل V-Model ممکن است در منابع و سازمان‌های مختلف کمی متفاوت باشد، اما ایده اصلی ثابت است:

هر مرحله از توسعه، با یک سطح یا نوع مشخص از تست ارتباط دارد.

چرا V-Model ایجاد شد؟

یکی از محدودیت‌های رویکردهای سنتی این بود که تست ممکن بود عمدتاً پس از پایان توسعه آغاز شود. در چنین شرایطی، بعضی مشکلات ممکن است نسبتاً دیر شناسایی شوند.

V-Model تلاش می‌کند این دیدگاه را تغییر دهد و برنامه‌ریزی و طراحی تست را از مراحل اولیه توسعه در نظر بگیرد.

برای مثال، وقتی نیازمندی‌های سیستم در حال تحلیل هستند، تیم تست نیز می‌تواند از همان زمان به این فکر کند که چگونه باید برآورده شدن این نیازمندی‌ها را بررسی کند.

بنابراین، تست در V-Model فعالیتی نیست که فقط بعد از پایان کدنویسی به آن فکر شود.

ساختار V-Model چگونه است؟

اگر مدل را به صورت ساده نمایش دهیم، می‌توان آن را این‌گونه در نظر گرفت:

Requirements
↓
System Design
↓
Architecture Design
↓
Module Design
↓
Development

سپس در سمت دیگر:

Module Testing
↑
Integration Testing
↑
System Testing
↑
Acceptance Testing

در واقع، سمت چپ بیشتر با تعریف و طراحی سیستم ارتباط دارد و سمت راست با تأیید و ارزیابی خروجی این مراحل.

ارتباط مراحل توسعه و تست در V-Model

یکی از مهم‌ترین نکات V-Model، ارتباط میان مراحل توسعه و سطوح مختلف تست است.

مرحله توسعه	فعالیت تست مرتبط
Requirement Analysis	Acceptance Testing
System Design	System Testing
Architecture Design	Integration Testing
Module Design	Module / Unit Testing
Development	پیاده‌سازی کد و آماده‌سازی برای اجرای تست‌ها

برای مثال، هنگام تحلیل نیازمندی‌ها، تیم می‌تواند معیارهایی را مشخص کند که بعداً در Acceptance Testing برای بررسی پذیرش سیستم مورد استفاده قرار گیرند.

همچنین طراحی معماری سیستم می‌تواند مبنایی برای برنامه‌ریزی Integration Testing باشد.

به این ترتیب، تست به صورت مستقیم با تصمیم‌ها و خروجی‌های مراحل توسعه ارتباط پیدا می‌کند.

نقش Tester در V-Model

V-Model از دید یک تستر (Tester) اهمیت زیادی دارد؛ زیرا تستر از مراحل اولیه پروژه می‌تواند در فرآیند مشارکت داشته باشد.

برای مثال، تستر می‌تواند در مرحله Requirement Analysis:

• نیازمندی‌ها را از نظر قابل تست بودن بررسی کند.
• ابهام‌ها و تناقض‌ها را شناسایی کند.
• معیارهای پذیرش را بررسی کند.
• سناریوهای تست را در سطح اولیه مشخص کند.

در مرحله Design نیز می‌تواند درباره قابلیت تست (Testability) سیستم بازخورد بدهد و برای سطوح مختلف تست برنامه‌ریزی کند.

در نتیجه، تستر مجبور نیست تا زمان آماده شدن نرم افزار منتظر بماند.

آیا در V-Model تست فقط بعد از Development انجام می‌شود؟

از نظر اجرای تست، بسیاری از فعالیت‌های تست پس از آماده شدن بخش مربوطه از نرم افزار انجام می‌شوند.

اما نکته مهم این است که برنامه‌ریزی تست می‌تواند همزمان با مراحل توسعه انجام شود.

برای مثال، زمانی که تیم در حال تحلیل نیازمندی‌ها است، تیم تست می‌تواند معیارهای پذیرش و روش بررسی آن نیازمندی‌ها را مشخص کند.

پس باید بین این دو مفهوم تفاوت قائل شویم:

• Test Planning و Test Design می‌توانند از مراحل اولیه آغاز شوند.
• Test Execution زمانی انجام می‌شود که نرم افزار یا بخش مورد نظر برای اجرا آماده باشد.

این یکی از مفاهیم کلیدی V-Model است.

مزایای V-Model

تمرکز بیشتر بر کیفیت از مراحل اولیه: فعالیت‌های تست از همان مراحل اولیه در نظر گرفته می‌شوند و کیفیت فقط به پایان Development موکول نمی‌شود.

ارتباط مشخص بین توسعه و تست: هر مرحله توسعه با یک سطح یا نوع تست مرتبط می‌شود و این موضوع ساختار فرآیند تست را واضح‌تر می‌کند.

شناسایی زودهنگام مشکلات: بررسی نیازمندی‌ها و طراحی تست در مراحل اولیه می‌تواند به شناسایی برخی مشکلات پیش از اجرای نرم افزار کمک کند.

مناسب برای پروژه‌های با نیازمندی‌های نسبتاً پایدار: در پروژه‌هایی که نیازمندی‌ها مشخص و تغییرات محدود هستند، ساختار V-Model می‌تواند مفید باشد.

معایب V-Model

V-Model نیز مانند Waterfall محدودیت‌هایی دارد.

انعطاف‌پذیری محدود در برابر تغییرات: اگر نیازمندی‌ها در طول پروژه مرتباً تغییر کنند، بازگشت و اصلاح مراحل قبلی می‌تواند هزینه‌بر باشد.

نیاز به مشخص بودن نیازمندی‌ها: برای استفاده مؤثر از این مدل، بهتر است نیازمندی‌ها در مراحل اولیه تا حد مناسبی مشخص باشند.

مناسب نبودن برای همه پروژه‌های پویا: در محصولاتی که نیازهای کاربران دائماً تغییر می‌کنند، ممکن است رویکردهای تکرارشونده و چابک انعطاف بیشتری ایجاد کنند.

احتمال ایجاد مستندات و فعالیت‌های اولیه زیاد: در برخی پروژه‌ها، ساختار دقیق V-Model می‌تواند نیازمند برنامه‌ریزی و مستندسازی قابل توجهی باشد.

V-Model برای چه پروژه‌هایی مناسب‌تر است؟

V-Model می‌تواند برای پروژه‌هایی مناسب باشد که:

• نیازمندی‌های نسبتاً مشخص و پایدار دارند.
• کیفیت و قابلیت اطمینان اهمیت بالایی دارد.
• به فرآیند تست ساختاریافته نیاز دارند.
• امکان تغییرات گسترده در طول توسعه کم است.
• مستندسازی و ردیابی نیازمندی‌ها اهمیت دارد.

در برخی حوزه‌های حساس و قانون‌مند نیز رویکردهای ساختاریافته‌ای مانند V-Model می‌توانند مورد توجه قرار گیرند، زیرا ارتباط میان نیازمندی‌ها، توسعه و تست را قابل ردیابی‌تر می‌کنند.

V-Model از دید یک تستر

V-Model یکی از مدل‌هایی است که نقش تستر را از یک اجراکننده تست در پایان پروژه به یک عضو فعال‌تر در چرخه توسعه نزدیک می‌کند.

تستر از همان مراحل اولیه می‌تواند درباره قابل تست بودن نیازمندی‌ها، معیارهای پذیرش، طراحی سیستم و روش‌های ارزیابی بازخورد دهد.

به همین دلیل، شناخت V-Model برای درک این موضوع مفید است که تست نرم افزار فقط اجرای Test Case پس از پایان کدنویسی نیست؛ بلکه برنامه‌ریزی و طراحی فعالیت‌های تست نیز می‌تواند همزمان با مراحل توسعه انجام شود.

در بخش بعدی به سراغ Agile و ارتباط آن با SDLC می‌رویم؛ رویکردی که در آن توسعه و تست به جای دنبال کردن یک مسیر طولانی و یک‌باره، در چرخه‌های کوتاه و تکرارشونده انجام می‌شوند.

Agile و SDLC

Agile یا توسعه چابک رویکردی برای توسعه نرم افزار است که بر تحویل تدریجی، همکاری تیمی، بازخورد مداوم و توانایی سازگاری با تغییرات تأکید دارد.

در مقایسه با مدل‌هایی مانند Waterfall که مراحل توسعه معمولاً به صورت متوالی و نسبتاً طولانی انجام می‌شوند، در رویکرد Agile فعالیت‌های مختلف SDLC در چرخه‌های کوتاه و تکرارشونده انجام می‌شوند.

به همین دلیل، در Agile معمولاً تیم تلاش نمی‌کند تمام محصول را از ابتدا تا انتها طراحی و توسعه دهد و سپس برای اولین بار آن را در اختیار کاربر قرار دهد. بلکه محصول به بخش‌های کوچک‌تر تقسیم می‌شود و هر بخش در یک چرخه کوتاه توسعه، تست و آماده انتشار می‌شود.

Agile چه تفاوتی با Waterfall دارد؟

برای درک بهتر، فرض کنید قرار است یک فروشگاه اینترنتی ایجاد شود.

در یک رویکرد آبشاری، ممکن است تیم ابتدا تمام نیازمندی‌ها را تحلیل کند، سپس طراحی کامل سیستم را انجام دهد، بعد وارد توسعه شود و در ادامه تست و استقرار را انجام دهد.

اما در Agile، ممکن است تیم ابتدا یک بخش کوچک و باارزش از محصول را انتخاب کند؛ برای مثال:

ثبت‌نام و ورود کاربران

سپس فعالیت‌های لازم برای این بخش انجام شوند:

Requirement → Design → Development → Testing → Deployment

پس از دریافت بازخورد، تیم به سراغ قابلیت بعدی می‌رود؛ برای مثال:

Product Catalog → Development → Testing → Deployment

و این چرخه برای قابلیت‌های بعدی نیز تکرار می‌شود.

بنابراین، در Agile کل SDLC می‌تواند بارها و در مقیاس‌های کوچک‌تر تکرار شود.

Iteration در Agile چیست؟

یکی از مفاهیم مهم در توسعه چابک، تکرار (Iteration) است.

Iteration یک چرخه کوتاه توسعه است که در آن تیم مجموعه‌ای از کارهای مشخص را انجام می‌دهد و در پایان، خروجی قابل ارزیابی ارائه می‌کند.

در برخی روش‌های Agile، مانند Scrum، این چرخه‌ها معمولاً Sprint نامیده می‌شوند.

برای مثال، یک تیم ممکن است یک Sprint دو هفته‌ای داشته باشد و در طول آن:

• نیازمندی‌های انتخاب‌شده را بررسی کند.
• طراحی مورد نیاز را انجام دهد.
• قابلیت‌ها را توسعه دهد.
• تست‌ها را اجرا کند.
• باگ‌ها را برطرف کند.
• خروجی قابل استفاده یا قابل ارزیابی ارائه دهد.

سپس در چرخه بعدی، مجموعه دیگری از قابلیت‌ها انتخاب و توسعه داده می‌شوند.

جایگاه تست در Agile

یکی از تفاوت‌های مهم Agile با رویکردهای سنتی این است که تست معمولاً به عنوان مرحله‌ای جدا و طولانی در انتهای پروژه قرار نمی‌گیرد.

تست می‌تواند همزمان با توسعه هر قابلیت انجام شود.

برای مثال، اگر تیم در یک Sprint قابلیت «افزودن محصول به سبد خرید» را توسعه دهد، تستر نیز می‌تواند در همان چرخه:

• نیازمندی را بررسی کند.
• سناریوهای تست را طراحی کند.
• موارد تست را آماده کند.
• داده‌های تست را آماده کند.
• قابلیت را تست کند.
• باگ‌ها را گزارش کند.
• پس از اصلاح، تست مجدد انجام دهد.
• در صورت نیاز تست بازگشتی انجام دهد.

در نتیجه، توسعه و تست به جای اینکه ماه‌ها از یکدیگر فاصله داشته باشند، در چرخه‌های کوتاه در کنار یکدیگر انجام می‌شوند.

نقش Tester در Agile

در Agile، تستر معمولاً عضوی از تیم توسعه محصول است و همکاری او با Developer، Product Owner و سایر اعضای تیم اهمیت زیادی دارد.

تستر می‌تواند از مراحل اولیه کار روی یک قابلیت مشارکت داشته باشد و درباره مواردی مانند موارد زیر بازخورد ارائه دهد:

• قابل تست بودن نیازمندی
• معیارهای پذیرش
• سناریوهای مختلف
• حالت‌های مرزی
• ریسک‌های کیفیت
• داده‌های مورد نیاز برای تست
• شرایط غیرعادی و نامعتبر

برای مثال، فرض کنید یک User Story درباره ورود کاربر به سیستم وجود دارد. تستر می‌تواند پیش از شروع توسعه درباره مواردی مانند رمز عبور اشتباه، حساب غیرفعال، ورود چندباره ناموفق و محدودیت تعداد تلاش‌ها سؤال مطرح کند.

این موضوع باعث می‌شود بخشی از مشکلات احتمالی پیش از تبدیل شدن به باگ شناسایی شوند.

آیا در Agile تست فقط در پایان Sprint انجام می‌شود؟

خیر.

این یکی از برداشت‌های اشتباه درباره Agile است.

در یک تیم Agile مناسب، تست می‌تواند در طول فرآیند توسعه یک قابلیت انجام شود، نه اینکه الزاماً همه توسعه انجام شود و تستر فقط در آخرین روز Sprint وارد عمل شود.

برای مثال، وقتی بخشی از یک قابلیت آماده می‌شود، تستر می‌تواند همان بخش را بررسی کند و نتیجه را سریعاً به تیم بازگرداند.

در این حالت، اگر مشکلی وجود داشته باشد، Developer می‌تواند در همان چرخه آن را اصلاح کند.

بازخورد مداوم در Agile

یکی از ویژگی‌های مهم Agile، بازخورد مداوم (Continuous Feedback) است.

بازخورد می‌تواند از منابع مختلفی دریافت شود:

• تستر
• Developer
• Product Owner
• کاربران
• مشتری
• داده‌های استفاده از محصول

این بازخوردها می‌توانند باعث تغییر در نیازمندی‌ها، اولویت‌ها یا حتی طراحی محصول شوند.

به همین دلیل، Agile برای محیط‌هایی که نیازهای کاربران و شرایط کسب‌وکار مرتباً تغییر می‌کنند، می‌تواند انعطاف‌پذیری بیشتری نسبت به مدل‌های کاملاً مرحله‌ای ایجاد کند.

مزایای Agile در SDLC

انعطاف‌پذیری بیشتر: تیم می‌تواند بر اساس تغییر نیازهای کسب‌وکار، اولویت‌ها را تغییر دهد.

بازخورد سریع‌تر: کاربران و ذی‌نفعان می‌توانند زودتر خروجی‌های واقعی محصول را مشاهده و درباره آن‌ها بازخورد دهند.

شناسایی زودتر مشکلات: توسعه و تست در چرخه‌های کوتاه انجام می‌شوند و مشکلات می‌توانند زودتر شناسایی شوند.

تحویل تدریجی محصول: لازم نیست تمام قابلیت‌های محصول برای ارائه اولین نسخه کامل آماده باشند.

همکاری بیشتر تیمی: Developer، Tester، Product Owner و سایر اعضای تیم در طول چرخه توسعه همکاری نزدیک‌تری دارند.

محدودیت‌ها و چالش‌های Agile

Agile نیز مانند هر رویکرد دیگری برای همه شرایط بهترین انتخاب نیست.

اگر تیم تجربه کافی نداشته باشد، تغییرات مداوم ممکن است باعث بی‌نظمی یا ایجاد بدهی فنی شوند.

همچنین اگر نیازمندی‌ها بدون اولویت‌بندی مناسب مرتباً تغییر کنند، برنامه‌ریزی و کنترل محدوده پروژه می‌تواند دشوار شود.

از طرف دیگر، Agile به معنای حذف مستندات، برنامه‌ریزی یا فرآیندهای مشخص نیست. تیم همچنان به مستندات و برنامه‌ریزی مناسب نیاز دارد، اما این فعالیت‌ها متناسب با نیاز پروژه و به شکل انعطاف‌پذیرتری انجام می‌شوند.

Agile از دید یک Tester

برای یک تستر، کار در محیط Agile به معنای اجرای سریع‌تر Test Caseها نیست؛ بلکه نیازمند همکاری مداوم با تیم و مشارکت زودهنگام در فرآیند توسعه است.

تستر باید بتواند:

• نیازمندی‌ها را تحلیل کند.
• ابهام‌ها را زود مطرح کند.
• ریسک‌های کیفیت را شناسایی کند.
• سناریوهای تست مناسب طراحی کند.
• تست را همگام با توسعه انجام دهد.
• با Developer همکاری نزدیک داشته باشد.
• تست بازگشتی را متناسب با تغییرات انجام دهد.
• از Automation Testing در بخش‌های مناسب استفاده کند.

به همین دلیل، در Agile مرز بین «مرحله توسعه» و «مرحله تست» نسبت به مدل‌های سنتی کمتر می‌شود.

نکته مهم: Agile به این معنا نیست که دیگر SDLC وجود ندارد. برعکس، همان فعالیت‌های اصلی مانند Requirement، Design، Development، Testing و Deployment همچنان وجود دارند؛ اما این فعالیت‌ها معمولاً در چرخه‌های کوتاه‌تر، تکرارشونده‌تر و انعطاف‌پذیرتر انجام می‌شوند.

در بخش بعدی، مدل‌های Waterfall، V-Model و Agile را در کنار یکدیگر مقایسه می‌کنیم تا مشخص شود هرکدام چه تفاوتی در نحوه اجرای SDLC و فعالیت‌های تست دارند.

مقایسه مدل‌های SDLC

تا اینجا سه رویکرد مهم برای اجرای چرخه توسعه نرم افزار را بررسی کردیم: Waterfall، V-Model و Agile.

هر سه رویکرد از فعالیت‌هایی مانند تحلیل نیازمندی‌ها، طراحی، توسعه و تست استفاده می‌کنند، اما نحوه اجرای این فعالیت‌ها و میزان تکرار آن‌ها متفاوت است.

مقایسه کلی Waterfall، V-Model و Agile

ویژگی	Waterfall	V-Model	Agile
نحوه اجرای مراحل	عمدتاً متوالی	متوالی و ساختاریافته	تکرارشونده و تدریجی
تغییر نیازمندی‌ها	دشوارتر	دشوارتر	انعطاف‌پذیرتر
زمان دریافت بازخورد	معمولاً دیرتر	معمولاً دیرتر	سریع‌تر و مداوم
جایگاه تست	معمولاً پس از Development	از ابتدا برنامه‌ریزی می‌شود	همگام با توسعه
مشارکت تستر	می‌تواند از مراحل اولیه باشد	از مراحل اولیه پررنگ است	مستمر و نزدیک به تیم
تحویل محصول	معمولاً در مراحل پایانی	معمولاً پس از تکمیل مراحل	تدریجی و در چرخه‌های کوتاه
مناسب برای	نیازمندی‌های نسبتاً ثابت	پروژه‌های ساختاریافته و حساس به کیفیت	نیازمندی‌های متغیر و محصولاتی با بازخورد مداوم

تفاوت در نحوه اجرای SDLC

در Waterfall، مراحل SDLC معمولاً به شکل نسبتاً خطی دنبال می‌شوند:

Requirement → Design → Development → Testing → Deployment

در V-Model نیز مراحل توسعه ساختار نسبتاً متوالی دارند، اما برای هر بخش از فرآیند توسعه، فعالیت تست متناظر در نظر گرفته می‌شود:

Development Activities ↔ Testing Activities

در Agile، همین فعالیت‌ها در چرخه‌های کوتاه بارها تکرار می‌شوند:

Requirement → Design → Development → Testing → Deployment

سپس چرخه بعدی آغاز می‌شود و بخش دیگری از محصول توسعه پیدا می‌کند.

تفاوت جایگاه تست

یکی از مهم‌ترین تفاوت‌ها برای یک تستر نرم افزار، نحوه قرار گرفتن Testing در این رویکردها است.

در Waterfall، تست معمولاً به عنوان مرحله‌ای مشخص پس از Development دیده می‌شود.

در V-Model، تست از همان مراحل اولیه برنامه‌ریزی و طراحی می‌شود و هر مرحله توسعه با یک سطح تست ارتباط دارد.

در Agile، تست بخشی از چرخه مداوم توسعه است و تستر می‌تواند در طول هر چرخه کوتاه، همزمان با توسعه فعالیت کند.

بنابراین می‌توان این تفاوت را به شکل ساده این‌گونه خلاصه کرد:

• Waterfall: توسعه → سپس تست
• V-Model: توسعه و برنامه‌ریزی تست به صورت متناظر
• Agile: توسعه و تست به صورت همگام و تکرارشونده

کدام مدل SDLC بهتر است؟

نمی‌توان گفت یک مدل SDLC در تمام پروژه‌ها از مدل‌های دیگر بهتر است.

انتخاب مدل مناسب به شرایط پروژه بستگی دارد.

برای مثال، اگر نیازمندی‌ها از ابتدا نسبتاً مشخص و پایدار باشند، یک رویکرد ساختاریافته مانند Waterfall یا V-Model می‌تواند قابل استفاده باشد.

اگر پروژه به تست ساختاریافته، ردیابی نیازمندی‌ها و کنترل دقیق کیفیت نیاز داشته باشد، V-Model می‌تواند مزیت‌هایی داشته باشد.

در مقابل، اگر نیازهای کاربران مرتباً تغییر کنند و دریافت بازخورد سریع اهمیت داشته باشد، Agile معمولاً انعطاف‌پذیری بیشتری ایجاد می‌کند.

بنابراین سؤال بهتر این نیست که:

«بهترین مدل SDLC کدام است؟»

بلکه باید پرسید:

«کدام مدل SDLC با شرایط، ریسک‌ها و نیازهای این پروژه سازگاری بیشتری دارد؟»

آیا ممکن است یک سازمان از ترکیب رویکردها استفاده کند؟

بله.

در دنیای واقعی، فرآیند توسعه بسیاری از سازمان‌ها دقیقاً مطابق یک مدل نظری اجرا نمی‌شود. ممکن است یک تیم برخی ویژگی‌های رویکردهای مختلف را با توجه به نیاز خود ترکیب کند.

برای مثال، ممکن است یک سازمان از روش‌های چابک برای مدیریت توسعه استفاده کند، اما برای بخش‌هایی مانند مستندسازی، کنترل تغییرات یا تست‌های خاص، فرآیندهای ساختاریافته‌تری داشته باشد.

بنابراین مدل‌های SDLC را بهتر است به عنوان الگوهایی برای سازمان‌دهی فرآیند توسعه در نظر بگیریم، نه قوانینی که تمام پروژه‌ها الزاماً باید دقیقاً مطابق آن‌ها اجرا شوند.

نکته: شناخت مدل SDLC برای تستر اهمیت زیادی دارد؛ زیرا روش توسعه پروژه روی زمان‌بندی تست، نحوه همکاری با تیم، برنامه‌ریزی تست، مدیریت تغییرات و میزان استفاده از تست خودکار تأثیر می‌گذارد.

تا اینجا با SDLC و مدل‌های اصلی آن آشنا شدیم. در بخش بعدی، یکی از مفاهیم بسیار مهم برای تسترها را بررسی می‌کنیم: تفاوت SDLC و STLC.

ارتباط SDLC و STLC چیست؟

SDLC و STLC هر دو به فرآیند توسعه و تست نرم افزار مربوط هستند، اما دامنه و هدف آن‌ها یکسان نیست.

SDLC (Software Development Life Cycle) به چرخه توسعه نرم افزار اشاره دارد و کل فرآیند تبدیل یک نیاز یا ایده به نرم افزار، از برنامه‌ریزی و تحلیل نیازمندی‌ها تا توسعه، تست، استقرار و نگهداری را در بر می‌گیرد.

در مقابل، STLC (Software Testing Life Cycle) بر چرخه تست نرم افزار و فعالیت‌هایی تمرکز دارد که برای برنامه‌ریزی، طراحی، اجرا و ارزیابی تست انجام می‌شوند.

SDLC درباره چرخه کلی توسعه و تکامل نرم افزار است، در حالی که STLC روی فرآیند انجام تست نرم افزار تمرکز دارد.

رابطه SDLC و STLC

STLC را می‌توان چرخه‌ای تخصصی برای سازمان‌دهی فعالیت‌های تست در چارچوب کلی توسعه نرم افزار در نظر گرفت.

برای مثال، در SDLC ممکن است تیم از مرحله تحلیل نیازمندی‌ها به طراحی، توسعه، تست و سپس استقرار برسد. در همین فرآیند، تیم تست نیز فعالیت‌های تخصصی خود را برای برنامه‌ریزی، طراحی و اجرای تست انجام می‌دهد.

بنابراین، این دو چرخه کاملاً از یکدیگر جدا نیستند و فعالیت‌های STLC با فعالیت‌های توسعه و تحویل نرم افزار در چارچوب کلی SDLC ارتباط دارند.

تفاوت SDLC و STLC به زبان ساده

اگر بخواهیم تفاوت آن‌ها را بسیار ساده بیان کنیم:

SDLC:
«نرم افزار را چگونه از ایده به محصول قابل استفاده تبدیل کنیم؟»

STLC:
«فعالیت‌های تست را چگونه برای ارزیابی کیفیت نرم افزار سازمان‌دهی و اجرا کنیم؟»

به همین دلیل، SDLC دامنه گسترده‌تری دارد و موضوعاتی مانند برنامه‌ریزی، نیازمندی‌ها، طراحی، توسعه، تست، استقرار و نگهداری را شامل می‌شود؛ در حالی که STLC بر فعالیت‌های مرتبط با تست تمرکز دارد.

آیا برای یادگیری STLC باید SDLC را بدانیم؟

آشنایی با SDLC به درک بهتر STLC کمک می‌کند، زیرا تست نرم افزار در خلأ انجام نمی‌شود و بخشی از یک فرآیند بزرگ‌تر توسعه محصول است.

برای مثال، وقتی تستر می‌داند نیازمندی‌ها در کجای چرخه توسعه شکل می‌گیرند، توسعه چه زمانی انجام می‌شود و محصول چگونه به محیط واقعی می‌رسد، ارتباط فعالیت‌های مختلف تست با فرآیند توسعه را بهتر درک می‌کند.

اگر می‌خواهید خود STLC، مراحل آن و فعالیت‌های تست در هر مرحله را به صورت کامل بررسی کنید، می‌توانید به مقاله اختصاصی چرخه تست نرم افزار (STLC) در سایت مراجعه کنید.

نکته: هدف این بخش فقط مشخص کردن رابطه SDLC و STLC است. برای جلوگیری از تکرار مطالب، جزئیات مراحل و فرآیند STLC را در مقاله اختصاصی آن بررسی می‌کنیم.

اکنون که تفاوت و ارتباط SDLC و STLC مشخص شد، در بخش بعدی با یک مثال کامل از چرخه توسعه نرم افزار همراه می‌شویم تا تمام مراحلی را که بررسی کردیم در یک پروژه واقعی‌تر ببینیم.

مثال کامل چرخه توسعه نرم افزار؛ فروشگاه اینترنتی

برای درک بهتر مفهوم چرخه توسعه نرم افزار (SDLC)، فرض کنید یک شرکت قصد دارد یک فروشگاه اینترنتی راه‌اندازی کند.

هدف پروژه این است که کاربران بتوانند محصولات را مشاهده کنند، آن‌ها را به سبد خرید اضافه کنند، سفارش ثبت کنند و هزینه سفارش را به صورت آنلاین پرداخت کنند.

حالا ببینیم این پروژه چگونه می‌تواند مراحل مختلف SDLC را طی کند.

۱. برنامه‌ریزی (Planning)

در ابتدا تیم باید مشخص کند چرا قرار است این نرم افزار ساخته شود و چه منابعی برای اجرای پروژه در اختیار دارد.

برای مثال، در این مرحله موارد زیر بررسی می‌شوند:

• هدف پروژه ایجاد یک فروشگاه اینترنتی است.
• کاربران باید بتوانند محصولات را مشاهده و خریداری کنند.
• قابلیت‌های مورد نیاز نسخه اولیه مشخص می‌شوند.
• اعضای تیم و مسئولیت‌های اصلی آن‌ها مشخص می‌شود.
• زمان و هزینه تقریبی پروژه بررسی می‌شود.
• ریسک‌های مهم پروژه شناسایی می‌شوند.

همچنین ممکن است تیم تصمیم بگیرد ابتدا یک نسخه اولیه با قابلیت‌های اصلی ایجاد کند و سپس امکانات بیشتری را در نسخه‌های بعدی اضافه کند.

۲. تحلیل نیازمندی‌ها (Requirement Analysis)

در مرحله بعد، نیازهای کاربران و کسب‌وکار با جزئیات بیشتری بررسی و مشخص می‌شوند.

برای مثال، یکی از نیازمندی‌ها می‌تواند این باشد:

«کاربر باید بتواند یک محصول موجود را به سبد خرید اضافه کند.»

اما برای تبدیل این نیازمندی به یک رفتار دقیق و قابل تست، باید سؤالات بیشتری پاسخ داده شوند:

• اگر محصول موجود نباشد چه اتفاقی رخ دهد؟
• آیا کاربر مهمان می‌تواند محصول را به سبد خرید اضافه کند؟
• حداکثر تعداد قابل سفارش چقدر است؟
• اگر موجودی محصول تغییر کند، چه اتفاقی برای سبد خرید می‌افتد؟
• قیمت محصول چه زمانی در سبد خرید ثبت می‌شود؟

در این مرحله، تستر نیز می‌تواند نیازمندی‌ها را از نظر وضوح، کامل بودن و قابل تست بودن (Testability) بررسی کند و ابهام‌های موجود را پیش از شروع توسعه مطرح کند.

۳. طراحی (Design)

پس از مشخص شدن نیازمندی‌ها، تیم تصمیم می‌گیرد نرم افزار چگونه ساخته و اجزای مختلف آن چگونه با یکدیگر ارتباط داشته باشند.

برای مثال، در این مرحله ممکن است موارد زیر طراحی شوند:

• ساختار کلی سیستم
• پایگاه داده (Database) و جداول مورد نیاز
• رابط‌های برنامه‌نویسی کاربردی (API) مربوط به محصولات و سفارش‌ها
• رابط کاربری فروشگاه
• نحوه ارتباط بخش Frontend و Backend
• فرآیند ثبت سفارش
• فرآیند پرداخت

تستر نیز می‌تواند طراحی را از نظر قابل تست بودن (Testability) بررسی کند؛ برای مثال مشخص کند آیا امکان تست مستقل APIهای مختلف وجود دارد یا آیا سیستم اطلاعات کافی برای بررسی خطاها و رفتارهای غیرمنتظره ارائه می‌دهد.

۴. توسعه (Development)

در این مرحله، طراحی‌ها و نیازمندی‌ها به کد و اجزای واقعی نرم افزار تبدیل می‌شوند.

توسعه‌دهندگان (Developers) قابلیت‌هایی مانند موارد زیر را پیاده‌سازی می‌کنند:

• ثبت‌نام و ورود
• نمایش محصولات
• جست‌وجوی محصول
• افزودن محصول به سبد خرید
• ثبت سفارش
• پرداخت

همزمان با توسعه، تستر می‌تواند سناریوهای تست و موارد تست را آماده کند و با تیم توسعه درباره رفتار مورد انتظار قابلیت‌های جدید همکاری داشته باشد.

۵. تست (Testing)

پس از آماده شدن قابلیت‌ها، نرم افزار از جنبه‌های مختلف مورد ارزیابی قرار می‌گیرد.

برای مثال، برای قابلیت «افزودن محصول به سبد خرید» می‌توان موارد زیر را بررسی کرد:

• افزودن یک محصول موجود
• افزودن چند عدد از یک محصول
• تلاش برای افزودن محصول ناموجود
• تلاش برای اضافه کردن تعداد بیشتر از موجودی
• افزودن محصول توسط کاربر مهمان
• بررسی قیمت محصول در سبد خرید

بسته به نیاز پروژه، ممکن است تست‌های دیگری مانند تست رابط کاربری، تست API، تست یکپارچه‌سازی، تست سیستم، تست بازگشتی و تست کارایی نیز انجام شوند.

اگر مشکلی پیدا شود، تستر آن را به عنوان باگ (Bug) ثبت و پیگیری می‌کند. پس از اصلاح، تست مجدد انجام می‌شود و در صورت وجود احتمال تأثیر بر بخش‌های مرتبط، تست بازگشتی نیز انجام خواهد شد.

فرآیند کامل و جزئیات چرخه فعالیت‌های تست در STLC بررسی می‌شود و در این مقاله تمرکز بر جایگاه تست در چرخه کلی توسعه نرم افزار است.

۶. استقرار (Deployment)

پس از اینکه نسخه مورد نظر معیارهای لازم برای انتشار را برآورده کرد، نرم افزار در محیط مقصد مستقر می‌شود.

برای مثال، فروشگاه اینترنتی روی سرور قرار می‌گیرد و کاربران می‌توانند به آن دسترسی پیدا کنند.

پس از استقرار نیز ممکن است بررسی‌های اولیه مانند تست دود (Smoke Testing) انجام شود تا مشخص شود قابلیت‌های حیاتی مانند ورود، مشاهده محصولات و ثبت سفارش همچنان قابل استفاده هستند.

۷. نگهداری (Maintenance)

پس از انتشار فروشگاه، چرخه توسعه به پایان نمی‌رسد. ممکن است کاربران با مشکلات جدیدی مواجه شوند یا کسب‌وکار قابلیت‌های جدیدی درخواست کند.

برای مثال:

• امکان پرداخت با روش جدید اضافه شود.
• قابلیت تخفیف و کد تخفیف ایجاد شود.
• عملکرد جست‌وجوی محصولات بهبود پیدا کند.
• یک باگ در فرآیند پرداخت اصلاح شود.
• امنیت سیستم افزایش پیدا کند.

هر یک از این تغییرات می‌تواند دوباره نیازمند تحلیل، طراحی، توسعه، تست و استقرار باشد.

بنابراین، چرخه توسعه نرم افزار می‌تواند دوباره تکرار شود:

Requirement → Design → Development → Testing → Deployment → Maintenance

نقش تستر در کل این مثال

اگر از ابتدا تا انتهای این پروژه به نقش تستر نگاه کنیم، می‌بینیم که فعالیت او فقط به مرحله Testing محدود نمی‌شود.

• Planning: شناسایی ریسک‌های کیفیت و نیازهای اولیه تست.
• Requirement Analysis: بررسی نیازمندی‌ها از نظر ابهام، کامل بودن و قابل تست بودن.
• Design: ارائه بازخورد درباره Testability سیستم.
• Development: آماده‌سازی سناریوها، موارد تست و داده‌های تست و همکاری با Developer.
• Testing: اجرای تست‌ها و ثبت و پیگیری باگ‌ها.
• Deployment: بررسی قابلیت‌های مهم نسخه مستقرشده.
• Maintenance: تست تغییرات و باگ‌های اصلاح‌شده و انجام تست بازگشتی در صورت نیاز.

این مثال نشان می‌دهد که تست نرم افزار یک فعالیت جدا از چرخه توسعه نیست، بلکه در بخش‌های مختلف SDLC با فعالیت‌های توسعه و تصمیم‌های پروژه ارتباط دارد.

نکته: در یک پروژه واقعی، این مراحل الزاماً همیشه به صورت خطی و فقط یک بار انجام نمی‌شوند. در رویکردهایی مانند Agile و Iterative، همین چرخه می‌تواند برای قابلیت‌های مختلف، بارها و در دوره‌های کوتاه تکرار شود.

در بخش بعدی، به صورت مشخص‌تر بررسی می‌کنیم که نقش Tester در SDLC چیست و یک تستر در هر مرحله چه ارزش و مسئولیتی دارد.

نقش Tester در چرخه توسعه نرم افزار (SDLC)

یکی از برداشت‌های قدیمی درباره تستر (Tester) این است که وظیفه او زمانی شروع می‌شود که توسعه نرم افزار به پایان رسیده باشد و باید با اجرای Test Case به دنبال باگ بگردد.

در یک فرآیند توسعه مناسب، تستر می‌تواند از مراحل اولیه چرخه توسعه نرم افزار (SDLC) در پروژه مشارکت داشته باشد.

هدف از این مشارکت فقط پیدا کردن باگ نیست؛ تستر می‌تواند با بررسی نیازمندی‌ها، شناسایی ریسک‌ها و ارائه بازخورد در مراحل مختلف، به پیشگیری از مشکلات و افزایش کیفیت محصول کمک کند.

نقش Tester در هر مرحله از SDLC

نقش تستر بسته به مدل توسعه، نوع پروژه و ساختار تیم متفاوت است، اما می‌توان یک تصویر کلی از مشارکت او در مراحل مختلف SDLC ارائه کرد.

۱. نقش Tester در Planning

در مرحله برنامه‌ریزی (Planning)، تستر می‌تواند از دید کیفیت و ریسک به پروژه نگاه کند.

برای مثال، می‌تواند درباره موارد زیر بازخورد دهد:

• ریسک‌های مهم کیفیت
• پیچیدگی تست نرم افزار
• نیاز به محیط‌های مختلف تست
• نیاز به داده‌های تست
• نیاز به تست خودکار
• نیاز به تست‌های کارایی یا امنیت
• زمان و منابع مورد نیاز برای فعالیت‌های تست

برای مثال، اگر قرار باشد نرم افزاری برای تعداد بسیار زیادی کاربر همزمان توسعه داده شود، تستر می‌تواند از همان ابتدا نیاز به تست کارایی (Performance Testing) را مطرح کند.

۲. نقش Tester در Requirement Analysis

در مرحله تحلیل نیازمندی‌ها (Requirement Analysis)، تستر می‌تواند نیازمندی‌ها را از نظر وضوح، کامل بودن و قابل تست بودن بررسی کند.

تستر ممکن است سؤالاتی مانند این موارد مطرح کند:

• آیا رفتار مورد انتظار سیستم مشخص است؟
• آیا معیارهای پذیرش مشخص شده‌اند؟
• آیا حالت‌های مرزی در نظر گرفته شده‌اند؟
• آیا شرایط نامعتبر مشخص هستند؟
• آیا می‌توان بر اساس این نیازمندی مورد تست طراحی کرد؟

این مشارکت می‌تواند از تبدیل شدن ابهام‌های موجود در نیازمندی‌ها به مشکلات و باگ‌های آینده جلوگیری کند.

۳. نقش Tester در Design

در مرحله طراحی (Design)، تستر می‌تواند سیستم را از دید قابل تست بودن (Testability) بررسی کند.

برای مثال، تستر می‌تواند درباره موارد زیر بازخورد دهد:

• امکان تست مستقل اجزای سیستم
• دسترسی به APIهای مورد نیاز
• امکان ایجاد داده‌های تست
• قابلیت مشاهده و بررسی خطاها
• وجود Logging مناسب
• وابستگی‌های پیچیده بین اجزای سیستم

اگر طراحی سیستم از ابتدا Testability مناسبی داشته باشد، اجرای تست‌ها در مراحل بعدی ساده‌تر و قابل اطمینان‌تر خواهد بود.

۴. نقش Tester در Development

در مرحله توسعه (Development)، تستر می‌تواند همزمان با تیم توسعه برای آماده‌سازی فعالیت‌های تست همکاری کند.

• آماده‌سازی سناریوهای تست
• طراحی موارد تست
• آماده‌سازی داده‌های تست
• بررسی محیط تست
• هماهنگی با Developer درباره رفتار مورد انتظار قابلیت‌های جدید
• بررسی تأثیر احتمالی تغییرات جدید بر قابلیت‌های موجود

این همکاری باعث می‌شود زمانی که یک قابلیت برای تست آماده شد، تیم تست بتواند سریع‌تر آن را ارزیابی کند.

۵. نقش Tester در Testing

در مرحله Testing، تستر فعالیت‌های اصلی ارزیابی نرم افزار را انجام می‌دهد.

بسته به پروژه، این فعالیت‌ها می‌توانند شامل موارد زیر باشند:

• اجرای موارد تست
• اجرای تست‌های اکتشافی
• بررسی قابلیت‌های عملکردی
• اجرای تست‌های غیرعملکردی
• ثبت و پیگیری باگ‌ها
• تست مجدد (Retesting)
• تست بازگشتی (Regression Testing)
• گزارش وضعیت تست
• ارائه اطلاعات درباره ریسک‌های باقی‌مانده

تستر در این مرحله اطلاعاتی در اختیار تیم قرار می‌دهد که به تصمیم‌گیری درباره کیفیت و آمادگی نسخه برای انتشار کمک می‌کند.

۶. نقش Tester در Deployment

در مرحله استقرار (Deployment)، تستر می‌تواند بررسی کند که نسخه منتشرشده در محیط مقصد رفتار مورد انتظار را دارد.

برای مثال، پس از استقرار یک فروشگاه اینترنتی، تستر می‌تواند قابلیت‌های حیاتی مانند موارد زیر را بررسی کند:

• ورود کاربر
• مشاهده محصولات
• افزودن محصول به سبد خرید
• ثبت سفارش
• پرداخت

اجرای تست دود (Smoke Testing) یا سایر بررسی‌های اولیه پس از استقرار می‌تواند به شناسایی سریع مشکلات جدی کمک کند.

۷. نقش Tester در Maintenance

در مرحله نگهداری (Maintenance)، هر تغییر جدید می‌تواند نیازمند تست باشد.

اگر یک باگ اصلاح شود، تستر می‌تواند تست مجدد (Retesting) انجام دهد. اگر تغییر انجام‌شده احتمال تأثیر بر بخش‌های دیگر سیستم را داشته باشد، تستر می‌تواند تست بازگشتی (Regression Testing) انجام دهد.

همچنین قابلیت‌های جدید، بهبودهای نرم افزار و تغییرات محیطی نیز ممکن است نیازمند تست باشند.

Tester فقط مسئول کیفیت نیست

یک نکته مهم این است که تستر تنها فرد مسئول کیفیت نرم افزار نیست.

کیفیت یک محصول نتیجه همکاری اعضای مختلف تیم است و Developer، تحلیلگر، Product Owner، طراح و سایر اعضای تیم نیز در ایجاد کیفیت نقش دارند.

تستر در این میان نقش مهمی در ارزیابی کیفیت، شناسایی ریسک‌ها و ارائه اطلاعات قابل اتکا درباره وضعیت محصول دارد.

بنابراین بهتر است به جای اینکه تستر را «فردی که مسئول پیدا کردن همه باگ‌ها است» بدانیم، او را عضوی از تیم بدانیم که به تیم کمک می‌کند ریسک‌های کیفیت را بهتر شناسایی و مدیریت کند.

آیا Tester باید در تمام جلسات پروژه حضور داشته باشد؟

لزوماً خیر. میزان مشارکت تستر باید بر اساس نوع پروژه، ساختار تیم و نیازهای محصول تعیین شود.

اما هرچه تستر زودتر با نیازمندی‌ها، تصمیم‌های طراحی و تغییرات محصول درگیر شود، فرصت بیشتری برای شناسایی مشکلات پیش از تبدیل شدن آن‌ها به باگ خواهد داشت.

این همان ایده‌ای است که در رویکردهای مدرن با مفاهیمی مانند Shift Left Testing نیز مورد توجه قرار می‌گیرد؛ یعنی فعالیت‌های مرتبط با تست و کیفیت تا حد امکان به مراحل اولیه چرخه توسعه نزدیک شوند.

جمع‌بندی نقش Tester در SDLC

مرحله SDLC	نقش اصلی Tester
Planning	شناسایی ریسک‌ها و نیازهای اولیه تست
Requirement Analysis	بررسی نیازمندی‌ها و قابل تست بودن آن‌ها
Design	بررسی Testability و ارائه بازخورد
Development	آماده‌سازی سناریوها، موارد تست و داده‌های تست
Testing	اجرای تست، ثبت باگ و ارزیابی کیفیت
Deployment	بررسی نسخه مستقرشده و قابلیت‌های حیاتی
Maintenance	تست تغییرات، Retesting و Regression Testing

بنابراین، نقش تستر در SDLC را نمی‌توان به «پیدا کردن باگ بعد از کدنویسی» محدود کرد.

یک تستر حرفه‌ای می‌تواند از ابتدای چرخه توسعه با شناسایی ابهام‌ها، ریسک‌ها و مشکلات قابل پیشگیری، به تیم کمک کند محصولی با کیفیت‌تر و قابل اعتمادتر ایجاد کند.

مزایای استفاده از SDLC

استفاده از چرخه توسعه نرم افزار (SDLC) به تیم کمک می‌کند فرآیند تولید و تکامل نرم افزار را به شکل ساختاریافته‌تری مدیریت کند.

SDLC به خودی خود تضمین نمی‌کند که یک پروژه حتماً موفق شود یا هیچ باگی در نرم افزار وجود نداشته باشد؛ اما ایجاد یک فرآیند مشخص می‌تواند بسیاری از ریسک‌ها و مشکلات رایج توسعه نرم افزار را بهتر مدیریت کند.

۱. ایجاد ساختار مشخص برای توسعه

یکی از مهم‌ترین مزایای SDLC این است که فعالیت‌های اصلی توسعه نرم افزار را در یک ساختار مشخص قرار می‌دهد.

اعضای تیم می‌توانند درک مشترکی از ارتباط میان فعالیت‌هایی مانند تحلیل نیازمندی، طراحی، توسعه، تست و استقرار داشته باشند. این ساختار می‌تواند از انجام فعالیت‌های پراکنده و بدون هماهنگی جلوگیری کند.

۲. شناسایی زودهنگام مشکلات

SDLC کمک می‌کند مشکلات فقط در پایان پروژه شناسایی نشوند.

برای مثال، یک ابهام در نیازمندی می‌تواند در مرحله تحلیل شناسایی شود یا یک مشکل مربوط به Testability هنگام طراحی سیستم مشخص شود.

هرچه مشکل زودتر شناسایی شود، معمولاً اصلاح آن ساده‌تر و کم‌هزینه‌تر خواهد بود.

۳. کاهش دوباره‌کاری

یکی از مشکلات رایج پروژه‌های نرم افزاری، انجام دوباره بخشی از کار به دلیل برداشت اشتباه، نیازمندی ناقص یا تغییرات کنترل‌نشده است.

وجود یک فرآیند مشخص برای تحلیل، طراحی، توسعه و تست می‌تواند احتمال چنین دوباره‌کاری‌هایی را کاهش دهد.

برای مثال، بررسی دقیق نیازمندی پیش از شروع توسعه می‌تواند از پیاده‌سازی قابلیتی جلوگیری کند که از ابتدا با نیاز واقعی کسب‌وکار مطابقت نداشته است.

۴. بهبود کیفیت نرم افزار

SDLC باعث می‌شود کیفیت نرم افزار فقط در پایان پروژه مورد توجه قرار نگیرد.

فعالیت‌هایی مانند بررسی نیازمندی‌ها، طراحی مناسب، بازبینی کد، تست و پایش نرم افزار می‌توانند در مراحل مختلف چرخه انجام شوند. در نتیجه، کیفیت محصول می‌تواند به صورت تدریجی و در طول چرخه توسعه مورد توجه قرار گیرد.

۵. مدیریت بهتر ریسک

هر پروژه نرم افزاری با ریسک‌هایی مانند مشکلات فنی، تغییر نیازمندی‌ها، محدودیت منابع، مشکلات امنیتی یا کاهش کارایی مواجه است.

SDLC کمک می‌کند این ریسک‌ها در مراحل مختلف شناسایی و مدیریت شوند.

برای مثال، اگر یک نرم افزار قرار است تعداد بسیار زیادی کاربر همزمان داشته باشد، نیاز به تست کارایی (Performance Testing) می‌تواند از مراحل اولیه پروژه شناسایی شود.

۶. بهبود همکاری بین اعضای تیم

توسعه نرم افزار معمولاً نتیجه همکاری افراد و تیم‌های مختلف است.

تحلیلگر، طراح، Developer، Tester، Product Owner و سایر اعضای تیم باید درک مشترکی از هدف و وضعیت پروژه داشته باشند.

SDLC با مشخص کردن مراحل و فعالیت‌های اصلی می‌تواند به ایجاد زبان مشترک و هماهنگی بهتر بین اعضای تیم کمک کند.

۷. کنترل بهتر زمان و منابع

وقتی فعالیت‌های اصلی پروژه مشخص باشند، برنامه‌ریزی منابع، زمان و مسئولیت‌ها نیز ساده‌تر می‌شود.

البته میزان دقت این برنامه‌ریزی به مدل SDLC بستگی دارد. برای مثال، در Waterfall ممکن است برنامه‌ریزی اولیه جزئیات بیشتری داشته باشد، در حالی که در Agile برنامه‌ریزی می‌تواند به صورت تدریجی و در چرخه‌های کوتاه انجام شود.

۸. افزایش قابلیت ردیابی

در پروژه‌هایی که نیاز به مستندسازی و کنترل دقیق دارند، SDLC می‌تواند به ردیابی ارتباط بین نیازمندی، طراحی، توسعه و تست کمک کند.

برای مثال، می‌توان بررسی کرد که یک نیازمندی مشخص چگونه طراحی شده، در کدام بخش نرم افزار پیاده‌سازی شده و با چه سناریوها و موارد تستی بررسی شده است.

این موضوع به‌خصوص در پروژه‌هایی که نیازمند کنترل کیفیت و مستندسازی دقیق هستند اهمیت بیشتری پیدا می‌کند.

۹. پشتیبانی بهتر از نگهداری و توسعه آینده

SDLC فقط برای ساخت نسخه اولیه نرم افزار نیست.

وقتی فرآیند توسعه و تغییرات محصول ساختار مشخصی داشته باشد، اضافه کردن قابلیت‌های جدید، رفع باگ‌ها و انجام تغییرات آینده نیز می‌تواند منظم‌تر انجام شود.

در واقع، نرم افزار پس از انتشار وارد مرحله‌ای طولانی از نگهداری و تکامل می‌شود و SDLC می‌تواند این فرآیند را نیز پوشش دهد.

آیا استفاده از SDLC همیشه باعث موفقیت پروژه می‌شود؟

خیر.

SDLC یک چارچوب برای سازمان‌دهی فرآیند توسعه است، نه یک تضمین برای موفقیت پروژه.

اگر نیازمندی‌ها اشتباه تحلیل شوند، ارتباط بین اعضای تیم ضعیف باشد، مدل نامناسبی انتخاب شود یا فرآیندها بدون توجه به شرایط واقعی پروژه اجرا شوند، صرفاً داشتن یک SDLC رسمی نمی‌تواند مشکلات را برطرف کند.

بنابراین، مهم‌تر از پیروی کورکورانه از یک مدل، انتخاب و اجرای فرآیندی متناسب با نیازهای واقعی پروژه است.

برای مثال، استفاده از یک فرآیند کاملاً خطی برای محصولی که نیازهای آن مرتب تغییر می‌کنند، ممکن است مشکلات بیشتری ایجاد کند. در مقابل، استفاده از یک رویکرد بیش از حد پیچیده برای یک پروژه کوچک نیز می‌تواند باعث افزایش غیرضروری هزینه و زمان شود.

نکته: SDLC را بهتر است یک چارچوب قابل تطبیق بدانیم. هدف آن ایجاد نظم، کاهش ریسک و بهبود فرآیند توسعه است؛ نه اینکه تمام تیم‌ها را مجبور کند دقیقاً یک مسیر ثابت را طی کنند.

اشتباهات رایج درباره SDLC

با وجود اینکه مفهوم چرخه توسعه نرم افزار (SDLC) نسبتاً ساده به نظر می‌رسد، چند تصور اشتباه درباره آن وجود دارد که می‌تواند باعث درک نادرست فرآیند توسعه نرم افزار شود.

۱. SDLC فقط مربوط به برنامه‌نویسی است

یکی از رایج‌ترین اشتباهات این است که SDLC را فقط به کدنویسی و فعالیت‌های Developerها مرتبط بدانیم.

در حالی که برنامه‌نویسی تنها یکی از فعالیت‌های چرخه توسعه نرم افزار است.

SDLC فعالیت‌هایی مانند برنامه‌ریزی، تحلیل نیازمندی‌ها، طراحی، توسعه، تست، استقرار و نگهداری را در بر می‌گیرد و افراد مختلفی می‌توانند در این مراحل نقش داشته باشند.

۲. تست فقط در پایان توسعه انجام می‌شود

در برخی مدل‌های سنتی ممکن است Testing به عنوان مرحله‌ای پس از Development دیده شود، اما این موضوع به معنی شروع تمام فعالیت‌های مرتبط با کیفیت در پایان توسعه نیست.

تستر می‌تواند از مراحل اولیه مانند Requirement Analysis در پروژه مشارکت داشته باشد و نیازمندی‌ها را از نظر وضوح، کامل بودن و قابل تست بودن بررسی کند.

همچنین در مراحل Design و Development نیز می‌توان فعالیت‌های مرتبط با کیفیت و تست را انجام داد.

۳. SDLC همیشه خطی است

نمایش SDLC به شکل:

Planning → Requirement → Design → Development → Testing → Deployment → Maintenance

برای درک مراحل اصلی مفید است، اما نباید تصور کنیم تمام پروژه‌ها دقیقاً همین مسیر را یک بار و بدون بازگشت طی می‌کنند.

در روش‌هایی مانند Agile و Iterative، این فعالیت‌ها می‌توانند در چرخه‌های کوتاه بارها تکرار شوند. حتی در مدل‌های مرحله‌ای نیز ممکن است در صورت شناسایی مشکل، تیم به مراحل قبلی بازگردد.

۴. SDLC یک مدل مشخص است

SDLC خودش یک مدل توسعه خاص نیست.

SDLC یک چارچوب کلی برای توصیف چرخه توسعه نرم افزار است. مدل‌هایی مانند Waterfall، V-Model و رویکردهای Agile روش‌های متفاوتی برای سازمان‌دهی و اجرای فعالیت‌های SDLC ارائه می‌کنند.

بنابراین بهتر است بین مفهوم «چرخه توسعه نرم افزار» و «مدل توسعه نرم افزار» تفاوت قائل شویم.

۵. یک مدل SDLC برای همه پروژه‌ها بهترین است

هیچ مدل SDLC واحدی وجود ندارد که برای تمام پروژه‌های نرم افزاری بهترین گزینه باشد.

پروژه‌ها از نظر میزان تغییر نیازمندی‌ها، ریسک، اندازه، پیچیدگی، الزامات قانونی و نوع محصول با یکدیگر تفاوت دارند.

به همین دلیل، انتخاب مدل مناسب باید بر اساس شرایط واقعی پروژه انجام شود.

۶. استفاده از SDLC یعنی پروژه حتماً موفق می‌شود

SDLC یک چارچوب برای سازمان‌دهی فرآیند توسعه است، اما تضمین نمی‌کند که پروژه حتماً موفق شود.

اگر نیازمندی‌ها به درستی تحلیل نشوند، ارتباط تیم ضعیف باشد، تصمیم‌های فنی نامناسب گرفته شوند یا ریسک‌ها نادیده گرفته شوند، داشتن یک فرآیند رسمی SDLC به تنهایی نمی‌تواند مشکل را حل کند.

هدف SDLC این است که فرآیند توسعه منظم‌تر، قابل کنترل‌تر و قابل پیش‌بینی‌تر شود.

۷. Tester فقط مسئول پیدا کردن باگ است

تستر فقط یک Bug Finder نیست.

وظیفه تستر صرفاً پیدا کردن و گزارش باگ نیست، بلکه می‌تواند با بررسی نیازمندی‌ها، شناسایی ریسک‌ها، ارزیابی کیفیت و ارائه بازخورد به تیم، در پیشگیری از مشکلات نیز نقش داشته باشد.

از طرف دیگر، کیفیت مسئولیت کل تیم است و نباید تمام مسئولیت کیفیت محصول را فقط بر عهده Tester گذاشت.

۸. Agile یعنی بدون برنامه‌ریزی و مستندات

یکی دیگر از تصورات اشتباه این است که Agile یعنی تیم بدون برنامه‌ریزی و مستندسازی کار می‌کند.

Agile با برنامه‌ریزی و مستندسازی مخالف نیست؛ بلکه تأکید دارد این فعالیت‌ها باید متناسب با نیاز واقعی پروژه و بدون ایجاد فرآیندهای غیرضروری انجام شوند.

یک تیم Agile همچنان به نیازمندی‌های قابل فهم، برنامه‌ریزی، تست، مستندات مورد نیاز و هماهنگی بین اعضای تیم نیاز دارد.

۹. پایان Deployment یعنی پایان SDLC

استقرار نرم افزار به معنی پایان چرخه توسعه نیست.

پس از Deployment، نرم افزار وارد مرحله Maintenance می‌شود و ممکن است برای رفع باگ، بهبود عملکرد، افزایش امنیت یا اضافه کردن قابلیت‌های جدید تغییر کند.

در واقع، هر تغییر مهم می‌تواند بخشی از چرخه SDLC را دوباره فعال کند:

Requirement → Design → Development → Testing → Deployment

۱۰. هرچه فرآیند SDLC پیچیده‌تر باشد، بهتر است

فرآیندهای بیشتر همیشه به معنی مدیریت بهتر پروژه نیستند.

اگر برای یک پروژه کوچک، فرآیندها و مستندات بیش از حد پیچیده ایجاد شوند، ممکن است زمان و منابع زیادی صرف فعالیت‌هایی شود که ارزش واقعی کمی ایجاد می‌کنند.

هدف SDLC باید ایجاد تعادل بین کنترل، کیفیت، سرعت و انعطاف‌پذیری باشد.

نکته: SDLC یک قانون ثابت برای ساخت نرم افزار نیست؛ بلکه چارچوبی برای سازمان‌دهی و مدیریت چرخه توسعه و تکامل نرم افزار است.

چک لیست چرخه توسعه نرم افزار (SDLC Checklist)

اگرچه جزئیات چرخه توسعه نرم افزار (SDLC) بر اساس نوع پروژه و مدل توسعه متفاوت است، داشتن یک چک‌لیست کلی می‌تواند به تیم کمک کند فعالیت‌های مهم را فراموش نکند.

این چک‌لیست را نباید یک دستورالعمل اجباری برای تمام پروژه‌ها در نظر گرفت؛ بلکه بهتر است متناسب با اندازه، پیچیدگی، ریسک و مدل توسعه پروژه تنظیم شود.

۱. چک لیست برنامه‌ریزی (Planning)

• هدف و مسئله اصلی پروژه مشخص شده است.
• نیاز اولیه کسب‌وکار و کاربران مشخص شده است.
• محدوده اولیه پروژه (Scope) مشخص شده است.
• منابع مورد نیاز شناسایی شده‌اند.
• زمان و هزینه تقریبی پروژه بررسی شده است.
• ریسک‌های اولیه شناسایی شده‌اند.
• امکان‌پذیری پروژه بررسی شده است.
• اعضای اصلی تیم و مسئولیت‌های آن‌ها مشخص شده است.
• نیازهای اولیه مربوط به کیفیت و تست بررسی شده‌اند.

۲. چک لیست تحلیل نیازمندی‌ها (Requirement Analysis)

• نیازمندی‌های کاربران و کسب‌وکار شناسایی شده‌اند.
• نیازمندی‌ها مستند و اولویت‌بندی شده‌اند.
• ابهام‌ها و تناقض‌های موجود بررسی شده‌اند.
• وابستگی‌ها و محدودیت‌ها مشخص شده‌اند.
• قوانین کسب‌وکار مورد نیاز مشخص شده‌اند.
• معیارهای پذیرش (Acceptance Criteria) در صورت نیاز تعریف شده‌اند.
• نیازمندی‌ها قابل فهم و قابل تست هستند.
• سناریوهای اصلی و شرایط خاص مورد توجه قرار گرفته‌اند.

۳. چک لیست طراحی (Design)

• معماری کلی سیستم مشخص شده است.
• اجزای اصلی و ارتباط آن‌ها مشخص شده‌اند.
• ساختار پایگاه داده در صورت نیاز طراحی شده است.
• APIها و ارتباط بین سرویس‌ها مشخص شده‌اند.
• طراحی رابط کاربری انجام شده است.
• ملاحظات امنیتی و کارایی بررسی شده‌اند.
• قابل تست بودن (Testability) سیستم در نظر گرفته شده است.
• وابستگی‌های مهم و نقاط پرریسک شناسایی شده‌اند.

۴. چک لیست توسعه (Development)

• توسعه بر اساس نیازمندی‌ها و طراحی انجام می‌شود.
• کد مربوط به قابلیت‌های مورد نیاز پیاده‌سازی شده است.
• بازبینی کد (Code Review) در صورت نیاز انجام شده است.
• تست‌های واحد (Unit Testing) مورد نیاز انجام شده‌اند.
• ساخت (Build) مناسب و قابل استفاده ایجاد شده است.
• تغییرات مهم با تیم تست هماهنگ شده‌اند.
• شرایط مورد نیاز برای تست نسخه آماده شده است.

۵. چک لیست تست (Testing)

• سناریوهای تست مشخص شده‌اند.
• موارد تست مورد نیاز طراحی شده‌اند.
• داده‌های تست آماده شده‌اند.
• محیط تست آماده و قابل استفاده است.
• تست‌های مورد نیاز اجرا شده‌اند.
• باگ‌ها با اطلاعات کافی ثبت شده‌اند.
• باگ‌های رفع‌شده تست مجدد شده‌اند.
• تست بازگشتی در صورت نیاز انجام شده است.
• تست‌های غیرعملکردی مورد نیاز انجام شده‌اند.
• نتایج تست و ریسک‌های باقی‌مانده بررسی شده‌اند.
• وضعیت کیفیت نسخه برای تصمیم‌گیری درباره انتشار مشخص است.

۶. چک لیست استقرار (Deployment)

• محیط مقصد آماده است.
• نسخه مورد نظر برای انتشار مشخص شده است.
• تنظیمات مورد نیاز اعمال شده‌اند.
• تغییرات پایگاه داده در صورت نیاز اعمال شده‌اند.
• فرآیند استقرار بررسی شده است.
• تست دود (Smoke Testing) پس از استقرار انجام شده است.
• قابلیت‌های حیاتی سیستم بررسی شده‌اند.
• پایش (Monitoring) مورد نیاز فعال است.
• در صورت بروز مشکل، برنامه بازگشت به نسخه قبلی (Rollback) مشخص است.

۷. چک لیست نگهداری (Maintenance)

• مشکلات گزارش‌شده کاربران بررسی می‌شوند.
• باگ‌های موجود اصلاح می‌شوند.
• تغییرات و قابلیت‌های جدید تحلیل می‌شوند.
• تأثیر تغییرات بر بخش‌های موجود بررسی می‌شود.
• تست بازگشتی برای تغییرات مهم انجام می‌شود.
• کارایی و امنیت در صورت نیاز بررسی می‌شوند.
• وابستگی‌ها و فناوری‌های مورد استفاده به‌روزرسانی می‌شوند.
• نسخه‌های جدید پس از بررسی و تست منتشر می‌شوند.

چک لیست کلی SDLC

در یک نگاه، می‌توان مهم‌ترین نقاط کنترل چرخه توسعه نرم افزار را به شکل زیر خلاصه کرد:

مرحله	سؤال کلیدی
Planning	چه چیزی می‌خواهیم بسازیم و چرا؟
Requirement Analysis	دقیقاً چه چیزی باید ساخته شود؟
Design	سیستم چگونه باید ساخته شود؟
Development	آیا طراحی و نیازمندی‌ها به درستی پیاده‌سازی شده‌اند؟
Testing	آیا نرم افزار مطابق انتظار کار می‌کند و ریسک آن قابل قبول است؟
Deployment	آیا نسخه آماده استقرار و استفاده است؟
Maintenance	چگونه نرم افزار را پس از انتشار اصلاح و تکامل دهیم؟

یک نکته مهم درباره SDLC Checklist

این چک‌لیست نباید باعث شود تیم تصور کند تمام پروژه‌ها باید دقیقاً همین فعالیت‌ها را انجام دهند.

برای مثال، در یک پروژه کوچک ممکن است برخی فعالیت‌ها بسیار ساده انجام شوند، در حالی که در یک سیستم بانکی، پزشکی یا سازمانی با الزامات قانونی، مستندسازی، بررسی ریسک، تست و کنترل تغییرات می‌تواند بسیار گسترده‌تر باشد.

همچنین در مدل‌های Agile، بسیاری از این فعالیت‌ها در هر Iteration یا Sprint تکرار می‌شوند و الزاماً یک بار در کل پروژه انجام نمی‌شوند.

بنابراین، بهترین استفاده از این چک‌لیست این است که آن را به عنوان یک چارچوب قابل تنظیم برای بررسی کامل بودن فرآیند توسعه نرم افزار در نظر بگیریم.

جمع‌بندی

چرخه توسعه نرم افزار (Software Development Life Cycle یا SDLC) چارچوبی برای سازمان‌دهی فرآیند توسعه، تحویل و نگهداری نرم افزار است. SDLC کمک می‌کند توسعه نرم افزار به جای مجموعه‌ای از فعالیت‌های پراکنده، در قالب یک فرآیند مشخص و قابل مدیریت انجام شود.

در یک ساختار رایج، چرخه توسعه نرم افزار شامل مراحل زیر است:

Planning → Requirement Analysis → Design → Development → Testing → Deployment → Maintenance

در مرحله برنامه‌ریزی (Planning) هدف، محدوده، منابع، زمان، هزینه و ریسک‌های اولیه بررسی می‌شوند. سپس در تحلیل نیازمندی‌ها (Requirement Analysis) مشخص می‌شود که نرم افزار دقیقاً چه نیازهایی را باید برآورده کند.

در مرحله طراحی (Design) ساختار و نحوه عملکرد سیستم مشخص می‌شود و در مرحله توسعه (Development) این طراحی و نیازمندی‌ها به نرم افزار واقعی تبدیل می‌شوند.

پس از آن، نرم افزار در مرحله Testing از جنبه‌های مختلف مورد بررسی قرار می‌گیرد تا مشکلات، ریسک‌ها و رفتارهای غیرمنتظره شناسایی شوند. در صورت آماده بودن نسخه، نرم افزار وارد مرحله Deployment می‌شود و در نهایت در مرحله Maintenance برای رفع مشکلات، بهبود و اضافه کردن قابلیت‌های جدید تغییر می‌کند.

البته این مراحل الزاماً همیشه به صورت خطی و یک‌بار انجام نمی‌شوند. در مدل‌هایی مانند Agile و Iterative، فعالیت‌های SDLC در چرخه‌های کوتاه‌تر تکرار می‌شوند و محصول به صورت تدریجی توسعه پیدا می‌کند.

SDLC و تست نرم افزار

یکی از مهم‌ترین نکاتی که باید درباره SDLC به خاطر داشته باشیم این است که تست نرم افزار فقط یک فعالیت در پایان توسعه نیست.

اگرچه Testing یکی از مراحل اصلی SDLC محسوب می‌شود، فعالیت‌های مرتبط با کیفیت می‌توانند از مراحل اولیه آغاز شوند. تستر می‌تواند در تحلیل نیازمندی‌ها، بررسی طراحی، آماده‌سازی تست، اجرای تست، استقرار و نگهداری نرم افزار نقش داشته باشد.

به همین دلیل، تستر در یک تیم حرفه‌ای فقط فردی نیست که در پایان Development به دنبال Bug بگردد؛ بلکه می‌تواند با شناسایی زودهنگام مشکلات و ریسک‌ها، به پیشگیری از نقص‌ها و افزایش کیفیت محصول کمک کند.

SDLC یک مسیر ثابت برای همه پروژه‌ها نیست

مدل‌های مختلفی مانند Waterfall، V-Model، Iterative و Agile روش‌های متفاوتی برای اجرای فعالیت‌های SDLC ارائه می‌کنند.

انتخاب مدل مناسب به عواملی مانند نوع پروژه، میزان تغییر نیازمندی‌ها، ریسک، پیچیدگی، الزامات کسب‌وکار و نیاز به بازخورد سریع بستگی دارد.

بنابراین نمی‌توان گفت یک مدل همیشه بهترین انتخاب است. یک فرآیند مناسب باید با شرایط واقعی پروژه و نیازهای تیم و کسب‌وکار هماهنگ باشد.

ارتباط SDLC و STLC

در نهایت باید بین SDLC و STLC نیز تفاوت قائل شویم.

SDLC چرخه کلی توسعه و تکامل نرم افزار را پوشش می‌دهد، در حالی که STLC (Software Testing Life Cycle) بر فرآیند انجام فعالیت‌های تست تمرکز دارد.

به بیان ساده:

• SDLC: چرخه کلی توسعه نرم افزار
• STLC: چرخه انجام فعالیت‌های تست نرم افزار

شناخت SDLC برای درک جایگاه تستر در فرآیند توسعه اهمیت زیادی دارد؛ اما جزئیات مراحل و فرآیند STLC موضوع مستقلی است که می‌توان آن را جداگانه بررسی کرد.

یک نگاه نهایی به SDLC

اگر بخواهیم کل مقاله را در چند سؤال ساده خلاصه کنیم:

• چه چیزی و چرا باید ساخته شود؟ → Planning
• دقیقاً چه چیزی باید ساخته شود؟ → Requirement Analysis
• چگونه باید ساخته شود؟ → Design
• چگونه آن را پیاده‌سازی کنیم؟ → Development
• آیا مطابق انتظار کار می‌کند؟ → Testing
• چگونه آن را در اختیار کاربران قرار دهیم؟ → Deployment
• چگونه آن را اصلاح و توسعه دهیم؟ → Maintenance

درک این چرخه برای هر فردی که در فرآیند تولید نرم افزار فعالیت می‌کند، به‌خصوص Developer، Tester، تحلیلگر، Product Owner و سایر اعضای تیم محصول، دید بهتری نسبت به جایگاه فعالیت‌های مختلف در پروژه می‌دهد.

برای یک Software Tester نیز شناخت SDLC اهمیت ویژه‌ای دارد؛ زیرا کمک می‌کند تست را نه به عنوان یک فعالیت جدا از توسعه، بلکه به عنوان بخشی از فرآیند کلی تولید و بهبود نرم افزار با کیفیت درک کند.

در نهایت، هدف SDLC ایجاد یک فرآیند منظم و قابل مدیریت برای تبدیل یک نیاز یا ایده به یک نرم افزار قابل استفاده و سپس نگهداری و تکامل آن در طول زمان است.