كيف تُبنى البرمجيات
تطوير البرمجيات (Software development) هو كل العمل الذي يحوّل فكرة إلى برنامج يستطيع الناس استخدامه، ويُبقيه عاملاً بعد ذلك. وكتابة الكود جزء واحد منه فقط: فهناك من يقرر ماذا سيُبنى، ومن يصمم كيف يتصرف، ثم يكتب المطورون الكود، ويفحصه المختبِرون، ويتولى أحدهم إصداره وإبقاءه قيد التشغيل.
خذ مثلاً تطبيق بقالة يريد أن يتيح للعملاء تكرار طلب سابق بلمسة واحدة. قبل أن يُكتب أي كود، يقرر مالك المنتج (Product Owner) أن الميزة تستحق البناء، ويكتب محلل الأعمال (Business Analyst) القواعد (ماذا عن الأصناف التي نفدت؟)، ويرسم المصمم الشاشة. وكما رأيت في الدرس السابق، يبني البشرُ البرمجيات، فكل خطوة موضعٌ قد يدخل فيه خطأ أو يُكتشف.
لماذا يهم
المختبِر الذي لا يرى إلا الشاشة النهائية لا يرى إلا آخر حلقة في سلسلة طويلة. فكثير من العيوب يبدأ قبل الكود أو خارجه: متطلب غامض، أو تصميم بلا حالة خطأ، أو إعداد يختلف بين البيئات. ومعرفة أي خطوة أنتجت أي مُخرَج تتيح لك تتبّع الإخفاق (Failure) إلى مصدره، وطرح أسئلتك ما دام التغيير رخيصاً.
وتخبرك هذه المعرفة أيضاً بمن تسأل وبما تسجّل: فنتيجة الاختبار لا معنى لها إلا إذا ذكرت البناء والبيئة اللذين جاءت منهما.
الأشخاص: الأدوار في فريق البرمجيات
الدور مجموعة مسؤوليات وليس مسمّى وظيفياً: فقد يشغل شخص واحد عدة أدوار، وقد يكون دور واحد فريقاً كاملاً.
- مالك المنتج (Product Owner): يقرر ما الذي يفعله المنتج بعد ذلك وبأي ترتيب؛ وهو في سكرم (Scrum) المسؤول عن تعظيم قيمة المنتج وعن إدارة قائمة مهام المنتج (Product Backlog)، أي القائمة المرتبة لما يلزم لتحسينه.
- محلل الأعمال (Business Analyst): يحدد التفاصيل (قواعد العمل والبيانات والاستثناءات) ويكتبها متطلباتٍ؛ وبعض الفرق تترك ذلك لمالك المنتج.
- المصمم (Designer): يقرر كيف سيستخدم الناس الميزة: المسارات والتخطيط والصياغة، والحالات مثل الحالة الفارغة وحالة التحميل وحالة الخطأ.
- المطوّر (Developer): يحوّل المتطلبات والتصاميم إلى كود، ويكتب اختبارات الوحدة، ويراجع كود زملائه، وغالباً في طبقة واحدة مثل الواجهة الأمامية أو الخلفية.
- المختبِر أو مهندس ضمان الجودة (Tester / QA engineer): يراجع المتطلبات والتصاميم، وينفذ الاختبارات، ويبلّغ عن العيوب، ويزوّد الفريق بمعلومات عن الجودة لقرار الإصدار.
- مهندس DevOps أو العمليات: يعتني بخط الأنابيب (Pipeline) الذي يبني الكود وينشره، وبالبيئات، وبمراقبة الإنتاج. وبالمعنى الدقيق فإن DevOps طريقة عمل للفريق كله، لكنه أيضاً مسمّى وظيفي شائع.
مخرجات العمل: ما تسلّمه كل خطوة للتي تليها
كل خطوة تنتج شيئاً تستخدمه التالية. ويسمي ISTQB هذه المخرجات «مخرجات العمل» (Work products)، وتسميها فرق كثيرة Artifacts. وهي تهمّ المختبِر مرتين: فهو يختبر في ضوئها، ويستطيع أن يختبرها هي نفسها بمراجعتها قبل تشغيل أي كود. وهي تتغير أيضاً: فإذا عُدّل أحدها فقارن النسخة القديمة بالجديدة لتعرف أي الاختبارات تأثرت.
- المتطلبات: قصص المستخدم (User stories) مع معايير القبول (Acceptance criteria)، وقواعد العمل، وأهداف مثل زمن الاستجابة. والقصة أدناه مثال نموذجي.
- التصاميم: المخططات الأولية (Wireframes) والنماذج الأولية من المصمم، والبنية المعمارية وعقود الواجهات البرمجية (API contracts) من المطورين.
- الكود: ملفات مصدرية في نظام للتحكم في النسخ مثل Git؛ وفي فرق كثيرة يُراجَع كل تغيير في طلب دمج (Pull request) قبل دمجه.
- البناء (Build): حزمة قابلة للتشغيل تُصنع، آلياً في الغالب، من نسخة محددة تماماً من الكود، ولها معرّف خاص بها؛ وقد ينتج الفريق بناءات كثيرة في اليوم.
- الإصدار (Release): بناء قرر الفريق تسليمه للمستخدمين، له رقم إصدار وملاحظات إصدار (Release notes).
STORY-142 تطبيق رمز ترويجي عند الدفع
بصفتي متسوقاً
أريد تطبيق رمز ترويجي في صفحة الدفع
كي أدفع السعر بعد الخصم.
AC1 الرمز الصالح يُخفّض إجمالي الطلب قبل الدفع.
AC2 الرمز المنتهي تظهر معه رسالة «انتهت صلاحية هذا الرمز».
AC3 لا يمكن تطبيق أكثر من رمز واحد على الطلب.من الفكرة إلى التشغيل
اجمع الأدوار ومخرجات العمل معاً تحصل على المسار الذي يقطعه كل تغيير. والوحدة التعليمية التالية تسمّيه دورة حياة تطوير البرمجيات (SDLC) وتقارن النماذج التي تنظمه بها الفرق؛ وهذه هي الصورة المبسطة.
- 1الفكرةمالك المنتجبند في قائمة المهام من الملاحظات أو هدف تجاري أو لائحة تنظيمية
- 2المتطلباتمالك المنتج ومحلل الأعمالقصص المستخدم ومعايير القبول وقواعد العمل
- 3التصميمالمصمم والمطورونالشاشات والمسارات وعقود الواجهات البرمجية وتغييرات البيانات
- 4البناءالمطورونكود مُراجَع، وخط الأنابيب ينتج بناءً
- 5الاختبارالمختبِروننتائج الاختبار وتقارير العيوب واختبارات التأكيد
- 6الإصداريقرر مالك المنتج وينشر مهندس DevOpsرقم إصدار وملاحظات إصدار
- 7التشغيلمهندس DevOps والدعم والفريق كلهالمراقبة وبلاغات المستخدمين والفكرة التالية
طوال الخطوات 2–7 يشارك المختبِرون طوال المسار: يراجعون المتطلبات والتصاميم، ويختبرون البناءات، ويتحققون من الإصدارات، ويقرؤون ملاحظات الإنتاج.
عودة إلى الخطوة 1 ما يتعلمه الفريق أثناء التشغيل يصبح الفكرة التالية
صورة مبسطة: تتداخل الخطوات وتتكرر مع كل تغيير، وقد يشغل شخص واحد عدة أدوار.
وانتبه إلى أمرين. الخطوات تتداخل وتتكرر: فالعيب يعيد العمل إلى البناء، والمتطلب الغامض يعيده إلى المتطلبات. والمختبِرون لا يقتصرون على خطوة الاختبار: فمنهج ISTQB للمستوى التأسيسي يوصي بأن يقابل كلَّ نشاط تطوير نشاطُ اختبار، وبأن يراجع المختبِرون مخرجات العمل بمجرد توفر مسوداتها.
- الفكرة: ملاحظات أو هدف تجاري أو لائحة تنظيمية؛ ويقرر مالك المنتج هل تستحق التنفيذ.
- المتطلبات: قصص وقواعد ومعايير قبول يراجعها المختبِرون.
- التصميم: الشاشات والمسارات من المصمم، والتصميم التقني من المطورين.
- البناء: يُكتب الكود ويُراجَع، وينتج خط الأنابيب بناءً.
- الاختبار: تُنفَّذ الاختبارات على البناء في بيئة الاختبار، وتُختبر الإصلاحات من جديد، وهذا ما يسمى اختبار التأكيد (Confirmation testing).
- الإصدار: يقرر الفريق أن البناء جاهز، فيُنشر في الإنتاج مع ملاحظات الإصدار.
- التشغيل: يراقب الفريق النظام العامل ويدعم مستخدميه، وما يتعلمه يصبح الفكرة التالية.
مثال تطبيقي: رمز ترويجي من الفكرة إلى التشغيل
يتلقى متجر إلكتروني رسائل دعم متكررة من عملاء لا يجدون أين يُدخلون رمز الخصم. فينقل مالك المنتج حقل الرمز الترويجي إلى أعلى قائمة المهام، ويكتب محلل الأعمال القصة STORY-142. تابعها عبر بقية الخطوات:
- المتطلبات: يسأل المختبِر ماذا يحدث للخصم إذا حُذف صنف، وهل تختلف الرموز باختلاف حالة الأحرف الكبيرة والصغيرة. وتصبح الإجابتان المعيارين AC4 وAC5 قبل وجود أي كود.
- التصميم: يطلب المختبِر حالة تحميل، لأن التحقق من الرمز يستدعي الخادم.
- البناء والاختبار: بعد دمج طلب الدمج 318 يُنتج خط الأنابيب البناء 1047 وينشره في بيئة الاختبار. فيبلّغ المختبِر عن عيبين، يذكر كلٌّ منهما البناء 1047 والمعيار الذي لم يتحقق، ثم يتأكد من الإصلاحات في البناء 1049 (اختبار التأكيد).
- الإصدار: يذهب البناء 1049 إلى الإنتاج بوصفه الإصدار 4.6.0، ويُجري المختبِر فحصاً قصيراً بعد النشر مباشرةً.
- التشغيل: يبلّغ مستخدم أن رمزاً صالحاً رُفض بسبب مسافة زائدة في آخره. فيدخل الإصلاح في الإصدار التالي مع اختبار انحدار (Regression) جديد، وتكتمل الحلقة.
جرّبها: مولّد معايير القبول جرّبها: قصة المستخدم ← سيناريوهات اختبار
أخطاء شائعة
- الظن أن الاختبار يبدأ حين ينتهي الكود. فالمتطلبات والتصاميم يمكن مراجعتها، وكشف عيوبها، قبل وجود أي كود.
- معاملة الخطوات كخط ذي اتجاه واحد؛ فالعمل يعود إلى الوراء كلما ظهر عيب أو متطلب غامض.
- اختبار «التطبيق» بدلاً من بناء محدد: فتقرير العيب الذي لا يذكر البناء والبيئة يتعذّر غالباً إعادة إنتاج ما يصفه.
- الاختبار في ضوء ما تعرضه الشاشة بدلاً من المتطلب، فلا تستطيع التمييز بين العيب والسلوك المقصود.
- افتراض أن الجودة مهمة المختبِر وحده. فمنهج ISTQB يصف نهج الفريق الكامل (Whole-team approach) الذي يكون فيه كل فرد مسؤولاً عن الجودة.
من منظور ضمان الجودة
في الفريق الحقيقي اعرف لكل عمل في أي خطوة هو، وأي مُخرَج هو المرجع المعتمد، ومن يملكه؛ فهذا يخبرك بمن تسأل. قواعد العمل لمالك المنتج أو المحلل، وحالات الشاشة للمصمم، و«أي بناء يحتوي الإصلاح؟» للمطور. واحضر جلسات تحسين قائمة المهام (Backlog refinement)، فهناك تكون الأسئلة أرخص ما تكون.
وسجّل المعرّفات في كل مكان: كل نتيجة اختبار وكل تقرير عيب يذكر المتطلب، والبناء أو الإصدار، والبيئة. وبعد الإصدار اقرأ إشارات الإنتاج وبلاغات المستخدمين، فهي تُظهر ما فاتته اختباراتك.
تمرين عملي
تتبّع ميزة من الفكرة إلى التشغيل
يريد تطبيق لحجز مواعيد عيادة أن يرسل إلى المرضى رسالة نصية للتذكير قبل موعدهم بـ24 ساعة. اكتب لكل خطوة من الخطوات السبع الدورَ الرئيسي، ومُخرَج العمل، وشيئاً واحداً يستطيع المختبِر فعله أو السؤال عنه. ثم اذكر ما يجب أن يتضمنه تقرير العيب حتى يعرف المطور بالضبط أي نسخة أخفقت.
إظهار الإجابة النموذجية
الفكرة — مالك المنتج؛ بند في قائمة المهام. اسأل كيف سيُقاس النجاح، مثل انخفاض المواعيد الفائتة.
المتطلبات — مالك المنتج أو محلل الأعمال؛ قصة مع معايير قبول. اسأل: ماذا لو حُجز الموعد قبل أقل من 24 ساعة؟ وأي منطقة زمنية تُعتمد؟ وماذا لو ألغى المريض الموعد بعد التذكير؟
التصميم — المصمم والمطورون؛ صياغة الرسالة بكل لغة والتصميم التقني للمهمة المجدولة. اسأل كيف تُسجَّل حالات فشل الإرسال.
البناء — المطورون؛ الكود والبناء. جهّز مواعيد بعد 23 و24 و25 ساعة، واسأل كيف تُشغَّل المهمة دون انتظار يوم كامل.
الاختبار — المختبِر؛ نتائج الاختبار وتقارير العيوب. نفّذ الحالات المُجهَّزة، ومنها حجز أُلغي بعد التذكير، باستخدام أرقام هواتف مخصصة للاختبار لا أرقام مرضى حقيقيين.
الإصدار — يقرر مالك المنتج وينشر مهندس DevOps؛ رقم الإصدار وملاحظاته. تحقّق من أن التذكيرات تُجدوَل في الإنتاج.
التشغيل — مهندس DevOps والدعم؛ مراقبة الرسائل التي فشل إرسالها. حوّل الشكاوى إلى حالات اختبار جديدة.
تقرير العيب: البناء أو الإصدار، والبيئة، والمتطلب أو المعيار الذي يخالفه، وتاريخ الاختبار ووقته ومنطقته الزمنية، لأن التذكيرات تعتمد على الوقت.
أسئلة شائعة
هل أحتاج إلى معرفة البرمجة لأعمل ضمن هذه العملية؟
ليس في البداية. يحتاج المختبِر إلى فهم الخطوات، وقراءة مخرجات العمل، والتواصل مع كل الأدوار. وتصبح قراءة الكود مفيدة لاحقاً، مثلاً عند مراجعة اختبارات الوحدة أو أتمتة الفحوص، وتعلّمها وحدات الأتمتة في خارطة الطريق هذه.
هل هذه هي دورة حياة تطوير البرمجيات (SDLC)؟
إنها معاينة مبسطة لها. يصف ISTQB دورة حياة تطوير البرمجيات بأنها الأنشطة التي تُنفَّذ في كل مرحلة من مراحل تطوير البرمجيات وكيف ترتبط ببعضها منطقياً وزمنياً. ونماذج مثل الشلال (Waterfall) ونموذج V والنماذج الرشيقة (Agile) ترتّب الأنشطة نفسها بطرق مختلفة، وتقارن بينها الوحدة التعليمية التالية.
ما الفرق بين البناء والإصدار؟
البناء حزمة قابلة للتشغيل تُصنع من نسخة واحدة من الكود، وقد ينتج الفريق منها الكثير في اليوم، ومعظمها يُختبر فقط. أما الإصدار فبناء قرر الفريق تسليمه للمستخدمين، له رقم إصدار وملاحظات إصدار. فكل إصدار بناء، لكن معظم البناءات لا تُصدَر أبداً.
ما بيئة الاختبار، ولماذا لا نختبر في الإنتاج مباشرةً؟
بيئة الاختبار نسخة منفصلة من النظام تُثبَّت عليها البناءات للاختبار، وتحتوي بيانات اختبار بدلاً من بيانات العملاء الحقيقيين. فالاختبار فيها يعني أن الإخفاق لا يضر أي مستخدم حقيقي، وأن البيانات يمكن إعادة ضبطها. وتُجرى بعض الفحوص في الإنتاج أيضاً بعد الإصدار، لكن بحذر وبموافقة الفريق.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- ISTQB Glossaryالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
- The 2020 Scrum Guideتعريف Scrum: مسؤولياته وأحداثه ومخرجاته، بما فيها تعريف الإنجاز (Definition of Done) الذي يساعد الاختبار على تحقيقه.
- About pull requestsما طلب السحب (Pull Request): اقتراح لدمج تغييرات من فرع في آخر، مع مساحة للنقاش والمراجعة وتشغيل الفحوص قبل الدمج.
تدرّب بأدوات متقن
ولّد معايير قبول بصيغة Given/When/Then وقائمة تحقق لتعريف الإنجاز (Definition of Done) من قصة مستخدم.
اشتق سيناريوهات اختبار شاملة (end-to-end) من قصة مستخدم، بما فيها التدفقات البديلة والاستثنائية.
حوّل قائمة متطلبات مرقّمة إلى حالات اختبار قابلة للتتبّع مع مصفوفة تربط المتطلبات بالاختبارات.
قارن نصّين سطراً بسطر أو كلمةً بكلمة مع إبراز الاختلافات.
للتعمّق أكثر
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.