هر مرحله از چرخه عمر توسعه نرم افزار به همان اندازه مهم است. با این حال، اگر بخشی از توسعه وجود داشته باشد که بیشترین تأثیر را بر تجربه مشتری داشته باشد، احتمالاً آزمایش یا تست است. باگ های از دست رفته که در محیط تولید ظاهر می شوند، بدترین تاثیر را بر کاربران نهایی می گذارند. و اگر خطاهای مهم را از دست دادید، برنامه می‌تواند در نامناسب‌ترین زمان کار را متوقف کند که ممکن است برای کاربران و کسب‌وکار شما هزینه زیادی داشته باشد.
تست نرم افزار کامل می تواند از وقوع همه اینها جلوگیری کند. اما اگر می خواهید مرحله تستی گردش کار توسعه خود را واقعاً مؤثر کنید، باید با آن مانند نبرد با باگ ها رفتار کنید. هیچ نبردی بدون یک نقشه خوب هرگز پیروز نشده است. بنابراین نقشه تست نرم افزار چیست و چگونه می توان یک نقشه تست نویسی ایجاد کرد؟ بیایید همه چیز را در مورد آن یاد بگیریم.
نقشه تست نویسی چیست؟
اول و مهمتر از همه، یک نقشه تست یک سند مهم است که حاوی تمام اطلاعات در مورد نحوه انجام تست پروژه شما توسط تیم شما است. این با اطلاعات کلی در مورد اهداف تست شروع می شود، اما سپس عمیق تر می شود و به سطح عملی می رود و محیط تست، برنامه زمان بندی و نتایج تست را مشخص می کند. نقشه تست به صورت کلی تنظیم نشده است. می تواند در طول پروژه رشد کرده و تغییر کند. بهترین روش این است که به طور منظم آن را با در نظر گرفتن آخرین پیشرفت های پروژه به روز کنید.
در یک نقشه تست چه چیزی وجود دارد؟
یک نقشه تست نویسی جامع شامل تمام جزئیات مفید در مورد نحوه انجام تست، از کجا شروع، و نحوه تعیین اینکه چه زمانی تست نرم افزار با موفقیت انجام می شود، می باشد. این باید شامل برخی از داده‌ها در مورد منابع مورد نیاز، مؤلفه‌ها یا ویژگی‌هایی باشد که آزمایش می‌شوند و کدام اعضای تیم مسئول انجام آزمایش‌ها هستند.
چه کسی در آن شرکت می کند؟
ممکن است به نظر برسد که شما یک نقشه تست به طور خاص برای تیم QA ایجاد می‌کنید و فقط تست کننده گان و مدیر تست از آن استفاده می‌کنند. در واقع، کار بر روی مستندات تست همراه با تیم‌های خارجی، مانند مدیران پروژه، توسعه‌دهندگان، تحلیلگران تجاری و دیگران، برای شفاف‌تر کردن تست و کمک به ذینفعان برای درک بهتر جزئیات آن، مهم است. در نتیجه، رعایت مهلت‌های پروژه و برآورده کردن الزامات محصول آسان‌تر می‌شود.
نوشتن نقشه تست
نقشه های تست باید شامل جزئیاتی در مورد آنچه که قرار است آزمایش کنید، چگونه آن را انجام می دهید، و انتظار دارید به چه نتایجی دست یابید، باشد. چندین مرحله وجود دارد که می تواند به شما در درک نحوه نوشتن یک نقشه تست کمک کند که زندگی تیم QA شما را آسان تر می کند و موفقیت محصول شما را با مشتریان تضمین می کند.
محصول را درک کنید
شما باید برنامه ریزی تست را با یادگیری بیشتر در مورد نرم افزار شروع کنید. شما باید درک کنید که محصول قرار است چگونه کار کند و کاربران نهایی و سهامداران پروژه از آن چه انتظاری دارند تا بتوانید مطمئن شوید که تست شما تمام ویژگی های مهم را پوشش می دهد. برای آشنایی بیشتر با نرم افزار می توانید موارد زیر را انجام دهید:
برای مشاهده عملکرد محصول خود، مروری داشته باشید.
برای درک بهتر محدوده تست، مستندات محصول و فرآیند موجود، از جمله الزامات پروژه را بررسی کنید.
با ذینفعان پروژه، از توسعه دهندگان گرفته تا مشتری صحبت کنید تا در مورد اهداف کسب و کار بیشتر بدانید و اولویت های آزمایشی صحیح را تعیین کنید.
استراتژی آزمون را مشخص کنید
یک استراتژی تست بخشی از آماده سازی برای نوشتن نقشه تست است، اما این دو اصطلاح اغلب به اشتباه به جای یکدیگر استفاده می شوند. شما باید استراتژی تست را به عنوان یک سند جداگانه طراحی کنید تا تیم شما بتواند اهدافی را که باید به آن دست یابند به وضوح ببیند.
به طور معمول، این استراتژی شامل اطلاعات کلی در مورد آنچه قرار است آزمایش شود، چه کسی آن را انجام خواهد داد و چه زمانی (حوزه تست و تدارکات تست) است. همچنین به خطرات احتمالی و راه های کاهش آنها اشاره می کند.
استراتژی تست به نوع تست بستگی دارد، که می‌تواند تست واحد، تست سرتاسر، تست عملکرد، تست API، تست امنیتی و غیره باشد. انواع مختلف تست می‌توانند اشکالات مختلفی را کشف کنند، بنابراین نزدیک‌ترین روش تست به اهداف پروژه خودتان را انتخاب کنید.
در نهایت، هزینه های تست را در نظر بگیرید. سند استراتژی تست باید به منابع تست موجود اشاره کند زیرا برخی از انواع تست نرم افزار می توانند بسیار گران باشند، به خصوص اگر به دنبال اتوماسیون تست باشید.
اهداف آزمون را برای تست نرم افزار تنظیم کنید
یک تست موفق سیستم، تستی است که به هدف خود می رسد. اگر واقعاً ندانید که با تست خود چه کاری را انجام می دهید، نمی توانید این کار را انجام دهید. یک هدف تستی باید ویژگی‌هایی را که آزمایش می‌شوند، تعریف کند و سیستم/نرم‌افزار تحت آزمایش (SUT) را مشخص کند. تعیین مرزهایی برای آنچه قرار است آزمایش شود و چه چیزی نیست با مشخص کردن SUT مهم است زیرا می تواند به راحتی در برنامه های مدرن با چندین سیستم یکپارچه گیج کننده شود.
اهداف آزمون همچنین می‌تواند شامل معیارها (برای نتایج تست های غیردودویی مانند آزمون‌های عملکرد) باشد. این معیارها یا نتایج مورد انتظار برای مقایسه با نتایج واقعی آزمایش مورد استفاده قرار خواهند گرفت. برای تجسم بهتر اهداف و نتایج آزمایش، ممکن است بخواهید نمودارها و نمودارها را در سند طرح آزمون خود قرار دهید.
موارد آزمایش را شرح دهید
اهداف آزمون شما اهداف سراسری آن را پوشش می دهد، اما گام بعدی این است که به جزئیات بیشتری در مورد آنچه که دقیقاً انجام خواهد شد پرداخته شود. یک مورد تستی شرح گام به گام تمام اقدامات مورد نیاز برای آزمایش یک ویژگی خاص است. موارد تست همچنین شامل اطلاعاتی در مورد نتایج مورد انتظار در هر موقعیت است. ارائه توضیحات دقیق قبل از شروع پروژه تست ممکن است دشوار باشد، بنابراین بهتر است موارد آزمایش را در یک سند مختلف یا حتی چندین سند برای هر ویژگی/عملکرد خاص سازمان‌دهی شده در یک ساختار درختی جدا کنید تا به‌روزرسانی آنها در صورت لزوم بدون نیاز به تصویب مجدد طرح آزمون جامع تسهیل شود.
منابع را تخصیص داده و محیط تست را تنظیم کنید
بخش مهمی از ایجاد یک نقشه تست، تصمیم گیری برای بهترین استفاده از منابع انسانی و سیستمی است که می تواند برای پروژه تدارک دیده شود. شما باید وظایفی را که هر یک از اعضای تیم تست انجام خواهند داد، تعیین کنید. این اطلاعات به شما کمک می کند تا زمان مورد نیاز برای پروژه خاص را تخمین بزنید و یک برنامه زمان بندی واقعی تهیه کنید.
در اینجا نیز فهرستی از منابع سخت افزاری و نرم افزاری که تیم شما به آن نیاز دارد را تهیه می کنید. اگر چیزی مورد نیاز است اما فوراً در دسترس نیست، گنجاندن آن در طرح آزمایشی به شما یادآوری می‌کند که آن منبع را از قبل تهیه کنید.
منابعی را که برای راه اندازی محیط تست نیاز دارید نیز برنامه ریزی کنید. شما می‌خواهید شرایط تست نرم‌افزار تا حد امکان از شرایط واقعی شبیه‌سازی شود، که ممکن است به ابزارهای تست خاصی نیاز داشته باشد. این کمک می کند تا در مورد نیازهای تیم آزمون برای درک بهتر موارد گمشده صحبت کنید.
معیارهای آزمون را مشخص کنید
اگر هیچ پارامتری وجود نداشته باشد که بتوانید نتایج تست را قضاوت کنید، نمی توانید موفقیت یا شکست تلاش خود را تعیین کنید. اثربخشی تست شما به زمان شروع و پایان فرآیند تست نیز بستگی دارد. به همین دلیل است که در نقشه های تست خود، باید معیارهای تستی را که برای کنترل تست خود استفاده می کنید، مشخص کنید. به طور معمول، سه نوع معیار تست وجود دارد:
معیارهای ورود
این چیزی است که تعیین می کند چه زمانی می توانید تست را شروع کنید. ناگفته نماند که ویژگی یا عنصر خاصی از نرم افزاری که می خواهید تست کنید باید برای تست آماده باشد. علاوه بر این، قبل از شروع، باید همه چیز را برای کار واقعی آماده کنید، که شامل نقشه تست کامل و تمام منابعی است که نیاز دارید. محیط تست باید راه‌اندازی شود و هر مهندس در تیم تست باید به ماژول‌ها، مؤلفه‌ها یا ویژگی‌هایی اختصاص داده شود که قرار است تست کنند.
معیارهای تعلیق
گاهی اوقات تست قبل از تکمیل باید مکث شود. معیارهای تعلیق تعیین می کنند که دقیقا چه زمانی ممکن است این اتفاق بیفتد. به عنوان مثال، ممکن است در حین آزمایش باگ های زیادی مواجه شود که ادامه آن را غیرممکن می کند. بنابراین، برای مثال، می‌توانید حدی را بین 40 تا 50 درصد تعیین کنید و هنگامی که بسیاری از موارد تست با شکست مواجه شدند و معیارهای تعلیق برآورده شدند، تست را تا زمانی که مشکلات حل شود به حالت تعلیق در می‌آورید.
معیارهای خروج
اینها معیارهایی هستند که برای تعیین نتیجه تست و همچنین اهدافی که می خواهید به آنها برسید و همچنین لحظه واقعی تکمیل تست به آنها نگاه خواهید کرد. روش‌های مختلفی برای تعیین معیارهای خروج وجود دارد، اما رایج‌ترین آنها عبارتند از:
نرخ اجرا (Run rate). این روش از نسبت بین تعداد موارد آزمایشی اجرا شده و تعداد کل موارد تست همانطور که در مشخصات تست تعریف شده است استفاده می کند. به طور معمول، نرخ معیار خروج 100٪ تعیین می شود، مگر اینکه دلیل خاصی برای کاهش آن وجود داشته باشد.
نرخ پاس(Pass rate). این یکی بر اساس نسبت بین تعداد موارد آزمایشی با موفقیت گذرانده شده و تعداد کل موارد تستی اجرا شده است. معیارهای خروج را می توان به عنوان یک قاعده در 80-90٪ تنظیم کرد. هر چه بالاتر، بهتر است، اما معیار دقیق به محدوده پروژه شما بستگی دارد. همچنین، مهم است که عملکردهای حیاتی را مشخص کنیم که باید تمام تست ها را پشت سر بگذارند تا انتشار، صرف نظر از میزان تست عمومی انجام شود.
موارد تحویلی تست را فهرست کنید
هر مرحله تست منجر به تعدادی منابع ملموس می شود که برخی از آنها ممکن است بعداً برای ذینفعان تست ارسال شود. همه این اسناد باید در نقشه تست شما فهرست شوند تا به تیم توسعه شما کمک کنند تا بفهمند چه زمانی باید تحویل داده شوند. بسته به مرحله تست پروژه، محموله های تستی معمولاً به سه دسته تقسیم می شوند:
قبل از شروع آزمایش
اول از همه، باید مطمئن شوید که نقشه تست شما برای این مرحله خاص از پروژه آماده است. همچنین معمولاً یک طرح تست سطح پایین تر با جزئیات بیشتر وجود دارد که مشخصات نقشه تست و موارد تست را توصیف می کند. در صورت امکان، داده های تست و نامزدهای اتوماسیون باید از قبل مشخص شوند.
در طول آزمایش
هنگام اجرای تست ها، باید گزارش‌های مربوط به باگ‌ها را پر کنید که باید حاوی هرگونه تحویلی باشد که به بازتولید و تجزیه و تحلیل اشکال کمک می‌کند، به عنوان مثال. گزارش‌ها، داده‌های آزمایشی مورد استفاده در صورتی که از قبل آماده نشده باشند، اسکرین‌کست‌ها، اسکرین‌شات‌ها، و غیره. علاوه بر این، اگر برخی یا تمام تست‌های شما خودکار باشد، باید اسکریپت‌های تست و مستندات آنها را تحویل دهید.
بعد از اتمام تست
نتایج تست به عنوان گزارش‌های تستی مشخص می‌شود که شامل یک خلاصه تست با تجزیه و تحلیل نتایج تست و یافته‌های مربوط به نقص است. داده های این گزارش ها بیشتر در هنگام ایجاد دستورالعمل های محصول و یادداشت های انتشار استفاده می شود. این یک عامل مهم برای تصمیم گیری توسط همه ذینفعان است و می تواند در قضاوت در مورد اینکه آیا معیارهای خروج برآورده شده است یا خیر، مورد استفاده قرار گیرد.
زمان رفع باگ را لحاظ کنید
نقشه شما در نقشه تست باید مدتی به طور خاص برای رفع باگ های کشف شده از هم جدا باشد. در یک محیط چابک، تست ممکن است در اسپرینت‌ها درست مانند هر بخش دیگری از چرخه عمر توسعه نرم‌افزار اتفاق بیفتد، و سپس پس از هر مرحله، باگ‌های یافت شده باید بلافاصله برطرف شوند. این یک واقعیت شناخته شده است که توسط مطالعه ای که از طرف مؤسسه ملی استاندارد و فناوری وزارت بازرگانی ایالات متحده در سال 2003 انجام شد، تأیید شد که هر چه زودتر یک باگ بر طرف شود، هزینه آن برای بودجه پروژه ارزان تر است. یک باگ کشف شده در محیط تولید می تواند 10000 دلار برای شرکت هزینه داشته باشد، در حالی که اگر همان باگ در مرحله QA رفع شود، هزینه می تواند صد برابر کمتر شود، و اگر اشکال را در زمانی که هنوز هم پیدا کنید ممکن است 100 دلار هزینه داشته باشد. جمع آوری الزامات بنابراین بسیار مهم است که همه مشکلات احتمالی در اسرع وقت حل شود.
برای تسهیل رفع باگ ها ، باید طبقه بندی مسائل را در نقشه تست خود قرار دهید. این به توسعه دهندگان کمک می کند تا رفع اشکالات مهم را نسبت به موارد جزئی در اولویت قرار دهند. معیارهای دقیق و مجموعه مقادیر برای تخصیص سطوح اولویت باید منعکس کننده خط مشی شرکت شما باشد و می تواند در هر سازمان متفاوت باشد.
چگونه نقشه تست خود را مفید نگه دارید
پروژه های توسعه نرم افزار می توانند نسبتاً انعطاف پذیر باشند. بسیاری از چیزها، حتی الزامات پروژه، می توانند در طول مسیر تغییر کنند. این تغییرات، به ناچار نیاز به ویرایش نقشه تست نیز دارد. آیا حتی تلاش برای برنامه ریزی دقیق تست ارزشش را دارد؟
نکته این است که بخش‌های مختلف نقشه تست می‌توانند بیشتر از بقیه مستعد تغییرات باشند. دامنه تست و اهداف تست احتمال کمتری دارد که در طول پروژه اصلاح شوند، بنابراین می توانید آنها را مستقیماً در سند طرح تست اصلی توضیح دهید. در مورد چیزهایی که اغلب تغییر می‌کنند، مانند افراد خاصی که به وظایف تست خاص، تخمین‌ها، زمان‌بندی‌ها و غیره اختصاص داده می‌شوند، معمولاً بهتر است فقط به آنها در سند اصلی خود اشاره کنید و پیوندهایی به اسناد نقشه تست دقیق ارائه دهید که می‌توانید آنها را بدون بازنویسی طرح اصلی آزمون واقعی تغییر دهید.
ابزارهای مختلفی برای مدیریت موارد تست مانند Zephyr، QA Touch، TestRail، PractiTest، TestLink یا Testpad وجود دارد که می‌توانید به راحتی بخش‌های جداگانه نقشه تست خود را بر روی یک پلتفرم مدیریت کنید. به این ترتیب، می توانید اطمینان حاصل کنید که طرح تست شما همیشه به روز و معتبر است.
قالب های نقشه های تست نرم افزار
اگر هنوز مطمئن نیستید از کجا شروع کنید، در واقع نیازی به نوشتن یک نقشه تست را از ابتدا ندارید. چندین الگوی طرح تست به صورت آنلاین موجود است که می تواند اولین قدم خوبی در راه تست موثر باشد. اگر تصمیم به استفاده از آن دارید، مطمئن شوید که الگوی نقشه تستی را که پیدا کرده اید تغییر دهید تا مشخصات واقعی پروژه شما را منعکس کند. ممکن است ساده تر باشد که از یک الگو شروع کنید تا از یک صفحه خالی، این به شما بستگی دارد که چه تصمیمی بگیرید.
اگر نگران کیفیت یک الگوی نقشه تست هستید، راه حل آسان این است که از استاندارد بین المللی ISO/IEC/IEEE 29119-3:2013 استفاده کنید. این استاندارد حاوی الگوهای مستندسازی برای تست نرم افزار است که برای مدل های سنتی و چابک SDLC کار می کند. نمونه ها شامل یک نقشه تست، روش های تست، و مواردی هستند که می توانند برای هر گونه فعالیت های تستی، پروژه یا سازمان استفاده شوند.
نتیجه
ایجاد یک نقشه تست نرم افزار خوب از هرج و مرج در تیم QA شما جلوگیری می کند. یک نقشه تست جامع به همه می گوید که چه کاری و چه زمانی انجام دهند، در حالی که همچنین اطمینان می دهد که فقط وظایف ضروری و با هزینه اضافی کمتر تکمیل شده است. سرمایه گذاری مدتی برای یک برنامه تستی دقیق و سنجیده روشی عالی برای آماده سازی محصول خود برای کاربران در سریع ترین زمان و با خیال راحت است. فقط به یاد داشته باشید که تست نباید به عنوان چیزی که در طول مسیر انجام می شود تلقی شود، آن را به عنوان بخش مهمی از گردش کار توسعه نرم افزار خود در نظر بگیرید.