מדריך - איזה תואר ללמוד כדי להיות מהנדס בדיקות

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

לבדוק ידנית או אולי אוטומטית?

ענף בדיקות התוכנה מתחלק לשני סוגים עיקריים ושונים במהותם:

בדיקות ידניות

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

בדיקות אוטומטיות

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

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

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

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

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

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

בדיקות חומרה

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

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

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

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

אם הווריפיקציה היא הבדיקה שנעשית לשבב, לפני שהוא מיוצר, הרי ש-ATE היא הבדיקה שנעשית לשבב לאחר שהוא מיוצר. משמעות ראשי התיבות היא "ציוד לבדיקה אוטומטית", וכפי שהשם מצביע, מדובר בציוד בדיקה שמאפשר לתכנת אותו, על מנת שהוא יריץ סדרת בדיקות אוטומטיות על החומרה הנבדקת (שמכונה DUT – Device Under Test). התיכנות של ציוד הבדיקה (צב"ד) מבוצע בשפות יעודיות (LabView), והוא נעשה על ידי מהנדס (עם תואר בחשמל ואלקטרוניקה) או על ידי הנדסאי.

להכנס לתוכנה בדלת האחורית

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

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

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

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

ואיך עושים את המעבר הזה

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