בתאריך 26.03.2025 התקיים וובינר בסגנון פאנל שכותרתו הייתה:

Share your Best Test Plan

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

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

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

משתתפי הפאנל כללו את:

קארין זלוף - מובילת בדיקות בחברת Autodesk

דור חן - מהנדס בדיקות אוטומציה במובייל בחברת Bluevine

מישל שושנקוב - מהנדסת בדיקות בחברת Image AI

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

יתרונות השיטה:

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

חסרונות השיטה:

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

מתי כדאי להשתמש בגישה זו?

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

איזה בדיקות יש לבחור לאוטומציה? 

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

מישל התמקדה ביצירת STP בסגנון רשימת בדיקות (Checklist) ובסגנון עץ בדיקות (Test Tree), תוך כדי דגש על פשטות, יעילות, ויכולת הסתגלות לשיטות עבודה אג'יליות.

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

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

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

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

טיפים

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

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

קישור לצ׳ק ליסט שמישל הציגה

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

תרחישים שחוזרים על עצמם, עתירי-סיכון, גוזלי זמן, יציבים ומבוססי-נתונים.

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

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

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

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

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

קישור לפרופיל לינקדאין של רם

קישור לפרופיל לינקדאין של מישל

קישור לפרופיל לינקדאין של קארין