מבנה צוות בדיקות תוכנה
מאת: נתי הורנשטיין
במהלך העשור האחרון אנו עדים להתפתחות בתפקידו של בודק
התוכנה שהפך לחלק חשוב בתהליך פיתוח תוכנה.
שלב בדיקות התוכנה נמצא בחלק האחרון של תהליך הפיתוח
והינו קריטי לעליית הפרויקט לאוויר, כל איחור בשלב מוקדם בתהליך
הפיתוח מקטין את הזמן שנותר לצוות הבדיקות.
ציור 1
עליה לאוויר <= בדיקות רגרסיה <= בדיקות <= בדיקות יחידה <= פיתוח <= עיצוב/אפיון <= ייזום
ן-----------------3----------------ן--------------2-----------------ן------------1------------ן
* עד לפני תקופה קצרה בודק התוכנה היה פוגש את המוצר רק בחלק האחרון בתהליך הפיתוח (חלק 3-ציור 1).
--------------------------------------------------------------------------------------------------------------------------------------------
כיום חשיבות תאריך עליה לאוויר הינו קריטי לארגון (TIME TO MARKET)
בעולם עסקי שחייב להיות מהיר כל הגורמים המשרתים
את העסק חייבים להיות גמישים וזריזים - טכניקות אלו נכללות
תחת עולם התוכן הנקרא Agile.
לכן ניתן למצוא היום מספר אפשרויות לבניית צוותי בדיקות
כך שתהיה התאמה הטובה ביותר לארגון ולתהליך העסקי של החברה.
להלן 3 דוגמאות למבנה צוותי פיתוח ובדיקות ושילוב תהליך הבדיקות בהם.
מבנה הצוות[בתחילת העשור]
צוות הפיתוח – בעבר מתכנתים היו מפתחים את המוצר, בודקים אותו ומשחררים גרסה ישירות למשתמשי המערכת.
מבנה הצוותים[מבנה שאינו גמיש]
צוות הפיתוח מסיים את בדיקות היחידה (Unit Testing) ומעביר
לצוות הבדיקות – בודקי התוכנה מבצעים בדיקות ע"פ דרישת לקוח
(פונקציונאליות, Gui,אינטגרציה וכו' ...) ומשחררים גרסת תוכנה חדשה ללקוחות רק לאחר בדיקות רגרסיה.
מבנה הצוותים [מבנה בעולם Agile/גמיש]
כיום אנו רואים צוותי פיתוח הכוללים בודקים אשר מבצעים בדיקות במהלך הפיתוח ולא בסוף הפיתוח, פיתוחים נבדקים גם כאשר יש רכיב חלקי שניתן לבדוק בנפרד ובסוף ביצע בדיקת אינטגרציה והעברה לבדיקות של צוות הבדיקות החיצוני.
צוות הבדיקות מתמקד בבדיקות לקוח קצרות ושחרור הגרסה למשתמשי המערכת לאחר בדיקות רגרסיה.
.jpg)
.jpg)
בטעינה...
