🔵 عنوان مقاله
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.
👍1
🔵 عنوان مقاله
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…
👍1
🔵 عنوان مقاله
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
👍1