מאמר חדש: STP - Software Test Planning

[davidtzhmach]

מאמר חדש: STP - Software Test Planning

מאמר חדש בבלוג שלי ,
הנושא : STP(Software Test Planning)
בקצרה :
המאמר מחולק לשלושה חלקים(קישורים מצורפים) , שממפים את כל החלקים הרלוונטים למסמך מסוג זה,
החלק הראשון:הגדרות , זמן שימוש ? מקורות לאיסוף המידע , כלים לאיסוף המידע
החלק השני והשלישי :עוסקים יותר במבנה המומלץ כולל דוגמאות רבות שמפשטות את הנושא.
הערה:
המאמר נכתב מנקודת המבט האישית שלי ועל פי הנסיון שלי ,
המאמר מהווה בסיס מצוין לכתיבת מסמכים מסוג זה, אני מקווה שכל אחד יעזר וימצא את החלקים הרלוונטים לארגון שלו.
תהנו!
קישורים :
מאמר 1 : http://www.dtvisiontech.com/2014/01/stp-software-test-planning-part-1.html
מאמר 2: http://www.dtvisiontech.com/2014/01/stp-software-test-planning-part-2.html
מאמר 3 : http://www.dtvisiontech.com/2014/01/stp-software-test-planning-part-3_15.html

 

[halperin]

אבל השאלה העיקרית היא-מי בכלל משתמש?

במרבית החברות בהן הייתי, או ש:
1. לא כותבים בכלל STP.
2. כתבו לפני שנים רבות - אף אחד לא קורא ואף אחד לא מעדכן לגירסאות החדשות שלא לדבר על תוך כדי לפי שינויי הגירסה.
3. כולם כותבים STP - אבל בעצם הם פשוט קוראים כך למסמך ה- STD

4. החלקים החשובים והחיים של ה- STP מנוהלים בדרכים אחקות כמו גנט, כל מיני טבלאות אקסל ממוקדות מטרה ספציפית וכן הלאה.

 

[davidtzhmach]

לפי דעתי זה חלק חשוס ביותר ...

אני חושב שזה חלק חשוב ביותר ואבן יסוד משמעותית בכל תהליך בדיקה ,
אני מאוד מקווה שהמאמר יעזור להבין את החשיבות וכמובן ההיתרונות שבדבר.

 

[davidtzhmach]

*חשוב

 

[Israel Fruchter]

מסכים עם קובי, ותוספת סיפור משלי

לגבי סעיף 4, אני בחרתי להפסיק לכתוב מסמכי WORD. (ולהשתדל לא לפתוח את PowerPoint יותר מידי)
עברתי להשתמש בשרת wikimedia (יש לנו אחד מרכזי שרוב החברה משתמש בו)
ככה מסמכי התוכניות זמינים, אפשר לעדכן אותם מהר. ואף אחד לא יכול להתלונן שעובדים ללא תוכנית

בשביל לעדכן סופר מהר, כתבתי לעצמי CLI שעובד עם ה API של wikimedia, ומאפשר לי לערוך את העמודים באיזה כלי שאני רוצה, במקרה שלי הברירת מחדל היא nano.

המוטו שלו היה משהו כזה,
"now you don't have an excuse not to update the wiki"

I need to open source it some day...

ישראל

 

[עמית ו]

מאוד קשה לי להתחבר לתהליך המתואר שם

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


הנפילה, לפחות במקרה שלי, היא כבר בתנאי הכניסה לכתיבת המסמך -
1 - לקוח שלח בקשה - נניח. נדיר מאוד אצלנו (אני עובד על מוצר קיים, למעט בקשה אחת מלקוח אחד, כל השדרוגים והתוספות שהיו בשנתיים האחרונות הגיעו כיוזמה "שלנו" בעקבות איתור חסר, תלונה של לקוח או בקשה מעורפלת)
1.5 שאושרה - כלומר, החליטו לעבוד על הבקשה? אוקי.
2 - PM מייצר מסמך דרישות - מסמך זו מילה מאוד חזקה לשלושה משפטים שאומרים "אני רוצה כזה, לכו להגדיר מה זה בדיוק". גם שלושת המשפטים האלה הם לפעמים יותר ממה שאפשר לצפות לו.
3 - DDD קיים - לא לפני ולא אחרי. לרוב צוות הפיתוח כותב את מסמך הSRS וזהו. גם זה, לא מעט פעמים - בדיעבד ואחרי כתיבת הקוד.
4 - אם אחכה שכל המסמכים האלה יהיו כתובים לפני שאני מתחיל לעבוד, התוכנה תהיה באוויר כשאני רק אתחיל לכתוב את הטיוטה הראשונה.

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


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

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

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

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

 

[davidtzhmach]

כל הכבוד על השיתוף!!!

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

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

 

[halperin]

"לקוח" יכול להיות פנימי או חיצוני... כמו כן

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

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

 

[davidtzhmach]

כיף לראות שמתפתח דיון על הנושא..!