הרצאה 1 - קורס Quality Center השלישי

תמלול ההרצאה: הרצאה 1 - קורס Quality Center השלישי

הטקסט המלא של הדקות הראשונות בהרצאה «הרצאה 1 - קורס Quality Center השלישי» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.

1. 00:03

   היום אנחנו נלמד על ה-Quality Center. ה-Quality Center זה בעצם, אנחנו נדבר גם על הנושאים מעבר לעובדה שאני אסביר מה זה ה-Quality Center, אנחנו גם נדבר על מה זה ה-Test Director, שהוא בעצם הגלגול הראשוני של ה-Quality Center, לשם מה הוא קיים, ואנחנו נראה את ההתפתחויות של ה-Test

2. 00:24

   Directory בתעשייה. זה בעצם אומר, המעבר של טסט דירקטור ל-Quality Center. אנחנו נקבל סקירה, אני אסביר לכם סקירה קצרה על המודולים השונים הקיימים ב-Quality Center ואנחנו נדבר באופן קצת יותר פרטני על ה-Specified Testing Requirement

3. 00:46

   שזה בעצם המודול הראשון ב-Quality Center שבעצם ממנו אנחנו נתחיל להגדיר את דרישות הבדיקות שלנו מהספציפיקציה או מהתוכנה או מהמוצר שאותו אנחנו רוצים לבדוק אוקיי נתחיל מה זה בעצם ה-Test Director ולשם מה הוא קיים?

4. 01:08

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

5. 01:30

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

6. 01:57

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

7. 02:28

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

8. 02:59

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

9. 03:25

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

10. 03:47

    נראה אותו בהמשך ההרצאה היא יותר פישטה אותו יותר ארגנה אותו בטסט דירקטור היו יותר תהליכי עיבוד ויותר תהליכי ניתוח ה quality center הוא ב-95% על אותם פיצ'רים שהיו לטסט דירקטור הוא פשוט מאורגן ויזואלית קצת שונה ופחות תהליכי ניתוח זהו לכאורה ההתפתחויות בתעשייה של הטסט דירקטור.

11. 04:16

    המודולים השונים הקיימים, אנחנו נראה את זה כרגע. זאתי תוכנת ה-quality center, היא מאוד דומה ברמה הוויזואלית של הטסט דירקטור.

12. 04:28

    פה אנחנו יכולים לראות את ארבעת המודולים העיקריים, יש לנו פה את ה-requirement, זה בעצם המודול שבו אני מגדיר את דרישות הבדיקה. מודול ה-Test Plan זה בעצם המודול שבו אני אגדיר את הטסטים שלי, כמובן שזה ריק מאחר ולא הכנסנו כאן שום טסט, שום פרמטר מסוים.

13. 04:49

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

14. 05:13

    אוקיי, נחזור למודול של ה-requirement, אז אלה בעצם השלבים שאני אדבר עליהם במהלך הפרזנטציה הנוכחית. אוקיי, השלב הראשוני, שזה בעצם השלב הזה, השלב של ה-requirements, הוא בעצם מורכב מצאב נושאים, מתת נושאים, ואלה הם התת נושאים של ה-pathify requirements שזה השלב הזה, שוב, של הגדרת הדרישות. השלב הזה הוא השלב הכי חשוב,

15. 05:48

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

16. 06:03

    הוא מאוד קריטי מאחר ובמידה והדיזיין שלי לא נכון, כל שאר הפעילויות שלי יהיו לא נכונות וזה משהו שהוא מיותר והוא חבל. אז כמו שאתם רואים, זה השלב הראשוני, Specify Requirements, הטסט פלאן, זה המודול הזה, המודול השלישי זה Execute Test, בעצם השלב שבו אני כאן מריץ את הטסטים, וה-Track Defect,

17. 06:33

    השלב שזה השלב הזה, המודול הזה, בו אני מבצע מעקב אחר הדיפקטים שלי, שימו לב גם לשדות, בהמשך אתם תראו מה המשמעות של זה, מה המשמעות של Defect ID, של הסטטוס שלו, מי יצר אותו, מה רמת החומרה שלו וסיכום של ה-defect.

18. 06:56

    נחזור ל-requirements ונראה את השלבים של ה-requirements. אלה השלבים של ה-requirements, זאת אומרת, התת-שלבים בעצם של המודול הזה. התת-שלבים של המודול הזה זה, השלב הראשון הוא-Define Testing Scope.

19. 07:18

    ב-Define Testing Scope בעצם אני מגדיר את סקופ הבדיקות שלי, זאת אומרת, טווח הבדיקות ואת ההגדרה הפרויקטלית של הבדיקות שאני מעוניין לעשות.

20. 07:32

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

21. 07:44

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

22. 08:10

    לדעת להגדיר ב-requirement שאני מעוניין לבדוק שאכן ה-calculator יודע לעשות 2 פחות 2 הוא יודע לעשות שורש של 4 והוא יודע לעשות שורש של 9 אבל אם אני אעשה לו שורש של 0 והוא צריך להוציא לי error זאת אומרת אני אמור להגיד מה המוצר גם מה הוא אמור לעשות ואני גם צריך להגדיר בבדיקות שלי מה הוא לא אמור לעשות ואכן לבדוק שהוא לא עושה את מה שאני לא רוצה שהוא יעשה מה

23. 08:41

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

24. 09:03

    Sanity טסט זה בעצם הבדיקה הכי בסיסית שאני מבצע למוצר. זה בכלל לבדוק אם המוצר עושה את הדברים הבסיסיים ביותר. זאת אומרת, אם החברה שלי נניח פיתחה איזשהו מחשבון והמחשבון אמור לבצע אחד ועוד אחד, זאת תהיה הבדיקה הפשוטה וברמת הסאניטי, זאת אומרת אני בא למחשבון ולוחץ אחד ועוד אחד ורואה אם התוצאה בטקסט בוקס היא באמת 2 ולא יוצא

25. 09:31

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

26. 10:03

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

27. 10:26

    למה? כי ככה הלקוח רוצה וזה מה שמעניין אותו. השלב הבא זה ה-Create Requirement. לאחר שהגדרנו את הדרישות, אני ממש יוצר את הדרישות שלי. זאת אומרת, אני נכנס לשלב הזה, ל-Requirements, ואני מגדיר מהם הדרישות, כיצד אני מבצע את זה.

28. 10:43

    אני מבצע את זה פה בשלב הזה. אנחנו נראה איך אנחנו מגדירים New Requirement ואנחנו נבצע את זה.

29. 10:50

    לאחר שיצרתי את ה-Requirement, אני מפרט Detail Requirement, אני מפרט את הדרישה. כמובן, אני לא נכנס לכאן ולאחר שיצרתי Requirement, אני לא מפרט יותר מדי. הרעיון הוא לפרט ברמה של שלושה-ארבעה משפטים מה הדרישה צריכה לבצע ולתת לה את כל הערכים והפרמטרים שה-Quality Center דורש ממני.

30. 11:14

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

31. 11:31

    עשו מחקרים וגילו שרוב הטעויות שנוצרות או רוב הבאגים שקורים, Bugs are a cause for numerous reasons בגלל המון סיבות, אבל ברוב הסיבות שמתרחשות זה בעצם בשלב של הספציפיקציה. זאת אומרת, גילו שהבאגים שמתרחשים הם בעצם באגים שראו שבכלל לא הגדירו נכון את הדרישות מהמוצר ואנחנו גם יכולים לראות שהרוב הוא נובע במקום

32. 12:04

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