Sauce Labs وتكلفة نتيجة الاختبار التي يثق بها المطورون

ملخص

• تقع شركة Sauce Labs Inc في سلسلة الإصدار بين أطر الاختبار مفتوحة المصدر والتطبيق المواجه للعميل. يمكن للشركة توفير البنية التحتية للمتصفحات والأجهزة، وتكاملات CI، والسجلات، والفيديوهات، والمقارنات البصرية، والتحليلات، والتأليف بمساعدة الذكاء الاصطناعي، لكن الناتج المقبول لا يزال نتيجة اختبار يثق بها المطورون بما يكفي للتصرف بناءً عليها.
• المقام الحقيقي ليس عدد مجموعات المتصفحات والأجهزة في السحابة. بل هو عدد نتائج الاختبار التي تفصل عيوب التطبيق عن أخطاء البرنامج النصي، ومشكلات توفر السحابة، وتباين الشبكة، وعدم توفر الجهاز، وتصنيف النجاح/الفشل المفقود، والتغير في الخط الأساسي البصري، وترقيات الأطر.
• تظهر الوثائق العامة منصة واسعة: اختبار الويب والجوال، والأجهزة الحقيقية والافتراضية، وأنفاق Sauce Connect، وتنسيق saucectl، وقطع أثرية لنتائج الاختبار، و Insights، و Visual Testing، و Error Reporting، وتأليف اختبارات الذكاء الاصطناعي. كما تظهر تحذيرات: أصول الاختبار تنتهي بعد 30 يومًا، والأجهزة العامة تخضع للتوفر، ودعم أجهزة معينة وبرامج طرف ثالث غير مضمون، ويجب تقييم مخرجات الذكاء الاصطناعي من قبل العميل.
• السؤال التجاري هو ما إذا كانت ملكية الأجهزة المحلية المنخفضة، والتنفيذ المتوازي الأسرع، والتصنيف الأوضح تفوق التزامات التزامن، والتعرض للزيادة، وصيانة التكامل، ووقت التصحيح، وحدود الاحتفاظ، وتكلفة الترحيل، والحاجة المستمرة لاختبارات منضبطة.

نتيجة الاختبار، وليس الشبكة

شركة Sauce Labs Inc، شركة سان فرانسيسكو التي تقف وراء سحابة اختبار Sauce Labs، من السهل وصفها بشكل واسع جدًا. إنها منصة اختبار تطبيقات الويب والجوال. تدعم Selenium وAppium وCypress وPlaywright ومسارات اختبار أخرى. تقدم أجهزة حقيقية، وأجهزة افتراضية، ومجموعات متصفحات وأنظمة تشغيل، وتكامل CI، ولقطات شاشة، وفيديوهات، وسجلات، واختبار بصري، وإبلاغ عن الأخطاء، وتحليلات، وتأليف اختبارات بمساعدة الذكاء الاصطناعي. تصف صفحاتها العامة مليارات الاختبارات المنفذة وآلاف البيئات الحقيقية والافتراضية.

هذا الجرد مهم، لكنه ليس وحدة التحليل المفيدة. لا يُدفع لمزود اختبار سحابي لأن شركة تستمتع بإطلاق المتصفحات في مركز بيانات آخر. يُدفع له لأن فريق الإصدار يريد إجابة: هل يمكن شحن بناء هذا التطبيق، أو التراجع عنه، أو حظره، أو إعادة اختباره، أو تحديد نطاقه، أو تصعيده؟ الناتج المقبول هو نتيجة اختبار يمكنها تحمل السؤال التالي من مطور أو مدير إصدار أو مراجع حادث: هل تعطل المنتج، أم تعطل الاختبار، أم كذبت البيئة؟

هذا هو الإطار لـ Sauce Labs. الشركة ليست Selenium نفسها، ولا Appium نفسها، ولا Playwright أو Cypress، وليست تطبيق العميل. إنها تقع بين هذه الأجزاء المتحركة. تقدم للمشترين بنية تحتية مستضافة وسياق نتائج للاختبارات التي لا يزال يتعين على المشترين تصميمها وصيانتها وتفسيرها. تحدد الأطر مفتوحة المصدر الكثير من لغة الأتمتة. يحدد بائعو المتصفحات وأنظمة تشغيل الجوال الكثير من سلوك وقت التشغيل. تحدد أنظمة CI للعميل موعد تشغيل الاختبارات وما إذا كانت النتيجة تمنع الدمج أو الإصدار. يمكن لـ Sauce Labs أن تجعل هذه السلسلة أسهل في التوسع، لكنها لا تستطيع أن تجعل السلسلة حتمية بأعجوبة.

السبب العملي الذي ينظر به الفرق إلى Sauce Labs واضح. توافق الويب والجوال هو مشكلة اندماجية. قد يحتاج فريق المنتج إلى فحص Chrome وSafari وEdge وFirefox؛ وإصدارات macOS وWindows الحديثة؛ وإصدارات iOS وAndroid؛ والمحاكيات والمحاكيات الافتراضية والأجهزة الحقيقية؛ وتخطيطات العمودي والأفقي؛ وأعطال خاصة بالأجهزة؛ وسلوك الموقع الجغرافي والكاميرا والتخزين والأذونات والشبكة؛ وبيئات التدريج الخاصة التي لا يمكن الوصول إليها إلا عبر نفق آمن. امتلاك كل هذه الأجهزة والحفاظ على تحديثها هو عبء تشغيل متخصص. تشغيل الاختبارات المحلية فقط يقلل هذا العبء، لكنه يضيق أيضًا الأدلة قبل أن يرى المستخدمون عيبًا.

تحاول Sauce Labs شغل تلك الأرضية الوسطى: وصول واسع دون أن يقوم كل مشترٍ ببناء مختبر أجهزة، بالإضافة إلى أدلة نتائج كافية لجعل حالات الفشل قابلة للتنفيذ. تقول صفحة الأجهزة العامة إنها تهدف إلى دعم أحدث الإصدارات بسرعة، حسب التوفر الإقليمي، وتدعي آلاف مجموعات المتصفحات والأجهزة. تشرح وثائق الجوال الخاصة بها لماذا تهم الأجهزة الحقيقية عندما يحتاج الفريق إلى نموذج دقيق، وسلوك عرض مثالي للبكسل، وسلوك مكتبة ARM الأصلية، وسيناريوهات شبكة الناقل، ومتغيرات نظام التشغيل المخصصة، أو ظروف تعتمد على الأجهزة.

