The W Model
פרקי ההרצאה: The W Model
תמלול ההרצאה: The W Model
הטקסט המלא של הדקות הראשונות בהרצאה «The W Model» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
מודל ה-W הוא שיפור ושדרוג בצורה מאוד מאוד מהותית של מודל ה-V, והוא למעשה פותר כמעט את כל הבעיות גם של מודל ה-V וגם של מודל המפל.
רצון אובג'קטיבס, רצון השיעור, אינטרודקשן, אנחנו נעשה איזושהי הקדמה קטנה למודל ה-W, מה זה מודל ה-W, נדבר מה זה מודל ה-W, מודל ה-W נראה את המודל עצמו, גם את המודל הגרפי וגם ניכנס לכל שלב ושלב במודל.
Advantages and Disadvantages of the Model. נדבר על היתרונות ועל החסונות של המודל. Introduction. The W-Model is an enhancement of the V-Model.
Implemented in many companies. אז מודל ה-W הוא איפור מאוד מאוד רציני של מודל ה-V, והוא יחסית אחד המודלים היותר חדשים שיש. הוא פותח בסביבות באמצע שנות התשעים והוא משמש, הוא ממומש היום בהרבה הרבה חברות וארגונים.
פחות הארגונים שעובדים עדיין עם מודל המפל כמו תעשייה האווירית, נאסא וכדומה, אלא עם ארגונים שיותר קל או הם ארגונים מספיק פתוחים לקבל שינויים בשיטות עבודה.
What is the W model? מהו מודל ה-W? W הוא Model Focus on the Development Product. מודל ה-W מתמקד בתוצרים של הפיתוח, כלומר הוא מתמקד בתוצרים עצמם, לא רק בתהליך ולא רק בקשר בין התהליך אלא בתוצר עצמו.
לכל תהליך, לכל שלב יש כאילו איזשהו תוצר וההתמקדות היא בו. Every development product is a test activity that need to determine whether the development activity met the requirements and work well.
לכל שלב יש איזשהו תוצר. ובמודל ה-W כל תוצר כזה נבדק מה שאומר שלמעשה כל השלבים שראינו קודם במודלים האחרים שהם לא נבדקים לעומק מודל ה-W נותן על זה מענה מודל ה-W בא ואומר כל תוצר סופי כל מסמך סופי צריך לבדוק אותו צריך לעשות לו סטטיק טסטינג בדיקות סטטיות בנוסף לבדיקות האקטיביות שעושים ובנוסף לשאר התהליכי הבדיקות שמבצעים לדעת ה-W מודל
אז הנה האיור הגרפי של מודל ה-W, יש לנו את שלב הדרישות, כשאנחנו מסיימים אותו אנחנו מתחילים לעשות איזשהו פעילויות של טסטינג, גם עליו וגם משתמשים בו לכתיבת תסריטי בדיקות עתידיים, ממנו אנחנו עוברים לשלב הספציפיקציות, ושני השלבים האלה, שני התוצרים האלה משמשים אותנו לפלנינג של ה-System Test,
ממנו, משלב הספציפיקציות עוברים לדיזיין, ולמעשה שני השלבים האלה שזה כולל גם את זה משמשים אותנו לתכנון של הפלנינג אינטגרשן טסט ממנו אנחנו עוברים לדיטל דיזיין דיזיין קצת יותר מעמיק ושני השלבים האלה משמשים אותנו לתכנון של היוניט טסט ואז אנחנו עוברים לשלב הקודינג שימו לב שפה מתכננים את היוניט טסט זה שמתחיל לכתוב את
הקוד אחר כך אנחנו מבצעים את היוניט טסט עצמו ובתוך הביצוע של הוניטסט יש איזשהו תהליך מעגלי של לבדוק, מוצאים תקלות, מדבגים אותן, עושים את השינויים המתאימים ומבצעים בדיקות מחדש.
אחרי שכל הוניטסט עברו, אנחנו עוברים לשלב ה-Integration Test, ממשים, כלומר כתבנו פה את ה-Integration Test, פה אנחנו ממש מבצעים, מוצאים לפועל את ה-Integration Test, ושוב אותו תהליך של תיקונים, דיבאגינג, שינויים, בדיקות מחדש וכדומה.
אחר כך הולכים לסיסטם טסט, מבצעים את הסיסטם טסט שכבר נכתבו ותוכננו פה מיד בסוף שלב הספציפיקציות, וגם פה אותו תהליך מעגלי של מציאת תקלות, דיבאגינג, שינויים, בדיקה מחדש, ובסוף עוברים לתהליך ה-ATP, למימוש תהליך ה-ATP.
זה W-Model. For each activity on the left, there is a static test, inspection review and early test case preparation.
זאת אומרת, שימו לב, בכל קלף קצת שמאל יש שלב מקביל לו בצלע שלידו והשלב הזה הזרוע הזאת פה שהיא צמודה לזרוע השמאלית ביותר של שלב הכתיב הפעילויות היא גם שלב הבדיקות הסטטיות של הבדיקה של ה-requirements בדיקות של הספציפיקציות בדיקות של הדיזיין, בדיקות של הדיזיין המעמיק וגם שלב שבו משתמכים על התוצרים האלה לכתיבה ולתכנון
של אותן בדיקות שצריך לעשות אחר כך, לתכנן את ה-ATP, לתכנן את ה-System Test, לתכנן את ה-Integration Test, לתכנן את ה-Unit Test.
The right side contains Dynamic Tests, אז כל הצד הימני הוא למעשה כל הבדיקות הדינמיות. בדיקות דינמיות זה כשמבצעים על קוד שמריצים אותו.
בדיקות הסטטיות זה בדיקות שמריצים על התוכנה בלי להריץ אותה, ובדיקות על המסמכים וריוויו על המסמכים וכדומה. והמודל הזה נקרא מודל W כי אם תדמיינו זה נראה כאילו היה כתוב פה W step by step.
נעבור עכשיו צעד צעד בכל שלב. Requirements phase - All possible requirements of the system to be developed are captured in this phase. Requirements are set of functionalities and constraints that the end user expects from the system.
These requirements are analyzed for their validity. אוקיי, אז בשלב הזה אנחנו אוספים את הדרישות מהלקוח, ולמעשה הדרישות הן איזשהו אוסף של פונקציונליות ואיסורים ומותרות שהמערכת אמורה לעשות, כאשר מי שמביא לנו אותם זה הלקוח.
הלקוח אומר לנו מה הוא רוצה שהמערכת תעשה, מה הוא רוצה שהמערכת לא תעשה, מה הוא רוצה שהמערכת תתנהג כאשר קורה א' וכאשר קורה ב'.
את הדרישות אנחנו באמת מוודאים שהן נכתבו ברורות, הן כתובות כמו שצריך וכדומה. Usually the project manager's system analysis is the main responsibility for the output of the phase, בדרך כלל מנהל הפרויקט או מנתח המערכת הוא זה שאחראי לאסוף את הדרישות מהלקוח ולהוציא את התוצר שלו,
שהתוצר שלו הוא מסמך דרישות. The output will be a requirement document. Testers use this document for system and ATP acceptance tests. אנחנו כאנשי בדיקות משתמשים במסמך הזה גם לבדיקות מערכת, גם בעקיפין לבדיקות אינטגרציה.
המסמך הזה משמש אותנו לתכנון ולאפיון ולכתיבה של אותן בדיקות והלקוח משתמש במסמך הזה למעשה לביצוע ולתכנון ה-ATP שלו, בדיקות הקבלה שהוא הולך לעשות, שבהם הוא הולך לבדוק האם הדרישות שהוא ביקש אכן מתקיימות ואם הן מתקיימות אם הן מתקיימות טוב מספיק.
ב-Analysis this document the tester can plan and write test cases that will cover each requirement. אז שוב על ידי ניתוח המסמך הזה אנחנו יכולים לכתוב בדיקות שיבדקו האם כל דרישה מחוסה.
Programmers usually don't use this document for their work, or so it can help them to see the big picture. אז שוב, השאיפה צריכה להיות שגם המתכנתים יעברו על המסמך הזה ויכירו אותו.
זה ייתן להם אפשרות לבנות את המבנה הכללי יותר של התוכנה, את התמונה הגדולה יותר של התוכנה. הם לא רק יסתכלו רק על הקטע קוד שהם כותבים, הם גם יבינו איך זה משתלב בתוכנה הגדולה.
השלב הבא, Start of the Test Activities Phase, שלב שפה מתחילים את פעילויות הטסטינג. אז השלב הזה זה Review of the Requirements. אנחנו בודקים, עוברים על ה-Requirements.
Planning and Preparing Acceptance Tests. מתכננים ומכינים את בדיקות הקבלה, את ה-ATP. Fixing of Tests, Strategy and Test Concept. אנחנו בונים למעשה את כל אסטרטגיות הבדיקות שלנו, ואנחנו מחליטים מה יהיו ה-Concepts לבדיקות שלנו.
בין השאר זה כולל לעשות Risk Analysis, ניתוח סיכונים לפרויקט. ריסק אנליסיס ניתוח סיכונים על הדרישות שזה משהו שאנחנו נראה ריסק בי בשביל ריסק בייסט טסטינג למשל.
דיטרמנט קריטיקליטי אנחנו מחליטים מהם הדרישות הקריטיות מהם הדרישות הלא קריטיות הפחות קריטיות כדי לתכנן את לוחות הזמנים שלנו.
בדרך כלל זה מתבסס על תוצאות הריסק אנליסיס. פנס אוף טסטינג אנחנו באים ומגדירים מה תהיה העלות עכשיו אנחנו יכולים לבוא ולקבוע כמה זמן ייקח לנו לעשות את הבדיקות האלה. מה אנחנו צריכים בשביל לבדוק?
כמה אנשים? טסט אינטנסיטי, אנחנו מגדירים את האומץ של הבדיקות, אנחנו מגדיר את השלבי בדיקות למעשה, כדומה.
המשך של שלב ההכנות לבדיקות, Draw up the test plan, אנחנו מתכננים ככה באיזשהו מבט על את ה-STP, או למעשה אפילו אפשר די במבט מעמיק לכתוב כבר את ה-STP, את ה-software test plan, Organize the tests, אנחנו מאכינים את הצוות בדיקות, עושים לו הדרכה אם צריך, מלמדים אותו על הכלים,
מסבירים לו על המערכת, נותנים לו לקרוא את הדרישות. Training of the testing if necessary. Establish monitoring and reporting. אנחנו מגדירים איך ננטר את העבודה, איך נדווח על באגים, מה מגדירים, מה החומרה של כל באג, מה היא אומרת וכדומה.
Provide required hardware resource pieces, דאטאבייס, אנחנו נגדיר מה החומרה שאנחנו צריכים לצוות הבדיקות, כמה מחשבים, כן מדפסת צבעונית, לא מדפסת צבעונית, כן שוויוטקנט דאטאבייס בשביל שאילתות, לא שוויוטקנט דאטאבייס וכדומה.
Provide Required Software Resource, Software Version Test Tools, אנחנו מגדירים מה התוכנות שאנחנו צריכים, אולי צריכים לעבוד עם QTP, כלים אוטומטיים, עם טסט דירקטור, רק עם אקסל ווורד וכדומה.
המשך של תהליך ההכנות לבדיקות.