לא צריך להיות מומחה בטכנולוגיות היי-טק, כדי להבין שיחידות שאמורות לפעול בתוך מערך כללי, חייבות לא רק לעמוד בדרישות הספציפיות מהן, אלא גם להשתלב במערך הכללי כך שישרתו כראוי את המטרה הסופית. רוית דניאלי, מנהלת תחום בדיקות בכלנית כרמון, אוהבת לפשט את העיקרון הזה בדוגמא הבאה: כאשר מריצים מנוע חדש, לא מספיק לדעת שיחידת המנוע כיחידה עצמאית עובדת במאה אחוז. צריך גם לוודא שאותה יחידה משתלבת ומתאימה לדרישות החלקים האחרים ברכב בו הוא יותקן, כדי ליצור הרמוניה תפעולית.
שירות מנוהל לבדיקת איכות
בעולם ה-IT, פעולות אלה נקראות "שירות מנוהל לבדיקות איכות". רוית דניאלי מפשטת ומסבירה שוב: "בבואנו לבדוק תוכנה, אנו בודקים שני היבטים מרכזיים: הפונקציונאליות הנדרשת לצורך תפקוד מלא של התהליך העסקי, וכן התאמה מלאה של המערכת לדרישות המשתמש. שכן לא פעם קורה שמשתמש מסוים תאר צורך ספציפי בתחומו, והמתכנת הבין זאת מעט אחרת, מספיק שלא היה דיוק בכתיבת מסמך האפיון וכבר יתכן שהפתרון האפליקטיבי לא יהיה מלא או מדויק.בנוסף, אם מסמך האפיון לא יהיה סגור ומסונכרן, יתכן מצב בו בעת הפעלת ישום מסוים שהוזמן על-ידי משתמש - תיווצר התנגשות עם פעולות אחרות של המערכת".
החזרה לדוגמא המופשטת של המנוע והמכונית - חוזרת ומתבקשת. ייתכן שמזמין הרכב ביקש שהגיר האוטומטי יחליף הילוכים ברגע שהמנוע יגיע למספר סיבובים מסוים, מול תנאי הדרך. אבל תוך ניהול נכון של בדיקות האיכות, התברר שדרישת המשתמש לא הייתה ברורה, או שתנאי הדרך הם כאלה שהסטנדרטים שביקש המשתמש אינם הולמים אותם.
מסמך הדרישות
מסבירה רוית דניאלי: "שירות QA מנוהל מתחיל בכך שאנו מקבלים את מסמך הדרישות שכתב כל משתמש ומתחילים לבדוק אם אנחנו מבינים אותו נכון. לשם כך אנו נעזרים בקבוצת משתמשים מובילים שאנו בוחרים מתוך הארגון, ולהם ידע מעמיק ויכולת להיות מובילי תהליך, אותו משתמש, רצוי שיכיר מקרוב את עבודת מחלקת ה-IT בארגון, אך אין הדבר מחויב המציאות. לאחר הדרישות שבוצע בארגון שלב איסוף הדרישות, וכן נכתבו מסמכי אפיון, אנו מבצעים השוואה ובודקים האם כל דרישה קיבלה מענה באפיון. לאחר השלמת שלב זה, מתחילים לבנות את סט הבדיקות כנגד כל דרישה וקושרים בין הדרישה, מספר האפיון ובין תסריטי הבדיקות הרלוונטיים כדי לוודא שהאחרונים עונים לדרישות המשתמש ובודקים אותם.
למשל לצורך הדוגמא, אם המשימה היא לבדוק תוכנת בילינג לחברת סלולר, שאחד המשתמשים ביקש לכלול בה אפשרות לחיוב בכרטיסי אשראי - לא נסתפק בבדיקה שהפונקציה אכן קיימת. אנחנו נעמיק ונבדוק מולה את כל סט הדרישות של המשתמש, וכן את יכולת קיומה במכלול של התוכנה כולה. רק לאחר שנמצא הלימה והרמוניה מושלמות - נדע שהאפליקציה עומדת במבחן האיכות...
יוצרים מחויבות
להליך ניהול הבדיקות יש ערך מוסף חשוב: בעקבות הבדיקות המפורטות, נוצר גם סט של FAQ, תשובות מפורטות לשאלות נפוצות, שהמשתמשים בוודאי יעלו - הן במסגרת בדיקות משתמשים והן לאחר שהמערכת תעלה לאוויר. "בדיקות מנוהלות של איכות תוכנה, יוצרות קשר של מחויבות בין מי שמבצע אותן לבין הארגון המזמין, משום שבמהלך העבודה הבודקים לומדים להכיר מקרוב את הארגון על התהליכים העסקיים שלו, את הצרכים היומיומיים שלו וגם את הצורך הנדרש להעלאת המערכת לאוויר", מסבירה רוית דניאלי. "מסיבות אלה, פעמים רבות מעדיף הארגון שאת עבודת ההטמעה וההדרכה יעשה הגוף הבודק משום שמתוך היכרות קרובה עם רצונות הארגון, העסק והמערכת הוא יהיה היעיל והמקצועי ביותר."
הליך שירות הבדיקות המנוהל, נוצר כהתפתחות טבעית של תחום בדיקות התוכנה. אם בתחילה הבודקים נדרשו לבדוק רק תסריטים שכתב עבורם המפתח, אחר כך הם היו אלה שכתבו את התסריטים והודיעו למפתח מה הם הולכים לבדוק - הרי שהיום הבודקים רואים עצמם אחראים לא רק על תקינות האפליקציה, אלא על ביצוע התהליך באופן איכותי בארגון כולו. "אנחנו, בכלנית כרמון, רואים את עצמנו כיום לא כאנשי בדיקות תוכנה בלבד - אלא כאנשי בקרת איכות כוללת, ותפקידנו לוודא לא רק שתוכנה מסוימת מתפקדת, אלא גם לבדוק את כל מה שמסביב, שכל גורמי הפרויקט הבינו מה נדרש ומדברים בשפה אחת, מבינים את התהליך באותו אופן, ומספקים ללקוח פתרון איכותי מקיר-לקיר בארגון", מסכמת רווית דניאלי.
