كل المقالات
QA CareerCodeAccessMocking

المختبِر لازم يكون قريب من الكود — والوصول مش رفاهية

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

6 دقائق قراءة

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

مش لأنه الشركة سيئة بالضرورة، لكن لأنه هذا بيحدّد سقف اللي تقدر توصله. وبيحدّد كمان شغلك رح يضل مطلوب لأي مدة.

الاختبار كصندوق أسود صار أرخص شي

خلينا نبدأ من الجزء اللي بيوجع.

الطريقة القديمة — الشركة بتعطيك بيئة اختبار وبس، وإنت بتفحص من برّا: تضغط، تعبّي، تشوف النتيجة، تقارنها بالمتطلب — هذه بالضبط النقطة اللي الـ AI شاطر فيها اليوم. توليد مدخلات، تجريب مسارات، مقارنة النتيجة بالوصف: كله شغل ما بيحتاج يعرف شو صاير جوّا.

فإذا كل قيمتك إنك تفحص من برّا، إنت عم تتنافس مع أرخص شي موجود بالسوق.

والمفارقة إنه نفس القاعدة بتنطبق على الـ Agents نفسها: الـ Agent اللي عنده وصول للكود بيعطي نتيجة أفضل بمراحل من اللي بيشتغل على الواجهة بس. إذا هذا صحيح للأداة، هو صحيح إلك.

شو بيتغيّر لما تفتح الكود

الواجهة (UI) الـ API منطق العمل والكود قاعدة البيانات صندوق أسود مع وصول للكود

بتفهم كيف بيشتغل التطبيق فعلاً. مش كيف المفروض يشتغل حسب الـ Story — كيف انبنى. وهذا الفرق هو بالضبط وين بتختبي أغلب العيوب.

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

بتبني الـ Mock Server. الـ Mocking كله قايم على إنك تعرف شكل الطلب والرد بين الخدمات. بلا كود، إنت بتخمّن.

بتضيف data-testid بنفسك. ما بتستنى حدا يضيفها إلك بعد أسبوعين — بتفتح الملف، بتضيف السطر، وبتعمل Pull Request.

وبتقرأ الـ Diff. هذه لحالها بتغيّر شغلك: بدل ما تخمّن شو تفحص بعد كل إصدار، بتشوف شو تغيّر بالضبط، وشو الملفات اللي انمسّت، وشو اللي ممكن ينكسر معها. هون بيصير الاختبار المبني على المخاطر شي حقيقي مش كلام بعروض تقديمية.

مثال بيوضّح النقطة: إجاك إصدار مكتوب بملاحظاته «تحسين أداء صفحة الطلبات».

بلا كود: بتفتح الصفحة، بتلاقيها سريعة وشغالة، بتمرّرها.

مع الكود: بتفتح الـ Diff وبتلاقي إنهم ضافوا Caching على الصفحة. وهسا صار عندك قائمة فحص مختلفة تماماً — شو بيصير لما المستخدم يعدّل طلب ويرجع للصفحة فوراً؟ بيشوف البيانات القديمة؟ وشو بيصير لمستخدمَين مختلفين على نفس الشاشة؟ وإمتى بتنتهي صلاحية الـ Cache؟

نفس الإصدار بالضبط. الفرق إنك عرفت شو تغيّر فعلاً، فعرفت وين تدوّر. ملاحظات الإصدار ما رح تقولك هذا أبداً.

وبتتغيّر تقاريرك. «الزر مش شغال» بتصير «الـ API بيرجّع 200 مع Body فاضي لما تكون قيمة الخصم null» — وهذه مش تقرير أفضل وبس، هذه علاقة مختلفة تماماً مع فريق التطوير.

مهم
«قريب من الكود» مش معناها تصير مطوّر. تقرأ كود شي، وتكتب ميزة كاملة شي ثاني تماماً. تقرأ Diff وتفهم شو انمسّ — هذه مهارة أسهل بكثير مما بيتخيّل الناس، وعائدها أكبر بكثير من أي أداة رح تتعلمها هذه السنة.

