LOGIN
התחברות או הרשמה
Avatar
להמשך הרשמה ידנית – לחץ על כפתור ההרשמה, להרשמה/כניסה מהירה בעזרת חשבון רשת חברתית – לחץ על הלוגו בכותרת

אפס סיסמה - שכחתי את שם המשתמש

שם משתמש
סיסמה
זכור אותי

he icon   en icon

בכדי להוסיף פוסט בבלוג יש להרשם או להתחבר - ההרשמה/כניסה מתבצעת מכותרת האתר.

ניהול סיכונים בתכנון הפרויקט וכתיבת תסריטים

נכתב על ידי 
ראשון, 19 מרס 2017 11:37
דרגו כתבה זו
(1 הצבעה)

ניהול סיכונים, מושג שאנחנו משתמשים בחיי היום יום כמעט בכל אספקט של החיים.

אנחנו מנהלים את חיינו בניסיון למקסם את האפשרויות השונות עם הכלים שיש לנו.

בעולם פיתוח התוכנה בכלל ובעולם בדיקות התוכנה בפרט אנחנו מנהלים סיכונים כדי שנוציא גרסאות איכותיות ככל הניתן בכלים הקיימים.

 

כדי שנוכל להשתמש בניהול סיכונים בצורה נכונה, בואו נגדיר את משמעות המושג ניהול סיכונים וסיכונים מהם, לפי וויקיפדיה, הפרוש הינו:

"ניהול סיכונים הוא תהליך הקשור בניהול שוטף ומטרתו לאתר סיכונים/מפגעים, הערכת עוצמת הפגיעה/הנזק, תעדוף הטיפול בהם על פי העוצמה, הגדרת השיפור הנדרש וההשקעה הנדרשת לשיפור ובקרה על ביצוע  פעילויות השיפור.

סיכון מוגדר כגורם או פעולה העלולים להתרחש שלא על פי התכנון וכתוצאה ממנו ייגרם נזק, לעלות, לגוף, או לזמן. הסיכון נמדד על פי סבירות המימוש שלו, ברמה הטכנית, התוכניתית או הניהולית, ועוצמת הפגיעה כתוצאה מהכשל מחושבת בעלות, בביצועים או בזמן."

כחלק מניהול פרויקט אנחנו מנהלים משאבים, תכולות וזמנים, על פי רוב יש הבדל עצום בין שלב התכנון לבין שלב הביצוע, המון דברים משתנים במהלך הדרך ולא להכל אנחנו יכולים לצפות.

לכן כמנהלים אנחנו חייבים לנהל את הסיכונים לכל אורך חיי הפרויקט, לנהל את תהליכי הפיתוח והבדיקות ולתת מענה בזמן.

גם כאשר הגדרנו את הסיכונים, אנחנו חייבים לנהל אותם ולתת מענה לכל סיכון ולתת דרכי פעולה איך ניתן למנוע אותם ובמקרה של משבר מה תוכנית המגרה שלנו.

במאמר זה אני אתן דגש על תכנון הבדיקות והתסריטים לכל גרסה.

אנו מנהלים סיכונים משלב הכנת תוכנית הפרויקט ולכל אורך חיי הפרויקט, והמטרה הינה להפחית את השפעת הסיכונים עד השגת יעדי הפרויקט במהלכו ובסופו.

בעולם ניהול הפרויקט ובדיקות תוכנה, כשאנחנו מתכננים את תהליך הבדיקות, אנחנו צריכים לשאול את השאלות הבאות בשלב התכנון, להבין בשלב התכנון את הסיכונים שלנו:

·         מה התכולה שאותה אנו נדרשים לבדוק.

·         מה הם המשאבים שלנו לתכולה הנבדקת.

·         מהו פרק הזמן לבדיקות התכולה, שלב שאותו אנו צריכים להגדיר ותלוי במספר גורמים שיכולים להשפיע על פרק הזמן של הבדיקות (לדוגמא: התחייבות חוזית או חוק רגולטורי).

