יום שלישי, 1 בדצמבר 2015

קביעת סדר עדיפויות בהמרת בדיקות ידניות לאוטומטיות

בחלק מהצוותים איתם אני עובד ב-AVG יש לנו רגרסיות שאנו רוצים להמיר לאוטומציה. כיוון שכמות הרגרסיות גדולה, אנו זקוקים לקריטריון ברור שיעזור לנו להחליט על סדר ההמרה לאוטומציה. למשל המרה של רגרסיה קצרה להרצה ידנית, קשה להמרה לאוטומציה ומורצת לעיתים רחוקות תהיה בדחיפות נמוכה.
  
אנו חושבים שתהליך ההמרה אמור להיות כזה:
1.      כתיבת רשימת רגרסיות.
2.      נתינת ציון לכל רגרסיה לפי מידת הדחיפות שלה.
3.      אם צריך בתוך הרגרסיה עצמה נתינת ציון ל-test cases.
4.      להתחיל בהמרה בהתאם.
  
המידות לפיהן נחשב את מידת הדחיפות של כל רגרסיה הן: 
1. ההשקעה באוטומציה:
כמה זמן יקח לנו להעביר לאוטומציה, כתיבת הקוד (אפשר להתייעץ עם צוות האוטומציה אם יש).

נקודות לחשיבה:
- זמן כתיבת הקוד.
- האם יש צורך ללמוד טכנולוגיות / כלים חדשים?
- האם יש צורך בשינוי תשתיות האוטומציה?

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

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

3. חזרות:
- האם אנו מריצים את הרגרסיה בכל גרסה? בכל בניה בתוך גרסה (למשל בדיקות שפיות)?

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

4. תחזוקת הקוד האוטומטי:

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

5. ניהול סיכונים:
איזה פיצ'ר חשוב יותר לבדוק?

מבחינת המוצר:
- פיצ'ר חשוב למשתמשים.
- פיצ'ר חשוב לחברה.
- מתחבר לפיצ'ר חשוב.

מבחינה הנדסית:
- פיתוח מורכב.
- קוד בסיסי.
- האם היה בעייתי בעבר?

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

קביעת סדר עדיפויות בהמרת בדיקות ידניות לאוטומטיותקביעת סדר עדיפויות בהמרת בדיקות ידניות לאוטומטיות
  
  
איך הבדיקות שלכם אמורות להיראות:


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

יום שבת, 14 בנובמבר 2015

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

המשך המאמר מכאן. (כדאי לעיין בכדי שהמשך המאמר הנוכחי יהיה ברור).
  
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 של גוגל פלוס:
התיאור של המוצר: 
איך בודקים תוכנה בגוגל
ממה הוא בנוי:
איך בודקים תוכנה בגוגל
מה הוא עושה:
איך בודקים תוכנה בגוגל

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

בגוגל הבדיקות שייכות לארגון שנקרא 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 והרבה ידני.
איך בודקים תוכנה בגוגל: תפקידים ובדיקות
איך בודקים תוכנה בגוגל: תפקידים ובדיקותאיך בודקים תוכנה בגוגל: תפקידים ובדיקות
 לחלק השני של המאמר לחץ כאן.

יום רביעי, 28 באוקטובר 2015

REST, GET ו-Post

REST, Representational State Transfer
  
REST הינו סגנון ארכיטקטוני, או סט של אילוצים ארכיטקטוניים.
HTTP בנוי בסגנון של REST.
HTTP הינו פרוטוקול של שליחה ותגובה (Request / Response) ומיועד לאפשר תקשורת בין ה-Client ל-Server
ל-HTTP יש מתודות לשליחה / תגובה בין השרת לקליינט, למשל Get ו-Post.
ה-Get הוא בטוח - אין תופעות לוואי, ניתן לשליחות חוזרות ואפשרי לקאשינג.
התגובה ב-HTTP כוללת אספקטים ייצוגיים שזה התוכן של ה-URL, מה שנמצא ב-Body, כמו למשל מסמך HTML.
מסמך HTML יכול לכלול לינקים למסמכים אחרים, ל-CSS ול-Java Script.
הינה כמה מאפיינים של REST:

Resources:
   URI
      Uniform Interface
      Methods
      Representation
  
