ينبغي أن تكون قادراً

على الدخول الآن. هل

هناك أي أحد آخر؟

موجود هنا. حتى نغلق

موضوع تليجرام. حسناً،

ينقصني إسكالانتي، هو

الوحيد الذي لا يزال

ينقصني، لكني لا أعرف

تحت أي اسم هو موجود،

فهو ليس مسجلاً باسم

إسكالانتي ولا باسم

تشونغ إسكالانتي، لذا

لا، ليس لدي. حسناً،

إذن ليس لديكم أي

أسئلة حول الفصول

الافتراضية، هل

تمكنتم من رؤية كل شيء

محملاً؟ الاختباران

الجزئيان حضوريان،

وكذلك الاختبار

التعويضي بالطبع. إيه،

هناك ثلاث مهام عملية،

كما أخبرتكم. حسناً،

إيه، سنقوم بـ

>> حسناً، عن ماذا يتحدث

المحتوى؟ بالطبع هناك

إيه جزء النماذج

والمنهجيات والعمليات

، حيث لا يزال جزء

النماذج والمنهجية

نظرياً كما أخبرتكم،

وفقط في جزء العمليات

سنقوم بالجزء العملي،

أي من المنهجية فما

قبلها. سنقوم بتمرين

عملي حيث ستضعون فيه

مهاراتكم قيد

الاختبار. من ناحية

أخرى، لدينا أنواع

الاختبارات. حسناً،

سنرى هناك أنواع

الاختبارات المختلفة

الموجودة، وهي كثيرة؛

وكيف يتم تنظيمها،

وكيف نرتبها في

أذهاننا حتى لا تكون

المفاهيم مشتتة، بل في

صناديق، لنسمّها هكذا

؛ وأن كل شيء يُستخدم

في لحظة مختلفة لنتمكن

من بناء استراتيجية

اختبار جيدة لمواجهة

مشاريع جديدة أو

إضافتها إلى مشروع

موجود بالفعل. وأخيراً

سنرى جزء التقنيات،

حسناً، والذي سيخبرنا

كيف سنجري هذا

الاختبار بطريقة أكثر

تنظيماً وهيكلة حتى لا

تكون مجرد أفكار أولية

تخطر ببالكم. حسناً.

إيه، وهنا يخطر ببالي

عدم جعل الطريقة التي

نولد بها الاختبارات

نظامية لنبدأ. حسناً.

إيه، نعم، لكنه ليس

موجوداً باسم جون

إسكالانتي، إيه؟ لقد

تأكدت بالفعل، ليس لدي

"جون إسكالانتي" محظور

، يجب أن يكون قادراً

على الدخول، لذا إذا

لم يستطع الدخول،

بصراحة لا أعرف، لقد

راجعت ذلك، ليس لدي أي

إسكالانتي محظور، إيه

؟ لكن حسناً، إذا لم

يكن موجوداً عندما

يأتي، ليس هناك

إسكالانتي، عندما

يأتي سنراجع الأمر،

إيه؟ التحقق والصحة. "

التحقق والصحة" تشير

إلى عمليتي رقابة وهما

التحقق والصحة. التحقق

والصحة مفهومان مهمان

جداً في هندسة

البرمجيات. حسناً،

لهذا يتم دراستهما

ومعرفتهما معاً، لذا

إذا بحثتم عنهما في

جوجل ستجدونهما كـ "

التحقق والصحة". حسناً.

لقد أخبرتكم للتو أن

التحقق (Validation)

والتحقق (Verification) هما

عمليتان للرقابة. ولكن

، ماذا يراقبان؟ إنهما

يراقبان أن النظام يتم

تطويره وفقًا

للمواصفات وأنه يلبي

توقعات واحتياجات كل

من العملاء والمستخدم

الذي سيستخدمه. حسنًا.

و، ما هو الفرق بالضبط

بين هذين الأمرين،

التحقق والتحقق؟ من

ناحية، لدينا التحقق (

Validation). يتحقق هذا

النوع مما إذا كان

المنتج سيلبي

المتطلبات ويجيب على

السؤال: هل نحن نبني

البرنامج بشكل صحيح؟

هل نراقب كل ما لدينا

من النظام، النموذج

الذي نملكه لهذا

النظام مقابل

المستخدم، لنرى ما إذا

كان ذلك النموذج، ذلك

التمثيل، ذلك التجريد

الذي قمنا به لما

سنبنيه يلبي التوقعات

؟ وعندما أتحدث عن

نموذج، فأنا أشير إلى

الطريقة التي ستأتي

بها تلك المواصفات.

المتطلبات، سنرى

لاحقًا قصص المستخدم،

حسنًا، ما هو النموذج.

لأننا كمتخصصي ضمان

جودة (QA) سنشارك في

عملية بناء البرمجيات.

حسنًا. وهو ما سنراه

لاحقًا. إذن، ما سنقوم

به هو بناء البرنامج. و

الآن، كيف تأتي

مواصفات ذلك البرنامج

الذي أريد بناءه؟

حسنًا. و، كيف ستأتي

تلك المتطلبات حتى

أتمكن من فهمها

واختبارها؟ حسنًا،

ستأتي كما قلت لكم

كقصص مستخدم (user stories)،

وهي عبارة عن قصص. وهذا

سنراه لاحقًا، وسأشرح

لكم ما تحتويه وكيف

يتم إعداد قصة

المستخدم. و، قد تأتي

مع نوع من الرسوم

البيانية، أو بوصف

حرفي لمتطلب ما. إذن،

ستأتي بأشكال مختلفة،

وهذه الأشكال خارج

نطاق هذه الدورة.

حسنًا، لأن رؤيتها أمر

واسع جدًا. إذن،

بالعودة إلى مفهوم

التحقق، من المهم

إجراء عمليات التحقق

في أقرب وقت ممكن

للبدء في بناء نظام

يلبي التوقعات. لأنه

إذا لم يتم التحقق من

تلك التوقعات منذ

البداية، فكل ما نبنيه

لاحقًا سيكون حول شيء

لا يريده العميل. لذلك

، من المهم جدًا

دائمًا التحقق من

النموذج مقابل

المستخدم الرئيسي،

المستخدم النهائي، أو

مقابل العميل المتاح

لدينا، ممن له كلمة

مسموعة. ومن ناحية

أخرى لدينا التحقق (

Verification)، الذي يراقب

أن المنتج الذي يتم

بناؤه يحترم

المواصفات الأولية.

هذا البرنامج الذي

نبنيه يقوم بما يفترض

به أن يقوم، وينفذ ما

تنص عليه المواصفات.

إذن هو يجيب على سؤال:

هل نبني النظام بشكل

صحيح؟ نحن نقوم بما

قلنا إننا سنقوم به.

لذا، بدلاً من مقارنة

النموذج مع المستخدم،

سنقوم بمقارنة ما

لدينا في النظام مقابل

النموذج. لماذا؟ لأن

النموذج قد تم التحقق

منه بالفعل. جيد.

ولماذا من المهم ذكر

هذا في بداية الدورة؟

لأنه على الرغم من

أننا نقوم بعمليات

التحقق (Validation) في

الاختبار، إلا أن معظم

جهدنا ينصب على عمليات

التأكد (Verification). حسناً

، إذن، باختصار شديد،

يمكننا القول إن

التحقق (Validation) يجيب

على سؤال: هل نبني

النظام الصحيح؟

ويقارن المستخدم بما

لدينا في النظام. أما

التأكد (Verification) فيجيب

على سؤال: هل نبني

النظام بشكل صحيح؟

ويقارن النظام

بالنماذج. إذا أردتم

مثالاً أكثر واقعية

وملموسة، حسناً، ربما

يمكننا التفكير في

مثال أستخدمه دائماً،

وهو بناء منزل. ما الذي

نفعله؟ على الأرجح،

سيأتي مهندس معماري

أولاً برسم هندسي،

وسيقوم بالتحقق من هذا

الرسم مع المستخدم أو

العميل، ليقول: "هل من

المناسب أن تكون

النوافذ هنا، والمطبخ

هنا، والحمام هناك؟"

حسناً، إذا كانت

الإجابة نعم، نبدأ في

بناء المنزل. تخيلوا

لو قمنا ببناء منزل

دون التحقق من الرسم

الهندسي. عندما يرغب

العميل في النهاية

بإجراء تغيير، سيكون

الأمر صعباً جداً

ومكلفاً للغاية،

بالإضافة إلى أن

المنزل عند اكتماله لن

يلبي توقعاته. سيخسر

العميل الكثير من

المال، لذا فإن هذا

الرسم هو بمثابة

النموذج. الآن، يجب

علينا التأكد من

المنزل المبني مقابل

الرسم الهندسي. يتم

التحقق من الرسم مع

العميل، بينما نتأكد

من المنزل مقابل الرسم

. هذا المثال يترجم ما

قلته لكم للتو عن

النظرية في سياق بناء

منزل. لننظر إلى متطلب

معين. حسناً، كنت أقول

إنه يجب علينا إجراء

عمليات التحقق في أقرب

وقت ممكن لأن التغافل

وأخطاء التواصل

