تیستن جامعه مهندسین تست نرم‌افزار ایران
نوشته های مرتبط
Pyramid Model
تعداد زیادی از پروژه‌ها و تیم‌های توسعه با چالش در اختیار داشتن یک تعداد منبع ویژه ًَQA درگیر هستند. در این حالت به طور میانگین یک تستر به پنج توسعه‌دهنده در هر تیم تخصیص داده می‌شود.
همانطور که پروژه‌ها با سرعت تحویل می‌شوند، با تغییر نیازمندی‌های پروژه، منابع QA نیز بیش از پیش ارزشمند می‌شوند.
هنوز هم بسیاری از تیم‌های تحویل وجود دارند که برای نیازمندی‌های تست، Planning، تحلیل، طراحی Test Case، پیاده‌سازی، اجرا و خاتمه تست بیش از حد روی فرآیند دستیِ دقیق متمرکز هستند. در این حالت با گذشت زمان هزینه افزایش می‌یابد و کیفیت تحویل نیز کاهش چشمگیری خواهد داشت. اکنون چرخه‌های مدرن تست باید یک رویکرد لاغرتر و سریع را برای تطبیق با رشد قابلیت‌های تست اتوماتیک دنبال نمایند، که از آن به تیم‌های تحویل مداوم(Continuous Delivery) و Agile تعبیر می‌شود. در اینجا چند نگرش در رابطه با اجرای یک چرخه عمر تست ساده‌تر، ارزان‌تر و سریع‌تر وجود دارد:
رویکرد “مدل هرم تست”
هرم تست رویکردیست که مانند یک مدل در چرخه مدرن حیات تست دنبال می‌شود. البته این رویکرد در چرخه حیات تست بر یافتن باگ‌ها در ابتدای کار، به شکلی ارزان و سریع تاکید دارد.
بزرگترین قسمت این مدل می‌گوید که ۷۰% تست‌های نوشته شده باید Unit Test باشند که پیش از استخراج باگ‌ها توسط تیم‌های QA، توسط برنامه‌نویس‌ها برای تست کدهای خود آنها نوشته می‌شود. این تست بسیار مهم است، چرا که اساس پوشش تست را فراهم می‌کند. این امر تعداد اشکالات عمده‌ای که بعدا در چرخه تست یافت می‌شوند را کاهش می‌دهد.
با بالا رفتن به سمت نوک هرم، به مرحله بعدی می‌رسیم که نشان می‌دهد باید ۲۰% تست‌ها به Integration اختصاص یابند، که معمولا به منظور یکپارچه‌سازی سیستم با دیگر وابستگی‌ها یا سیستم‌های ثالث نوشته می‌شوند. در این تست‌ها سرویس‌های Mock و محیط‌های مجازی اتوماتیک می‌توانند مورد استفاده قرار گیرند تا بدین ترتیب قسمت‌هایی که از دست Unit Testها دَر رفته است را به طور کامل پوشش دهند.
در مرحله آخر به نوک هرم می‌رسیم، که نشان می‌دهد باید ۱۰% تست‌ها بر Functional UI Testing متمرکز باشند. این تست‌ها شکننده هستند، زیرا هر تغییر UI به راحتی می‌تواند بسته‌های تست را از بین ببرد، بنابراین در حالت ایده‌آل باید در خط ساخت(Building Pipeline) اتوماتیک شوند. این کار اجازه نگهداشت‌پذیری و کار بیشتر در حوزه Exploratory Testing را فراهم می‌آورد. از طریق مدل هرم تست، تیم‌ها می‌توانند با افزایش پوشش تست در کف هرم و نیز حذف باگ‌های افشا شده در زمان حرکت به نوک هرم، در هزینه و زمان مصرف شده در چرخه تست صرفه‌جویی نمایند.
چرخه‌حیات تست BDD
به دنبال تکامل روش TDD(متدولوژی توسعه تست محور یا Test Driven Development)، توسعه رفتار محور یا BDD که مخفف Behavior Driven Development است متولد شد، و البته در حال حاضر تقریبا تبدیل به یک استاندارد صنعتی برای تیم‌ها شده است. اکنون این روش به خوبی تکمیل گشته و جایگزین روش سنتی نوشتن Test Requirementها و فاز تحلیل چرخه تست(که در آن تحلیلگران کسب و کار، مدیران پروژه، معماران، توسعه‌دهندگان و تسترها قادر به ارائه ورودی مستقیم و تشکیل معیارهای پذیرش یا Acceptance Criteria به زبان Gherkin با فرمت Given, When, Then برای Agile User Storyها هستند) شده است.
در اصل، BDD Acceptance Criteria/Test Scriptها به عنوان یک جایگزین برای جمع‌آوری Test Requirementها و فاز تحلیل ایفای نقش می‌کنند، که باعث می‌شود هر گونه سوتفاهم بین اعضای تیم از بین رفته، و علاوه بر آن با برچیده شدن هر گونه تائید برای فرآیندهای غیرضروری، چرخه تست کارآمدتری به ارمغان آید.
افزون بر موراد بالا، با استفاده از امکانات تست اتوماتیک مانند “Cucumber” و “JBehave”، به ویژه در هنگام نوشتن اسکریپت‌های فنی تست، می‌توان پتانسیل این متدولوژی را به حداکثر رساند. این موضوع ارتباط زیادی با گزارش تست دارد، که در آن BDD Reporting Engineهایی مانند “Cucumber HTML Reports” و “Serenity BDD” وجود دارند که سختی و عذاب گزارش‌های سنتی و خاتمه آزمون(Test Closure) را از بین می‌برند. این بدان دلیل است که گزارش‌های Manual Test را برای هر چرخه تست ایجاد می‌کنند. این موتورهای گزارشدهی، گزارش‌های تست حرفه‌ای از Test Scenarioها، Test Coverage و Test Execution به صورت مبتنی بر کاربر ایجاد می‌کنند که باید با تیم‌ها و ذینفعان(Stakeholderها) به اشتراک گذاشته شوند.
با استفاده از متدولوژی BDD در چرخه حیات تست، پل ارتباطی بین تیم‌های کسب و کار و تیم‌های فنی بهبود می‌یابد تا بدین ترتیب پیاده‌سازی، اجرا و فرآیندهای گزارشگیری تست از طریق مفهوم زبان کسب و کاریِ عمومی و ساده بهبود یابد.
یکپارچه‌سازی مداوم(Continuous Integration) در چرخه‌های حیات تست
ادغام و یکپارچه شدن تیم‌های توسعه در فضای Continuous Integration-CI/Continuous Development-CD، در حال حاضر تبدیل به یک کاتالیزور جدید برای حفظ چرخه تست بارور و کارآمد شده است.
در مقایسه با سیکل تست سنتی که در آن اکثر خط ساخت و تست نیازمند چندین فرآیند دستی خسته کننده بود، CI/CD به شدت بر پیاده‌سازی خطوط ساخت خودکار(Automated Build Pipeline) تمرکز دارد. CI/CD نه تنها از عهده چالش منابع QA بر می‌آید، بلکه به منظور کار بر روی فعالیت‌هایی از قبیل Exploratory Testing(جهت تولید و تحویل محصولات Free-Bug)، زمان را برای فعال کردن تست‌های Functional Testerها آزاد می‌کند.
هنگام غرق شدن در فرآیند سنتی چرخه حیات تست، می‌توانید شاهد بسیاری از فرآورده‌ها و اسناد تست باشید که برای حمایت از فعالیت‌های تست و ایجاد اطمینان برای ذینفعان فراهم شده‌اند. بعضی ممکن است فکر کنند، حرکت به سمت یک روش ساده‌تر ممکن است نیازمند از بین بردن محصولات و اسناد تست باشد! البته دقیقا اینطور نیست.
اسناد زنده
ایجاد یک چرخه تست پایدار، مستلزم کاهش مستندات و تأییدات غیر ضروری است، با این حال، به جای حذف این شیوه‌ها، ما یک نسل جدید به نام “اسناد زنده” را ایجاد می‌کنیم. روشی که در آن استفاده از رویکردهای سنتیِ مستندسازی تست با جداول Word و Excel(که دیگر کسی آنها را نمی‌خواند) غیرممکن است. البته شایان ذکر است هنوز در شرکت‌های ایرانی علاقه زیادی به این تولیدات برای ارائه به ذینفعان وجود دارد.
در اینجا هدف ما دستیابی به مجموعه محصولات و اسناد زنده‌ایست که ابزارهایی مانند JIRA Confluence را برای ایجاد اسناد تست پویا بکار می‌گیرند، که شاید بتوان آنها را به Daily Scrum Backlogها(به همراه آخرین وضعیت و Updateها از تیم) لینک نمود؛ البته همراه با ماکروهای بصری و با قابلیت Tag کردن و Comment گذاشتن. بواسطه اسناد زنده، با آخرین گزارش وضعیت که مستقیما از سوی تیم‌ها می‌آید، تیم‌ها و ذینفعان اجبارا در سرتاسر مستندسازی فرآیند و اصلاح آن در هر Iterative Delivery Milestone(نقطه تحویل تکرارشونده) شرکت می‌کنند. چنین موضوعی می‌تواند در زمانی که باید در برقراری ارتباط با دیگران مصرف می‌کردید صرفه‌جویی نماید.
هر تیم از منابع، اهداف و فرآیندهای مختلف تشکیل شده است. با این حال، با پیروی از برخی اصول مندرج در اینجا، و استفاده از قابلیت‌های اتوماسیون موجود در بازار، پیشرفت قابل ملاحظه‌ای در دراز مدت به وجود خواهد آمد، و در این زمان یک چرخه حیات تست ساده‌تر بدست آمده است.