طيب شو تطلب بالضبط؟

خلي الطلب محدد، مش «بدي أصير قريب من الكود». هذه القائمة تقدر تاخدها لمديرك بكرا:

الوصول ليش
قراءة على الـ Repository تقرأ الـ Diff، وتفهم التنفيذ
تشغيل التطبيق محلياً تجرّب إعدادات وحالات مستحيلة على بيئة مشتركة
قراءة على قاعدة البيانات (غير الإنتاج) تتأكد من الحالة الحقيقية بدل ما تستنتجها من الشاشة
الـ Logs والمراقبة تعرف ليش فشل، مش إنه فشل بس
صلاحية على الـ CI تشوف نتائج التشغيل وتصلّح اختباراتك بنفسك

لاحظ إنه كلها قراءة وتشغيل، ما فيها ولا صلاحية خطيرة على الإنتاج.

«بس إحنا بنك، ما بينفع»

هذا اعتراض حقيقي ولازم ننصفه. في قطاعات — بنوك، صحة، دفاع — عندها قيود تنظيمية جدية على من بيشوف شو.

بس القيد الحقيقي دايماً بيكون على بيانات الإنتاج، مش على الكود. وبمعظم هذه الشركات الحل موجود ومطبّق فعلاً:

  • وصول قراءة على الـ Repository بلا صلاحيات نشر
  • قاعدة بيانات غير إنتاجية ببيانات مموّهة
  • بيئة محلية ببيانات مولّدة بالكامل

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

نصيحة
بالمقابلة الجاية، اسأل: «رح يكون عندي وصول قراءة على الـ Repository؟» جوابهم بيقولك عن مكانة الاختبار عندهم أكثر من أي شي ثاني بالإعلان.

من وين تبدأ إذا خلفيتك مش برمجية

ما لازم تبلّش من دورة برمجة كاملة. ابدأ بثلاث خطوات صغيرة، بالترتيب:

أول شي: اقرأ الـ Diff. على كل Pull Request، افتح قائمة الملفات المتغيّرة وبس. ما لازم تفهم كل سطر — بيكفي تعرف: أي ملفات انمسّت؟ الخدمة أي وحدة؟ فيها شي يمسّ الدفع؟ خلال شهر رح تصير تخمّن وين ممكن ينكسر قبل ما يفتح المطوّر تمّه.

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

ثالث شي: تعلّم SELECT. استعلام SQL بسيط بيخليك تتأكد من الحالة الحقيقية بقاعدة البيانات، بدل ما تستنتجها من الشاشة. هذه أقل استثمار وأعلى عائد بالقائمة كلها.

ثلاثتهم مجاناً، وولا واحد فيهم بيحتاج إذن غير الوصول نفسه.

ليش هذه النقطة بتجمع كل شي

ارجع لأي ممارسة حديثة بالاختبار، ورح تلاقيها بتفترض الوصول للكود:

  • الـ Shift Left بيقوم على إنه الاختبارات تعيش بنفس الـ Repository مع الكود
  • الـ Mock Server بيحتاج تعرف العقود بين الخدمات
  • الـ Locators الثابتة بتحتاج تعدّل بالواجهة
  • والـ Agents بتشتغل أفضل بمراحل لما تعطيها الكود مع الـ Jira

يعني الوصول للكود مش بند إضافي بالقائمة — هو الشرط اللي بيخلّي باقي القائمة ممكنة.

بالنهاية

الاختبار من برّا الصندوق ما اختفى، ورح يضل جزء من الشغل. بس صار الجزء الأرخص — واللي في أدوات بتعمله أسرع منك ومن غير ما تتعب.

القيمة اللي ما بتنستبدل هي إنك تربط النية بالتنفيذ: تقرأ المتطلب، وتقرأ الكود اللي نفّذه، وتشوف المسافة بينهم. وهذه ما تقدر تعملها وإنت واقف برّا.

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

بدك تتعمّق أكثر؟

المقال هون بيعطيك الفكرة. الدورات بتاخدك من الصفر لحد ما تشتغل فيها فعلياً.

شوف الدورات