Protocol
   Client / Server
   Stateless: each req is independent from each other.
   Cacheable
   Layered
וכמה יתרונות:  
   Network performance
   Efficiency - Caching
   Scalability - Possibile to use large set of origin servers
   User Perceived Performance - set of defined methods, lets the code run in the client or server - whatever is faster
ככה נראה REST בחיים האמיתיים

ההבדלים בין המתודות הם:
ב-Get הפרמטרים נמצאים ב-URL
ב-Post הפרמטרים נמצאים ב-Body 
הרבה פעמים אנו משתמשים ב-Get להביא מסמכים והפרמטרים מתארים את המסמכים - למשל באיזה דף אנחנו נמצאים.
ב-Post בד"כ משתמשים בכדי לעדכן את הנתונים או את השרת.
ל-Get יש הגבלה על אורך, ל-Post כמעט ואין.
ל-Get אפשר לעשות קאשינג בדרך השרת לקליינט, ב-Post לא.
את ה-Get אפשר לשלוח מספר פעמים, את ה-Post לא.
  
RESTful API הוא API לפניות לשרת. אפשר להשתמש במגוון מתודות וב-XML, אבל בעיקר משתמשים בו ב-JSON. SOAP (Simple Object Access Protocol) למשל משתמש רק ב-Post וב-XML.

יום ראשון, 18 באוקטובר 2015

ממה בנוי דף ווב? - צד הקליינט

HTML
על טים ברנרס-לי שמעתם? לא? אולי הוא בכלל לא מספיק חשוב בכדי לשמוע עליו?
תחליטו אתם. הוא בסה"כ, בין יתר הדברים שעשה, המציא את ה-HTML. הא, כן, הוא גם הגה את ה-World Wide Web אבל זה סיפור אחר.
ה-HTML זה ראשי-תיבות של HyperText Markup Language, והינה ההפתעה השנייה: יש שם בעברית: "שְׂפַת סִימָנֵי עֲרִיכָה לְתַמְלִיל-עָל". אני מצפה שמהיום תשתמשו בו!
ב- markup language הכוונה, בהקשר שלנו, לשפת תגיות, הנלוות לטקסט ומטרתן היא בעיקר להוראות של הצגת הטקסט, קביעת היררכיה, מידור של חלקים ועוד. הדבר קיים כבר מזמן, למשל הוראות הבמאי על תסריט וכד'.
אגב, זו שפת תגיות ולא, זו לא שפת תכנות. חשוב לי לציין את זה כי ראיתי בקו"ח משפטים כמו:
"שפות תכנות: HTML, XML ." נא בדקו בקו"ח שלכם ואם קיימים, מחקו מיד, זה יחסוך לכם עוגמת נפש.
  
תג HTML אופייני נראה כך:
<title>HTML – ויקיפדיה</title>
התג <title> (או כל תג אחר) אינו נראה בדף, והוא מורה על כך שהטקסט המקושר אליו הינו הכותרת: HTML – ויקיפדיה.
התג <title/> בעצם אומר בזכות הסלש שזוהי סופה של הכותרת.
  
ב"הייפר טקסטס" הכוונה לקישור לנקודה אחרת, וידוע בימינו בכינוי החיבה "לינק".
  
בכדי לראות עוד דוגמאות פשוט תבחרו view source כשאתם רואים עמוד מסוים בדפדפן.
  
ה-HTML מאפשר הכנסת תמונות ואובייקטים אחרים כמו Java Script לדף אינטרנט שאותו הדפדפן שלכם "מתרגם" למה שאתם רואים.
בדיחה פרטית
מה לשים לב בבדיקות?*
ישנם אתרים שבודקים תקינות של דפי HTML, למשל זה. למרות שבבסיסה השפה הזו היא סלחנית, כדאי לבדוק האם מדובר באזהרות פחות חשובות או בדברים שיש לתקנם.
  
