איך הייתם מגדירים STR ??
- פותח הנושא Taloded
- פורסם בתאריך
ScrollLock
New member
הסתייגויות...
אני נוטה להיות מינימליסט. עד עכשיו זה מוכיח את עצמו לא רע בכלל. אז ככה: 1. יש תבנית. לדעתי היא אמורה להיות מבוססת על IEEE 829:1998. 2. רק מידע כללי ביותר על המכלול הנבדק אמור להיות כלול במסמך (ממש רקע כללי). 3. עיקר הדגש הוא על סביבת הבדיקות, תוצאות הבדיקות והתרשמות כללית מתוצאות הבדיקות. מעבר לזה - לא לחנטרש יותר מדי. חבל על הזמן!
אני נוטה להיות מינימליסט. עד עכשיו זה מוכיח את עצמו לא רע בכלל. אז ככה: 1. יש תבנית. לדעתי היא אמורה להיות מבוססת על IEEE 829:1998. 2. רק מידע כללי ביותר על המכלול הנבדק אמור להיות כלול במסמך (ממש רקע כללי). 3. עיקר הדגש הוא על סביבת הבדיקות, תוצאות הבדיקות והתרשמות כללית מתוצאות הבדיקות. מעבר לזה - לא לחנטרש יותר מדי. חבל על הזמן!
עם כל הכבוד למינימליזם
יש עוד כמה דברים בכל זאת שיש לשים לב אליהם: 1. באגים שנכתבו במהלך תהליך הבדיקות 2. סוגי הבדיקות שנעשו והשוואת התוצאות לסבב בדיקות קודם 3. סיכונים לפרויקט שנחשפו במהלך ההרצה (בעיות חמורות של ביצועי מערכת), רגרסיות קשות וכו. 4. סיכום למנהלים של תוצאות הבדיקות ומסקנות מומלצות
יש עוד כמה דברים בכל זאת שיש לשים לב אליהם: 1. באגים שנכתבו במהלך תהליך הבדיקות 2. סוגי הבדיקות שנעשו והשוואת התוצאות לסבב בדיקות קודם 3. סיכונים לפרויקט שנחשפו במהלך ההרצה (בעיות חמורות של ביצועי מערכת), רגרסיות קשות וכו. 4. סיכום למנהלים של תוצאות הבדיקות ומסקנות מומלצות
מסכים ../images/Emo45.gif ../images/Emo39.gif
נכון שטוב מאד אם בראש המסמך יהיה מעין תקציר מנהלים עם השורות התחתונות (עדיף אגב על סיכום מנהלים בסוף: הרי זה לא סיפור מתח. קודם רואים את עיקרי התוצאות ומי שמעוניין ביתר פירוט ימשיך לקרוא), אבל בהחלט יש מקום לפירוט שהזכרת. חשוב לציין גם: רשימת כל הבאגים מרמת חומרה מסויימת (לרוב כל הקריטיים, כולל אלו שנפתרו). רשימת כל הבאגים שטרם נפתרו, לפחות בשתי רמות החומרה הגבוהות.
נכון שטוב מאד אם בראש המסמך יהיה מעין תקציר מנהלים עם השורות התחתונות (עדיף אגב על סיכום מנהלים בסוף: הרי זה לא סיפור מתח. קודם רואים את עיקרי התוצאות ומי שמעוניין ביתר פירוט ימשיך לקרוא), אבל בהחלט יש מקום לפירוט שהזכרת. חשוב לציין גם: רשימת כל הבאגים מרמת חומרה מסויימת (לרוב כל הקריטיים, כולל אלו שנפתרו). רשימת כל הבאגים שטרם נפתרו, לפחות בשתי רמות החומרה הגבוהות.
ScrollLock
New member
הממממ... הבהרות?
1. "תקציר מנהלים" מופיע תמיד (!) בראש כל מסמך! 2. הגישה שלי (ושל "עוד כמה אנשים"?) היא שמסמך הבדיקות חייב להיות מופרד מהמסמך שמתאר את תוצאות הבדיקות. 3. רשימות של באגים שנמצאו חייבות (!) להיות מרוכזות ומסודרות - למשל בכלי לניהול באגים. מסמך הבדיקות, גדול ככול שיהיה אמור להיות מפורט במידה מספקת כך שלא ישאיר מקום לסטיות או טעויות במהלך ביצוע של כל בדיקה אבל מספיק קצר ותכליתי כדי לא "לזיין ת'שכל". מסמך הבדיקות אכן מכיל או לפחות אמור להכיל מקום לרישום (ידני) של תוצאות כל שלב א ב ל בסופו של כל סבב בדיקות יוצא מסמך נפרד שנקרא STR שהוא בעצם הסיכום של כל הבדיקות. המסמך הזה מתאר מפרט ודן בנושאים כגוןשינויים או חריגות מדרישות הסביבה שנדרשות לצורך הבדיקות, תוצאות כלליות של כל בדיקה (PASS\FAIL) וכן התרשמות כללית מתוצאות הבדיקות - האם המערכת בכללותה עברה או נכשלה ומה צריך לשפר לגירסה הבאה. באגים שנמצאו לא מפורטים במסמך זה אלא פשוט מובא קישור (REF) לסעיף הספציפי בתוכנת ניהול הבאגים. כל האמור לעיל, הוא רק חלק מנוהל הבדיקות ותוכנית הבדיקות המלאים. בנוהל הבדיקות מוגדרים יותר נושאים כמו תחומי אחריות, הקצאת משאבים ולוחות זמנים ובתוכנית הבדיקות מוגדרים נושאים כמו Entry\Exit criteria מפורטים, שיטות בדיקה וכלי בדיקה (אם יש) שונים.
1. "תקציר מנהלים" מופיע תמיד (!) בראש כל מסמך! 2. הגישה שלי (ושל "עוד כמה אנשים"?) היא שמסמך הבדיקות חייב להיות מופרד מהמסמך שמתאר את תוצאות הבדיקות. 3. רשימות של באגים שנמצאו חייבות (!) להיות מרוכזות ומסודרות - למשל בכלי לניהול באגים. מסמך הבדיקות, גדול ככול שיהיה אמור להיות מפורט במידה מספקת כך שלא ישאיר מקום לסטיות או טעויות במהלך ביצוע של כל בדיקה אבל מספיק קצר ותכליתי כדי לא "לזיין ת'שכל". מסמך הבדיקות אכן מכיל או לפחות אמור להכיל מקום לרישום (ידני) של תוצאות כל שלב א ב ל בסופו של כל סבב בדיקות יוצא מסמך נפרד שנקרא STR שהוא בעצם הסיכום של כל הבדיקות. המסמך הזה מתאר מפרט ודן בנושאים כגוןשינויים או חריגות מדרישות הסביבה שנדרשות לצורך הבדיקות, תוצאות כלליות של כל בדיקה (PASS\FAIL) וכן התרשמות כללית מתוצאות הבדיקות - האם המערכת בכללותה עברה או נכשלה ומה צריך לשפר לגירסה הבאה. באגים שנמצאו לא מפורטים במסמך זה אלא פשוט מובא קישור (REF) לסעיף הספציפי בתוכנת ניהול הבאגים. כל האמור לעיל, הוא רק חלק מנוהל הבדיקות ותוכנית הבדיקות המלאים. בנוהל הבדיקות מוגדרים יותר נושאים כמו תחומי אחריות, הקצאת משאבים ולוחות זמנים ובתוכנית הבדיקות מוגדרים נושאים כמו Entry\Exit criteria מפורטים, שיטות בדיקה וכלי בדיקה (אם יש) שונים.
המחלוקת היא רק בנושא אחד... ../images/Emo39.gif
למיטב הבנתי. 1. כמובן. 2. כמובן. אני אישית, אגב, דוגל במילוי תוצאות הבדיקה ב soft copy של מסמך STD, ושומר את זה במסמך שאני קורא לו STDR. באמצעות קצת טכניקה של וורד אפשר לתחזק ולשפר בצורה זו את מסמך הבדיקות עצמו תוך ביצוען, בסבב הבא לראות בקלות מה נכשל בסבב הקודם ולשים לב שלא חזר, וכדומה. 3. כמובן, אבל להבנתי מסמך התוצאות (STR) כן טוב שיכלול רשימה של באגים קריטיים שנתגלו במהלך הבדיקות, ושל באגים קריטיים וחמורים שעדיין פתוחים אם יש כאלו. נכון שאפשר לציין רק את עצם קיומם ומספרם ולהפנות, אבל לדעתי אלו נתונים מהותיים להבנת מצב האפליקציה במהלך ובסוף סבב הבדיקות, וככאלה מוטב לשים אותם כנספח למסמך (כלומר מקום נגיש לכל קורא של המסמך), ולא בקישור שמטבע הדברים פחות מגיעים אליו ולעתים כלל לא (למשל מי שקורא עותק מודפס של המסמך). רתיעה מזיוני שכל היא מבורכת כשלעצמה, אבל לא כדאי להפוך אותה לאובססיה
למיטב הבנתי. 1. כמובן. 2. כמובן. אני אישית, אגב, דוגל במילוי תוצאות הבדיקה ב soft copy של מסמך STD, ושומר את זה במסמך שאני קורא לו STDR. באמצעות קצת טכניקה של וורד אפשר לתחזק ולשפר בצורה זו את מסמך הבדיקות עצמו תוך ביצוען, בסבב הבא לראות בקלות מה נכשל בסבב הקודם ולשים לב שלא חזר, וכדומה. 3. כמובן, אבל להבנתי מסמך התוצאות (STR) כן טוב שיכלול רשימה של באגים קריטיים שנתגלו במהלך הבדיקות, ושל באגים קריטיים וחמורים שעדיין פתוחים אם יש כאלו. נכון שאפשר לציין רק את עצם קיומם ומספרם ולהפנות, אבל לדעתי אלו נתונים מהותיים להבנת מצב האפליקציה במהלך ובסוף סבב הבדיקות, וככאלה מוטב לשים אותם כנספח למסמך (כלומר מקום נגיש לכל קורא של המסמך), ולא בקישור שמטבע הדברים פחות מגיעים אליו ולעתים כלל לא (למשל מי שקורא עותק מודפס של המסמך). רתיעה מזיוני שכל היא מבורכת כשלעצמה, אבל לא כדאי להפוך אותה לאובססיה
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.