PracticU

מבוא ל-QA ולבדיקות - חלק 2

בלי כתוביותעם כתוביות
PracticU › קורס בדיקות ידניות - Manual Testing › מבוא ל-QA ולבדיקות - חלק 2
מילון מושגים:
QA - הבטחת איכות (Quality Assurance): תחום שעוסק בבדיקת תוכנה ובתהליכים שמבטיחים שהמוצר עומד בדרישות.
דרישות - התיאור של מה שמערכת או תוכנה צריכות לעשות, המשמש בסיס לפיתוח ולבדיקות.
רכיב - יחידת בניין עצמאית וניתנת לשימוש חוזר בתוך מערכת או ממשק משתמש, שאחראית על חלק מוגדר מהתפקוד.
באג - תקלה או שגיאה בקוד שגורמת לתוכנה להתנהג בניגוד למצופה.
מקרה בדיקה - תיאור של תרחיש בדיקה בודד: הקלט, הצעדים והתוצאה המצופה, לצורך בחינת תקינות תוכנה.
סקריפט - קובץ המכיל רצף פקודות שמבוצעות על ידי מפרש, לרוב כדי להפוך משימות לאוטומטיות.
בדיקות אוטומטיות - הרצת בדיקות תוכנה באמצעות סקריפטים וכלים, במקום בדיקה ידנית, כדי לחסוך זמן ולהגדיל כיסוי.

מבוא ל-QA ולבדיקות - חלק 2
השיעור ממשיך את מבוא ל-QA ועוסק באנשים שעובדים עם הבודק בפרויקט פיתוח, במה כל אחד צריך ממנו, ובסיבה שבדיקה מלאה אינה אפשרית.
אנשי הפרויקט
1. הנהלת הפרויקט: נותנת הבנה של המטרה ושל לוחות הזמנים, ומקבלת מהבודק את סטטוס האיכות ואישור לשחרור גרסה.
2. מתכנתים: מממשים את הדרישות, מסבירים איך הרכיבים בנויים מבפנים, ומעדכנים שינויים בקוד.
3. בודקים נוספים: מכירים באגים ידועים ודרכי בדיקה, ויכולים להציע כלים קיימים.
4. הלקוח: נותן את הדרישות ומקבל את התוצר. הבודק מסביר לו בעיות ושינויים.
מה כל צד צריך מהבודק
1. מתכנתים: מידע מדויק על הבאג, איפה הוא נמצא, איך משחזרים אותו, ומה בדיוק נבדק.
2. הנהלה: דיווח על איכות המערכת ועל האפשרות לשחרר גרסה.
מורכבות הבדיקות
1. דוגמה: שדה שמכיל שישה תווים אלפא-נומריים ורגיש לאותיות גדולות וקטנות. בכל מקום יש 62 אפשרויות, כלומר 62 בחזקת 6, שהם כ-56 מיליארד מקרים.
2. המסקנה: בדיקה מלאה אינה אפשרית, ולכן בוחרים מה לבדוק לפי מתודולוגיות.
מתי מפסיקים לבדוק
1. דדליין: כשמגיע מועד ההגשה שנקבע.
2. תקציב: כשהתקציב של הבדיקות מסתיים.
3. כיסוי: כשהגיע אחוז מוסכם של פונקציונליות ודרישות שנבדקו.
4. רמת באגים: כשמספר הבאגים יורד מתחת לסף שהוגדר בתחילת הפרויקט.
מה הבודק עושה
1. תכנון מקרי בדיקה: לפי הדרישות ולפי מתודולוגיות.
2. כתיבת סקריפטים לאוטומציה.
3. דיווח על באגים ואישור איכות: הבודק מחליט אם התוכנה מוכנה לשחרור.
שימו לב
לעיתים בודקים נדרשים לבדוק תוך כדי עבודה ללא תסריט כתוב. זה דורש ניסיון, ואפשר לעשות זאת רק כשמכירים את הדרישות היטב.
בתום השיעור הסטודנט מבין את תפקיד כל גורם בפרויקט, ואת הסיבה שבדיקה מלאה אינה אפשרית.
השיעור הבא בקורס: מחזור חיים של תוכנה

פרקי ההרצאה: מבוא ל-QA ולבדיקות - חלק 2

  1. 00:00

    האנשים בפרויקט ותפקיד מנהל הפרויקט

  2. 01:27

    מה המתכנתים מספקים לבודקים

  3. 02:58

    שינויי קוד, לוחות זמנים וסטטוס באגים

  4. 03:54

    מה המתכנתים צריכים מאנשי הבדיקות

  5. 04:32

    הבודקים האחרים: באגים ידועים וכלים

  6. 05:30

    הלקוח ומבט הפרויקט מהצד שלו

  7. 06:08

    סיבוכיות הבדיקות: שדה בן שישה תווים

  8. 09:14

    מתי מפסיקים לבדוק: לוחות זמנים