·         מה החוסרים שלנו (לדוגמא: חוסר בידע, חוסר במעבדות, חוסר בכלים, חוסר בבודקים).

·         מה הסיכונים שעומדים לפנינו (לדוגמא: פרק זמן קצר לבדיקות, חוסר ידע, תלויות בגורמים מחוץ לחברה ועוד)

הבעיה הכי גדולה בתהליך ניהול הסיכונים הינה בסיכונים שאינם ידועים לנו, ולכן אנחנו צריכים לתת Buffer לדברים הלא ידועים ולשיניים שיצוצו במהלך הדרך.

לאחר שהבנו את התכולות, המשאבים, הזמנים והחוסרים שלנו, נוכל לצלול פנימה ולהתחיל להגדיר את הסיכונים הידועים לנו בשלב התכנון, להגדיר אותם ולנהל אותם.

לאורך כל חיי הפרויקט חשוב מאוד לנהל את הסיכונים ולהגדיר אותם מחדש או להגדיר סיכונים חדשים.

בשלב ניתוח הסיכונים אני רוצה להתמקד בניתוח הסיכונים למודולים או תהליך עסקי במערכת שאותם אנחנו אמורים לבדוק הלכה למעשה.

לכל מודול או תהליך עסקי יש מספר מאפיינים מנקודת ההיבט של הפיתוח והבדיקות שאותם אנו צריכים לזהות וגם בשלב זה נשאל את השאלות הרלבנטיות:

·         האם המודול הינו תהליך מרכזי?

·         האם ישנה השפעה על מודולים נוספים?

·         רמת מורכבות הקוד?

·         מה החשיבות של המודול ללקוח?

·         האם טכנולוגית הפיתוח היא חדשה בארגון?

·         האם צוות הפיתוח חדש בארגון?

·         האם לצוות הבדיקות יש ידע קודם על המודול?

·         האם השינוי הינו רגולטורי?

בשלב הזה לכל מודול ניתן ניקוד לכל השאלות בין 1 ל-3, כאשר הציון 1 משמעו השפעה נמוכה והציון 3 הינו השפעה גבוהה.

כך שנקבל לכל מודול רשימה של ציונים לכל פרמטר/שאלה.

נסכם את הציונים לכל מודול וכך נקבל רשימה של מודולים עם ציון סופי, ועכשיו נחלק את הציונים הסופיים לשלוש קבוצות, 8 שאלות * 3 = 24 נקודות, לכן החלוקה לפי ניקוד:

·         המודולים בעלי הציון הגבוהה ביותר – מודולים בסיכון גבוה – ציון 20-24

·         המודולים בעלי ציון ממוצע – מודולים בסיכון בינוני – ציון 14-19

·         המודולים בעלי ציון נמוך – מודולים בסיכון נמוך – ציון 8-13

לכל מודול או תהליך עסקי נבצע את הפעילויות הבאות בהתאם לציון:

·         המודולים בעלי הציון הגבוהה ביותר – נשקיע 100% בכתיבת תסריטים, נבדוק את המודול בצורה מלאה עם כיסוי מקסימלי.

·         המודולים בעלי ציון ממוצע – נשקיע 60% בכתיבת תסריטים תוך דגש על תהליכים עסקיים מרכזיים, נבדוק את המודול עם כיסוי חלקי לפי התסריטים שהגדרנו + exploratory testing.

·         המודולים בעלי ציון נמוך – נשקיע 20% בכתיבת תסריטים, בעיקר בראשי פרקים או check list ונשקיע בעיקר ב- exploratory testing.

 

לסיכום, המטרה הינה לחסוך בצורה מושכלת בזמן כתיבת התסריטים שמשפיעה באופן ישיר על זמן הרצת התסריטים וזמן הבדיקות.

זמן הבדיקות מושפע בהתאם, ככל שנריץ יותר תסריטים זמן הבדיקות יהיה ארוך יותר וזמן הבדיקות של exploratory test קצר יותר ומתאים לבדיקת מומחים שמכירים את התהליך העיסקי.