غالباً ما تجعل

التواصل معقداً

للغاية. ولاحظوا في

هذا المتطلب، أريد أن

يتمكن الأطفال من

القفز من ارتفاع معين

إلى الأرض دون أن

يصابوا بأذى. المثالي

هو أن يتمكن الأطفال

من الانزلاق عبر ذلك

السطح. حسناً؟ هل

المتطلب مفهوم؟ هل هذا

جيد؟ حسناً، ما الذي

سنقوم ببنائه؟ عندما

أسأل هذا، ما الذي

سنقوم ببنائه؟ حسنًا،

نظرًا لأن هذا المطلب

يأتي إليكم عندما يكون

لدي تكرار، حسنًا،

سيتم بناء زلاقة مثلاً

. إذًا بعد كل شيء،

يمكن للأطفال

الانزلاق من سطح معين،

هل سيؤذون أنفسهم؟

حسنًا، أو لن يؤذوا

أنفسهم، لنفترض أنهم

لن يتأذوا. سوف

ينزلقون من ارتفاع

معين، حسنًا،

وسيتزلجون على تلك

الزلاقة. وماذا يحدث

عندما نبني الزلاقة؟

حسنًا، على سبيل

المثال، يبدأ الأطفال

في الانزلاق من أي

مكان آخر، لذا هناك

الكثير من الأشياء

التي يجب أن نأخذها في

الاعتبار عند البناء.

هل كان ذلك المطلب

واضحًا؟ هل تحققنا منه

مع الأطفال لنرى ما

إذا كان هذا ما

يريدونه، فربما لم

يريدوا ذلك. ربما كان

يكفيهم، لا أعلم، تل

أو سطح، لا أعلم، من

التراب، حسنًا، أو من

الرمل. إذًا، حسنًا،

هذا مهم جدًا، أن نضع

في اعتبارنا وجود

أخطاء في التواصل،

وسأكررها لكم كثيرًا

خلال الدورة، كلمة

التواصل خاصة مع موضوع

المنهجية. ودائمًا ما

يكون من المهم، حسنًا،

ومن الأساسي التحقق من

ذلك مع المستخدمين

النهائيين. حسنًا، كنت

أقول لكم إننا نواجه

مشاكل في التواصل للتو

، وهذا رسم بياني

نموذجي. ربما رآه

البعض، والبعض الآخر

لا. حسنًا، إذا كنتم في

مجال تطوير البرمجيات

، كان هناك القليل

جدًا، لكن ربما

رأيتموه لأنه موجود

منذ سنوات عديدة. هذا

طلب المستخدم هو

أرجوحة، لنقل ذات

ثلاثة طوابق، لنفترض

أنها الصورة الأولى.

حسنًا، ماذا فهم قائد

المشروع؟ جاهز، يكفي

صنع أرجوحة وتعليقها

بفرعين على شجرة. من

صممها؟ ماذا فعل؟ محلل

النظم. انتظروا قليلاً

ماذا فعل محلل النظم

هذا؟ حسنًا، أضاف

القليل من التعقيد،

كما في الصورة الثالثة

، أليس كذلك؟ إه، ماذا

طور المبرمج؟ حسنًا،

جاء استشاري خارجي

لنرى ما إذا كان

بإمكانه مساعدتنا،

وهو أمر يحدث أحيانًا.

ما الذي اقترحه؟

بالطبع، الاستشاري

الخارجي دائمًا، بما

أنه ليس من سيبنيها،

يقترح دائمًا أشياء،

حسنًا، لكي، أو بمعنى

لا أعرف إن كان لتعقيد

الأمر، ولكن حسنًا.

أعني، الاستشاري

الخارجي، أنا لست من

مؤيدي الاستشاريين

الخارجيين لأنهم لا

يدركون جيدًا ما يفعله

كل شخص. إه إذًا، من

الواضح، بما أنه يجب

عليهم تقاضي أجر، فيجب

أن يقولوا شيئًا ما.

إذًا، ما هي وثائق

المشروع؟ لم يتم توثيق

أي شيء. يعني، هذه

مسألة إشكالية جداً

بالنسبة للاختبار،

وهي مسألة التوثيق.

وصل إلى الإنتاج، لم

يصل إلى الإنتاج، لم

يصل إلى الإنتاج سوى

مجرد حبل. ميزانية

المشروع كانت متقلبة

من الأعلى إلى الأسفل،

ومن الأسفل إلى الأعلى

. كانت أشبه بركوب

الأفعوانية. حسناً.

إيه، من قدم الدعم

وماذا كان يحتاج

المستخدم حقاً؟ لأن

لاحظوا ما طلبه

المستخدم وما كان

يحتاجه بالفعل. هو لا

يعرف دائماً ما يريده،

حسناً. المستخدم

النهائي يريد شيئاً

دائماً، لكنه في كثير

من الأحيان لا يعرف ما

يريده. في الواقع، هو

لا يعرف أبداً ما يريد.

هل هذا سيء؟ لا، ليس

سيئاً جداً. نحن نوظف

لنساعدهم، لذا يجب

علينا مساعدتهم في

معرفة ما يحتاجونه.

وبالعودة إلى هذا

الرسم البياني، بينما

كنت أخبركم به، أدركت

أنني ذكرت كلمة "

الإنتاج". الإنتاج،

كما يعلم البعض، هو

اسم يطلق على بيئة

العمل. حسناً، إذا كنا

سنتحدث عن بيئات

مختلفة، وهو ما

سنتناوله خلال الدورة

، فهناك بيئة التطوير

حيث يعمل المطورون،

وبيئة الاختبار حيث

نجري اختبارات الجودة

(QA)، وبيئة الإنتاج،

وقد تكون هناك بيئات

أخرى. هناك بيئة وسيطة

بين بيئة الاختبار

والإنتاج تسمى (UAT)،

وهي اختبارات قبول

المستخدم النهائي.

ماذا يعني ذلك؟ أن

المطور سيعمل في بيئة،

بينما سيختبر المختبر

في بيئة أخرى. وسيصل

المستخدمون النهائيون

إلى مكان آخر وهو بيئة

الإنتاج. لماذا؟ لأن

هناك أمراً أساسياً.

يعني، لا يمكن للمطور

أن يقوم بإجراء

تعديلات وتغييرات في

نفس الوقت الذي يستخدم

فيه المستخدم النهائي

النظام، على سبيل

المثال. هذا جنون.

حسناً، لأن الاختبار

لا يمكن أن يتم في نفس

المكان الذي يتم فيه

التطوير وإجراء

التغييرات، وإلا فلن

تكون الاختبارات

موثوقة. إذن، هذا ما

يقصده بمصطلح الإنتاج.

الآن، ما هو الاختبار؟

حسناً، إنه سؤال عظيم

لمقدمة عن الاختبار.

إنه أشبه بمحتوى

الدورة التدريبية

بأكملها. هذا تقريباً.

دعونا نرى بعض

المفاهيم. حسناً، إذا

بحثتم عن تعريف

للاختبار، ستجدون

الكثير. أنا شخصياً

يعجبني التعريف

الموجود هنا والذي

ترونه على الشاشة، لكن

هناك العديد غيره.

حسناً. وهذا لا يعني أن

هذا هو الحقيقة

المطلقة. حسناً. وهذا

التعريف يقول إن

الاختبار هو التحقق

الديناميكي من مطابقة

النظام للمتطلبات.

لماذا التحقق؟ تلك

الكلمتان الموضحتان

بالخط العريض هناك،

التحقق والديناميكية.

حسناً، رأينا مصطلح

التحقق سابقاً لأنه

يتكون ببساطة من

مطابقة النظام مع

المتطلبات. ولماذا

الديناميكية؟ لأنها

تتضمن تنفيذ النظام

على عكس شيء ثابت، وهو

شيء لا يتحرك، شيء لا

يتم تنفيذه. حسناً،

الاختبار يعني تنفيذ

النظام. في كثير من

الأحيان ستجدون هذا،

حيث يقولون: أنا أختبر

الكود، لا. إذا كنت

تختبر الكود، فأنت

تبحث عن أخطاء أو عيوب

، وسنرى لاحقاً الفرق

في الكود؛ فأنت لا

تقوم بعملية "اختبار"

فعلية، بل تقوم بشيء

آخر. على سبيل المثال،

التحليل الساكن. ولكن،

أحياناً نقول إن

مفاهيم الاختبار

مبالغ فيها، ويطلق

مسمى "اختبار" على

الكثير من الأشياء

التي ليست اختباراً في

الحقيقة. حسناً. في

الواقع، أقول أنا

أحياناً "أنا أختبر

شيئاً ما في حياتي

اليومية"، ولكنني في

الحقيقة لا أقوم

بالاختبار؛ لأنني إذا

حصرته في اختبار

البرمجيات، فلن يكون

تعريفاً صحيحاً. لذا

في الممارسة العملية،

ستجدون أن هناك أموراً

تُسمى اختباراً وهي

ليست كذلك. لكن،

باختصار، هذا التعريف

يقول إنه عبارة عن

عملية تحقق. وما الذي

