בתהליך פיתוח תוכנה קיימות 2 קבוצות עבודה מרכזיות אשר רוב העבודה נעשית על ידן:
קבוצת הפיתוח
קבוצת הבדיקות
הליך פיתוח תוכנה תקין מצריך את קיומן של שתי קבוצות אלו. שתי הקבוצות תומכות אחת בשניה בתהליך הפיתוח. כל שינוי בתהליכי פיתוח התוכנה מצריך את התיישרותה של קבוצת הבדיקות בהתאם. ברוב המיקרים, חוק אצבע זה אינו עובד הפוך.
בחרתי להביא כאן את חמשת הסיוטים הכי גדולים של מנהלי הפיתוח ומנהלי הבדיקות בתהליך פיתוח תוכנה...
1. ניהול גרסאות (CM)
מנהלי הפיתוח: ניהול מספר גרסאות במקביל (גרסה ראשית מול branch מול patch)
מנהלי הבדיקות: כל עליית גירסה ו/או עדכון בכל רמה ותכולה מצריכה סבב בדיקות משלה. ככל שיש יותר
2. אבולוציה מול רבולוציה
מנהלי הפיתוח: כאשר מדובר במערכות מידע מסועפות ומורכבות, האופציה העדיפה תהיה האבולוציה ולא הרבולוציה. עם זאת, רבולוציה תאפשר הכנסה ושימוש בטכנולוגיות חדשות, שיפור וייעול תהליכי העבודה עם המערכת ועם המערכת עבור המשתמשים.
רבולוציה תובא בחשבון אם וכאשר, מתוכננת גרסה גדולה וחדשה המכילה כמות ניכרת של תכולה חדשה. זו האופציה הפחות מועדפת על מנהלי הפיתוח.
מנהלי הבדיקות: במידה ותרחישי הבדיקות נבנו מלכתחילה בצורה מודולרית הכוללת תבניות, ניתן יהיה להשתמש בם בצורה אבולוציונית. אך במחלקת הבדיקות, אם התרחישים נכתבו בצורה תהליכית מלאה (כל תרחיש מתאר תהליך מתחילתו ועד סופו), במידה ונשתמש בשיטה אבולוציונית מהר מאוד נגיע למצב שבו לא ניתן להריץ את התרחישים בצורה רציפה ויעילה. לכן במקרה זה תהיה עדיפה השיטה הרבולוציונית עבור תהליך במערכת או עבור רכיב כזה או אחר...
3. ריבוי סביבות עבודה
מנהלי הפיתוח: בד"כ יהיו מספר סביבות עבודה המשרתות את אנשי פיתוח התוכנה: סביבת פיתוח (אחת או יותר), סביבת ייצור, סביבת בדיקות עליה ישחזרו תקלות על מנת לודא תקלות שנמצאו בזמן הבדיקות. ריבוי סביבות עבודה ועדכוני גרסה שונים בכל אחת מהסביבות עלולות ליצור בלבול ולפיכך גם לגרום לתקלות.... לשם מניעת תקלות מסוג זה, קיים צורך לניהול סביבות העבודה והגרסאות המעודכנות בהם.
קבוצת הפיתוח יהיו ככלל בעלים של סביבת הפיתוח העיקרית.
מנהלי הבדיקות: קבוצת הבדיקות תעבוד בד"כ מול סביבת הבדיקות וסביבות המדמות את סביבת הייצור הקיימת אצל הלקוחות. ריבוי סביבות עבודה יכולות לגרום ליכולת שחזור / אי שחזור תקלות חוזרות המגיעות מהשטח ו/או תקלות הנמצאות במהלך הבדיקות. יש צורך לנהל את סביבת הבדיקות גם עבור מחלקת הבדיקות.
קבוצת הבדיקות יהיו ככלל בעלים של סביבת הבדיקות העיקרית.
4. חוסר חדשנות ושגרה
מנהלי הפיתוח: פיתוחים באותו סקופ – ללא חידושי טכנולוגיה, מביא לשחיקה ושיעמום עבור המפתחים אשר ברובם אנשים יצירתיים המחפשים את האתגר והחדשנות.
מנהלי הבדיקות: עם כל שינויי טכנולוגי ו/או חידוש בפיתוח התוכנה שמשפיע על התהליכים העיסקיים של המערכת ותהליכי השימוש – יש לשנות את שיטת הבדיקות ולכתוב את התרחישים מחדש.....
עם זאת, קבוצת הבדיקות תחפש בכל הזדמנות שיטות יעילות וחדישות יותר מעשית או טכנולוגית אשר בהתאם לתקציב של הקבוצה יוכלו לבדוק התאמה ולהתקדם לשיטות בדיקה חדשניות יותר.
הטמעת שיטות בדיקה חדשניות תהיה על פי רוב חסרת ממשק לקוח ועל כן לכאורה קבלת ההחלטה תושפע בעיקר ממשאבי תקציב, כוח אדם ולוחות זמנים. קבלת ההחלטה תושפע פחות מרמת הסיכון למוצר בשל היעדר ממשק לקוח לשינוי זה, וכן חוסר השפעה על המוצר עצמו.
5. רגרסיה
מנהלי הפיתוח: הסיוט הכי גדול שמנהלי הפיתוח וכן המתכנתים עצמם הוא תיקון תקלות קטנות באזור שעבד באופן מלא ולא נבדק במשך מספר גרסאות בשל כך, שיכולות ליצור תקלות רגרסיה גדולות יותר.
מנהלי הבדיקות: עם כל תיקון של תקלה באזור נרחב עם ממשקי פונקציונאליות רבים, יידרשו בדיקות רגרסיה באזור ההשפעה של התיקון.
ככל שנרחב יותר אזור ההשפעה, היקף הבדיקות גדול יותר ולכן סיכוי רב יותר שהשפעה אזורית שלא נלקחה בחשבון תביא לתקלות שלא היו קיימות מספר גרסאות אחורה, וכל זאת בשל תיקון אותה תקלה.
בדיקות רגרסיה לוקחות זמן רב.
הן בעלות תיעדוף לא נמוך בד"כ ולא ניתן להתעלם מהן, מה גם שהן יבואו בד"כ מחוץ לתוכנית וכן ישפיעו על תוכנית הבדיקות השוטפת.
לכל אחד מהסיוטים שצוינו לעיל יש פתרון, הן עבור הפיתוח והן עבור הבדיקות. נוכל למצוא שיטות עבודה שנותנות מענה בקורלציה לבדיקות ולפיתוח בתהליך משותף ומתואם.
גם אתם לוקחים חלק בתהליך הפיתוח ורוצים לשמוע עוד על הפתרונות?
תמיד לשירותכם, שירלי.