בדיקות מערכת

בדיקות מערכת

בדיקות מערכת

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

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

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

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

מבוא והסבר כללי

הגדרה כללית

בדיקות (Testing) הן מכלול תהליכים, שיטות, פעילויות וכלים המלווים את פיתוח המערכות והמוצרים לאורך מחזור החיים מתוך כוונה לבצע אימות והוכחת תקפות V&V (Verification & Validation) להתאמת התוצרים לדרישות הלקוח, למפרטים הטכניים, לתקנים ולנהלים מחייבים.

בדיקות ואיכות

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

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

 

 ·         האם אנו בונים את המוצר הנכון ?

 ·         האם אנו בונים נכון את המוצר ?

 

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

שלבי הבדיקות

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

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

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

 

 ·         תכנון הבדיקות

 ·         התארגנות לביצוע

 ·         ביצוע הבדיקות

 ·         סיכום הבדיקות

תכנון הבדיקות

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

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

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

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

פרויקט המפותח ע"י גורם חיצוני – מנהל הפרויקט יכתוב מסמך בדיקות ראשוני ועל פיו יבקר את מסמך תכנון הבדיקות של החברה החיצונית עפ"י עקרונות מסמך תכנית בדיקות - STP

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

יש לבנות את תיקיית הבדיקות עפ"י הנדרש בתיקיית הבדיקות.

 

התארגנות לביצוע

מינוי צוותי בדיקות והדרכת צוותים

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

 

#

תפקיד

תחומי אחריות

1.        

מנהל סביבת הבדיקות

אחריות כוללת על סביבת הבדיקות המערכתית.

ייזום הקמת סביבת הבדיקות, ריכוז צרכי ציוד, ריכוז היקף בדיקות נדרש, תכנון לו"ז סביבת הבדיקות.

ניהול הבדיקות.

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

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