يتحقق منه؟ مدى ملاءمة

النظام للمتطلبات. هذا

ما قلته سابقاً،

النظام مقابل تلك

النماذج والديناميكية

. لماذا؟ لأنه يتم

تنفيذه. دعونا نلقي

نظرة على تعريف آخر من

شين باتش. شين باتش

خبير اختبار من الطراز

الرفيع، صاحب مسيرة

مهنية طويلة، ابتكر

منهجية اختبار تسمى "

رابيد"(Rapid). اختبار

البرمجيات. هو شخص نشط

جداً على وسائل

التواصل الاجتماعي،

ومثير للجدل، كتب

العديد من المقالات،

وغالباً ما يكون

مضيفاً للعديد من

المؤتمرات، لذا إذا

كنتم تحبون الاختبار

وتفهمون اللغة

الإنجليزية، أنصحكم

بمتابعته. إذاً، هو

يقول إن الاختبار هو

العملية اللانهائية

لمقارنة ما هو غير

مرئي بما هو غامض. لقد

قمت بتسليط الضوء على

ثلاث كلمات هناك.

عملية، أي أن هناك

عملية للقيام

بالاختبار. ليس الأمر

أنني أفعل ما أريد،

وأقوم بالبحث ونرى ما

سيحدث، لا. هناك عملية

وسنراها لاحقاً.

ومجازياً، يقول إنه

يقارن بين ما هو غير

مرئي وما هو غامض. ما

هو الشيء غير المرئي؟

حسناً، غير المرئي هو

الكود، كود النظام،

البرمجيات، ذلك الشيء

الذي لا يُرى، والغامض

هو المواصفات.

المواصفات دائماً

غامضة، وفي أغلب

الحالات تكون كذلك.

ولهذا السبب التواصل،

وهنا أذكركم مجدداً

بكلمة التواصل، هو أمر

جوهري. إذًا، باختصار،

ما يقوله جيمس هو نفس

ما كنا نقوله نحن أو ما

كنت أقوله لكم. هو يضيف

فقط أن هناك عملية،

ويقول بشكل مجازي إنه

يقارن النظام

بالمتطلبات. وهناك

تعريف آخر جيد لماهية

الاختبار من السيد

ديكسترا، وهو أن

الاختبار وسيلة فعالة

لإظهار وجود الأخطاء،

لكنه وسيلة غير ملائمة

لإثبات غيابها. أي أنه

من خلال الاختبار

يمكننا القول بوجود

عيوب، لكن لا يمكنني

القول بأن النظام خالٍ

من العيوب أو أنه لا

يحتوي على المزيد،

فأنا ببساطة لم أعثر

عليها. انتبهوا لهذا

الأمر، وسنراه لاحقًا

في عدة دروس. إذًا،

لماذا نقوم بالاختبار

؟ والإجابة تتعلق

بأنني أقوم بالاختبار

لتقليل مخاطر حدوث

العيوب. عدم إجراء

الاختبار أثناء تطوير

البرمجيات هو مخاطرة،

ومخاطرة كبيرة جدًا.

يساعد إجراء الاختبار

في تقليل احتمالية

العثور على عيوب في

النظام. والآن، لقد

قدمنا للتو هذا

المفهوم المهم للغاية

، لأن هناك نهجًا

للاختبار يركز على

المخاطر، وسنرى

لاحقًا درسًا حول

مخاطر الاختبار. والآن

، ما هو الخطر؟ الخطر

هو حدث في مستقبل غير

مؤكد، إذا وقع، فمن

الواضح أنه سيكون له

تأثير، سواء كان

إيجابيًا أو سلبيًا،

على أحد أهداف المشروع

. هو مستقبل غير مؤكد

لأنه لا يُعرف ما إذا

كان سيحدث أم لا. إذا

لم يكن هناك يقين بشأن

ذلك، فقد يكون له

تأثير إيجابي، أي يمكن

أن يكون فرصة، على

سبيل المثال، لنذهب

إلى كرة القدم، أو خطر

رياضي، فقد يتم تسجيل

هدف. هذا شيء في مستقبل

غير مؤكد يمكن أن تكون

له نتيجة إيجابية. وقد

يكون له أيضًا تأثير

سلبي، أو تهديد، وهو

أن يتم تسجيل هدف في

مرماي. حسنًا، إذًا

هذا الخطر لديه

احتمالية للوقوع.

حسنًا، سواء كان

إيجابيًا أو سلبيًا،

فله تأثير، وهذان

السمتان ستسمحان لي

بتقييم ذلك الخطر. أي

تحديد مدى الأهمية

التي سأعطيها لهذا

الخطر، لأنه أحيانًا

يكون خطرًا، لا أعلم

يا شباب، وقوع جائحة،

فهو خطر حتى قبل 6

سنوات كان شيئًا لن

يحدث، لكنه خطر تحقق

ووقع بالفعل. إذًا،

احتمالية الوقوع

تتعلق بالتكرار،

وبإمكانية حدوثه أو

تحقق ذلك الخطر،

وبالتأثير الذي

سيحدثه. حسناً، الأمر

يتعلق بما سيحدث إذا

تحقق ذلك الخطر. وفيما

يتعلق بالمخاطر،

حسناً، هناك أنواع

مختلفة من المخاطر.

هناك مخاطر الأعمال

التي ستؤثر على

المؤسسات. على سبيل

المثال، إطلاق منتج

مبكراً، لأن المنافس

يطلق شيئاً مشابهاً

لتغيير هيكلي في

الإدارة. يمكن أن يجلب

معه خطر عمل، أو خطر

مشروع إذا أثر على أحد

أهداف ذلك المشروع مثل

المواعيد النهائية أو

التكاليف أو النطاق،

على سبيل المثال. بعد

ذلك لدينا خطر يتعلق

بالمشروع، قد يكون

دوران الموظفين،

حسناً من الفريق أو

التغيير المفرط في

المتطلبات أو التقليل

من تقدير الجهد. لدينا

أيضاً مخاطر المنتج

التي ستؤثر عليه. هذا

قد يكون جودة أو أداء

المنتج، على سبيل

المثال، لا أعلم، عيوب

في التصميم، مخرجات

غير قابلة للتحقق، نقص

في تفاصيل التعريفات.

ومن ناحية أخرى،

الأخيرة، لدينا

المخاطر الخارجية،

وهي تلك البعيدة عن

المنظمة والمشاريع

التي تولد، على سبيل

المثال، لا أعلم، خطر

عمل. هي أمور لا يمكننا

السيطرة عليها عموماً

، مثل التضخم، انخفاض

العملة، تغير اللوائح

، أمثلة على جائحة،

كوارث مناخية. حسناً،

الآن، ما علاقة هذا

بالاختبار؟ حسناً،

شيئان. من جهة، الفريق

الذي يشارك في تطوير

البرمجيات يبلغ عن

المخاطر، والاختبار

جزء من ذلك الفريق.

إذاً، سيكون الاختبار

متيقظاً وسيبلغ عن

المخاطر، والتي من

الواضح أنه سيكون مدير

المشروع، أو الـ PM، أو

مدير التسليم، أو أي

مسمى آخر، هو من سيدير

تلك المخاطر، لكن يمكن

لأي شخص من الفريق

الإبلاغ عن خطر. حسناً.

وبالإضافة إلى ذلك، من

ناحية أخرى، من خلال

الاختبارات نحن نساهم

في تقليل بعض المخاطر

التي تم ذكرها، بعض

المخاطر التي قد تظهر

في هذا المشروع. يمكن

تقليلها بشكل جيد من

حيث احتمالية الحدوث

من خلال الاختبار

وأيضاً يمكن تقليل أثر

البعض، حسناً، لكننا

نعمل في الغالب على

احتمالية الحدوث.

حسناً، أي أسئلة حتى

الآن؟ أمم، كنت أريد

أن أسأل فيما يتعلق

باحتمالية الأثر. من

الواضح أنه يمكن قياس

ذلك بالنسبة المئوية،

ولكن الأثر بأي طريقة

يمكن قياسه؟

>> أمم، نعم، كما قلت، هو

بالنسبة المئوية،

والأثر، حسناً، كما

أخبرتكم، أي المثال

الذي أعطيتكم إياه،

على سبيل المثال، ماذا

يحدث في جائحة؟ حرفياً

، هذه هي الطريقة التي

نقارن بها الأمر مع

جائحة، حيث تضع اليوم

نسبة مئوية لحدوث

جائحة وربما تكون

عالية، لكن قبل 6 سنوات

، كنت ستقول: "لا،

احتمال حدوث جائحة، لا

أعلم، 0.5%." هل تفهم؟

يعني، أو لنقل، لا

أعلم، لنقل حدوث زلزال

في المبنى ويتحطم

المبنى بالكامل

ويتحطم مركز البيانات.

خطر آخر قد يحدث، وأود

أن أقول لك أنه 0.1%هنا،

على سبيل المثال، حيث

نتواجد نحن، في كابا

وأمبا، قد حدث ذلك من

قبل، أليس كذلك؟ وقد

يحدث، لا أعلم، لهذا

السبب يجب وضع نسبة

