בדיקת תוכנה כשירות

מתוך ויקיפדיה, האנציקלופדיה החופשית

בדיקה כשֵׁרוּתאנגלית: Testing as a Service או TaaS) היא גישה בבדיקות תוכנה המבוססת על טכנולוגיית מחשוב ענן. בגישה זו, הלקוח פונה אל ספק השירות על מנת שזה יבצע את הבדיקות הנדרשות ללקוח.

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

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

היסטוריה[עריכת קוד מקור | עריכה]

תעשיית התוכנה התפתחה במשך עשרות שנים ופיתחה גישות שונות לפיתוח תוכנה (לדוגמה תכנות מונחה-עצמים), במקביל להתפתחות תהליך הפיתוח, היה ברור לכל שחייב להתפתח תהליך של הבטחת איכות תוכנה (SQA - Software Quality Assurance). תהליך שכזה הוא הנחת מפתח בהצלחתו של כל פרויקט תוכנה הן בשלב הפיתוח והן בשלב המימוש. כחצי מתקציב תעשיית התוכנה מוקצה לבדיקות - במגוון רחב של דרכים ופתרונות - הן בשלב הפיתוח והן בשלב התחזוקה. ארכיטקטורה מוכוונת-שירותים (SOA) החלה להתפתח כבר בשנות ה-90 המאוחרות, אולם רק בשנות ה-2000 החלו לממש וליישם ארכיטקטורה זו. היתרונות היו ברורים ולכן היה בלתי נמנע שגם בתחום בדיקות התוכנה ותהליך הפיתוח יישומו הגישות הנפוצות של SOA.

אופן העבודה[עריכת קוד מקור | עריכה]

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

בדיקות לעומת בדיקות כשירות[עריכת קוד מקור | עריכה]

יש דמיון בין בדיקות לבדיקות כשירות בנושאים הבאים:

  • כלי בדיקה
  • סקריפטי בדיקה
  • סטנדרטי בדיקה
  • תהליך העבודה
  • האפליקציות הסטנדרטיות שנבדקות (כגון SAP או ORACLE)
  • מטריקות בדיקה
  • סביבת הבדיקה (פלטפורמה, ארכיטקטורה והאפליקציות עצמן)

גישת TaaS מחדשת במספר נושאים:

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

מתי נשקול להשתמש ב-TaaS?[עריכת קוד מקור | עריכה]

נשקול להשתמש ב-TaaS בבדיקות מסוג:

  • ביצועים, אבטחה ובדיקות שימושיות (אנ')
  • בדיקות תאימות לדפדפנים
  • בדיקת התקנים (Devices)
  • בדיקת אפליקציות מובייל
  • בדיקות SOA
  • בדיקות שדרוג OS
  • אפליקציות פנימיות
  • שינויים במרכזי מידע (Data Centers)

המניעים לפיתוח הגישה[עריכת קוד מקור | עריכה]

הקמת מעבדת בדיקה פנימית וייעודית מגיעה עם אתגרים. האתגרים העיקריים הם:

  1. תשתיות: משאבי חומרה ותוכנה, הקמה של כלים ותהליכים מתאימים ומשאבים אחרים כמו רוחב פס יוצרים עומס על התקציב הכולל.
  2. סילומיות (יכולת הרחבה): על מנת להבטיח כי התכנה פועלת במצבים אמתיים, היא צריכה להיבדק בסביבה אמיתית. זה לא קל לארגון ליצור תשתית סקלבילית שמדמה את סביבת הייצור.
  3. עלות: נדרשות השקעות הון גדולות לצורך רכישה ותחזוק של מעבדות בדיקה מתאימות. מאחר שרוב העלויות הן עלויות קבועות (חומרה, תוכנה, רישיונות לכלים) נוצר אתגר להקצות תקציב להשקעות מסוג זה ולהצדיק את החזר השקעה (ROI).
  4. מהנדסים מיומנים: זמינותם של מהנדסי בדיקות מקצועיים, בעיקר מהנדסי אוטומציה היא מוגבלת עקב הביקוש הרב לעומת ההיצע.

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

ארכיטקטורת TaaS[עריכת קוד מקור | עריכה]

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

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

הארכיטקטורה מורכבת מ-4 שלבים מרכזיים.

קטלוג השירותים[עריכת קוד מקור | עריכה]

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

חתימת הסכם העסקה[עריכת קוד מקור | עריכה]

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

וירטואליזציית סביבת הבדיקות[עריכת קוד מקור | עריכה]

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

פריסה בענן[עריכת קוד מקור | עריכה]

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

יתרונות[עריכת קוד מקור | עריכה]

Taas

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

אתגרי TaaS[עריכת קוד מקור | עריכה]

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

ראו גם[עריכת קוד מקור | עריכה]

קישורים חיצוניים[עריכת קוד מקור | עריכה]

דוגמאות TaaS: