Setting Goals and Milestones
في الـ Quality Engineering لازم الفريق يحدد المهام اللي مفروض يعملها ، و امتى. يحدد ايه هي انواع الـ Bugs اللي ليها high priority و بالتالي لازم تتصلح قبل اي حاجة تانية ، ايه هي الBugs اللي ليها Priority اقل شوية ، و ايه هي الـ Bugs اللي ممكن يتغاضى عنها و ممكن تسليم الـ Product بدون اصلاحها ﻷنها مش بتأثر على Quality Requirements اللي تم تحديدها في البداية.
تصنيف المشاكل:
يمكن تصنيف انواع المشاكل او الـ Bugs لكذا نوع ، و على اساسها ممكن نحدد لكل نوع من دول Priority معينة ، مش ثابتة و لكن بتختلف باختلاف الـ Project اللي شغالين عليه و الـ Requirements بتاعته.
و من الانواع دي :
1- Cosmetic : و هي مشاكل في الشكل الخارجي او الـ User Interface للبرنامج او الـ Application.
2- Performance : مشاكل بالنسبة لكفاءة و اداء البرنامج مثلاً عدد الـ Calculations اللي يقدر يعملها في الثانية و هكذا.
3- Crash : مشاكل بتؤدي لتعطيل البرنامج خالص أو حتى الـ Operating System اللي هيشتغل فيه.
4- Non-Functioning : أجزاء من البرنامج لا تؤدي الوظيفة اللي مفروض تأديها ، مثلاً Button في
الـ Application المفروض يعمل Send لما تضغط عليه ، لكن لما تضغط عليه مفيش اي حاجة بتحصل.
5- Incorrectly Functioning : جزء من البرنامج بيؤدي وظيفة غلط ، زي مثلاً Button المفروض يعمل Save لـ File لكن لما عملتله Test بيعمل Open او بيمسح.
6- Incorrectly Functioning with a Workaround : جزء من البرنامج بيؤدي وظيفة غلط ، لكن ممكن يؤدي الوظيفة الصح عن طريق حاجة معينة مش موجودة في الـ Manual او الـ Documentation الموجود مع
الـ Application.
لو حاولنا نرتبهم كمثال – لكن مش ثابت – ، طبقاً للـ Priority ممكن نخلي Crash Bugs اعلى واحدة فى الاهمية ، عشان احنا مش عايزين البرنامج يقف او يوقف الـ OS أهم حاجة بالنسبة لنا ، بعد كده ممكن تيجي Non-Functioning و بعدها Incorrectly Functioning و Incorrectly Functioning with a Workaround و بالنسبة لنا يكون Performance بعدهم و ف الاخر خالص Cosmetic Bugs.
الانواع اللي فاتت من المشاكل ، مش بيكون ليها نفس الأولوية في كل المشاريع ، عشان كده لازم الـ Quality Team في بداية المشروع يحددوا مع بعض و يتفقوا ايه هتكون اولوية كل نوع من انواع الـ Bugs دي و بناءً عليه تمشي خطة العمل.
بعد ما رتبنا الـ Priorities ممكن نعمل Matrix زي دي ، عشان نقدر نحدد ايه اللي هنعمله بالظبط و امتى.
بناءً على الـ Matrix اللي عاملينها في المثال ده فاحنا لو عندنا مشكلة Crash بتواجه من 75-100 % من الـ users ، لازم تتحل في أسرع وقت ممكن. في حين مثلاً لو عندنا مشكلة Cosmetic بتواجه اقل من 25% من الـ users فهي بالنسبة لنا مش مهمة و هنعمل Release للـ Version الجديدة عادي. و ممكن على اساس الـ Matrix دي تاخد اي قرار مشابه مثلاً لو الـ Deadline بتاع تسليم الـ Project قرّب و اكتشفت ان فيه Bug من نوع Incorrectly Functioning with a Workaround و بتواجه اقل من 25% و في نفس الوقت لو هتعملها Fix هتاخد وقت كبير جداً و هتأخرك ، بالتالي ممكن تتجاهل و تعمل Shipping للـ Product من غير ما تعمل Fix بما انها مش هتأثر على Quality Requirements اللي حددتها مع الفريق مسبقاً.
