ניהול תצורה וסיכון
פרקי ההרצאה: ניהול תצורה וסיכון
תמלול ההרצאה: ניהול תצורה וסיכון
הטקסט המלא של הדקות הראשונות בהרצאה «ניהול תצורה וסיכון» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
ניהול תצורה סעיף 5.4 מטרה של ניהול תצורה בעצם לוודא שצוות הבדיקות עובד בשיטה כזאתי שבאמת תביא את התוצרים המצופים ממנו על ידי הארגון.
כדי לתמוך בבדיקות בצורה נכונה ניהול התצורה יהיה מעורב בווידוא הדברים הבאים כל פריטי בדיקות ועל איזה יהיו ייחודי מספר רץ זאת אומרת טסט קייסים תקלות requirements ודברים אחרים לכל אחד ואחד מהם יהיה מספר מזהה אתה יהיה לו בקרת גרסאות, זאת אומרת הוא יהיה גם יכול להיות משוייך לגרסה מסוימת, לא בהכרח, יכול להיות שיש טסטים שירוצו בין גרסאות,
אבל אנחנו נוכל לשייך טסט סטים לגרסאות מסוימות. מעקב אחרי שינויים ומתייחסים לזה, זאת אומרת אנחנו נוכל לראות את השינויים שבוצעו בטסט קייסים שונים או ברקווייאמנט שונים במהלך הגרסאות או תוך כדי העתיקה.
אני רוצה לחזור ולהגיד test set זה בעצם מאגד כמה טסט קייסים שאנחנו מבצעים אותם ובעצם הוא יכול לעבור ולהשתמש באותה תכולה של טסט קייסים בין סבב לסבב ובין גרסה לגרסה של הבדיקות.
אם בגרסה מסוימת יש מודול או פיצ'ר או חלק בתוך האפליקציה בתוך התוכנה שלא השתנה בעצם אז אנחנו יכולים להשתמש באותם טסט קייסים או לעדכן רק את הטסט קייסים קלה ולהשתמש בהם שוב.
כל פרטי הבודקה בעלי זיהוי ייחודי כמו שאמרנו תחת בקרת גרסאות, זאת אומרת כל הגרסאות או כל הסבבים שאנחנו בודקים הם גם הם עם פריט זיהוי, זאת אומרת גם צוות הפיתוח צריך לעבוד עם גרסאות על מנת שאנחנו נוכל להעביר דוח מסודר של תוצרי הבדיקה מול במקביל לתהליך של גרסאות הפיתוח.
קו אחר שינויים מתייחסים זה לזה ומתייחסים לגרסאות של פריט. זה יעזור לנו בנקבות, מה שנקרא תריסביליטי. מוכן בעצם לוודא באמת את המצב בדיקות של כל חלק וחלק בעזרת המספרי גרסאות והתיעוד שהוא משותף לשני החלקים, גם של הבודקה וגם של הבריטי הבדיקות.
מסמכי הבדיקות מתייחסים בצורה חד משמעית לכל המסמכים ופריטי התוכנה המזוהים, זה חשוב. זאת אומרת שלכל ריקווארמנט וריקווארמנט משויכים גם פרטי בדיקות.
לכל חלק או מודול במסמך האפיון בעצם יש חלק מקביל אליו גם בפרטי הבדיקות. אנחנו נצטרך להראות את זה ולהשתמש בזה במהלך הדוחות במהלך הריצה. סיכון ובדיקות סעיף 5.5 הגדרה של סיכון סיכון קשור באפשרות להתרחשות אירוע עתידי שיהיו לו תוצאות שליליות רמת הסיכון נקבע על ידי הסבירות להתרחשות האירוע וההשפעה זאת אומרת ככל שההשפעה יותר דרמטית
והסבירות שהאירוע יתרחש יותר גבוה כך ההגדרה של הסיכון היא חמורה יותר ככל שההשפעה של האירוע והסבירות שלו נמוכה יותר זאת אומרת ההשפעה שלו נמוכה יותר והסבירות שזה יקרה נמוך יותר כך ההגדרה של הסיכון נמוכה יותר סיכוני מוצר וסיכוני פרויקט סיכוני מוצר כוללים את האפשרות של תוצר לדוגמה מפרט רכיב,
מערכת או בדיקה ייחשלו לענות על הצרכים הלגיטימיים של המשתמשים או בעלי העניין שלהם, כאשר סיכוני המוצר קשורים עם מאפייני איכות מסוימים של המוצר לדוגמה התאמה פונקציונלית, אמינות, יעילות ביצועים, שימושיות, אבטחה, תאימות, תחזוקתיות וניידות.
סיכוני מוצר נקראים סיכוני איכות. לסיכוני מוצר כולל תוכנה אסורה לא לבצע את הפונקציונליות המצופה ממנה על פי המפרט לא לתת תוצרים לדוגמה אפליקציה וייז לא תנווט בצורה נכונה תוכנה אסורה לא לבצע את הפונקציונליות המצופה ממנה על פי צרכי המשתמש הלקוח הוא בעלי העניין גם אם היא נגיד הווייז תביא אותנו למקום מסוים אבל בדרך מאוד מסובכת ומסורבלת
וארוכה אז למקרה הזה היא לא תבצע את הפונקציונליות שלה התכנון המבנה של מערכת לא תתמוך בצורה נאותה בדרישות לא פונקציונליות זאת אומרת אם המערכת היא כתובה בצורה לא ברורה העיצוב שלה לא אסתטי או דברים כאלה גם זה יכול לגרום לסיכון ולכישלון של הגרסה חישוב מסוים עשוי לעשות בצורה לא נכונה ובתנאים מסוימים נגיד מערכת לחישוב משכנתא אם היא מחשבת את
ההחזרים לא נכון זה עלול לגרום לכישלון של המערכת קוד שלולת בקרה עשוי להיכתב בצורה לא נכונה זמני תגובה עשויים לא להתאים user experience זה performance כן אם מערכת היא מאוד איטית תחשבו על מערכת כמו הזמנת סרטים אנחנו נחכה המון זמן עד לאישור הטרנזקציה אז בעצם המערכת תיכשל ואנחנו לא נשתמש בה חוויית משתמש user experience ux לא מתאים לציפיות
מהמוצר זאת אומרת בסביבה טכנולוגית תחרותית אנחנו מצפים גם לאפקט וואו לאפקט של התלהבות של המשתמשים ולא שעמום או אדישות. סיכוני פרויקט כוללים מצבים שבמידה והתרחשו ישפיעו בצורה שלילית על יכולת הפרויקט להשיג את מטרותיו.
לדוגמה, עיכובים שעשויים להתרחש במסירה, עיכובים עשויים לחשוף את החברה לתביעות, אומדנים לא מדויקים, הקצאת משאבים לפרויקטים חשיבות גבוהה יותר, קיצוצי תקציב, בכל ארגון עשויים לגרום לתקציב לא מתאים.
זאת אומרת, ארגון התחייב לתהליך בדיקה מסוים ואז אין לו את המשאבים לבצע את זה אז בעצם זה סיכום גדול מבחינתו. שינויים מאוחרים עשויים לגרום לכמות משמעותית של עבודה מחדש, זאת אומרת אם היה כשל באפיון או בתכנון הראשוני אנחנו עלולים להגיע למצב שהפרויקט מתאחר בגלל ריפקטורינג או כתיבה מחדש של מודולים.
בעיות ארגוניות, כישורים של העובדים, הדרכות וכוח אדם עשויים להיות לא מתאימים, בעיות בין אישיות בין הצוותים, סכסוכים, כל זה עלול לגרום לעיכוב.
משתמשים צוות עסקי או מומחים בתחום עשויים להיות לא זמינים בשל סתירה בעדיפויות עסקיות. זה מקרה שבפרויקטים מורכבים שדורשים אינטגרציה עם מערכות ומחלקות וצוותים אחרים בתוך הארגון ומחוץ לארגון בעצם נוצר חוסר סנכרון, מה שמוביל לבזבוז זמן של הצוותים.
זאת אומרת, לא הכל תלוי בצוות בדיקות, לא הכל תלוי בצוות פיתוח, לא הכל תלוי לפעמים בארגון עצמו, אלא בגורמים גם מחוץ לארגון שצריכים לספק את החלק שלהם בתוך הפרויקט.
בעיות פוליטיות, הבודקים עשויים לא לפרסם ולהעביר את צרכיהם או את תוצאות הבדיקה בצורה נאותה.