מפגש שולחן עגול בנושא איכות ובדיקות תוכנה 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

ישנם מספר מופעים של כל סביבה (פיתוח למפתחים, סביבת פיתוח אינטגרטיבית למפתחים, סביבות בדיקה, סביבת pre-prod וסביבות ייצור) בייחוד למפתחים. נניח שבארגון מסויים המערכת שנמצאת בייצור היא בגרסה 200. המערכת שנמצאת בבדיקות היא בגרסה 201. המערכת עליה עובדים המפתחים היא כבר גרסה 202. אבל מובן שלמפתחים צריך שיהיו עותקים גם של 200 (למקרה של תקלות בייצור) וגם של 201 (למקרה של תקלות בגרסה שנמצאת ב- QA).
ל- QA שעובדים על גרסה 201 יש גם עותק של גרסה 200 וזאת בכדי שיוכלו לאשר תיקונים בייצור.

במקרים רבים האחראי הטכני לכל הסביבות הוא צוות בתוך צוות ה- DBA. ישנם מקרים שבהם האחריות מחולקת בין תשתיות לבין אפליקציה. מדובר על חלוקה שעלולה לגרום לקשיים בתפעול.
בתוך ה- PMO יש "מנהל סביבות טכניות" אשר נותן הוראות לצוות הסביבות – למתי יש להכין כל סביבה. וזאת בכדי שלדוגמה מפתחים לא יתחילו לעבוד ולא תהיה להם סביבה מוכנה.



סוגי הפעולות של צוות סביבות
1. Setup – בניה של סביבה חדשה. מתבצע לפי Check list. דברים כגון שרתים, אחסון DBA, middleware. אבטחת מידע ופיתוח.
2. שדרוגים :
a. שדרוגים תשתיתיים על פי checklists או scripts ידועים של אוטומציה
b. שדרוגי תוכנה- כלים או ידנית
3. Data Refresh –
a. Full - דרך clone, ומיסוך (משכורות, סיסמאות)
b. SUBSET או שיש הפצה מרובת סביבות. בונים master (כלומר מייצרים מדגם) , מרעננים ומפיצים לכולם (העתקה ממש ולא SNAPS) .בד"כ מבצעים העתקות בפועל – לא משתמשים ב- SNAPS
c. Direct – לוקחים נתונים מייצור בפועל. בכדי לבדוק בעיה.

הכלים לביצוע משימות ה- Refresh הם: ETL, refresh scripts - ובכלים – כמו Optim (כיום של IBM ) או Brilix שמבצעים גזירות ו- SUBSET.

על סביבות בדיקה- המשך testing enviroments

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

סוגי הסביבות
סביבות הבדיקה המלאות, באופן תאורטי, צריכות לכלול 4 סוגים:
1. סביבות פיתוח – בבעלות אנשי הפיתוח
2. סביבות פיתוח לטובת unit test – בבעלות אנשי הפיתוח. ישנו צורך לסביבה כזו מכיוון שסביבת הפיתוח משמשת מספר רב של מפתחים הנמצאים בגרסאות שונות של קוד וב"תהליך" כלומר קוד לא סגור ולא פונקציונלי ולכן ביצוע unit test לא ייתן תוצאה אמיתית. "סביבת הפיתוח לטובת unit test" אמורה להכיל רק קוד עובד.
3. סביבות בדיקה – בבעלות ה- QA
4. סביבות Pre-Production – בבעלות התפעול\הייצור
5. סביבות ייצור

אחריות על בניית הסביבות – "צוות סביבות"
צוות "סביבות" הוא הצוות האחראי לבניית הסביבות כאשר אחריות הצוות היא גם תפעולית (כלומר מבצע חלק מהמשימות בעצמו) אבל יותר ניהולית (מזמין שירותים מגופים אחרים בארגון לטובת ייצור הסביבה – משאבי DBA , אנשי סיסטם, מפתחים ו- QA שמוודאים שהסביבה זהה לייצור).
דגשים לגבי הסביבות השונות:
1. סביבת הפיתוח – בגלל שהיא משרתת מפתחים רבים שעובדים על פרוייקטים רבים בו זמנית, מדובר על הסביבה הכי פחות מסודרת.
2. סביבת הפיתוח לטובת unit test – בארגונים שאין סביבה כזו ניתן לבצע unit test על סביבת הבדיקות הכללית.
3. סביבת הבדיקות הכללית – עיקר המשימה היא לוודא שמבחינה פונקציונלית המערכת מבצעת את משימותיה.
4. סביבת ה- Pre-Prod אמורה להיות זהה לגמרי לסביבת הייצור. בה מבצעים קימפול סופי ומוודאים שתהליך ההתקנה עובר חלק כאשר בתום ההתקנה מבצעים בדיקת שפיות כללית. לא מריצים את כל תסריטי הבדיקות אלא מוודאים שהמסכים נפתחים ושפעולות בסיסיות מתקיימות. העיקר בסביבה זו הוא לוודא שאכן תהליך ההתקנה עובד בצורה חלקה. לדוגמה, כאשר העבירו גרסה לסביבת ה- TEST הייתה חסרה הרשאה מסויימת שהעיפה את התוכנית והוסיפו אותה בצורה ידנית – לא כחלק מ- SCRIPT. נקודה זו תתגלה ב- Pre-Prod. כמו כן יש לבדוק שהמערכות מדברות בין עצמן בגרסה החדשה.