هذه احتياجات اختبار حقيقية، خاصة للبنوك، وتجار التجزئة، وأنظمة الصحة، والألعاب، وتطبيقات الوسائط، وتطبيقات التأمين، وبوابات المؤسسات التي لا يحمل جميع مستخدميها جهازًا مرجعيًا واحدًا.

لكن الشبكة ليست سوى نقطة بداية. يمكن أن يكون سبب نتيجة اختبار فاشلة هو التطبيق. يمكن أن يكون أيضًا بسبب محدد هش، أو افتراض توقيت، أو بيانات اختبار قديمة، أو انقطاع من طرف ثالث، أو تكوين VPN أو نفق، أو هاتف غير متاح، أو تحديث متصفح، أو تغيير في برنامج تشغيل Appium، أو تأكيد مفقود، أو تحديث حالة نجاح/فشل خاطئ، أو حادث مزود السحابة نفسه. يمكن أن تكون النتيجة الناجحة مضللة أيضًا إذا كانت تفحص القليل جدًا، أو تعمل على تكوين خاطئ، أو تفوت انحدارًا بصريًا، أو تحدد الإكمال كنجاح دون تأكيدات ذات معنى. وبالتالي فإن المقام لـ Sauce Labs ليس "اختبارات تم إطلاقها". إنه نتائج اختبار مقبولة ومفسرة.

الحدود القانونية والمنتجات

حدود الشركة مهمة لأن البنية التحتية للاختبار تصبح بسهولة قصة ائتمان مشترك. تدير Sauce Labs Inc منصة سحابية تجارية. Selenium هو مشروع أتمتة متصفح مفتوح المصدر. Appium هو نظام بيئي لأتمتة الجوال مفتوح المصدر يطبق تحكم WebDriver من خلال برامج التشغيل. Playwright وCypress هما إطارا اختبار بأدوات محلية ومجاورة للسحابة. تدعم Sauce Labs هذه المسارات وتتكامل معها، لكنها لا تملك النتيجة بأكملها. المشتري الذي يكتب اختبارات سيئة سيظل يتلقى إشارات سيئة على نطاق أوسع.

توثق Sauce Labs هذا الانقسام. تصف صفحات التكوين القدرات، ومعالجة W3C WebDriver، واختيار بيئة المتصفح والجوال، وإصدارات الأطر ومصفوفات المنصات. تقول وثائق saucectl إن الأداة السطرية تنظم الاختبارات من الأطر الموجودة، وتشغيلها في سحابة Sauce Labs، وتنقل الأصول إلى المنصة للمراجعة والمشاركة والتقييم. تصف صفحات CI التكامل مع أنظمة التسليم الحالية مثل Jenkins وTeamCity وBitbucket وCircleCI وTravis CI. هذا دور بنية تحتية وتنسيق، وليس ملكية جودة التطبيق.

يظهر نفس الحدود في اختبار الجوال. تقول وثائق Appium إن Appium يستخدم WebDriver كواجهة برمجية، ويعتمد على برامج التشغيل للأتمتة الخاصة بالمنصة، ويستخدم بنية خادم عميل تتيح لمزودي السحابة استضافة خادم Appium والأجهزة بينما يشير كود الاختبار إلى نقاط نهاية آمنة. يمكن لـ Sauce Labs استضافة سطح تنفيذ الجوال، لكن لا يزال يتعين على المشتري اختيار القدرات، وتحميل بنيات التطبيق، والتعامل مع حالة التطبيق، والحفاظ على توافق برنامج التشغيل، وحماية بيانات الاعتماد، وتحديد النتيجة المهمة.

تضيف الصفحات القانونية حافة أكثر صلابة. تصف شروط الخدمة المحددة الجلسات المتزامنة الافتراضية والأجهزة الحقيقية كخدمات مشتراة مع تزامن محجوز. تقول إن Sauce Labs لا تقدم أي التزامات أو ضمانات فيما يتعلق بدعم أو توفر أي برنامج محدد من طرف ثالث في جلسة افتراضية، أو أي نموذج جهاز حقيقي معين، أو نظام تشغيل أو إصدار. هذا لا يجعل الخدمة ضعيفة؛ بل يجعل التبعية صادقة. منصة اختبار سحابية مبنية على متصفحات طرف ثالث، وأنظمة تشغيل، وأجهزة، وأطر أتمتة، وعمليات مركز بيانات. بعض هذه الطبقات تتغير خارج سيطرة Sauce Labs.

هذا مهم تجاريًا لأن المشترين غالبًا ما يقارنون مزودي الاختبار السحابي كما لو كانوا مجرد قوائم بيئات. المقارنة الأفضل تدور حول مدى كشف المزود للحدود. إذا فشل اختبار على iOS، فهل فشل لأن التطبيق معيب، أو خطوة الاختبار غير مستقرة، أو الجهاز غير متاح، أو تم ترقية نظام التشغيل، أو بنية التطبيق خاطئة، أو النفق انقطع، أو كان لدى المزود حادث؟ إذا نجح اختبار على محاكي لكنه فشل على جهاز حقيقي، فهل التباين ذو دلالة أم ضوضاء؟ إذا احتاج اختبار مولّد بالذكاء الاصطناعي إلى مراجعة، فمن يملك المراجعة والصيانة الناتجة؟

لدى Sauce Labs إجابة معقولة للعديد من هذه الأسئلة لأن منصتها تلتقط القطع الأثرية والبيانات الوصفية. ليس لديها إجابة عامة تزيل الأسئلة.

ما تحتويه نتيجة Sauce Labs المقبولة

تبدأ نتيجة الاختبار المقبولة قبل أن تستلمها Sauce Labs. يجب على الفريق تحديد السلوك الذي يجب تأكيده، والبيئات المهمة، والبيانات التي قد يلمسها الاختبار، وما إذا كان الفشل يمنع الإصدار، وكيف يتم تفسير إعادة المحاولات. يمكن لـ Sauce Labs تنفيذ التسجيل، لكن "التنفيذ" وحده إشارة ضعيفة.

