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

הפוסט הזה בדיוק בשבילכם.

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

מחזור חיי התוכנה בנוי כידוע מהשלבים הבאים:

1. איפיון צרכים
2. ניהול הפרוייקט
3. פיתוח התוכנה
4. בדיקות התוכנה
5. העברה לייצור

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

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

סוגי בדיקות התוכנה

בדיקות התוכנה נחלקות בין בדיקות ידניות ובדיקות אוטומטיות (אוטומציה).

בודק התוכנה הידני (נקרא גם איש QA או מהנדס QA) מקבל תסריטי אפיון ותהליכי עבודה ונדרש בצורה ידנית לדמות עבודה מול המוצר (כמו הזנת מידע בשדות בטופס ולחיצה על כפתור לראות את ההשפעה של זה) ממש כפי שמשתמש היעד אמור לעבוד מול מוצר התוכנה.  לצורך כך מתכננים קודם את תהליך הבדיקות הצפוי (כגון גרסה, נושאי הבדיקות, מתודולוגיות הבדיקה ועוד) במסמך שנקרא STP ( Software Test Plan). לאחר מכן מתכננים את הבדיקות עצמן (לפי נושאים וקטגוריות) במסמך בשם STD ( Software Test Description). לעיתים, חותמים את כל התהליך בסוג של דוח, מסמך בשם STR ( Software Test Report).

זה היה תיאור תהליך העבודה של בודק ידני, איש QA.

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

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

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

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

מה נדרש מבודקי תוכנה?

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

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

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

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

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

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

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