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

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

Ramona Schwering

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

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

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

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

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

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

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

כמפתח, אתה משתמש גם באפליקציות ובמכשירים רבים אחרים. מהבחינה הזו, אתם המשתמשים שמסתמכים על כל המערכות האלה כדי "לעבוד". בתורם, אתם מסתמכים על אינספור מפתחים שיעשו כמיטב יכולתם כדי לגרום לאפליקציות ולמכשירים שלהם לעבוד. כדי לפתור את הבעיה, כמפתחים, גם אתם שואפים לעמוד באמון הזה. לכן המטרה הראשונה שלכם היא תמיד לשלוח תוכנות פועלות ולשרת את המשתמשים. כולל הבדיקות שאתם כותבים כדי להבטיח את איכות האפליקציה. Kent C. Dodds מסכם את זה היטב בפוסט שלו בנושא Static vs Unit vs Integration לעומת E2E Testing for Frontend Apps:

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

מאת קנט סי. מחסורים (Dodd)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מאת גיירמו ראוץ'

זהו אחד מהציטוטים הנפוצים ביותר בנושא זה, אז נפרט אותו:

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

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

יהלום בדיקה

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

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

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

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

בדיקת חלת דבש

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

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

• בדיקות משולבות. במאמר של Spotify נעשה שימוש בציטוט מאת J. B. Rainsברגer, כדי להגדיר את השכבה הזו: "בדיקה שתעבור או תיכשל על סמך התקינות של מערכת אחרת". בבדיקות כאלה יש יחסי תלות חיצוניים שצריך לקחת בחשבון, ולהפך, יכול להיות שהמערכת שלכם מהווה תלות שגורמת למערכות אחרות. בדומה לבדיקות E2E באנלוגיות אחרות, יש להשתמש בבדיקות האלה בזהירות, רק במקרים החיוניים ביותר.
• בדיקות הטמעה. בדומה להתאמות אחרות, עליכם להתמקד בשכבה הזו. היא כוללת בדיקות שמאמתות את נכונות השירות שלך באופן מבודד יותר, אבל עדיין בשילוב עם שירותים אחרים. פירוש הדבר הוא שהבדיקות יכללו גם מערכות אחרות ויתמקדו בנקודות האינטראקציה, למשל, באמצעות בדיקות API.
• בדיקות של פרטי ההטמעה. הבדיקות האלה דומות לבדיקות יחידה – בדיקות שמתמקדות בחלקים בקוד שהם מבודדים באופן טבעי, ולכן יש להם מורכבות פנימית משל עצמם.

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

גביע בדיקה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

עצות מעשיות: בואו נתכנן אסטרטגיה!

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

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

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

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

מאת Justin Serls

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

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