من الشغلات اللي ترفع إنتاجيّة المبرمج عشان يختصر الوقت ويبرمج بثقة - غير الـ automated tests - هو وجود scripts تخلق states معيّنة ينطلق منها عشان يحل المشكلة ويختبر حله شخصيًا بسهولة ويلقى الأخطاء ويصلّحها قبل ما يسلّم الشغل .. ?
إذا هالشيء غير متوفر, غالبًا بيسوي التالي:
إذا هالشيء غير متوفر, غالبًا بيسوي التالي:
?ممكن يبدأ مباشرة بقراءة الكود بناء على تقرير المشكلة لإستنتاج الحل والعمل عليه فورًا..
هالأسلوب منطقي كبداية لكنه لا يعتمد عليه لإنشاء conclusion لأن كل ما يفسّره المبرمج هو بناء على استيعابه الشخصي في تلك اللحظات دون الأخذ بالإعتبار كل الأشياء الأخرى التي قد لا يعرفها .. ❌
هالأسلوب منطقي كبداية لكنه لا يعتمد عليه لإنشاء conclusion لأن كل ما يفسّره المبرمج هو بناء على استيعابه الشخصي في تلك اللحظات دون الأخذ بالإعتبار كل الأشياء الأخرى التي قد لا يعرفها .. ❌
من تجربة شخصيّة هذا النوع من المبرمجين ( خصوصًا اللي ما يختبر شغله) هو الأسوء على الفريق!
الظاهر في نظام تتبع التذاكر إن إنتاجيته عالية كون التذكرة ما تطوّل عنده, ولكن في الواقع هو ممكن يضيّع وقت زملاءه من ناحية أن إصلاح المشكلة غير دقيق, أو أن هالإصلاح تتسبب في مشكلة أخرى!
الظاهر في نظام تتبع التذاكر إن إنتاجيته عالية كون التذكرة ما تطوّل عنده, ولكن في الواقع هو ممكن يضيّع وقت زملاءه من ناحية أن إصلاح المشكلة غير دقيق, أو أن هالإصلاح تتسبب في مشكلة أخرى!
?ممكن يحاول إحداث المشكلة يدويًا بناء على التقرير..
هالأسلوب ممتاز ولكن مو كل المبرمجين يتبعونه بدقّة, خصوصًا للمشاكل اللي تتطلب test data خلقها معقّد.
غالبًا سيحاول المبرمج أخذ إختصارات لخلق الحالة, عيب هالأسلوب - غير عدم دقته - هو إمكانية الوقوع في مشاكل الـ data integrity❌
هالأسلوب ممتاز ولكن مو كل المبرمجين يتبعونه بدقّة, خصوصًا للمشاكل اللي تتطلب test data خلقها معقّد.
غالبًا سيحاول المبرمج أخذ إختصارات لخلق الحالة, عيب هالأسلوب - غير عدم دقته - هو إمكانية الوقوع في مشاكل الـ data integrity❌
من تجربة شخصيّة من أسوء أنواع المشاكل هي اللي يكون سببها داتا مضروبة! تدوش الفريق لأنه ما يدري هل هي مضروبة بسبب التعبّث في الـ DB؟ أو بسبب bug فعلا؟
دائمًا أطلب من المبرمج يعيد إحداث المشكلة كما وصفتها له عشان نتفادى هذا النوع من المشاكل اللي تضيّع الوقت وتشتت التركيز..
دائمًا أطلب من المبرمج يعيد إحداث المشكلة كما وصفتها له عشان نتفادى هذا النوع من المشاكل اللي تضيّع الوقت وتشتت التركيز..
? ممكن يكون "رايق" ويحاول إحداث المشكلة يدويًا بناء على التقرير مهما كانت الخطوات معقدة!
هذا المبرمج يستاهل "مطخة" على جبينه لأنه "نظامي" ويحاول إصلاح المشكلة بعد ما يقع فيها بشكل Organic! ✅
عيب هالأسلوب إن المبرمج قد يأخذ وقت طويل لمجرد خلق الـ state اللي تساعده يبدأ!
هذا المبرمج يستاهل "مطخة" على جبينه لأنه "نظامي" ويحاول إصلاح المشكلة بعد ما يقع فيها بشكل Organic! ✅
عيب هالأسلوب إن المبرمج قد يأخذ وقت طويل لمجرد خلق الـ state اللي تساعده يبدأ!
الوقت الطويل اللي يأخذه المبرمج عشان يعيد إحداث المشكلة بطريقة نظاميّة, هو جهد قيمته لحظيّة وتنتهي, وهو نفس الوقت والجهد اللي يستغرقه الـ tester عشان يتأكد إن المشكلة إنحلت (كل مرة)..
ما تلاحظون فيه double work؟
هنا تجي القيمة الكبيرة من الـ scripts اللي تخلق الـ states!
ما تلاحظون فيه double work؟
هنا تجي القيمة الكبيرة من الـ scripts اللي تخلق الـ states!
مثال واقعي عشان تتضح الصورة:
متجر متكامل يبيع أونلاين ورابط تقنيًا مع شركة لتوصيل الطلبات, وشركة التوصيل تعطيه خدمة تتبع الطلب عشان يشاركها مع عملاءه أثناء التوصيل..
متجر متكامل يبيع أونلاين ورابط تقنيًا مع شركة لتوصيل الطلبات, وشركة التوصيل تعطيه خدمة تتبع الطلب عشان يشاركها مع عملاءه أثناء التوصيل..
الخاصيّة: الطلب اللي يرفض إستلامه العميل بسبب عدم توفره وقتها بعد ما طلع السوّاق للتوصيل, المفروض إن العميل يقدر يعيد جدولة توصيل الطلب من التطبيق في تلك الحالة..
المشكلة: الطلب جالس يتكنسل تمامًا, ولازم العميل يطلب ويدفع من جديد!
المشكلة: الطلب جالس يتكنسل تمامًا, ولازم العميل يطلب ويدفع من جديد!
على حسب المبرمج (ومزاجه ذاك اليوم) قد يحاول حل المشكلة بأحد الأساليب اللي شاركتها أعلاه..
أفضل سيناريو على الإطلاق هو إنه يعيد إحداث المشكلة بحذافيرها, ولكن زي ما تشوفون راح يأخذ وقت, لأنه يحتاج يسوي كل التالي (بافتراض ان المتجر ومنتجاته موجودين في البيئة الاختبارية):
أفضل سيناريو على الإطلاق هو إنه يعيد إحداث المشكلة بحذافيرها, ولكن زي ما تشوفون راح يأخذ وقت, لأنه يحتاج يسوي كل التالي (بافتراض ان المتجر ومنتجاته موجودين في البيئة الاختبارية):
- تسجيل مستخدم جديد
- توثيق بريد المستخدم
- البحث عن منتج
- إضافته في السلة
- اختيار موقع التوصيل
- الدفع الإلكتروني
- انتظار تأكيد شركة الشحن بإستلام الطلب
- تغير حالة الشحنة بعد الحصول على رقم التتبع
- تغير حالة الشحنة إلى جاري التوصيل
- رفض استلام الطلب من العميل
- توثيق بريد المستخدم
- البحث عن منتج
- إضافته في السلة
- اختيار موقع التوصيل
- الدفع الإلكتروني
- انتظار تأكيد شركة الشحن بإستلام الطلب
- تغير حالة الشحنة بعد الحصول على رقم التتبع
- تغير حالة الشحنة إلى جاري التوصيل
- رفض استلام الطلب من العميل
على فرض إن المبرمج لقى المشكلة وحلها من المرة الأولى, أفضل سيناريو على الإطلاق كذلك إنه يعيد نفس الخطوات السابقة عشان يتأكد إن حله صحيح! (وقت إضافي!)
هنا يجي الـ scripting المفيد اللي لو كان موجود كان قدر يستخدمه من البداية عشان يخلق الحالة ويختصر الوقت!
مثلًا:
هنا يجي الـ scripting المفيد اللي لو كان موجود كان قدر يستخدمه من البداية عشان يخلق الحالة ويختصر الوقت!
مثلًا:
- سكربت وظيفته يسجّل يوزر جديد ويوثّق بريده الإلكتروني
- سكربت وظيفته يُنشئ طلب جديد تحت هاليوزر ويتمم الشراء واختيار مكان التوصيل
- سكربت وظيفته يمشّي حالات الشحنة إلى "جاري التوصيل"
حرفيًا المبرمج يشغل هالسكربتات الثلاثة ويبدأ شغله الأساسي لـ تشخيص المشكلة وحلّها في ثواني!
- سكربت وظيفته يُنشئ طلب جديد تحت هاليوزر ويتمم الشراء واختيار مكان التوصيل
- سكربت وظيفته يمشّي حالات الشحنة إلى "جاري التوصيل"
حرفيًا المبرمج يشغل هالسكربتات الثلاثة ويبدأ شغله الأساسي لـ تشخيص المشكلة وحلّها في ثواني!
من تجربة شخصيّة, الفكرة فعّالة واختصرت وقت وجهد علينا, لكنها تحتاج تنفيذ بطريقة حذره!
أسلم أسلوب وجدناه هو إعادة استخدام الـ business logic APIs بالتسلسل الصحيح لخلق الحالة كما ينبغي, وكأننا نحاكى أن المتصفح أو الجهاز جالس يتخاطب REST مع الـ BE لخلق الحالة بطريقة Organic..
أسلم أسلوب وجدناه هو إعادة استخدام الـ business logic APIs بالتسلسل الصحيح لخلق الحالة كما ينبغي, وكأننا نحاكى أن المتصفح أو الجهاز جالس يتخاطب REST مع الـ BE لخلق الحالة بطريقة Organic..
الأسلوب أعلاه هو أحد أهم عناصر نجاح الـ test automation في الفريق, اللي لازم "المبرمجين" يفكرون فيه أثناء كتابة الكود..
دائمًا نسمع إن الكود لازم يكون testable, ولكن عشان تتعظّم قيمة الـ test automation لازم يكون حتى automatable باستخدام التكنيكات أعلاه..
دائمًا نسمع إن الكود لازم يكون testable, ولكن عشان تتعظّم قيمة الـ test automation لازم يكون حتى automatable باستخدام التكنيكات أعلاه..
اللي وعّاني على هالأفكار الرائعة (وغيرها) هي المهندسة @techgirl1908 في كورسها المجاني الرهيب: ?
angiejones.tech
الأكثر جمالًا هو أن هالسكربتات يمكن إعادة استخدامها لتوسيع الـ automated tests coverage وجعل الاختبارات أسرع, وأصلب, وأكثر كفاءة! ?
angiejones.tech
الأكثر جمالًا هو أن هالسكربتات يمكن إعادة استخدامها لتوسيع الـ automated tests coverage وجعل الاختبارات أسرع, وأصلب, وأكثر كفاءة! ?
جاري تحميل الاقتراحات...