תמלול ההרצאה: מבוא ל-QA ולבדיקות - חלק 2

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

  1. 00:07

    אנחנו מדברים על מבוא ל-QA ובדיקות תוכנה. Software Project Personals מי האנשים שמולם אתם הולכים לעבוד בפרויקט הפיתוח? Project Management הנהלת הפרויקט will help you understand the target of the project, will give you schedules, need from you the quality/status of the project.

  2. 00:39

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

  3. 00:55

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

  4. 01:19

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

  5. 01:39

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

  6. 02:05

    It will help you to understand how the components work on the inside. המתכנתים יכולים להסביר לכם איך הקומפוננטות בנויות בפנים, איך הן כתובות, למה הם כתבו את זה בצורה שהם כתבו את זה.

  7. 02:19

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

  8. 02:33

    We help you to know about joint points of the product. הם יכולים להגיד לכם איפה הנקודות שבהן יש התממשקות עם מתכנתים אחרים. איפה נקודות האינטגרציה בין המתכנתים כי הרבה פעמים באגים נמצאים בנקודות האלה.

  9. 02:49

    הנקודות שבו לוקחים חלק שמתכנת א' כתב חלק שמתכנת ב' כתב ועכשיו מנסים לאחד את זה ביחד. We help you to know about code changes. הם אלה שעושים את השינויי הקוד אז הם יוכלו תמיד לבוא ולהגיד לכם עשינו ככה וככה בקוד אתם יכולים לבדוק את זה תתייעצו איתם האם מסיר או תשאלו אותם האם הם עשו איזה שהם שינויים בקוד לקראת הגרסה החדשה we let you know the schedule of

  10. 03:18

    coding הם אלה שיכולים לבוא ולהגיד לכם כמה זמן ייקח להם לכתוב מודול ספציפי שלפיו תוכלו לתכנן את לוחות הזמנים שבו אתם תצטרכו לכתוב את הבדיקות למודול אבל תדעו מתי אתם יכולים להתחיל באמת לבדוק אותו We let you know the status of bugs.

  11. 03:37

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

  12. 03:47

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

  13. 04:03

    מה המתכנתים צריכים מאיתנו, מאנשי הבדיקות? need for mute information about problems הם צריכים להבין איפה הבעיה נמצאת. לא באיזה שורה, אלא איפה. איך לשחזר אותה.

  14. 04:17

    למה אתם באמת חושבים שזאת בעיה? need for mute what will be tested and when הם צריכים לדעת מה אתם הולכים לבדוק ומתי ולפעמים גם איך כי אולי המתכנת יוכל לעשות בדיוק את מה שאתם חושבים לעשות קודם כל אצלו ולראות שזה בכלל עובר את הבדיקות ואז הוא יחסוך שלב כי בזמן הכתיבה הוא כבר יגלה באגים.

  15. 04:41

    והחוליה השלישית שקיימת בפרויקט היא טסטרס בודקים will help you understand product functionality אתם תוכלו להתייעץ עם בודקים אחרים שמכירים זווית אחרת של המערכת לגבי אותה זווית will tell you about known bugs הרבה פעמים יוכלו לספר לכם על באגים שכבר קיימים שיכול להיות שאין טעם שתדווחו אותם יכול להיות שתדעו כבר להבין שהם קיימים will tell you about tools

  16. 05:12

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

  17. 05:40

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

  18. 06:05

    The Complexity of Testing הסיבוכיות בטסינג למה בדיקות זה דבר כל כך מסובך למה בדיקות לוקחות זמן למה אי אפשר בכלל לבדוק את הכל. אז נניח שיש לכם במסך מסוים שדה אחד לוגי name אוקיי והשדה הזה can It contains six characters alpha-numeric only.

  19. 06:32

    כלומר, השדה הזה יכול להכיל שש מקומות לשישה תווים שיכולים להיות או אותיות או מספרים או שילוב שלהם. Field is case-sensitive. השדה הזה הוא רגיש לאותיות גדולות או קטנות באנגלית, ונניח אפשר להכניס פה רק אותיות אנגליות.

  20. 06:55

    Question How many tests you can make? כמה בדיקות אתם יכולים לעשות על שדה כזה? את הזמן תחשבו כמה שניות תעשו אפילו pause למצגת תחשבו על זה תרשמו לעצמכם את הבדיקות שאפשר לעשות לזה ואז תמשיכו.

  21. 07:18

    נעבור לתשובה יש לנו 26 אפשרויות כדי לבחור אות אנגלית קטנה יש לנו 26 אפשרויות לבחור אות אנגלית גדולה יש לנו 10 ספרות מ-0 עד 9 יש לנו 6 מקומות בשדה שבהם אני יכול להכניס או 26 אותיות קטנות או 26 אותיות גדולות או 10 ספרות, זאת אומרת שיש לי בסך הכל 62 אפשרויות לכל מקום בשדה הזה. למה? כי זה 26 ועוד 26 ועוד 10. מכאן שמספר האפשרויות לבדוק את השדה

  22. 08:07

    הזה הוא 62 מחזקת 6. כי למקום הראשון יש לי 62 אפשרויות ולמקום השני יש לי 62 אפשרויות ולמקום השלישי 62 אפשרויות וכך הלאה עד המקום השישי.

  23. 08:19

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

  24. 08:51

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

  25. 09:14

    When we stop to test אנחנו מפסיקים לבדוק אנחנו מפסיקים לבדוק כאשר יש לנו badlining זאת אומרת נקודות לוחות זמנים שבהם אומרים לנו עד התאריך הזה והזה המערכת צריכה להיות בדוקה מה שבדקתם בדקתם ומה שלא לא.

  26. 09:32

    This case is completed with certain percentage past. עשינו, כתבנו מסמכי בדיקות, כתבנו תהליכי, תסריטי בדיקות, ובארצות אנחנו רואים ש-80%,

לקורס המלא: קורס בדיקות ידניות אונליין

ההרצאה הקודמת: מבוא ל-QA ולבדיקות - חלק 1

ההרצאה הבאה: מחזור חיים של תוכנה

קורסים נוספים במסלול

  • קורס בדיקות ידניות - QA
  • קורס הכנה למבחן ההסמכה ISTQB