מפגש שולחן עגול בנושא איכות ובדיקות תוכנה Quality and Testing RT

לקוחות נכבדים,
תחום האיכות והבדיקות הוא נדבך מרכזי בפיתוח תוכנה. עם זאת ישנן גישות שונות לביצוע משימות אלו כאשר ארגונים שונים מתייחסים לנושא באופנים שונים. בהמשך למחקר שבצעה חברת STKI על פיתוח תוכנה בארגוני IT ברצוננו להעמיק את ההתיחסות לנושא זה. תחום זה אף עומד להתפתח בצורה משמעותית עם הכניסה של טכנולוגיות חדשות בתחום של Mobile ,רשתות חברתיות וכד'.
סדר היום למפגש:
1. מה הם שלבי הבדיקות השונים, מתי הם מתבצעים ומי מבצע אותם.
2. האם מידת השקעה בבדיקות שונה בין פרוייקטים שונים: פיתוח מול תחזוקה, פרוייקטים פנימיים מול חיצוניים וכד'. האם וכיצד קובעים מראש את מידת ההשקעה בבדיקות.
3. מהם הכלים שנמצאים בשימוש ועד כמה הם מחוברים לכלי ALM אחרים (Requirements, Versioning וכד').
4. TDD - Test Driven Development
5. אבטחת מידע בהקשר של איכות ובדיקות (בהמשך לשולחן עגול שנערך בנושא פיתוח מאובטח).
6. בדיקות ואיכות של פרוייקטים בטכנולוגיות חדשות: Mobile , רשתות חברתיות.

מפגש שולחן עגול הוא מפגש של לקוחות הדנים על נושא שנקבע מראש. המפגש יתקיים יום א' ה- 19 ליוני בשעות 09:30 עד 12:30 לערך במשרדי STKI אשר בבני ציון. על פי מדיניות STKI ספקים או יועצים אינם מורשים להשתתף. בד"כ ארגון יכול לשלוח עד 2 נציגים.
בכדי להשתתף במפגש יש לשלוח מייל ל- etty@stki.info או ortal@stki.info.
פרטים על הגעה לאתר ב- http://www.stki.info/files/9e85ab2145dca6f674e36361a806cef9.doc .

סיכומי שולחן עגול קודמים נמצאים בלינק הבא.

בברכה,

פיני

על סביבות בדיקה testing enviroments

יצירת או עדכון של סביבה היא משימה לא טריוואלית. הדגשים במשימה זו הנם בין הייתר:
1. הפצת גרסאות התוכנה המתאימות. משימה זו מורכבת אך מצד שני היא נתמכת בצורה בכלי גרסאות – scm- software configuration management , כלים שנמצאים ברובם של הארגונים.
2. שכפול הנתונים ממערכות הייצור. הסוגיות כאן הוא שכפול מלא למול שכפול חלקי. לעיתים מדובר גם על ערבול נתונים.
3. עדכון הפניות מתאימות בתוך התוכניות. בשלבים שונים ישנה קריאה ישירות לתוכנית, מסד נתונים וכד'. כאשר יש צורך לבצע שינוי בקוד או בסביבות תשתית אחרות. לדוגמה אם יש פניה ישירות מתוכנית לקובץ בשם SAP_PROD על שרת SATURAN הרי שבסביבת הבדיקות יש לגשת לקובץ SAP_TEST על שרת SATURAN_TEST.
4. עדכון הפניות מתאימות בתוך DNS
5. עדכון הפניות מתאימות בסביבה התשתיתית כגון dblinks, שירותים במערכת ESB , SNAPS במערכת האחסון וכד'.
6. סיסמאות בדומה למשימה 3, גם כאן יש לעדכן לדוגמה מ- admin במערכות הייצור ל- admin_test במערכות הבדיקות.

מתוך משימות אלו, שתי המשימות הראשונות - עדכון התוכנות ושכפול הנתונים הנן משימות "סגורות" שמתבצעות בתדירות גבוהה. אולם שאר המשימות, שנקראות לעיתים גם "אינטגרציה של סביבת הבדיקות" שמשמעו "חיבור נכון בין כל הרכיבים במערכות" (אינו קשור ל"אינטגרצית נתונים \ SOA"), הנן משימות שאינן "סגורות" ולא מנוהלות ברוב (כל?) הארגונים על ידי כלים אינטגרטיביים. משימות ה"אינטגרציה" מחייבות גם משאבים רבים של מפתחים, אנשי תשתיות וכד' שעסוקים במשימות אחרות – שמבחינתן הן המשימות החשובות. המשמעות היא שיצירת סביבה היא משימה שאורכת זמן רב. לקוח מתחום התקשורת דיבר על כך שיצירת סביבה מלאה "שמנגנת" את כל התהליכים העסקיים והתשתיתיים (גיבוי...) עורכת לעיתים גם חודשיים! כאשר "חודש" הוא בהחלט זמן שנחשב סביר ל"ייצוב סביבה".
ישנן בגדול שתי קטגוריות של סביבות. סביבות "מוקטנות" אשר מכילות רק אפליקציה ספציפית ומסדי נתונים הקשורים לה וסביבות מלאות אשר מכילות את כל רכיבי המערכת.

על סוגי הסביבות והכלים התומכים - בהמשך

מתי צריך להחליף את צוות בדיקות התוכנה?

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