הבטחת איכות או אבטחת איכות?// - בואו ננפץ כמה מיתוסים מעולם בדיקות התוכנה...

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

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

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

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

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

לאחרונה פותחו שיטות שונות ומתקדמות המנהלות את אורך חיי הפיתוח של המוצר, ומאפשרות לקבוצת הבדיקות להשתלב בבדיקת המוצר כבר בתחילת הפיתוח.

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

בואו ננפץ 5 מיתוסים מעולם הבדיקות:

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

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

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

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

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

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

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

4. את תפקיד הבדיקות יכול לעשות כל אחד, אפילו אדם שלא למד ולא הוכשר כבודק, וכן אדם שסיים לימודים כלשהם על אף שאינם רלוונטיים לעולם הבדיקות בו הוא עוסק.

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

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

הסמכת ISTQB על כל רמותיה מביאה את אנשי הבדיקות לרמת מקצועיות מעולה ונותנת את הכלים הנכונים לבודק להיות בודק מקצוען. יותר ויותר ארגונים מבקשים את ההסמכה כתנאי כניסה לתפקיד הבודק ו/או מסמיכים את הבודק בעצמם. ניכר כי הסמכה זו מיצרת מגמת עליה ברמת המקצועיות של בדיקות האיכות מה שישפיע באופן ישיר על השפעתו של ארגון הבדיקות על רמת הוצאת מוצר התוכנה לשוק.

5. הדרך הנכונה והזולה ביותר לבצע בדיקות היא ע"י מיקור חוץ, קבוצה חיצונית כלשהיא, שלא חייבת לשבת בתוך הארגון.

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

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

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

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

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

מחויבת להצלחה שלכם, כנגד כל השיפועים,

שלכם,

שירלי.

#photo