ועכשיו כמה נקודות הקשורות ל-HTML ואובייקטים שהוא יכול להכיל. בחרתי במושגים שאני שומע ביום-יום. ברור שיש עולם שלם מאחורי ה-HTML והאובייקטים הללו. מה שחשוב לנו, בתור בודקים, זה להכיר אותם ברמה לפחות בסיסית ולדעת לאתר אותם בדף. חשוב להבין אילו בדיקות מותאמות לאילו אלמנטים. למשל אם יודעים שבעמוד מסוים יש iframe  (הסבר למטה) צריך לקחת בחשבון שיכול להיות שלא תהיה גישה לאתר השני מכל מיני סיבות, וששינוי באתר השני עלול לפגוע ב-UI  של האתר שלי.
  
JavaScript 
ציטוט ישיר של וויקיפדיה:
"Java Script היא שפת תסריט מפורשת מבוססת אובייקטים המותאמת לשילוב באתרי אינטרנט ורצה על ידי דפדפן האינטרנט בצד הלקוח. השפה מרחיבה את יכולות שפת התגיות הבסיסית HTML ומאפשרת בכך ליצור יישומי אינטרנט מתוחכמים יותר. למעשה, רוב אתרי האינטרנט המודרניים משלבים שפה זו. היא ידועה בעיקר כשפה המוטבעת בדפי HTML על מנת להציג דפים דינמיים, שמשולבת בהם תוכנה. קוד ה-JavaScript שמשולב בדף HTML מבוצע על ידי הדפדפן. JavaScript נוחה מאוד לעבודה עם DOM ולתפעול DHTML."
  
מה לשים לב בבדיקות?
בדיקות UI ופונקציונליות רגילות, ע"פ הגדרות המוצר.
  
Cascading Style Sheets או CSS
CSS נועד להפריד אלמנטים עיצוביים מהעמוד עצמו, וכך להפוך את מקור העמוד לקריא יותר. בנוסף מספר דפי HTML יכולים לרשת מאותו וה- CSS חוסך עבודה והופך את האתר לעקבי יותר.
ב- Cascading הכוונה לכך שיש היררכיה, למשל תגית עיצוב בתוך עמוד עצמו גוברת על אותה תגיד ב-CSS.
  
מה לשים לב בבדיקות?
אכן האתר עקבי באובייקטים שלו (למשל סוגי וגדלי פונטים). כשמוצאים בעייה כדאי להבין האם מדובר רק בדף אחד או אם מדובר ב-CSS, שזה האחרון ישפיע על כל האתר. לכן תיקון CSS יש לבדוק בכמה דפים, לא רק שהעניין תוקן אלא שדבר לא נפגע כתוצאה.
  
DIV
קונטיינר שמאגד תחתיו אלמנטים של הדף ויוצר חלקים. כך ניתן למשל לאחד פונט לכל הטקסט תחת ה-DIV.
  
Asynchronous JavaScript And XML או AJAX
  
AJAX היא טכניקת פיתוח של צד ה-client שמטרתה לייצר אפליקציות ווב בלתי מסוכרנות. ב"בלתי מסוכרנות" הכוונה שהטעינה של חלקים אלה נעשית ברקע ואינה מעכבת את טעינת העמוד. בנוסף, תוכן ה-AJAX יכול להתעדכן מול השרת מבלי הצורך בטעינת הדף מחדש. כל זה מושג ב-Java Script שנמצא בדף הקליינט.
  
מה לשים לב בבדיקות?
שאכן התוכן של האובייקט יכול להשתנות ללא טעינת הדף, ו"יחסיו" עם הדף ואובייקטים אחרים.
  
Inline frame  או Iframe
זהו תאג שבעזרתו אפשר להכניס מסמך אחר לתוך המסמך שעובדים עליו כרגע. בעצם אפשר להכניס ל-iframe אתר אחר.
  
מה לשים לב בבדיקות?
מעבר למה שנאמר למעלה, ענייני security, שהאתר שהכנסנו לא "יגנוב" מידע של משתמשים (למרות שיש לו cookies משלו).
  
  
Document Object Model או DOM
ה-DOM הוא סטנדרט לגישה למסמכים (ב"מסמך" הכוונה כאן לעמוד HTML).
בעזרת ה-HTML DOM ה-Java Script יכול להגיע ולשנות את כל האלמנטים בעמוד. כשעמודHTML  נטען הדפדפן יוצר את המודל הזה של האובייקטים של המסמך, כלומר הדף. למשל:
DOM HTML tree
בעזרת מודל זה ה-Java Script מקבל יכולת לצור HTML דינמי:
לשנות אלמנטים, לשנות מאפיינים של אלמנטים , לשנות את הסטייל של העמוד, להוסיף אלמנטים ותכונות ל-HTML וליצור HTML Events חדשים.
  
מה לשים לב בבדיקות?
בדיקות UI ופונקציונליות רגילות, ע"פ הגדרות המוצר.
  
* הכוונה היא ספציפית לנושא זה והבאים אחריו, לא לבדיקות כלליות של דף אינטרנט למשל UI  וביצועים.
  
מקורות:
וויקפדיה
tizag tutorials

יום שישי, 24 ביולי 2015

האג'ייל כחושף בעיות בתהליך הפיתוח

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

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

בכך שהבעיות צפות אפשר לאתר אותן ולהתחיל בתהליך של פתרונות.
צוות אג'ייל הומוגני בהיפסטריות שלו
* בעיה שאינה חייבת להיות (אך עלולה להיות) דווקא של צוות הבדיקות אלא אולי של החברה: קוד "ספגטי" שמחייב לבדוק "הכל" אחרי כל שינוי, חוסר בבדיקות כמו unit tests ואוטומציה וכד'.



Jun 24, 2015

יום שישי, 17 ביולי 2015

אסטרטגיית הבדיקות

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

הייתי רוצה שזה יהיה מסמך שתלוי על קיר כל קבוצת בדיקות, אג'ילית או לו.
  
מצ"ב הצעה למסמך אסטרטגיית בדיקה. "לפי הספר" אמורים להיות כאן גם קריטריוני האיכות, אבל זה יסבך את המסמך ללא צורך:
https://drive.google.com/file/d/0B1WL1k115uIiSWlJU0tsLURfOTg/view?pli=1

יום שבת, 4 ביולי 2015

מה בודקים במערכת - ברמה גבוהה

השתתפתי לא מזמן בכנס של ג'יימס באך בצ'כיה (באדיבות AVG). אכן יש הרבה מה ללמוד מהבנאדם, וקצרה כאן היריעה לתאר את כל הדברים שלמדתי שם. אבל יש כמה דברים שאנסה לטפטף כאן.
למשל יש את מה שהוא קורא לו Quality Criteria Categories. אפשר למצוא את התוכן של זה באתר שלו, בקובץ הורדה בשם RST Appendices.

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

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

הקובץ כ-pdf.
לינק למיינדמפ.
לינק לתמונה.

יום רביעי, 1 ביולי 2015

צ'ק ליסט לכתיבת מסמך בדיקות - STD Checklist

The final list includes many items added by Kobi Halperin as appeared here.

Preparations and format:
01. Were all the requirements identified and listed while preparing the TD?
02. Does the traceability matrix exist as a part of the document or referenced from the TD?
03. Is every requirement covered by at least one test group in the TD?
04. Was the TD written in accordance with the template?
05. Was the TD written in accordance with the guidelines in the Test Approach document?
06. Are all the test groups and test cases uniquely identified?
07. Is the naming convention used consistent throughout the document?
08. Was the Doc Revision Change Control filled properly?
09. Are the Testing Gear properly identified?
a. Tool specifications.
b. Scripts and debug tools.
c. Information that should be found in logs.
10. Are some of the tests defined as being done not in a clean environmet to identify integration and other parts influances?
11. Are all related documents mentioned and linked?
12. Are there Definitions &amp; Abbreviations to all the terminology in the document?
13. Are all the topics that will be tested and will not be tested defined in the document?
14. Is there any reference to documentation tests (Help windows, User Manual &amp; Installation Manual)?
15. Are there any TBD issues?
16. Was the Speller run? Were all needed updated values updated (e.g. TOC)?
17. Does the document include diversity (users, ports, slots etc)?
 ×¦'ק ליסט למסמך בדיקות STD