مئوية، ولهذا فهي

مخاطر، مخاطر المشروع

ومخاطر سنتعمق فيها

لاحقاً في مخاطر

الاختبار. سنرى خطة

جيدة وهناك نضع المزيد

من المخاطر. كنت أتخيل

التأثير كعدد الأشخاص

الذين قد يصل إليهم أو

نطاق ذلك الخطر،

>> مثلاً على مدينة أو

على العالم، كما قلت،

جائحة أو

>> مجموعة من الأشخاص

هكذا، لكن لا أعلم،

ربما كانت لديك طريقة

أخرى لقياسه، ولهذا

كنت أسأل. لا، لا، لا،

يتم وضع نسب مئوية

ويتم تحديدها. حسناً.

>> نعم، حسناً. شكراً

جزيلاً.

>> أه، حسناً. هل هناك أي

أسئلة أخرى يا شباب؟

حتى نتمكن من المتابعة

مع الجزء الثاني. جون

إسكالانتي، هل أنت

موجود؟

>> نعم يا أستاذ، أنا هنا.

أنا هنا. لقد اتصلت.

عذراً،

>> حسناً. أه، لا أستطيع

إضافتك إلى أه تليجرام

لأنني لا أعرف ما هو

اسمك. أه، كيف تظهر

باسمك؟ ليس اسم

المستخدم، بل الاسم

الحقيقي. باسم "جون

إسكالانتي" لست مسجلاً

عندي. يجب أن تخبرني

باسمك حتى أتمكن من

إلغاء حظرك. لدي واحد

باسم "J"، لكن لا أعرف

إن كنت أنت ذلك الشخص.

>> أه، سأبحث عنه وأرسل

لك ما يظهر لي، لكن لدي

"mayor escal"، وليس اسم

المستخدم. هل هذا

مفهوم؟ آه، حسناً.

سأتحقق من الأمر إذن.

>> تحقق منه وأخبرني. هل

هناك أي شخص آخر هنا لم

يتمكن من الدخول إلى

تليجرام؟ أه، عذراً،

لكن هل أنشأت مجموعة

أخرى كما ذكرت بالأمس؟

>> لا، إنها نفسها.

>> آه، إنها نفسها. مفهوم.

إذاً، شكراً. لهذا

أريد رؤية ذلك، حسناً،

إذا رأيتم، إذا كان

لديكم أي سؤال بخصوص

موضوع الفصل

الافتراضي و هكذا نكون

قد انتهينا

>> آه، هل ما كنت تعرضه

للتو يمكن مشاهدته

لاحقاً؟ هل ستقوم

برفعه لاحقاً أم أنه

مقتصر على الفصل فقط؟

لا أعرف.

>> سؤال.

>> لأنني كنت أبحث عنه

الآن في الفصل

الافتراضي ولم أجد سوى

ملفات PDF، وما كنا

نشاهده كان عرضاً

تقديمياً من PowerPoint.

>> نعم، هو نفسه، العرض

التقديمي بصيغة PDF.

>> حسناً. بمعنى، ما

تعرضه لنا هو أساساً

ملخص لما في ملفات الـ

PDF. هل هذا صحيح؟ لا،

الأمر ليس نفسه. بدلاً

من رفع عرض تقديمي، هو

موجود بصيغة PDF. حسناً.

>> يا أستاذ. لقد أرسلت لك

ما يظهر عندي. لا أعلم

إن كان هذا هو المقصود.

>> أه؟ لا، هذا ليس الاسم.

هذا هو اسم المستخدم.

أنا أحتاج إلى اسمك

الحقيقي. كيف حالك؟ هل

أنت هكذا؟ جون

إسكالانتي، أليس كذلك

؟ أعني، أنت لست

محظوراً. لا، يجب أن

تكون قادراً على

الدخول.

>> بالطبع، لدي نفس الاسم

تقريباً، لكن بدون

الشرطة السفلية فقط.

لكن لا.

>> أريد الاسم، لا اسم

المستخدم. بالطبع، لا،

لست مسجلاً لدي.

بالطبع.

>> أعني، أنت لست محظوراً

. هذا ما أقصده.

>> حسناً، سأحاول

الانضمام مجدداً

وسأخبرك بما سيحدث.

>> لأنك لست محظوراً.

محظور. أنا أستخدم نفس

الحساب لأن لدي بعض

الأشياء هناك، سأخبرك

ولا أجدك عندي. لهذا

السبب. أعني الآخرين،

مثل أوليسيس

وديلغاديو، وشخص آخر

دخل اليوم، لقد

أخبروني ودخلت حينها.

>> نعم، تمكنت من الدخول

الآن. ها هو ذا. غريب،

لأنه في المرة الأولى

التي حاولت فيها

الدخول، ظهر لي نفس

الشيء الذي ظهر

لزملائي.

>> حسناً.

>> تمكنت من الدخول.

شكراً لك يا أستاذ.

>> هل هناك أي شخص آخر لم

يتمكن من الدخول؟

لننهي هذا الأمر. تم.

حسناً، جيد. حسناً،

بما أن يوم الإثنين

عطلة، سنتقدم قليلاً

لنكمل يوم الأربعاء.

يوم الأربعاء لدينا

حصة. جيد. لأنه وبسبب

العطلة يوم الإثنين،

للأسف يقصر الأسبوع يا

شباب. آه. سنلقي نظرة

سريعة على العلاقة بين

القابلية للاختبار،

وأيضاً ما يخص التصحيح

. جيد. آه، عن ماذا

نتحدث عندما نتحدث عن

الجودة؟ حسناً، من

الواضح أن اختبار

البرمجيات يضيف جودة

لها، حسناً، ولكن هناك

بعض التعريفات لهذا

الأمر. على سبيل

المثال، هناك ما تقوله

الأكاديمية الملكية

الإسبانية (RAE). ماذا

تقول؟ تقول إن الجودة

هي خاصية لشيء ما تسمح

بمقارنته مع البقية

والقول ما إذا كان

يتمتع بجودة أقل أو

مساوية أو أعلى. أي

أنها سمة تسمح

بالمقارنة، لكنها لا

تحدد أيّاً من الشيئين

اللذين أقارنهما

يتمتع بجودة أعلى من

الآخر. حسناً، لاحظ

أنني أتحدث دائماً عن

هذا المثال. لدينا هنا

صورة لسيارة فيراري

وسيارة هامر. ما رأيكم

أنتم؟ أيّهما يتمتع

بجودة أعلى؟ سيارة

هامر أم فيراري؟ ما

الذي يبدو لكم؟

>> لا، لا، الأمر يعتمد

على الغرض أيضاً.

>> نعم، ولكن إذا قلت لكم

هذا، فإحدى الإجابات

صحيحة. حسناً، ولكن

السؤال هو، لماذا

يعتمد على ذلك؟ حسناً،

الأمر يعتمد على

السياق، جيد. يعتمد

على الغرض الذي تريد

استخدامه من أجله.

حسناً. لقد قلت ذلك،

الغرض هنا يأتي بكلمات

أخرى. إذا كان للقيادة

على الطريق السريع،

فمن الواضح أن

الفيراري أفضل. أما

إذا كنت سأقوم برحلة

دفع رباعي، فربما تكون

الهامر أكثر ملاءمة لي

. حسناً، إذن أحد

الاستنتاجات الأولى

التي نصل إليها هو أن

الجودة ذاتية، وإذا لم

تصدقوا، فاسألوا

أنفسكم. حسناً. ما هي

السمات التي تقدرونها

لكي تقولوا إن منتجاً

ما يتمتع بجودة جيدة؟

واسألوا أنفسكم جيداً

، اسألوا أنفسكم. من

المؤكد أن الأشياء

التي تقدرونها ستكون

مختلفة. وهذا يحدث لنا

أيضاً عندما نسأل

شخصاً ما إذا كان

راضياً عن، على سبيل

المثال، منتجنا أو

خدمتنا. ربما يجد

شخصان لديهما نفس

المنتج أو الخدمة

مستويات مختلفة من

الرضا لأن لديهما

تصوراً مختلفاً لتلك

الجودة. حسناً، وهنا

لدينا تعريف آخر

لماهية الجودة، لأنني

ذكرت لكم للتو الجودة

ولدينا تعريف آخر هنا.

هذا التعريف مقدم من

منظمة الأيزو (ISO).

حسناً. ويخبرنا أن

الجودة هي الدرجة التي

تفي بها مجموعة من

الخصائص المتأصلة في

شيء أو منتج أو خدمة أو

عملية أو شخص أو منظمة

أو نظام أو موارد

بالمتطلبات. هذا

التعريف يتوافق مع

التعريف السابق، لكنه

يضيف أن الشيء يتمتع

بالجودة إذا كان يلبي

المتطلبات. إذن، هذا

ما كنا نقوله للتو، أن

جودة شيء ما ستعتمد

على السياق، وعلى

المتطلبات، وعلى

الغرض منه، وكيف ترتبط

تلك الجودة بالاختبار.

من ناحية، أخبرتكم في

البداية أن النظام

الجيد يتطلب الامتثال

