גם לאחר שהוחלט באיזו שיטה לבדוק את המוצר, עדיין קיימות קבוצות של בדיקות שיש לבחור מהן איזו לבצע.
ההחלטה יכולה להיות מבוססת על אילוצים כמו כמות הזמן שנותרה לבדיקות או טיבו של המוצר עצמו. כך למשל, תוכנה שנמצאת בשלבי פיתוח ראשוניים ולא יציבה מספיק, תקבל העדפה לסוגי בדיקות בסיסיות יותר ורק לאחר שהתוכנה תתקדם לשלבי בשלות מאוחרים, יבחרו לבדוק אותה דרך סוגי בדיקות מעמיקות יותר.
Sanity Test
בדיקת שפיות. סט של בדיקות שיכול להיות מחזור שלם של בדיקות שנועד לבדוק בצורה כללית את איכות התוכנה ובעיקר לתת תשובה מהירה, גם אם לא מדוייקת לגבי אמינות ויציבות התוכנה בעיקר בתפקודים המרכזיים שלה.
Full Cycle Test
סט בדיקות שלם שנועד לעבור ביסודיות על כל פונקציונליות התוכנה. בגלל אורכו ועומס הבדיקות, סט הבדיקות יבוצע בהעדפה רק אחת לתקופה ולא כשגרה, בעיקר כאשר מדובר בתוכנה שעדיין לא שלמה או לא מספיק בשלה (mature)
Smoke Test
המינוח מגיע מעולם האלקטרוניקה, שם לאחר הרכבת המוצר, נדרשת בדיקה כללית רק כדי לבדוק שאין קצר ו / או שהוא אינו מעלה עשן. סט בדיקות מצומצם ביותר שנועד לבדוק ברמה הכללית האם לתוכנה "יש דופק" או שהיא DOA.
Unit Test
בדיקה שעורך לרוב המתכנת בצד שלו כדי לוודא שברמה הפשוטה, הקוד שכתב או ששינה עובד כפי שהוא מצפה. מדובר בתרחישים נאיביים וממוקדים מאד ובכל מקרה אינם תורמים מידע למחזור הבדיקות הכללי שיתבצע ע"י ה-QA.
System Test
בדיקת המוצר כמכלול, על כל חלקיו והמודולים שלו. המטרה בבדיקות אלה היא לבדוק את התפקוד הכולל של המוצר כיחידה אחת, בניגוד ל- Unit Test שמתמקדת בחלק ספציפי וקטן בתוכנה.
Differential Test
בדיקות שמריצות את אותם טסטים של מוצרים דומים, לרוב מדובר באותו מוצר בגירסאות שונות על מנת למצוא את ההבדלים ו / או הרגרסיה בין שתי הגרסאות.
Integration Test
בדיקות אינטגרציה. כאשר מדובר במוצר עם מספר מודולים, לרוב תעלה דרישה לבדוק את האינטרקציה ביניהם. למשל, בטלפון סלולרי הגיוני לבדוק מה קורה כאשר מתקבלת שיחה במהלך צפייה בסרטון או שמיעת מוזיקה ולא רק כאשר כל אחד מהתרחישים קורה בנפרד.
Interoperability Tests
בדיקות לשיתוף פעולה תקין בין שני מוצרים. הרבה מתבלבלים בין בדיקות אלה לבין בדיקות אינטגרציה, אז אני אסביר את ההבדל. בבדיקות Interop, קיימים שני מוצרים שכבר נבדקו כהלכה וידוע שכל אחד מהם עובד בצורה תקינה בנפרד. המטרה היא לא לבדוק את המוצרים, אלא את שיתוף הפעולה ביניהם.
בדיקות המתייחסות לאותו מוצר, הן ככל הנראה בדיקות אינטגרציה ולא Interop.
Regression Tests
בדיקות נסיגה. אחת המטרות שתהליך בדיקות תקין צריך לוודא הוא שתהליך הפיתוח הולך קדימה ולא לאחור. זה עלול לקרות כאשר תיקון של באג אחד הורס תפקוד שהיה תקין לפני כתיבת הקוד. אפשר להסתדר עם העובדה או ההנחה שבאג אחד יוצר באג אחר, אך ראשית צריך לדעת כשזה קורה והדרך לעשות זאת היא באמצעות הרצת הטסטים עם תוצאת pass על הגירסה הקודמת, על הגירסה החדשה כדי לוודא שהם עדיין באותו סטטוס.
Stress / Load Tests
בדיקות עומסים. טסטים שנועדו לבדוק מצבי קצה של המוצר. בדיקה לגיטימית למשל, עבור server הוא בדיקת תפקודו כאשר הוא תחת שימוש של כמות מקסימלית של משתמשים. כאשר המוצר נתון לעומס, התזמונים של הקוד משתנים וכתוצאה מכך ההתנהגות עלולה להשתנות ובאגים שלא היו צצים במצבים אחרים של המוצר מתממשים.
Stability Tests
בדיקות יציבות. בניגוד לבדיקות עומסים, שהפרמטר העיקרי היה כמות המשתמשים / הנתונים אליהם נחשף המוצר, כאן יש התמקדות בזמן. המטרה היא לאתר באגים שמתממשים בריצה מתמשכת של המוצר, בתנאי עבודה רגילים, לאו דווקא אידאלים אבל מציאותיים ושכיחים.
למי שמעוניין לבחון את עצמו, הוספתי את השאלות הבאות:
מתוך הקורס Software Testing ב- Udacity
ההחלטה יכולה להיות מבוססת על אילוצים כמו כמות הזמן שנותרה לבדיקות או טיבו של המוצר עצמו. כך למשל, תוכנה שנמצאת בשלבי פיתוח ראשוניים ולא יציבה מספיק, תקבל העדפה לסוגי בדיקות בסיסיות יותר ורק לאחר שהתוכנה תתקדם לשלבי בשלות מאוחרים, יבחרו לבדוק אותה דרך סוגי בדיקות מעמיקות יותר.
Sanity Test
בדיקת שפיות. סט של בדיקות שיכול להיות מחזור שלם של בדיקות שנועד לבדוק בצורה כללית את איכות התוכנה ובעיקר לתת תשובה מהירה, גם אם לא מדוייקת לגבי אמינות ויציבות התוכנה בעיקר בתפקודים המרכזיים שלה.
Full Cycle Test
סט בדיקות שלם שנועד לעבור ביסודיות על כל פונקציונליות התוכנה. בגלל אורכו ועומס הבדיקות, סט הבדיקות יבוצע בהעדפה רק אחת לתקופה ולא כשגרה, בעיקר כאשר מדובר בתוכנה שעדיין לא שלמה או לא מספיק בשלה (mature)
Smoke Test
המינוח מגיע מעולם האלקטרוניקה, שם לאחר הרכבת המוצר, נדרשת בדיקה כללית רק כדי לבדוק שאין קצר ו / או שהוא אינו מעלה עשן. סט בדיקות מצומצם ביותר שנועד לבדוק ברמה הכללית האם לתוכנה "יש דופק" או שהיא DOA.
Unit Test
בדיקה שעורך לרוב המתכנת בצד שלו כדי לוודא שברמה הפשוטה, הקוד שכתב או ששינה עובד כפי שהוא מצפה. מדובר בתרחישים נאיביים וממוקדים מאד ובכל מקרה אינם תורמים מידע למחזור הבדיקות הכללי שיתבצע ע"י ה-QA.
System Test
בדיקת המוצר כמכלול, על כל חלקיו והמודולים שלו. המטרה בבדיקות אלה היא לבדוק את התפקוד הכולל של המוצר כיחידה אחת, בניגוד ל- Unit Test שמתמקדת בחלק ספציפי וקטן בתוכנה.
Differential Test
בדיקות שמריצות את אותם טסטים של מוצרים דומים, לרוב מדובר באותו מוצר בגירסאות שונות על מנת למצוא את ההבדלים ו / או הרגרסיה בין שתי הגרסאות.
Integration Test
בדיקות אינטגרציה. כאשר מדובר במוצר עם מספר מודולים, לרוב תעלה דרישה לבדוק את האינטרקציה ביניהם. למשל, בטלפון סלולרי הגיוני לבדוק מה קורה כאשר מתקבלת שיחה במהלך צפייה בסרטון או שמיעת מוזיקה ולא רק כאשר כל אחד מהתרחישים קורה בנפרד.
Interoperability Tests
בדיקות לשיתוף פעולה תקין בין שני מוצרים. הרבה מתבלבלים בין בדיקות אלה לבין בדיקות אינטגרציה, אז אני אסביר את ההבדל. בבדיקות Interop, קיימים שני מוצרים שכבר נבדקו כהלכה וידוע שכל אחד מהם עובד בצורה תקינה בנפרד. המטרה היא לא לבדוק את המוצרים, אלא את שיתוף הפעולה ביניהם.
בדיקות המתייחסות לאותו מוצר, הן ככל הנראה בדיקות אינטגרציה ולא Interop.
Regression Tests
בדיקות נסיגה. אחת המטרות שתהליך בדיקות תקין צריך לוודא הוא שתהליך הפיתוח הולך קדימה ולא לאחור. זה עלול לקרות כאשר תיקון של באג אחד הורס תפקוד שהיה תקין לפני כתיבת הקוד. אפשר להסתדר עם העובדה או ההנחה שבאג אחד יוצר באג אחר, אך ראשית צריך לדעת כשזה קורה והדרך לעשות זאת היא באמצעות הרצת הטסטים עם תוצאת pass על הגירסה הקודמת, על הגירסה החדשה כדי לוודא שהם עדיין באותו סטטוס.
Stress / Load Tests
בדיקות עומסים. טסטים שנועדו לבדוק מצבי קצה של המוצר. בדיקה לגיטימית למשל, עבור server הוא בדיקת תפקודו כאשר הוא תחת שימוש של כמות מקסימלית של משתמשים. כאשר המוצר נתון לעומס, התזמונים של הקוד משתנים וכתוצאה מכך ההתנהגות עלולה להשתנות ובאגים שלא היו צצים במצבים אחרים של המוצר מתממשים.
Stability Tests
בדיקות יציבות. בניגוד לבדיקות עומסים, שהפרמטר העיקרי היה כמות המשתמשים / הנתונים אליהם נחשף המוצר, כאן יש התמקדות בזמן. המטרה היא לאתר באגים שמתממשים בריצה מתמשכת של המוצר, בתנאי עבודה רגילים, לאו דווקא אידאלים אבל מציאותיים ושכיחים.
למי שמעוניין לבחון את עצמו, הוספתי את השאלות הבאות:
מתוך הקורס Software Testing ב- Udacity
אין תגובות:
הוסף רשומת תגובה