Test groups:
18. Were all the test groups and test cases defined in accordance with system impacts (Installability, Integrity, Security, Performance, Maintainabilility, Serviceability, Update/Migration, Documentation, Usability, Standards, Reliability, Requirements, Capability?)
19. Were all the test groups and test cases defined in accordance with triggers (Functional, Startup/Restart, Recovery/Exception, Redundancy Failover, Hardware configuration, Software configuration?)
20. Does every test group contain at least one test case?
21. Does each test group test one specific requirement?
22. Is every test group verified under different conditions/inputs/scenarios?
23. Is the testing method described clearly for each test group (to the level that will enable the reviewer to understand how the test cases will be executed and how the results will be evaluated?)
24. Does the test method for each test group include criteria for evaluating tests results?

Test Cases:
25. Are the test cases classified according to applicable test types (Positive Test Case, Negative Test Case - about 30%, Boundaries Test Case, End Cases)?
26. Are there tast cases designed to detect problems between the tested feature and other features / sub-systems of the system?
27. Does each test case include the purpose of the test?
28. Are the test cases for the same test group testing the same requirement under different conditions?
29. Are the test groups and test cases designed in bug revealing orientation (we are testing in order to find bugs and not to show that it works?)
30. Do the tests cases have priority based on the product (e.g. complexity) and version (e.g. feature X as milestome for a customer)?
31. Do the test groups include separate test cases for positive, negative, boundary checks?
32. Do the test groups include separate test cases for end cases?

a. Were test cases with special input values (empty file, empty message, etc) defined?

b. Were test cases defined for testing functionality under abnormal conditions (no communication between two components, temporarily no connection to data base, etc)?

c. Were test cases with illegal input values defined?
33. Were complicated and not only trivial scenarios defined for test case execution (for example, several users performing actions or contradictory actions, like one user deposing a message, while the subscriber is deleted, or depositing a message while another message is deposit and causes exceeding the message quota)?
34. Are the test objectives described clearly for each test group?
35. Was test results evaluation defined (at least considered) by more than one method (for example, visual observation of user’s handset, activity log record and relevant log file record?)
36. Does every test case have preparations and setup (either stated implicitly or referenced to the test group or whole TD preparations and setup?)
37. Are issues of error handling addressed?
38. Were test cases with default input values defined?
39. Was test cases dependency eliminated (can each test case run independently and not dependent of execution of other test cases)?
40. For test cases that have specific preparations and setup, was a return to initial conditions defined upon end of execution (to eliminate dependency)?
41. Were test cases defined in order to check data integrity (data loss in case of errors, failures?)
42. Were test cases defined in order to check data consistency (in case of flow errors, for example?)
43. Were test cases defined to check rollback in case of flow error?
44. Were test groups and test cases that are relevant only for specific version identified and marked as such (the idea is to have one TD for a sub-system/service/feature for all versions and test cases that are not relevant for this version can be easily identified and not executed?)
45. Are the expected test results for each test case specific and unambiguous (you understand exactly what to expect from the test results and if everything works correct, you will always expect the same results?)
46. Where we use the same set of steps (e.g. checking text fields): is it written only once with reference?
47. Where we use the same set of parameters (e.g. checking configuration files): is it written only once with reference?
48. Do all test cases include running time estimation (before the first run it is a ragh estimation, will be updated if needed after the first run)?

Test Steps:
49. Are the actions (steps) in the test procedure specific and unambiguous?
50. Do the steps include only relevant actions for test execution and are not mixed with test preparations and setup?
51. Are the test procedures brief (5-10 steps. If not, you are probably testing several things at once?)
52. Wherever a range of values (including in the test gear) can be used - is it included in the tests?

Jul 1, 2015

יום ראשון, 28 ביוני 2015

Form for Exploratory Testing - טופס לניהול אקספלורטורי טסטינג

So it's clear to everyone that exploratory testing is more than just "testing". They should be planned and, at some level, documented.

Attached is a form, if you wish, to be filled in before, during and after the tests.

  ×™×œ×“ שמבין באקספלורטורי יותר מאיתנו
Exploratory Tests Form

Date: Feature to be tested:

The scope of testing:
Examples: UI
Functionality Validation Usability Validation etc.

Time Frame (recommended: up to 2 hours):

