שם משתמש סיסמא
כניסה
זכור אותי במחשב זה שכחתי סיסמא
הרשמה לאתר ספק מיחשוב משתמש
חפש חיפוש מתקדם
דף הבית | כנסים | מכרזים | שאלות נפוצות | סיפורי לקוחות | תנאי השימוש באתר | הצהרת פרטיות | אודותינו | צור קשר
מאמרים וסקרי שוק
SYSTEM TESTING & QUALITY ASSURANCE -שלושת הרבדים של בדיקות ואבטחת איכות
מבוא - כללי
כולם מתכוונים לטובה. כולם רוצים לסייע בהשגת המטרה הנכספת של מערכת עובדת ומתפקדת כראוי, בלי נפילות ותקלות, לשביעות רצון הלקוח; מערכת שתועלתה מרובה על עלותה ושתורמת לתפקוד הארגון וקידום מטרותיו.
ראש וראשון "המתכוונים לטובה" הוא כמובן צוות הפיתוח בראשותו של מנהל הפרויקט, כאשר ועדת ההיגוי מעליו, מומחה היישום \ הלקוח מימינו ומומחים במקצועות התומכים: אבטחת מידע, ממשק אדם מחשב, סיוע טכני וכו' לשמאלו. צוות נכבד לכל הדעות (בתנאי כמובן שהוא זמין ומיומן). מספיק? לא! חסרות שתי פונקציות מרכזיות נוספות: בדיקות (Testing) ואבטחת איכות (Quality Assurance). רבים וטובים ניסו בלעדיהן - רבים וטובים נכשלו. תיאורטית אמנם, אם כולם "ישתדלו להיות איכותיים", אם כולם "יבדקו את עצמם כל הזמן", אולי אין צורך בגורם נוסף - חיצוני - שיבדוק ויוודא את איכות הפרויקט (המערכת!). אמרנו תיאורטית. מעשית, זה לא הולך. חייבים להוסיף את שתי הפונקציות האלה: אבטחת איכות ובדיקות.
אך מה ההבדל בין שתיהן? למה צריך את שתיהן?
לפני שנחדד את ההבדלים בין שתי פונקציות חיוניות אלה, כדאי דווקא להדגיש את המשותף. אבטחת איכות ובדיקות הם ה - Second opinion של הפרויקט. (יש שמוכנים אפילו להגדרה חריפה יותר, "האיש הרע" של הפרויקט, "פרקליט השטן" של הפרויקט - Project Devil Advocate - DA)). כך או כך, תפקיד איש אבטחת איכות ואיש הבדיקות הוא לבחון את המערכת מנקודת מבט שונה, לשאול את השאלות שלא תמיד שואלים, להיות הספקן כאשר כולם מאמינים ומתלהבים, להתעקש כל הזמן על ה"מה" וה"איך" ומה בדיוק יהיה באבן הדרך הבאה של הפרויקט וכו'.
יש הטוענים שההבדל הוא בין ה"מה" וה"איך" שזה עתה הזכרנו, בין התוכן והמהות ובין הצורה והתפקוד. מומחה הבדיקות, לפי טענה זו, מתמקד יותר בצורה, ב"איך" ובתפקוד המערכת בהתאם לדרישות שהוגדרו. הוא בודק את המערכת מול תיק האפיון ואינו שואל "למה" ו"בשביל מה" על תיק האפיון. איש אבטחת איכות, לעומת זאת, מתעכב גם על תכני המערכת, על היעדים, על הלקוח שצריך לקבל את השירות המבוקש, על מהות המערכת. יש משהו נכון בהבחנה זו, אבל אין היא העיקר ולא תמיד מדויקת.
אז מה בכל זאת ההבדל?
האיור הבא ממחיש את "מודל שלושת הרבדים" של אבטחת איכות ובדיקות בגישת מפת"ח.
QA1
איור מס' 1: מודל "שלושת הרבדים" של אבטחת איכות ובדיקות בתוכנה

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

שלב בדיקות המערכת
ב"ליבה" של אימות איכות המערכת ומוכנותה, היה ונשאר שלב מיוחד במחזור החיים של הפרויקט, שלב בדיקות המערכת, אשר מוקדש לבדיקה מקיפה של המערכת לפני התקנתה והעברתה לייצור ותפעול שוטף. בדיקה זו כוללת שני נושאים עיקריים:
  1. בדיקות מערכת מקצועיות מקיפות - System Testing
  2. בדיקות קבלה של המשתמשים \ מומחי היישום - Acceptance Tests