للمتطلبات، لأننا

نقوم بعمليات التحقق

والتدقيق لهذا الغرض.

ولكن لكي يمتثل

للمتطلبات، لدينا هنا

نقطة مشتركة. هناك

الصورة الأولى التي

تقول "المساهمة". الهدف

من الاختبار هو

المساهمة في جودة

النظام. سوف يوفر

معلومات موضوعية حول

تلك الجودة. هذا لا

يعني أن الاختبار يضيف

الجودة بحد ذاته.

فمجرد إجراء الاختبار

لا يعني أن النظام

سيصبح ذا جودة. هناك

الأيقونة الثانية،

التي تمثل فريقاً.

حسناً، جودة أفضل أو

أعلى. الجودة هي

مسؤولية الفريق

بأكمله، وليست

مسؤولية ضمان الجودة (

QA) كما كان يحدث منذ

سنوات عديدة حيث كانوا

يأتون ويقولون: "أنت

أخطأت وأنت المسؤول".

لا، في يومنا هذا،

المسؤولية تقع على

عاتق الفريق بالكامل.

حسناً، أنا أبلغك عن

العيب، أو الخطأ، أو

التحسين، ولكن إذا لم

يتم تصحيحه، فأنا لا

أضيف جودة بمجرد إجراء

الاختبار. حسناً. ثم

الصورة المجاورة،

الطبيب، الاختبار هو

طبيب، يقوم بتشخيص

حالة الأمور، وكلما

أجرينا اختباراً أفضل

، حصلنا على تشخيص

أفضل. ما يجب أن نتجنبه

هو الاعتقاد بأننا

نضيف الجودة من خلال

الاختبار. ثم لدينا

الأخير وهو الكوب.

حسناً، للنظام كما لو

كنا نضيف السكر للشاي

أو القهوة، أو كيفما

شئتم تسميته، ولتكن

القياس صحيحة، أننا

نقوم بذلك في النهاية

من خلال الاختبار. إذن

، ما نفعله هو تشخيص

حالة النظام، ولكن ليس

بمجرد إجراء الاختبار

أصبح نظامي الآن ذا

جودة أفضل مما كان

عليه من قبل. ربما لدي

معلومات أكثر من ذي

قبل، ولكن إذا لم يتم

تصحيح الأمور، وإذا لم

يتم تنفيذ التحسينات،

فلن أحصل على نظام

بجودة أفضل. الآن، كيف

نساهم في الجودة؟

حسناً، من ناحية نثبت

وجود الأخطاء ومن

ناحية أخرى نثبت أيضاً

أن النظام يعمل بشكل

جيد. إذا قمت بتنفيذ

الاختبار مرات عديدة،

ونفذت حالات الاختبار

مرات عديدة وقد نجحت

تلك الاختبارات. لا

يعني هذا أنني أضعت

وقتي لمجرد إجراء

الاختبار، وعدم

العثور على عيوب. على

العكس، ما أفعله هو

زيادة الثقة في ذلك

النظام. حسناً، إذن

سننتقل الآن إلى

التالي الذي في شركات

الأنظمة المختلفة

يوجد بالطبع ما يسمى

بقسم ضمان الجودة،

ولكن ليس كل من يعمل في

ذلك القسم أو تلك

المناطق يُطلق عليهم

موظفي ضمان الجودة.

وأجد هذا مثيراً

للاهتمام، فهناك فرق،

ولا يوجد تساوي بين ما

هو ضمان الجودة (QA)،

ومراقبة الجودة (QC)،

والاختبار (Testing). يشير

QA إلى Quality Assurance، وهو

ضمان الجودة. QC يعني

Quality Control، وهو مراقبة

الجودة، وهناك أيضاً

الاختبار (Testing). الآن

سنرى كيف يترابط كل

هذا، لأنني أوضحت لكم

بالتفصيل الفرق بين

هذه المفاهيم. حسناً،

في المقام الأول يأتي

Quality Management، وهو

مجموعة الأنشطة

المتعلقة بالإدارة

والتنسيق، حيث توجد

العمليات والمنهجية

والمقاييس. لاستخراج

هذا، سنرى لاحقاً

مقاييس مختلفة لتقييم

جودة البرمجيات. إذن،

إدارة الجودة (QM) هي

التي تضع التوجيهات،

وتنشئ السياسات

والإجراءات والمعايير

وأهداف الجودة تحت

مظلتها في هذه

المجالات الأربعة. من

ناحية، هناك تخطيط

الجودة (Quality Planning)،

وهو QP. وهو مجموعة

الأنشطة المتعلقة

بتخطيط تلك الأهداف

وسياسات الجودة. كيف

سننفذ هذا؟ ما هي

الموارد التي نحتاجها

؟ ما هي المعايير التي

يجب أن نلتزم بها؟ ما

هي المخاطر التي

نواجهها؟ ما هي

الأنشطة التي سنقوم

بها؟ عند تنفيذ أي

نشاط، يجب أن نفكر

دائماً في تحليل

التكلفة والعائد،

والقياس المقارن (

Benchmarking)، وإعداد الخطط

، وتحديد معايير

النجاح لقياس ما قمنا

به والتأكد من جدواه.

من ناحية أخرى، لدينا

ضمان الجودة (Quality

Assurance)، وهو مجموعة

أنشطة متابعة وتدقيق

الجودة. حول العمليات

وهذا هو الاختلاف

الرئيسي بين QA و QC. حيث

يهتم QA بالعمليات.

قلنا إن أفضل طريقة

للقيام بذلك هي من

خلال إنزال الأهداف من

إدارة الجودة (QM).

حسناً، و بالطبع، هو

يقوم أيضاً بتقييم

التطبيق الصحيح

للعملية، ولا يكتفي

بالتحقق مما نفعله

وفقاً لما خططنا له،

بل نسعى للتحسين

بإزالة المهام غير

الضرورية، وتقييم

أسباب المشكلات

المتكررة. وذلك لنرى

كيف يمكننا استئصالها

من الجذور. نرى كيف

يمكن الوقاية من

المشكلات. من ناحية

أخرى، لدينا مراقبة

الجودة (Quality Control)، وهي

مجموعة الأنشطة

الخاصة بفحص جودة

المنتج. حسناً، وهو ما

يسمى بـ QC، وترجمته هي

مراقبة الجودة. حسناً،

لاحظوا أننا تحدثنا

للتو عن جودة العملية،

والآن نتحدث عن جودة

المنتج. أحد الأنشطة

التي سنقوم بها

للمساهمة في جودة

المنتج هو الاختبار،

ولكنه ليس النشاط

الوحيد. حسناً، عندما

نتحدث عن منتج في

حالتنا، فنحن نتحدث

بشكل عام عن منتج

برمجي، ولكن في المثال

الذي ذكرته سابقاً عن

أفضل طريقة لممارسة

إدارة الجودة...حسناً،

سابقاً قيمنا عملية

البناء، والآن نقوم

بتقييم الجودة. إذن،

الاختبار هو أحد أنشطة

مراقبة الجودة، ولكنه

ليس الوحيد، فهناك

أنشطة أخرى، مثل

عمليات الفحص،

والمراجعات، والتحليل

الساكن. على سبيل

المثال، يمكننا إجراء

مراجعة لمواصفات

المتطلبات، وهذا

سيضيف جودة، لكنه لا

يعد اختباراً. لهذا

السبب قلت لكم في

البداية إن مصطلح

الاختبار مثقل

بالمعاني؛ لأننا

غالباً ما نقول إننا

نختبر المواصفات، رغم

أننا نعلم من تعريف

التحقق الديناميكي أن

ذلك ليس اختباراً

بالمعنى الحرفي. حسناً

. ومن ناحية أخرى،

لدينا ما يسمى بـ QI،

وهو الأخير، أي تحسين

الجودة، وهو مجموعة

الأنشطة الموجهة

لتحسين العمليات

الحالية، وهو ببساطة

ما قد تسمونه التحسين

المستمر. كوننا نقوم

بالأمور بشكل جيد لا

يعني، حسناً، لا يعني

أننا لا نستطيع القيام

بها بشكل أفضل. يتطلب

هذا اكتشاف وتحليل

أوجه القصور واقتراح

التحسينات، وهذا أمر

ضروري دائماً. إذن،

هذا هو الفرق الرئيسي

بين الاختبار، وضمان

الجودة، ومراقبة

الجودة. في كثير من

الأحيان في الشركات،

حسناً، إيه يطلقون على

الدور أحياناً اسم

محلل أو مدرب. حسناً،

في حين أننا في الواقع

لا نعمل على العمليات،

بل نقوم فقط بإجراء

الاختبارات. حسناً،

هذا تطبيق خاطئ لهذا

المسمى. إذن، بشكل عام

، الفرق الرئيسي هو أن

ضمان الجودة يركز على

جودة العمليات،

ومراقبة الجودة تركز

على جودة المنتج،

والاختبار هو أحد

الأنشطة العديدة التي

يمكننا القيام بها

كجزء من مراقبة الجودة

. حسناً، إيه، هذا بشكل

عام، ما هو الفرق بين

الواحد والآخر؟

