בדיקות חקרניות הן סוג ספציפי של בדיקות תוכנה שיש לה יתרונות רבים עבור אפליקציה, המאפשרות לה למצות את הפוטנציאל שלה.
האופן שבו צוות משלב בדיקות חקרניות בבדיקות השגרתיות שלו יכול אפילו לקבוע עד כמה התוכנה מתפקדת, במיוחד כשהיא מתקרבת להליכי הבדיקה בדרכים חדשות ובלתי צפויות. זה עוזר לבודקים לחשוף בעיות בתוך האפליקציה שעלולות להישאר מעיניהם עד ההשקה ולגרום לכך שתכונות מפתח לא פועלות.
הבנת התהליכים, הסוגים והגישות של בדיקות חקרניות יכולה לעזור לך לכוון את הארגון וצוותי הבדיקות שלו כיצד לשלב זאת בבדיקות הרגילות שלהם.
ישנם גם מספר כלים חינמיים שבהם הצוות יכול להשתמש כדי להקל על הבדיקות הללו ולהבחין בבעיות לפני שהן עשויות להפוך לחסימות דרכים לפיתוח.
במדריך זה, אנו מציגים את היתרונות של בדיקות חקרניות לצד השיקולים המרכזיים שצוות צריך לשקול לפני היישום.
מהי בדיקות חקרניות?
בדיקות חקר משלבות את שלבי תכנון וביצוע הבדיקה, מבטיחה חופש תפעולי מלא לבוחן ומאפשרת להם לייעל באופן רציף את עבודתו.
כשהצוותים האלה יבדקו את התוכנה, הם סביר להניח יגלו רכיבים חדשים הדורשים בדיקות יסודיות ועשויים בקלות להמציא בדיקות חדשות שיועילו לאפליקציה.
בדיקות חקר דומות לבדיקות אד-הוק אך עוקבות אחר תיעוד קפדני הרבה יותר, ומשלבות גם תהליך למידה אקטיבי יותר.
הגישה הפחות מובנית מסייעת לבודקים לברר כיצד יישום עשוי להגיב לתרחישים ולמקרי בדיקה מציאותיים ומשמשת כהשלמה חיונית לבדיקות תסריטאיות.
איכות הבדיקות החקרניות של צוות תלויה לרוב במיומנותם של בודקים בודדים שכן הבדיקות דורשות יצירתיות והבנה מעמיקה של התוכנה. זהו תהליך של גילוי מתמשך – כזה שבו בודקים משתמשים בהיגיון דדוקטיבי כדי להנחות את הטכניקה הכוללת שלהם.
בדיקות חקר מועילות במיוחד בגלל שהן משקפות את האופן שבו משתמשים עשויים להשתמש בתוכנה. רוב המשתמשים מוצאים באגים ובעיות בטעות, כך שתהליכים ללא סקריפט אלה יכולים לעזור לבודקים למצוא בעיות שבדיקות קבועות מראש עשויות לא לחשוף.
זה גם אפשרי לצוות להפוך את ההליך הזה לאוטומטי כדי להבטיח רמת יעילות גבוהה יותר.
1. מתי צריך לעשות בדיקות חקרניות?
בדיקות חקר מועילות בדרך כלל כמעט בכל תהליך בדיקת תוכנה, אם כי היא מצטיינת במיוחד במתן משוב מהיר על אפליקציה.
הצוות עשוי גם לשלב את הבדיקות הללו אם ייגמרו להם הבדיקות התסריטאיות. ללא הנחיות ברורות לבדיקות התוכנה שלהם, בדיקות גישוש עשויות לסייע בגילוי בעיות שמתאימות מחוץ לבדיקות הסטנדרטיות.
הבטחת הליכי בדיקה מגוונים מאפשרת לבודקים להבין את התוכנה הזו ברמה הרבה יותר עמוקה בכל שלב, אך עריכתם המוקדמת עשויה להציע יתרונות נוספים.
ניתן לצוותים לערוך מחדש בדיקות גישושים מאוחר יותר לפי הצורך לשקט נפשי נוסף.
2. כאשר אין צורך לבצע בדיקות חקרניות
ישנם כמה תרחישים שבהם בדיקות חקרניות לא מציעות יתרונות, אם כי זה יכול להיות שימושי יותר עבור בודקים לחכות עד שהתוכנה תקבל את פונקציונליות הליבה שלה.
התכונות של אפליקציה בדרך כלל מצטלבות או מקיימות אינטראקציה זו עם זו, מה שאומר שבדיקות גישושים בפונקציה אחת עשויות להיות מיושנות ברגע שצוות הפיתוח מוסיף יותר לתוכנה זו.
אפשר גם לבצע את הבדיקות הללו לצד בדיקות תסריטאיות ללא בעיה, בהנחה שהבודקים יכולים להבטיח רמה חזקה של תיעוד כדי למנוע בלבול.
בדיקות חקר הן רב-תכליתיות ביותר בהשוואה לסוגי בדיקות אחרים, מה שהופך את הבדיקות הללו לישימות מאוד.
3. מי מעורב בבדיקות חקרניות?
בדיקות חקר מערבות אנשי צוות רבים בהיבט מסוים, כולל:
• בודקי תוכנה מכל רמת מיומנות יכולים לבצע את המבחנים הללו, אם כי חברי צוות בעלי הבנה טובה יותר של התוכנה יכולים לתכנן מגוון גדול יותר של בדיקות.
הניסיון עשוי גם להשפיע על יכולתם לקבוע את המבחנים השימושיים ביותר.
• מפתחי תוכנה שמכירים בתוצאות של בדיקות אלו, יפעלו בכל הצעה ולעתים קרובות יפתחו פתרון משלהם לבעיה.
התגובה שלהם לבדיקות היא המאפשרת לאפליקציה להגיע למצב התאמה לשחרור מוצלח.
• מנהלי פרויקטים שמפקחים על כל התהליך הזה ויכולים אפילו להיות אלו שיחליטו באילו סוגי בדיקות הצוותים מעסיקים.
הם עשויים גם להיות אחראים על רכישת תוכנה עבור הצוותים שיכולה לייעל או אפילו להפוך בדיקות לאוטומטיות.
מחזור חיים של בדיקות חקרניות
תהליך הבדיקה החקרני מתמקד חזק בחופש הבודקים, אך עדיין עוקב אחר מבנה ספציפי.
שלושת השלבים העיקריים של גישה זו הם:
שלב 1: למידה
בודקים מתחילים בפיתוח הבנה חזקה של התוכנה והפונקציונליות שלה – מנתחים אותה באופן ביקורתי כדי לקבוע כיצד היא משתלבת.
זה מאפשר לבוחן להבין את הקלט הרגיל שמשתמש יכול לבצע, אם כי ייתכן שהוא כבר מודע לאפליקציה ולאופן שבו היא פועלת.
שלב הלמידה יכול אפילו לדרוש הדרכה כיצד לתפעל את התוכנה. זהו שלב החקירה והוא מצייד את הבוחן בכל המידע הדרוש לו כדי לתכנן מגוון רחב של בדיקות שימושיות.
שלב 2: עיצוב מבחן
עיצוב מבחן גישוש אומנם כולל כללים ופרמטרים שונים, אך עדיין מציע חופש משמעותי יותר בהשוואה לבדיקות תסריטאיות – שפרטיהן ידועים כבר לפני תחילת הבדיקה.
הבוחן יכול להמציא בדיקות שלדעתם מתאימות לאפליקציה בצורה מדויקת יותר ויכולים לחשוף נתונים בעלי ערך עבור צוות הפיתוח, כולל שגיאות בולטות לתיקון.
צוותי בדיקה משתמשים בשלב זה כדי לברר באיזו גישה לנקוט וכיצד לחלק את העבודה בין הבודקים השונים בדרכים שמשפיעות על החוזקות שלהם.
שלב 3: ביצוע
לאחר תכנון הבדיקות לשימוש, הבודקים יכולים כעת לבדוק את האפליקציה בדרכים שהם מאמינים שהן היעילות ביותר – הם עשויים לבצע זאת מיד לאחר תכנון הבדיקה הספציפית.
זה השלב שבו בודקים מחפשים באופן פעיל בעיות וכיצד כל בעיה שהם חושפים יכולה להזין תכונות ופונקציות אחרות.
אמנם יש מידה מסוימת של עבודה אינטואיטיבית המעורבת בביצוע בדיקות חקרניות, אך היא עדיין עוקבת אחר תהליכים ויעדים מוגדרים, מה שמאפשר בדיקה זורמת שיכולה להתאים בקלות את יעדי הבדיקה הספציפיים.
בדיקה חקרנית לעומת בדיקות תסריטאיות
בדיקות גישוש הן למעשה ההפך מבדיקות תסריטאיות, אם כי שתיהן עשויות להיות חשובות כדי להבטיח שהאפליקציה מוכנה לשחרור. האחרון הוא בדרך כלל רשמי ומובנה יותר, וכולל בדיקות רחבות רבות בהשוואה לבדיקות חקרניות, שלעתים קרובות ספציפיות יותר לפונקציונליות של האפליקציה.
כחלק מכך, גם בדיקות חקרניות ניתנות להתאמה משמעותית, בעוד שבדיקות תסריטאיות יכולות להתקשות אם יש שינויים גדולים בתוכנה. בדיקות גישוש עשויות לחשוף באגים ולפעול נגדם מהר יותר, מה שהופך את הראשון לשימושי במיוחד במקרים שבהם משוב מהיר הוא בעל חשיבות עליונה.
1. בדיקות חקרניות אקטיביות
בדיקות חקרניות אקטיביות כוללות בודק שמעצב סקריפט אוטומטי עבור הבדיקות שלו, שבודק אחר מבצע. סקריפטים אלה לוקחים בחשבון את המבחנים הקודמים אם רלוונטי.
שני הבודקים בדרך כלל מחליפים תפקידים במהלך הליך הבדיקה כדי לבדוק פעמיים את המהימנות של סקריפטים ותהליכים אלה.
לבדיקות אקטיביות יש כיסוי רחב יותר מבלי לוותר על הספציפיות של סימן המסחר של בדיקות חקרניות. סקריפטים אלה מאפשרים גם תיעוד טוב יותר, מה שמקל על שחזור כל בעיה שהבודקים מוצאים.
תיעוד הוא מרכיב חיוני של בדיקות אקטיביות שכן זה גם עוזר לבעלי עניין לראות את ההתקדמות הכוללת של היישום.
2. בדיקות חקר פסיביות
בדיקות חקר פסיביות דורשות רק בודק אחד, אם כי עבודה בזוגות יכולה לייעל את התהליך עוד יותר.
גישה זו כוללת תוכנה ספציפית שמתעדת את פעולות הבודקים – מספקת להם שלבים קלים לשכפול כל בעיה שהם חושפים. זה בדרך כלל בצורה של סרטון עם הבוחן נותן פרשנות שמסבירה את פעולותיו שלב אחר שלב.
הקלטת תהליך הבדיקה נותנת גם תובנות לגבי ביצועי האפליקציה, כולל המהירות שבה היא מגיבה לבקשות קלט.
בדיקות פסיביות מספקות הן לבודקים והן לצוות הפיתוח שפע של מידע מפורט על אופן פעולת התוכנה.
טכניקות בדיקה חקרניות
בדיקות חקר בדרך כלל עוקבות אחר פורמט ‘סיור’ – שבו בודק חוקר את התוכנה בצורה היעילה ביותר.
ישנם סיורים שונים שהצוות יכול לבחור מהם, כולל:
• סיורים בספר הדרכה
גישה זו נותנת עדיפות לפונקציונליות המודגשת של האפליקציה, משכפלת מקרוב את האופן שבו משתמש ממוצע מתקשר עם התוכנה ומגלה בעיות שהוא ימצא באופן טבעי.
• סיורי היסטוריה
סיור זה בודק את התכונות הישנות ביותר של האפליקציה כדי לוודא שהן עדיין פועלות; זה חשוב במיוחד אם המפתחים הוסיפו תכונות חדשות שמתנגשות איתה.
• סיור כסף
מבחן חקר זה בודק את תכונות האפליקציה הקריטיות, במיוחד אלה שלקוחות ולקוחות משלמים כסף כדי לגשת אליהם – אלה הם בדרך כלל העדיפויות הגבוהות ביותר בקרב צוות הבדיקות.
• סיור מסע פשע
בודקים לפעמים פועלים באופן אקטיבי כדי לשבור אפליקציה או לגרום לתרחישים שליליים, כגון על ידי הזנת מידע לא חוקי וחקירה כיצד האפליקציה מגיבה לכך.
• סיור בסמטה האחורית
תהליך זה כולל תכונות שפחות לקוחות עשויים לעשות בהן שימוש; אלה חיוניים לא פחות עבור כל גישת בדיקה, במיוחד מכיוון שהם יתקשרו עם פונקציות אחרות.
• סיור אינטלקטואלי
סיור זה דוחף את האפליקציה הלאה, בודק את הפונקציות המסובכות ביותר עם ערכים גבוהים יותר (לפעמים המקסימום) כדי לקבוע את מהירות העיבוד של התוכנה.
גישות בדיקה חקרנית
ישנן שתי גישות עיקריות לבדיקות חקרניות:
1. בדיקות חקירה מבוססות מפגש
זוהי טכניקה מבוססת זמן שמטרתה לכמת את תהליך הבדיקה על ידי חלוקתו ל’מפגשים’ עם שני מרכיבים: משימות וצ’רטרים.
המשימה היא המטרה ומשך הפגישה המסוימת, מספקת לבוחן חקרני עם מיקוד ברור.
אמנה קובעת את היקף כל מפגש ומפרטת את כל היעדים הספציפיים שהבודק מתכוון להגשים. זה מביא לרמה גבוהה יותר של אחריות (ותיעוד) על ידי פיצול בדיקות אלה לרכיבים ניתנים לניהול.
בדיקות מבוססות הפעלה גם משפרות את הפרודוקטיביות ומספקות לבודק מדדים ברורים ומידע על פתרון בעיות.
2. בדיקות חקרניות מבוססות זוג
בדיקה מבוססת זוג דומה לבדיקות חקרניות אקטיביות שכן היא כוללת בעיקר עבודה בזוגות – בדרך כלל על אותו מכשיר – כדי לבדוק באופן רציף את האפליקציה בו זמנית. בסידור זה, בודק אחד מציע מגוון מקרי בדיקה ושומר הערות על ההתקדמות בעוד שהשני בודק את התוכנה.
תקשורת חיונית לאורך כל בדיקות מבוססות זוג, מכיוון שהדבר מוודא ששני הבודקים מודעים לבדיקות ולמטרתן.
אם אתה מקצה את הזוגות האלה בעצמך, הקפד להתאים את החוזקות והחולשות של כל בוחן, שכן זה מאפשר לך לבנות תהליכי בדיקה חקרניים חזקים יותר.
אילו גורמים משפיעים על בדיקות חקר?
הגורמים שעלולים להשפיע על איכות הבדיקות החקרניות של צוות כוללים:
• מטרת העל ופונקציונליות הליבה של התוכנה.
• מטרות הבדיקה הספציפיות לשלב הנוכחי של יישום.
• התפקידים והיכולות האישיות של כל בוחן בצוות.
• הכלים הזמינים, כגון תוכנה חינמית לאוטומציה של בדיקות.
• התמיכה שהבודקים מקבלים מעמיתים או מההנהלה.
• בקשות הלקוח והמגמות הרחבות העכשוויות בשוק.
• קלות השימוש של האפליקציה, כגון נזילות הממשק.
• הזמן שיש לבודקים להשלים את שלב הבדיקה.
• הקלט ונתונים מגוונים אחרים שהבודקים מתכוונים להשתמש בהם.
• התכונות שמפתחים מוסיפים לתוכנה לאורך זמן.
סוגי בדיקות חקרניות
שלושת הסוגים העיקריים של בדיקות חקרניות שצוות יכול לשלב הם:
1. בדיקה חקרנית בסגנון חופשי
בדיקת סגנון חופשי מאמצת את גישת האד-הוק לבדיקת אפליקציה. יש לזה כמה כללים שצריך לתת עליהם את הדעת ולכן היעילות שלו עשויה להשתנות; חלק מהתוכנות והרכיבים מחייבים מתודולוגיה חזקה יותר.
בדיקות אלו עדיין יכולות להציע יתרונות רבים בכך שהם עוזרים לבודקים להכיר את האפליקציה הזו ולאמת עבודה של בודק קודם.
גם ללא כללים נוקשים, בודקים מנוסים ומיומנים עשויים להשתמש בזה בקלות כדי לפרמט לטובתם. הם יכולים לעבור בקלות בכל היבט של התוכנה – במצבים מסוימים, כללי הבדיקה מגבילים ועלולים להגביל בטעות את תוצאות הצוות.
2. בדיקות חקרניות מבוססות תרחיש
בדיקה מבוססת תרחישים משתמשת במצבים מציאותיים כבסיס לכל בדיקה, כגון על ידי בדיקת תשומות שסביר שהמשתמשים יבצעו במהלך הפעולה האופיינית של תוכנה זו.
בודקים עובדים קשה כדי להבטיח שכל תרחיש שהם ממציאים תואם לאופן שבו משתמש מתקשר עם האפליקציה.
הזמן יכול להוות מגבלה שכן המטרה של הצוות היא לבדוק כמה שיותר תרחישים; בהתאם למועדים קדימה, סביר להניח שזה לא יוכל לכסות כל אפשרות.
בודקים צריכים להפעיל מגוון רחב של מבחנים בקטגוריות שונות.
3. בדיקות חקרניות מבוססות אסטרטגיה
בדיקה מבוססת אסטרטגיה כוללת מגוון רחב של שיטות ספציפיות כולל בדיקת ערך גבול, טכניקות שקילות, טכניקות מבוססות סיכונים ועוד. זה בדרך כלל נותן עדיפות לבודקים שכבר מכירים את האפליקציה מכיוון שהם יכולים לפתח אסטרטגיות מותאמות המשלבות שיטות בודדות אלו.
גישה מבוססת אסטרטגיה מתמקדת בעיקר בפונקציונליות של התוכנה (ובפעולה הפנימית) מבלי להסתכל על התרחישים האפשריים שעלולים להוביל משתמש להיתקל בבעיות שצצות. זה יכול להביא לניתוח רחב יותר של יישום ותכונותיו השונות, אולי לעומק רב יותר מאשר גישות שונות אחרות.
בדיקות חקר ידניות או אוטומטיות?
צוותי בדיקה יכולים לבצע בדיקות חקירה באופן ידני או שהם יכולים להפוך אותם לאוטומטיים. לכל אחת מהאפשרויות יש את היכולת להציע יתרונות אדירים; האפשרות הנכונה תלויה לעתים קרובות בפרטי הפרויקט.
בדיקות חקר ידניות
בדיקות חקרניות ידניות מאפשרות מגוון גדול יותר של בדיקות מותאמות אישית. למרות שזה יכול להימשך זמן רב יותר בגלל שהבודקים האנושיים איטיים יותר ממחשבים, בדיקה ידנית יכולה להיות מכרעת בקביעת חווית המשתמש.
בודק פועל לא רק כדי להבטיח שהתכונות של אפליקציה פועלות כמו שצריך, אלא גם כדי לוודא אם בסיס המשתמשים יכול להפעיל אותה בקלות. זוהי אולי הצורה הנפוצה ביותר של בדיקות חקרניות – אם כי זה לא בהכרח הופך אותה ליעילה ביותר.
1. יתרונות בביצוע בדיקות חקירה באופן ידני
היתרונות של בדיקות חקר ידניות כוללות:
התמקדות חזקה יותר בשימושיות
בדיקות גישוש אוטומטיות עשויות להבחין באי-התאמות בתוכנה, אך ייתכן שלא יוכלו לפרש את הבעיות הללו באותו אופן כמו בודק אנושי.
זה כולל הבנה של האופן שבו משתמשי התוכנה עשויים לנווט או לקיים אינטראקציה עם האפליקציה, משהו אוטומציה לא יכולה לקחת בחשבון.
בודקי חקירה ידניים יכולים להציע רמה גבוהה יותר של משוב, כולל פרטים ספציפיים על האופן שבו הבעיות שהם מוצאים משפיעות על התוכנה הכוללת או על החוויה הכללית.
יכול לבצע שינויים בזמן אמת
אחת מנקודות החוזק המרכזיות של בדיקות חקרניות היא שניתן לזהות את הצורך בבדיקה ולבצע אותה במהירות יחסית לפני מכירות פומביות של השיפורים הנדרשים.
בדיקות אוטומטיות הן בדרך כלל תהליך הרבה יותר מהיר, אבל הבודקים חייבים להמתין עד שהכל יסתיים לפני ביצוע שינויים – בודקים ידניים יכולים לעשות זאת בזמן שתהליך הבדיקה החקרני עדיין בעיצומו.
עם זאת, לעתים קרובות זה אפשרי רק עבור שגיאות המשפיעות על חלקים מינוריים של התוכנה.
תשומת לב רבה יותר לפרטים
בדיקות חקרניות עוסקות בעיקר בגילוי דרכים חדשות לבדיקת אפליקציה תוך הבנתה; זה יכול לפעמים לומר שמבחן אחד מוביל לאחר על ידי מתן רעיונות לבוחן.
בדיקות אוטומטיות עשויות שלא להתייחס לכך בגלל היותה ניתנת יחסית לצוות הבדיקות. בודקים ידניים משפרים ללא הרף את הידע שלהם על התוכנה ומעצבים בדיקות חדשות אך חשובות לא פחות – אבל זה יכול להיות קשה אם תוכנת צד שלישי עושה אותם אוטומטית.
יכול למצוא שגיאות מחוץ לקוד
בדיקות חקר ידניות מאפשרות לבודקים להסתכל על כל היבט של האפליקציה והתוכנה, כולל מעבר לקוד עצמו.
גישות אוטומטיות רבות מוגבלות לקוד ולאופן פעולתו, מה שעלול לגרום לכך שצוותי בדיקה לא יבחינו בבעיות שעלולות להופיע בחלקים אחרים של האפליקציה.
זה תלוי בעיקר בתוכנת האוטומציה שיש לך מכיוון שפתרונות מסוימים יכולים להציע גישה רחבה יותר לבדיקות חקרניות.
מבטיח איכות לאורך כל הפרויקט
בדיקות גישוש אוטומטיות מחפשות רק שגיאות ומדדים בתוך האפליקציה; בודקים ידניים יכולים במקום זאת לבדוק את התוכנה ולהציע משוב מקיף משלהם.
לדוגמה, הם יכולים לבדוק את הקוד ולקבוע שהוא מורכב מדי – חשוב במיוחד מכיוון שקוד מת יכול להאט את הביצועים אך למעשה לא יזוהה על ידי תהליכים אוטומטיים.
הידע של בודק על התוכנה עשוי להיות מכריע באבחון בעיות שעולות בשלבים אחרים של הבדיקה.
2. אתגרים של בדיקות חקר ידניות
האתגרים של בדיקות חקר ידניות כוללים:
אפשרות לטעויות אנוש
בדיקות חקר אוטומטיות יכולות להריץ את אותה בדיקה בדיוק כמה פעמים שצריך ללא שינויים בהתקדמות המדויקת, מה שמבטיח עקביות ותוצאות אמינות.
בדיקות חקר ידניות חשופות לטעויות אנוש, כלומר הבוחן עשוי להזין ערך שגוי. בדרך כלל ניתן לבדוק שוב את הבדיקות הללו ולתקן אי-התאמות מכיוון שהן עשויות להיראות ברורות אפילו במבט ראשון.
עם זאת, ביצוע מחדש של בדיקה לאחר שמבחינים בטעות עלול לקחת יותר זמן.
בדרך כלל לוקח יותר זמן
גם אם הבודקים מבצעים כל בדיקה חקרנית בצורה נכונה ללא טעויות אנוש, התהליך הכולל הזה לוקח הרבה זמן בהשוואה לתוכנה אוטומטית שיכולה לחשב את הבדיקות הרבה יותר מהר.
זה יכול להיות הבדל של מספר שעות לכל הפחות; זמן שהבודקים יוכלו להשקיע בחלקים מהאפליקציה שלא ירוויחו מאוטומציה.
בדיקות חקר דורשות גם פיקוח מתמיד, ואילו אוטומציה מאפשרת לבדיקות לפעול בן לילה.
תהליך תיעוד ארוך
על פי קווים דומים, תיעוד ידני במהלך ואחרי הבדיקה הידנית עלול להוות עומס מיותר על תהליך הבדיקה החקרנית.
זה מקשה על מעקב אחר שינויים ועריכות תוכנה לאורך זמן – תוכנה אוטומטית מסוגלת בדרך כלל לקחת זאת בחשבון באופן אינטואיטיבי בעת הפעלת בדיקות.
זהו עוד נושא ניהולי שלוקח זמן ואנרגיה מעניינים אחרים, מה שמפחית למעשה את ההיקף והרוחב של הליך בדיקות התוכנה הכולל.
חייב להכיר את התוכנה מקרוב
בודקים ידניים מכל רמת מיומנות יכולים לבדוק את היישום ולבדוק אותו ביסודיות. הסיבה לכך היא העבודה שהם השקיעו בהבנת התוכנה – השלב הראשון של תהליך החקר.
עם זאת, אם בוחן מתקשה או מזניח ללמוד כיצד יישום זה עובד, סביר להניח שהוא ייאבק להמציא ולבצע מגוון מתאים של בדיקות.
הכרת התוכנה היטב מאפשרת לבודקים ללכת מעל ומעבר לפרמטרי הבדיקה הרגילים.
יקר לתחזוקה
הסתמכות על בדיקות חקרניות ידניות מצריכה בדרך כלל צוות בדיקות גדול יותר, מה שעלול לגרום לעלויות גבוהות יותר בטווח הארוך בהשוואה לבדיקות אוטומטיות. תוכנת הצד השלישי שעורכת את הבדיקות החקרניות הללו עשויה לספק ערך עצום או אפילו להיות ללא תשלום לחלוטין.
בהתאם למורכבות המשימות, חברה עשויה לדרוש בודקים מיומנים ביותר עם שנים של ניסיון כדי לבדוק את האפליקציה במלואה. זה עשוי להגדיל משמעותית את הוצאות הבדיקה בהשוואה לשימוש בתוכנת אוטומציה חינמית.
3. מתי להשתמש בבדיקות חקר ידניות
בדיקות חקר ידניות מגיעות לרוב עם מספר אתגרים, אך היא עדיין מרכיב חיוני בבדיקות תוכנה יסודיות. הסיבה לכך היא שיש היבטים של התוכנה שהאוטומציה לא יכולה לתת עליהם את הדעת במלואם, שגם דורשים מיקוד חזק.
לדוגמה, תוכנה אינה יכולה לספק משוב אמין על ממשקי משתמש או מבחני חווית משתמש. בודקים יכולים לקבל מושג טוב על איך אפליקציה פועלת בפועל רק אם הם בודקים אותה באופן ידני. המשמעות היא שגם מפתחים וגם צוותי בדיקה חייבים לשקול לשלב לפחות מידה מסוימת של בדיקות חקרניות ידניות בבדיקות שלהם.
בדיקות חקר אוטומטיות
בדיקות אוטומטיות משתמשות בתוכנת צד שלישי כדי להפוך בדיקות מסוימות לאוטומטיות – בודקים יכולים בדרך כלל להתאים זאת כך שיתאים למעשה לכל בדיקה.
עם זאת, בדרך כלל זה מחייב את הצוות להפעיל את הבדיקה באופן ידני לפחות פעם אחת כדי לכייל את האוטומציה. זה יכול לייעל משמעותית את התהליך הן עבור צוותי הבדיקה והן עבור צוותי הפיתוח.
למרות שאוטומציה של בדיקות חקירה עשויה להיות נדירה, יש כמה יתרונות ברורים לעשות זאת עבור היישום שלך וביצועיו.
1. היתרונות של אוטומציה של בדיקות חקרניות
היתרונות העיקריים של אוטומציה של בדיקות חקרניות כוללים:
ביצוע בדיקה עקבי
טעות אנוש יכולה בקלות להוביל לטעויות בדיקה שלוקח זמן וכסף לתקן אותן; בדיקות חקר אוטומטיות מאפשרות לצוותי בדיקה לעקוף בעיה זו.
בודקים מלמדים ביעילות תוכנת אוטומציה כיצד לבצע נכון בדיקה, ומבטיחים שהיא מבצעת אותה באופן זהה בכל פעם. זה משפר את האמינות הכוללת של הבדיקות ומפחית את משך הזמן שמפתחים מבלים בהמתנה לתוצאות – במיוחד מכיוון שהבודקים יכולים להגדיר זאת כך שיפעל בן לילה בקלות.
חוסך זמן לכולם
בדיקות אוטומטיות מאפשרות למפתחים להתחיל לעבוד על תיקונים לבעיות הרבה יותר מהר ובמקביל מאפשרות לבודקים לכסות מגוון רחב יותר של בדיקות גישושים. יש רק כל כך הרבה תרחישים שהצוות יכול לתת עליהם את הדעת ללא קשר למועד האחרון שלהם, כלומר חשוב שהבודקים יתאימו כמה שיותר בדיקות למסגרת הזמן המותרת שלהם.
אוטומציה עוזרת על ידי ביצוע בדיקות חקירה אלה בקצב מהיר הרבה יותר מאשר בודקים ידניים.
גישה חסכונית
בהתאם לתוכנה שהצוות בוחר, אוטומציה עשויה להיות הרבה יותר חסכונית מאשר בדיקות ידניות – זה יכול אפילו להיות בחינם.
בעוד שבודקים ידניים עדיין קריטיים להעסקה וחלקם יהיו אחראים לכיול הליכי האוטומציה, אוטומציה של כמה שיותר בדיקות חקרניות נותנת לחברה הזדמנות להוזיל את עלויות הצוות.
לאחר שהצוות מבין את תוכנת האוטומציה, הם יכולים להתאים אותה למגוון רחב של משימות.
ניתן להתאמה למספר מכשירים
בדיקה ידנית עשויה לדרוש צוות עם ניסיון במכשירים שונים, כגון ידע במערכות הפעלה שונות לטלפונים, כולל אנדרואיד ו-iOS, אם בונים אפליקציה לנייד.
תוכנה אוטומטית יכולה להסביר זאת ולבדוק על פני התקנים מרובים כדי להבטיח שהאפליקציה יכולה לבצע ביצועים טובים באופן עקבי. צוותי בדיקה עם ידע במכשירים אלה יכולים למצוא את התהליך מייגע; אוטומציה מסוגלת שוב לייעל את תהליכי הבדיקה החקירה הרגילים ולבדוק כל איטרציה בו זמנית.
סקריפטים לשימוש חוזר
אם הצוות בודק מספר גרסאות של אותה תוכנה או אפילו מוצרים מרובים עם ארכיטקטורה או תכונות דומות, אפשר לעשות שימוש חוזר בסקריפטים ממחזור בדיקה אחד למשנהו.
אם יש התאמות כלשהן הנחוצות כדי להבטיח תאימות, בודקים ידניים יכולים לבצע אותן הרבה יותר מהר מאשר כתיבת סקריפט חדש לגמרי.
אוטומציה מייעלת כמעט כל שלב בתהליך הבדיקה החקרנית, קלה להגדרה לאורך תצורות תוכנה שונות.
2. אתגרים של אוטומציה של מבחני חקר
תהליך זה כרוך גם באתגרים שונים, כגון:
מייצג רק צד אחד של הבדיקה
זה לא מעשי או חכם להפוך כל בדיקה לאוטומטית בזמן בדיקת האפליקציה מכיוון שיש כמה היבטים שרק בודק ידני יכול לספק משוב אמין עליהם.
זה כולל את חווית המשתמש, אם כי ייתכן שניתן לקבל ניתוח ביצועים ובדיקת עומסים יסודיים באמצעות אוטומציה, בהתאם לתוכנה שתבחר.
אוטומציה של בדיקות חקר חסרת שיקול דעת אנושי ויכולה לעבוד בצורה הטובה ביותר לצד בודק ידני עבור כמה בדיקות.
ציפיות לא מציאותיות ליכולות
על פי קווים דומים, הליכי בדיקות חקרניות אוטומטיות יכולים לספק יתרונות עצומים ליישום לצד הפרויקט הכולל.
עם זאת, גישה זו היא לא תמיד התשובה. ארגונים שמסתמכים במידה רבה על אוטומציה בכל שלב יכולים לקבל פרספקטיבה לא מלאה של התוכנה.
אוטומציה מזהה בעיות אך צוותי הבדיקה והפיתוח אחראים לתיקון אותן. חשוב להגדיר אסטרטגיית אוטומציה כוללת כדי שכולם בפרויקט יבינו את היכולות והמגבלות שלו.
דרישות מיומנות גבוהות יותר
אוטומציה כרוכה בדרך כלל לדעת כיצד לבצע בדיקות מורכבות, לצד כיצד לתכנת ולמעשה להפוך אותן לאוטומטיות. זה מצריך לעתים קרובות שנים של ניסיון בסקריפטים, אם כי תוכנות אוטומציה יכולות לסייע באופטימיזציה משמעותית של תהליכים אלה.
זה קריטי שהחברה תגייס בודקים עם כישורים מגוונים וחסונים כדי לאפשר אוטומציה יעילה.
בודקים מנוסים באוטומציה יודעים גם את הפונקציות שיש לתעדף תוך בחירה מבין אפשרויות התוכנה הזמינות של צד שלישי, מה שמבטיח שהצוות יקבל מוצר טוב.
אסטרטגיות ותקשורת לא נאותים
העברת אסטרטגיה קוהרנטית היא חיונית לכל אוטומציה מוצלחת; מפתחים, בודקים ואפילו מנהלי פרויקטים חייבים להיות באותו עמוד לאורך כל הבדיקות.
הצוותים חייבים לעבוד יחד כדי לזהות את ההיקף ואת לוח הזמנים של ההליכים הקרובים שלהם. זה נכון לגבי כל תהליך בדיקה אבל הוא חיוני במיוחד בשל המורכבות הנוספת של אוטומציה. קווי תקשורת טובים יותר והיעדר ממגורות מידע מאפשרים לצוותים שלך לבצע את הבדיקות שלהם בצורה יעילה יותר.
בחירת תוכנת האוטומציה הנכונה
אוטומציה כרוכה בדרך כלל בבחירת אפליקציה של צד שלישי התואמת את יעדי הבדיקה של הצוות. לכל אפשרות יש תוכניות תמחור ופונקציונליות שונות. זו עשויה להיות הוצאה משמעותית לטווח ארוך, גם אם התוכנה מבצעת בהצלחה בדיקות אוטומטיות תוך מתן ערך משמעותי.
ישנן מספר אפשרויות חינמיות המציעות פונקציונליות מרשימה הדומה לחלופות פרימיום. זה חיוני שצוות הבדיקות יחקור את כל האפשרויות הזמינות, כולל תוכנה חופשית.
מסקנה: אוטומציה של בדיקות חקרניות לעומת בדיקות חקר ידניות
יש מעט פרויקטים שנהנים מבדיקה ידנית מלאה או מבדיקה אוטומטית לחלוטין, שכן יישומים מכל הסוגים מתפקדים טוב יותר עם שילוב של שניהם.
בעוד שבדיקות אוטומטיות יכולות לייעל את התהליך עבור צוותי הפיתוח והבטחת האיכות, חלק מההיבטים של התכנון דורשים בדיקות חקרניות ידניות; זו הדרך היחידה לקבל משוב מודע למשתמש.
עם הזמן, יותר ארגונים עובדים על הטמעת היפר-אוטומציה , תהליך שמטרתו למקסם אוטומציה בצורה חכמה, להבטיח שלעסק יש אסטרטגיה יעילה – זה עדיין יכול להתקיים לצד בדיקות ידניות.
בדיקות אוטומטיות הופכות נגישות יותר עבור חברות בשל השכיחות המוגברת של תוכנות אוטומציה, במיוחד עם מספר אפשרויות חינמיות זמינות עם שפע של תכונות. זה מקל על חברות לאמץ גישת בדיקות חקרניות ידניות/אוטומטיות משולבות.
הפופולריות ההולכת וגוברת של Agile (טכניקת ניהול פרויקטים המתמקדת בהתקדמות מצטברת אך משמעותית) בפיתוח גם היא גורם לכך שכן היא דורשת מחזורי בדיקה קצרים. אסטרטגיית בדיקה משולבת יכולה להתאים לאסטרטגיות התפתחותיות זו ואסטרטגיות התפתחות שונות אחרות, כגון אינטגרציה מתמשכת, אשר מחייבת באופן דומה בדיקות חוזרות על מנת להבטיח הצלחה לאורך איטרציות רבות של אותה תוכנה.
מה אתה צריך כדי להתחיל בדיקות חקרניות
התנאים המוקדמים של בדיקות חקרניות הם:
1. מטרות בדיקה ברורות
למרות שבדיקות חקרניות הן שם נרדף לחופש ולעיתים מבולבלות עם בדיקות אד-הוק, הן עדיין עוקבות אחר כללים ספציפיים או מטרות שניתן להגדיר. הדרך היחידה של צוות QA לנווט בהצלחה כמעט בכל מבנה בדיקה היא לדעת את התוצאה הצפויה של כל בדיקה, במיוחד מכיוון שהבודקים בדרך כלל מעצבים את הבדיקות הללו בעצמם.
2. בודקים יצירתיים ואינטואיטיביים
בדיקות חקר מתמקדות בעיצוב בדיקות חדשות ויצירתיות שעשויות לחשוף בעיות באפליקציה. אפילו בודקים עם ניסיון מוגבל יכולים לעשות זאת, בהנחה שהם מבינים את התוכנה.
חשוב שהבודקים יבינו את האפליקציה וכיצד היא פועלת; זה מאפשר להם לפתח באופן אינטואיטיבי מגוון של בדיקות שימושיות.
3. תיעוד קוהרנטי
לכל סוג של בדיקה חייב להיות תיעוד חזק כדי לוודא שכל חבר צוות עומד בלוח זמנים צפוי של בדיקות ושאף אחד לא יחזור על בדיקה בטעות.
זהו היבט חיוני בתקשורת בכל מחלקה בודדת ובכמה, כגון מפתחים הדורשים עדכוני בדיקה שוטפים כדי להבין כיצד לתקן בעיות.
4. נקודת מבט של לקוח
בדיקות גישוש מכסות אסטרטגיות ותרחישים רבים, כולל אלו המשקפים את האופן שבו המשתמשים יתקשרו בפועל עם האפליקציה. זה חיוני שצוותי הבדיקה יתייחסו לכך במהלך הבדיקות שלהם, גם אם הם לא עורכים בדיקות מבוססות תרחישים.
אימוץ זה מאפשר לבוחן לגשת לבדיקות מנקודות מבט שונות, ולשפר את איכות הבדיקות הללו.
5. תוכנת בדיקה אוטומטית
מכיוון שהצוות יכול לבצע אוטומציה של כמות ניכרת מהבדיקות שהם מעצבים, חשוב שיוכלו לרכוש תוכנת בדיקות אוטומטיות באיכות גבוהה לפני שלב הביצוע.
המפתחים וצוות הבדיקות יכולים להשתמש בהבנתם את הפרויקט כדי לקבוע את יישום הצד השלישי שיתאים לדרישות שלהם.
תהליך בדיקה חקרנית
השלבים הספציפיים לבדיקות חקרניות הם כדלקמן:
1. סיווג הליך הבדיקה
השלב הראשון של בדיקות חקר הוא שאנשי הצוות הרלוונטיים יבינו כיצד הם עשויים לגשת לבדיקות אלו, כגון על ידי סיווג תקלות נפוצות וביצוע ניתוח שורש.
זה המקום שבו הבוחנים מפתחים את הרעיונות שלהם למבחנים עצמם; בהתאם למתודולוגיה המדויקת שלהם, הם עשויים גם לעצב אמנת בדיקה.
זה קובע את ההיקף והמבחנים עבור אותו מפגש או יום עבודה.
2. התחל את המבחנים
בעוד שהפרמטרים המדויקים (כגון הזמן לכל מבחן או מפגש כולל) תלויים בהעדפות הצוות עצמו ובדרישות הפרויקט, כל החוקרים עוקבים אחר מאפיינים משותפים מסוימים.
עם סיווג הבדיקות הרלוונטיות, צוות אבטחת האיכות מתחיל לבצע את הבדיקות ולרשום כל תוצאות.
אם הבדיקות דורשות אוטומציה, הבודקים יכולים להגדיר זאת כך שיעבוד בן לילה או לפקח על כך בעצמם במהלך היום.
3. סקור את התוצאות
השלב הבא הוא סקירת התוצאות, השוואתן מול ברירת המחדל והתוצאות הצפויות. אם בדיקות אלו יגרמו לסטיות בלתי צפויות משמעותיות מכל סוג שהוא, הבודקים יוכלו לחזור על הבדיקה או להתחיל מיד להבין כיצד לתקן זאת. ההצעות שהם מגישים למפתחים עשויות להועיל בקביעת הגישה הנכונה לנקוט – ודוחות הבאגים שלהם יכולים לפרט זאת בפירוט.
4. תחקיר המבחן
לאחר מכירה פומבית של תוצאות הבדיקה, צוות אבטחת האיכות מתחיל לסקור את הליך הבדיקה עצמו ומשתמש בו כדי לקבוע אם גישת הבדיקה החקרנית שלהם הייתה מתאימה.
דוח סיכום בדיקה זה עשוי אפילו להסיק שהיו טעויות תפעוליות במהלך הבדיקות הדורשות בדיקה חוזרת. צוות הבדיקה עשוי גם לבדוק את האפליקציה שוב לאחר שהמפתחים יתקנו את הבעיות הללו כדי לקבוע אם הן הצליחו.
שיטות עבודה מומלצות לבדיקות חקרניות
הפרקטיקות היעילות ביותר לבדיקות חקר כוללות:
1. זיווג בודקים
צורות רבות של בדיקות חקר מרוויחות מהבודקים שעובדים יחד – זה מייעל את התהליך עוד יותר ומאפשר נקודות מבט מרובות של אותן בדיקות.
בדיקת זוג גם מונעת את האפשרות של ראיית מנהרה, ומעודדת עיצוב בדיקות יצירתי יותר.
מספר אנשים שעובדים על אותם מבחנים עשויים להוביל לדיוק רב יותר בכל רחבי הלוח, ופיצול עומס העבודה גם עוזר להפוך את הבדיקות למהיר הרבה יותר עבור כל הצוות.
2. ערבוב בדיקות ידניות ואוטומטיות
חברות מסוימות עדיין נאבקות לאמץ אוטומציה בעוד שאחרות משתמשות בה יתר על המידה, גם כאשר פרספקטיבות ידניות עשויות להיות מועילות יותר. איזון הבדיקות הללו יחד מאפשר לצוות הבדיקות לכסות יותר בסיסים ולהבטיח איכות בכל האפליקציה, כולל להיבטים סובייקטיביים יותר כמו ממשק התוכנה.
ביצוע בדיקות ידניות ואוטומטיות יחד הוא הדרך היחידה להבטיח כיסוי בדיקה מלא של כל תכונה או פונקציה.
3. להבין את השוק
חשוב שהבודקים יכירו גם את קהל היעד שלהם וגם את המתחרים במהלך תהליך הבדיקה; זה עוזר להם להעריך כיצד סביר להניח שאנשים יגיבו לפונקציונליות הנוכחית של האפליקציה.
לתכונות מסוימות יש ביקוש גבוה, וצוות הבדיקות יכול להפיק תועלת מתעדוף אלה במהלך הבדיקות. אם כי עליהם לשמור גם על כיסוי מבחן רחב. זה יכול לקבוע את הכיוון לבדיקה לצד הצלחתה הפוטנציאלית של התוכנה בהשקה.
4. השתמש במכשירים אמיתיים לבדיקה
צוותי בדיקות תוכנה עשויים לעשות שימוש באמולטורים כדי להקל על הבדיקות החקרניות שלהם; זה יכול להיות שימושי אבל רק לעתים רחוקות משקף סביבת משתמש מעשית.
מכשירים אמיתיים עוזרים לשפר את האמינות של בדיקות חקרניות על ידי יצירת חוויה מציאותית יותר – אמולטורים אינם מושלמים ועשויים להכיל שגיאות שאינן קיימות עבור הלקוחות.
אמולציה היא דרך מהירה לבדוק פלטפורמות מרובות, אך היא אינה מהווה תחליף למכשירים בפועל.
סוגי תפוקות ממבחן חקר
ישנם פלטים שונים שהבודקים יכולים לקבל לאחר ביצוע בדיקה, כולל:
1. תוצאות הבדיקה
התוצאות עצמן לובשות צורות רבות שכן בדיקות חקרניות יכולות לכלול מאות בדיקות ייחודיות. תוצאות אלו מהוות את רוב התפוקות של שגרת בדיקות, ומציעות מידע חיוני על מצב האפליקציה והיכולת שלה לספק את צרכי המשתמש.
הבודקים יכלו לבדוק מחדש את המערכת ולאמת את המידע עם קבלת התוצאות הללו כדי לקבוע את הפעולה הבאה שלהם.
2. יומני בדיקה
היומנים של יישום עצמו חושפים לעתים קרובות שגיאות ובעיות במהלך תהליך הבדיקה; אלה מספקים את הרמזים החזקים ביותר מדוע התוכנה נכשלה במבחן. בודקים בכירים מיומנים במיוחד בפירוש יומני אפליקציה, ומאפשרים להם לזהות את הגורם לבעיות מסובכות.
ככל שבוחני מידע יאספו יותר מהיומנים הללו, כך הם יוכלו לעזור למפתחים.
3. דוחות בדיקה
בהתאם לנוהל האוטומציה של הצוות, הפלטים שלהם עשויים ליצור דוח באגים באופן אוטומטי. זה מפרט את כל השגיאות הקיימות באפליקציה, אולי כולל את הסיבות שלהן וכל מידע אחר הרלוונטי למפתחים.
הבודקים עשויים להשתמש בזה כדי להציע דעה משלהם אם התוכנה מוכנה להשקה, מה שידוע בדרך כלל כהחלטה ללכת/לא ללכת.
דוגמאות לבדיקות חקרניות
להלן שלוש דוגמאות לאופן שבו חברה יכולה להשתמש בבדיקות חקרניות:
1. אפליקציית גיימינג לנייד
אם חברת משחקים מעוניינת לשחרר עדכון גדול עבור אפליקציה לנייד, בודקים חוקרים יכולים לבדוק גם תכונות ישנות וגם חדשות כדי לקבוע אם האפליקציה עדיין יציבה. זה עשוי להגביר את מורכבות התוכנה עד כדי כך שהיא לא מצליחה לפעול במכשירים מסוימים.
בודקים פועלים כדי למזער את ההשפעות של זה תוך הבטחת שימושיות על פני כמה שיותר פלטפורמות.
בודקים חוקרים בודקים היטב את המשחק ואת התרחישים המסובכים הרבים שלו כדי להבטיח שכל פונקציה פועלת כמתוכנן; תהליך זה דורש בדרך כלל בודק ידני.
2. אתר אינטרנט של ספק שירות
אתרי אינטרנט עוברים גם בדיקות גישושים כדי לוודא שהם עובדים הן עבור המשתמשים והן עבור הצוות, כך שהבודקים עשויים להתחיל בכניסה לאתר. זה בודק את יכולת האתר ליצור פרופילי משתמשים חדשים ובודק שמשתמשים אינם יכולים לגשת לפונקציות ניהוליות.
לאחר מכן הבודקים מתקדמים לבדיקת השירות שיכולה להיות בצורת הזמנת תור או ביצוע הזמנה. לאחר מכן הם ישלימו את הרכישה כדי לוודא שהקופה מתפקדת כראוי, ולאחר מכן עיון באישור הדוא”ל של ההזמנה ובהיסטוריה של החשבון.
3. מערכת ניהול בית חולים
יישומים ומערכות מכל הסוגים יכולים להפיק תועלת מבדיקות חקרניות. עבור מערכות ניהול בתי חולים, בודק עשוי לבדוק כיצד מודול התשלום מתקשר עם תכונות אחרות.
רמות גבוהות יותר של אינטגרציה עשויות להוביל לשגיאות משמעותיות ללא בדיקות קפדניות. בדיקות אלו יכולות לכלול דיאגרמה ארכיטקטונית העוקבת אחר מרכיבי המערכת הרבים והאופן שבו הם מצטלבים.
בודקים גם בוחנים את הבעיות באיטרציות הקודמות של המערכת ובודקים באופן ספציפי כדי לראות אם אלה עדיין קיימות, תוך ביצוע פעולה מהירה אם הם חושפים שגיאות כלשהן.
סוגי שגיאות ובאגים שזוהו באמצעות בדיקות חקרניות
שגיאות שבודקים עשויים לחשוף במהלך בדיקות חקר כוללות:
1. תכונות לא תואמות
פונקציות מסוימות באפליקציה עשויות שלא לקיים אינטראקציה זו עם זו כצפוי – מה שעלול להוביל לכך שמשתמשים לא יוכלו להשלים רכישות או להשתמש באפליקציה. בודקים בודקים את הפונקציות בבידוד ובמקביל זה לזה כדי לוודא שהכל מתאים זה לזה.
2. עיצוב ממשק משתמש לא תקין
ממשק המשתמש של אפליקציה קובע בדיוק איך מישהו משתמש בתוכנה. לדוגמה, אם תכונות חשובות אינן גלויות ללקוחות, ייתכן שהם לא יבחינו בתכונות אלו קיימות, מה שמגביל את ההנאה שלהם מהאפליקציה.
בדיקת ממשק משתמש ידנית מזהה ומתקנת עיצוב לא ידידותי למשתמש.
3. שגיאות אימות
יישומים ואתרים רבים מאפשרים יצירת פרופיל משתמש עם הרשאות מסוימות. זה חיוני שהבודקים יבדקו אם משתמשים ממוצעים יכולים איכשהו לגשת לנתונים רגישים או אפילו לתכונות ניהול תוך שימוש בתוכנה בדרכים בלתי צפויות.
4. קוד מת
בודקים עשויים למצוא קוד מיושן שעדיין קיים בתוך האפליקציה, מה שעשוי אפילו להיות הגורם לבעיות ביצועים בולטות. קוד מת מסבך יתר על המידה את פעולתו הפנימית של היישום ועלול לגרום לשגיאות הניתנות להימנעות. זיהוי ואופטימיזציה של זה הופכים את התוכנה למגיבה יותר עבור הצוות והמשתמשים.
מדדי בדיקות חקר נפוצות
המדדים הרגילים שהבודקים עלולים להיתקל בהם במהלך הבדיקות החקרניות שלהם כוללים:
1. מדדי בדיקת ביצועים
מבחנים גישושים אשר בוחנים את הביצועים הכלליים של אפליקציה יכולים לגרום למגוון רחב של מדדים. זה יכול לכלול זמני תגובה מינימליים, ממוצעים ומקסימליים לצד כישלון ושיעורי הצלחה לקביעת יציבות.
2. בדיקת מדדי כיסוי
כיסוי המבחן חשוב מכיוון שהוא קובע כמה קטגוריות והיבטים של יישום הבדיקות מקיפות. אחוז כיסוי דרישות, למשל, מעריך אם יש פונקציות שדורשות סבבי בדיקה נוספים.
3. יעילות בדיקה כוללת
מעקב אחר מספר הבדיקות המוצלחות והנכשלות עוזר לבודקים להבין את המצב הכללי של אפליקציה. נוסף על כך, הצוות יכול לעקוב אחר כמה מהשגיאות שהם מזהים הן קריטיות.
4. הפצת ליקויים
לאורך קווים דומים, בדיקת התפלגות הפגמים מציגה את הרכיבים או הפונקציות הרגישות ביותר לשגיאות. אלה עשויים להיות חלקים מהאפליקציה שלעתים קרובות מקיימים אינטראקציה עם אחרים, מה שהופך את זה חיוני לתעדף בדיקות אלה.
5. מדדי רגרסיה
בדיקות רגרסיה חקרניות מאפשרות לבודקים לראות כיצד איטרציות שונות של אותה תוכנה מתנהגות וכיצד זה יכול להשפיע על הביצועים.
שיעור הזרקת פגמים ופגמים לכל מבנה הם המדדים הספציפיים שעוזרים בכך.
ניקוי בלבול מסוים: בדיקות חקרניות לעומת בדיקות אד-הוק
עם התמקדות חזקה בחופש הבוחנים, חלק מהאנשים מבלבלים לעתים קרובות בין בדיקות גישושים לבדיקות אד-הוק. שני הפורמטים חולקים מספר קווי דמיון מרכזיים אך בסופו של דבר משרתים מטרות שונות.
1. מה זה בדיקות אד הוק?
בדיקות אד-הוק הן גישה בלתי מובנית לחלוטין, אשר שוברת את התכנון המקובל של הבדיקות כדי למצוא פגמים שאחרת עלולים לא להופיע.
צורה זו של בדיקה בדרך כלל אינה כרוכה בתיעוד, מה שמקשה על שחזור בעיות אלא אם הבוחן בטוח לחלוטין בגורם.
אחת הדוגמאות לכך היא ‘בדיקת קופים’, בדיקה שכוללת תשומות אקראיות ומטרתה בסופו של דבר לשבור את המערכת.
בדומה לבדיקות חקרניות, בודקים אד-הוק רבים עובדים כזוגות כדי להשלים את הבדיקות הללו; זה משפר את האמינות שלהם. גישה אד-הוק יכולה להיות שימושית לאחר ביצוע בדיקה רשמית כדי לוודא שהצ’קים מתייחסים לכל אפשרות; זה עוזר גם כאשר יש זמן מוגבל לבצע בדיקות נוספות. עם ביצוע נכון, בדיקות אד-הוק מועילות מאוד.
2. הבדלים בין בדיקות חקרניות לבדיקות אד-הוק
בדיקות אד-הוק אינן כוללות בדרך כלל תיעוד רשמי. זאת בניגוד חריף למבחנים גישושים שבהם האופי המאולתר של בדיקות אלו הופך את שמירת הרישומים לחשובה עוד יותר.
בדיקות גישוש משתמשות במגוון גדול יותר של טכניקות בדיקה פורמליות בעוד שבדיקות אד-הוק נמנעות מכך על ידי הסתכלות מחוץ לכללי הבדיקה המקובלים. זה עוזר להם לחשוף באגים שהבודקים לא היו מוצאים.
לבדיקות חקרניות יש מטרות וגבולות ברורים אך עדיין מאפשרת לחברי הצוות להשתמש במבחנים יצירתיים. למבחנים אד-הוק אין בדרך כלל יעדי קצה ניתנים להגדרה מעבר לדחיפת התוכנה איך שהיא יכולה. בדיקות אד-הוק כרוכות לרוב גם בידע קיים של התוכנה ותפקודיה, בעוד שבדיקות חקרניות משלבות את למידת האפליקציה בתהליכים הרגילים שלה.
בדיקות חקרניות בזריזות
מתודולוגיה זריזה מקדמת מאוד שיפור מתמיד. פירוש הדבר שהוא משתלב היטב עם בדיקות גישושים, במיוחד כשהביקוש גדל לעדכוני תוכנה תכופים.
שילוב של בדיקות חקרניות עם Agile יכול להעניק לחברי הצוות מבנה בדיקות חזק יותר על ידי שילוב תכנון שחרור וביצוע ספרינט לאורך לוחות הזמנים שלהם. חברה המאמצת טכניקות Agile יכולה לנצל זאת עוד יותר על ידי שילוב זה עם בדיקות חקרניות; זוהי דרך מצוינת לבדוק כל רכיב תוכנה בנפרד של יישום. מכיוון שבודקים עשויים לבצע בדיקות גישושים ללא סקריפטים, הדבר חוסך הן לצוות אבטחת האיכות והן למפתחים זמן יקר.
בדיקות חקרניות אוטומטיות מרכיבות את החיסכון הללו, ועוזרת לחברות לבדוק את האיטרציות האחרונות של היישום שלהן הרבה יותר מהר, אולי בן לילה. בדיקות חקר מספקות תוצאות מהירות ושמישות, והמפתחים יכולים לפעול על כל השינויים הדרושים כחלק מהספרינט הבא שלהם.
בדיקות חקר ידניות עדיין מציעות יתרונות רבים בשילוב עם Agile בשל יכולתה לזהות בעיות שגישה אוטומטית עלולה להחמיץ. צורות אחרות של בדיקות פשוט נמשכות זמן רב מדי או מספקות מעט מדי יתרונות כדי להתאים בנוחות במסגרת Agile. בדיקות גישושים יכולות לוודא שכל שלב Agile משפר משמעותית את התוכנה ואת הפונקציונליות שלה.
7 טעויות ומלכודות שכדאי להימנע מהם ביישום בדיקות גישוש
להלן שבע טעויות נפוצות שחברות עושות לעתים קרובות בזמן יישום בדיקות גישוש, לצד הדרך שבה חברות יכולות להימנע מבעיות אלו:
1. בדיקות ידניות/אוטומציה לא מאוזנות
להבין את הבדיקות שעובדות הכי טוב עם בדיקות ידניות ואילו מהן ירוויחו מאוטומציה לוקחת זמן אבל מאפשרת לצוותים לבדוק ביעילות רבה יותר.
אוטומציה של יותר מדי בדיקות עשויה לגרום לאפליקציה לא מנוהלת או לא ידידותית למשתמש בגלל היעדר בודק אנושי.
2. אילוצי זמן
בדיקות חקר מהירות יותר מצורות רבות אחרות של בדיקות, אך המציאות של מועדי פרויקט פירושה שעדיין יש מגבלות למספר הבדיקות שהצוות יכול לבצע.
ניהול זמן ומחויבות לכיסוי בדיקות עוזרים לצוות הבדיקות לבצע כמה שיותר בדיקות בקטגוריות רחבות רבות.
3. בודקים לא גמישים
בעוד שבודקים חקרניים אינם דורשים ידע קיים בתוכנה או מיומנויות מעמיקות במיוחד, הבדיקות עדיין מסתמכות על היכולות והיוזמה של חברי צוות בודדים.
על מנהל הפרויקט להקצות את תפקידי הבדיקה הללו בחוכמה, ולשמור אותם לחברים יצירתיים ואינטואיטיביים יותר בצוות במידת הצורך.
4. קושי לשחזר כשלים
לא תמיד ברור אילו פעולות תורמות לכישלון במבחן; יכול להיות גם לא ברור אילו היבטים של הבקשה אשמים.
זו הסיבה שהרבה גישות חקירה כוללות זיווג של בודקים יחד או אפילו הקלטה ישירה של מסך של בודק כדי לקבל הבנה ברורה יותר של הבעיות והסיבות המדויקות שלהן.
5. תיעוד לא ברור
בין אם מדובר בדוח באג אוטומטי או ברישום ידני של הבדיקות שהושלמו, תיעוד טוב מקל על המפתחים לפעול בהתאם לממצאי צוות הבדיקות.
צוות הבדיקה חייב להתחייב להבטיח שמירה באיכות גבוהה לאורך כל בדיקה בודדת, ולהציע פרטים רבים ככל האפשר לכל דוח.
6. ציפיות גבוהות
בדיקות חקר מועילות כמעט לכל פרויקט תוכנה אך עדיין מוגבלות בהיקפו – הן פועלות בצורה הטובה ביותר בשילוב עם שיטות בדיקה אחרות.
צוותי הבדיקה חייבים לבצע את הבדיקות הללו לצד בדיקות התסריט הרגילות; זו הדרך היחידה שבה מחלקות אבטחת איכות יכולות להבטיח כיסוי בדיקות רחב באופן עקבי.
7. אוטומציה לא נכונה
חשוב שצוות הבדיקות ומנהל הפרויקט יבינו איזו תוכנת אוטומציה מספקת את היתרונות הרבים ביותר עבור היישום המסוים הזה.
אפשרויות שונות של צד שלישי מציעות תכונות ייחודיות משלהן, כך שהבחירה של הצוות עשויה לקבוע את הצלחת האוטומציה הרובוטית של התהליך ; הם חייבים לשקול כל אפשרות העומדת בפניהם.
5 כלי הבדיקה החקרניים הטובים ביותר בחינם
חמשת כלי הבדיקה החקרניים הטובים ביותר שצוותי אבטחת האיכות יכולים להשתמש בהם בחינם כוללים:
1. ZAPTEST FREE Edition
ZAPTEST Free מספק פונקציונליות ברמת פרימיום בעלות אפסית לחלוטין, מה שמאפשר לכל ארגון להפיק תועלת מיישום בדיקות חקרניות קלות.
יישום זה יכול להפוך כל פלטפורמה, מכשיר ודפדפן לאוטומטי עם טכנולוגיית 1SCRIPT חדשנית.
ZAPTEST מספקת גם אוטומציה גמישה של RPA, המאפשרת לך לשלב זאת עם גישה ידנית.
2. אפליקציית חקר XRAY
XEA מאפשרת למשתמשים ליצור אמנת בדיקה מקיפה ולתעד בקלות את ההתקדמות שלהם, מה שמייעל את שלב דיווח הבאגים של בדיקות חקרניות.
אפשרות זו מתמקדת לחלוטין בפרספקטיבה של המשתמש ומציעה מרכז תוצאות מרכזי לעדכון בודקים אחרים.
עם זאת, ל-XRAY אין כרגע אוטומציה משולבת, מה שעלול להגביל את יעילותה לטווח ארוך.
3. באג מגנט
תוסף דפדפן המציע בדיקות חקירה יסודיות, Bug Magnet מאפשר לבודקים לבדוק מקרי קצה וערכים בעייתיים אחרים.
הרחבה זו מספקת גם אינטגרציה פשוטה של טקסט דמה, כתובות דוא”ל וקבוצות תווים מרובות.
עם זאת, זה זמין רק עבור דפדפנים מבוססי פיירפוקס וכרום, מה שהופך אותו לבחירה פחות תכליתית מהמתחרים שלו.
4. תכניות בדיקה של תכלת
Azure Test Plans היא חלק מרכזי בפלטפורמת Azure של מיקרוסופט ומאפשרת לבודקים ללכוד נתונים עשירים בתרחישים רבים.
אפשרות זו מתאימה הן ליישומים שולחניים והן ליישומים מבוססי אינטרנט תוך מתן מעקב מקצה לקצה שיש לו תיעוד ברור של התפתחות התוכנה.
עם זאת, גישה זו דורשת לעתים קרובות אינטגרציה עמוקה יותר עם Azure, ומכאן שהיא באה במחיר של גמישות.
5. עדות
Testiny מתמחה בבדיקות חקרניות ידניות, ומציעה עורך חכם המאפשר לבודקים לעצב צ’קים באמצעות מבנה עץ לגמישות מרבית.
כל שינוי בהרצה או במקרה בדיקה נשאר בהיסטוריה של האפליקציה כדי להבטיח אחריות מלאה ועקיבות.
עם זאת, זה בחינם רק עבור צוותים קטנים ופרויקטים בקוד פתוח.
מתי כדאי להשתמש בכלי בדיקות חקירה ארגוניות לעומת בחינם?
בעוד שבדיקות גישושים הן השקעה משתלמת ויישומי פרימיום בדרך כלל מציעים פונקציונליות רבה יותר, ישנן אפשרויות חינמיות רבות המספקות די והותר תכונות.
בדיקות חקר יכולות להיות הוצאה תפעולית משמעותית אם אתה מתחייב למודל פרימיום, אבל לא לכל חברת פיתוח תוכנה או צוות יש את הכסף לכך. בחירת התוכנה הטובה ביותר של צד שלישי תלויה לרוב בדרישות הספציפיות של החברה.
פתרון בתשלום עשוי להיות הדרך היחידה לספק את הצרכים של אותו פרויקט; הצוות חייב לחקור את הבחירות השונות לפני שהם מתחייבים לבקשה.
חברות עם צוותים קטנים יותר עשויות להפיק את המרב מכלי בדיקה חינמיים מכיוון שרבות מהאפשרויות הן בחינם למספר מוגבל של משתמשים.
לחלופין, הם עשויים לבחור אפשרויות ללא הגבלה זו וכאלה שיכולות להתאים לקנה המידה של צוות הבדיקה. זה יכול להפוך את זה אפילו יותר כדאי להתאים בודקים גישושים כדי להבטיח תוצאות מדויקות יותר – הצוות ידרוש באופן טבעי פחות פרופילי משתמשים.
שירותים רבים מציעים ניסיון חינם של התוכנה שלהם כדי שארגונים יוכלו לראות אם היא עונה על הצרכים שלהם; אלה בדרך כלל נמשכים רק כמה שבועות.
רשימת בדיקות גישוש, טיפים וטריקים
ישנם טיפים רבים נוספים שהבודקים יכולים לתת עליהם את הדעת כשהם מתחילים את הבדיקות החקרניות שלהם, כולל:
1. חלקו את התכונות והמודולים בצורה מתאימה
כדי למנוע תקשורת שגויה, צוותי הבדיקה צריכים להכין רשימה ברורה של כל תכונה והבדיקות שהם מתכוונים להפעיל. משמעות הדבר היא גם להבטיח שהבדיקות מפוזרות כראוי בין פונקציות התוכנה.
לקבלת התוצאות הטובות ביותר, חשוב ביותר שצוות הבדיקות ינהל משא ומתן אילו חברים יערכו כל מבחן בהתבסס על הכישורים והחוזקות שלהם.
2. עבדו להבנת התוכנה
שלב הלמידה הוא חלק קריטי בבדיקות חקרניות. משמעות הדבר היא שהבודקים חייבים לעסוק באופן פעיל בתוכנה ולהבין כיצד היא פועלת לפני שהם מתכננים בדיקות.
למידה על פעולתה הפנימית של תוכנה זו יכולה להיות תהליך שיתופי, המבטיח הבנה גדולה יותר בכל הצוות. זה מאפשר לבודקים לפתח בדיקות ומקרי בדיקה טובים יותר.
3. להבין אזורים בעייתיים
לכל אפליקציה יש תכונות או רכיבים שמצטלבים עם אחרים. ככל שהתוכנה הולכת וגדלה מורכבת, סביר יותר לפתח שגיאות; זה עשוי לדרוש בדיקות נוספות. הצוות חייב לעבוד באופן אקטיבי כדי להבין אילו רכיבים זקוקים לעזרה נוספת.
הם עשויים להפעיל סיורי בדיקה ספציפיים המשקפים בצורה הטובה ביותר את צרכי האפליקציה ואת סדרי העדיפויות הכוללים של הצוות.
4. התחל בתרחישי משתמש בסיסיים
צוותי אבטחת איכות יכולים לערוך בדיקות גישושים בכל סדר, במידת הצורך, אבל אולי יהיה מועיל יותר להתחיל עם בדיקות קלות יותר לפני התעמקות בתכונות מסובכות יותר.
זה מאפשר התקדמות חלקה מבחינת המורכבות, מה שנותן לבודקים הזדמנות להבין את התוכנה. זה גם עוזר לבדוק אם התכונות הבסיסיות פועלות כמצופה.
5. צמד בודקים יחד
בדיקות חקרניות משולבות מייעלות ומאמתות את שלב הבטחת האיכות, ומאפשרות לבודקים לעבוד בביטחון מוחלט בכל בדיקה. שיתוף פעולה הופך כל צורה של בדיקה ליעילה יותר על ידי שיפור ההיכרות של כל חבר צוות עם התוכנה.
הם יכולים גם לספק דוחות באגים עם הרבה יותר עומק בשל נקודות המבט האישיות שלהם, לתת למפתחים יותר מידע לעבוד איתו.
6. הפעל מספר בדיקות
יכולת הצוות לבחון מחדש בקשה תלויה בלוח הזמנים ובמועדים הצפויים להם. אבל אם זה אפשרי, בדיקה כפולה של רכיבים בעייתיים במיוחד עשויה להיות שימושית.
נוסף על כך, בדיקות חוזרות יכולות לאמת שבעיה שזוהתה בעבר תוקנה כעת ולא תשפיע יותר על התוכנה. חריצות זו נחוצה לפעמים כדי לוודא שהבדיקה מוצלחת.
סיכום
לבדיקות גישוש יש הרבה מה להציע לחברות פיתוח תוכנה מכל הסוגים, הפועלות כהשלמה לבדיקות תסריט ובדיקות רבות אחרות.
בעזרת בדיקות גישושים, צוותי אבטחת איכות עשויים לבדוק יישומים בסטנדרט גבוה יותר, לשפר את איכות התוכנה הסופית ולעזור למפתחים לתקן שגיאות אם הן קיימות.
שילוב של בדיקות חקר ידניות ואוטומטיות יכול להבטיח את מירב היתרונות, ולאפשר תשומת לב שווה לכל רכיבי התוכנה.
אם החברה שלך דורשת תוכנת אוטומציה חקרנית, ZAPTEST FREE Edition מציעה פונקציונליות רחבה וגמישה הרבה יותר מיישומי פרימיום אחרים, ומאפשרת לבודקים לייעל את הבדיקות הללו בקלות.
שאלות נפוצות ומשאבים
1. הקורסים הטובים ביותר בנושא אוטומציה של מבחן חקר
גם בודקים חדשים ומנוסים יכולים להפיק תועלת מקורסים לשיפור כישוריהם. זה כולל להבין איך לגשת לתוכנה חדשה.
קורסים שימושיים שיכולים לעזור בכך כוללים:
• Bootcamp לבדיקות תוכנה של Udemy לשנת 2023; זה מלמד בדיקות תוכנה רחבות לאורך 28 שעות.
• בדיקות חקירה של Coveros; זה מתמקד כיצד לפתח אמנות וליישם בדיקות גישושים על ממשקי API.
• הכשרת בדיקות גישוש של Polteq של יומיים; זה בוחן איך מבחנים גישושים עובדים בהקשר אג’ייל.
• בדיקות חקירה של לינקדאין; זה מראה כיצד בדיקות תוכנה מודרניות אימצו בדיקות חקרניות.
• המבוא של Coursera לבדיקות תוכנה; זה עוזר לבודקים הראשונים להבין את ההליכים האופייניים.
2. מהן 5 שאלות הראיון המובילות בנושא בדיקות חקרניות?
כאשר מתראיינים לתפקידי בדיקה גישושים, חשוב שמנהלים מגייסים ישאלו שאלות טובות כדי להעריך במדויק את כישוריו וניסיונו של המועמד.
חמש השאלות המובילות לשאול הן:
• כולל התאמתם, מהם ההבדלים העיקריים בין בדיקות תסריטאיות לבדיקות חקרניות?
• באילו אתגרים נתקלת כבוחן חקרני וכיצד התגברת עליהם?
• תן דוגמאות של בדיקות חקרניות שיועילו הכי הרבה מאוטומציה רובוטית של תהליכים.
• לדעתך, מהי המיומנות המשמעותית ביותר (טכנית או אחרת) עבור בודק חקרני?
• איזו עצה היית נותן לבוחן שמתקשה להבין את התוכנה וכיצד לבדוק זאת?
3. מדריכי YouTube הטובים ביותר על בדיקות גישוש
ישנם מדריכים חינמיים רבים זמינים באתרי שיתוף וידאו כגון YouTube, שיכולים לעזור לבודקים פוטנציאליים להבין את עקרונות הליבה שלו. חלקם מהווים חלק מסדרה בעוד שאחרים הם צלילות עמוקות בווידאו בודד לתוך הנושא.
ערוצים המציעים מדריכים אלה כוללים:
• האקדמיה לבדיקות, מספקת מאות סרטונים המכסים כל היבט של בדיקות תוכנה.
• Software Testing Mentor, שמציע באופן דומה סרטונים נרחבים על יסודות בדיקות תוכנה.
• QAFox, המספקת גם דוגמאות מהעולם האמיתי ופרויקטים חיים כדי להשלים את כל הסרטונים שלהם.
• SDET-QA Automation Techie, שיש לו כמה סרטונים מקיפים על גישות בדיקה שונות.
• GlitchITSystem, אשר בוחנת אתרי אינטרנט שונים עם בדיקות חקרניות כדי לנסות לחשוף תקלות.
4. כיצד לשמור על בדיקות גישוש?
בדיקות חקירה מבוצעות היטב כוללות תיעוד חזק שמפתחים ובודקים עתידיים מפנים אליו עבור איטרציות חדשות יותר של התוכנה.
כאשר יש עדכונים משמעותיים לאפליקציה, יש צורך בבדיקה חוזרת של הפונקציות העיקריות שלו כדי להבטיח שלתוספות אלו אין השפעות שליליות על תכונות קיימות.
זו הדרך היחידה להבטיח שהבדיקות החקרניות יישארו מוצלחות לאורך זמן. זה גם עוזר לקחת בחשבון תוכניות עתידיות כמו תכונות ראשוניות בעת תכנון האפליקציה המקורית והבדיקות שלה.
צוות QA חייב לתכנן כראוי את הבדיקות הללו ולהבין מתי לבדוק מחדש את היישום; כלי בדיקה אוטומטיים יכולים לעזור לצוות בכך.
5. האם בדיקות חקרניות נבדקות בקופסה שחורה?
בדיקות חקר דומות מאוד לבדיקת קופסה שחורה, המתייחסת לבדיקת אפליקציה על ידי התבוננות בתכונות שלה מבלי לבדוק ישירות את הקוד.
אין הגבלה מפורשת לסוגי הבדיקות הנכללות בבדיקות חקרניות; גישה זו עשויה להקיף כל היבט של התוכנה, כולל הקוד.
אחד מנקודות הדמיון המרכזיות בין שני סוגי הבדיקות הללו הוא חוסר הידע של הבוחן מראש. בוחני Black-box בדרך כלל לא מכירים את התוכנה לפני שהם בודקים אותה ובוחנים חוקרים לומדים כיצד התוכנה פועלת כחלק מהבחינה הראשונית שלהם.
בעוד שבדיקות חקרניות באופן כללי לא תמיד מסווגות כבדיקת קופסה שחורה, זה נכון שיש כמות משמעותית של הצלבה בין שתי הגישות הללו.
