🔵 عنوان مقاله
Seriously Testing LLMs
🟢 خلاصه مقاله:
این مقاله به این می‌پردازد که برای آزمون جدی LLMs چه نیاز است. نویسنده با تکیه بر مجموعه‌ای از آزمایش‌ها، نشان می‌دهد چرا اتکا به دمو یا امتیازهای سطحی کافی نیست و چگونه رفتار مدل با تغییر متن راهنما، زمینه و زمان تغییر می‌کند. James Bach در این مسیر روش LARC را معرفی می‌کند؛ رویکردی ساخت‌یافته و اکتشافی برای برنامه‌ریزی، اجرای آزمون‌ها و تفسیر نتایج که بر طراحی موارد تنشی و خصمانه، مشاهده نظام‌مند و بهبود تکرارشونده تأکید دارد تا الگوهای خطا و محدودیت‌های قابلیت اعتماد آشکار شوند. مقاله توضیح می‌دهد که چرا آزمون جامع دشوار و پرهزینه است: خروجی‌های غیرقطعی، نبود داور قطعی برای «درستی»، حساسیت به Prompt و زمینه، به‌روزرسانی‌های مدل که بازتولیدپذیری را می‌شکنند، محدودیت معیارهای کمی، و نیاز به ابزار، داده، محاسبات و داوری انسانی. در نهایت پیشنهاد می‌شود آزمون LLM را یک کار تحقیقاتی-حرفه‌ای ببینیم: اهداف و ریسک‌ها را روشن کنیم، داده‌های متنوع و خصمانه بسازیم، ثبت و رهگیری کامل انجام دهیم، و با اجرای تکرارشونده روش LARC میان عمق و وسعت، خودکارسازی و قضاوت کارشناسی، و هزینه و کفایت تصمیم‌گیری کنیم.
#LLMs #SoftwareTesting #AIQuality #Evaluation #PromptEngineering #Reliability #JamesBach #MachineLearning
🟣لینک مقاله:
https://cur.at/OfLtyHW?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Seriously Testing LLMs
🟢 خلاصه مقاله:
این مقاله به این می‌پردازد که برای آزمون جدی LLMs چه نیاز است. نویسنده با تکیه بر مجموعه‌ای از آزمایش‌ها، نشان می‌دهد چرا اتکا به دمو یا امتیازهای سطحی کافی نیست و چگونه رفتار مدل با تغییر متن راهنما، زمینه و زمان تغییر می‌کند. James Bach در این مسیر روش LARC را معرفی می‌کند؛ رویکردی ساخت‌یافته و اکتشافی برای برنامه‌ریزی، اجرای آزمون‌ها و تفسیر نتایج که بر طراحی موارد تنشی و خصمانه، مشاهده نظام‌مند و بهبود تکرارشونده تأکید دارد تا الگوهای خطا و محدودیت‌های قابلیت اعتماد آشکار شوند. مقاله توضیح می‌دهد که چرا آزمون جامع دشوار و پرهزینه است: خروجی‌های غیرقطعی، نبود داور قطعی برای «درستی»، حساسیت به Prompt و زمینه، به‌روزرسانی‌های مدل که بازتولیدپذیری را می‌شکنند، محدودیت معیارهای کمی، و نیاز به ابزار، داده، محاسبات و داوری انسانی. در نهایت پیشنهاد می‌شود آزمون LLM را یک کار تحقیقاتی-حرفه‌ای ببینیم: اهداف و ریسک‌ها را روشن کنیم، داده‌های متنوع و خصمانه بسازیم، ثبت و رهگیری کامل انجام دهیم، و با اجرای تکرارشونده روش LARC میان عمق و وسعت، خودکارسازی و قضاوت کارشناسی، و هزینه و کفایت تصمیم‌گیری کنیم.
#LLMs #SoftwareTesting #AIQuality #Evaluation #PromptEngineering #Reliability #JamesBach #MachineLearning
🟣لینک مقاله:
https://cur.at/OfLtyHW?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Satisfice, Inc.
Seriously Testing LLMs - Satisfice, Inc.
Michael and I are getting a lot of interest about how we apply Rapid Software Testing methodology both to test AI and to use AI in testing. We've developed various answers to such questions in recent years. But now that the book is done (and almost out!)…
👍1
🔵 عنوان مقاله
AI in Testing: Hype or Real Progress?
🟢 خلاصه مقاله:
این یادداشت با نگاهی عمل‌گرایانه، دیدگاه Arik Aharoni را درباره نقش واقعی هوش مصنوعی در تست نرم‌افزار شرح می‌دهد: او نشان می‌دهد کجاها AI ارزش ملموس ایجاد کرده و کجاها همچنان اغراق می‌شود. به‌گفته او، AI در تولید اولیه تست‌ها از نیازمندی‌ها، پیشنهاد موارد مرزی، کاهش شکنندگی تست‌های UI، شناسایی تست‌های flaky، خوشه‌بندی خطاها، اولویت‌بندی ریسک‌محور و ساخت داده‌های آزمایشی مفید است؛ همچنین در بررسی‌های بصری و دسترس‌پذیری می‌تواند رگرسیون‌های ظریف را آشکار کند.
در مقابل، خطاهای مدل‌های زبانی، عدم درک عمیق دامنه، محدودیت‌های امنیت و حریم خصوصی، و دشواری ارزیابی کیفیت تست‌های تولیدی، مانع اعتماد کامل می‌شوند. «عامل‌های» خودمختار تست بدون نظارت انسانی هنوز پایدار نیستند و AI جایگزین طراحی آگاه از معماری، تحلیل ریسک و تأیید انسانی نمی‌شود.
جمع‌بندی Aharoni این است: پیشروی واقعی اما تدریجی است. با اجرای آزمایشی کوچک، معیارهای روشن (مانند نرخ کشف عیب و پایداری تست) و جریان‌های human-in-the-loop، می‌توان از AI در حوزه‌هایی با سیگنال قوی—مثل نگهداشت و تریاژ شکست‌ها—بهره برد؛ AI باید مکمل مهارت تیم‌های QA و مهندسی باشد، نه جایگزین آن.
#AIinTesting #SoftwareTesting #QA #TestAutomation #QualityEngineering #LLM #DevOps #TestStrategy
🟣لینک مقاله:
https://cur.at/6kIevSo?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
AI in Testing: Hype or Real Progress?
🟢 خلاصه مقاله:
این یادداشت با نگاهی عمل‌گرایانه، دیدگاه Arik Aharoni را درباره نقش واقعی هوش مصنوعی در تست نرم‌افزار شرح می‌دهد: او نشان می‌دهد کجاها AI ارزش ملموس ایجاد کرده و کجاها همچنان اغراق می‌شود. به‌گفته او، AI در تولید اولیه تست‌ها از نیازمندی‌ها، پیشنهاد موارد مرزی، کاهش شکنندگی تست‌های UI، شناسایی تست‌های flaky، خوشه‌بندی خطاها، اولویت‌بندی ریسک‌محور و ساخت داده‌های آزمایشی مفید است؛ همچنین در بررسی‌های بصری و دسترس‌پذیری می‌تواند رگرسیون‌های ظریف را آشکار کند.
در مقابل، خطاهای مدل‌های زبانی، عدم درک عمیق دامنه، محدودیت‌های امنیت و حریم خصوصی، و دشواری ارزیابی کیفیت تست‌های تولیدی، مانع اعتماد کامل می‌شوند. «عامل‌های» خودمختار تست بدون نظارت انسانی هنوز پایدار نیستند و AI جایگزین طراحی آگاه از معماری، تحلیل ریسک و تأیید انسانی نمی‌شود.
جمع‌بندی Aharoni این است: پیشروی واقعی اما تدریجی است. با اجرای آزمایشی کوچک، معیارهای روشن (مانند نرخ کشف عیب و پایداری تست) و جریان‌های human-in-the-loop، می‌توان از AI در حوزه‌هایی با سیگنال قوی—مثل نگهداشت و تریاژ شکست‌ها—بهره برد؛ AI باید مکمل مهارت تیم‌های QA و مهندسی باشد، نه جایگزین آن.
#AIinTesting #SoftwareTesting #QA #TestAutomation #QualityEngineering #LLM #DevOps #TestStrategy
🟣لینک مقاله:
https://cur.at/6kIevSo?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Software Test Management | Testuff | SaaS Test Management
AI in Testing: Hype or Real Progress? | Software Test Management | Testuff
Discover how AI is reshaping software testing, from self-healing automation to predictive quality insights, and what it means for the future of QA.
🔵 عنوان مقاله
Epistemic Testing, Chapter 2 — Is that a Test or an Experiment?
🟢 خلاصه مقاله:
در ادامه‌ی یادداشت قبلی، Masoud Bahrami با رویکردی معرفت‌شناختی مرز میان «تست» و «آزمایش» را روشن می‌کند و می‌پرسد: هر بار که می‌گوییم در حال «تست» هستیم، واقعا تست می‌کنیم یا آزمایش؟ او توضیح می‌دهد که تست برای راستی‌آزمایی یک ادعا/الزام مشخص در شرایط کنترل‌شده با اوراکل و معیارهای پذیرش روشن و هدف کاهش سریعِ ریسک‌های شناخته‌شده به‌کار می‌رود؛ در حالی‌که آزمایش برای کشف مجهولات، شکل‌دهی/اصلاح فرضیه‌ها، تحمل ابهام و سنجش سیگنال‌ها از طریق تکرار و اندازه‌گیری طراحی می‌شود. فصل به کیفیت شواهد نیز می‌پردازد: تکرارپذیری، ابطال‌پذیری، دقت اندازه‌گیری و هزینه‌ی کسب اطلاعات. یک تست خوب شامل ادعا، شرایط، اوراکل و قاعده‌ی توقف است؛ یک آزمایش خوب فرضیه، متغیرها، طرح ابزار/اندازه‌گیری و معیار به‌روزرسانی باورها را صریح می‌کند. در هر دو، شفاف‌سازی مفروضات، سوگیری‌ها و تهدیدهای اعتبار ضروری است. راهنمای عملی فصل: پیش از اجرا بپرسید در پی تأیید هستیم یا کشف؛ فرضیه/ادعا چیست؛ چه چیزی شواهد معتبر محسوب می‌شود و کدام اوراکل/متریک به‌کار می‌رود؛ ریسک هدف کدام است؛ و معیار توقف/ادامه/تغییر مسیر چیست. پیام نهایی: با نام‌گذاری درست فعالیت و اتخاذ ذهنیت معرفت‌شناختی، «تست» و «آزمایش» را مکمل هم برای تصمیم‌گیری بهتر و یادگیری سریع‌تر به‌کار بگیرید.
#EpistemicTesting #SoftwareTesting #ExperimentVsTest #QualityAssurance #Evidence #Hypothesis #MasoudBahrami
🟣لینک مقاله:
https://cur.at/4sqUvVw?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Epistemic Testing, Chapter 2 — Is that a Test or an Experiment?
🟢 خلاصه مقاله:
در ادامه‌ی یادداشت قبلی، Masoud Bahrami با رویکردی معرفت‌شناختی مرز میان «تست» و «آزمایش» را روشن می‌کند و می‌پرسد: هر بار که می‌گوییم در حال «تست» هستیم، واقعا تست می‌کنیم یا آزمایش؟ او توضیح می‌دهد که تست برای راستی‌آزمایی یک ادعا/الزام مشخص در شرایط کنترل‌شده با اوراکل و معیارهای پذیرش روشن و هدف کاهش سریعِ ریسک‌های شناخته‌شده به‌کار می‌رود؛ در حالی‌که آزمایش برای کشف مجهولات، شکل‌دهی/اصلاح فرضیه‌ها، تحمل ابهام و سنجش سیگنال‌ها از طریق تکرار و اندازه‌گیری طراحی می‌شود. فصل به کیفیت شواهد نیز می‌پردازد: تکرارپذیری، ابطال‌پذیری، دقت اندازه‌گیری و هزینه‌ی کسب اطلاعات. یک تست خوب شامل ادعا، شرایط، اوراکل و قاعده‌ی توقف است؛ یک آزمایش خوب فرضیه، متغیرها، طرح ابزار/اندازه‌گیری و معیار به‌روزرسانی باورها را صریح می‌کند. در هر دو، شفاف‌سازی مفروضات، سوگیری‌ها و تهدیدهای اعتبار ضروری است. راهنمای عملی فصل: پیش از اجرا بپرسید در پی تأیید هستیم یا کشف؛ فرضیه/ادعا چیست؛ چه چیزی شواهد معتبر محسوب می‌شود و کدام اوراکل/متریک به‌کار می‌رود؛ ریسک هدف کدام است؛ و معیار توقف/ادامه/تغییر مسیر چیست. پیام نهایی: با نام‌گذاری درست فعالیت و اتخاذ ذهنیت معرفت‌شناختی، «تست» و «آزمایش» را مکمل هم برای تصمیم‌گیری بهتر و یادگیری سریع‌تر به‌کار بگیرید.
#EpistemicTesting #SoftwareTesting #ExperimentVsTest #QualityAssurance #Evidence #Hypothesis #MasoudBahrami
🟣لینک مقاله:
https://cur.at/4sqUvVw?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Masoud Bahrami
Epistemic Testing, Chapter 2 – Is that a Test or an Experiment? | Masoud Bahrami
Chapter 2 of Epistemic Testing dives deep into the philosophy and practice of testing. I'll show you why separating experiments from tests clarifies verification, boosts reusability, and turns fragile belief into measurable trust. The Experiment Prepares…
🔵 عنوان مقاله
The Invisible Forces of Testing
🟢 خلاصه مقاله:
این مطلب با عنوان The Invisible Forces of Testing به قلم Taras Mankovski نشان می‌دهد که تصمیم‌های ما در تست تنها حاصل ابزارها و چک‌لیست‌ها نیست، بلکه تحت تاثیر «نیروهای نامرئی» قرار دارد. او با مثال توضیح می‌دهد چگونه هرم‌های آزمون تعادل میان unit، integration و end-to-end را بر اساس ریسک، زمان و معماری تعیین می‌کنند؛ چگونه حلقه‌های بازخورد سریع و قابل‌اعتماد یادگیری را شتاب می‌دهند و حلقه‌های کند یا flaky اعتماد را کاهش می‌دهند؛ و چگونه مرزهای واضح میان مولفه‌ها، قراردادها و وابستگی‌ها تست‌پذیری را بهبود می‌بخشند. نتیجه‌گیری او این است که با رویکرد systems thinking و همراستاسازی با ریسک محصول و اهداف تحویل، می‌توان آگاهانه‌ترین و موثرترین انتخاب‌ها را در استراتژی تست انجام داد.
#SoftwareTesting #TestingPyramid #FeedbackLoops #QualityEngineering #TestStrategy #SystemsThinking #QA
🟣لینک مقاله:
https://cur.at/43H9lzA?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
The Invisible Forces of Testing
🟢 خلاصه مقاله:
این مطلب با عنوان The Invisible Forces of Testing به قلم Taras Mankovski نشان می‌دهد که تصمیم‌های ما در تست تنها حاصل ابزارها و چک‌لیست‌ها نیست، بلکه تحت تاثیر «نیروهای نامرئی» قرار دارد. او با مثال توضیح می‌دهد چگونه هرم‌های آزمون تعادل میان unit، integration و end-to-end را بر اساس ریسک، زمان و معماری تعیین می‌کنند؛ چگونه حلقه‌های بازخورد سریع و قابل‌اعتماد یادگیری را شتاب می‌دهند و حلقه‌های کند یا flaky اعتماد را کاهش می‌دهند؛ و چگونه مرزهای واضح میان مولفه‌ها، قراردادها و وابستگی‌ها تست‌پذیری را بهبود می‌بخشند. نتیجه‌گیری او این است که با رویکرد systems thinking و همراستاسازی با ریسک محصول و اهداف تحویل، می‌توان آگاهانه‌ترین و موثرترین انتخاب‌ها را در استراتژی تست انجام داد.
#SoftwareTesting #TestingPyramid #FeedbackLoops #QualityEngineering #TestStrategy #SystemsThinking #QA
🟣لینک مقاله:
https://cur.at/43H9lzA?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Freestyle Testing
The Invisible Forces of Testing
Testing conversations are shaped by three metaphors — the Pyramid, Feedback Loops, and Boxes. Understanding how these forces interact helps us design test harnesses suited to our context rather than following arbitrary rules.
🔵 عنوان مقاله
Why Your 97% Test Coverage Is a Lie
🟢 خلاصه مقاله:
Ran Algawi یادآوری می‌کند که درصد بالای test coverage الزاماً به معنای کیفیت یا ایمنی نیست؛ این عدد فقط اجرای خطوط کد را می‌سنجد، نه درستی رفتار یا توان کشف خطا. پوشش بالا می‌تواند با تست‌های سطحی و خوش‌بینانه به دست آید و شاخه‌های خطا، لبه‌ها و مسائل یکپارچه‌سازی را نادیده بگیرد؛ بنابراین ریسک‌های همروندی، عملکرد و امنیت باقی می‌مانند. راه مؤثرتر، فرهنگِ تفکر سیستمی و پرسشگری است: شناسایی حالت‌های خرابی، تمرکز بر رفتار و سناریوهای واقعی، تست‌های قراردادی و اکتشافی، و تقویت مشاهده‌پذیری و بازخورد محیط تولید. coverage فقط یک سیگنال است نه هدف؛ اثربخشی را با شاخص‌هایی مثل خطاهای گریزان، زمان کشف/بازیابی و کیفیت طراحی تست بسنجید. نتیجه نهایی: به‌جای تعقیب «۹۷٪»، روی کاهش ریسک واقعی و ساخت اعتماد سرمایه‌گذاری کنید.
#TestCoverage #SoftwareTesting #QualityEngineering #RiskBasedTesting #QA #SoftwareEngineering #DevOps
🟣لینک مقاله:
https://cur.at/5eqX2tW?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Why Your 97% Test Coverage Is a Lie
🟢 خلاصه مقاله:
Ran Algawi یادآوری می‌کند که درصد بالای test coverage الزاماً به معنای کیفیت یا ایمنی نیست؛ این عدد فقط اجرای خطوط کد را می‌سنجد، نه درستی رفتار یا توان کشف خطا. پوشش بالا می‌تواند با تست‌های سطحی و خوش‌بینانه به دست آید و شاخه‌های خطا، لبه‌ها و مسائل یکپارچه‌سازی را نادیده بگیرد؛ بنابراین ریسک‌های همروندی، عملکرد و امنیت باقی می‌مانند. راه مؤثرتر، فرهنگِ تفکر سیستمی و پرسشگری است: شناسایی حالت‌های خرابی، تمرکز بر رفتار و سناریوهای واقعی، تست‌های قراردادی و اکتشافی، و تقویت مشاهده‌پذیری و بازخورد محیط تولید. coverage فقط یک سیگنال است نه هدف؛ اثربخشی را با شاخص‌هایی مثل خطاهای گریزان، زمان کشف/بازیابی و کیفیت طراحی تست بسنجید. نتیجه نهایی: به‌جای تعقیب «۹۷٪»، روی کاهش ریسک واقعی و ساخت اعتماد سرمایه‌گذاری کنید.
#TestCoverage #SoftwareTesting #QualityEngineering #RiskBasedTesting #QA #SoftwareEngineering #DevOps
🟣لینک مقاله:
https://cur.at/5eqX2tW?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Why Your 97% Test Coverage Is a Lie
A friend recently shared a story about a payment bug that double-charged customers. During their post-mortem, someone pulled up the metrics…
🔵 عنوان مقاله
If you have 100 pages, do you create 100 Page Objects?
🟢 خلاصه مقاله:
اگر در یک اپلیکیشن ۱۰۰ صفحه دارید، آیا باید ۱۰۰ تا Page Objects بسازید؟ Đinh Công Cảnh یادآوری می‌کند که Page Objects قرار نیست نقشه‌ی یک‌به‌یک از UI باشند؛ آن‌ها باید رفتارهای پایدار و معنادار برای کاربر را کپسوله کنند تا تست‌ها خوانا و مقاوم در برابر تغییرات ظاهری بمانند. به‌جای پیروی کورکورانه از ساختار DOM، مرزها را بر اساس «قصد و کار» تعریف کنید: احراز هویت، جست‌وجو، افزودن به سبد، تسویه‌حساب. اجزای تکرارشونده مثل ناوبری، سربرگ، فیلترها، جدول‌ها و مودال‌ها را به صورت component objectهای قابل‌استفاده‌مجدد جدا کنید.
قانون سرانگشتی این است که تعداد Page Objects را نه با تعداد صفحات، بلکه با انسجام مسئولیت‌ها و میزان تغییرپذیری تعیین کنید: گاهی یک صفحه به چند object کوچک‌تر (فرم، لیست، ویجت سبد) نیاز دارد، و گاهی چند صفحه با رفتار مشابه یک object مشترک را به اشتراک می‌گذارند. نام‌گذاری را هدف‌محور کنید و جزییات تعاملی و locatorهای پایدار را در خود Page Objects نگه دارید تا تست‌ها در سطح دامنهٔ کسب‌وکار بیان شوند. از الگوهای مکمل مثل Screenplay Pattern هم می‌توان در دامنه‌های پیچیده بهره گرفت.
نتیجه اینکه عدد «۱۰۰» پاسخی ندارد؛ معیار واقعی، نگهداشت‌پذیری و کاهش اثر موجی تغییرات UI است. پیام اصلی Đinh Công Cảnh درباره شمردن objectها نیست، بلکه ساختن انتزاع‌های درست است تا تست‌ها سریع‌تر تغییر کنند، واضح‌تر بمانند و سخت‌تر بشکنند.
#PageObjects #TestAutomation #UITesting #DesignPatterns #Selenium #QA #SoftwareTesting #Maintainability
🟣لینک مقاله:
https://cur.at/vvybnfG?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
If you have 100 pages, do you create 100 Page Objects?
🟢 خلاصه مقاله:
اگر در یک اپلیکیشن ۱۰۰ صفحه دارید، آیا باید ۱۰۰ تا Page Objects بسازید؟ Đinh Công Cảnh یادآوری می‌کند که Page Objects قرار نیست نقشه‌ی یک‌به‌یک از UI باشند؛ آن‌ها باید رفتارهای پایدار و معنادار برای کاربر را کپسوله کنند تا تست‌ها خوانا و مقاوم در برابر تغییرات ظاهری بمانند. به‌جای پیروی کورکورانه از ساختار DOM، مرزها را بر اساس «قصد و کار» تعریف کنید: احراز هویت، جست‌وجو، افزودن به سبد، تسویه‌حساب. اجزای تکرارشونده مثل ناوبری، سربرگ، فیلترها، جدول‌ها و مودال‌ها را به صورت component objectهای قابل‌استفاده‌مجدد جدا کنید.
قانون سرانگشتی این است که تعداد Page Objects را نه با تعداد صفحات، بلکه با انسجام مسئولیت‌ها و میزان تغییرپذیری تعیین کنید: گاهی یک صفحه به چند object کوچک‌تر (فرم، لیست، ویجت سبد) نیاز دارد، و گاهی چند صفحه با رفتار مشابه یک object مشترک را به اشتراک می‌گذارند. نام‌گذاری را هدف‌محور کنید و جزییات تعاملی و locatorهای پایدار را در خود Page Objects نگه دارید تا تست‌ها در سطح دامنهٔ کسب‌وکار بیان شوند. از الگوهای مکمل مثل Screenplay Pattern هم می‌توان در دامنه‌های پیچیده بهره گرفت.
نتیجه اینکه عدد «۱۰۰» پاسخی ندارد؛ معیار واقعی، نگهداشت‌پذیری و کاهش اثر موجی تغییرات UI است. پیام اصلی Đinh Công Cảnh درباره شمردن objectها نیست، بلکه ساختن انتزاع‌های درست است تا تست‌ها سریع‌تر تغییر کنند، واضح‌تر بمانند و سخت‌تر بشکنند.
#PageObjects #TestAutomation #UITesting #DesignPatterns #Selenium #QA #SoftwareTesting #Maintainability
🟣لینک مقاله:
https://cur.at/vvybnfG?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
If you have 100 pages, do you create 100 Page Objects?
An interview question you may encounter