
הטקסט המלא של הדקות הראשונות בהרצאה «תכנון בדיקות» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם בפרק 5.2 מחומר ההסמכה של ה-STQB נדבר על מטרת תוכנית הבדיקות ותוכן תוכנית הבדיקות תוכנית בדיקות טסטפלנד מתארת את פעילויות הבדיקה עבור פרויקטים של פיתוח ותחזוקה התכנון מושפע ממדיניות הבדיקות ואסטרטגיית הבדיקות של הארגון ממחזור חיי הפיתוח
ומשיטות שמונהגות בארגון הגדרת היקף הבדיקות מטרות סיכונים מגבלות קריטיות בדיקתיות וזמינות המשאבים. בעצם מה שאנחנו רוצים להגיד בפסקה הזאתי זה שהטסט פלאן הוא בעצם המסמך שעליו אחראי בדרך כלל מנהל הבדיקות, מנהל צוות הבדיקות אמור לשקף את התרבות או את הנוהלי העבודה בארגון.
לדוגמה טסט פלאן שנכתב בארגון שעובד בווטרפול מפל מים ייראה שונה מטסטפלן שנכתב בארגון שעובד בצורה אג'ייל.
אז בטסטפלן בארגון שעובד בווטרפולד הוא ייראה בצורה אחרת עם משכי זמן יותר ארוכים לעומת זאת באג'ייל טסטפלן יהיה יותר מקוצר יותר תמציתי ומחולק לאיטרציות קטנות וקצרות.
מסמך הטסטפלן אמור לענות על השאלות המרכזיות שבעצם משקפות או אמורות להעביר לדרג הניהולי את המטרות והיעדים וצורת העבודה של צוות הבדיקות על מנת לוודא ולהקטין את הסיכונים בתהליך הפיתוח של התוכנה.
הטסטפליין אמור לדווח מתי יתבצעו הבדיקות, מה כוח האדם שאמור לבצע אותן ואיזה מערכות הפעלה יבוצעו, איזה מכונות וירטואליות נדרשות, כמה זמן זה ייקח, איזה מערכות אוטומטיות יעשה בהן שימוש, איזה הכשרה תהיה לבודקים.
שוב, להדגיש שטסט פלאן הוא לא דבר סטטי, זאת אומרת המסמך עצמו נכתב וכל הזמן יהיו גרסאות ועדכונים. בגלל זה הרבה פעמים מנסים לעשות את התהליך הזה כמה שיותר דינמי וכמה שיותר אינטגרלי לתהליך העבודה, זאת אומרת שזה לא איזשהו מסמך סטטי ברשת, אלא תהליך שכל הזמן יהיה איתו אינטראקציה, יעבירו אותו, ינהלו אותו,
ובעצם ידאגו שהוא יהיה רלוונטי. תכנון הבדיקות, כתיבת המסמך טסט-פלנד ובכלל התכנון של הבדיקות היא פעילות מתמשכת שמבוצעת לאורך כל חיי מחזור המוצר, לא רק בשלב התכנון.
ניתן להשתמש במשוב על פעילויות הבדיקה כדי לזהות שינויים בסיכונים וכך להתאים את התכנון. ניתן לתעד את תכנון הבדיקות בתוכנית בדיקה כוללת, ותוכניות בדיקה נפרדות קטנות יותר כמו בדיקות שימושיות או בדיקות ביצועים פרפורמנס טסט פעילויות תוכניות בדיקה עשויות לכלול את הפעילויות
הבאות קביעת תכולת הבדיקות, מה ההיקף, מה הסקופ שהצוות בדיקות הולך לכסות בתהליך העבודה שלו, מטרות הבדיקות והסיכונים בבדיקות, מה הסיכונים להצלחה בתהליך הבדיקה, הגדרת הגישה הכללית לבדיקות, האם אנחנו הולכים לעבוד בצורה של יותר פונקצ'ונל,
פחות גרועי או יותר גרועי ופחות פונקציונל באיזה שלב אנחנו נכנסים לעבודה באיזה שלב אנחנו באים לתעד את התקלות ולעבוד בצורה יותר או פחות אינטנסיבית מול צוות הפיתוח שילוב ותיאום פעילות הבדיקה עם פעילויות מחזור אחרי התוכנה אם אנחנו מסתכלים באתר גורו 99 על דוגמה ל sdlc software development life cycle
אנחנו יכולים לראות את החלוקה לפרקים הבאים ניתוח הדרישות, ניתוח היכולות, המימוש, התכנון, ביצוע כתיבת הקוד, מימוש כל האפיון, כל החלק האפיוני, בדיקות, תהליך ההתקנה והשדרוג לגרסה והתחזוקה.
אוקיי, זו איזושהי תצוגה מאוד מאוד תיאורטית של ה-Software