لنتحدث قليلاً عما

يسمى بنماذج الجودة.

تُعرف نماذج الجودة

أيضاً بنماذج التميز.

هناك العديد من

النماذج، والمنظمات

التي ترغب في تطبيق

أحدها تختار النماذج

التي تريد الالتزام

بها. لكن هذه النماذج،

بالنسبة للمنظمات

التي ترغب في تطبيقها،

حسناً، إيه، هي إطار

مرجعي تقارن المنظمات

نفسها به لمعرفة نقاط

ضعفها ونقاط قوتها.

تحديد بعض مسارات

التحسين، وهذه

المقارنة هي عبارة عن

تقييم ذاتي. تختلف

المعايير عن ذلك.

النموذج ليس معياراً.

يضع المعيار مبادئ

توجيهية يجب الالتزام

بها وهي قابلة

للاعتماد. على سبيل

المثال، شهادة ISO 9001

التي تعتمد العمليات،

أو معيار 25,000 الذي

يعتمد جودة البرمجيات.

ولكن بالعودة إلى

النماذج، هناك نماذج

مختلفة. على سبيل

المثال، نموذج "ديمنج"

الذي طوره "إدوارد" في

اليابان للمساهمة في

تحسين القدرة

التنافسية. يُفترض أنه

بفضل هذا النموذج

انتعشت الصناعة في

اليابان. حسناً، هناك

نماذج أخرى، مثل نموذج

"مالكولم بالدريج"

الذي أُنشئ في

الولايات المتحدة

لمنافسة الشركات

اليابانية من خلال

مفهوم الجودة الشاملة.

نموذج آخر هو EFQM، وهو

المؤسسة الأوروبية

لإدارة الجودة، أو

بالنسبة للجزء

الأيبيري الأمريكي

وهو "FUNDIBEQ"، أعتقد أنها

المؤسسة الأيبيرية

الأمريكية لإدارة

الجودة، وهي تشبه

السابقة لكنها مكيفة

لأمريكا. حسناً، على

الرغم من أن لكل نموذج

من هذه النماذج خصائص

فريدة، إلا أنها تشترك

في مجموعة من الخصائص

التي يمكنكم رؤيتها

هنا في هذه الشريحة.

النماذج ذات طبيعة

طوعية، أي أنه لا أحد

يجبرنا على الالتزام

بنموذج التميز. كل

شركة تقرر ما إذا كانت

تريد تطبيق نموذج أم

لا. حسناً، وأي نموذج

ستقوم بتطبيقه.

بالإضافة إلى ذلك،

بناء إطار مرجعي،

بالطبع، من أجل

التحسين المستمر. ولكن

كما قلت لكم، يمكن أن

تكون النماذج عبارة عن

متطلبات وتوصيات غير

إلزامية، فهي ليست

ملزمة بالتنفيذ

الحتمي، بل هناك أمور

يمكن للمرء تكييفها

حسب احتياجاته. من

ناحية أخرى، يمكن

تكييفها مع أي نوع من

الشركات، بغض النظر

عما إذا كانت صغيرة أو

متوسطة أو كبيرة أو

محلية أو دولية، وهي

قابلة للتقييم الذاتي.

أي أنني لا أحتاج إلى

جهة اعتماد تأتي

لتخبرني ما إذا كنت

أقوم بالأمر بشكل جيد

أو سيئ. وأخيراً،

ونتيجة لذلك، فهي غير

قابلة للاعتماد، كما

قلت لكم، عكس المعايير

التي هي قابلة

للاعتماد. حسناً، الآن

سنرى مصطلح التنقيح أو

تصحيح الأخطاء (Debugging).

ما هذا؟ ما هو تصحيح

الأخطاء؟ أولئك الذين

يعملون في البرمجة

يعرفونه بالتأكيد،

وربما رآه البعض منكم

في مسيرتكم الدراسية،

عذراً، في دورات سابقة

. تصحيح الأخطاء هو

عملية تحديد سبب

العيوب وتصحيحها.

حسناً. وللقيام بذلك،

حسناً، ما يتم القيام

به هو تنفيذ محكوم

للبرنامج. هذه العملية

، عادة ما يقوم بها

المطورون، وهم لا

ينفذونها مثلنا

تماماً. حسناً، هم

ينفذونها بطريقة خاصة

، إذ يضيفون أشياء

تسمى نقاط التوقف (

breakpoints) لكي يتمكنوا من

تتبعها. نقاط التوقف

هي نقاط لقطع مسار

التنفيذ. إذن، بدلاً

من تشغيل البرامج دفعة

واحدة، ستستمر

البرامج في مسارها؛

ولكن حيثما وُضعت نقاط

التوقف هذه، ستتوقف

لكي يتمكن المطور من

رؤية تدفق البرنامج،

وحالة المتغيرات في

تلك اللحظة، وتفحص

أسطر الكود المختلفة

لتحليل سبب تلك العيوب

، وبطبيعة الحال،

تصحيحها في النهاية.

مصطلح "تصحيح الأخطاء"(

debugging)، عند نقله إلى

الإسبانية أو العربية

، قد لا يكون مفهوماً

بنفس القدر، ولكن في

الإنجليزية عندما

نبلغ عن خطأ، نقول

إننا نبلغ عن "ثغرة"(bug).

حسناً، إذن تصحيح

الأخطاء هو إزالة

الثغرات من ذلك

البرنامج، لنسمِّه

هكذا. من ناحية أخرى،

الاختبار (testing)، لقد

تحدثت كثيراً عما

أخبرتكم به حول

الاختبار منذ يوم

الإثنين. إذن، ما هو

الفرق الرئيسي بين

الاختبار وتصحيح

الأخطاء؟ من ناحية،

يقوم بالاختبار مختص

الجودة (QA)، بينما يقوم

بالتصحيح المطور (dev)،

ولكن من ناحية أخرى،

ما يفعله الاختبار هو

كشف وجود العيوب، ومن

هناك يبحث (التصحيح) عن

سببها ليتمكن من

معالجتها. حسناً. من

الواضح أن هناك سبع

فوائد لإجراء اختبار

البرمجيات واختبارات

الجودة. ولماذا تعتبر

هذه الاختبارات

ضرورية؟ حسناً، نحن

نريد...شئنا أم أبينا،

في الوقت الحالي أصبح

استخدام البرمجيات

جزءاً من حياتنا

اليومية، في اللحظات

التي أكتب فيها مثلاً،

أمامي شاشة، وحاسوبي،

وهاتفي المحمول، ولدي

متصفحان وثماني

علامات تبويب مفتوحة.

حسناً، باختصار،

أستطيع القول إن حياتي

الإنتاجية تعتمد

كلياً على عمل

البرمجيات، تماماً

مثلكم. وأعلم أنني لست

وحدي في هذا، كما قلت

لكم. أليس من المحبط

عندما يتوقف برنامج

تستخدمه فجأة عن العمل

؟ هذا بالظبط. بالنسبة

لي شخصياً، إذا استغرق

موقع ويب أو تطبيق

جوال 3 ثوانٍ أو أكثر

للتحميل، فمن الطبيعي

أن أشعر بالانزعاج.

وأعتقد أنكم أيضاً

تتشتتون. كونوا صادقين

، نحن نعيش في عصر لا

يتحلى فيه أحد بالصبر

تجاه البرمجيات رديئة

الجودة، ولهذا السبب

يجب أن يكون ضمان

الجودة جزءاً لا يتجزأ

من أي مشروع برمجيات.

تكمن العلوم وراء

اختبارات ضمان الجودة

(QA) في تحديد جودة

البرمجيات بدقة، بهدف

التأكد من أنها تعمل

كما هو متوقع وفي كل

مرة. يشير المصطلح إلى

طرق وعمليات مختلفة

لاختبار البرمجيات

وضمان جودتها. ولهذا

السبب تعد اختبارات

ضمان الجودة حليفك

الأفضل، من حيث نسبة

التكلفة إلى الفائدة

لضمان الحصول على

برمجيات ذات جودة

ممتازة. حسناً، ولهذا

السبب تقول النقطة

الأولى إن ضمان الجودة

يوفر عليك المال

والكثير من المتاعب.

كم من المال يكلفك

مشروع برمجيات معيب؟

إنها تكلفك فقدان

المستخدمين والعملاء،

ومن المعروف أنه كلما

طالت مدة بقاء الخطأ

في برمجياتك دون

اكتشاف، زادت صعوبة

حله لاحقاً. حسناً،

النقطة الثانية، ضمان

الجودة يمنع الطوارئ

المؤسسية الكارثية. مع

برمجيات الشركات،

تكون المخاطر أكبر

بكثير. يمكن أن تؤدي

الأخطاء في برمجيات

الشركات إلى تعطل

النظام، وفقدان

البيانات، وفشل

الاتصالات. إذا كنت

ستستخدم برمجيات في

شركة أو لمعالجة

معلومات حساسة، فيجب

عليك التأكد من أن

البرنامج سيعمل

تماماً كما يجب أن

يعمل. لا يوجد مجال

للخطأ. حسناً. النقطة

