סיכום - קורס Quality Center השני
פרקי ההרצאה: סיכום - קורס Quality Center השני
תמלול ההרצאה: סיכום - קורס Quality Center השני
הטקסט המלא של הדקות הראשונות בהרצאה «סיכום - קורס Quality Center השני» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
טוב, אז אני אדבר על טסט דירקטור, כלי של מרקיורי למעקב אחרי באגים. אז הדבר הראשון שעושים בו כשבאים למוצר קיים או מוצר חדש, זה בונים את עץ התתי המערכות שיש לאותו מוצר.
כאן זה כתוב קצת בסינית, אבל למשל באאוטלוק היינו כותבים כאן משהו כמו הודעה חדשה, שליחה או קונטקס או כל מיני דברים כאלה.
כל תתי הנושאים, באאוטלוק, באאוטלוק, נתתי דוגמה למוצר, דוגמה למוצר שבודקים, כן. לבדוק את אאוטלוק? כן, למשל. אני אומר אאוטלוק, כי זה פשוט, כולם מכירים את אאוטלוק.
הבנתי. זאת אומרת, אם היית רוצה לבדוק את אאוטלוק? אם הייתי רוצה לבדוק את אאוטלוק, כן. פשוט מחלקים מראש את כל מוצר לתתי מערכות, למודולים, לתתי מודולים, כדי שיהיה יותר נוח.
אז לכל תת-נושא שכזה, אנחנו צריכים להכין את ה-Test Plan, או Test Rules, טסט טול דפינישן מספר ורסיות אז הטסט טולס מה שנקרא לזה בשם כללי זה מה בעצם צריך לבצע זה אנחנו רושמים בשבילנו וגם בשביל מי שיבוא אחרינו וכל מי שרוצה לראות תיעוד של כל הבדיקות שזה מחולק לטפס שזה סתם מספור לדסקריפשן זה הפעולה שיש לעשות
ואקספקטד ריזלט למה אנחנו מצפים שיקרה למשל ייכנס עם שם שגוי בצע לוגין עם שם שגוי והפעולה שאנחנו מצפים לה זה שתתקבל איזושהי הודעה פגיעה למשתמש או בצע לוגין עם שם נכון, מה שאנחנו אמורים לראות זה כניסה למערכת אז כך רושמים כל הסטייפים, זה נקרא סטייפים, רושמים את כולם אחרי שסיימנו לרשום את כל הסטייפים האלה, כמובן
שאפשר גם להדפיס אותם אבל כל הרעיון בטסט דירקטור הוא שנוכל לעבור עליהם ולסמן לעצמנו סעיף סעיף מה הצליח, מה קיבל את התוצאה המצופה ומה נכשל, מה קיבל תוצאה אחרת.
אז מאותו מסך שהיינו בו קודם אנחנו מגיעים למסך ההרצה, מה שנקרא הראן. איך הגענו לפה? בגלל שהתמונה היא סטטית אז זה בעיה לראות.
זה נקרא טסט לב ושם יש את אותה רשימה ופשוט בוחרים בדיוק את אותו str שיצרנו. SDR, טסטלן, SDR, סופטוור טסט, רולס, נניח טסטלן, לא משנה כל כך כרגע, טסטלן זה שם כללי לתכנון הבדיקות, ששם לפעמים לא מסתפקים ברישום טאפ, דיסקריפצ'ן ואקספקטד ריזלט, אלא לפני כן מציינים בדיוק את מטרות הבדיקה, מה ייחשב כישלון, מה ייחשב כהצלחה,
אם זה למשל עומסים, אז בכמה עומס אנחנו מצפים שזה יעמוד, וכל מיני דברים כלליים כאלה. זה טסט רולס ממש, זאת אומרת, סטפ, סטפ, סטפ, סטפ.
זה מאוד מאוד בסיסי. ויש גם מסמכים שבהם רושמים את כל המסקנות בסוף, ואז זה מסמך יותר מפורט. נחזור רגע לפה.
פה אנחנו ממש מבצעים בעצמנו בדיקה ידנית, זאת אומרת, הטסט דירקטורי לא עושה בשבילנו כלום. פה אנחנו רק... תסביר שהטסט דירקטור הוא טופסולוגיה. הטסט דירקטור הוא טופסולוגיה.
זאת אומרת זה נועד לכל הבירוקרטיה של מעקב אחרי באגים ואחרי בדיקות והוא לא מבצע שום דבר בעצמו, זה לא כלי אוטומטי. אז אנחנו עוברים על ה-Test Plan שכתבנו ומבצעים בעצמנו על המוצר בדיקה אחרי בדיקה וכל בדיקה אנחנו מסיימים אם היא עברה או נכשלה.
זאת אומרת זה עבר עם ה-V וזה נכשל עם ה-X וכשאנחנו מבצעים את זה, פה זה סטטי אי אפשר לראות אז נפתח לנו למטה אם זה כישלון אז סיבת הכישלון וכל מיני פרטים נוספים שאנחנו יכולים להוסיף שיעזרו לשחזר את הבאג או להבין אותו במועד יותר מאוחר אם אנחנו נבצע את הבדיקה שוב שיהיה לנו קל לשחזר אז אנחנו מבצעים כאן את כל
הבדיקות וברגע שאנחנו מוצאים באג אז אנחנו מכניסים אותו לדאטאבייס של הבאגים זאת אומרת add defect ואנחנו צריכים להתחיל להכניס את כל הפרטים אז בסאמרי אנחנו חייבים לרשום את הבאג בצורה הכי הכי כללית זאת אומרת לא תיאור מפורט אלא קורה כך וכך בלי הסברים באיזה מקרים בדרך כלל סיין 2 זה לאיזה מתכנת כי המתכנתים עצמם מסתכלים על עוברים
על רשימות הבאגים ורואים מה שמוכוון אליהם הם מתקנים אותו ואפשר גם לעשות שהם יקבלו מייל על כל באג בגלל זה זה חשוב קטגורי זה אם המוצר מחולק לכל מיני קטגוריות זה לא תמיד שדה חובה זה חלק מהשדות כאן אפשר שהם יהיו חובה וחלק לא אז קטגוריה אם כן אז יש פה קומבו בוקס שמפרט את כל הקטגוריות
Detected Inversion זה גם כן גרסה שמכניסים בדרך כלל ל-QA הוא אחראי להכניס כאן את הגרסאות זאת אומרת לפני שבכלל מבצעים לוגין ל-Test Director אז מכניסים את מספר הגרסה שבודקים עכשיו ואז הוא יופיע גם כאן בקומבו בוקס אסטימט פיקס טיים זה לא מעניין את ה-QA כי הוא לא יודע אופרייטינג סיסטם זה אם יש חשיבות למערכת
ההפעלה או לקונפיגורציה פריוריטי זה כן הQA קובעים, אם זה באג שהוא חמור, לא חמור פריוריטי זה עדיפות, האם הבאג הוא קריטי, למשל סרבר בכלל לא עולה וכל התוכנה מתרסקת לגמרי, או שיש שגיאת כתיב, או כל מיני סוגים של עדיפויות שהוגדרו מראש.
רגרשן זה צעדי yes/no שהוא לא תמיד מופיע, זה האם הבדיקה היא בדיקה חוזרת על סבב בדיקה שכבר בוצע. למשל בדקתי מוצר, מצאתי בו ככה וככה באגים, ועכשיו אני בוטג אותו שוב אחרי שכל הבאגים תוקנו, ומצאתי עוד באג בסבב שהוא רגרסיה, זאת אומרת הסבב השני.
סבב זה ביצוע כל הבדיקות על המוצר, בדיקות שמקיפות את כל המוצר. כל הצעת גרסה עוברות, כל הבאגים עוברים? כל הצעת גרסה עוברים, מסתכלים על כל הבאגים הקודמים, הפתוחים עדיין, כי זה בדרך כלל נקודות שהן כמו שיש חלודה ויכולה להתפשט, אז מעיפים מבט שם על אותו נושא.
מסתבר לך שגם פה הוא לא יהיה טוב, במיוחד אם הוא לא סומן פיקס על ידי המתכנתים. וזהו, סבב זה פשוט לעבור על כל הבדיקות שהוגדרו, שאנחנו הגדרנו לעצמנו בסטפים, סטפים שאנחנו כתבנו.
מה זה אומר רגרשן? רגרשן זה שדה yes/no שמציין האם זה סבב שהוא לא ראשון או כן ראשון. זאת אומרת, אם זה רגרסיה זה לא סבב ראשון. זאת אומרת שזה סבב שני או שלישי או רביעי במקרים קשים הלאה.
בראוזר זה חלק מהקונפיגואציה, אם זה קרה למשל רק בבראוזר Firefox או רק באינטרנט אקספלורר 7 וכו'. Detected by זה מי שמצא את הבאג כדי שהמתכנת, אם יש לו שאלות, יוכל לחזור בקלות לאותו בן אדם.
הזמן מוכנס אוטומטית. שפה זה אם יש שפות שונות למוצר, למשל עברית, אנגלית, אז אם הבאג מתייחס לשפה מסוימת. closing version זה הגרסה שבה זה מתוכנן להיסגר, זה גם מה QA מגדיר, project זה גם בדומה לקטגוריה, מגדירים מראש מה נחשב project, מה נחשב קטגוריה, זה בדרך כלל ראש צוות ה-QA מגדיר
מראש, reproducible, yes, no, האם הוא ניתן לשחזור או שהוא באג כזה שקרה ולא מצליחים לשחזר אותו, אם יש attachments אנחנו מוסיפים אותם על ידי האייקון הזה והם מתווספות לפה, או אם זה משהו שנמצא על המסך, יכולים להשתמש במצלמה ואז ללכוד את המסך תמונה
חד פעמית. והשדה החשוב ביותר, ה-Description, פה אנחנו רושמים ממש את כל הבאג על כל ההיבטים שלו.
איך הוא קרה, מתי הוא קרה, איך לשחזר,