
הטקסט המלא של הדקות הראשונות בהרצאה «איך נראת עבודה אמיתית» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
אנחנו נלמד איך נראה תהליך עבודה של בודק תוכנה. נכנסים לאתר של מרקיורי, אתם פשוט נכנסים לאזור של הדאונלוד, זה נמצא פה בצד ימין למעלה, יש לכם שיעור, יש לכם אתכם להוריד את התוכנה של המרקיורי ל-14 יום בחינם.
גרסת ניסיון, הגרסה הזאת זה כלי לניהול בדיקות של הטסט דירקטור. אחרי שתורידו את התוכנה, ככה היא נראית, יש פה בצד שמאל requirements, test plan, test labs ו-defect.
כלי לתיעוד ודיווח של בדיקות אתם עובדים איתו אני לא אכנס עכשיו לעומק שלו מה שאני רוצה שתבינו כרגע הוא נמצא ב-Test Land יש פה דבר שנקרא Design Steps לכל רכיב בתוכנה שאני רוצה להוסיף לו איזה צעד איזה סטפ אני מתאר מה אני רוצה שירואה יש פה Description ויש פה Expected Result אנחנו לא ניכנס לזה אבל אני מדבר על זה כדי שנבין את השקף הבא איך נראה תהליך עבודה של בודק תוכנה המסמך אפיון
זה מה שאתם מקבלים כרגע המסמך אפיון זה מה שאתם מקבלים מאלה שמנהלי הפיתוח הדבר הזה בעצם, המסמך אפיון, זה נקרא functional design, זה ספר עב כרס עם הרבה תמונות ומסכים שמסביר איך התוכנה הזאת עובדת.
אתם צריכים להבין מהם התהליכים העסקיים, כלומר ה-requirements, מהם הדרישות ברמת התוכנה שצריך לעשות את זה. כלומר נניח אם המערכת האקדמיה שלנו צריך לנגן הרצאה או להוריד הרצאה או אפילו לעשות לא גין למערכת, זה סוג של Requirement, זה תהליך עסקי, לא הוגן למערכת, זה תהליך של Requirement, אתם צריכים לכתוב בתוכנה
של המרקיורי את העובדה הזאת של ה-Design Steps, את התיאור שלה, וככה אתם כאילו מתקדמים. עכשיו, לאחר מכן יש כתיבה של מסמך וורד שנקרא SDP כתיבת מסמך זה נקרא Software Test Plan, נותן תיאור כללי ושמות של הבדיקות של מה שאנחנו הולכים לעשות.
בשקף הבא אני אסביר לכם איך להוריד אותו מהאינטרנט, לעבוד איך להבין מה זה לאחר מכן יש כתיבת מסמך בדיקה שנקרא std software test design שהוא נעשה בתוך ה quality center quality center זה הכלי של mercury שנקרא test director בעצם אותו דבר ה test plan נמצא פה זה ה test plan זה השלב הבא לאחר שאתם עובדים על ה requirement אתם נכנסים ל test plan ושם אתם מבצעים את
ה std הזה לאחר שביצענו את כתיבת המסמך בדיקה של ה std כלומר כל הסטפים תוארו בשלב של ה-Design Step שנמצא פה, תיארנו מהו השם של ה-Step, כלומר נניח לוגין, אז פה נכתוב לוגין, מהו ה-Description, מהו התיאור של הלוגין הזה, ומה אנחנו רוצים שהוא
יעשה, Expected Result, זה Step. אני רוצה להתקדם למסמך, לכתוב שהוא אמור לקחת נתונים של תעודת זהות של לקוח, זה תיאור השם. תיאור השם נניח זה איסוף נתונים, דסקריפשן זה מה הוא אמור לעשות, מה אני צריך ללחוץ כדי שיקרה, איסוף התעודת זהות ואקספקטד
ריזולט שהתעודת זהות הוכנס למסד נתונים של המערכת ככה על קצה המזלג אני חוזר לפה, עכשיו השלב של הבדיקות הידניות הכלי הזה של מרקרו וקואליטי סנטר זה כלי לניהול בדיקות הבדיקות נעשות בשלב הזה שלב הארצות כל תרחישי הבדיקה כל התהליכים העסקיים
תרחישי הבדיקה לתהליכים עסקיים כל סטפ כל איסוף נתון של תעודת זהות נבדק ידנית באזור הזה של ה-Test Labs וה-Defects.
מה זאת אומרת, אחרי זה חוזרים למסך, בודקים ידנית, נותנים דיווח על הסטטוס של הבאג, אם הוא עבר, אם זה הצליח, אם האזנתי תעודת זהות וזה הצליח, או נכשל, failed, test or failed.
עכשיו, כל פעם שיש איזה באג, אני שולח אותו מהכלי, מה-Quality Center, המפתח מקבל אימייל שהבאג הזה לא תקין ואז הסטטוס שלו משתנה, אצל המפתח, המפתח מחזיר את זה ומשנה את זה לפיקס.
לאחר מכן בדרך כלל ראש הצוות, ולא הבודק תוכנה, מבצע מכתיבת מסמך סיכום שנקרא SDR, Software Test Report, אשר מבצע סיכום מה נבדק ומה לא נבדק.
לאחר מכן נעשית רגרסיה, כלומר זה הרצאה של כל הבדיקות, אם הוספנו מודול חדש למערכת, כלומר מין עוד איזה תת רכיב למערכת, אז איך כל המערכת הזאת עובדת עכשיו ביחד?
או אם ביצענו את כל הבאגים,