The technique to be used (mark the relevant one/s or add new ones):
Examples:
Risk management (tests what is more risky) Use case / User stories “Drifting” vs. the spec Scenario based (Soap Opera) These are tests where one assumes that the user has everything going on. Invariance testing changes things that shouldn't affect the product and then makes sure that they indeed don't Gorilla testing is a quick attempt to determine the level of risk of a subsystem It can also be used to find major bugs early in the cycle run tests that emulate user tasks. Some testers should explicitly be given a task focus, not a feature focus. Their job is to do whatever users do in order to accomplish whatever it is that users try to accomplish. Run the tests based on the Manual of the product Bug based testing. Run tests based on bug types found in the feature/application going over the menus

Test mission:

Examples:
Does something work as requested in the requirement? How does something work under this and that conditions? Is documentation of something aligned with the actual something behavior? What is the performance of something? Does something behaves user-friendly way? Does something affected current and existing behavior of something

Running log (please fill while you go):

Testing the: Conjecture(or: what could go wrong and how to find it): Flows that I run in high level: a. b. c.... Conjecture refuted / corroborated: New conjecture etc.... I saw something strange… Bugs found in high level (will be reported later):

My impressions:
Feelings I had about the product, about specific features, flows etc. (Bad and good  ). Thoughts about the testing: is the product good? Reliable? Does it serve its purpose? Will users like it?

Thoughts about the test itself: (what was good, what we can improve, what was missing). what should be tested next based on my experience.

Jun 28, 2015

יום שישי, 26 ביוני 2015

אג'ייל: האם כדאי לדווח על באגים במערכת ניטור