تظهر وثائق نتيجة الاختبار الخاصة بـ Sauce Labs النسخة الأكثر ثراءً من المخرجات. بعد التشغيل، يمكن للمستخدمين عرض تسجيلات الفيديو، ولقطات الشاشة، والأوامر الصادرة، والسجلات، والبيانات الوصفية. يمكن تصفية نتائج الاختبار الآلي حسب الاسم، ونوع الجهاز، والنطاق الزمني، والمالك، والحالة، والبناء، والمنصة، والمتصفح، أو الجهاز. تتضمن نتائج البناء حالات النجاح، والفشل، والإكمال، والتشغيل، والخطأ. تميز الوثائق صراحة بين الاختبار المكتمل والاختبار الذي تم تعيين حالة نجاح/فشل له. هذا التمييز أساسي. يمكن أن تعني الجلسة المكتملة أن البيئة عملت حتى النهاية. لا تعني بالضرورة أن التطبيق استوفى متطلبًا.

توفر Sauce Labs آليات لتعيين حالة الاختبار أثناء الجلسة أو بعد الإكمال. تظهر وثائقها تعليقات النجاح/فشل من خلال Selenium JavaScript Executor وتحديثات من خلال REST API. هذا مفيد، لكنه يثبت أيضًا أن النتيجة المقبولة تعتمد على سباكة حالة جانب المشتري. إذا لم يتم تشغيل التأكيدات، أو إذا أبلغ محول الإطار عن فشل بشكل خاطئ، أو إذا تم وضع علامة إكمال دون فحص ذي صلة بالأعمال، فقد تبدو النتيجة السحابية أنظف من مخاطر الإصدار.

القطع الأثرية التشخيصية محددة زمنيًا أيضًا. تقول وثائق Sauce Labs إن مقاطع الفيديو ولقطات الشاشة والسجلات يتم الاحتفاظ بها لمدة 30 يومًا، بينما تتوفر معلمات الاختبار والبيانات الوصفية إلى أجل غير مسمى. للتصحيح العادي، قد تكون 30 يومًا كافية. للبيئات المنظمة، والتحقيقات طويلة الأمد، وحوادث الإصدار المتكررة، وحبس التقاضي، وتدقيق البائع، أو تحليل الانحدار الموسمي، قد لا تكون كافية بدون تصدير أو احتفاظ موازٍ. نتيجة الاختبار مفيدة فقط بقدر ما يمكن للمؤسسة الاحتفاظ بها والبحث فيها وشرحها عند الحاجة.

تحاول Sauce Insights جعل تيار النتائج أكثر فائدة بمرور الوقت. تجمع Job Overview صحة مجموعة الاختبار في حالات الفشل المستمر، والنجاح المستمر، والخطأ المستمر، والحالة المفقودة، والنتائج غير المتسقة. يمكنها تحليل المهام حسب نظام التشغيل، وإصدار المتصفح، والإطار، ونوع الجهاز. يمكن للاتجاهات التصفية حسب المالك، والبناء، ونظام التشغيل، والمتصفح، والجهاز، ومجموعة الأجهزة، والإطار، والعلامة، والفترة الزمنية. هذا هو الاتجاه الصحيح لمشكلة المخرجات المقبولة لأن تشغيلًا واحدًا غالبًا ما يكون أقل إفادة من نمط. قد تكون النتيجة الحمراء المفردة عيبًا حقيقيًا أو ضوضاء. قد تشير عشر نتائج حمراء مماثلة عبر إصدار متصفح واحد إلى خطأ في المنتج.

قد تشير عشر نتائج حمراء متناثرة عبر بيئات غير مرتبطة إلى البنية التحتية أو بيانات الاختبار أو التوقيت.

يضيف الاختبار البصري طبقة أخرى من التفسير. تفصل وثائق Sauce Visual بين إنشاء اللقطة والمراجعة. يلتقط جزء التنفيذ لقطات شاشة ويقارنها بالخطوط الأساسية. يوافق جزء المراجعة على التغييرات المكتشفة أو يرفضها ويطور خطوطًا أساسية للتغييرات المقبولة. هذا التقسيم صحي لأن الاختلافات البصرية يمكن أن تكون عيوبًا أو تغييرات تصميم مقصودة. يمكن للنظام البصري السحابي العثور على وحدات البكسل التي تحركت. لا يمكنه، بدون سياسة أو مراجعة بشرية، تحديد ما إذا كانت الحركة عبارة عن صفحة دفع معطلة، أو تحديث لافتة تسويقية، أو تاريخ ديناميكي، أو اختلاف في عرض الخط، أو تغيير في منع التعرج، أو تعديل ترجمة مشروع.

تجعل تشخيصات الجوال سلسلة القطع الأثرية أكثر تحديدًا. تقول وثائق تقارير الأعطال/الأخطاء الخاصة بالأجهزة الحقيقية من Sauce Labs إن النظام يمكنه التقاط بيانات الأعطال أثناء الاختبار المباشر والآلي دون دمج SDK منفصل، ويمكنه عرض الأعطال المميتة، ومكدسات استدعاء Android، والتحذيرات غير المميتة عند التمكين. هذا قيم لأن حالات فشل الجوال غالبًا ما تحتاج إلى سياق الجهاز، وليس مجرد تتبع خطوة الاختبار. لكنه يخلق أيضًا شرط إعداد: يجب تمكين الميزة، ويجب تحميل التطبيق، ويجب أن تكون الأدوات متوافقة، ويجب ربط العطل الملتقط بقرار الإصدار.

أقوى حالة عامة لـ Sauce Labs، إذن، ليست أنها تلغي تعقيد الاختبار. إنها تتمركز الكثير من الأدلة اللازمة للجدال حول هذا التعقيد. يمكن للفيديو ولقطات الشاشة والسجلات والأوامر والبيانات الوصفية والحالة وأبعاد الجهاز والإطار وسجلات الأنفاق وتحليل الاتجاهات تقليل تكلفة السؤال "ماذا حدث؟" لكن لا يزال يتعين على المشتري تحديد ما يعتبر دليلاً كافيًا.

عدم الاستقرار هو المنافس داخل مجموعة الاختبار

أهم منافس لـ Sauce Labs ليس دائمًا بائع اختبار سحابي آخر. غالبًا ما يكون انعدام الثقة. الفريق الذي لم يعد يصدق نتائجه الآلية سيلتف حولها: يعيد المطورون تشغيل الاختبارات يدويًا، ويتجاهلون البناءات الحمراء، ويعزلون الحالات الصعبة، ويصدرون مع استثناءات، أو يقلصون السطح المختبر حتى تصبح الإشارة قابلة للإدارة. عندما يحدث ذلك، قد يبقى الفاتورة السحابية لكن قيمة القرار تتلاشى.

