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

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

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

  • User experience (UX) and data quality

    User experience (UX) and data quality Someone I know was moaning recently about a lot of tedious electronic form filling they had to do for work.  It was something that happened once a year, but it was much more lengthy and tedious this year than before.  It struck me that this was a sharply focused example of when user experience (UX) and data quality collide. I realised that I haven’t talked about these two together so far, so this article is a fairly random collection of thoughts about the relationship between UX and data quality. Defining terms I’ve already gone into the meaning of UX a few times, so I won’t repeat that here.  Data quality could (like UX) have lots of definitions, but I’ll go with one inspired by the RST definition of a bug: poor data quality means that you have data that’s less valuable to you than it might otherwise be. This is things like: You have less data than you’d like (in terms of rows, filled-in i.e. non-null columns, or both);Some or all of it is unusable;If you process the data then the output will be less valuable than you’d like, or it will take a lot of effort to get the data into a state where processing it will produce valuable output. Drilling down one more level: Data might be unusable because e.g. a field that should hold the name of a day of the week instead contains the word hippopotamus;Data might produce bad outputs if e.g. it contains duplicate rows,[…]

    23.01.2021 | 4:21 קרא עוד...
  • First Aid for the Mission Statement

    A while back, a tester brought a patient in for treatment. It wasn’t a human patient; it was a sentence about building and testing in an organization. The tester asked me for help. “Could you provide me with a first aid kit for this statement that came from my management?” “We have to move on to DevOps to be able to release code more often but we also have to increase testautomation in any way we can and minimize manual time consuming testing.” This is the sort of statement that needs more than first aid; it needs emergency room treatment. We’ll start with handling some critical problems right away to get the patient stabilized. Then we need to prepare the way for longer-term recovery, so that the patient can be restored to good health and become an asset to society. I’ll suggest a number of quick treatments. As I do that, I’ll identify why I believe the patient needs them. Replace “have to” with “choose to” in each case. Unless someone is about to run afoul laws of nature, of government, or of ethics, no one has to do anything. People and organizations choose to do things. It’s important to preserve your agency. When you have to do things, you don’t have control over them. When you choose to do things, you remain in charge. Replace “move on to DevOps” with “apply DevOps principles and practices”. DevOps is not something to do; it’s a set of ideas and approaches for[…]

    23.01.2021 | 3:57 קרא עוד...
  • Sort numbers with python

    Sometimes we need to sort numbers. In this post I will give a solution a fictive sorting problem. I want to sort numbers with python. Sorting is a part of many tasks. It is useful to know how to use the sorting function in python. We have a list with positive and negative numbers. Create a function that sorts the list by the absolute values. This means without the sign. Some examples will explain what I want to do: sorting [-20, -5, 10, 15] results in [-5, 10, 15, -20]sorting [1, 2, 3, 0] results in [0, 1, 2, 3]sorting [-1, -2, -3, 0] results in [0, -1, -2, -3] My first solution uses the build in sorted function. Let’s create a function that has an input parameter and returns the sorted array. The sorted function has two input parameters. The first one is the list or iterable that you want to sort. The second one is a comparison key from each element in the list. sort_numbers(input): return sorted(input, key=lambda x: abs(x)) sort_numbers([-1,-2,-4,0]) The sorted function will return a new array. The result is sorted according our rules. There is an other solution. A lambda function can be used. sort_numbers=lambda n:sorted(n,key=abs) sort_numbers([-1,-2,-4,0]) The key can be just the abs function. There is no need to create an extra lambda. A list object in python has a sort method. This method will modify the list in place. The output is the same. the_numbers = [-1,-2,-4,0] the_numbers.sort(key=abs) This solution is not the[…]

    23.01.2021 | 12:08 קרא עוד...

טיפים

לרשימה המלאה >>