איך מחליטים

[nat1g]

איך מחליטים

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

 

[עמית ו]

זו שאלה קשה

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

 

[halperin]

עמית התייחס בחלק הראשון לשלב אותו תיארת - לחשוב ולתכנן

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

 

[עמית ו]

לא, הוא לא.

ניסיתי להתייחס בצורה הכי כללית שיכולתי לכל התהליך - כן STP או לא, אלה כבר פרטים לא מאוד מעניינים: יש מי שחושבים היטב בעזרת כתיבת מסמכים, יש מי שהדרך היעילה עבורם לחלוק את תהליכי המחשבה היא בעזרת מסמך, ויש מי שמסמך יהיה בזבוז זמן משווע עבורם. לכן אני מתייחס לכתיבת המסמך כאל חלק משלב הביצוע.
&nbsp
לפני שמגיעים לחלק של הביצוע, צריך להבין איך תהיה הדרך הנכונה לגשת לביצוע הזה - על ידי ניחוש (ותיקון בעקבות פידבק), שיחות עם בעלי העניין והבנה של הדרישות הרגולטוריות (אם יש). בשאיפה, נמצא מהשלב הראשון עם הבנה של מה הם התוצרים שאנחנו צריכים לספק: האם יש צורך במסמך מסוג כזה או אחר, או אולי מספיקה לנו שיחת מסדרון של חמש דקות (דוגמה: בהינתן פיצ'ר: הזזה של קבצי התמונות על שרת ווב לתיקיה אחרת. בדרך כלל, תוכנית בדיקות סבירה תהיה בערך "נעבור על כל הדפים באפליקציה ונגרום לכל התמונות להיטען, נוודא שהמצב תקין ע"י חיפוש 404 בaccess log" במקומות מסויימים, ירצו שנרכיב את רשימת הדפים\צעדים ונציג אותם בישיבה, במקומות אחרים ירצו מאיתנו פשוט לומר "זה מה שאני הולך לעשות" ואז להתחיל לעשות את זה בלי לבזבז זמן על כתיבת מסמך שאף אחד לא יקרא)
&nbsp

 

[nat1g]

המשך

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

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

 

[עמית ו]

זה תלוי בעיקר בך

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