בין אם בוצעו פעילויות איכות ובדיקות לאורך מחזור החיים, באפיון ובפיתוח, בין אם לא, יש לבצע בדיקות מערכת מקיפות (ההבדל יכול להיות רק בהיקף המדויק ובמינון). התמקדות בשלב זה היא בבניית תכנית הבדיקה (STP - System Test Plan), ניהול הבדיקות, תיקי בדיקות לסוגיהם, כתיבת תסריטים ותרחישים, נתוני אכלוס (Test Data), תיקי ממצאים וסיכומי בדיקות למיניהם. כלי העזר הם: מתודולוגיה סדורה, טכניקות בדיקה, כלים ממוחשבים, טפסים וכמובן צוות בדיקות מיומן. כל זה, בהתאמה לרמות והיקפים שונים של בדיקות: בדיקות תוכנה בלבד, בדיקות ליחידות מסירה (סבבי פיתוח), בדיקות רגרסיה למערכות בתחזוקה ולמהדורות חדשות וכו'. מבחון התוצאה המרכזי של שלב הבדיקות הוא ההחלטה אם להעביר את המערכת (או את יחידת המסירה) לייצור או להחזירה לצוות הפיתוח.
התרומה המרכזית של מפת"ח לרובד "ליבתי" חשוב זה הוא קיט בדיקות מערכת מפותח ומלא, אשר כולל גם התאמות וקיצורי דרך, בלי לוותר על איכות הבדיקות, לפרויקטים קטנים ו"זריזים". בנוסף, יש למתודה ערכה מפותחת עוד יותר בשם MethodTesting. בליבה של הערכה נמצאת תיקיית ניהול שלב הבדיקות אשר כוללת את כל הגלופות הנדרשות, הפניה לנהלים ולכלים הממוחשבים ועוד.
QA2
איור מס' 2: תרשים שלב הבדיקות - מתוך מפת"ח 2006
אימות והוכחת תקפות
אימות והוכחת תקפות (V&V), הוא מכלול הפעולות התורמות לבדיקת המערכת שאינן חלק משלב הבדיקות עצמו. הדגש כאן הוא על "בדיקות מלוות פיתוח", היינו על כל הבדיקות שנעשות לאורך מחזור החיים של הפרויקט: אפיון, עיצוב ובנייה, התקנה והרצה, תפעול ותחזוקה, להוציא את שלב הבדיקות כאמור. ביתר פירוט מכיל נושא זה את תת-הנושאים הבאים:
  • גלגולה של תכנית הבדיקה (רכיב 4.8.1 בעץ המערכת של מפת"ח, זה שבהמשך יהפוך לאורך מחזור החיים, לפני וגם אחרי שלב הבדיקות)
  • שיקופים וסקרים – Reviews לאורך כל תהליך הפיתוח
  • תכנון וביצוע בדיקות יחידה – Unit Tests
  • בדיקות קוד – Code inspection
  • בדיקות שילוב והתקנות
  • בדיקות בסביבות פיתוח דינאמיות: RAD, יחידות מסירה וכו'

התרומה של נוהל מפת"ח לרובד חשוב זה בא לידי ביטוי במספר קיטים חשובים, כגון: קיט שיקופים וסקרים - Reviews אשר שודרג באופן משמעותי במפת"ח 2006, בדיקות יחידה ובדיקות קוד בקיט עיצוב ובנייה ומחזורי חיים דינאמיים. בנוסף, יש במפת"ח קיט בשם אימות והוכחת תקפות - V&V אשר סוקר את הנושא בכללותו ומפנה אל הקיטים הייעודיים הנדרשים.
QA3
איור מס' 3: פריסת בדיקות המערכת V&V לאורך מחזור החיים של הפרויקט
ניהול האיכות - אבטחת איכות כוללת
אבטחת איכות היא כל מה שכלול ברובד הקודם: אימות והוכחת תקפות, + נושאים הקשורים גם לכל אופן ניהול הפרויקט והיבטים עסקיים\ארגוניים הקשורים במהות המערכת ותפקודה הכולל. מדובר כאן באבטחת איכות ניהולית עסקית המשלימה את אבטחת איכות הטכנית\מקצועית שתוארה ברובד הקודם. בהגדרה הרחבה והכוללת, אבטחת איכות היא מתודולוגיית מפת"ח כולה. באופן יותר ממוקד, הכוונה ברובד זה לנושאים כמו:
  • ניתוח סיכונים
  • ניתוח חלופות
  • תיעוד המערכת: כתיבה, ניהול ובקרה
  • אמידת עלויות
  • ניתוח עלות\תועלת
  • עמידה בתקני איכות, כגון: ISO9000, CMMI
  • ניהול תצורה
  • ניהול דרישות
  • הגדרות מדדים וביצוע מדידה לאורך כל הפרויקט
  • ועוד.

גם נושאים אלה מכוסים בקיטים ייעודיים בנוהל מפת"ח אשר משודרגים כל העת.
סיכום - מערכת לניהול האיכות - QMS
אבטחת איכות ובדיקות הם שני נושאים משלימים אך שונים. הבדלי הגישה הם ברורים:
  • " פעילות הבדיקות היא יותר "טכנית" ומתמקדת בבדיקה שהמערכת פועלת בהתאם לדרישות שהוגדרו לה. גם אם פעילות הבדיקות מלווה בצמוד את פיתוח המערכת, היא מתמקדת בנושא הנ"ל: מה נבדוק (מול מסמך הגדרת דרישות עדכני) ואיך נבדוק ונציג את הממצאים, היינו, תכנית בדיקות ברורה, בניית תסריטים, שימוש בכלי בדיקה ועוד.
  • " אבטחת איכות שואלת גם "למה" ו"בשביל מה" ומתמקדת על שלושת קודקודי משולש הפרויקט: תכנים, לוחות זמנים ועלויות. אבטחת איכות שואלת אם נבחנו חלופות, אם הוגדרו מדדי עלות\תועלת, אם הצוותים הוכשרו, אם יש קשר לתכנית העבודה השנתית של הארגון, מי מבצע ניהול תצורה, מה הם כלי הפיתוח, איך עושים ניהול סיכונים וכו'. ובכל אחד מהם, היא מנסה גם לעזור ולסייע ולא רק להיות "מבקר".

עם זאת, יש גם שטח אפור לא קטן. שטח זה הוא כל הרובד של אימות והוכחת תקפות אשר אנשי בדיקות מנסים לנכס אותו אליהם ואילו אנשי אבטחת איכות מנסים לנכס אותו אליהם. אנשי הבדיקות יטענו שהעיקר בסופו של דבר הוא קיום בדיקות מערכת במטרה לוודא שהמערכת מתפקדת כראוי. אנשי אבטחת איכות, לעומת זאת, יטענו שעל מנת להגיע למערכת שבכלל ניתן לבדוק אותה, עוד לפני מערכת מתפקדת, יש לבצע פעילויות ניהול איכות שוטפות, הרבה לפני שלב הבדיקות. זאת ועוד, גם מערכת "מתפקדת כראוי", עדיין איננה ערובה למערכת פונקציונאלית ועסקית שעומדת ביעדים שהוגדרו לה, בלוחות הזמנים ובתקציב, ושתורמת לניהול העסקי של הארגון. ויש כמובן גם את הנושא של אבטחת איכות לשלב הבדיקות עצמו!
על הצד התיאורטי אפשר להתווכח ללא סוף. בפועל, גורם מאד משמעותי הוא היקף הפרויקט והארגון (המיזם). ככל שהארגון ו\או הפרויקט גדול יותר, תהיה נטייה להיעזר הן בפונקצית הבדיקות והן באבטחת איכות. יש מקום לשניהם תחת קורת גג רחבה אחת. ויש גם מקום שאבטחת איכות תבדוק, כאמור, גם את הגוף הבודק. מאידך, ככל שהארגון ו\או הפרויקט קטנים יותר, תהיה נטייה לרכז את הכל תחת פונקציה אחת. במקרה זה, תידרש מאיש הבדיקות גם ידע באבטחת איכות או ההפך, שאיש אבטחת איכות יהיה גורם שמכיר היטב את עולם הבדיקות ויכול לשמש גם כמנהל הבדיקות.
החזון הוא מערכת ניהול איכות כוללת, אשר מכילה את שני הנושאים, כמתואר באיור מס' 4. ועל כך, במאמר הבא: מערכות לניהול איכות - Quality Management Systems .
QA4
איור מס' 4: מערכת ניהול איכות כוללת בארגון
 
נכתב ע"י:
אשר יובל, יו"ר/ מנכ"ל חברת מתודה
לדף פרטי מתודה ב RFIgo
לראש העמוד
מיוחד ללקוחות RFIgo arrow_white_left (1K) פגישת יעוץ חינם בנושא ניהול ובקרת פרויקטים לפרטים מוצר arrow_white_left (1K) הפתרון לניהול פרויקטים ארגוניים לפרטים