בעד:
1. כבר רגילים, אין צורך ללמוד משהו חדש.
2. יש בבאג הרבה מידע (סביבות, לוגים, על מי הבאג, באיזה הקשר התגלה וכד').
3. נח להוסיף לו דברים כמו צילומי מסך.
4. שמירת מידע על באגים שתוקנו, נדע למשל מתי תוקנו ואיך במידה שהם חוזרים. או למשל אם באג התגלה כבר כ-invalid חוסך זמן לבודק לתעד שוב.
5. מדידות.
6. במקרה שיש כמה קבוצות ויכולה להיות השפעה הדדית. יחד עם זה תמיד עדיף לתקשר את הבאגים בשיחה.
7. אם מודדים באגים.
  
באג מדווח
נגד:
1. צורך זמן.
2. הרבה באגים בכלל לא מתכוונים לתקן.
3. מספיק פתק פשוט עם הבאג והכנסת הסנריו לרגרסיות.
4. גם היום מפתחים בד"כ לא מכניסים בגים שהתגלו בקידוד.
5. ניתן לשמור מידע גם בדף FAQ.
6. מעודד פחות תקשורת ורבלית בין צוותים.
7. דורש טיפול רב: כתיבה, טריאג'ים, הסברים, שחזורים, הערות.
  
דעתי:
אם הבאג מתוקן יחסית במידי (הייתי אומר: באותו יום) - אין צורך לדווח.
אם הבאג מתוקן בספרינט (אבל לא היום) - כדאי לכתוב על הבאג בכמה מילים במקום הזמין לכולם.
אם הבאג אינו מתוקן בספרינט - יש לדווח אותו.

Jun 26, 2015

יום חמישי, 25 ביוני 2015

Planning Poker

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

יחידות המדידה בהן בוחרים הן שיטה אחת מאלה:
1. פשוט מספרי ימים.
2. סדרת פיבונאצ'י. כיוון שההערכה היא גסה ולא מדוייקת, הסדרה אמורה לשקף זאת.
3. לפי מידות בגדים: S, M, L, XL, XXL.
4. Story points. זו שיטה שמגיע לה פוסט כשלעצמה. בעיקרון אלו יחידות מידה יחסיות לא חופפות זמן אלא לפי מורכבות או גודל הסטורי.
5. Ideal days - זמני נטו של העבודה.



איך זה מתנהל?
1. ה-product owner מציג את הסטורי לקבוצה אך אינו משתתף בהערכה.
2. המשתתפים מורידים את האפליקציה ומקנפגים אותה ליחידות המדידה שהוסכם עליהן.
3. כל משתתף בוחר את ההערכה המתאימה.
4. לאחר שכולם בחרו הם מציגים את ההערכות שלהם.
5. בעל ההערכה הגבוהה ביותר והנמוכה ביותר מסבירים את השיקולים שלהם.
6. חוזרים על 3-5 עד שמושגת הסכמה.


יום שבת, 20 ביוני 2015

DNS והקשר לבדיקות קליינט סרבר ובדיקות ווב

ראיינתי עשרות אנשי בדיקות, חלקם בתחום שנים רבות, שלא ידעו לענות לי, אפילו בדרגה שטחית, על המושגים הבסיסיים ביותר בתחום. אם תסלחו לי רגע על הצדקנות, בודק ווב 5 שנים שלא ממש מבין מה זה cookie, כמעט בוודאות לא בדק את המוצר שלו כמו שצריך. סתם לצורך אנקדוטה, מישהו אפילו הסביר לי שפעם הוא שאל את המפתח מה זה cookie, אבל התשובה הייתה "מסובכת נורא". בכדי לדעת לבדוק מוצרי client-server בסביבת web צריך להתחיל מהיסודות הטכניים, להבין את זרימת המידע בין הקליינט לסרבר ועוד.
ידע זה אינו נשאר בספירה תיאורטית,  זה יכול לעזור גם לבדיקות עצמן:
1. בתכנון הבדיקות.
2. בהבנת מיקומה של הבעיה.
3. ככלים העוזרים לבדיקות.
  
כשלא יודעים מה זה cookie, אתה (בהתאמה):
1. לא יכול לבדוק שהצבת ה- cookie השיג את מטרתו (למשל לשמור מידע מאוד ספציפי על המשתמש), האם המידע שם שצריך להיות אכן מוצפן ועוד בדיקות.
2. לא תדע איפה להתחיל לדבג בעיות. למשל  איך זה שאני נזרק מהאתר במעבר בין דפים.
3. לעשות מניפולציה על ה- cookie בשביל לבדוק מה קורה כשלמשל תוקף ה-cookie פג.
  
אבל עכשיו אדבר דווקא על DNS, Domain Name System.
מה זה בעצם DNS? DNS הינו בראשונה פרוטוקול המשרת מערכת שמטרתה להמיר שמות דומיין מתווים שאמורים להיות בעלי משמעות (למשל: google.com) לכתובת IP (למשל: 173.194.112.169).
אפשר למצוא את כתובת ה-IP ידנית ע"י הרצת שורת הפקודה (windows+r, הקלקת CMD ו-Enter), ואז הפקודה: ping google.com.
אם אפשר להגיע לשרת נקבל את ה-IP.
בתסריט שהמחשב / הטלפון לא מכיר את ה-IP (תיכף אסביר איך ייתכן שהוא מכיר) זה עובד כך:
את מקלידה google.com ב-address bar של הדפדפן, מקליקה על ה-enter -> הדפדפן מחפש אצלו את ה-IP של גוגל. אם מצא הוא משתמש בו בכדי להגיע לשרת. אם לא מצא -> פניה לשרתי DNS. מדובר במספר רב של שרתים שמאחסנים כל אחד מידע יחסית קטן. זה מתחיל בפניה לשרת ה-ISP (ספק האינטרנט שלך – Internet Service Provider) שבמידה ואינו מוצא את ה-IP הוא מעביר את הבקשה לשרת DNS root שמעביר אותך לשרת אחר שאמור לספק את התשובה.
הכנתי תרשים לוגי בכדי להקל על ההבנה, לאו דווקא מדוייק במאת האחוזים.

DNS והקשר לבדיקות קליינט סרבר ובדיקות ווב

אבל אולי אותנו כבודקים יעניין התהליך הפנימי שקורה בתוך המחשב, תיכף אסביר למה.
לפני שהמחשב בכלל פונה לשרת DNS הוא פונה לקובץ מוגן משינוי שנקרא hosts ונמצא ב-C:\Windows\System32\drivers\etc (בווינדואוס כמובן. לגבי אנדרויד למשל אפשר לראות כאן). שם הוא מחפש את השם שהוקלד, למשל google.com. אם הוא מוצא אותו, זה יראה כך:
מה זה אומר? בעצם דבר פשוט: עזוב אותך אחי מללכת לשרת DNS וכאלה בזבוז זמן, אני יודע את הכתובת המדויקת של מה שאתה מחפש – זה 173.194.112.169. וזה מה שקורה – הדפדפן מחפש ישירות את 173.194.112.169.
  
למה זה טוב (פרט מלשגע מישהו ולתת לו IP של פייסבוק בכל פעם שהוא מקליד google.com)? זה טוב כשאנו צריכים לעבוד בבדיקות מול שרת מקומי. למשל את עובדת על אתר בשם atar.com. כשמקליקים את זה ברגיל, נגיע לאתר העובד שכל העולם יגיע אליו באותה דרך. אבל אנחנו בודקים את הגרסה החדשה של האתר בסביבת הבדיקות טרם עלייתו לפרודקשין. ולאתר בסביבת הבדיקות יש IP משלו. אז נכניס לקובץ hosts את השם atar.com עם ה-IP של שרת הבדיקות. עכשיו כשנקליק את שם האתר הדפדפן ונלחץ Enter, המחשב יחפש קודם בקובץ, ימצא את ה-IP הפנימי ויפנה אליו.
  
אבל אם אין את האתר בקובץ ה- hosts אנחנו עדיין לא ברשת. המחשב מחפש ב-DNS cache הפנימי שלו. רוצים לראות אותו? הקלידו את הפקודה הבאה:
ipconfig /displaydns
זה יראה כך:
ואם אתם תמיד מגיעים בבדיקות לאתר הלא נכון, כדאי למחוק את ה-DNS cache כך:
ipconfig /flushdns
  
ואם אתם רוצים להתחבר ישירות לשרת DNS מסויים:
בקונטרול פאנל לכו לרשתות לפי מה שמצויין בתמונה, פרופרטיס של ה-local area connection, פרופרטיס של Internet Protocol version 4:
בעקבות הערה בפורום, יש עוד פקודה המזכירה את ה-ping ונקראת nslookup. הפינג מורה לאן אתה מגיע בפועל. כלומר הוא עובד דרך הקש וקובץ ההוסטס, ואם הוא מגיע לשרת הוא יחזיר את ה-IP.
 nslookup יביא הכתובת האמיתית של השרת מבלי התייחס לקש, להוסטים או למצב השרת (הוא בודק בשרתי ה-DNS).
כלומר nslookup יותר מדוייק מפינג, אבל השאלה מה אתה צריך: להבין לאן אתה מגיע בפועל, או מה כתובת השרת.
  
  
  
  
  
מקורות:

  

יום חמישי, 4 ביוני 2015

תעלומת החולצה הכחולה

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

יום רביעי, 27 במאי 2015

מגזין עולם הבדיקות - גליון ראשון

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

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


יום רביעי, 22 באפריל 2015

פגישות באג'ייל - מי צריך להיות איפה


על כל הפגישות אחראי הסקראם מסטר.


Pre-grooming \ Clarification: פגישה בה בעל המוצר מציג את התכונות החדשות, ארכיטקט הפיתוח מסביר על מה שיעשה מבחינת הפיתוח, מורכבות וכד', וארכיטקט הבדיקות מציג תכנית בדיקות ברמה גבוהה.

משתתפים:

Product owner

Dev & QA Architects

אופציונלי: Scrum Master

Grooming: פגישה של צוות האג'ייל בא מפרקים אפיק לסיפורים ונותנים הערכת זמנים.

משתתפים:

צוות האג'ייל + Product owner + Scrum Master

Dev & QA Architects


Planning + Commitment: מה נכנס לספרינט.

משתתפים:

צוות האג'ייל + Product owner + Scrum Master

Project Manager

Optional: Dev & QA Architects

Scrum daily meetings:

משתתפים:

צוות האג'ייל + Product owner + Scrum Master

Project Manager אופציונלי כיוון שהסנכרון יכול להתבצע מאוחר יותר בין הסקראם מסטר ומנהל הפרוייקטים).

אופציונלי: כל העולם (אבל ללא זכות דיבור).

Demo:
משתתפים:

צוות האג'ייל + Product owner + Scrum Master

Stakeholders (Customers, Architects etc)

Retrospective:
משתתפים:

צוות האג'ייל + Product owner + Scrum Master

אופציונלי: Dev & QA Architects

רשומות פופולריות