الثالثة، ضمان الجودة

يلهم ثقة العملاء. من

خلال إجراء اختبارات

ضمان جودة البرمجيات،

تصبح لديكم أولوية

واضحة في تطوير

البرمجيات. أنتم

ترسلون رسالة إلى

عملائكم تفيد بأنكم

تريدون لبرمجياتكم

تحقيق أكبر قدر ممكن

من النجاح. هذا أمر في

غاية الأهمية عندما

يتعلق الأمر بتقديم

الجودة وبناء علاقات

طويلة الأمد. حسناً،

النقطة الرابعة، ضمان

الجودة يحافظ على

تجربة مستخدم رائعة.

أصبح من الواضح بشكل

متزايد أن تجربة

المستخدم هي التي تجعل

المنتج ينجح أو يفشل.

إذا كان البرنامج

معطلاً أو بطيئاً،

فإنه يقطع تجربة

المستخدم مع المنتج.

تؤدي تجربة المستخدم

السيئة إلى عدم الرضا

والإحباط. تجربة

مستخدم جيدة. ما تحصل

عليه عند اختبار منتج

برمجي بدقة هو مستخدم

راضٍ، ومن المرجح أن

يوصي بالمنتج وعملك

للآخرين. حسناً، ونقطة

أخرى، النقطة الخامسة

، ضمان الجودة يجلب

المزيد من الأرباح.

إذا كنتم تنشئون

برنامجاً لتسويقه أو

بيعه، فإن الاستثمار

في ضمان الجودة يعني

أنه يمكنكم بيع منتجكم

بأسعار أعلى. حسناً،

لا شيء أسوأ من مستخدم

غاضب دفع ثمن منتج لا

يعمل. حسناً، النقطة

السادسة، تزيد من رضا

العملاء. بالارتباط

بالنقطة الأولى، تركز

هذه الفائدة السادسة

على سمعة رضا العملاء

التي تقدمها الشركة.

لا يقتصر الأمر على

الربح فقط، فتقديم

برمجيات عالية الجودة

تعمل متى وكيفما يرغب

المستخدم سيعزز

سمعتكم من خلال كسب

رضا العملاء. لا

تختبروا صبر العملاء

النهائيين ببرمجيات

معيبة، حسناً، تلك

التي تتطلب إصلاحاً

مستمراً لأن هذا النوع

من البرمجيات مصيره

الفشل. حسناً، يجب

توفير الجودة منذ

البداية وسيكافئكم

العملاء بولائهم.

حسناً، النقطة

السابعة، ضمان الجودة

يعزز التنظيم

والإنتاجية والكفاءة.

بالتأكيد لا تريدون

التعامل مع فوضى ناتجة

عن برمجيات معيبة.

حسناً، لا تواصل محموم

ولا إصلاحات متسرعة.

يجب التنظيم

لاختبارات مراقبة

الجودة منذ بداية

استراتيجية التطوير.

عندما يتم التطوير،

سيسمح لكم ذلك بالعمل

بسلام، وتكونوا أكثر

إنتاجية في وقتكم.

سنرى هذا لاحقاً بشكل

أكثر تفصيلاً. عند

استخدام المنهجيات

الرشيقة (Agile)، حيث

يقوم مطورو البرمجيات

بإنشاء وتسليم أجزاء

صغيرة من المنتجات في

جدول زمني أوضح. يمكن

البدء في اختبار

البرمجيات أثناء

إنشائها. بدلاً من

الانتظار دائماً حتى

النهاية. عندما تكون

اختبارات البرمجيات

جزءاً لا يتجزأ من

استراتيجية البرنامج،

فأنتم الرابحون.

عميلكم سيربح

ومستخدموكم سيربحون

أيضاً. لماذا؟ لأن ذلك

سيضيف قيمة للبرنامج.

سيعتقدون أن هذا

البرنامج يتمتع

بالجودة. حسناً، حسناً

. آه، هل هناك شكوك أو

استفسارات حول هذا

الجزء الثاني؟

>> كيفن فوينتس.

>> بإضافة حرف "بي"، ولكن

نعم. أعني، الاختبار

يساعد في الجودة، لكنه

لا يضمن عدم وجود خطأ

فادح لم يظهر أثناء

تصحيح الأخطاء (debug)، و

،

>> أعني، هو لا ينقذك من

ذلك، لنقل، أيضاً.

>> لا، لا. طوال الدورة

التدريبية سنقوم

برؤية هذا الأمر.

سأتحدث معكم كثيراً

حول هذا الموضوع، لأنه

، دعونا نرى، الحالة

الأولى تظهر لي، وبعد

ذلك سنرى كيف أن الدرس

القادم سأعطيكم

منهجية "أجايل"

وسنتعمق قليلاً في

الموضوع. في منهجية "

أجايل" تسمى الدورات "

سبرينت"(sprints) وتكون كل

أسبوعين. خلال هذين

الأسبوعين يتم

التطوير وإجراء ضمان

الجودة (QA)، ثم ينتقل

للإنتاج. وفي

الأسبوعين التاليين

يحدث الشيء نفسه.

حسناً. آه، عليكم

اختبار كل شيء،

والتأكد من أن النظام

يعمل، وأن كل ما لم

يلمسه المطور لا يزال

يعمل بشكل جيد. حسناً.

هناك، من الواضح أن

لديكم، وسنرى ذلك

لاحقاً خلال الدورة،

ولكن لكي تأخذوا فكرة،

هناك أنواع من

الاختبارات التي يجب

عليكم القيام بها،

والتي يجب أن تكون

واضحة لكم بحيث تقولون

: "حسناً، سأقوم بهذا

الاختبار، وهذا

الاختبار، وهذا

الاختبار". لماذا؟ لأن

المطور عدّل هنا، عدّل

في النواة، في جوهر

العمل، وهذا قد يؤدي

إلى كسر كل شيء، لذا

يجب عليكم التخطيط

خلال هذين الأسبوعين

لكيفية اختبار كل شيء.

حسناً. إيه،

>> لأنني كنت أسأل من

جانب أنني أتخيل أن

العديد من مختبري

الجودة (QA) ليسوا

مطورين، لذا لا بد

أنهم لا يعرفون

البرمجة أيضاً. لكن

الآن بعد أن أخبرتني

عن التكرار وعن وجود

منهجيات، فمن الواضح

أنكم ستختبرون كثيراً

لدرجة أنه من الصعب

جداً أن يفوتكم شيء،

سواء كنتم مطورين أم

لا؛ بل لأن العملية

نفسها تدفعكم لتحسين

الاختبار طوال الوقت،

لنقل. أتقصد أن يقوم

مطور باختباره،

>> أليس كذلك؟ أنا أعرف

الفرق بين تصحيح

الأخطاء (debug)

والاختبار (test).

>> أعلم أن هناك من ليسوا

مبرمجين.

>> من الواضح أن مختبري

الجودة ليسوا مبرمجين.

>> بالطبع، الغالبية

ليسوا كذلك.

>> وقد ثبت ذلك، سأخبرك،

لقد ثبت أن المطور، من

الواضح أن المطور يجب

أن يسلمك اختبارات

الوحدة (unit tests) وهي

مختبرة بالفعل. حسناً،

اليوم بالذهاب أبعد

قليلاً، هي تلك التي

يتم أتمتتها. سنرى هذا

لاحقاً بشكل أكبر

قليلاً، لكنني سأعطيك

إياه بشكل عام جداً.

إيه إذا كان لدي 2 + 2 = 4،

حيث يجب أن أدخل 2 و 2

ويجب أن تكون النتيجة

أربعة، فما سيفعله

المطور في اختبارات

الوحدة هو إدخال 2 و 2،

بينما سيقوم مختبر

الجودة بإجراء مجموعة

من الاختبارات. سيضع 1

و 3 ليرى إن كانت ستعطي

4، أو سيضع 9، أو سيضع

علامة نجمة. هذا ما يجب

على مختبر الجودة

اختباره. هذا هو الفرق

الكبير. لا أعرف إذا

كان هذا ما تقصده

بسؤالك أو

>> أنا أقصد أكثر ما إذا

كان هناك خطأ كارثي لم

يظهر أثناء الاختبار

>> وهو مسؤولية مختبر

الجودة.

>> بالطبع، لهذا السبب.

لكن أتخيل أنها

مسؤولية المطور أيضاً

لأنه يجب أن يسلم...لم

أكن أعلم أنه يجب عليه

أيضاً تسليم اختبارات

الوحدة بجانب...

>> وهذا هو المنطقي.

المطور يجب أن يسلم

اختبارات الوحدة. أنت

تطور البرمجيات.

بالطبع، أنا آتٍ من

جانب البرمجة ولم أكن

في جانب ضمان الجودة.

>> بالطبع. حسناً، انظر،

أنا أقول هذا كما لو

كان العالم المثالي.

كل شركة لها عالمها

الخاص يا رفاق. أي،

>> لا، بالإضافة إلى أن

الشركات لا تعرف أيضًا

، فهم لا يدركون،

ويسمون أي شيء "

اختبارًا"(testing)،

ويسمون أي شيء "

