למה צריך בדיקות תוכנה? הסבר לבן דוד שלא מהתחום

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

מצד שני, כשאנו משתמשים בתוכנה הזו, בין אם היא תוכנת עסקים רצינית ובין אם היא משחק, אנו מצפים - ואפילו דורשים - שהיא תפעל כראוי. "תפעל כראוי" - כלומר לא תעשה משהו שהיא לא אמורה לעשות, ותעשה את כל מה שהיא כן אמורה לעשות.

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

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

תהליך הבדיקות הוא במובן מסוים הדבר הכי קרוב שיש בין כתלי החברה שדומה לתהליכים שעובר הלקוח. תפקידנו למצוא את הבעיות שלקוח ממוצע אמור להיתקל בהן: בעיות פונקציונליות (לחצתי על כפתור שאמור לשלוח הודעה ולא קרה כלום), בעיות של מהירות תגובה, בעיות בשימוש מסורבל וכד'.

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

בעולם כזה תפקידו של הבודק הוא קריטי. הרבה פעמים הוא זה שמביא להצלחת מוצר ומונע זליגה של לקוחות.


חיי הבודקים אינם קלים:

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

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

במקור: מאמר מהבלוג מתאריך 29.01.2008