تشرح الاختبارات غير المستقرة السبب. عرّف النقاش الهندسي العام لـ Google من عام 2016 النتيجة غير المستقرة على أنها اختبار يمكن أن ينجح ويفشل ضد نفس الكود. أبلغ Google عن معدل مستمر يبلغ حوالي 1.5 في المائة من جميع عمليات تشغيل الاختبار التي تبلغ عن نتائج غير مستقرة عبر مجموعته في ذلك الوقت، محذرًا من أن حالات الفشل غير المستقرة تفرض تكلفة تحقيق ويمكن أن تخفي عيوبًا حقيقية. يعامل العمل الأكاديمي على الاختبارات غير المستقرة الاختبارات غير الحتمية كتهديد لاختبار الانحدار لأنها تضعف الثقة في النتائج الخضراء والحمراء. هذه الأرقام والدراسات ليست قياسات Sauce Labs، لكنها تشرح المشكلة التي يجب على Sauce Labs مساعدة المشترين في إدارتها.

الأسباب أوسع مما يعترف به العديد من فرق الإصدار. تخلق افتراضات التوقيت سباقات. تؤدي الرسوم المتحركة لواجهة المستخدم، وتأخيرات الشبكة، والعرض غير المتزامن إلى تحويل الصفحة تحت الاختبار. تتسرب الحالة المشتركة بين الاختبارات. تنتهي صلاحية بيانات الاختبار. ترجع خدمات الطرف الثالث استجابات غير متوقعة. تتغير المتصفحات وأنظمة تشغيل الجوال. تصبح المحددات قديمة. تتحرك إصدارات الأطر. تسخن الأجهزة، أو تقفل، أو تعيد التشغيل، أو تفقد الشبكة، أو تصبح غير متاحة. تقدم الأنفاق مسارها الخاص لبيانات الاعتماد والتوجيه وسلوك الوكيل وتوقيت دورة الحياة. يؤكد مؤلفو الاختبار أحيانًا تفاصيل التنفيذ بدلاً من السلوك المرئي للمستخدم.

يمكن لـ Sauce Labs تقليل بعض الأسباب وكشف البعض الآخر. يمكن أن يؤدي التشغيل في بيئة سحابية موحدة إلى إزالة تباين الكمبيوتر المحلي. يمكن أن يكشف التنفيذ المتوازي عن مشكلات التوقيت التي تخفيها عمليات التشغيل المحلية المتسلسلة. يمكن أن تكشف الأجهزة الحقيقية عن سلوك الأجهزة ونظام التشغيل الذي تفوته المحاكيات. يمكن أن تظهر السجلات والفيديو وتتبعات الأوامر ما إذا كان الاختبار قد نقر على العنصر الخاطئ، أو انتظر لفترة قصيرة جدًا، أو فقد جلسة، أو واجه خطأ من جانب السحابة. يمكن لـ Insights وضع علامات على أنماط النتائج غير المتسقة.

لكن لا يمكن لـ Sauce Labs جعل تأكيد سيئ جيدًا، أو صفحة ديناميكية ثابتة، أو خدمة طرف ثالث موثوقة، أو مجموعة اختبار عميل منضبطة.

تاريخ الحالة العامة هو تذكير مفيد بأن بيئة المزود هي أيضًا جزء من سطح الفشل. في وقت الاسترجاع، أظهر ملخص حالة Sauce Labs أن المكونات تعمل. تضمن تاريخ الحوادث الأخيرة فشل اختبارات macOS 14 في البدء في US-West و EU-Central، ومشكلات الوصول إلى Appium Inspector عبر عدة مراكز بيانات، وفشل جلسات اختبار الجهاز الحقيقي التي تؤثر على Appium و Access API، وحادث توفر جهاز iOS في EU-Central مرتبط بطاقة الرف، وحادث في US-East حيث تم حظر المصادقة وجلسات الاختبار الجديدة بسبب سلسلة شهادات TLS غير مكتملة. هذه الحوادث لا تثبت خدمة سيئة. إنها تثبت النقطة الواضحة ولكن غالبًا ما تُنسى أن منصة الاختبار السحابية هي نظام تشغيل بحد ذاتها.

تغير تلك الحقيقة التشغيلية كيفية تفسير النتائج المقبولة. التشغيل الفاشل أثناء حادث معروف للمزود لا يعادل تشغيل فاشل خلال فترة مستقرة. خطأ عدم توفر الجهاز لا يعادل عطل المنتج. مشكلة مصادقة من جانب السحابة لا تعادل نموذج تسجيل دخول معطل. لذلك يجب أن تتضمن الحوكمة الجيدة حول Sauce Labs تصنيف النتائج، وليس مجرد جمع النتائج. تحتاج الفرق إلى تسميات لفشل المنتج، وفشل كود الاختبار، وخطأ المزود، وفشل النفق، والحالة المفقودة، والمراجعة البصرية المعلقة، وغير المستقر أو إعادة التشغيل مطلوبة. بدون هذه الفئات، يمكن أن تؤدي المزيد من عمليات التشغيل إلى مزيد من الجدالات بدلاً من مزيد من الثقة.

نتيجة الاختبار المقبولة هي كائن اجتماعي وتقني. يجب أن يثق بها المطورون الذين يصلحون الكود، وأصحاب الإصدار الذين يوافقون على النشر، ومراجعو الأمان والامتثال الذين يهتمون بالأدلة، والمديرون الذين يدفعون مقابل التزامن. يمكن لـ Sauce Labs توفير الكثير من الكائن. لا يزال يتعين كسب الثقة في الطريقة التي تستخدمها كل منظمة.

اقتصاديات التغطية والتوازي

يبدأ الجاذبية التجارية لـ Sauce Labs بحجة تجنب التكلفة. بناء وتشغيل مختبر المتصفحات والأجهزة الجوالة مكلف. يجب شراء الأجهزة، وتسجيلها، وشحنها، وإعادة تعيينها، وتنظيفها، وتأمينها، وتوصيلها بالشبكة، والتقاعد. يجب تحديث أنظمة التشغيل أو الحفاظ عليها. يجب الحفاظ على إصدارات المتصفح. يحتاج مشغلو الاختبار إلى التوسع. يحتاج التنفيذ المتوازي إلى بنية تحتية. يحتاج تكامل CI إلى الدعم. تحتاج الفرق البعيدة إلى الوصول. تحتاج فرق الأمان إلى طريقة لاختبار أنظمة التدريج دون كشفها علنًا.

