בדיקה כשֵׁרוּת (באנגלית: Testing as a Service או TaaS) היא גישה בבדיקות תוכנה המבוססת על טכנולוגיית מחשוב ענן. בגישה זו, הלקוח פונה אל ספק השירות על מנת שזה יבצע את הבדיקות הנדרשות ללקוח.
מודל ה-TaaS, מודל אספקה מבוסס ענן, עוזר לעסקים להתמודד עם האתגרים של יעילות בדיקת יישומים בפלטפורמות רבות כמו טלפונים סלולריים ובסביבות וירטואליות.
ביצוע ולידציה (אימות) של הבטים פונקציונליים ולא פונקציונליים במרחב מגוון של מכשירים שדורשים מגוון כלים שבדרך כלל מסבכים ומייקרים את הבדיקות.
מודל ה-TaaS מאפשר לעסקים לבדוק אפליקציות בכל פלטפורמה רצויה תוך שימוש בכלי בדיקה לפי בחירה, על מנת להבטיח מוצר איכותי מבלי לרכוש רישיונות נוספים, רכישה או אספקת חומרה חדשה או שכירת אנשים נוספים.
היסטוריה
תעשיית התוכנה התפתחה במשך עשרות שנים ופיתחה גישות שונות לפיתוח תוכנה (לדוגמה תכנות מונחה-עצמים), במקביל להתפתחות תהליך הפיתוח, היה ברור לכל שחייב להתפתח תהליך של הבטחת איכות תוכנה (SQA - Software Quality Assurance). תהליך שכזה הוא הנחת מפתח בהצלחתו של כל פרויקט תוכנה הן בשלב הפיתוח והן בשלב המימוש. כחצי מתקציב תעשיית התוכנה מוקצה לבדיקות - במגוון רחב של דרכים ופתרונות - הן בשלב הפיתוח והן בשלב התחזוקה.
ארכיטקטורה מוכוונת-שירותים (SOA) החלה להתפתח כבר בשנות ה-90 המאוחרות, אולם רק בשנות ה-2000 החלו לממש וליישם ארכיטקטורה זו. היתרונות היו ברורים ולכן היה בלתי נמנע שגם בתחום בדיקות התוכנה ותהליך הפיתוח יישומו הגישות הנפוצות של SOA.
אופן העבודה
נגישות פלטפורמת TaaS: לקוחות יכולים להתחבר לפלטפורמת האספקה של TaaS באופן מאובטח דרך האינטרנט, זמין לכולם.
גישה לשירותים: ללקוחות קיימת גמישות בבחירת השרות הנדרש מתוך קטלוג השירותים שנמצא בפלטפורמה.
אפשרות צריכת שירותים: הלקוח יכול לבחור אם לצרוך חבילת שירותים או שירות בודד לפי דרישה.
פיקוח על השירות והשלמתו: בהתבסס על בחירת השירות, נוצרות סביבות בדיקה וירטואליות ומוקצים כלי הבדיקה (המסחריים או קוד פתוח).
ביצוע השירות: משאבים מובנים מסופקים עבור השירותים הנדרשים. המשאבים יעברו תהליך של פריסה, או באמצעות מודל קהל מבוקר עבור כל הצרכים לפי דרישה או באמצעות משאבים המוקצים במיוחד עבור חבילות שירותים מסוימות.
בדיקות לעומת בדיקות כשירות
יש דמיון בין בדיקות לבדיקות כשירות בנושאים הבאים:
כלי בדיקה
סקריפטי בדיקה
סטנדרטי בדיקה
תהליך העבודה
האפליקציות הסטנדרטיות שנבדקות (כגון SAP או ORACLE)
הקמת מעבדת בדיקה פנימית וייעודית מגיעה עם אתגרים. האתגרים העיקריים הם:
תשתיות: משאבי חומרה ותוכנה, הקמה של כלים ותהליכים מתאימים ומשאבים אחרים כמו רוחב פס יוצרים עומס על התקציב הכולל.
סילומיות (יכולת הרחבה): על מנת להבטיח כי התכנה פועלת במצבים אמתיים, היא צריכה להיבדק בסביבה אמיתית. זה לא קל לארגון ליצור תשתית סקלבילית שמדמה את סביבת הייצור.
עלות: נדרשות השקעות הון גדולות לצורך רכישה ותחזוק של מעבדות בדיקה מתאימות. מאחר שרוב העלויות הן עלויות קבועות (חומרה, תוכנה, רישיונות לכלים) נוצר אתגר להקצות תקציב להשקעות מסוג זה ולהצדיק את החזר השקעה (ROI).
מהנדסים מיומנים: זמינותם של מהנדסי בדיקות מקצועיים, בעיקר מהנדסי אוטומציה היא מוגבלת עקב הביקוש הרב לעומת ההיצע.
עלות יחד עם אתגרים נוספים (המעודדים את יוזמת הקמת ה-TaaS) גורמים למקבלי החלטות להתפשר על אספקטים קריטיים כגון כיסוי בדיקות נסיגה ושחרור גרסאות תוכנה מבלי לבצע בדיקות מלאות של עומסים, ביצועים וסילומיות.
ארכיטקטורת TaaS
ניתן לפנות אל פלטפורמת TaaS באמצעות שתי דרכים: פנייה מקוונת או פנייה פנים אל פנים. אפליקציית הלקוח אינה מחויבת להיות אפליקציית ענן אך מבוססת על צורכי הלקוח.
הלקוח יכול להשתמש בפלטפורמה על פי שלושה תרחישים:
הלקוח יכול להעלות את האפליקציה לפלטפורמת ה-TaaS - ואז הבדיקות נעשות על ידי בודקי תוכנה בצד הלקוח, הלקוח משלם רק על כלי הבדיקה.
הלקוח מעלה את האפליקציה לפלטפורמה והבדיקות נעשות על ידי חברת הבדיקות, הלקוח משלם על השימוש.
הלקוח פונה עם חברת הבדיקות לבדוק את האפליקציה ללא העלאת האפליקציה לענן.
מודל ארכיטקטורת בדיקה כשירות
הארכיטקטורה מורכבת מ-4 שלבים מרכזיים.
קטלוג השירותים
בשלב זה מוצגים ללקוח שלל המוצרים והיכולות של פלטפורמת ה-TaaS. הלקוח יכול להתרשם מהשירותים השונים ולבחור את זה שמתאים לו, בעזרת מערכת התמיכה מערכת התמיכה הקיימת בשכבה זו. קיימים קטלוגים המציגים ללקוח את השירותים ומספקים מידע רב לגבי כל שירות, בנוסף קיימת אפשרות של דרישת "חבילת שירותים". "חבילת שירותים" היא אוסף שירותים המספק ללקוח פתרון אפקטיבי - לדעת ספק השירות- כלומר כזה המטפל בכל קצוות הבדיקה. היתרון הנוסף "בחבילת שירותים" היא המחיר הנמוך יחסית. הספק מציע דילים על מנת לקדם גישות שונות של בדיקה באמצעות חבילות שביחד מספקות תוצר טוב יותר - איכותי יותר.
הלקוח ניצב מול ארכיטקטורות בדיקה ופלטפורמות שונות כמו גם תוכנות שונות (הן תוכנות מסחריות והן תוכנות קוד פתוח) והוא יכול לבחור במי הוא רוצה להשתמש ומי לדעתו יתן את הפתרון הטוב ביותר עבורו.
בתחילה הלקוח צריך להירשם לשירות הבדיקות ורק לאחר מכן הוא יכול להעלות לשרת "בקשת שירות"
בקשת השירות צריכה להכיל פרטים לגבי האפליקציה שאותה הלקוח מעוניין לבדוק. בדף זה הלקוח יכול לבחור את סוג הבדיקה ואת סוג השירות שבו הוא מעוניין.
ברגע שהלקוח מגיש את הדף בחזרה לשרת, נשלח בחזרה ללקוח מזהה ייחודי לבקשת השירות שלו. לאחר קבלת המזהה, הלקוח מקבל את הצעת המחיר. הצעת המחיר כוללת את עלויות השירותים השונים ופירוט התמחור של כל בקשה שהלקוח העלה. בנוסף קיימת כבר חשבונית ללקוח בעבור השירותים שבחר.
חתימת הסכם העסקה
בשלב זה הלקוח צריך לחתום על SLA. בהסכם זה הצדדים מציגים את הסחורה ואת הדרישות ומייצרים תיאום ציפיות. יש צורך ליצור הסכמה בין הלקוח לחברה על מנת לוודא שבסוף התהליך שני הצדדים יהיו מרוצים ולא תהיינה הפתעות לגבי התוצר או הדרישות. בנוסף הלקוח חותם שהוא מוכן לשלם את הסכום המבוקש על ידי החברה - על פי הפירוט שנסגר בשלב הראשון.
וירטואליזציית סביבת הבדיקות
בשלב זה, הספק מבצע את ניהול כלל הסביבות הווירטואליות שבהן יבוצעו הבדיקות. הספק עובר על האפליקציה שהוגשה על ידי הלקוח ומבצע הערכות שימוש יצירת מדדים וניתור של האפליקציה. ביצוע שלב זה בצורה טובה גורר מיקסום יעילות השימוש בתוכנות הקיימות ושיפור משמעותי בניהול תהליך ה-IT.
פריסה בענן
בשלב זה כלל הסביבות הווירטואליות שיוצרו עבור בדיקות התוכנה מועלות לענן ועוברות אינטגרציה עם התוכנות והמתאמים השונים הקיימים כבר בענן.
מתאם העלאת התכנים לענן מספק את התשתית שדרכה פריסת הסביבות היא פשוטה מהירה ויעילה (ניצול יתרונות טכנולוגיית הענן).