במצב אידאלי ארגון אמור להחזיק כמה סביבות פיתוח ואולי כמה סביבות "פיתוח ל- unit test " אבל סביבת בדיקות אחת וסביבת Pre-Prod אחת. אולם בפועל, בגלל שלא רוצים לפגוע בגרסאות שנמצאות בשימוש ולא מצליחים לתאם בין כל הפרוייקטים (שעובדים על מערכות שונות המקושרות ביניהן) ישנם מקרים שבהם יש כמה סביבות בדיקות ואפילו כמה סביבות Pre-Prod !
עדכון הסביבות מתבצע בד"כ פעם בשבוע מבחינת מסדי הנתונים אבל לא מבחינות אחרות (לא מבחינת "אינטגרציה"). יש עדיפות לעדכון הנתונים בסביבת הבדיקות כי סביבת הבדיקות חייבת להכיל את כל הנתונים (ובעיקר סוגי הנתונים) העדכניים – לדוגמה מסוג חדש בשם "סופר פלטינום". סביבת ה- Pre-Prod פחות חייבת להתעדכן מבחינת הנתונים כי מדובר שם על בדיקות "שפיות בלבד". אבל מצד שני סביבת ה- Pre-Prod חייבת להיות מעודכנת ברמה התשתית ("אינטגרציה") – דברים כמו עדכוני patch של windows שהתבצעו בייצור צריכים לעבור גם ל- pre-prod , גרסאות ESB , וכד'. אבל במקרים רבים ארגונים לא מבצעים את העדכונים מייד ולכן ה- pre-prod אינו מעודכן בצורה מלאה.
בגלל הזמן הרב שנדרש ליצירת סביבה ניתן להשתמש במתודולוגיה של fip-flop לבניית סביבת הבדיקות. הבודקים עובדים על סביבה יציבה ובמקביל בונים סביבה חדשה. תהליך זה לוקח כחודש ולאחר ייצוב הסביבה מעבירים את הבודקים לסביבה החדשה ומוחקים את הסביבה הישנה. ואז מתחילים לבנות סביבת בדיקות מעודכנת יותר.
כלים תומכים
מבחינת כלים תומכים:
1. עבור הקוד משתמשים בכלים בשלים של SCM – software configuration management. החל מכלים ממשפחת rational, team system של מיקרוסופט, subversion שהנו open source וישנם רבים אחרים.
2. עבור ריפרוש ה- DBMS – ארגונים רבים פתחו כלים (scripts מתוחכמים) משל עצמם.
3. לשאר המשימות אין שימוש נפוץ בכלים.
מבחינת כלים המאתרים שינוי בין סביבות, אחד הלקוחות סיפר על כלי שפותח בארגון. על ידי פונקציית DIF מוצאים מה השתנה בין קבצים או טבלאות קונפיגורציה. כאשר הבדיקה אינה מתבצעת על כל הסביבה אלא רק על דברים בעייתיים (קבצי קונפיגורציה, מבנה DBMS, סיסמאות, טבלאות קונפיגורציה) אשר בעבר התגלו איתם בעיות.

על סביבות בדיקה 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 בארגונים רבים. כלומר צוות הבדיקות הוא צוות חיצוני כאשר מנהלי הבדיקות הם כן פנימיים. במקרים רבים גם צוות הבדיקות אינו נמצא תחת אגף הפיתוח אלא באגף אחר בארגון - תחת מנהל איכות חיצוני לתחום הפיתוח.
בכל מקרה, מנהלים רבים מעדיפים לשמור מתח זה וכאשר המנהלים מזהים שישנה התקרבות בין הצוותים, כי בכל זאת העבודה היא על אותם תכנים ובצורה צמודה, זה הזמן להחליף את צוות הבדיקות.

מתי לבצע בדיקות רגרסיה

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

מה לקוחות רוצים - חלק ב'

בהמשך לרשימה הקודמת, לקוחות גם הזכירו סוגייה של טיפול בסביבות.
מעבר לסביבת הייצור של כל מערכת ארגוני התשתיות נדרשים לספק סביבות רבות נוספות: סביבת פיתוח, סביבות בדיקות, סביבת אינטגרציה, סביבת trainning ועוד ועוד.
הדבר מורכב יותר ממה שנראה בתחילה וזאת מכיוון שהיום למערכות רבות קשרים מהותיים אחת עם השנייה ואז מסתבר שיש צורך לשכפל מערכות רבות.
אם ישנו פיתוח במערכת א', אך מערכת זו עובדת צמוד למול מערכות ב', ג' ו-ד', אז צוות התשתיות צריך להכין לטובת הפיתוח גם את מערכות ב' עד ד'.
במקביל, אם מתרחש גם פיתוח במערכת ב', הרי גם היא צריכה סביבה את מערכות א', ג' ו-ד' ובצורה נפרדת כי חייבים לשמור על סביבות יציבות (כלומר מערכת ב' לא יכולה לבצע בדיקות מול מה שמפותח כעת במערכת א').
חשבון מראה שמדובר בבעיה אקספוננציאלית. במקרה שהוזכר כאן צריכים 8 מערכות כפול מספר השלבים (פילוח, בדיקות, אינטגרציה, trainning ) כלומר 32 סביבות!
מבחינת האחסון ישנם כבר פתרונות שמאפשרים שימוש בשטחי אחסון קטנים יותר (לצערנו אחד הפתרונות הטובים בשוק נסגר בשבוע זה...) .
חברת VMWARE מספקת פתרון מעבר לאחסון אולם פתרון זה מטפל בסביבות שיכולות להשען על פלטפורמת ה- VMWARE.
בכל מקרה, לקוחות מדברים על כך שמדובר בסוגייה מטרידה שגוזלת זמן רב ומשאבים יקרים.