يغير الاختبار السحابي شكل التكلفة. بدلاً من شراء كل جهاز وتشغيل مختبر، يستأجر المشتري الوصول والتزامن وميزات المنصة. يمكن أن يكون ذلك جذابًا عندما يكون الاستخدام متقطعًا، وعندما تتغير مجموعة الأجهزة المختبرة كثيرًا، وعندما تحتاج الفرق العالمية إلى الوصول، وعندما تكون تغطية الجوال مهمة، أو عندما تفتقر الشركة إلى مهارات تشغيل المختبر المتخصصة. تتحدث ادعاءات الأجهزة المدعومة من Sauce Labs ووثائق الأجهزة الحقيقية مباشرة إلى هذه المشكلة. يمكن للفريق استخدام الأجهزة العامة للتغطية الواسعة أو الأجهزة الخاصة عندما يحتاج إلى أجهزة مخصصة، أو إعدادات محددة، أو راحة الأمان، أو عمليات تشغيل متوازية، أو توزيع MDM، أو متطلبات اتصال الشبكة.

المصيدة هي افتراض أن البنية التحتية المستأجرة تزيل تكلفة الاختبار. إنها تغير فئات التكلفة. يصبح التزامن مشكلة تخطيط: كم عدد الجلسات المطلوبة في الذروة، وما هو وقت الانتظار المقبول، وأي البناءات تستحق الفتحات النادرة؟ تصف شروط الخدمة المحددة لـ Sauce Labs التزامن المحجوز وتقول إن الاستخدام الزائد يمكن أن يتم فوترة بمقدار 1.5 ضعف سعر الاشتراك للتزامن المحجوز. هذه التفاصيل القانونية مهمة لأن تكلفة التغذية الراجعة السريعة ليست فقط الاشتراك الأساسي. إنها أيضًا تكلفة التحديد الحجم لفترات الإصدار القصوى، ومعالجة مجموعات الاختبار الطويلة، وتحديد ما إذا كان الدفع مقابل توازي أسرع أم قبول تأخيرات قائمة الانتظار.

يبقى التكامل تكلفة. يجب تثبيت وتكوين saucectl. يجب تعيين علامات CI. يجب أن تتوافق إصدارات WebDriver أو Appium أو Cypress أو Playwright مع مصفوفات Sauce Labs المدعومة. يجب أن تبدأ أنفاق Sauce Connect، وتثبت الجاهزية، وتحمي بيانات الاعتماد، وتوجه حركة المرور، وتغلق بشكل نظيف. توصي الوثائق بنفق واحد أو مجموعة أنفاق لكل مجموعة اختبار أو بناء، مع التحكم في دورة الحياة المرتبطة بإطار الأتمتة. هذا معقول، لكنه لا يزال عملاً. النفق الذي يبدأ متأخرًا، أو يفشل في الجاهزية، أو يستخدم وكيلًا خاطئًا، أو يكشف بيانات الاعتماد في وسيطات العملية، أو يغلق قبل انتهاء الاختبارات، يمكن أن يحول الاختبار السحابي إلى مصدر آخر للنتائج غير المستقرة.

تبقى الصيانة تكلفة. تتغير دعم المتصفحات وأنظمة التشغيل. تقول Sauce Labs إنها تهدف إلى دعم أحدث الإصدارات بسرعة، لكن شروطها توضح أيضًا أن توفر برامج محددة من طرف ثالث غير مضمون وأن بعض إصدارات برامج Apple الأحدث قد تتطلب معرفات جلسة افتراضية متميزة. تحد وثائق الأجهزة الحقيقية الدعم للأجهزة المصنعة في آخر ست سنوات، بينما تنكر شروط الخدمة ضمانات لنماذج أو إصدارات نظام تشغيل معينة. بالنسبة للعديد من المشترين، هذا جيد؛ الاختبار على الأجهزة السائدة الحديثة كافٍ. بالنسبة للآخرين، خاصة في الأسواق ذات دورات استبدال الأجهزة الطويلة، قد تظل الأجهزة القديمة أو إصدارات نظام التشغيل الدقيقة مهمة.

يبقى الاحتفاظ تكلفة. إذا كانت مقاطع الفيديو ولقطات الشاشة والسجلات متاحة لمدة 30 يومًا، يجب على الفرق التي تحتاج إلى نوافذ أدلة أطول تصدير أو نسخ ما تحتاجه. يجب تصميم عملية التصدير هذه قبل الحادث، وليس بعده. وإلا، فقد يحتفظ الفريق بالبيانات الوصفية التي تثبت حدوث تشغيل بينما يفقد القطعة الأثرية اللازمة لشرحه.

تكلفة التبديل هي مقام آخر. قد يشفر نظام الاختبار المستند إلى Sauce Labs القدرات والعلامات وقواعد CI وواجهات الحالة وأنماط النفق وروابط النتائج وعادات لوحة القيادة والخطوط الأساسية البصرية وتاريخ التحليلات. قد يظل الكثير من كود الاختبار محمولاً لأنه يستخدم أطرًا مفتوحة، لكن عملية التشغيل يمكن أن تصبح خاصة بالمنصة. هذا ليس سيئًا بالضرورة. تكسب أدوات المؤسسات رسومها بأن تصبح جزءًا من عملية التشغيل. لكن يجب على المشترين حساب التكلفة بصدق: الابتعاد عن Sauce Labs لاحقًا قد يعني إعادة بناء الوصول إلى الأجهزة، والقطع الأثرية للنتائج، وتاريخ الاتجاهات، والخطوط الأساسية البصري، وعلامات CI، وافتراضات الجهاز الخاص، وذاكرة العضلات للفريق.

الحالة الاقتصادية هي الأقوى عندما تقلل Sauce Labs من عنق الزجاجة محدد: لا يستطيع فريق الجوال الاحتفاظ بأجهزة كافية متاحة؛ يحتاج فريق الويب إلى دليل عبر المتصفحات قبل كل إصدار؛ يحتاج فريق منظم إلى القطع الأثرية؛ تحتاج مجموعة هندسية موزعة عالميًا إلى أدلة اختبار مشتركة؛ تقضي الشركة وقتًا طويلاً في صيانة شبكة Selenium محلية؛ أو توقف قطار الإصدار بسبب حالات فشل غير واضحة. تكون الحالة أضعف عندما يكون لدى المشتري سطح متصفح صغير، وتنوع منخفض في الأجهزة، وتغطية محلية جيدة لـ Playwright، وعدد قليل من بوابات الإصدار، أو اختبارات غير منضبطة ستفشل ببساطة بشكل أسرع في السحابة.

