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

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

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

  • The challenge of prioritizing bugs

    The challenge of prioritizing bugs ...

    20.10.2019 | 11:07 קרא עוד...
  • 92: 9 Steps to Crater Quality & Destroy Customer Satisfaction - Cristian Medina

    Cristian Medina wrote an article recently called "Test Engineering Anti-Patterns: Destroy Your Customer Satisfaction and Crater Your Quality By Using These 9 Easy Organizational Practices" Of course, it's sarcastic, and aims to highlight many problems with organizational practices that reduce software quality. The article doesn't go out of character, and only promotes the anti-patterns. However, in this interview, we discuss each point, and the corollary of what you really should do. At least, our perspectives. Here's the list of all the points discussed in the article and in this episode: Make the Test teams solely responsible for quality Require all tests to be automated before releasing Require 100% code coverage Isolate the Test organization from Development Measure the success of the process, not the product. Metrics, if rewarded, will always be gamed. Require granular projections from engineers Reward quick patching instead of solving Plan for today instead of tomorrow Special Guest: Cristian Medina.Sponsored By: Azure Pipelines: Automate your builds and deployments with pipelines so you spend less time with the nuts and bolts and more time being creative. Many organizations and open source projects are using Azure Pipelines already. Get started for free at azure.com/pipelines Support Test & CodeLinks: Test Engineering Anti-Patterns: Destroy Your Customer Satisfaction and Crater Your Quality By Using These 9 Easy Organizational Practices — The article we discuss in the show. tryexceptpass — Cris's blog

    20.10.2019 | 2:00 קרא עוד...
  • What is a Customer?

    What Is A Customer? In the world of Agile, and the world of business too, we hear a lot about “customer value”. Folks seem to have some kind of handle on “value” (although not everyone can agree on that one – see my post “What Is Value” for my take, based on Goldratt and his Theory of Constraints). And for the record, we might also choose to frame the question of value within the Antimatter Principle frame, and vocabulary: Value: The degree to which folks’ needs, in aggregate, are being (or have been) met. But what about “customer”? So simple and straightforward. Do we even need to define it? I thought not, until a recent conversation on Twitter gave me pause for reconsidering. Specifically, the idea that maybe folks are talking at major cross-purposes, with significantly differing assumptions and definitions for the term. If we can’t agree on a basic term like “customer”, what chance alignment of a whole host of fundamental questions about software, products and business generally? Here’s my definition, again using the Antimatter Principle as a frame: Customer: Someone (could be either a person, or a collection of people) whose needs we’re attending to. I’m pretty sure you’ll have a different definition of customer. I’d love to hear your take. Before I close this post, here’s a different definition, informed by Crosby and his Zero-Defects (ZeeDee) approach to quality: Customer: Anyone who receives or anticipates receiving something (e.g. a good or a service) from someone else. This[…]

    19.10.2019 | 5:51 קרא עוד...

טיפים

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