טסט דירקטור

[Calculin]

טסט דירקטור

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

 

[vinney]

תלוי מאוד בנוהלים שלכם

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

 

[Calculin]

מה לגבי תיקוני באגים?

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

 

[vinney]

לא כל כך הבנתי את השאלה

עקרונית, אתה יכול לאפיין באגים לפי גרסאות, אין עם זה בעיה

 

[אליק בליק]

תשובה

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

 

[vinney]

מה פתאום...

בשביל ערכים שונים משתמשים בפרמטרים וTEST LAB, להקים פרוייקט נפרד רק בגלל זה???

 

[אליק בליק]

לפני שאתה כותב מה פתאום....

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

 

[vinney]

מה הבעיה בתגובה שלי?

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

 

[אליק בליק]

אתן לך דוגמא

האם בדיקות STD ללקוח המפתח ובדיקות ATP (בדיקות קבלה) ללקוח הסופי תכתוב באותו פרוגקט בטסט דירקטור? נניח שהדרישות ב STD מחמירות/שונות מאשר ב ATP האם אתה משתמש בפרמטיזציה? נניח שאתה בודק הספקים/יכולות של שרת - כל אחד מהלקוחות שלך(המפתח / המשתמש) מנתי ומבין אחרת את מה שהוא מצפה מהשרת ברמת CPU זיכרון כמות פעולות IO או זמני נעילות של טבלאות בבסיס הנתונים וכו.. בקיצור ישנן המון סיבות להשתמש בשיטה שלנו כך שזה עובד במקומות הנכונים.

 

[vinney]

זה משהו אחר לחלוטין

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

(בלי לזלזל, כמובן, יש כאלה שסומכים על הספק, אבל ככה הם גם נראים...) לגבי סוגי בדיקות שונים (שזה מה שאתה מתאר ברמות CPU וכו), אז כן, אני מנהל את זה בפרוייקט אחד, וזה עובד מעולה. לכל TEST SET אני עושה RUNים לכל סוג מכונה עם פרמטרים עבור אותו סוג מכונה, שקובעים גם את הTEST DATA וגם את הEXPECTED RESULTS, וזאת הדרך הכי טובה להשוות דברים, כי תכל'ס אני בודק אותו דבר, רק המספרים בפרמטרים משתנים. CODE REUSE אומר לך משהו? אומנם אתה לא כותב CODE כמו תוכניתן, אבל לכתוב עשר טסטים בעשר פרוייקטים שכולם עושים אותו דבר עד כדי מספר זה מקור לטעויות, ובתור איש QA אתה אמור להיות הראשון לעלות על זה כבאג בדיזיין... אז נכון שזה עובד אצלכם, אבל נכון גם שאתה לא יכול לדעת מתי זה יפסיק לעבוד אלא אחרי התקלה הראשונה שתקרה. לנהל טסטים צריך בשכל, לא בEXCEL, וטסט דיירקטור זה לא בוידם שזורקים לתוכו טסטים ופרוייקטים בלי לחשוב מראש, זה כלי מתוחכם ביותר שכדי לנצל אותו עד הסוף צריך לעבוד קצת על תכנון מקדים ולבדוק את כל האפשרויות של שימוש. גם אם בסוף תגיע למסקנה שהשימוש שאתה עושה בו הכי נוח לך, זה אומר קודם כל - לא לשלול אפשרויות אחרות, ולחפש דרכים לייעל ולקצר תהליכים, כי TD מצוין לזה. ולא, לא עובד, לא עבדתי, ואין לי מניות במרקורי (כמה חברים רק

)

 

[jaffar1]

גם לדעתי זה תלוי בשוני בין הפרוייקט

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