تأليف اختبارات الذكاء الاصطناعي لا يزيل القبول

حركت Sauce Labs توجهها العام نحو الجودة بمساعدة الذكاء الاصطناعي. تؤكد صفحتها الرئيسية وصفحات المنتجات الحديثة على تأليف الاختبارات ورؤى الذكاء الاصطناعي. تقول وثائقها لـ Sauce AI for Test Authoring إن المنتج يمكنه إنشاء حالات اختبار منظمة وقابلة للتحرير من تعليمات اللغة الطبيعية، والتفاعل مع تطبيق ويب أو جوال، وتوليد نصوص لأطر الأتمتة المدعومة، والسماح للمستخدمين بمراجعة الاختبارات وتحسينها، وحفظ الحالات وتنظيمها، وتشغيل المجموعات وجدولة التشغيل. يتم وضع الميزة كإضافة مدفوعة للمؤسسات وتتطلب تزامن جهاز حقيقي أو افتراضي متاح.

هذا اتجاه طبيعي. إنشاء الاختبارات وصيانتها مؤلمان. غالبًا ما تكون اختبارات النهاية إلى النهاية هشة لأن التطبيقات تتغير أسرع من نصوص الاختبار. إذا كانت الأداة يمكنها تحويل نية المنتج إلى فحوصات قابلة للتنفيذ والتكيف مع تغييرات واجهة المستخدم، يمكنها تقليل عنق الزجاجة الرئيسي. تمتلك Sauce Labs أيضًا مطالبة بميزة بيانات معقولة لأنها تدير سحابة اختبار كبيرة لسنوات وتقول إن لديها مليارات عمليات تشغيل الاختبار في تاريخ منصتها.

لكن مقام النتيجة المقبولة يصبح أكثر أهمية عندما يدخل الذكاء الاصطناعي سلسلة الاختبار. يمكن أن يكون الاختبار المولد قابلاً للتنفيذ نحويًا ومع ذلك يفحص الشيء الخطأ. يمكن أن يتبع مسارًا سعيدًا بينما يفوت الحالات الهامشية. يمكن أن يستخدم محددات مستقرة اليوم لكنها هشة غدًا. يمكن أن يفرط في التكيف مع واجهة المستخدم الحالية. يمكن أن يستنتج نية العمل بشكل غير صحيح. يمكن أن يتخطى الحالات السلبية، والأذونات، والتوطين، وإمكانية الوصول، أو شروط حدود البيانات. يمكن أن ينتج بناءً أخضرًا يشعر بالإثارة على وجه التحديد لأن لا أحد راجع ما يعنيه النتيجة الخضراء.

الشروط القانونية لـ Sauce Labs حذرة بشكل مناسب. تقول إن مخرجات تطبيقات Sauce AI قد تكون غير متوقعة أو غير دقيقة أو غير كاملة، وأن العملاء مسؤولون عن تقييم الدقة والملاءمة والملاءمة للغرض. كما تقول إن بيانات العميل لا تُستخدم لتدريب نماذج الذكاء الاصطناعي التوليدية، وأن نماذج الأساس من طرف ثالث قد تدعم منصة الذكاء الاصطناعي. لا ينبغي قراءة هذه التحذيرات على أنها ضعف خفي. إنها إطار الحوكمة الصحيح لأي أتمتة لتأليف الاختبارات. يظل المشتري مسؤولاً عن تحديد ما إذا كان الاختبار المولد بوابة إصدار، أو فحص مسودة، أو اختبار دخان، أو مرشح انحدار، أو مجرد اقتراح.

تواجه AI for Insights نفس مشكلة القبول من الاتجاه المعاكس. تصف Sauce Labs طبقة تحليل محادثة لأسئلة مثل أي الاختبارات فشلت، وما هو اتجاه الاختبار غير المستقر، وما إذا كان البناء جاهزًا للإصدار. يمكن أن يقلل ذلك من التنقيب في لوحة القيادة. يمكن أن يساعد المطورين وقادة الاختبار في الوصول إلى الأنماط بشكل أسرع. لكن إجابة جاهزية الإصدار ليست قيّمة لأنها بطلاقة. إنها قيّمة فقط إذا كانت قائمة على مجموعة النتائج الصحيحة، والبناء الصحيح، ومرشحات البيئة الصحيحة، وسياسة المخاطر الصحيحة، وتتبع القطع الأثرية الصحيح.

وبالتالي، سيعامل المشتري الناضج Sauce AI كطبقة ضغط، وليس بديلاً عن التحكم. قد تضغط إنشاء الاختبار. قد تضغط تحليل النتائج. قد تقترح أسبابًا جذرية. قد تساعد في الحفاظ على التغطية. لكن المنظمة لا تزال بحاجة إلى قواعد المراجعة، والملكية، والتحكم في التغيير، وتسميات الاختبارات المولدة، ومسارات التدقيق للخطوط الأساسية المقبولة، وطريقة لتمييز "الأداة أنتجت اختبارًا" عن "الاختبار يثبت المتطلب."

البدائل ليست شيئًا واحدًا

تتنافس Sauce Labs مع بدائل متعددة في وقت واحد. الأول هو مختبر الأجهزة والمتصفحات الداخلي. يمكن أن يكون جذابًا للشركات ذات متطلبات الأجهزة الصارمة، وحجم الاختبار العالي، والتخصص العميق في الجوال، أو أسباب أمنية لحفظ القطع الأثرية والأجهزة تحت السيطرة المباشرة. يمكن أن يصبح أيضًا إلهاءً مكلفًا إذا كانت الشركة تفتقر إلى انضباط تشغيل المختبر. الأجهزة تتقادم. الكابلات تفشل. المتصفحات تتغير. تقاويم المختبر المشترك تصبح سياسية. الوصول عن بعد والتنظيف يصبحان منتجيهما الخاصين.

