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

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

Ramona Schwering

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

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

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

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

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

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

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

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

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

מאת Kent C. Dodds

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

קביעת אסטרטגיות בדיקה: איך בוחרים אסטרטגיית בדיקה

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

הקלאסי: פירמידה של בדיקות

ברגע שתתחילו לחפש אסטרטגיות בדיקה, סביר להניח שתתקלו בתרשים הפירמידה של אוטומציית הבדיקות בתור הדוגמה הראשונה. מייק קון (Mike Cohn) הציג את הקונספט הזה בספר שלו 'הצלחה עם Agile'. מאוחר יותר, Martin Fowler הרחיב את המושג במאמר שלו Practical Test Pyramid. אפשר לייצג את הפירמידה באופן חזותי באופן הבא:

כפי שמוצג בתרשים הזה, פירמידה הבדיקה מורכבת משלושה שכבות:

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

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

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

רווח בר-סמך לעומת משאבים

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

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

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

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

פירמידה עברה שדרוג! התאמות של פירמידות הבדיקה

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

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

מאת Guillermo Rauch

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

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

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

יהלום לבדיקה

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

כתוצאה מכך, יחד עם ההתמקדות הרבה יותר בבדיקות השילוב, יכול להיות שהתהליך ייראה כך:

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

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

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

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

הצורה הזו מזכירה לנו כוורת, ולכן השם. הוא כולל את השכבות הבאות:

• בדיקות משולבות. במאמר של Spotify מופיעה ציטוט מ-J. ב. Rainsberger כדי להגדיר את השכבה הזו: "בדיקה שתעבור או תיכשל על סמך תקינות המערכת האחרת". לבדיקות כאלה יש יחסי תלות חיצוניים שצריך להביא בחשבון, ומנגד, יכול להיות שהמערכת שלכם היא יחסי תלות שגורמים לבעיות במערכות אחרות. בדומה לבדיקות E2E בדוגמאות אחרות, צריך להשתמש בבדיקות האלה בזהירות, רק במקרים החיוניים ביותר.
• בדיקות אינטגרציה. בדומה להתאמות אחרות, כדאי להתמקד בשכבה הזו. הוא מכיל בדיקות שמאמתות את תקינות השירות בצורה מבודדת יותר, אבל עדיין בשילוב עם שירותים אחרים. כלומר, הבדיקות יכללו גם מערכות אחרות ויתמקד בנקודות האינטראקציה, למשל באמצעות בדיקות API.
• בדיקות של פרטי ההטמעה. הבדיקות האלה דומות לבדיקות יחידה (unit testing) – בדיקות שמתמקדות בחלקים של הקוד שמבודדים באופן טבעי, ולכן יש להם מורכבות פנימית משלהם.

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

גביע לבדיקה

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

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

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

מידע נוסף על גביע הבדיקות זמין בפוסט בבלוג של Kent C. Dodds בנושא הזה.

עוד כמה גישות שמתמקדות בממשק המשתמש

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

בדיקת גלידה בגביע ובדיקת סרטן

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

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

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

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

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

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

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

עצה מעשית: קדימה, נתחיל לתכנן אסטרטגיה!

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

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

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

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

מאת ג'סטין סיירלס (Justin Searls)

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

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