هنر نوشتن مورد آزمایشی: یافتن تعادل (مشخصات در مقابل مختصر)

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

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

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

انتقال به رهبری: با چه چالش های جدیدی روبرو شدم؟

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

سبک های نوشتاری متناقض

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

تغییرات مکرر محصول

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

کمبود آرشیو:

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

مسائل دیگر به مرور زمان پدیدار شد 🤦‍♀️

با بررسی این چالش ها، مسائل جدیدی ظاهر شد:

چالش های رگرسیون را رها کنید

آزمایش رگرسیون ما اغلب به دانش تیمی متکی بود تا مجموعه آزمایشی جامع، که منجر به پوشش متناقض بسته به اینکه چه کسی آزمون را اجرا می کرد، می شد.

مشکل در تجزیه و تحلیل علت ریشه ای

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

حضور اعضای جدید تیم

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

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

قبل از پرداختن به دستورالعمل‌های خاص، اجازه دهید ابتدا نگاهی به ابزارهای مدیریت پرونده آزمایشی بیندازیم. ویژگی‌ها و قابلیت‌های ابزار مناسب به‌طور قابل‌توجهی بر میزان مؤثر ایجاد، مدیریت و نگهداری موارد آزمایش تأثیر می‌گذارد.

ابزارهای مدیریت آزمون چیست و چگونه ابزار مناسب را انتخاب می کنید؟

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

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

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

در اینجا چند نمونه از ابزارهای مختلف مدیریت تست آورده شده است: TestRail، Testiny، QA Touch، TestCollab، TestLodge، XRay، Qase، Zephyr و غیره.

برای انتخاب یک ابزار مناسب، باید فعالیت های ارزیابی زیر را در نظر بگیرید:

نیازهای خود را ارزیابی کنید

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

تعریف ویژگی های کلیدی

ویژگی های ضروری و موارد اضافی مطلوب را بر اساس نیازهای شرکت خود شناسایی کنید. این به محدود کردن دامنه ابزارهای مورد نظر شما کمک می کند.

مقیاس پذیری را در نظر بگیرید

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

ویژگی های امنیتی را بررسی کنید

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

هزینه و بازگشت سرمایه را ارزیابی کنید

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

منحنی یادگیری و پشتیبانی را در نظر بگیرید

سهولت استفاده از ابزار و کیفیت پشتیبانی ارائه شده را ارزیابی کنید، از جمله آموزش اعضای تیم خود و خدمات مشتری، برای اطمینان از روند پذیرش روان.

رسیدگی به چالش های ما 🧐

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

چالش 1: سبک های نوشتاری ناسازگار

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

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

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

چالش 2: تغییرات مکرر محصول

برای غلبه بر مشکلات ناشی از تغییرات مکرر محصول، به نکات زیر توجه کنید:

موارد تست را در مجموعه های تست منطقی سازماندهی کنید

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

• 🗂️ عملکرد اصلی
• 🗂️ اعتبارسنجی و رسیدگی به خطا
• 🗂️ عملکرد
• 🗂️ اعتبار UI و طراحی
• 🗂️ اعتبار سنجی محتوا

این ساختار به شما کمک می کند تا موارد تست را به طور موثرتری درک و مدیریت کنید، زیرا هر زیرپوشه زمینه روشنی در مورد محتوای خود ارائه می دهد.

مجموعه های تست و موارد تست را اولویت بندی کنید

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

چرخه های بررسی منظم را اجرا کنید

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

از مراحل تست قابل استفاده مجدد استفاده کنید

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

از مجموعه های آزمایشی در سراسر پروژه ها استفاده کنید

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

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

چالش 3: کمبود آرشیو

برای رسیدگی به چالش سوم «عدم آرشیو»، استراتژی‌های زیر برای تیم‌های من کارساز بوده است:

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

برای هر پروژه در ابزار مدیریت تست، پروژه دیگری به نام بایگانی ${project_name} ایجاد کردم.

پروژه اصلی شامل تمام موارد تست به روز مرتبط با الزامات مربوطه است. پروژه بایگانی شبیه سازی است که در آن پوشه ای با هر نسخه جدید ایجاد می شود که شامل تمام موارد آزمایشی اضافه/به روز شده در این نسخه است که به نسخه الزامات آنها پیوند داده شده است (کپی و جایگذاری در بین پروژه ها در اینجا نجات دهنده زندگی شما خواهد بود 😉😉).

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

اسناد و مدارک واضح را حفظ کنید و سیاهههای مربوط به تغییرات را حفظ کنید

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

کاهش بار: چگونه نوشتن مورد تست را کارآمد و لذت بخش کنیم؟

اگر با ذهنیت تیم خود در مورد نوشتن موارد آزمون مواجه هستید، تغییر طرز فکر آنها مستلزم یک رویکرد استراتژیک است.

مقدار را نشان دهید

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

فرآیند را ساده کنید

از قالب ها استفاده کنید

الگوهای ساده و استانداردی را برای موارد آزمایشی ارائه دهید تا روند نوشتن سریعتر و سازگارتر شود. این کار باعث کاهش بار شناختی تیم شما و سرعت بخشیدن به اسناد و مدارک می شود.

چک لیست ها را بپذیرید

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

با منافع تیم هماهنگ شوید

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

در صورت امکان خودکار کنید

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

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

ترویج فرهنگ مشارکتی

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

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

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

تست مبارک! 🐞🐞