שונה לאחרונה ב שני, 20 מרס 2017 05:58

חובה להיות משתמש רשום במערכת בכדי להגיב - ההרשמה/כניסה בכותרת האתר

חדשות מעולם הבדיקות

  • Check the Effectiveness of Your Automated Tests

    Check the Effectiveness of Your Automated Tests Have you ever found yourself working on an automated test suite and wondered if it's worth the effort? It's probably a typical thought that goes through the minds of every developer and tester working on test automation. Even in all of my years of building and maintaining automated tests, I admittedly find myself thinking this way occasionally, wondering if there's a better use of time elsewhere on the project.Whenever I notice teams of developers and testers not putting any emphasis on test automation, it's usually because there's a level of uncertainty in the effectiveness of automated tests. The team might think it would help their work but can't or won't dedicate some time to know for sure. Worse yet, some teams believe that test automation is an added burden to the software development and testing process with little to no reward. These developers and testers proceed with the belief that they can deliver quality work faster by skipping these types of tests.Even teams with a solid test automation strategy in their workflow have some reservations about the effectiveness of their test suite. They can't figure out how to gauge the success of their testing work and try to find ways to measure it, like counting the number of automated test cases or keeping track of code coverage. While these seem like good metrics, they're not as valuable as you might think.If you're in a team trying to determine if your test automation work is worth the effort, how can you[…]

    30.11.2021 | 5:00 קרא עוד...
  • “Spring Testing Tips” Webinar Recording

    SPRING IS HERE! Well, not really. Well, according to my window it looks like it, but the calendar says otherwise. But the recording of the Tips for Spring Testing webinar is here. In fact, it’s just below. Check it out! Oh, and if you’re interested in some training on these topics, let me know! The post “Spring Testing Tips” Webinar Recording first appeared on Everyday Unit Testing.

    30.11.2021 | 2:27 קרא עוד...
  • What testing does your team do that is Lean?

    What testing does your team do that is Lean? We want to find bugs as early as possible so that the cost of fixing them is as little as possible. The earlier a bug is found the cheaper it is to fix. If a bug is found and fixed in a specification before any code is written then it costs very little to fix. If a bug is found during development then it costs some development time to fix it. If a bug is found in production and fixed then the cost to fix it includes some development time, some customer service time and its effect on customers. A lean perspective expresses this in another way as lean is about reducing waste and improving the flow of work. Bugs are waste so finding bugs early is lean because it reduces waste, and so improves the flow of work. The value of testing as early as possible was highlighted by Tom Gilb when I heard him speak about ‘Lean QA’ a few years ago. He spoke about how it is best to find issues as early as possible in development. The advantages are clear in theory and it is helpful to be able to give examples. Tom Gilb spoke about inspecting specifications for software before code is written as an example of early testing and showed how many issues can be identified by inspecting the specifications. One way for testers to help with inspecting specifications is to review requirements with a developer before they start work as this may identify[…]

    30.11.2021 | 2:10 קרא עוד...

טיפים

  • בדיקות מוצלחות = בדיקות בראיית לקוח
    בדיקות מוצלחות = בדיקות בראיית לקוח בדיקות מוצלחות = בדיקות בראיית לקוח - בדיקות שנעשות בהתבסס על איך שהלקוח היה מצפה לקבל את המוצר. טיפים מחברי ITCB-AB
    קרא עוד...
  • בדוק מוקדם ככול הניתן
    בדוק מוקדם ככול הניתן "בדוק מוקדם ככול הניתן" – אחת המטרות של הבדיקות הינה לספק כמה שיותר משוב ומידע לגבי איכות המערכת מנקודות מבט שונות (פונקציונליות ולא פונקציונליות כמו עמידה בעומסים ושאר יכולות). לעיתים בודקים נוטים בטעות לחשוב כי הדרך…
    קרא עוד...
לרשימה המלאה >>