סיכום מפגש שולחן-עגול איכות תוכנה ובדיקות מנחה פיני כהן Page 1 of 16
לקוחות נכבדים שלום, תודה על השתתפותכם במפגש שולחן עגול Round Table בנושא איכות תוכנה ובדיקות. מצ"ב סיכום עקרי הדברים שעלו במהלך המפגש. בסיכום זה תומצתו נושאים מהותיים כפי שעלו במפגש. אין בסיכום זה המלצה גורפת ללקוחות אלא מתן פרספרטיבה והצגה של ההתלבטויות שעלו במפגש כלומר "מהשטח". תחום האיכות וביצוע הבדיקות הוא נושא מורכב ביותר ומחייב הבנה עמוקה של המציאות העסקית. המערכות היום מורכבות ביותר והבדיקות שנדרשות הן מסובכות מאוד. באג שלא יתגלה בשלבי הבדיקות יכול "לחיות" שנים רבות במערכת הייצורית תוך שהוא גורם נזק לחברה ללא ידיעתה. דוגמה לסיטואציה כזו היא בתחום הטלקום )וגם בתחומים אחרים( כי אם נציג מכירות\שירות יזהה פרצה במערכת שמאפשרת לו "למכור חבילות יותר בזול" ובכך להגדיל את העמלה שלו, הנציג ישתמש בפרצה זו והמערכת לא "תעוף" או תתריע על בעיה. במפגש בלט שמצג אחד התהליך הכללי של בדיקת התוכנה ברור. אולם מצד שני מידת היישום של התהליך שונה בין הארגונים השונים. ישנם הרבה ארגונים שכבר הטמיעו בצורה טובה את נושא האיכות )בעיקר מהמגזרים הפיננסיים והטלקום( אולם ישנם ארגונים שרק כעת בונים מתודולוגיות וצוות בתחום. מספר משתתפים בדיון ציינו ש"כיום יש לנו רק X בודקים אבל בעתיד אנחנו מתכוונים להגדיל מספר זה". במפגש גם בלט הנושא של.Agile Software Development גם ארגונים מסורתיים מתחלים לשקול פיתוח על פי מתודולוגיה זו והמעבר מחייב התארגנות שונה בתחום האיכות והבדיקות. בדיון התבקשו ארגונים לתאר מדדים הקשורים בתחום האיכות ואת ערכם. לדוגמא אצל אחד הארגונים ישנו מדד איכות של מספר תקלות קריטיות שמתגלות בייצור. ערך המדד הוא כ- 2 תקלות ל- 011 ימי פיתוח. לנושא מעניין זה מוגדר פרק שלם בסיכום. יש לציין שמקור מצויין למושגים בסיסים ומתקדמים בתחום הבדיקות הוא http://www.matrix.co.il/marketing/qa_dictionary.pdf Page 2 of 16
בברכה, פיני כהן תוכן מספר הבודקים למול מספר המפתחים...4 מעורבות של תחום הבדיקות בשלבים השונים של פיתוח המערכת...5 שלבי בדיקות בפרוייקטים שמפותחים בתוך הארגון...5 תהליכי בדיקות בפרוייקטים שמתבצעים מחוץ לארגון...6 קונפליקטים בתחום הבדיקות...6 פונקציית ביניים בין הלקוח, הפיתוח והבדיקות...7 מי הם הבודקים...7 בדיקות עומסים...8 בדיקות רגרסיה...8 כלים בתחום הבדיקות...8 שימוש בכלים פנימיים... 9 01... Test Driven Development TDD 01... Unit Testing מדדי איכות וערכם...01 00... AGILE רגולציה וסטנדרטים...02 תגובות של ספקים...02 מיקרוסופט...02 01... IBM 04... HP טסקום...05 Page 3 of 16
מספר הבודקים למול מספר המפתחים במפגש נשאלו המשתתפים לגבי מספר הבודקים למול מספר המפתחים. לא מדובר במחקר מבוסס אלא רק בסקר מדגמי מהנעשה אצל המשתתפים בדיון. להלן תוצאות השאלון של המצב כעת )חלק מהארגונים דיברו על מצב עתידי ומשופר יותר מבחינת הבדיקות אולם נתונים אלו לא מופיעים כאן(: תוצאות אלו מזכירות רק בחלקן את התוצאות שהתקבלו במחקר STKI כאן נראה שתחומי התקשורת והמגזר הפיננסי משקיעים יותר בבדיקות. 1 בנושא פיתוח. גם במגזר הממשלתי הייתה שונות גדולה. ישנם משרדי ממשלה שכבר הטמיעו את נושא האיכות בצורה טובה וישנם משרדים שכעת בונים ומחזקים תחום זה. המשתתפים לציין את חלוקת התקציבים יש לציין שבמחקר ובמפגש דובר על מספר הבודקים STKI נתבקשו למול מספר המפתחים. מכיוון שבד"כ שכר הבודקים נמוך יותר הרי שיש יותר בודקים ב"מספרים" לעומת התקציב המושקע. שימוש ב- Near Shore יכול לגרום להטייה נוספת של הנתונים וזאת מכיוון שהשכר שם נמוך יותר וגם הממשלה משתתפת בשכר. כלומר גרף של "תקציב הבדיקות המפתחים". למול תקציב הפיתוח" יהיה שונה מגרף של "מספר הבודקים למול מספר אחד הארגונים תאר את סך התקציב שמושקע בבדיקות. בד"כ לוקחים לבדיקות 21% אבל יש שונות מכיוון שבמידה ומדובר על מערכת stand alone לוקחים 01% ולחילופין למערכת מאוד אינטגרטיבית מערבת הרבה מערכות לוקחים יותר. http://www.slideshare.net/pini/stki-application-developmentresearch עמ'.01 1 Page 4 of 16
מעורבות של תחום הבדיקות בשלבים השונים של פיתוח המערכת אצל רוב הלקוחות דובר על כך שישנה השתתפות של נציגים מצוות הבדיקות כבר בשלבי הייזום של הפרוייקט. זאת כשמדובר בפרוייקטים גדולים. בפרוייקטים קטנים בד"כ לא משלבים נציגים מצוות הבדיקות בשלב הייזום. במקרים וצוות הבדיקות מצומצם מאוד יחסית אין מעורבות של הצוות בשלבים הראשונים של הפיתוח )ייזום ואפיון(. שלבי בדיקות בפרוייקטים שמפותחים בתוך הארגון שלבי הבדיקות היו ברורים במהלך הדיון לכן לא הייתה העמקה בתאור התהליך עצמו. להלן רשמים כלליים שהתקבלו. לאחר שלב הייזום שבו נתבקשו נציגים מצוות הבדיקות לחוות דעה, השלב הבא שבו צוות הבדיקות משתלב בפרוייקט הוא כשיש אפיון מפורט ובמקביל לפיתוח של המערכת. בשלב זה מתחילים לכתוב תסריטי )תרחישי( בדיקות cases(.)test התסריטים נרשמים ב- WORD או בכלי יעודיים בד"כ בצורה של TEXT אולם במקרים מורכבים ישנו שימוש בטבלאות בד"כ ב-.EXCEL יש לציין שכאשר מתבצעים דיוני design review מצטרפים גם אנשי הבדיקות. המטרה היא שכאשר הגרסה מסתיימת הבדיקות לאותה גרסה יהיו מוכנות. אחד הארגונים תאר מצב מתקדם שבו המפתחים מתבקשים לפתח את התוכנה גם בראייה של בדיקות. כלומר מבקשים מהמפתחים לחשוב על סנריו של בדיקה ולפתח כך שניתן יהיה לבצע את הבדיקה והם מתבקשים לתת הוראות לבודקים מה ואיך לבדוק. לאחר סיום הפיתוח נכנסים צוותי הבדיקה לעבודה מול המערכת כאשר מדובר בד"כ בסט כזה של בדיקות: 2-1 0. סבבים של בדיקות פונקציונליות. בכל סט של בדיקה עולים על מספר תקלות\באגים ומוסרים אותם לפיתוח לתיקון. 2. לקראת סוף פרוייקט מבצעים לעיתים בדיקות עומסים. 1. בדיקות רגרסיה- בדיקות של המערכת כולה כיצד משתלבת עם המערכות הקיימות בארגון. זאת בכדי לוודא שתהליכים חוצי ארגון לא נפגעים. במקרה של מערכות stand alone אין צורך לבצע בדיקות מסוג זה. 4. לקראת הסוף מכניסים את המשתמשים מהארגון בדרך כלל משתמשים מובילים. ועובדים איתם על המערכת. ישנם ארגונים שבהם שלב זה מוגדר כ"בדיקות קבלה של משתמשים" והנו נפרד מבדיקות הקבלה של ה-.IT Page 5 of 16
בחלק מהארגונים מקובל לבדוק את התוכנה לפי תסריטי הבדיקה ולא למול האפיון. אולם ישנם ארגונים שבהם כבר בשלב כתיבת תסריטי הבדיקה בודקים האם יש שיוני מהאפיון. תהליכי בדיקות בפרוייקטים שמתבצעים מחוץ לארגון להלן תאור של פעולות הבדיקות שמתבצעות באחד הארגונים. במקרה זה ארגון שנוהג להוציא פרוייקטים לביצוע מחוץ לארגון. בארגון זה כבר כאשר יוצאים למכרז )כלומר )RFP יש כבר פרק של QA ובהן הנחיות לספק איך ינהל את הבדיקות אצלו. השלב הבא שמתבצע על ידי הספק הוא שלב בדיקות המסירה. מדובר על בדיקות שהספק מבצע אצלו לפני שמוסר את התוכנה ללקוח לאחר תום הפיתוח. בארגון זה בשלב של בדיקות המסירה, לקראת מסירת הפרוייקט ללקוח, אין בדיקות Sanity כלומר בדיקות מנדטוריות )אשר חייבות לעבור( ובלעדיהן עוצרים את תהליך המסירה. אולם בארגונים רבים אחרים, בייחוד ממגזר הממשלתי, בהחלט מקובל להגדיר כאבני דרך בפרוייקט בדיקות מסירה. ניתן להגדיר קריטריונים קשיחים )עמידה בכל תסריטי הבדיקה( ולחילופין ניתן להגדיר קריטריונים "רכים" יותר לדוגמה קריטריוני רוחב של "עמידה ב- 81% מתרחישי הבדיקה" או קריטריונים של קריטיות של תקלות )עד 1 תקלות קריטיות(. בשלב זה הלקוח מקבל בדרך כלל את ה- STR Results( )Summary Test הכולל גם את תאור התסריטים שנבדקו ותוצאתיהם. לאחר מסירת הפרוייקט על ידי הספק מתחיל הארגון בבדיקות הקבלה שלו. קונפליקטים בתחום הבדיקות יש קונפליט בסיסי של אנשי צוות הבדיקות למול צוות הפיתוח. במיוחד הקונפליקט גדל כאשר מגיעים מפתחים\מנתחים חדשים ושאינם מכירים את העולם המקצועי כמו אנשי הבדיקות )ישנם גם מקרים שבהם הבודקים לא מכירים מספיק את העולמות העסקיים(. מצד שני ישנם לקוחות אשר דיווחו על משתמשים שהנם מאוד דעתניים ויודעים בדיוק מה שיש להם. בארגון יש להם פגישת סטטוס שבועית עם לקוח )הערת STKI בכך דומה משהו המצב לעקרונות ה-.)AGILE Page 6 of 16
פונקציית ביניים בין הלקוח, הפיתוח והבדיקות אחד הארגונים תאר מצב שבו ישנה פונקציית ביניים בין הלקוח, לפיתוח ולבדיקות. אדם זה הגיע מהעולם העסקי )במקרה זה תחום הביטוח( ולו מעל 01 שנים נסיון בעולם העסקי. כאמור הוא יושב כגורם מתווך בין הגורמים העסקיים לבין אגף הפיתוח ומחלקת הבדיקות. הוא עובד מערכות המידע. פונקצייה זו אף מקבלת מהלקוח את הדרישות, כותבת דגשים לבדיקות, מאשר את מסמך הייזום ומסמך האפיון הראשוני. אותו גורם מחפש תקלות באפיון ואף מבצע ניתוח פערים בין דרישה לאפיון כאשר השאיפה היא שתאור המתרחש במערכת יוצג בתרשימי זרימה וטבלאות החלטה. הערת STKI מדובר על פונקציה מעניינת המזכירה בעיקרה פונקציה של business BRM.relationship management מי הם הבודקים במחקר 2 STKI עלה שרובם המכריע של הבודקים הם עובדי הארגון. אכן, על פי משתתפי המפגש עלה שישנה חשיבות רבה להיכרות של הבודקים את העולם העסקי העכשווי.לדוגמא אצל אחד המשתתפים מתחום התקשורת הבודקים הם משתמשים מנוסים כלומר עובדים ממרכז השירות. לעובדים אלו המעבר לתחום הבדיקות מהווה קידום מכיוון שהם מקבלים בתהליך ההסבה קורס מסודר של בדיקות תוכנה..LOB לעיתים אחד הארגונים תאר מצב לא שכיח שבו תקציבי הפרוייקטים מתקבלים מה- ישנה "התמקחות" על עלויות ואז ה- LOB מביא אנשי בדיקות מטעמו! http://www.slideshare.net/pini/stki-application-developmentresearch 2 Page 7 of 16
בדיקות עומסים בדיקות עומסים לא מתבצעות על ידי כל הארגונים וגם ארגונים שמבצעים אותן לא עושים זאעת בכל מקרה כל מערכת וכל ייצור. כאשר מדובר על מערכת חדשה ובמידה ואפשר, יש לבצע בדיקת עומסת בסביבת הייצור. ישנם ארגונים אשר מבצעים בדיקות עומסים בסביבת ה- QA כאשר ההנחה היא שסביבת הייצור חזקה יותר מסביבת ה- QA ולכן אם המערכת עברה בדיקת עומסים ב- QA הרי שהביצועים בסביבת הייצור יהיו טובים יותר. מעבר לכלים הידועים HP(,Radview,IBM, מיקרוסופט וכד'( הוזכר גם Jmeter לבדיקות עומסים בסביבת WEB למערכות.JAVA ישנה גם Shunra המאפשרת לבצע סימולציה של סביבת WAN על תשתית בדיקות רגילה שמותקנת ב- LAN ובכך מאפשרת לקבל תוצאות דומות יותר של סביבת הבדיקות למציאות האמיתית מחוץ לארגון. בדיקות רגרסיה לרוב הארגונים ישנם תהליכים של בדיקות רגרסיה. לדוגמה, אחד הארגונים תאר מצב שבו יש בדיקות רגרסיה קבועות למספר של 2-1 תהליכים חשובים בארגון זה מדובר על תהליכי הפצה של מוצרים. בגלל חשיבות התהליכים כל נגיעה הכי קטנה- אפילו קינפוג "קטן" בתחום התשתיות מבצעים את בדיקות רגרסיה. כלים בתחום הבדיקות משפחת הכלים המובילה היא פתרונות HP לתחום הבדיקות. הן בהקשר של ניהול הבדיקות והן בהקשר של אוטומציה. יש לקוחות אשר לא משתמשים באוטומציה של HP מטעמים של עלויות. רוב הלקוחות עובדים בכלים הסטנדרטיים של HP בתחום זה עם כי ישנם לקוחות אשר מתחילים גם להטמיע כלים מתקדמים כמו.Business Process Testing אולם לאחרונה רואים גם כניסה של מיקרוסופט לתחום הבדיקות גם ניהול הבדיקות וגם אוטומציה. משתתפים דיווחו שהמפתחים מעוניינים לעבוד בסביבת ALM אינטגרטיבית ולכן הם מעדיפים לעבוד בסביבת ה- Team Foundation Server( TFS ומתוכו ב- MTM )Microsoft Test Manager המוכרת. בגרסאות החדשות של TFS של מיקרוסופט ניתן לנהל את הבדיקות וניתן גם לבצע אוטומציה של בדיקות כולל בדיקות GUI אשר מוגדרות Page 8 of 16
במיקרוסופט כ-.Coded UI 3 לקוחות ציינו שהכלי התקדם בצורה משמעותית אך לדוגמה עדיין לא כל הפרוטוקולים נתמכים )לדוגמה GUI של.)SAP חלק מהלקוחות גם עוד לא הצליח לממש ב- TFS קשר מלא בין פרוייקט-דרישה )של פרוייקט( משימה של מפתח item( )work קוד.BUG ישנם לקוחות אשר כן תארו מצב שבו קשר זה עובד בתצורה תקינה. כמו כן לגבי סוגיות של ADMIN לדוגמה בהקשר של הרשאות, בדיון נטען שטיפול בהרשאות ברמת שדה וערך בשדה )תקינות ערכים( מורכבת יותר מ- QC של.HP אפשרות אחרת היא להשתמש ב- synchronizer שמקשר בין ה- TFS לבין סביבת.HP כלי זה מסנכרן באגים ודרישות בין לקוחות גם ציינו כלים נוספים כגון.HP לבין TFS 4 WEB של אפליקציות DEBUG להקלטה וביצוע Fiddler עם זאת לקוחות משתמשים גם בכלים אחרים. לדוגמה לקוח תאר מצב שבו יש שימוש ב- Solution manager של.SAP הפידבק היה שהכלי טוב אך במקרה שלהם חייב קיסטום משמעותי וגם עקומת לימוד שאינה מבוטלת. שימוש בכלים פנימיים לקוחות גם תארו שימוש בכלים פנימיים כלים שפותחו בתוך הארגון. לדוגמה לקוח תאר מערכת WEB שפתחו בעצמם על SPS- MOSS ושם מנהלים את בדיקת פרוייקט תיק הבדיקות, הפניה לבודק מסויים, איזה סוגי מסמכים, כל האינטגראציה בין הבודק למפתח כל מה שצריך לתעד כולל מעלים מיילים רלוונטיים, אישורים של הבדיקות וכד'. זאת בתוספת למערכת ה- EPM הארגונית, מערכת שבה מנהלים פרוייקטים ולכן היה קל היה להוסיף חלק זה. לקוחות נוספים תארו מצב שבו את מסמכי האפיון מנהלים בסביבת ה-.SPS-MOSS לקוחות מתחילים להשתמש בפתרונות מיקרוסופט ובדיון עלו תכונות משופרות מעבר לכתיבה קלאסית של תסריטים. לדוגמה הבודק יכול להקליט את הרצת התסריט ואת הבעיה שהתגלתה ולהעביר סרט וידאו זה למפתח. מצד שני שימוש נרחב ביכולת זו עלול לעיתים לגרום לבעיה של ביצועים. לקוחות שוקלים גם שימוש ב- VDI לסביבת העבודה של הבודקים 3 http://msdn.microsoft.com/enus/library/dd380742.aspx להלן לינק לתאור הסביבות אשר נתמכות ב- Coded UI של מיקרוסופט 4 /http://www.fiddler2.com/fiddler2 Page 9 of 16
וכך יוכלו להעביר למפתחים באגים כולל סביבת העבודה שבה הבאגים נוצרו. הדבר אמור לחסוך זמן רב לבודקים לשחזר את כל סביבת העבודה בה נוצר הבאג. Test Driven Development TDD ב- Test Driven Development המפתחים אשר אמורים לכתוב את ה- Unit Testing כותבים זאת לפני הקידוד בפועל. בדיון לא היו משתתפים אשר אימצו תפיסה זו אולם התפיסה כן נראית מועילה ולקוחות דיברו על כוונה לבדוק יישום של תפיסה זו. Unit Testing ה- Testing Unit היא בדיקה של רמת הקוד הקטנה ביותר )פרוצדורה, פונקציה, מסך( והיא אמורה להכתב ולהתבצע על ידי המפתחים. בחלק מהארגונים המפתחים אכן מבצעים זאת וגם מתעדים זאת בסביבת ניהול הבדיקות )כאמור ברוב הארגונים מדובר ב- Quality Center של )HP אולם הרושם היה שביצוע ה- Unit Testing על ידי המפתחים לא מתבצע בכל הארגונים בצורה מסודרת. אחד הארגונים שמיישם AGILE תאר מצב שבו מבצעים unit testing "לפי הספר" אך מי שכותב את ה- Unit testing הוא הבודקים שנמצאים ב- Agile צמוד למפתחים. זאת מן הטעם שעלות המפתחים יותר יקרה. מדדי איכות וערכם תחום הבדיקות "משופע" במדדים. זאת מכיוון שזהו אחד התחומים שיותר קלים למדידה )"יש BUG או אין"(. בדיון לקוחות התבקשו לדבר על מדדים ועל ערכם. להלן מספר דוגמאות: DDP defect detected percent שהוא אחוז באגים שמתגלים בייצור מסה"כ באגים שהתגלו. בדיון עלה שארגונים מגיעים לערך של כ- 01% במדד זה. כלומר בארגון זה 0 ל- 01 באגים מתגלה רק בייצור. אחד הארגונים משתמש ב"כלל החזרה לפיתוח" לא ממשיכים לבדוק אלא מחזירים את הפרוייקט לפיתוח ללא סיום הבדיקה. עבור פרוייקט קטן מעל 1-4 באגים יבצעו "החזרה". בפרוייקט גדול )מעל 011 ימי פיתוח( מעל 01 באגים יחזירו לפיתוח )מדובר בבאגים חמורים(. בארגון שעובד ב- AGILE המדד הוא 0-2 תקלות לספרינט. כלומר אם יש יותר מ- Page 10 of 16
0-2 באגים בסיום הספרינט לא יעלו את התוצרת לייצור )למעט מצב שהלקוח מאשר מפורשות(. מדד של אחוז תקלות שנפתחות בייצור ביחס לכמות זמן הפיתוח בימים. המדד שהוזכר בדיון היה 1.22 כלומר 2.2 תקלות שהתגלו בייצור ל- 011 ימי פיתוח. ארגון אחד מתייחס למדד בצורה קצת שונה- המדד שהוזכר הוא בין 1-4 תקלות לחודש פיתוח של צוות )לא של מפתח בודד(. מספר תקלות משביתות\חמורות לכל מודול מערכת דובר על 0-2 תקלות כאלו פר מודול לחודש. כמה תקלות שנפתחו טופלו ב- service desk וכמה הגיעו לפיתוח. בארגון זה מדובר על 61% מהתקלות שנסגרות כבר ב-.service desk ישנם ארגונים שבהם כאשר יש תקלה ה- service לאחר מכן לפיתוח. במידת האפשר ה- ורק יעביר את התקלה לQA service desk desk מקליטים תקלה. בדיון גם עלו מספר מדדים ללא התייחסות לערך המדד: זמן לסגירת באגים כמה זמן עובר מאז שנתגלה באג בייצור. מדד של שביעות רצון לקוח. בדיקה של אפקטיביות עד כמה השתמשו בדברים שפותחו.. QA יחס באגים לכמות פרוייקטים שעלו לאוויר לאחר במחקר שערך חברת STKI בנושא פיתוח מערכות בארגוני IT עלו מדדים ראה רבים נוספים. http://www.slideshare.net/pini/stki-application-developmentresearch עמ'.21-22 AGILE חלק גדול מהלקוחות הנם בתהליך של בדיקה או הטמעה של.AGILE לטענת לקוחות שכבר מיישמים מתודולוגיה זו פיתוח במודל Agile מקטין הפתעות, מקטין חוסר ידיעה כאשר בהקשר של בדיקות הבודקים יושבים באותו חדר עם כולם )גם מפתחים וגם מנתחים( ועובדים יחדיו מהשלב הראשון. כולם עובדים ביחד על "איך יפתחו ואיך יבדקו". בניגוד לבדיקות "רגילות" בתוך ספרינט לא מתעדים את כל הבאגים שמתגלים מכיוון שרובם מטופלים בזמן הספרינט. כמובן שאם יש באגים פתוחים בסוף הספרינט הם מתועדים. ב- Agile חשוב לבצע במידת האפשר Continues Integration כלומר מוודאים שמקמפלים את כל המערכת בכל סוף יום וברצוי גם לבצע בדיקות רגרסיה. לפיכך אוטומציה של בדיקות חשובה מאוד כאשר מפתחים.Agile Page 11 of 16
העובדה שיושבים ביחד ויוצרים יחסי רעות בין הבודקים והמפתחים עלולה לגרום לפגיעה באיכות הבדיקה אולם לטענת המשתתפים בדיוק בפיתוח ב- AGILE הדבר לא קורה. איכות הבדיקה גבוהה ואפילו משתפרת. רגולציה וסטנדרטים מבחינת רגולציה או סטנדרטים בתחום הבדיקות לקוחות הזכירו עמידה ב- iso90001 ובעתיד כנראה גם. iso20000 ישנם גם לקוחות שחייבים לעמוד בבחינות של.SOX לטענת הלקוחות בודקי ה- SOX אינם אמונים על פיתוח אפליקציות ואיכות תוכנה אך עדיין שואלים את השאלות שהוכתבו להם "תראה לי תסריטים", "תראה לי תיעוד תקלות" וכד'. לדברי המשתתפים SOX מחייב גם לערבל נתונים במעבר מסביבת הייצור לסביבות האחרות. תגובות של ספקים מיקרוסופט בבחינה של ה MTM כרכיב לניהול הבדיקות כחלק מפלטפורמת ה ALM )(Application Lifecycle Management של מיקרוסופט, אנחנו האופן מובהק יכולים להבין את היתרון המשמעותי שקיים רק במערכות שיודעות לתת פלטפורמה מלאה והוא החיבור של כל העולמות, הצוותים והגורמים השונים שמעורבים בפרויקט למקום אחד. השילוב של הנתונים מאפשר בכל רגע קבלת סטאטוס מעודכן ומקיף שמציג נתונים על הפרויקט בשלביו השונים. כל אחד מהגורמים השונים שמעורב בפרויקט מקבל סביבה אחת אשר מותאמת לצרכים שלו ומרכזת לו את כל התהליכים הנחוצים לו לביצוע העבודה באופן המיטבי ביותר במקום אחד וללא צורך במעבר וניסיון לסנכרן עם מערכות רבות אחרות )לדוגמה לבודק, מפתח, מנהל הפרויקט, הארכיטקט וכו'(. במהלך העבודה, כל הנתונים מגיעים לשרת מרכזי אחד ( Foundation TFS Team,)Server אשר יודע לרכז את כל הנתונים. Page 12 of 16
החיבור בין התהליכים השונים לתהליך אחד מאפשר עבודה יותר אינטגרטיבית בין הצוותים השונים ומציג את התמונה הכוללת והנכונה לסטאטוס הפעילות של הפרויקט. יכולות שקיימות ב MTM כגון Test Impact Analysis, Data Collectors, Fast Forward אשר מאפשרות לצוות הבודקים ללא צורך בעבודה נוספת, לקבל הרבה יותר נתונים על הגרסה אותה הוא הולך לבדוק )מה השינויים שהתקבלו, אילו בדיקות הושפעו בעקבות השינויים וכו'( הערבת נתונים עשירים ומלאים אשר מקלים בתהליך זיהוי ותיקון הבאג על ידי המפתחים, קישור לאורך התהליך לניהול הדרישות והמלצות לעדכונים של לוחות הזמנים של הפרויקט ועוד יכולות רבות אחרון, מתאפשרות רק על ידי עבודה משותפת של הגורמים המעורבים בפלטפורמה אחת שתומכת בכל הגורמים המעורבים, וזה יתרון משמעותי ובלעדי שניתן על ידי פתרון ה ALM של מיקרוסופט.Visual Studio 2010 IBM אחד המושגים החמים בשוק הוא, ALM לקוחות מעוניינים לראות מחזור חיים מלא ומקושר ברכיביו אחד לשני כך שכל המידע יהיה זמין מכל מקום מבלי להתחיל ולחפש אותו בקישורים כאלה ואחרים ולכן עולות השאלות הבאות: איך דרישה נפרטת למשימות פיתוח וממומשת ונכללת בתוך ה? build איך בודק יודע שה build הסתיים בהצלחה על מנת לבסס את הריצה של testcase שאמור לכסות את הדרישה? איך ריצה שנכשלה מכילה מידע על באג שנפתח שמקושר ל? build איך כל המידע הזה מתקשר אחד לשני באופן הרצת דוחות? הפיתרון של IBM בתחום עונה על כל הדרישות הללו היות הוא מבוסס על טכנולוגיה חדשנית המאפשרת שיתוף ברמה כזו, כך שהמידע המבוקש זמין מכל מקום ונגיש בקלות. בנוסף הדגש שצריך להוביל הוא שיתוף בין כל בעלי העניין בארגון מנהל פרויקט,ראש צוות פיתוח,ראש צוות בדיקות, בודקים וכו.היות וכל המידע זמין וניתן לניתור בכל רגע נתון מיתר את כל ההתכתבויות האין סופיות בדוא"ל וטלפון בשביל להבין סטטוס Page 13 of 16
HP יוצאת בימים אילו עם חיזוק משמעותי לבשורת ה- HP -מלפני שנה.להלן המערכת. ALM המטרה ניהול מחזור חיי האפליקציה משלב התכנון ועד לשלב הבניה והשחרור תוך תקשורת יעילה בין השחקנים השונים. כיום יכול לקבל נתוני קדם דרישות מקצועיים. כגון אריס. יבוא כזה של נכסים יכול להוות בסיס לדרישות אפליקטיביות ממגוון סוגים)פיתוח,בדיקות,שיווק וכו,( כשהדרישות נמצאות במערכת כל השחקנים שצריכים לעבוד מול דרישות אלה יכולים לגשת אל הדרישות ולבצע את משימותיהם. מנהל פיתוח רואה את דרישות הפיתוח ויכול למנות מפתחים כבר בתוך ה- ALM' מפתחים יראו את המשימות במערכת או ישירות בתוך סביבת הפיתוח שלה תו שימוש ביכולת מימשוק חדשה. המפתחים יוכלו גם לעדכן סטטוס של הדרישה מתוך סביבת הפיתוח. מנהל הפיתוח יוכל לעקוב אחר קצב השלמת הפיתוח תוך שימוש במערכת או ע"י מעקב בכלי ניהול קונפיגורציות שיכול להיות ממומשק למערכת ולסביבת הפיתוח. מנהל הפיתוח יכול לשנות מצב של הדרישה ל פותח ו מוכן לבדיקות. בשלב זה מנהל הפיתוח יכול לעקוב אחר עלויות וקצב הפיתוח תוך שימוש בדוחות. אנו תומכים במערכות ניהול גרסאות וקונפיגורציה פופולריות. מנהל הבדיקות יוכל לקלוט את כל הדרישות המוכנות לבדיקה ולהתחיל מחזורי בדיקות ע"י מינוי אנשי בדיקות למחזורי בדיקות. באגים שידווחו במערכת יקלטו ע"י מנהל הפיתוח שיפתח במחזור תיקונים דומה לפיתוח. בסיום הבדיקות, כל המנהלים יוכלו לראות את ההתקדמויות תוך שימוש בשלל דוחות. מנהלי המוצר יוכלו גם לעקוב אחר קצב ההתקדמות מבחינתם. חידוש נוסף הוא מערכת ALI תוספת זו מאפשרת חיבור ישיר בין עץ הדרישות במערכת לבין מערכת ניהול הקונפיגורציה וגירסאות בהם משתמש הפיתוח. כך ששינוים שיתבצעו בכלי הקונפיגורציה ישתקפו במערכת כבסיס למחזור חיי מוצר. Page 14 of 16
אם נסכם את כל החידושים נראה שבעולם החדש כולם יכולים לדבר עם כולם. והשחקנים יכולים להמשיך להשתמש בטכנולוגיות ובכלי קונפיגורציה החביבים עליהם. אנחנו כבר נחבר בינהם. טסקום תמונת המצב, כפי שעולה מהסיכום, משקפת נכונה את המציאות בשטח. לדבריה, שימת הדגש בנושא הבדיקות בתחום הטלקום והבריאות הינה תוצר, המתחייב על פי נהלים ורגולציות. ייתכן, כי היה על הגורמים השונים לפעול למען מטרה משותפת של קביעת סטנדרטים ברורים גם בתחומי פעילות נוספים. זאת ועוד, לא אחת מתמודדים ספקי שרות דוגמת טסקום בהיעדר מנהל פרויקט/ Product.Manager זה המקום להדגיש, כי תפקיד מנהל הפרויקט הינו הכרחי להצלחת הפיתוח והייצור בכלל והבדיקות בפרט, שכן הוא מהווה מוקד ידע וניהול, מתווך בין הדרישות והאינטרסים השונים, מקל על הגורמים העוסקים בדבר ואחראי לעמידה ביעדים. Page 15 of 16
בדיקות על סוגיהן השונים, היו וימשיכו להוות חלק בלתי נפרד מתהליכי מחשוב מתקדמים. השינויים, קרוב לוודאי, יחולו בהתבססותן של טכנולוגיות חדשניות אשר יתרמו לייעול התהליכים. Page 16 of 16