סיוע בקבלת החלטות (האם לבצע סבב נוסף, האם ניתן לשחרר את המערכת, היקף בדיקות וכו').

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

ניהול ביצוע סקר סיכום בדיקות.

הדרכה והכשרת אנשי מרכז הבדיקות.

2.        

מנהל הפרויקט

הספקת תסריטים, תרחישים ונתוני בדיקה.

הגדרת סביבת הבדיקות הנדרשת, במיוחד מול גורמי התשתית המתאימים.

ביצוע סקר מוכנות לבדיקות (ראה בדיקות שפיות).

סיוע ומתן תמיכה אפליקטיבית לקראת ובמהלך ביצוע הבדיקות.

אחריות על הבדיקות ברמת Unit Test והבאת המערכת לבשלות ומוכנות מרבית לקראת שלב הבדיקות.

ניהול תצורה של סביבות הפיתוח.

העברה מסודרת של רכיבים לסביבת הבדיקות.

טיפול בתקלות ושמירה על הקפאת תצורה.

הגדרת היקף הבדיקות הנדרש, בשיתוף עם צוות הבדיקות הענפי.

העברת נהלי תפעול המערכת בטרם הקמת סביבת הבדיקות.

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

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

מינוי POC במערכות המתממשקות הרלוונטיות אם מדובר במערכת מתממשקת, ולא עיקרית.

פיתוח הכלים האוטומטים והמדמים - בהתאם לצורך.

תמיכה טכנית שוטפת.

3.        

רש"צ בדיקות

בטרם כניסה לסביבת הבדיקות:

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

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

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

במהלך סביבת הבדיקות:

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

הוצאה, מדי תקופה שיוחלט עליה (יום/שבוע), של דו"ח התקדמות תקופתי.

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

כתיבת מסמך סיכום בדיקות.

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

4.        

צוות בודקים - אפליקציה ושו"ב

ביצוע בדיקות על-פי סוגי הבדיקות למערכות הנבדקות.

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

ניהול טכני - הקמה ותחזוקת שדות הבדיקה (ציוד, תוכנות וכו').

עדכון, שיפור ושדרוג תהליכים וכלי הבדיקה.

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

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

5.        

צוות תשתיות

הקמה ותחזוקת תשתית סביבת הבדיקות.

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

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

סיוע ומתן תמיכה טכנית לקראת ובמהלך ביצוע הבדיקות.

6.        

צוות בדיקות חומרה

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

ביצוע בדיקות קבלה לפרויקטי החומרה.

7.        

צוות System

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

אחראי להקמת המערכת.

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

ביצוע התקנות מ"ה על שרתים.

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

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

טיפול בתקלות מול חברה אזרחית.

עדכון רש"צ בדיקות ומנהל סביבת הבדיקות בכל תקלה בסביבת סביבת הבדיקות.

8.        

צוות DBA

סיוע בתכנון סביבת הבדיקות בהיבטי בסיסי הנתונים, קונפיגורציה.

התקנת שרתי DB ומימוש התצורה הנבחרת.

ביצוע בדיקת שילוב של חומרה / תוכנה חדשה.

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

טעינת נתונים עבור סביבת הבדיקות.

ביצוע בדיקות העומסים וניתוחם, טיוב עבודת ה- DB.

9.        

צוות תקשורת

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

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

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

ביצוע בדיקות קבלה לפרויקטי תקשורת.

ביצוע בדיקות תקשורת לפרויקטים אשר שילבו בתוכם את רכיבי התקשורת השונים.

10.    

נציג הלקוחות

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

הנחיית בודקים על עבודת הלקוח.

השתתפות בביצוע בדיקות בסביבת הבדיקות, על פי תסריטיו, ולפי ראייתו. (הלקוח ישולב אחרי הרצה של סט בדיקות ע"י צוות הבדיקות הענפי.)

השתתפות בדיון סטאטוס תקופתי והצגת התקלות אשר אותרו ע"י צוות הבדיקות שלו.

11.    

צוות לוגיסטיקה

ניהול הציוד.

ניהול הרכש.

אחריות לוגיסטית כללית.

12.    

מנהל איכות

ביצוע אבטחת איכות לכלל פעילויות סביבת הבדיקות, בדיקות שילובים, וכו'.

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

13.    

מומחים חיצוניים לצוות

כתיבת הבדיקות הייחודיות הרלוונטיות.

ביצוע הבדיקות בסביבת הבדיקות והפעלת כלי הבדיקות.

ליווי ותמיכה של הצוות הבודק והמפתח.

 

 

הכנת סביבת הבדיקות

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

התקנות

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

תרחישים ותסריטים

כתיבה, עיבוי ועדכון מפרטי הבדיקות (מפרט / תסריטי בדיקות - STD) הכוללים כתיבת תרחיש (Scenario) ותסריט Script)). הבדיקה והכנת נתוני בדיקה (Test Data).

ביצוע הבדיקות

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

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

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

 

 ·         להמשיך את הבדיקות

 ·         לתקן מיידית תקלות מסוימות

 ·         עצירת הבדיקות

סיכום הבדיקות

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

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

מסמך סיכום הבדיקות ייכתב ע"י הגוף שביצע את הבדיקות - צוות פנימי או חברת בדיקות חיצונית.

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

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

שלב האפיון

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

מקובל לתכנן לשלב הבדיקות לפחות 15% - 20% מזמן ועלות הפיתוח.

בשלב האפיון מתגבשת תכנית הבדיקות למערכת. התכנון הראשוני של הבדיקות יבוא לביטוי במסמך האפיון ברכיב 4.8.1 תכנית הבדיקות (STP).

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

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

בשלב האפיון נכתב חלקו הראשון של מסמך הבדיקות (STD) המפרט את רשימת התרחישים (Scenarios) שתכסה את דרישות המערכת. עבור כל תרחיש תוגדר סביבת הבדיקות ותאור כללי של תרחיש הבדיקה. המסמך יכלול טבלת עקיבות ככלי בקרה לכיסוי הדרישות ע"י תרחישי הבדיקות. מסמך זה יוצג ויאושר בסקר האפיון הראשוני PDR (Preliminary design review). להרחבה ראה קיט סקרים –Reviews בכרך איכות.

שלב הבקשה להצעות RFP

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

RFP לבחירת חברת בדיקות (אופציונאלי)- בפרויקט בו הוחלט לבצע את הבדיקות בסיוע חברת בדיקות, ייכתב RFP תוך הסתמכות על נהלי הארגון או נוהל מפת"ח. לפירוט והרחבה ראה פרק בחירת גורם לביצוע הבדיקות להלן.

להלן דגשים להכנת ה- RFP:

 

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

 ·         יש לפרט את מבחני הקבלה לכל תת מערכת ולמערכת בכללותה. יש להיערך לביצוע מבחני הקבלה בהיבטי לו"ז, כ"א, תקציב, אתר בדיקות, הגדרת תכולת בדיקות וכד'.

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

 ·         יש לתכנן זמן למקרה שתדרש תוספת סבבים עד ל"הכשרת המערכת" ע"י הלקוח.

 ·         יש להתייחס לסביבת בדיקות הקבלה, מיקומה, האחריות על הקמתה ותיקצובה.

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

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

 ·         איכות מפרטי הבדיקות תיבדק לפי הסטנדרטים והעקרונות שנקבעו ב-STP.

שלב העיצוב והבניה

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

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

בשלב העיצוב ובמהלך הבניה יורחב מסמך הבדיקות STD. כל תרחיש יהפוך לתסריט (Script) אחד או יותר על מנת לכסות את כל (או את מירב) האפשרויות והמסלולים האפשריים במסגרת התרחיש. התסריטים יכללו הוראות מדויקות לבודק, לרבות נתוני הפתיחה (תכולת בסיסי הנתונים והקבצים), הסטנדרטים שנקבעו וצעדי הבדיקה שיכילו את נתוני הקלט והתוצאה הצפויה לכל צעד. המסמך יכלול טבלת עקיבות ככלי בקרה לכיסוי הדרישות בין האפיון לעיצוב ובין העיצוב לתרחישי הבדיקות. מסמך זה יוצג בסקר עיצוב קריטי CDR(Critical Design Review) ויאושר בסקר מוכנות לבדיקות מערכת (TRR). להרחבה ראה קיט סקרים – Reviews בכרך איכות. באם הוכנסו שינויים ושיפורים שאושרו ב- CDR יש לעדכן בהתאם גם את מסמך הבדיקות וטבלת העקיבות.

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

בדיקות יחידה (Unit Test) – במהלך בניית המערכת יבצע צוות הפרויקט בדיקות יחידה ויתעד אותן. תקלות שתאותרנה במהלך הבדיקה תרשמנה ותיבדקנה לאחר תיקונן. עומק תיעוד בדיקות היחידה יקבע ברמת הארגון ויעוגן בתוכנית הבדיקות. ביצוע בדיקות היחידה יתבצע בהתאם לתכנון מוקדם, כאשר בסיומן יוכן מסמך סיכום בדיקות.

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

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

הקמת צוות בדיקות - ימונה צוות בדיקות ותבוצע הדרכה והנחייה לצוות הבודקים.

סקר מוכנות לבדיקות TRR (Test Readiness Review) – יערך סקר לאישור מסמך בדיקות המערכת, תקינות סביבת הבדיקות, מוכנות צוות הבדיקה ונהלי הבדיקה וסקירת מידת מוכנות התוכנה לבדיקות. להרחבה, ראה קיט סקרים – Reviews בכרך איכות.

שלב בדיקות המערכת

בדיקות המערכת (System Test) הן למעשה בדיקה המבוצעת ע"י המפתח ומכונות לעיתים FAT (Factory Acceptance Test). הספק החיצוני או מנהל הפרויקט (בפיתוח פנימי) יבצע מספר סבבי בדיקות לא פורמאליות על מנת לוודא את מוכנות המערכת לקראת הבדיקות הפורמאליות בנוכחות נציגי המשתמשים. במהלך הבדיקות יורצו התרחישים שהוגדרו במסמך הבדיקות, ייבדקו היעדים והמדדים שהוגדרו לסבבי הבדיקות תוך תיעוד מהלך הבדיקות, התוצאות והתקלות במסמך הבדיקות. בין סבב אחד לשני יתקן צוות הפרויקט את התקלות ותותקן מהדורה עדכנית לבדיקה חוזרת בסביבת הבדיקות.

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

סקר סיכום בדיקות – בתום סבבי הבדיקות יערך סקר סיכום בדיקות STR (Software Test Review), אשר במהלכו יוצג מסמך סיכום הבדיקות.

מסמך סיכום הבדיקות יתאר את מהלך הבדיקות, יסכם את הסבבים שבוצעו והתרחישים שלא הורצו, יציג חריגות שבוצעו מן התסריטים ויפרט את רשימת התקלות הפתוחות. בסיכום הסקר תיבחן מוכנות המערכת לבדיקות קבלה (ATP) ותסוכם תכנית להשלמת המשימות הקריטיות שאי השלמתן תדחה את מועד תחילת ה ATP. להרחבה ראה קיט סקרים - Reviews בכרך איכות.

בדיקת שילוב מערכתי (Integration Test) - בדיקות הכוללים מרכיבים מערכתיים רוחביים תוך שילוב בין מרכיבים ותת פרויקטים שבתכולת הפרויקט. הבדיקות יבוצעו במסגרת סביבת הבדיקות המערכתית ובאחריות גורם שימונה ייעודית לניהול סביבה זו. ראה פרק סביבת הבדיקות.

שלב התקנה והרצה

בדיקות התקנה – לאחר התקנת המערכת בסביבת בדיקות הקבלה (ATP) יתבצעו בדיקות התקנה (חומרה ותוכנה) ובדיקות רגרסיה ושפיות על מנת לוודא שהמערכת מוכנה לתחילת עבודת המשתמשים או להרצה ניסיונית / מבצעית. סיכום מבדקי ההתקנה יתועד בנספח לתכנית ההתקנה. ראה קיט התקנה והרצה בכרך זה.

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

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

בדיקות תפעוליות – בשלב זה מתבצעות בדיקות תפעוליות בהן בוחנים את תפיסות ההפעלה והתפעול.

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

שלב התפעול והתחזוקה

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

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

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

מסמך הבדיקות (STD) יעודכן ויכיל תרחישים ותסריטים מעודכנים לפי הדרישות החדשות. אלה ישולבו עם תסריטים של תהליכים התלויים בממשקים והמשפיעים או מושפעים מתסריטים אלו.

סוגי בדיקות בפרויקטים

קטגוריות של בדיקות

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

בדיקות חומרה - פעולות ותהליכים שמטרתם לוודא שרכיבי החומרה עומדים בדרישות ומתפקדים כהלכה.

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

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

רמות בדיקה וסוגי בדיקות

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

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

רמות הבדיקה

 ·         בדיקות הוכחת יכולות (POC – Proof of Concept)

 ·         בדיקת יחידה (Unit Test)

 ·         בדיקת אינטגרציה ושילוב – פיתוח (Integration Test)

 ·         בדיקת שילוב מערכתי (Integration Test)

 ·         בדיקות מערכת (System Test)

 ·         בדיקות מסירה (FAT)

 ·         בדיקת התקנה והקמה (Test Installation)

 ·         בדיקות קבלה (Acceptance Test Procedure - ATP)

 ·         בדיקת מהדורה

 ·         בדיקת תפעוליות

סוגי בדיקות

(הסידור הינו לפי א-ב)

 

 ·         בדיקות אבטחת מידע - חדירה

 ·         בדיקת אמינות – איכות נתונים

 ·         בדיקות ביצועים (Performance Test)

 ·         בדיקות גיבוי - שיחזור

 ·         בדיקת הסבות נתונים

 ·         בדיקת כשל והתאוששות

 ·         בדיקת ממשק משתמש – GUI

 ·         בדיקת ממשקים

 ·         בדיקות מבוססות סיכון – Risk Based Testing

 ·         סקר קוד (Code Review)

 ·         בדיקת עומסים (Stress/Load Test)

 ·         בדיקת עיבודי אצווה (Batch)

 ·         בדיקת פונקציונאליות (Functionality Test)

 ·         בדיקת רגרסיה ((Regression Test

 ·         בדיקת שימושיות (Usability Test)

 ·         בדיקת שפיות (Sanity Check)

 ·         בדיקת שרידות

 ·         בדיקת תיקון תקלה או שינוי בודד

פירוט הבדיקות

סוגי ורמות הבדיקות המפורטים בסעיף זה ממוינים עפ"י הא"ב

בדיקות אבטחת מידע – חדירה

 

מטרה:

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

פירוט:

המענה לאיומי אבטחת מידע חולק לשבעה תחומים עיקריים:

·         הזדהות

·         הרשאות

·         בקרה וחיווי

·         אבטחת תקשורת

·         אבטחת תוכנה

·         שרידות והתאוששות

·         Audit trail

מאפייני הבדיקות בנושא אבטחת מידע הינם:

·         השפעת אבטחת המידע על הפונקציונאליות (במסגרת בדיקות הפונקציונאליות)

·         השפעת רכיבי אבטחת המידע על ביצועי המערכת.

·         מבחני חדירה, כגון ניסיונות פריצה דרך "חורים" שייווצרו בחיבור בין מערכות שונות.

 

 

בדיקת אינטגרציה ושילוב – פיתוח (Integration Test)

מטרה:

בדיקת תקינות של הפעלה משולבת של מספר מודולים/תת-מערכות.

פירוט:

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

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

הבדיקות מבוצעות אל מול עיצוב המערכת. אלו הן בדיקות קופסה לבנה (בדיקות המתוכננות ומבוצעות מתוך הבנה של המבנה הפנימי של המערכת).

השלב הבא:

הצלחה מהווה תנאי לתחילת בדיקות מערכת

 

 

בדיקת אמינות – איכות נתונים

 

מטרה:

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

פירוט:

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

 

 

בדיקות ביצועים (Performance Test)

 

מטרה:

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

פירוט:

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

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

קישורים

ראה גם בדיקת עומסים (Stress/Load Test)

 

 

בדיקות גיבוי – שיחזור

 

מטרה:

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

פירוט:

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

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

·         ביצוע גיבוי למערכת.

·         הקמת מערכת חדשה בסביבה חדשה, מתוך הגיבוי (ביצוע שחזור).

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

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

 

 

בדיקת הסבות נתונים

 

מטרה:

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

פירוט:

בדיקת הנתונים המוסבים תתבצע במספר רמות:

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

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

·         ברמת סיכום: סיכום הרשומות / המוצרים המוסבים בחתכים שונים ועל בסיס Check Sum.

·         ברמת שאילתות ודוחות מדגמיים: השוואת ישן מול חדש.

 

 

בדיקות הוכחת יכולות (POC – Proof of Concept)

 

מטרה:

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

פירוט:

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

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

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

השלב הבא:

הצלחה מהווה תנאי לתחילת שלב האפיון המפורט או הבקשה להצעות

 

 

בדיקת התקנה והקמה (Test Installation)

 

מטרה:

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

פירוט:

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

קישורים:

בכרך זה

 

 

בדיקת יחידה (Unit Test)

 

מטרה:

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

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

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

פירוט:

תכולות הבדיקה:

·         תאימות לסטנדרטים.

·         עיצוב של מסכים ושדות.

·         ניתובים, פקדים, Icons.

·         ידידותיות, Self-Explanatory.

·         בדיקות של מצבי עדכון.

·         פונקציונאליות בסיסית ברמת המודול הבודד (אל מול ההגדרות בעיצוב).

דרך הבדיקה:

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

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

קישורים:

ראה קיט "עיצוב ובניה " בכרך זה

השלב הבא:

הצלחה מהווה תנאי לתחילת בדיקות אינטגרציה

 

 

 

בדיקת כשל והתאוששות

 

מטרה:

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

פירוט:

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

סוגי כשלים אופייניים:

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

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

·         התאוששות שרת - נפילה של עמדות קצה בעקבות נפילת השרת, נפילת שרתים תלויים אחרים, נפילת התקשורת.

·         בדיקת גיבויים - האם הגיבויים משחזרים את המידע באופן מלא?

 

בדיקת מהדורה

 

מטרה:

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

פירוט:

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

השלב הבא

התקנת מהדורה ועדכון בדיקות תפעוליות

 

 

בדיקת ממשק משתמש – GUI

 

מטרה:

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

פירוט:

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

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

 

 

בדיקת ממשקים

מטרה:

בדיקת הממשקים מול מערכות משיקות.

פירוט:

בדיקה מקצה לקצה מול המערכת השנייה המבצעית. הבדיקה כוללת 3 רמות שונות:

·         בדיקה טכנית שהממשק עובד תקין

·          בדיקה שהמידע מגיע למערכת השנייה (לפי מה שהוגדר באפיון)

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

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

ניתן להשתמש בבדיקה של כמות מסכים / דוחות, ואם הסה"כ לא תואם, אז להיכנס לבדיקה יותר מדוקדקת כדי לאתר את הבעיה.

 

 

 

בדיקות מערכת (System Test)

 

מטרה:

לוודא את תאימות המערכת לאפיון ולוודא את פעילותה התקינה של המערכת.

פירוט:

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

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

בנוסף לבדיקות שתוארו לעיל יש לתת את הדעת על השאלות הבאות:

·         האם המערכת השיגה את המטרות והיעדים שהוגדרו לה באפיון.

·         האם המערכת פתרה את הבעיות שהיה עליה לפתור

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

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

השלב הבא:

הצלחה מהווה תנאי לתחילת בדיקות ATP / שילוב מערכתי

 

 

בדיקות מסירה (FAT)

מטרה:

בדיקות מסירה של מערכת המפותחת ע"י גורם חיצוני– Factory Acceptance Test. זוהי הבדיקה הסופית ואחרונה לפני בדיקות הקבלה אשר מבוצעות ע"י הלקוח.

פירוט:

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

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

·         בדיקות MMI ותפעול פיזי, בדיקות וניסויי הנדסת אנוש בהתאם לדרישות מהמרכיב,

·         בדיקות System, הקמה, הצטרפות והתאוששות,

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

·         בדיקות תקשורת ובטיחות,

·         בדיקות ביצועים ועומסים,

·         בדיקות התקנה לגרסה המשוחררת.

השלב הבא:

הצלחה מהווה תנאי לתחילת בדיקות קבלה ע"י הלקוח

 

 

בדיקות מבוססות סיכון – Risk Based Testing

מטרה:

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

פירוט:

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

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

 

 

 

בדיקת עומסים (Stress/Load Test)

 

מטרה:

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

פירוט:

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

·         בדיקת ביצועי המערכת תחת עומס מוגדר,

·         בדיקת גבולות עומס של המערכת (Sizing),

·         ניטור פעולות בעייתיות,

·         בדיקת זמני כשל,

·         בדיקת זמני התאוששות.

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

רמות העומסים:

·         בדיקות עומסים פונקציונאליות - בדיקת יכולת המערכת לעמוד בשימוש מקבילי מועט ללא תקלות הנובעות מהשימוש המקבילי. מומלץ לבצע בדיקה זו גם כחלק מה – Unit Test.

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

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

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

קישורים

ראה גם בדיקות ביצועים (Performance

 

בדיקת עיבודי אצווה (Batch)

 

מטרה:

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

פירוט:

ניתן לבדוק עיבודי אצווה בשתי שיטות:

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

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

 

 

 

בדיקת פונקציונאליות (Functionality Test)

 

מטרה:

בדיקת תפקוד המערכת עפ"י המוגדר במסמכי האפיון והדרישות. בדיקת תקינות תהליכים אפליקטיביים ותשתיתיים, ע"י קישור והתאמה מערכתית בין נתונים הקשורים או נובעים מתהליך לוגי מסוים (Integrity).

פירוט:

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

עוברים על מגוון הפונקציות שקיימות בכל רכיב תוך ידיעה מה התוצאה הצפויה – (expected result) וציון האם הפונקציה עברה את הבדיקה (pass) או לחלופין נכשלה בבדיקה (fail).

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

 

 

בדיקות קבלה (Acceptance Test Procedure - ATP)

 

מטרה:

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

מטרתן היא לוודא התאמת המערכת לצרכים (Validation) ולדרישות שהוגדרו במשימת הפרויקט.

פירוט:

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

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

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

מומלץ לשקול ביצוע סבב בדיקות מקדים לפני בדיקות הקבלה, על בסיס תרחישי בדיקות הקבלה (ATP), על מנת לעלות על תקלות נוספות לפני שנבדק ע"י הלקוח.

השלב הבא:

הצלחה מהווה תנאי לתחילת שלב קליטה והטמעה

 

בדיקת רגרסיה ((Regression Test

 

מטרה:

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

פירוט:

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

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

 

 

בדיקת שילוב מערכתי (Integration Test)

 

מטרה:

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

פירוט:

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

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

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

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

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

השלב הבא:

הצלחה מהווה תנאי לתחילת בדיקות קבלה

 

 

בדיקת שימושיות (Usability Test)

 

מטרה:

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

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

פירוט:

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

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

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

 

 

 

בדיקת שרידות

 

מטרה:

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

פירוט:

הסימולציה לתנאים אלו תתבצע תחת עומס שיא ועומס שיא מיוחד ובשני מצבים:

·         הורדה מסודרת של תת מערכת או אפליקציה אחת או יותר.

·         הדמיה של הורדה בלתי מסודרת של תת מערכת, אחת או יותר המזינות תת מערכות אלה

יש לבדוק נושאים כמו:

·         נפילה של בסיס הנתונים של המערכת

·         נפילת כלי קישוריות

·         נפילת מתח לתת המערכות המשולבות במערכת

·         השפעת אפשרית של קריסת רשת התקשורת, מקומית או כללית, על אפשרויות להצגת נתוני התפעול

 

 

 

בדיקת שפיות (Sanity Check)

 

מטרה/ הגדרה:

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

פירוט:

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

לעיתים נקראות בדיקות אילו גם בשם Smoke Tests.

 

 

 

בדיקת תיקון תקלה או שינוי בודד

 

מטרה:

סקר קוד, בדיקות יחידה ((Unit Test ובדיקות רגרסיה יבוצעו על כל תיקון תקלה או שינוי שהתבקש והוחלט לממשו.

פירוט:

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

 

 

בדיקת תפעוליות

 

מטרה:

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

פירוט:

בבדיקות אלה מוגדר סט בדיקות הכולל התייחסויות ל:

·         גיבויים - מה יגובה ובאיזה תדירות

·         תחום טכני - העלאת מערכת, הורדת מערכת, טיפול בתקלות, דרכי התמודדות

·         דילוג בין מתקנים - דילוג בתוך מתקן ובין מתקנים

·         ניטור - קישור המערכת לכלי הניטור והבקרה הכלליים

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

בבדיקות אלו בודקים שהנהלים עובדים ועפ"י הלו"ז שהוגדר ב- SLA והצוות כשיר.

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

 

 

 

סקר קוד (Code Review)

מטרה:

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

פירוט:

ביצוע הרצה "יבשה" של התכנית על מנת לוודא:

·         לוגיקה הגיונית של ריצת התכנית

·         סיום תקין

·         טיפול בשגויים

·         הימנעות מ - Deadlocks

הבדיקה מתבצעת כ- Peer Review (בדיקה בצוותי הפיתוח בינם לבין עצמם)

 

 

 

טכניקות לבדיקות

בדיקות קופסה לבנה

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

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

בדיקות קופסה שחורה

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

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

קבוצות שקולות

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

מקרי קצה

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

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

בדיקות חיוביות

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

בדיקות שליליות

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

בדיקות בסוגי פרויקטים שונים

בדיקות בפרויקט בפיתוח פנימי

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

 

 ·         בדיקות עצמיות באמצעות צוות הפרויקט

 ·         בדיקות באמצעות מרכז בדיקות

 ·         הפעלת ספק חיצוני באמצעות תהליך בקשה להצעות

 

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

 

בדיקות במהדורת המשך

מערכת בנויה ממספר מהדורות (Versions) וגרסאות (Releases). מהדורה היא שינוי משמעותי, בעוד שגרסה היא שינוי מקומי. כל מהדורה נחשבת למערכת עצמאית.

כל בנייה של מהדורה חדשה/המשך מחייבת גם הרצה מעמיקה של בדיקת רגרסיה ((Regression Test, בנוסף לביצוע תהליך שגרתי של בדיקות לרכיב שפותח או נוסף.

בדיקות בפרויקט נוהל מזורז

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

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

בדיקות פרויקט חוצה ארגון

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

 

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

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

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

 ·         שיתוף גורמים רבים (לקוחות ויחידות ארגוניות) בתהליך אישור התרחישים וליווי הבדיקות.

בדיקות בפרויקט המפותח ע"י ספק חיצוני

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

 

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

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

 ·         דגש על פעילויות לפיקוח ובקרה על איכות התוצר המפותח:

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

 ·         שיתוף נציג הפרויקט במהלך הבדיקות המבוצעות בחצר הספק ובדגש על בדיקות מסירה (FAT).

 ·         בדיקות המוצר בסביבת בדיקות בארגון

בדיקות במוצרי תשתית

מוצר תשתית עתיד לשרת קשת רחבה של פרויקטים ומערכות לאורך תקופות זמן ארוכות. עובדה זו מדגישה את הצורך במוצר אמין שיעמוד בביצועים וברמות השרות (SLA) שהוגדרו לו.

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

בבדיקות מוצרי תשתית יש לתת דגש לנושאים הבאים:

 

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

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

 ·         שיתוף גורמים רבים (לקוחות ויחידות ארגוניות) בתהליך אישור התרחישים וליווי הבדיקות.

 

בדיקות של מוצר מדף

מוצר מדף הינו מוצר שניתן לשינוי קל או שאינו ניתן לשינוי בכלל. מוצר זה אמין בד"כ וברוב המקרים הותקן ונבדק כבר בחברות שונות.

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

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

הבדיקות הרלוונטיות במקרה זה הן:

 

 ·         בדיקות קבלה - לצורך וידוא שהמוצר מתאים (בדיקה ויזואלית ופונקציונאלית)

 ·         בדיקת ביצועים - במקרה שנדרשת רמת ביצועיות גבוהה

 ·         בדיקת ממשק משתמש - לצורך בדיקת נוחות השימוש במוצר

 ·         בדיקת ממשקים - למערכות הרלוונטיות

 ·         בדיקת עומסים - במקרה שנדרשת עמידה בעומסים גבוהים

 ·         בדיקת שימושיות

 

סביבת הבדיקות

סוגי סביבה

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

 

 ·         סביבה פרויקטאלית – בו תבוצענה בעיקר בדיקות פונקציונאליות של פרויקט מסוים.

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

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

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

 

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

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

ביצוע סוגי בדיקות בסביבות שונות

להלן פירוט סוג הבדיקה המתאימה לכל סביבת בדיקות:

 

סביבת הבדיקות

סוג בדיקה

פיתוח (Development)

בדיקות יחידה, בדיקות שילוב

ניסוי (Test)

בדיקות מערכת, בדיקות קבלה, בדיקות התקנה, בדיקות רגרסיה

ייצור (Production)

בדיקות קבלה, בדיקות התקנה, בדיקות רגרסיה

 

 

הנחיות להקמה וכניסה לסביבת בדיקות

כללי

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

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

סביבת הבדיקות

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

תשתית וטכנולוגיה

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

 

סוג

פירוט

תחנות עבודה

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

בסיס נתונים

ציין את סוג בסיס הנתונים הנדרש לבדיקות.

ציוד תקשורת

ציין איזה ציוד תקשורת נדרש לסביבת הבדיקות, כמויות, ספקים שיספקו את הציוד (במידת הצורך) וכד'.

כלים לניהול הבדיקות

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

כלים לביצוע הבדיקות

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

ציוד נוסף

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

אמצעים להדמיית הסביבה האמתית

במידה ויעשה שימוש באמצעי הדמיה לסביבה האמתית יש לציין אילו אמצעים כגון: סימולטורים,Debuggers, Databases Manager, Generators וכד'.

תשתית

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

ציוד/תוכנות לסביבת העבודה

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

 

 

גרסת חומרה

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

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

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

גרסת תוכנה

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

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

גרסת נתונים

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

 

סוג

פירוט

קבצי נתונים

ציין איזה קבצי נתונים (או חלקי קבצים) יש להכין לצורך ביצוע הבדיקות.

טבלאות

ציין אילו טבלאות נדרשות ואילו נתונים צריכות להכיל טבלאות אלו.

נתונים נוספים

במידה ונדרש Data נוסף לצורך ביצוע הבדיקות, ציין זאת, למשל: מספרי לקוחות, ת"ז וכד'.

 

 

הגדרת משתמשים

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

רשימת תיוג להכנת סביבת בדיקות

 

סוג

פירוט

טכנולוגיה

תחנות עבודה

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

בסיס נתונים

ציין את סוג בסיס הנתונים הנדרש לבדיקות.

ציוד תקשורת

ציין את ציוד התקשורת הנדרש לסביבת הבדיקות, כמויות, ספקים שיספקו את הציוד (במידת הצורך) וכו'.

הכנות נתונים

קבצי נתונים

ציין איזה קבצי נתונים (או חלקי קבצים) יש להכין לצורך ביצוע הבדיקות.

טבלאות

ציין אילו טבלאות נדרשות ואילו נתונים צריכות להכיל טבלאות אלו.

נתונים נוספים

במידה ונדרש Data נוסף לצורך ביצוע הבדיקות, ציין זאת, למשל: מספרי לקוחות, ת"ז וכו'.

אמצעים לביצוע הבדיקה

כלים אוטומטיים לביצוע הבדיקות

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

כלים לניהול הבדיקות

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

ציוד נוסף

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

אמצעים להדמיית הסביבה האמיתית

במידה ויעשה שימוש באמצעי הדמיה לסביבה האמיתית, יש לציין אילו אמצעים, כגון: סימולאטורים, Debuggers,Databases Manager, Generators וכו', נדרשים.

אמצעים לסביבת העבודה – אדמיניסטרציה

ציוד/תוכנות לסביבת העבודה

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

הגדרות

Users – פרטי המשתמשים.

הגדרת בעלי תפקידים

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

תשתית

תקשורת חיצונית

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

תשתית

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

 

 

מהלך סביבת הבדיקה

הפעלה ממוכנת של סביבת הבדיקות

ראה פרק שימוש בכלים בבדיקות להלן.

שלבים מרכזיים טרם תחילת הבדיקות

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

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

בדיקות קבלה ובדיקות שפיות - בדיקות קבלה לסביבה בנושאי פונקציונליות (רגרסיה), שילוב אבטחת מידע, שילוב שו"ב, תקשורת וממשקים.

עיקרי הבדיקות

עיקר הפעילות בסביבת הבדיקות הינה התמקדות בבדיקת תהליכים מקצה לקצה (End to End Test), ביצוע בדיקות פונקציונאליות ואינטגרציה מול מערכות משיקות וממשקים, בדיקת עומסים ויציבות על רשתות התקשורת, שחזור אפליקטיבי ו- DB, ניסוי השבתה, בדיקות שרידות של המערכת, בדיקות אימות של הניטור, בדיקת השפעת שימוש בתוכנות חדשות על המערכות, בדיקות עומסים, יציבות ושילוב בדיקות המתבצעות ע"י הלקוח (בדיקות קבלה).

פעולות לסיכום סביבת הבדיקות

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

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

שימוש בכלים בבדיקות

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

כלי ניהול הבדיקות

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

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

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

כלי ביצוע בדיקות

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

צב"ד (ציוד בדיקה) - ציוד שניתן להפעילו בכל נקודת זמן לשם בדיקת שלמות המערכת ותפקודה התקין.

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

כלי בדיקה לביצוע בדיקות עומסים וביצועים.

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

 

 ·         בדיקת ביצועי המערכת תחת עומס מוגדר,

 ·         בדיקת גבולות עומס של המערכת (Sizing),

 ·         ניטור פעולות בעייתיות,

 ·         בדיקת זמני כשל,

 ·         בדיקת זמני התאוששות.

 

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

 

כללים מנחים

משולש ברמודה של הבדיקות

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

איכות נדרשת לתוצר > זמן ולוח זמנים > עלות ומשאבים

 

H_Testing_Img04_20080324

 

 ·         מהי רמת האיכות הנדרשת ?

 ·         כמה בודקים ?

 ·         מתי להפסיק את הבדיקות ?

הנחות יסוד

 ·         נדרשת בדיקה לכל תוצר

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

 ·         יש להגדיר את תכולת הבדיקות וקריטריונים לכניסה ויציאה מהבדיקות באופן ברור במסמך ה- STP

 ·         תוצר הבדיקות - מערכת בדוקה, עובדת, מלווה בתיעוד נדרש

משאבים

כללי אצבע

 ·        מינימום: 20% מהמשאבים שהושקעו בשלב הפיתוח.

 ·         מקסימום: שליש מהמשאבים שהושקעו בשלב הפיתוח.

 ·         כלל אצבע נוסף: 12%-15% מעלות הפיתוח.

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

 ·         יש "סחף זוחל" במשאבים לאורך הפרויקט ויש "לעמוד על המשמר".

לוחות זמנים

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

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

התחלה/סיום הבדיקות

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

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

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

 

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

 ·         שיטת הקצב – הפסקה שרירותית של הבדיקות

 ·         שיטת 20-80 (עקרון פארטו)

 ·         בדיקות סטטיסטיות

 ·         קביעת קריטריונים מדידים

 

קריטריונים אילו מוגדרים במסמך תכנון הבדיקות - STP.

להלן דוגמא לקריטריונים:

 

שם הקריטריון

פרוט

תחילת בדיקות מערכת

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

בשלות המערכת

99% מהנושאים שנבדקו במערכת עובדים כראוי ו- 1% מהתקלות שנותרו הנן ברמת חומרה נמוכה.

עצירת בדיקות עומסים

80% מבין התהליכים/הנושאים שתוכננו להיבדק עברו ללא תקלות בבדיקות העומס.

מעבר לבדיקות קבלה

99% מהנושאים שנבדקו בבדיקות המערכת (system test) עובדים כראוי ו- 1% מהתקלות שנותרו הנן ברמת חומרה נמוכה – לפי החלטת גוף המשתמשים

בדיקות קבלה

99% מהדרישות של המשתמשים יושמו במערכת.

עפ"י תכנית דגימה הנכתבת עפ"י אנשי אבטחת האיכות.

מעבר מלא לסביבת ייצור

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

הפסקת סבב הבדיקות

במהלך סבב הבדיקות התגלו 10 תקלות ברמה בינונית ומעלה.

במהלך סבב הבדיקות התגלו 2 תקלות משביתות.

תאריך יעד

תאריך היעד הגיע וצריך למסור את המערכת ללא תלות בסטאטוס הבדיקות

תקציב

התקציב נגמר

כמות תקלות ליציאה ממחזור/ סבב בדיקות

0 תקלות ברמת חומרה גבוהה, עד 3 תקלות ברמת חומרה בינונית

 

 

החלטה בתום הבדיקות

החלופות להמשך הן:

 

 ·         מעבר לשלב הבא - קבלה של התוצר כמו שהוא (as-is)

 ·         מעבר לשלב הבא - קבלה של התוצר וביצוע תיקונים תוך כדי תפעול שוטף

 ·         מעבר לשלב הבא רק לאחר ביצוע התיקונים, ללא בדיקה חוזרת

 ·         מעבר לשלב הבא רק לאחר ביצוע התיקונים, וביצוע בדיקה חוזרת

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

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

 

דיאלוג בודקים -צוות הפיתוח

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

הדרכת צוות הבדיקה

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

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

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

עיקרי נושאי ההדרכה:

 

 ·         תכנית עבודה ולו"ז

 ·         מידע על המערכת הנבדקת, מידע כללי ומידע טכני/תפעולי

 ·         כלי בדיקה רלוונטיים

 ·         דיווח וטיפול בתקלות

 ·         מהלך הבדיקה: הנחיות פרטניות

 ·         מה בודקים: מפרטי הבדיקה הרלוונטיים

 ·         מסקנות ולקחים מסבבים / בדיקות קודמים

ניהול סיכונים

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

קטגוריות סיכונים בתהליכי הבדיקות:

 

 ·         סיכונים שפוגעים במימוש הבדיקות - כגון, דחייה בשלבי פיתוח תוכנה, דחייה בהכנת סביבת הבדיקות, סביבת בדיקות לא יציבה

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

 ·         סיכונים שנובעים מהבדיקה - כגון, חשש לפגיעה ברכיב / מערכת / מסד נתונים עקב ביצוע הבדיקה

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

בחירת גורם לביצוע הבדיקות

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

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

נושאים לבדיקה והכנה

 ·         מה התקציב אשר הפרויקט מקצה לנושא בדיקות

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

 ·         תמהיל צוות הבדיקות - האם צוות הבדיקות יהיה מעורב, קרי עובדים מחברת בדיקות ואנשי הארגון.

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

שלבי בחירת חברת בדיקות

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

הספק הנבחר יכתוב את מסמך ה- STP אשר נכונותו והתאמתו תיבחן ע"י מנהל הפרויקט.

ניהול תקלות

מטרת הבדיקות הינה איתור וזיהוי תקלות

באם יש טעויות, הבדיקה הצליחה - אם אין טעויות, הבדיקה נכשלה!

תקלה - פעולה, מצב או התנהגות שאינם תואמים את מפרט אפיון המערכת. מקובל להגדיר Bug, אינטואיטיבית, בתור כל התנהגות של המערכת/הרכיב שאינה כפי "שהיא צריכה להיות" - המערכת לא ביצעה פעילות מבוקשת, המערכת ביצעה פעילויות לא רצויות, המערכת לא בצעה נכון את מה שנדרש ממנה.

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

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

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

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

במסמך הבדיקות יוגדר פורום CCB (Change Control Board) אשר יורכב ממנהל הפרויקט ו/או מהנדס המערכת, מנהל הפיתוח ו/או ראש צוות ה פיתוח. פורום CCB יסווג את התקלות ויקבע את העדיפות (במידת הצורך תוך התייעצות ואישור נציג הלקוח) לתיקון התקלות.

לפירוט נוסף, ראה הרחבה בנושא תקלות בהמשך.

תיקיית הבדיקות

יש להקים ספריה (תיקייה) מיוחדת לשלב הבדיקות בתוך תיקיית/פורטל הפרויקט.

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

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

תיקיית הבדיקות מכילה מספר תת-תיקיות בהתאם להחלטות הפרויקט ונהלי המחלקה והפרויקט. החלוקה הפיזית הראשית תהיה כדלהלן:

ניהול ומנהלה

בתיקייה זו יתויקו כל המסמכים הקשורים לתהליך הבדיקות בהיבטי ניהול (PMO), איכות ומנהלה. מבנה התיקייה המומלץ יהיה כדלהלן:

תוכנית הבדיקות

בתיקייה זו יתויקו כל מסמכי התכנון של שלב הבדיקות בהיבטי סביבת בדיקות, ATP, STP וכד'.

תסריטי בדיקות

בתיקייה זו יתויקו תסריטים או קישורים לוגיים לתיקיות הכלי בו מאוחסנים התסריטים ב- כלי בדיקה הממוכן וכד'. מבנה התיקייה המומלץ יהיה כדלהלן:

ביצוע הבדיקות

בתיקייה זו יתויקו תוצאות הבדיקות בפועל או קישור לתוצאות הבדיקות בכלי האוטומטי. מבנה התיקייה המומלץ יהיה כדלהלן:

סיכומי בדיקות

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

בדיקות ייחודיות

תיקייה זו תרכז ביצוע של בדיקות ייחודיות, כגון בדיקות רעידת אדמה. מבנה התיקייה המומלץ יהיה כדלהלן:

תוצרים

כל התוצרים נמצאים בלשונית תוצרים בקיט זה

תכנית בדיקות - STP

תכנית הבדיקה System Test Plan, מכילה את הנושאים הבאים:

 

 ·         מסמכים ישימים - אפיון/אופיון טכני, משימת פרויקט, מפרטים, תקנים וכד'

 ·         יעדים - יעדים ומטרות הבדיקות, בעיות, ניהול סיכונים

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

 ·         תשתית וסביבת בדיקות – תצורת סביבת הבדיקות, כלי בדיקות וכלי ניהול בדיקות, פירוט מרכיבי סביבת הבדיקה.

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

 ·         עלות - עלויות הקמה, ביצוע ותחזוקה.

 ·         תכולת הבדיקה - כולל אינדקס מפרטי הבדיקות וטבלת עקיבות (Cross Reference/ Traceability/ Coverage Matrix) שתאפשר לוודא שכל הדרישות מכוסות על-ידי תרחישים ותסריטים.

מסמך סיכום בדיקות - STR

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

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

עיקרי מסמך סיכום הבדיקות:

 

 ·         תכנית הבדיקה - סיכום תמציתי: איך התנהלה הבדיקה, תכולת הבדיקה – מה נבדק ומה לא ולמה, עמידת המערכת ביעדים שהוגדרו לה.

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

 ·         עלות - עלות הבדיקות

 ·         מסקנות ולקחים - פעילויות לשיפור בבדיקות / סבבים הבאים.

 

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

מפרט בדיקה/תרחיש (Script)

טופס המשמש לכתיבת תרחישי בדיקה ותסריטים לבדיקת רכיב מסוים. הטופס מורכב ממספר חלקים:

 ·         פרטי המערכת והגרסה הנבדקת

 ·         פרטים כלליים על המפרט, פרטי כותב ומאשר המפרט

 ·         ריכוז הרכיבים הנבדקים במפרט

 ·         מהלך הבדיקה, הנחלק לצד תכנון הבדיקה וביצוע צעדי הבדיקה וצד הביצוע ודיווח התקלות

 ·         הערות הבודק לסיום הבדיקה

אישור תחילת סבב בדיקות

טופס המסייע בידי הנהלת הפרויקט לרכז דרישות סף לתחילת סבב בדיקות ולאשר את תחילת הבדיקות

הנחיות לצוות בדיקות

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

נתוני בדיקה (Test Data)

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

בטופס מובאות שתי חלופות המקלות על ניתוח הנתונים המיוצרים לקובצי הניסוי

טופס תקלה

טופס לדיווח על תקלה במהלך הבדיקות ולמעקב התיקון. הטופס מכיל שני חלקים: פרטי התקלה ופרטי התיקון שלה. (בטופס יעשה שימוש בהעדר מערכת ממוכנת לניהול תקלות).

ריכוז תקלות

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

סטטוס סבב בדיקות

הטופס מכיל את הנושאים הבאים:

 

 ·         פרטים טכניים של המערכת והסבב

 ·         תוצאות הסבב לפי קטגוריות בדיקה

 ·         ריכוז התקלות שנתגלו

 ·         הסקת מסקנות ולקחים לסבבים הבאים

 

אבטחת איכות לבדיקות

מערכת האיכות וניהול איכות

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

איכות הבדיקות

לצורך ווידוא איכות הבדיקות יש לשאול:

 

 ·         האם הבודקים היו מיומנים דיים ?

 ·         האם הכלים שנבחרו התאימו לבדיקות בפועל?

 ·         האם הוקצב מספיק זמן לבדיקות?

 ·         האם בוצעה הפקת לקחים בכל תום סבב בדיקות?

 ·         האם מסמכי הבדיקות התאימו לבדיקות בפועל?

איכות התסריטים והתרחישים

לצורך ווידוא איכות התסריטים והתרחישים יש לשאול:

 

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

 ·         האם התסריטים היו רלוונטיים?

 ·         מה מספר התיקונים שבוצעו בתרחישים ובתסריטים?

איכות התוצר

עמידה של התוצר בארבעת מדדי האיכות:

 

 ·         פונקציונאליות - מענה לדרישות המשתמש: האם המוצר עושה מה שנדרש והאם עושה זאת נכון? האם אין בו באגים? האם הרכיב עושה רק מה שהוא נדרש לעשות?

 ·         יעילות ומבניות - איכות הנדסית: האם המוצר יעיל, אמין ובנוי כהלכה?

 ·         כלכליות - עמידה בגבולות המשאבים ולו"ז שהוקצו והוערכו מראש.

 ·         חוקיות - עמידה בדרישות החוק והרגולציה הרלבנטיים, מדיניות הארגון ותקני בחינה.

הרחבה בנושא תקלות

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

אפיון מערכת לניהול תקלות

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

מחזור חיים של תקלה וניהול סטאטוסים

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

דוגמא למחזור חיים של תקלה:

 

H_Testing_Img05_20080318

 

להלן דוגמה שנייה למחזור חיים של תקלה:

 

H_Testing_Img06_20080323

 

בטבלה הבאה מפורטות המלצות להצגת פעילויות המהוות טריגר למעבר בין סטאטוסים:

 

from

to

חדשה

מחודשת

בטיפול

תוקנה

סגורה

מושהית

כפולה

לא רלוונטית

מוקפאת

חדשה

 

 

 

 

 

 

 

 

 

מחודשת

 

 

 

דחייה

 

 

 

 

החייאה

בטיפול

השמה

השמה

 

 

פתיחה מחדש

השמה

פתיחה מחדש

פתיחה מחדש

 

תוקנה

 

 

תיקון

 

 

 

 

 

 

סגורה

 

 

 

אישור

 

 

סגירה

סגירה

 

מושהית

השהייה

השהייה

השהייה

 

 

 

 

 

 

כפולה

כפולה

כפולה

כפולה

 

 

כפולה

 

 

 

לא רלוונטית

לא רלוונטי

לא רלוונטי

לא רלוונטי

 

 

לא רלוונטי

 

 

לא רלוונטי

מוקפאת

הקפאה

הקפאה

הקפאה

 

 

הקפאה

 

הקפאה

 

 

 

להלן טבלה מומלצת להגדרת סטאטוסים של תקלה:

 

סטאטוס

תיאור

חדשה

כל תקלה מייד לאחר פתיחתה נמצאת בסטטוס זה.

בטיפול

לאחר שרש"צ מבצע השמה של התקלה לטיפול, הסטטוס שלה הופך ל"בטיפול".

תוקנה

תקלה שהסתיים תיקונה, תעבור לסטטוס זה, עד לבדיקה סופית ע"י פותח התקלה.

סגורה

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

אם היא מתרחשת עדיין (תיקון לא טוב או חלקי), הוא דוחה את התיקון והתקלה עוברת לסטטוס "מחודשת".

לא רלוונטית

תקלה לא רלוונטית היא תקלה שלא הייתה צריכה להיפתח בכלל.

מושהית

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

בגרסה הבאה היא תעבור שוב לסטאטוס "בטיפול".

מוקפאת

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

כפולה

תקלה שהסימפטומים שלה זהים לאלו של תקלה אחרת.

אופיינית

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

 

 

סיווג חומרת התקלות שהתגלו

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

להלן טבלה מומלצת להגדרת חומרת התקלה:

 

חומרה

משמעות

משביתה

תקלה אשר אינה מאפשרת להפעיל את המערכת או להפעיל מספר תפקודים עיקריים

חמורה

תקלה המשביתה תפקוד עיקרי של המערכת (לפני ביצוע הבדיקות ייקבע במסמך ה- STP מהם ה"תפקודים העיקריים")

בינונית

תקלה המשביתה תפקוד משני של המערכת

קלה

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

 

 

תקלות בסטאטוס "חמורה" ו"משביתה" יתווספו לתרחישי בדיקות השפיות של המערכת.

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

 

עדיפות לטיפול בתקלה

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

ניתן לסווג את הטיפול על פי הטבלה הנ"ל:

 

חומרת התקלה

עדיפות לטיפול (לדוגמא)

תקלה משביתה

טיפול מיידי בתקלה.

תקלה חמורה

תיקון התקלה לפני תחילת סבב בדיקות נוסף.

תקלה בינונית

תיקון תקלה לפני סיום סבב בדיקות נוסף.

תקלה קלה

 
 

תהליך טיפול בתקלה

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

להלן תיאור תהליך טיפול בתקלה:

 

פעולה

פרטים

אחראי

פתיחת תקלה

דווח התקלה במערכת ממוכנת או בטופס ידני, בצירוף הפרטים הבאים: גורם מדווח, מס' תרחיש + תסריט בהם התגלתה התקלה, שם משתמש, אתר נבדק, נושא, רכיבים מעורבים (שם מסך, שם תכנית וכדו'), תיאור התקלה, סביבת הבדיקות, התוצאה/התופעה שהתקבלה, הודעת מערכת/שגיאה, Dump, צילומי מסך, קבצי לוג וכל מידע נוסף רלוונטי אשר יסייע לניתוח ופתרון התקלה.

בודק

סיווג התקלה

פורום CCB יבחן את התקלה ויקבע אם היא אכן תקלה או שו"ש (שיפורים ושינויים).

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

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

מנהל הפרויקט

בדיקה האם התסריט שגוי

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

אם יתברר שהתסריט אינו תקין, יעודכן התסריט והתקלה תיסגר בציון סיבת הסגירה "תוקן תסריט"

אחראי בדיקות

בדיקת תקלה חוזרת

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

אם קיימת תקלה זהה, תיסגר הפניה ויצוין - תקלה כפולה.

אחראי בדיקות

טיפול בתקלה

המדור המתאים יטפל בתקלה ויבצע Unit Test.

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

יעודכן סטאטוס התקלה ל "טיפול".

מדור תוכנה/חומרה

סגירת התקלה

אחראי הבדיקות יוודא שאכן התקלה תוקנה ע"י ניסיון לשחזרה.

אם הבדיקה חיובית, יעדכן את סטאטוס התקלה ל "סגור".

יעודכן תאריך הסגירה ושם סוגר התקלה.

אם הבדיקה שלילית היא תועבר לגורם המטפל האחרון

אחראי בדיקות

 

 

מקור התקלה

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

 

 ·         תקלת אפיון – שגיאה בהגדרת האפיון. יש לתקן את התקלה באפיון, אח"כ בעיצוב ולבסוף בפיתוח. יש לתקן גם את תרחישי הבדיקות (נכתבו על בסיס האפיון).

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

 ·         תקלת פיתוח - אם המערכת אינה מתנהגת עפ"י העיצוב.

 ·         תקלה בתסריטי ותרחישי הבדיקות - נובעת מאי-תאימות של התרחיש לאפיון, לעיצוב או לסטנדרטים. יש לתקן את התרחיש / תסריט בלבד.

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

ניהול תקלות מול פרויקטים מקבילים

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

במקרה כזה יש לנהל את התקלה בשני הפרויקטים, כאשר האחראים על פתיחת התקלה הם אנשי הקשר (ה-POC). חומרת התקלה תקבע ע"י הפרויקט המושפע יותר מהתקלה. מספר התקלה בפרויקט א' יהיה ידועה לאיש הקשר בפרויקט ב' ולהיפך.

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

ניהול תקלות בשתי גרסאות במקביל

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

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

ניהול תקלות בתשתית

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

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

קיום מתח "בריא" בין מפתחים לבודקים

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

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

אי הסכמה על קיום/אי קיום של תקלה - נובעים במקרים רבים מתקלות שמקורן אינו בקוד, כלומר תקלות עיצוב או אפיון. לפיכך במקרה הנ"ל על פותח התקלה לבצע בירור מול המאפיין (או המעצב). באין תשובה מספקת יש להציף את הסוגיה לפתרון ברמת רש"צים.

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

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

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

 

ניהול תקלות בראיית ייצוב המערכת בתהליך הפיתוח

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

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

שלב 2 – אמצע הפיתוח – ככל שמתקדמים בבדיקת עוד סבבי פיתוח, קצב גילוי התקלות עולה, דבר המעיד על יכולת כיסוי בדיקות הולכת וגוברת, עד שמגיעה לשיא.

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

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

עקרונות לכתיבת תרחישים ותסריטים לבדיקות

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

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

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

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

רמת מיומנות של צוות הבדיקות

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

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

 

הפעלת פרוצדורות תוכנה או כלים אוטומטיים

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

 

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

 ·         מהי רמת הפירוט הנדרשת לשם הפעלת הכלים האוטומטיים וצפייה בתוצאות.

 ·         ההחלטה תהיה עפ"י רמת מבצעי הבדיקות המקליטים את התסריט בכלי האוטומטי.

טיפים לכתיבת תרחישים

להלן טיפים לכתיבת תרחישים / תסריטים:

 

 ·         חשיבה על כל מקרי הקצה ומקרים נדירים.

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

 ·         כיסוי כל הדרישות שהוגדרו. כל תסריט יכסה דרישה אחת לפחות.

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

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

 ·         מומלץ לא לאחד שלבים, אלא אם יש תוצאה צפויה אחת בלבד לכולם.

 ·         עדכן כל פרמטר או מידע אפשריים, וודא שהעדכון משתקף בכל דרך אפשרית.

 ·         בדוק גבולות נתונים.