Seven Principles Of Software Testing:

1- Testing shows the presence of defects, not their absence.

2- Exhaustive testing is impossible.

3- Early testing saves time & money

4- Defects cluster together

5- Beware of the pesticide paradox

6- Testing is context dependent

7- The absence of errors is a fallacy

Testing shows the presence of defects, not their absence.

--> Testing reduces the probability of undiscovered defects but it is not a proof of correctness

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

وهذا المبدأ يوضح أنّ العميل يمكن أن لا يكون راضي عند تسليم المشروع حتى بعد إيجاد المشاكل وحلّها، حيث أنّ هناك إختلاف بين ال verficiation وال validation.

اكتشافك لمئة مشكلة وحلّهم لا يعني بالضرورة رضى العميل عن المنتج النهائي، وعدم إيجادك لأيّة مشكلة لا يعني أنّ النظام لا يحتوي على مشاكل.

Exhaustive Testing Is Impossible.

--> Testing everything is not feasible except for trivial cases

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

الخلاصة لا يمكننا أبداً القول أنّنا أنهينا عملية الإختبار بنسبة 100%، لكن يمكننا القول أنّ نسبة الخطر وإمكانية حدوث أخطاء عند المستخدم قد قلّت.

Early Testing Saves Time & Money (Shift Left)

--> To find defects early, both static and dynamic test activities should be started as early as possible.

باختصار هذا المبدأ يعني أنّنا كلّما بدأنا بعملية الفحص في وقت أبكر، كلّما وفرّنا وقت ومال. فالأفضل أن تبدأ عملية الإختبار من لحظة البدء في جمع المتطلبات في حالة الـ static testing، أمّا في حالة الـ dynamic testing فالبدء المبكر يعني البدء في الإختبار عندما يصبح أي من أجزاء الـ software جاهز للفحص.

ويسمى هذا المبدأ بـ shift left أيّ أنّنا نقوم بإزاحة عملية الإختبار إلى اليسار أيّ إلى البداية (من اليسار إلى اليمين) ممّا يحسّن من جودة المشروع.

Defects Cluster Together

--> A small number of modules usually contains most of the defects discovered during pre-release testing.

يعني أنّ الـ defects أو الـ bugs تتّجمع معاً. حيث تمّ أخذ هذا المبدأ من إحدى مبادئ الإقتصاد والذي ينصّ على أنّ 80% من المشاكل سببها 20% من الأسباب.

والفكرة ذاتها تنطبق على الـ software حيث يكون عدد قليل من الـ modules أو ما يمثّل نسبة 20% متسبب في 80% من المشاكل.

فالتصرّف الصحيح من الـ tester أن يتوقع ما هي الـ modules التي تحتوي على أكثر عدد من الـ bugs والتركيز عليها من خلال الـ risk analysis ومراقبة ماذا ما هي الـmodules التي تحتوي على أكثر عدد من الـ bugs.

Beware Of Pesticide Paradox

--> If the same tests are repeated over and over again, these tests no longer find any new defects.

وتعني متلازمة المبيد الحشري، يعني لو كنتَ تستخدم دائماً نفس المبيد الحشري فمن الممكن أن يصبح عند الحشرات مناعة ضد هذا النوع من المبيدات الحشرية فالحلّ هنا هو تغيير المبيد الحشري، والأمر ذاته في فحص البرمجيات، فعندما تعيد نفس عملية الـ test بنفس الطريقة مراراً وتكراراً ستصل لمرحلة أنّك لن تجد أخطاء جديدة، فالحل هنا هو تغيير طريقة التفكير وكتابة test cases جديدة، أو تغيير نوع الـ testing ، مثلاً إن كنت تختبر الـ performance قم بالإنتقال لإختبار الـ security وهكذا.

Testing Is Context Dependent

--> Testing is done differently in different contexts.

تعتمد عملية الإختبار على المجال أو السياق الذي يتم العمل به، فإختبار تطبيق طبي يختلف عن موقع تعليمي يختلف عن لعبة ترفيهية وإلخ.

The absence of errors is a fallacy

--> It is a fallacy to expect that just finding and fixing a large number of defects will ensure the success of a system.

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

Popular Articles

Latest Articles