המשך המאמר מכאן. (כדאי לעיין בכדי שהמשך המאמר הנוכחי יהיה ברור).
Test Engineer
בעוד שברור לכולם ששאר התפקידים דורשים ידע קידוד מובנה, הרי שגם ה-TE חייבים לדעת קוד. גוגל כותבים במפורש שמי שאינו יודע לקודד הוא אזרח סוג 2. בעוד שאני מסתייג מהאמירה הזו, הרי שבודק שיודע לכתוב אוטומציה ככלי עזר (גם אם לא שולט בקוד כמפתח למשל) יכול לבדוק את המוצר פוטנציאלית טוב יותר מבודק שאינו יודע. גם אצלנו ב-AVG אנו מחפשים בודקים שיש להם ידע בכתיבת קוד.
ה-TE נכנסים לתמונה יחסית מאוחר בתהליך הפיתוח (עד אז יש UT ואוטומציה). כשהם נכנסים עליהם להחליט למשל:
- נקודות חולשה במוצר.
- בדיקות סקיוריטי, פרטיות, ביצועים וכד'.
- המוצר אל מול מוצרים אחרים שהוא עובד איתם.
- במקרה של בעיות, עד כמה הדיאגנוסטיקה טובה.
ה-TE הם היחידים שכל תפקידם למצוא נקודות חולשה במערכת. הם מתרכזים בשימוש במערכת כמערכת. הם עוסקים בדרישות לא ברורות. כשה-TE מגיע לפרוייקט, עליו להעריך האם המוצר מוכן לבטא, והם מתחילים לעשות Exploratory Testing.
תפקידי ה-TE הם:
- תכנון הבדיקות וניהול סיכונים.
- בדיקת הדרישות, הדיזיין, הקוד והבדיקות הקיימות.
- Exploratory Testing.
- סנריו של לקוח.
- כתיבת טסט קייס.
- ביצוע של הבדיקות הנ"ל.
- קראוד טסטינג.
- מטריצת שימוש.
- פידבק משתמשים.
באף מקום לא מצאתי הגדרה ברורה של TE אלא יותר מה ה-TE עושה.
ממה שאני מבין זה דומה למה שצוות ה-End Game עושה אצלנו ב-AVG.
Test Plan
לגבי טסט פלאן נוצר רק עם זה חשוב לפרוייקט, עובר ריוויו ומשתנה במהלך חיי הפיתוח. הוא חייב להיות מעודכן תמיד, מתאר את המוצר, את פעולותיו וכיצד הוא עושה זאת. עד כאן לא זה נראה כמשהו של מוצר ולא של בדיקות.
הוא אמור להיות מוכן בקלות, ולתאר את מה שאמור להיבדק. המסמך אמור להיות שימושי ולעזור בקביעת ההתקדמות ופערי הכיסוי. ה-TP חייב לקשר לבדיקות בפועל.
בגוגל משתמשים ב-Attribute Component Capability כ-Test Plan.
מסמך זה אמור להכיל רשימה של דברים חשובים בלבד, לגרום למי שמתכנן את הבדיקות לחשוב על הבדיקות בפועל והתוצאה של ה-ACC הוא טסט קייסים.
ה-ACC מכיל:
- תיאורים של המוצר ומטרתו - מדוע אנו בונים אותו, איזה ערך הוא נותן, מדוע זה יעניין את הלקוח. למשל כרום מהיר, בטוח, יציב וכד'. מכאן גוזרים למשל בדיקות של מהירות וכד'.
- מה המוצר מכיל - חלקים ופיצ'רים. הרשימה צריכה להיות קצרה. 10 זה בסדר, 20 לא.
- ומה הוא עושה (חייב לנבוע מהמטרות). למשל באתר קניות הוצאה והכנסה לסל, לתמוך בתשלומים וכד'. חשוב מאוד שהיכולות ניתנות לבדיקה.
כמה עצות ליכולות:
- כדאי שיהיו כתובות כפעולות.
- כל יכולת צריכה לתת לבודק הבנה על המשתנים. למשל ב"לעבד טרנסאקציות של תשלומים ב-HTTPS" מחייב שהבודק יבין אילו סוגי עיבוד תשלומים אנו תומכים.
- הסבר על יכולות אלה צריך להיות משולב ביכולות אחרות.
את היכולות מתרגמים לבדיקות:
- כל יכולת מתורגמת לפחות לטסט קייס אחד, רבים ליותר מאחד כולל משתנים.
- חלק מהיכולות חשובות יותר. כדאי להשתמש בניהול סיכונים.
מצ"ב ה-ACC של גוגל פלוס:
התיאור של המוצר:
ממה הוא בנוי:
מה הוא עושה:
אין תגובות:
הוסף רשומת תגובה