האנציקלופדיה לבדיקות | קובי יונסי

מה הם 7 עקרונות הבדיקה?

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

להלן סקירה של 7 העקרונות:

עקרון מס' 1

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

Testing shows the presence of defects

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

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

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

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

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

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

עקרון מס' 2

זה בלתי אפשרי לבצע בדיקות ממצות

Exhaustive testing is impossible

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

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

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

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

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

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

עקרון מס' 3

בדיקות מוקדמות חוסכות זמן וכסף

Early testing

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

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

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

למהלך הזה קוראים בתעשייה : shift left for testing וזה מוכח כמהלך שחוסך הרבה מאוד כסף וזמן בתיקון של תקלות.

עקרון מס' 4

התקבצות פגמים Defect clustering –

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

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

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

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

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

עקרון מס' 5

פרדוקס ההדברה Pesticide paradox –

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

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

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

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

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

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

עקרון מס' 6

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

Testing is context dependent

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

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

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

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

היבטים מרכזיים של עקרון הבדיקה תלוית הקשר כוללים:

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

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

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

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

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

עקרון מס' 7

העדר שגיאות היא סברה מוטעית

Absence-of-errors fallacy

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

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

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

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

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

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

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

ואלו היו 7 עקרונות הבדיקה.

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

השאלה היא, איך נוכל לשלב את העקרונות הללו בתהליך הפיתוח שלנו?

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

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

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

לי זה עבד לאורך השנים ואיפה זה פוגש אתכם?

מוזמנים לכתוב, להעיר, להאיר ולשתף.

יש נושאים ומושגים נוספים שהייתם רוצים לקרוא עליהם? תשלחו מייל ואשמח לכתוב[email protected]