הכנה לראיון עבודה QA - מושג Waterfall
פרקי ההרצאה: הכנה לראיון עבודה QA - מושג Waterfall
תמלול ההרצאה: הכנה לראיון עבודה QA - מושג Waterfall
הטקסט המלא של הדקות הראשונות בהרצאה «הכנה לראיון עבודה QA - מושג Waterfall» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם, בסרטון הקרוב נדבר על מודל מפל המים לניהול מחזור חיי פיתוח מוצר תוכנה. כשאנחנו רוצים להבין את המושג Software Development Lifecycle, מחזור חיים של פיתוח תוכנה, אנחנו יכולים להיעזר במודל ה-Waterfall.
מודל זה הוא מודל קלאסי, שמרני, מסורתי, של ניהול פיתוח תוכנה, והוא גם מאוד אינטואיטיבי ומאוד קל להבנה. הרעיון המרכזי של מודל מפל המים לניהול מחזור חיים של פיתוח תוכנה הוא חלוקה נוקשה וסכמטית וברורה של מחזור החיים לשלבים מאוד מאוד מוגדרים, שבכל שלב יש סט של פעולות שבדרך כלל מבוצע
על ידי צוותים שונים במערכת של הפיתוח, במערכת של אותה חברה שמפתחת את התוכנה. כל שלב ושלב הוא שלב בפני עצמו. חשוב להבין שהמודל התיאורטי המובהק של מפל המים, כל שלב יתחיל רק ברגע שהשלב הקודם אליו מסתיים.
כלומר, השלב הראשון מסתיים ורק אז מתחיל השני, אוקיי? באותה צורה סכמטית גם בדרך כלל יהיו חלוקות המשימות.
ניתן לחלק את שלבי מחזור החיים של פיתוח תוכנה על פי מודל מפל המים לשלבים הבאים יש לנו את תכנון המוצר שזה מנהלי המוצר דרישות לפיתוח שזה צוות אפיון המוצר וגם מנהלי המוצר הספסיפיקציה הפירוט של הפיתוח זה צוות המוצר
צוות המאפיינים הדיזיין זה מעצבי המוצר ביצוע הקוד והפיתוח זה צוות ה-R&D המפתחים, Software Testing זה הצוות בדיקות, שחרור הגרסה ללקוחות זה צוות התמיכה, צוות הסרוויסס, Product Support זה צוות התמיכה והסרוויסס.
אז לכאורה השלבים הם מאוד מחולקים וגם האחריות לשלבים האלה מחולקת על פי הצוותים שמרכיבים את הגוף המפתח של התוכנה. חשוב לזכור שהמאפיין של גישת מפל המים או מודל מפל המים בניתוח מחזור החיים של פיתוח או תוכנה הוא לא השלבים עצמם.
השלבים האלה יהיו בדרך כלל גם במודלים אחרים כמו מודל אג'ייל שהוא מודל הרבה יותר מודרני ודינמי מאשר המודל המסורתי של מפל המים. גם במודל האג'ייל יופיעו השלבים האלה.
תכף נעמוד על ההבדל בין אג'ייל לווטרפול אבל אני רק אגיד שווטרפול ההבדל בינו ובין אג'ייל הוא לא בקיום של השלבים האלה.
השלבים האלה יהיו קיימים גם לפי מודל מחזור חיים של אג'ייל. בתמונה הבאה אנחנו יכולים לראות את החלוקה למשימות לצוות הבדיקות על פי מודל מפל המים. אז יש לנו את החלוקה של עד שלב הבדיקות ואחרי שלב הבדיקות.
אז עד שלב הבדיקות צוות הבודקים ינסה למנוע את ההגעה של תקלות מהשלב פיתוח לשלב הבדיקות. על ידי מעבר על האפיון, על התכנון של המוצר, לנסות לאתר טעויות אנוש, לנסות לאתר מקומות שבהם האפיון לא נגע או נגע בצורה לא נכונה.
מהרגע שהמוצר עבר את שלב הפיתוח והגיע לשלב הבדיקות, הפוקוס של אנשי הבדיקות יהיה על איתור התקלות על מנת להחזיר אותם לתיקונים על ידי צוות הפיתוח.
אחרי שצוות בדיקות סיים את העבודה שלו והעביר את המוצר ללקוחות בעזרת צוות ה-Services, השירות או צוות התמיכה, המטרה של צוות הבדיקות הופכת לנסות למצוא פתרונות לתקלות, למצוא Workaroundים, איזשהם מעקפים, על מנת להקל את החומרה של תקלות שכבר הגיעו
לייצור. אז זה בגדול מחזור חיי פיתוח תוכנה על פי ווטרפול. המאפיין, אני רוצה לחזור, של ווטרפול הוא הסכמטיות והחלוקה גם לאחריות של צוותים וגם לקבוצות זמן לכרונולוגי, לתהליך כרונולוגי רציף, טורי, שבו כשחלק אחד מסתיים