البديل الثاني هو الاختبار المحلي مفتوح المصدر. تتيح Selenium وAppium وPlaywright وCypress جميعًا للفرق إنشاء فحوصات آلية مفيدة بدون Sauce Labs. على سبيل المثال، يدعم Playwright عمليات تشغيل متعددة المتصفحات محليًا، والتوازي، ووضع واجهة المستخدم، وعرض التتبع. بالنسبة للعديد من فرق الويب، قد يكون Playwright المحلي أو المستضاف ذاتيًا بالإضافة إلى اختبار الأجهزة اليدوي الانتقائي كافيًا. الميزة هي التحكم وانخفاض الاعتماد على البائع. العيب هو أن التغطية الواسعة للأجهزة الحقيقية، والقطع الأثرية للنتائج عبر الفرق، والبنية التحتية المشتركة القابلة للتوسع لا يزال يجب توفيرها بطريقة ما.

البديل الثالث هو سحابة اختبار تجارية أخرى. تبيع BrowserStack ومزودون آخرون وعودًا واسعة مماثلة حول الأجهزة والمتصفحات والأتمتة والمراقبة. يجب على المشتري الذي يقارن بينهم تجاوز مطابقة القائمة. الأسئلة المفيدة هي توفر البيئة للمزيج الدقيق للمشتري، وجودة القطع الأثرية، وشفافية الحالة، وملاءمة CI، وموثوقية النفق، ومراجعة الأمان، والاحتفاظ بالبيانات، وجودة الدعم، وجهد الترحيل، ونموذج الأساس البصري، وحوكمة الذكاء الاصطناعي، والتكلفة في التزامن الذروة.

البديل الرابع هو فعل اختبار أقل. هذا ليس غير مسؤول افتراضيًا. تفرط العديد من الفرق في استخدام اختبارات النهاية إلى النهاية البطيئة للمشاكل التي يتم التقاطها بشكل أفضل بواسطة فحوصات الوحدة والتكامل والعقد والثابتة وإمكانية الوصول ونظام التصميم أو الفحوصات الكنارية. قد يوفر هرم اختبار أصغر مزيدًا من الثقة مع عدد أقل من عمليات التشغيل السحابية. تكون Sauce Labs قيمة حيث تكون أدلة البيئة الواسعة ضرورية حقًا. إنها ضوضاء مكلفة حيث يمكن معالجة نفس المخاطر في وقت مبكر وبسرعة وبشكل حتمي أكثر.

البديل الخامس هو هجين. قد يحتفظ الفريق بـ Playwright محليًا لانحدار الويب السريع، ويستخدم Sauce Labs لبوابات الأجهزة الحقيقية للجوال، ويشغل الفحوصات البصرية فقط على الصفحات عالية القيمة، ويصدر القطع الأثرية للإصدارات، ويحجز تأليف الذكاء الاصطناعي للتغطية المسودة بدلاً من بوابات الإصدار الصارمة. غالبًا ما يكون هذا هو النموذج الأكثر عقلانية. إنه يعامل Sauce Labs كمنصة متخصصة لعدم اليقين المكلف، وليس كبديل عالمي للهندسة المنضبطة.

نقاط المراقبة للمشترين

نقطة المراقبة الأولى هي تصنيف النتائج. إذا كانت نتائج Sauce Labs مجرد أحمر أو أخضر في عمود CI، فإن الكثير من قيمة المنصة تضيع. يجب على الفرق تتبع حالات فشل المنتج، وفشل الاختبار، وأخطاء البيئة، وفشل النفق، والحالة المفقودة، وعمليات التشغيل في قائمة الانتظار، والمراجعة البصرية المعلقة، والأنماط غير المستقرة كفئات منفصلة. الهدف هو تقليل الوقت المستغرق في الجدال حول معنى النتيجة.

نقطة المراقبة الثانية هي سلوك قائمة الانتظار والتزامن. يمكن للصفحات العامة وصف الأجهزة والمتصفحات المتاحة؛ لا يمكنها إثبات وقت قائمة الانتظار القصوى للمشتري خلال نافذة الإصدار الخاصة به. يحتاج المشترون إلى فهم التزامن المحجوز، وتزامن الأجهزة، والاستخدام القصوى، ومتطلبات الجلسة المتميزة، وشروط الزيادة، وما يحدث عندما تختبر العديد من الفرق في وقت واحد.

نقطة المراقبة الثالثة هي الاعتماد الدقيق على الجهاز. مجموعات الأجهزة العامة مفيدة للاتساع، لكن الأجهزة العامة تخضع للتوفر والنماذج المحددة غير مضمونة. الفرق التي تحتاج إلى نماذج دقيقة، وإعدادات ثابتة، وتوزيع MDM، أو عزل أمني يجب أن تقيم خيارات الأجهزة الخاصة وتحسب التكلفة الإضافية.

نقطة المراقبة الرابعة هي انحراف الإطار. مجموعة اختبار مرتبطة بـ Selenium أو Appium أو Cypress أو Playwright ترث تغييرات إصدار الإطار بالإضافة إلى تغييرات منصة Sauce Labs. تسرد وثائق Sauce Labs الإصدارات المدعومة ونوافذ نهاية العمر لبعض الأطر. يجب امتلاك إيقاع الصيانة هذا، وليس اكتشافه أثناء إصدار معطل.

نقطة المراقبة الخامسة هي تشغيل النفق. غالبًا ما يكون Sauce Connect ضروريًا لاختبار أنظمة التدريج الخاصة. إنه أيضًا جزء متحرك مع بيانات الاعتماد والوكلاء وفحوصات الجاهزية ونقاط نهاية الحالة وتوقيت دورة الحياة وأوضاع الفشل. معاملة النفق كبنية تحتية، مع المراقبة والملكية، هي أكثر واقعية من معاملته كبرنامج إعداد لمرة واحدة.

نقطة المراقبة السادسة هي الاحتفاظ بالقطع الأثرية. إذا كانت المنظمة بحاجة إلى أدلة الإصدار بعد 30 يومًا، يجب تصميم قواعد التصدير وملكية التخزين مسبقًا. قد تكون البيانات الوصفية بدون الفيديو أو السجلات أو لقطات الشاشة غير كافية للتحقيق لاحقًا.

نقطة المراقبة السابعة هي قبول الذكاء الاصطناعي. يجب أن يكون للاختبارات المولدة تسميات، ومالكون، ومعايير مراجعة، وقواعد ترقية قبل أن تمنع الإصدارات. يجب أن يربط التحليل المنتج بالذكاء الاصطناعي بعمليات التشغيل والمرشحات الأساسية. لا ينبغي لأحد قبول ادعاء جاهزية الإصدار دون معرفة أي الاختبارات والبيئات وفئات الفشل نظر فيها.

