מבנה צוות בדיקות תוכנה

מאת : נתי הורנשטיין , עורך אתר QAtest

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

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

ציור 1

 עליה לאוויר <= בדיקות רגרסיה <= בדיקות <= בדיקות יחידה <= פיתוח <= עיצוב/אפיון <= ייזום 

                 ן-----------------3----------------ן--------------2-----------------ן------------1------------ן

* עד לפני תקופה קצרה בודק התוכנה היה פוגש את המוצר רק בחלק האחרון בתהליך הפיתוח (חלק 3-ציור 1).

     --------------------------------------------------------------------------------------------------------------------------------------------

כיום חשיבות תאריך עליה לאוויר הינו קריטי לארגון (TIME TO MARKET)
בעולם עסקי שחייב להיות מהיר כל הגורמים המשרתים
את העסק חייבים להיות גמישים וזריזים - טכניקות אלו נכללות
תחת עולם התוכן הנקרא Agile.

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

מבנה הצוות[בתחילת העשור]

צוות הפיתוח – בעבר מתכנתים היו מפתחים את המוצר, בודקים אותו ומשחררים גרסה ישירות למשתמשי המערכת.

מבנה הצוותים[מבנה שאינו גמיש]

צוות הפיתוח מסיים את בדיקות היחידה (Unit Testing) ומעביר
לצוות הבדיקות – בודקי התוכנה מבצעים בדיקות ע"פ דרישת לקוח
(פונקציונאליות, Gui,אינטגרציה וכו' ...) ומשחררים גרסת תוכנה חדשה ללקוחות רק לאחר בדיקות רגרסיה.