ال incident management من الأجزاء المهمة في ال test management | اعرف اكثر عن ال test management
ان شاءالله اليوم سوف نتحدث عن جزء مهم من أجزاء ال test management وهو ال incident management، تحدثنا سابقا عن ال test organization وعن العوامل
اللى بتؤثر على ال test planning وعرفنا ما هى ال test planning activities، وتحدثنا
أيضا عن ال test monitoring and control وال configration management وال risk management،
واليوم ان شاءالله سوف نتحدث عن جزء أخر من أجزاء ال test management وهو ال incident management، وهنعرف أهداف ال incident report وايه العناصر أو التفاصيل اللى بنكتبها
فى ال incident report وماهى دورة حياة ال incident.
ماهى ال incident وما الغرض من عمل incident report
ال incident هى عبارة عن ال unexpected actual result اللى بتظهر لحد مانبحث عنها ونعرف أسبابها ونحكم عليها هى bug ولا لأ و نصلحها
ونعمل لها closed، ال incident زى ال bug لكن ال bug بكون متأكد انها bug انما ال incident لا نكون متأكدين من كونها bug، ال incident بتظهر فى مراحل ال devlopment وال review و
ال testing و ال software product usage .
أهداف ال incident report
١- من خلاله بنعطى ال stackholders وال developers خلفية عن المشاكل اللى المشروع بيقابلها.
٢- ال incident report بيساعد ال test leaders انهم يحددوا ال quality بتاعت السيستيم.
٣- ال incident report بيساعدنى اننا نتعلم من
الدروس المستفادة من المشاكل اللى بتقابلنا فى كل مشروع وبالتالى نحسن من ال test process.
العناصر اللى ممكن يشتمل عليها ال incident report
بنسجل فى ال incident report ال date وال organization وال author اللى اكتشف ال incident، و بنسجل فيه ال expected result وال actual result، ولازم
نوصف فيه ال environment اللى عملنا من خلالها التيست، وبنكون محتاجين نوضح فى أى مرحلة من مراحل ال software life cycle ظهرت لنا هذه ال incident، وبنوصف
فيه الخطوات اللى عن طريقها ظهرت ال incident بالإضافة الى ال screen shots وال databases وال logs، و بنكتب تأثيرها على ال stack holders وهذا بيشمل ال severity وال priority، و بنكتب حالة ال incident هل opened و لا fixed ولا duplicated، ولازم
نكتب فى الآخر ال conclusion و ال recommendations وال approvals علشان نحاول منخليش هذه
المشاكل تحصل تانى بعد كده، و بنكتب ال global issues يعنى لما اتصلحت أثرت على
أماكن تانية ولا لأ وبنذكر هذه المناطق المتأثرة، وبنكتب ال change history علشان نثبت انها اتصلحت، و بنكتب
ال references وهى عبارة عن الحاجات اللى تسببت فى ظهور هذه ال incident.
ال incident life cycle
عندنا عدد من السيناريوهات اللى بتمر بها ال incident:
١- يتم توثيق ال incident ثم يتم مراجعتها فإذا
كانت جميع المعلومات الخاصة بها تم توثيقها بشكل صحيح بتكون الحالة الخاصة بها opened لكى يتم تصليحها ثم تتغير الحالة الخاصة بها الى fixed ثم يتم التأكد من انه
تم تصليحها ولم تؤثر على أى module ٱخر فى السيستيم ثم يتم اغلاقها وتكون الحالة
الخاصة بها closed.
٢- يمكن ان يكون توثيقها قد تم بشكل سئ وعندئذ
بيتم رفضها وتكون الحالة الخاصة بها rejected فييتم اعادة توثيقها مرة أخري.
٣- يمكن بعد ان يتم فتحها يؤجل تصليحها ل build أخر ثم يتم إعادة فتحها لكى يتم تصليحها.
والمسئول عن الحاجات دى هم ال reviewers و ال test leader و
ال test team وال development leader و ال development team .
ال incident report طبقا لل IEE Standards
يشتمل على اربعة عناصر:
١- test incident report identifier: وهو
بيمثل اسم ورقم المشروع اللى لاقينا فيه ال incident وال version الخاص به.
٢- summary of incident: وهو بيكون عبارة عن
ملخص لل incident.
٣- description: وهو بيكون عبارة عن وصف
تفصيلى علشان أسهل على ال devlopers حلها، و بيشمل العناصر الآتية:
ال inputs : بنوضح فيها ايه ال files وال keystrokes وال procedures اللى وصلتنى لهذه ال incident.
ال expected results : بنوضح فيها النتائج الإفتراضية لل test cases.
ال actual results: بنسجل فيها الوقائع اللى حصلت بالفعل مش
الإفتراضي.
ال anomalies: بنكتب فيه ال unexpected result by versions عن كل اللى كنت متوقعه فى ال expected result.
ال date and time: بنسجل فيه الوقت اللى حدث فيه
ال incident.
ال procedure step: بتعمل identity لكل ال steps اللى لاقيت
فيها ال incident ، وايه الprocedures اللى هتتعمل، وايه ال environment اللى كنت
شغال عليها لما لاقيت هذه ال incident، وايه ال version browser و ال hardware وال network وال software.
ال attempts to repeat: بيكون عبارة عن عدد المرات اللى
جربت فيها ظهور هذه ال incident قبل ما أعمل لها report.
ال testers: بنكتب فيه مين التيستر اللى اكتشف ال incident.
ال observers: هم الأشخاص الآخرين (غير التيستر) اللى
لاحظوا ظهور نفس المشكلة.
٤- ال impact section : بيوضح ال actual and potential damage اللى بتعملها ال incident اللى اكتشفناها ودائما بتتصنف اما على أساس
ال severity of incident أو على أساس ال priority to fix that incident.
ال severity of incident : بتوضح تأثير ال incident خلال
مرحلة ال production، عندنا اربع مستويات لل severity :
١- critical: هذه ال incident بتضرب لى فى core السيستيم وملهاش حل ولازم تتصلح.
٢- major: هذه ال incident بتضرب لى فى core السيستيم ولكن في حل.
٣- minor: هذه ال incident مش بتعمل failure لكن
بتعمل سيستيم مش كامل ولا متناسق.
٤- low:هذه ال incident ممكن نعملها أو نأجلها
مش هتعمل مشكلة.
ال priority of incident
عندنا اربع مستويات أيضا لل priority of incident:
١-high:يعنى كل حاجة واقفة و السيستيم مش
هيشتغل إلا لما تتحل هذه ال defect.
٢- medium : بنقدر نستخدم السيستيم لكن تأثيرها
عليه عالى جدا، ومش هنعرف نستخدمه بكفاءة إلا لما تتصلح.
٣- normal:بنقدر نستخدم السيستيم لحد ال next build أو ال next release.
٤- low: هذه الديفيكت ممكن نأجلها أونتجاهلها مش
هتأثر على السيستيم.
واللى بيحدد مستوي ال priority هو ال bug reviewers.
وهذا فيديو بيتكلم عن ال incident management.
موضوعات قد تهمك
.performance testing مقدمة عن ال
.software testing مقدمة عن ال
. testing لعملية ال organization كيفية عمل
.test planning العوامل التى تؤثرعلى ال
.test effort وال test planning activities ال
.test monitoring and control ال
.risk managemen وال configration management ال
تعليقات