איך בודקים תוכנה בגוגל חלק ב: מהנדס הבדיקות ותוכנית הבדיקה

המשך המאמר מכאן. (כדאי לעיין בכדי שהמשך המאמר הנוכחי יהיה ברור).

  

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  מכיל: 

1. תיאורים של המוצר ומטרתו - מדוע אנו בונים אותו, איזה ערך הוא נותן, מדוע זה יעניין את הלקוח. למשל כרום מהיר, בטוח, יציב וכד'. מכאן גוזרים למשל בדיקות של מהירות וכד'.
2. מה המוצר מכיל - חלקים ופיצ'רים. הרשימה צריכה להיות קצרה. 10 זה בסדר, 20 לא.
3.  ומה הוא עושה (חייב לנבוע מהמטרות). למשל באתר קניות הוצאה והכנסה לסל, לתמוך בתשלומים וכד'. חשוב מאוד שהיכולות ניתנות לבדיקה.

כמה עצות ליכולות:

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

את היכולות מתרגמים לבדיקות: 

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

מצ"ב ה-ACC של גוגל פלוס:

התיאור של המוצר: 

ממה הוא בנוי:

מה הוא עושה:

מקור

• Nov 14, 2015

איך בודקים תוכנה בגוגל חלק א: תפקידים ובדיקות

מתוך: How Google Tests Software

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

  

תפקידי הפיתוח העיקריים בגוגל הם:

Software Engineer - SWE – כלומר מפתח.

Software Engineer in Test - SET – מפתח שאחראי על הטסטביליות והתשתיות של הבדיקות. הם מפתחים framework לאוטומציה ול-unit tests ומפתחים אוטומציה, דברים שעוזרים למפתח לבדוק את הקוד שלו.

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

  

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

  

סוגי הבדיקות הם:

Small Tests – בד"כ הבדיקות הללו הן אוטומטיות ובודקות פונקציה או מודול (כלומר Unit Test) ונכתבות בעיקר ע"י המפתחים. בד"כ מצריכים מוקים וסביבות לא אמתיות. הבדיקות אמורות לענות לשאלה: האם הקוד עושה את מה שהוא אמור לעשות?

Medium Tests – בד"כ בדיקות אוטומטיות של שני פיצ'רים או יותר (כלומר בדיקות אינטגרציה). הפוקוס הוא על האינטראקציה ביניהם. הם נקראים פונקציות מהסביבה הקרובה. בהמשך תהליך הפיתוח גם ה-TE יכולים להריץ בדיקות אלה אן ידנית (במקרה שקשה או לא שווה להפוך לאוטומטי) או בהרצה של אוטומציה. הבדיקות אמורות לענות לשאלה: האם סט של פונקציות מהסביבה הקרובה עובדות האחת עם השנייה בדרך בה הן אמורות לעבוד?

Large Tests – מכסות שלוש אך בעיקר יותר פיצ'רים ומדמות משתמש קצה (בדיקות מערכת): תרחישים של משתמשים, דטה של משתמשים ולוקחים שעות או יותר להריץ. הבדיקות אמורות לענות לשאלה: האם המוצר מתפקד בדרך לה המשתמש מצפה והוא מייצר את התוצאות המצופות?

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

  

היחס בין סוגי הבדיקות:

כלל האצבע הוא: 70% בדיקות קטנות, 20% בדיקות בינוניות ו-10% בדיקות גדולות. לא ברור לי איך הם מכמתים את המספר (Test cases? Run Time?) אבל הכיוון ברור. בהרבה מהמקומות שאני מכיר המצב אינו כזה, והוא נא מבדיקות ידניות בלבד עד לאיזה ערבוב של מעט בדיקות אוטומטיות, מעט Unit Test והרבה ידני.

איך בודקים תוכנה בגוגל: תפקידים ובדיקותאיך בודקים תוכנה בגוגל: תפקידים ובדיקות

 לחלק השני של המאמר לחץ כאן.