تطويرًا"(dev) أيضًا.

>> نعم، نعم، نعم، نعم.

لهذا السبب، يعني،

الكثير هنا يتعلمون

جيدًا، وهناك

الكثيرون ممن كان هذا

عملهم الأول دون معرفة

أي شيء. هذا جيد، لأن

هناك الكثير من الشباب

بدأوا في ضمان الجودة (

QA). هنا جيد، أنا

أمنحكم الأساس، حسنًا

، بما أعطيكم إياه،

يمكنكم بكل هدوء البحث

بعد انتهاء الدورة،

يمكنكم البحث عن وظيفة

"مطور ضمان جودة مبتدئ"

(QA Junior)،

>> وستدركون ذلك،

ستلاحظون عندما ترون

إعلانًا لـ "QA Junior" أنه

نفس ما قدمته لكم في

المادة، وهو ما قمتم

به في التدريب وما

فعلتموه في

الاختبارات الجزئية،

هو نفسه يا شباب. حسنًا

، ستدركون ذلك. إذا

كنتم تريدون البدء في

مجال ضمان الجودة في

الأنظمة، فأنا أقول

دائمًا إن هناك أمرين.

إما الدخول في جزء

الدعم الفني، أو

الدخول في جزء ضمان

الجودة في عالم

الأنظمة، أو الدخول

للدعم الفني في مجال

تكنولوجيا المعلومات.

بعد ذلك يمكن للمرء

التنقل بين هذا وذاك.

حسنًا، لكن ضمان

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

الجيد دخوله.

>> بالتأكيد، سؤالي كان

من هذا الجانب لأنني

معتاد على القيام

بتنقيح الأخطاء (debugging)

، لكنني لا أتعامل مع

كل الجانب الآخر، لنقل

.

>> واضح، واضح. حسنًا،

الآن ستعرف كل ما يحدث

في الجانب الآخر. في

الدورة ستعرف كل ما

يحدث في الجانب الآخر.

لنرى. ربما لا أعرف أين

أنت، وما مدى حجم

الشركة، وما هي

العمليات والمنهجيات

التي لديهم. أنا أحاول

توضيح هذا في العالم

المثالي.

>> آه، نعم، إنها فوضى

عارمة.

>> حسنًا، ونعم، لهذا

السبب أحاول التحدث عن

العالم المثالي. كل

الجوانب والمشاكل

التي تواجهها الشركات

، لن أخبركم بها، هذا

ستفعلونه أنتم لاحقًا.

حسنًا،

>> لا، لكن يثير اهتمامي

أنه يمكن تحسين برنامج

دون أن تكون مبرمجًا

في قسم ضمان الجودة،

أي أنهم يستطيعون

التحسين، أتخيل أن

المنهجيات

والاختبارات هي ما

تقودك إلى ذلك. هذا

يثير اهتمامي من جانب

التطوير.

>> نعم،

>> لأنه إذا أردت القيام

بشيء ما، أقوم بإصلاحه

، وأقوم بتنقيحه بنفسي

وأصلحه. لكن من وجهة

نظر شخص لا يبرمج،

يعجبني هذا الأمر،

وتجذب انتباهي

الأدوات وكيفية

التعامل معها، وهو ما

لم أره من قبل. إم،

وسنرى شيئاً لم أخبركم

به. إم، سنقوم بـ ما

أفعله هو عرض مقاطع

فيديو لكم. حسناً، من

الجيد وجود هذه الحصة

لأن كل ما قدمته لكم في

التدريب، على الأقل

أنا أعمل بما يسمى "

جيرا"(Jira). حسناً. إم،

لا أعرف إن كنتم

تعرفونه، إنه مدير

مشاريع.

>> حيث إم لديك جزء

الاختبار الذي يتم

إضافته، ويمكن

التعامل معه مثل "XRay"

أو إضافة الاختبار

التي تسمى "Zephyr". هناك

تتم دورة الاختبار

بالكامل، وتُحدد جميع

تصاميم حالات

الاختبار، ولكن على أي

حال، سأريكم بعد ذلك

فيديو حول كيفية إنشاء

قصة مستخدم، لكنني

سأعطيكم ذلك في

النهاية. حسناً. لماذا

؟ لأنني إذا أعطيتكم

إياه الآن، فلن تفهموا

حتى نصف الأشياء التي

تتناولها تلك

الفيديوهات. حسناً،

إنها فيديوهات أحتفظ

بها للمبتدئين "

الجونيور" ليدركوا

كيفية القيام بالأمور.

حسناً، لنرى، سنقوم

برؤيتها لاحقاً خلال

الدورة لأن الأمر طويل

جداً للحديث عنه

بالكامل الآن، لكنكم

ستطلعون عليه لاحقاً.

حسناً، حسناً. هل هناك

أسئلة أو استفسارات؟

آه، كان لدي سؤال. لقد

ضعت في الجزء الذي

شرحت فيه نموذج الجودة

. لم أفهم ما كان يقصده

كل جملة كانت مرقمة. لا

أعرف إن كان بإمكانك

إخباري أيضاً

>> عن نموذج الجودة وأي

جزء

>> يمكنني إخبارك بكل شيء

. لم أفهم منذ البداية،

لكن حسناً، لا أعرف،

هل يمكنك إخباري بسرعة

أو شيء من هذا القبيل

أم أقرأه؟ يجب أن يكون

موجوداً هناك، لا أعلم

، لكنني أردت معرفة ما

إذا كان بإمكانك

إخباري بشيء.

>> سأضع لك العرض

التقديمي مرة أخرى

لتراه. لكن لتقول لي أي

جزء لم تفهمه ونقوم

بمراجعته.

>> يمكنني ذكر الخمسة،

لكن ذلك كان نموذجاً

قياسياً للجودة. هناك

نماذج مختلفة.

>> بالطبع، لكنني لا أعرف

إن كنت تقصد ذلك أو

شيئاً آخر.

>> لا، لا، لا، لا. إم، لم

أفهم لماذا تحدثت عن

نموذج الجودة، أعني،

بعد ذلك تحدثت عن

الفوائد التي يجلبها،

أليس كذلك؟ لأن

>> سبعة.

>> آها. من السبعة. وقبل

ذلك لم أفهم لماذا قلت

نموذج الجودة. أعني،

هذا ما يتضمنه نموذج

الجودة. ما يجب أن

يتضمنه هو خصائص

إلزامية، يمكن

تكييفها مع أي نوع من

الشركات، شيء من هذا

القبيل. بالطبع، ما

يحدث هو أنني أكرر لك

مجدداً، هذا هو العالم

المثالي. حسناً. إه،

بعد ذلك ستكون هناك

اختلافات بين واحد

وآخر. أنا أتحدث معك عن

العالم المثالي. إنه،

أعني، ما تم شرحه حول

نموذج الجودة هو بشكل

عام، ولكن هناك أنواع

أخرى من النماذج

>> التي ليست، نعم، أعني،

اعتماداً على الشركة،

الـ

>> بالطبع، هذا ما كنا

نتحدث عنه. الآن أصبح

التركيز موجهاً. هنا

فهمتك. أعني، إه، نعم،

أعني، سيكون لديك

الكثير، ولكن لكل منها

نهجها الخاص،

>> مفهوم؟ أعني، أنا

أخبرك بشيء عام، أعني،

بعد ذلك سيختلف كل

واحد.

>> حسناً،

>> أفهم. نعم، نعم، هذا هو

. ذلك، ذلك ما كنت تريد

القيام به. شكراً.

>> نعم، لهذا أكرر مرة

أخرى، أنا أقول لكم

هذا بشكل عام، حسناً.

أعني، إنه العالم

المثالي، المسار

السعيد، ولكن بعد ذلك،

أعني، كل شركة تقوم

بعملها الخاص، يا شباب

. أنا لا أتدخل في ذلك،

لا يمكنني التدخل.

>> بالطبع، بالإضافة إلى

ذلك من منظور تقنية

المعلومات، لأنه لا

يمكنك، على سبيل

المثال، متجر أدوات مع

مطعم، لن يكون لديهما

نفس

>> نفس المعايير التي يجب

اتباعها ولا ضوابط

الجودة.

>> لاحقاً سنرى درساً،

سأتحدث إليكم قليلاً

عن الآيزو، حسناً، لكي

تتمكنوا من رؤية ذلك

جيداً، وعما يدور.

حسناً. أي سؤال؟ كل شيء

واضح، سانتياغو.

>> نعم، كل شيء واضح.

>> حسناً، موضوع تليجرام

، نحن جاهزون كل شيء

على ما يرام. حسناً،

إذا لم يكن لديكم

المزيد من الشكوك،

نلتقي يوم الأربعاء

القادم. لكي أعطيكم

الجزء الآخر، يا شباب.

و نواصل. حسناً،

>> حسناً، حسناً.

>> ممتاز يا أستاذ. شكراً.

عطلة نهاية أسبوع

سعيدة.

>> حسناً، عطلة نهاية

أسبوع سعيدة. نلتقي

يوم الأربعاء القادم،

يوم الاثنين عطلة.

>> نراك. إلى اللقاء.