הרצאה 15 - קורס Quality Center הראשון
פרקי ההרצאה: הרצאה 15 - קורס Quality Center הראשון
תמלול ההרצאה: הרצאה 15 - קורס Quality Center הראשון
הטקסט המלא של הדקות הראשונות בהרצאה «הרצאה 15 - קורס Quality Center הראשון» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
טוב, אז אנחנו היום נעשה מצגת שבעצם קצת תסביר לנו על פתיחת באגים וכל מה שאנחנו צריכים להכניס לתוך השדות בכל מיני מקומות זה לפני שנתחיל להריץ ולפתוח באגים כי כבר כתבנו את הטסט קייסים ואת הטסטים וזה מה שנשאר לנו.
נעבור עליה ונמשיך טסטינג לייף סייקל זה הכותרת שלנו בוא נמשיך אוקיי יש לנו מונחים והמונח הראשון שלנו זה unit יחידה אז בעצם יש לנו unit testing שזה בדיקות יחידה שזה בדיקות שבעצם עושים במהלך שאנחנו בעצם מפתחים את התוכנה שלנו את האפליקציה אנחנו עושים בדיקות יחידה היחידה עצמה אפשר להגדיר שזה בעצם הקונפיגורציה
הפריט לעשות לו קונפיגורציה הכי הכי קטן בתוך אפליקציה מסוימת והיא בעצם דבר שהוא עומד בפני עצמו אפשר להמשיך component קומפוננט זה בעצם זה set of choosetive requirements מה זה אומר בעצם? שיש לנו כמה requirements שאנחנו בוחרים
ואנחנו בעצם שמים אותם ביחד, אנחנו עושים איזה יחידה מסוימת, קצת יותר גדולה, שהיא עומדת בפני עצמה stand alone entity, ישות בפני עצמה, כחלק ממוצר או של package מסוים שזה בעצם קבוצה של דברים ביחד, אוקיי סרוויס יש לנו שירות כמו שזה נקרא אז זה בעצם קולקשן זה אוסף או קומבינציות
אוסף כל מיני קומבינציות של מוצרים של קומפוננטות שהם ביחד משדרים ומשרתים בעצם סרוויס מסוים, נמשיך סאב סיסטם מה זה סאב סיסטם זה לדוגמה סוג של פונקצ'ונליטי כל מיני יכולות לדוגמה כמו שנותנים פה טלפוניה נוטיפיקציה שזה בעצם לידע אותך בכל מיני דברים מסוימים
אוקיי יש לנו סיסטם שזה גם קומבינציה ואוסף של שירותים שמשרתים בעצם מערכת וזה בעצם מערכת והיא בעצם מוזמנת לפי הקסטומר שלנו זה לא חשוב פה נמשיך אוקיי אז יש לנו Testing Levels ויש לנו Prison Responsibilities בוא נמשיך זה לא כל כך קשור ה-Prison Responsibilities אבל ה-Testing
Levels אוקיי יש לנו רמה של טסטינג אז יש לנו חלק בעצם הנה בוא נזיז את זה קצת ימינה אתה חוצץ ואז נראה את זה יותר טוב Responsibility אוקיי מי אחראי לעשות את זה אז בוא נמשיך יש לנו Unit Testing שזה בעצם מי שעושה Developing Group וזה באימפלימנטיישן זה עד שאנחנו מתחילים בעצם ליצור את הסיסטם את המערכת שלנו אוקיי יש לנו Component Private Integration שזה
בעצם שוב פעם זה עוד סוג של בדיקות בדיקות קומפוננטה שהן נעשות באינטגרציה שזה אומר כאשר אנחנו מקימים את המערכת זה גם Developing Group יש לנו Component Testing שזה עוד פעם זה כמו Unit Testing רק קצת יותר גדול כמו שהסברנו מה זה קומפוננט טסטינג קומפוננט דבלופינג דבלופמנט גרופ
סרוויס סיסטם אינטגריישן שוב פעם זה אנחנו עושים בדיקות של סרוויס של סיסטם עוד פעם ברמה של האינטגרציה שזה בעצם להקים את הרשתית ולעשות אינסטוליישן וכל הדברים האלה וזה עדיין אנחנו עושים לא בדבלופמנט אלא אינטגריישן גרופ וזה באמת בחלק של האינטגרציה אוקיי עכשיו אנחנו מתחילים באמת להגיע לרמה שבה אנחנו
מתעסקים שזה סרוויס סאב סיסטם טסטינג שזה יש את הרמה הזאתי קצת למעלה מאיתנו וכמו שראינו פה שזה סאב סיסטם ויש את זה ברמה שלנו כשאנחנו בעצם טסטינג גרופ זה מי שאנחנו עושים אנחנו בודקים את זה כמו כל בדיקות יש לנו סיסטם טסטינג עוד פעם הסברנו מה זה סיסטם אנחנו אחראים על בדיקות כאלה וג'ינריק פקטורי
אקספטנס זה בעצם אומר שאנחנו עושים לדברים גנריים ומאוחר יותר זה הולך לאקספטנס ופה זה בעצם ההכנה לאקספטנס כמו שאומרים שהאקספטנס זה בעצם בזמן שאנחנו עושים טסטים והחבר'ה בעצם שמפתחים גם עושים טסטים וגם בונים אנחנו ביחד מגיעים לאותו מקום גם עם הדיזיינרים או אלה שנקראים סיסטם
אינג'ינירס כל מיני כאלה שהם בעצם מי שכותבים את האפיונים יושבים ביחד ורואים שאפשר להתחיל לבדוק מעבר לבדיקות שאנחנו כותבים אלא שזה מוכן להגיע ל-QA שזה אנחנו שזה בעצם יכול לעבוד מבחינה מינימלית אוקיי נמשיך Service System Sub-System Testing אוקיי אוקיי What Do We Test?
Test Objects אוקיי אז אנחנו מדברים עכשיו על Functional Requirements Verification אנחנו צריכים לוודא את ה-Requirements שלנו functional requirements בעצם מה זה אומר validation both in progression and regression אנחנו בעצם מוודאים שהrequirements שלנו באים לידי ביטוי בפרוגרסיה וברגרסיה אנחנו נדבר על שתיהם
ממש או-טו-טו E2E זה end-to-end scenarios for verification of system capabilities אנחנו צריכים לעשות זיקות מצד אחד לצד אחר של המערכת בשביל לעשות וריפיקציה של בעצם היכולות של המערכת אז זה בעצם כל הסוגים, זה סוגים של Functional Requirements
Verification ויש לנו Non-Functional Requirements Verification. אוקיי, מה זה אומר? בואו נקרא, יש לנו Load שזה בעצם עומס, יש לנו Performance שזה בעצם איך התוכנה פועלת בעצם, איך היא, זה גם סוג של Load האמת היא.
אוקיי, Stress, Stress זה גם סוג של Load, פשוט לוקחים את ה-Load, מוסיפים שלושים אחוז לואוד מאה אחוז זה מה שכולם מבטיחים לואוד עוד שלושים אחוז מאה שלושים אחוז זה נקרא סטרס רילביליטי זה בעצם שהיא באמת יכולה לעמוד על הרגליים כמו שאומרים יציבות סקיוריטי זה אומר כאשר בוא נגיד אף אחד לא יכול לחדור לתוך התוכנה שלנו אוקיי
נטוורק דאטה אובר וואן רילביליטי לואוד לוס דאטה כל הדברים האלה שבעצם מתעסקים בלמה יש לנו כאן גם לואוד וכאלה כי הכל בעצם לפעמים עובד בנטוורקינג אם זה בוא נגיד אפילו ניקח לדוגמה את אקדמיה שזה גם הרבה משתמשים על תוכנה אחת בו זמנית אוקיי אוקיי יש לנו עוד עוד כל מיני בדיקות אני לא יודע אם כדי שנמשיך יש לנו availability
redundancy שזה בעצם אם מערכת נופלת אז שיהיה זמינות ישר למערכת אחרת קונפיורביליטי שאפשר לעשות קונפיגורציה בנצ'מארק שזה עוד סוג של בדיקות עומס ניסטולביליטי שאפשר לעשות אינסטוליישן כל הבדיקות האלה זה בדיקות שהן לא כל כך מתעסקות ברקווירמנטס אלא יותר בממש דברים לה כל יש
רקווירמנטס אבל הן לא מתעסקות בפונקצ'ונליטי של רקווירמנטס אלא בדברים שעומדים בצד לא שהתוכנה מתחילה במקום אחד עובדת כמו שצריך איך עושה את כל ה-80% שמשתמשים צריכים להתעסק באלה, דברים שמהצד.
נמשיך. How do we test? Test type. אוקיי, יש לנו סוגי טסטינג. בואו נתחיל להסביר מה זה פרוגרשן. אוקיי.
פונקשן טסטינג should focus on any requirements for tests that can't be traced directly to use cases or business functions and business rules. מה זה אומר בעצם?
זה אומר בעצם שאנחנו הפונקציונל טסטינג, בעצם הבדיקות הפונקציונליות שאנחנו עושים, בעצם יש להם את הפוקוס על requirements. זה בעצם אנחנו בודקים כל פעם את הדברים הנוספים, החדשים.
כל פעם, למשל, מההתחלה עד הסוף. עוד requirements ועוד requirements ועוד requirements. זה לא דברים שאנחנו בודקים על העבר. זה לא דברים שאם יצא, בוא נגיד, בגרסה הקודמת, אז לרוב אנחנו לא נבדוק את זה בפוגרשן, אם אנחנו כבר זה עבר אז תלוי בזמן שיש לנו כל מיני מקומות אבל בדרך כלל זה פשוט בדיקות שרושמים אותן מחדש לסבב בדיקות חדש שהוא לא
בודק את הדברים שכבר נבדקו כי הם כבר יבודקו ברגרשן שהנה זה רגרשן טסט the objective of regression testing is to ensure software remains intact אוקיי זה בעצם פשוט לוודא שיותר נכון להגיד אפילו שבאמת התוכנה נשארת כמו שהיא אמורה להיות שה-requirements שהיו חוסו שה-bugs שנפתרו וכבר עברו עליהם והם נבדקו והכל בסדר עכשיו אנחנו כבר בגרסה הבאה או כבר המשכנו
הלאה ופיתחנו עוד משהו ובדקנו או בכלל היה סבב בדיקות נוסף אנחנו צריכים לדעת שגם עדיין תיקנו דברים אבל ה-bugs שנשארו סגורים עדיין סגורים זה אומר שלא נהרס עוד פעם שום דבר, בשביל זה יש לנו את הריגרשן, אוקיי, סייניטי טסט, זה בעצם בייסיק סיסטם בייסיק פונקצ'ונליטי, זה בעצם הדבר הכי בסיסי שיש לעשות,
לפני שאפשר לבדוק כל דבר, אנחנו עושים את זה, אנחנו עושים את הבדיקה הבסיסית הזאתי, ורק אחריה נוכל לעבור ליותר פנימה, זה אפטר אינסטוליישן, עושים את זה רק אחרי שאנחנו עושים אינסטוליישן, ואנחנו עושים את זה בסביבת הבדיקות, אוקיי, ATP test, אוקיי, the process of demonstrating to the customer the system
meets the specification, בעצם זה כמו שאומרים ב-ATP יש כל מיני עוד מושגים, זה עוד סוג של acceptance שאנחנו נמצאים עם ה-customer שזה הלקוח, אנחנו אומרים לו שהתוכנה בסדר, שהיא עושה את הספציפיקציה שלה, היא מקיימת את הדרישות.
אוקיי, נמשיך. דיפקט סביריטי אנחנו יש לנו קריטיקליטי וסביריטי, אז מה זה אומר? אוקיי, קריטיקל. אם אנחנו שמים בסביריטי קריטיקל, זה אומר שיש לנו, אוקיי, שנייה אחת.
אוקיי, קריטיקל, סביריטי, חומריות. אז defect involving the more functionality of the, סליחה defect involving the malfunctionality of the system בוא נגיד ככה פשוט יש לנו בעצם defectים שזה בעצם באגים שנפתחו שהם קשורים לתפקוד הפגום תפקוד פגום אפשר להגיד לתפקוד
לא מלא של המערכת שזה משהו שלא יכול לתת לנו להמשיך כל כך הלאה ממש משהו רציני. הכל מייג'ור זה בעצם דיפקטינג שמובילים אותנו לדגרציה דגרדציה זה בעצם אנחנו בעצם מה שהלקוח רואה מה שהקסטומר מקבל זה כבר לא בדיוק מה שהוא היה אמור לקבל זה הידרדרות באיך שהתוכנה כבר מתפעלת מבחינת
או שבעצם יש לנו פאנק כן זה מה שזה עושה פחות או יותר אוקיי מיינור זה זה בעצם דברים שזה לא, זה פשוט דברים שהם נתפסים ומשפיעים על הפונקציונל הטי שהם דברים מאוד קטנים שבעצם אנד יוזר רואה, זה הכל.
אפשר להגיד במיין, בוא ניתן דוגמא לכל אחד, בוא נגיד אפילו אם יש לנו defect שהוא דוקיומנט למשל אם המסמך fsd יש בו אפילו טעות זה גם באג אז במסמך fsd שזה אפיון אז אפשר לקרוא לזה מיין או או אם בוא נגיד יש לנו מערכת שאמורה לתת הרצאות ובעצם פשוט יש לנו משהו בעיה בגוי שיש גייטקטיב
זה גם יכול להיות מיינור מייג'ור זה כבר יכול להיות בעיה שברג'יסטריישן אז הקוד שהוא מביא הוא בעייתי בוא נגיד