نقطة المراقبة الثامنة هي تفسير تاريخ الحالة. تظهر حوادث Sauce Labs العامة أن حالات فشل الخدمة تحدث ويمكن أن تؤثر على بدء الاختبار، وتوفر الجهاز، والوصول إلى Appium، والمصادقة، ومسارات API. يجب على المشترين دمج حالة المزود في التصنيف بدلاً من افتراض أن كل فشل سحابي هو كودهم.

ما يجب على Sauce Labs إثباته

لدى Sauce Labs سبب دائم للوجود. أصبح البرنامج معتمدًا جدًا على عدد كبير جدًا من المتصفحات، والأجهزة الجوالة، وإصدارات نظام التشغيل، وطبقات الإطار، وأنظمة الإصدار بحيث لا يمكن لكل فريق إدارة المصفوفة بأكملها بمفرده. سحابة اختبار مشتركة مع أجهزة حقيقية، وأجهزة افتراضية، واتصال آمن، وخطافات CI، وسجلات، وفيديو، ومراجعة بصرية، وإبلاغ عن الأخطاء، وتحليلات تجيب على حاجة تشغيلية حقيقية.

السؤال ليس ما إذا كانت الحاجة موجودة. إنه مقدار عدم اليقين الذي تزيله Sauce Labs من المشتري. إذا كانت التكلفة الرئيسية للمشتري هي ملكية الأجهزة، يمكن لـ Sauce Labs المساعدة. إذا كانت التكلفة هي الاختبار التسلسلي البطيء، يمكن للتنفيذ المتوازي المساعدة. إذا كانت التكلفة هي حالات الفشل غير الواضحة، يمكن للقطع الأثرية و Insights المساعدة. إذا كانت التكلفة هي تأليف الاختبار، قد يساعد الإنشاء بمساعدة الذكاء الاصطناعي، رهناً بالمراجعة. إذا كانت التكلفة هي ضعف تصميم الاختبار، أو عدم الملكية، أو بيانات غير مستقرة، أو سياسة إصدار غامضة، أو تجاهل حالات الفشل غير المستقرة، ستجعل Sauce Labs المشكلة أكثر وضوحًا بشكل أساسي.

يمكن أن تكون تلك الرؤية قيّمة مع ذلك. تحتاج العديد من المنظمات إلى رؤية الفوضى قبل أن تتمكن من حوكمتها. تضع Sauce Labs واجهة منظمة حول تلك الفوضى: أي بناء، أي متصفح، أي جهاز، أي حالة، أي سجل، أي فيديو، أي خطأ، أي اتجاه. لكن القيمة تصل فقط عندما تحول المنظمة تلك الواجهة إلى قرارات إصدار أفضل.

يجب قياس الدليل بالقرب من بوابة الإصدار الخاصة بالفريق. التقييم الناضج لن يسأل ما إذا كان بإمكان Sauce Labs تشغيل متصفح عصري أو نموذج هاتف شائع مرة واحدة. سيسأل ما إذا كانت نفس المجموعة يمكنها التشغيل بشكل متكرر، خلال حركة المرور الهندسية العادية، بجودة قطع أثرية كافية لتقصير وقت التحقيق. سيسأل ما إذا كانت حالات الفشل تتجمع بطريقة توجه العمل إلى المالك الصحيح.

سيسأل ما إذا كانت الجلسات في قائمة الانتظار تبقى ضمن نافذة الإصدار، وما إذا كان نقص الأجهزة العامة يتطلب إنفاقًا على الأجهزة الخاصة، وما إذا كانت الخطوط الأساسية البصرية تُراجع على الفور، وما إذا كانت صحة النفق مرئية قبل بدء الاختبارات، وما إذا كانت الأدلة الأقدم تُصدر قبل انتهاء صلاحية السجلات والفيديو. سيسأل أيضًا ما إذا كان المطورون يغيرون سلوكهم بعد رؤية نتائج Sauce Labs: هل يصلحون العيوب الحقيقية بشكل أسرع، ويزيلون الاختبارات غير المستقرة، ويضيقون التغطية غير المفيدة، أو يستمرون في إعادة تشغيل المهام حتى تظهر نتيجة خضراء؟

هذه الأسئلة خاصة بالمشتري حسب التصميم. بنك استهلاكي ذو رحلات جوال منظمة، وتاجر تجزئة مع حركة مرور ويب موسمية، واستوديو ألعاب مع تباين أجهزة ثقيل الأعطال، وشركة SaaS مع مستخدمي أعمال يعتمدون بشكل أساسي على Chromium، لا يشترون نفس النتيجة. قد يستخدمون جميعًا نفس السحابة، لكنهم يحتاجون إلى دليل مختلف. أقوى بيع لـ Sauce Labs ليس الثقة العالمية. إنه وعد أكثر وضوحًا وأضيق: حيث يكون عدم اليقين عبر المنصات مكلفًا، يمكن للمنصة أن تجعل ذلك عدم اليقين قابلاً للملاحظة بما يكفي للإدارة.

لذا فإن سؤال الشراء الأكثر صدقًا ضيق: بالنسبة للبيئات المهمة، هل يمكن لـ Sauce Labs مساعدة هذا الفريق على إنتاج نتائج اختبار مقبولة أكثر لكل دولار، ولكل ساعة، ولكل إصدار من البدائل؟ ستختلف الإجابة حسب نضج الاختبار، وتنوع الأجهزة، وإيقاع الإصدار، والضغط التنظيمي، وسطح الجوال، وتعقيد النفق، والاستعداد لصيانة مجموعة الاختبار.

لا ينبغي الحكم على Sauce Labs من خلال العرض التوضيحي الأكثر إثارة أو أكبر عدد من البيئات. يجب الحكم عليها في اللحظة التي يظهر فيها فشل اختبار دفع الجوال في CI، أو علامة فرق بصري على تغيير تصميم، أو سقوط نفق، أو خطأ في جلسة Appium، أو نجاح اختبار مولّد بالذكاء الاصطناعي، أو تحديث متصفح يكسر بوابة إصدار. إذا ساعدت المنصة الفريق في تحديد ما حدث وما يجب فعله بعد ذلك، فإنها تكسب مكانها. إذا كان الفريق لا يزال غير قادر على التمييز بين الإشارة والضوضاء، فإن الشبكة هي مجرد غرفة أكبر لعدم اليقين.