דף הכנה מלא למבחן באבטחת איכות (1) PDF

‫סיכום למבחן באבטחת איכות‬ ‫שלושה דברים עיקריים שחשובים באבטחת איכות‪:‬‬ ‫‪.1‬יחסי אנוש‬ ‫‪.2‬עמידה בזמנים‬...

‫סיכום למבחן באבטחת איכות‬ ‫שלושה דברים עיקריים שחשובים באבטחת איכות‪:‬‬ ‫‪.1‬יחסי אנוש‬ ‫‪.2‬עמידה בזמנים‬ ‫‪.3‬חשיבה יצירתית‬ ‫מה זה ‪ ALM‬ושרשור התהליך שלו‪:‬‬ ‫‪ Application lifecycle management -ALM‬תהליך מחזור החיים המלא של יישום תוכנה‪ ,‬החל‬ ‫מתכנון ופיתוח‪ ,‬דרך בדיקות ופריסה‪ ,‬ועד לתחזוקה והוצאה משימוש‪.‬‬ ‫שרשור התהליך של ‪:ALM‬‬ ‫יש יזם בעל הרעיון ולקוח שיש לו בעיה עם הרעיון הולכים לאנליסט שיקבע אפיון‪ ,‬יש את המתכנת‬ ‫שהוא זה שמפתח את הקוד ואנשי הבדיקות שעושים את הבדיקות לאחר מכן יש את מטמיע‬ ‫המערכת שמסביר על המוצר ומטמיע אותו ואנשי שירות הלקוחות ואנשי ניהול הצלחת לקוח‪.‬‬ ‫האנשים הכי חשובים בתהליך הם ה‪ customer support-‬מכיוון שהם מקבלים מהלקוח פידבקים‬ ‫ובעיות על המוצר והם אלו שמתרגמים את זה לפתרונות‪ ,‬שיפורים וכ'ו‪.‬‬ ‫סוגי בדיקות‪:‬‬ ‫‪.1‬בדיקת ‪ -GUI‬בדיקה ויזואלית של איך הממשק נראה מבלי להתעסק בו יותר מידי‪ ,‬לדוגמא גודל‬ ‫פונט‪ ,‬צבעים מסוימים באתר וכו'‪.‬‬ ‫‪ -UX/UI.2‬בדיקת חווית משתמש לדוגמא האם ההוראות ברורות?‪.‬‬ ‫‪( Accessibility.3‬בדיקת נגישות)‪ -‬בדיקה שהמוצר עונה על הצרכים של כל בעלי המוגבלויות בין אם‬ ‫באתר אינטרנט או באפליקציה‪ ,‬בדיקה שנעגנת בחוק ויכולים להיענש אם לא מקיימים צורך מסוים‬ ‫במוצר שפוגע בזכויות של אותם אנשים בעלי צרכים‪.‬‬  ‫‪( Functionality.4‬בדיקת פונקציונליות)‪ -‬תהליך הבודק האם התוכנה או היישום פועלים בהתאם‬ ‫לדרישות המוגדרות‪ ,‬תוך התמקדות בפונקציות ובתכונות המערכת‪.‬‬ ‫‪( Survival and recovery.5‬בדיקת שרידות והתאוששות) ‪ -‬בדיקת מערך הגיבויים והשחזור‪ ,‬מנגנון‬ ‫ההתאוששות מכשל ושיבה לפעילות‪.‬‬ ‫‪ -Boundary Values.6‬בדיקת ניתוח ערכי קצה‪ ,‬טכניקה לבדיקת ערכי קצה וגבולות של קבוצות‬ ‫שקילות‪.‬‬ ‫‪ –C.R.U.D.7‬בדיקת ארבעת הפעולות הבסיסיות שניתן לבצע על נתונים במערכות מידע‪:‬‬ ‫‪ – Create‬יצירה‪.‬‬ ‫‪ – Read‬קריאה‪.‬‬ ‫‪ – Update‬עדכון מידע קיים‪.‬‬ ‫‪ – Delete‬מחיקת מידע קיים‪.‬‬ ‫‪( Security.8‬בדיקת אבטחה)‪ -‬בדיקות אבטחה‪ ,‬בדיקת המערכת לאיתור כשלים בהגנה על‬ ‫המערכת‪.‬‬ ‫‪( Maintainability.9‬בדיקת תחזוקה)‪ -‬תהליך המעריך את היכולת של המערכת לעבור שינויים‪,‬‬ ‫תיקונים או שדרוגים בצורה קלה ויעילה‪.‬‬ ‫‪( Compatibility.10‬בדיקת תאימות) ‪ -‬תהליך הבודק את היכולת של התוכנה לפעול בסביבות שונות‪,‬‬ ‫כגון מערכות הפעלה‪ ,‬דפדפנים‪ ,‬חומרה או גרסאות שונות‪ ,‬ולהבטיח שהיא מתפקדת כראוי בכל אחת‬ ‫מהן‪.‬‬ ‫‪( integration.11‬בדיקת אינטגרציה)‪ -‬התהליך של שילוב רכיבים או מערכות נפרדות למערכת אחת‬ ‫מתפקדת‪.‬‬ ‫‪( Interface.12‬בדיקת ממשק)‪ -‬נקודת המפגש או התקשורת בין שני רכיבים או מערכות‪ ,‬המאפשרת‬ ‫להם לעבוד יחד‪.‬‬ ‫‪( Performance.13‬בדיקת ביצועים)‪ -‬בדיקת תפקוד המערכת במצבי פעילות מלאה ולאורך זמן‪.‬‬ ‫‪( Load.14‬בדיקת עומס) ‪ -‬בדיקות המיועדות להעריך את ביצועי המערכת תחת עומסים שונים‪ ,‬על‬ ‫ידי סימולציה של מספר משתמשים או תהליכים במקביל‪ ,‬במטרה לזהות צווארי בקבוק ולוודא‬ ‫שהמערכת עומדת בדרישות הביצועים‪.‬‬ ‫‪( Stress.15‬בדיקת לחץ)‪ -‬בדיקה למציאת נקודת השבירה של המערכת בעומס גבוה‪.‬‬ ‫‪( Internationalization.16‬בדיקת בינלאומיות)‪ -‬התאמת התוכנה לשפות שונות‪.‬‬  ‫סוגי מערכות‪:‬‬ ‫‪.1‬מערכות מידע‪:‬‬ ‫המוטיב המרכזי שלהן זה המידע שהמערכת אוחזת בה‪ ,‬זה אומר שאנשים ניגשים למערכות אלה כדי‬ ‫לשלוף מידע‪ ,‬לעדכן מידע וליצור מידע‪.‬דוגמא למערכת מסוג זה‪ :‬מערכת המידע של משרד התחבורה‬ ‫שהיא מתחלקת לשניים מערכת שמכילה בתוכה את הנהגים ומערכת שמכילה בתוכה את המידע עבור‬ ‫הרכבים‪.‬‬ ‫שני הדברים הכי חשובים לבדיקה במערכת מסוג מערכת מידע הינם‪:‬‬ ‫א‪( SECURITY.‬אבטחה)‬ ‫ב‪LOAD.‬‬ ‫בדיקות עיקריות נדרשות ‪:‬‬ ‫‪‬‬ ‫‪-Security‬בדיקות אבטחת מידע והרשאות‬ ‫‪o‬‬ ‫‪-Load‬בדיקות עומס למספר משתמשים במקביל‬ ‫‪o‬‬ ‫‪-Compatibility‬תאימות לדפדפנים ומערכות הפעלה שונות‬ ‫‪o‬‬ ‫‪ - Survival and Recovery‬יכולת התאוששות מקריסות ושמירת מידע‬ ‫‪o‬‬ ‫‪ - Usability‬שימושיות וידידותיות למשתמש‬ ‫‪o‬‬ ‫‪ - Performance‬ביצועים ומהירות תגובה‪.‬‬ ‫‪o‬‬ ‫‪.2‬מערכות זמן אמת ומערכות אונליין‪:‬‬ ‫מערכות הפועלות בזמן אמת ומחייבות תגובה מיידית‬ ‫‪‬‬ ‫בדיקות עיקריות נדרשות ‪:‬‬ ‫‪‬‬ ‫‪-Performance‬ביצועים ומהירות תגובה קריטית‬ ‫‪o‬‬ ‫‪-Survival and Recovery‬התאוששות מהירה מתקלות‬ ‫‪o‬‬ ‫‪-Interfaces‬בדיקת ממשקים עם מערכות חיצוניות‬ ‫‪o‬‬ ‫‪ -Integration‬אינטגרציה עם מערכות אחרות‬ ‫‪o‬‬  ‫‪.3‬תוכנות מדף‪:‬‬ ‫‪.1‬רוב התוכנות סטטיסטית הן תוכנות מדף הן נותנות את אותו המענה לכולם הן לא מיועדות למישהו‬ ‫מסוים כמו אינטרנט‪ EXECL ,‬וכו'‪.‬‬ ‫בתוכנות מדף נבדוק בעיקר‪:‬‬ ‫א‪( COMPABILITY.‬תאימות)‬ ‫ב‪USABILITY.‬‬ ‫בדיקות נדרשות ‪:‬‬ ‫‪‬‬ ‫‪-Compatibility‬תאימות למגוון פלטפורמות וסביבות‬ ‫‪o‬‬ ‫‪ -Performance‬ביצועים בתנאים שונים‬ ‫‪o‬‬ ‫‪ -Survival and Recovery‬יכולת התאוששות והתמודדות עם תקלות‬ ‫‪o‬‬ ‫‪ -Usability‬ממשק משתמש אינטואיטיבי‬ ‫‪o‬‬ ‫‪.4‬תוכנות מודולריות‪:‬‬ ‫‪.2‬תוכנות שיש בהן אינטגרציה מודלים שונים שבעצם מדברים זה עם זה לדוגמא‪,SAP ,ERP :‬‬ ‫פריורטי‪ CRM ,‬וכו'‪.‬‬ ‫נבדוק בעיקר‪:‬‬ ‫א‪INTRGRATION.‬‬ ‫ב‪UNIT TESTING.‬‬ ‫בדיקות עיקריות נדרשות ‪:‬‬ ‫‪‬‬ ‫‪ -Performance‬ביצועי המודולים השונים‬ ‫‪o‬‬ ‫‪ -Usability‬ממשק משתמש אינטואיטיבי‬ ‫‪o‬‬ ‫‪ -Load‬עומס בעבודה עם מודולים מרובים‬ ‫‪o‬‬ ‫‪ -Survival and Recovery‬התאוששות ברמת המודול והמערכת‬ ‫‪o‬‬ ‫‪ -Security‬אבטחה בין המודולים השונים‬ ‫‪o‬‬ ‫‪ -Compatibility‬תאימות בין המודולים‬ ‫‪o‬‬  ‫‪-Test case‬מרכיבים עיקריים‪:‬‬ ‫‪-Test case‬תרחיש בדיקה‪ ,‬אוסף של תנאים ומשתנים שלפיהם בודק תוכנה קובע האם האפליקציה‪,‬‬ ‫יישום‪ ,‬אתר או תוכנה פועלים בצורה נכונה בנקודה מסוימת‪.‬‬ ‫מה קורה כשנגמר הזמן לבדיקות? הגדרנו דירוג לכל בדיקה‪ ,‬בהינתן מצב של שינויים בתקציב‪,‬‬ ‫בפרויקט וכו' נקיים שיחה עם מנהל הפרויקט והלקוח ביחד ונקבל החלטה איזה רמת דירוג אנחנו‬ ‫רוצים לבדוק‪.‬‬ ‫מה כן לא נפספס בבדיקות בשום אופן? ‪ ,GUI‬פונקציונליות ואבטחה‪.‬‬ ‫שלבי בדיקת ‪:Test case‬‬ ‫‪ -Test case ID.‬מספר זיהוי של הבדיקה‬ ‫‪.2‬כותרת‪-Title-‬שם בדיקה‬ ‫‪( precondition.3‬תנאים מקדימים)‪ -‬מצבים או דרישות שיש למלא לפני ביצוע הבדיקה‪.‬‬ ‫‪.4‬מי כתב את ה‪TEST-‬‬ ‫‪.5‬באיזה תאריך זה נכתב‬ ‫‪.6‬סטטוס של ה‪ -test case -‬עבר או נכשל בהתבסס על ההשוואה בין תוצאה צפויה לתוצאה בפועל‪.‬‬ ‫‪ priority.7‬של ה ‪ -test case-‬מה רמת החשיבות של הבדיקה הנוכחית‪.‬‬ ‫‪.8‬נבדק על ידי מי? (שם הבודק)‬ ‫‪.9‬תאריך אחרון לסיום הבדיקה‬ ‫‪.10‬איזה סוג בדיקה זו?‪ -‬פונקציונליות‪ ,‬שפיות‪ GUI ,‬וכ'ו‪.‬‬ ‫‪.11‬איזה פלטפורמה? מובייל‪ WEB ,‬וכ'ו‬ ‫‪.12‬סביבת בדיקה‪-‬פירוט סביבת העבודה שבה התבצעה הבדיקה‬ ‫‪.13‬לאיזה קטגוריה שייכת הבדיקה‬ ‫‪.14‬גרסת בדיקה‬ ‫‪.15‬מ'ס צעדים בבדיקה‬ :‫בחלק התחתון יש את הפרוצדורה‬ Step number Description Expected result :‫בחלק של הבודק‬ Actual result Pass/Failed Attachments Related Bug Id comments :‫איך זה נראה ויזואלית‬  ‫‪( STP‬מסמך תכנון בדיקות)‪ -‬מסמך המפרט את אסטרטגיית הבדיקות‪ ,‬כולל מה ייבדק‪ ,‬איך‪ ,‬מתי‬ ‫ועל ידי מי‪.‬‬ ‫כיצד נפעל כאשר לא קיים מסמך אפיון או שהוא לא עדכני? נכנס למערכת וניצור מסמך בדיקות –‬ ‫בדרך כלל נאתר אדם שמבין במערכת ומנסים לחקור ולשאול מה הכי נכון לעשות‪.‬‬ ‫כשנגיע לבדוק תוכנה כיצד נבחר את אסטרטגיית הבדיקה? לא קיים סטנדרט קבוע‪ ,‬אך ההחלטה‬ ‫מתבססת על מס' פרמטרים שיש לקחת בחשבון‪:‬‬ ‫איזה מערכת אנחנו בודקים? מערכת מידע‪ ,‬זמן אמת‪ ,‬תוכנת מדף‪?ERP ,‬‬ ‫‪-‬‬ ‫האם המערכת בתחזוקה (‪ )MAINTABILITY‬או מערכת חדשה (בדיקת שפיות)‬ ‫‪-‬‬ ‫מהן נקודות התורפה במערכת? רצוי לזהות את הנקודות הקריטיות של המערכת‬ ‫‪-‬‬ ‫בכדי להתמקד עליהן בתהליך הבדיקה‪.‬‬ ‫מהם הדרישות של מזמין הבדיקות?‬ ‫‪-‬‬ ‫תוכנית העבודה של מחלקת הפיתוח – האם הפיתוח מתבצע בבת אחת או‬ ‫‪-‬‬ ‫בשלבים? אם זה בשלבים נבצע את בדיקת ‪.INTRGRATION‬‬ ‫הקשר של מערכת הנבדקת לשאר המערכות בארגון‪.‬‬ ‫‪-‬‬ ‫רמת הבדיקה שנדרשת מאיתנו כבודקים האם אלו בדיקות קבלה או מסירה?‬ ‫‪-‬‬ ‫מה מצב מעבדת הבדיקות?‬ ‫‪-‬‬ ‫האם נדרשת הכנות מיוחדות?‬ ‫‪-‬‬ ‫האם יש לכם מספיק כ"א‬ ‫‪-‬‬ ‫מספיק זמן?‬ ‫‪-‬‬ ‫מהו הסיכון אם לא נבדוק את כל הרכיבים?‬ ‫‪-‬‬ ‫האם יש צורך בהסבת נתונים?‬ ‫‪-‬‬ ‫מי הם המשתמשים?‬ ‫‪-‬‬ ‫כמה צפויים להשתמש במערכת?‬ ‫‪-‬‬ ‫האם יש סוגי משתמשים רבים?‬ ‫‪-‬‬ ‫האם ניתן לשלב מס' הוראות ביצוע בצעד אחד? יש לברר האם לכל הוראה יש תוצאה צפויה שונה‬ ‫שאותה יש לבדוק‪.‬‬ ‫אם קיימת תוצאה שונה רצוי להפריד ולכתוב כל הוראה בנפרד‪.‬‬ ‫מה עושים כאשר מסמך האפיון אינו שלם והתוכנה עדיין לא קיימת? כשאין בידינו תיאור ברור למסכי‬ ‫המערכת ולשדות במסכים שבה לא ניתן לכתוב מסמך בדיקות ‪ ,GUI‬ניתן לבצע ‪FUNCTIONAL‬‬ ‫‪ TESTS‬ברמה קצת שונה‪.‬‬ ‫האם ניתן לחבר צעדים לפונקציות שונות באותה בדיקה אחת?‬ ‫בבדיקות ממשק משתמש – רצוי לבצע את כל הבדיקות של השדות במסך הנתון‬ ‫‪-‬‬ ‫כצעדים רציפים בבדיקה אחת‪.‬‬ ‫בבדיקות פונקציונליות – שילוב של כמה פונקציות בבדיקה אחת עלול לגרום לבזבוז‬ ‫‪-‬‬ ‫זמן ולעיוות התוצאות‪.‬‬ ‫מהו היחס בין דרישה ל‪ ? test case‬הוא יחס של רבים לרבים‪.‬דרישה אחת יכולה להופיע בהרבה‬ ‫‪ test case‬ו‪ test case‬אחד יכול להכיל הרבה דרישות‪.‬‬  ‫מה אנחנו עושים כאשר יש לנו פער בין תיאור הבדיקה לתוצאה הצפויה? פותחים באג על המקום‪.‬‬ ‫סדר כתיבת באג‬ ‫‪ :BUG ID‬מספר הבאג בשרשור‬ ‫‪‬‬ ‫שם הבאג‬ ‫‪‬‬ ‫חשיבות בדיקה‪:‬‬ ‫‪‬‬ ‫‪:Severity‬‬ ‫‪ -Low‬משהו זניח שלא דורש פתרון מידיי‪ ,‬ויזואלי בעיקרו‪.‬‬ ‫‪ -Medium‬משהו קצת יותר חמור ויזואלית או תכנית שמפריע בביצוע בתוכנה‪.‬‬ ‫‪ -High‬פעולה קריטית שעליה מתבססת התוכנה והיא לא עובדת והחשיבות של התיקון שלה גבוהה‪.‬‬ ‫‪ -Show Stopper‬לולאה אין סופית‪ ,‬או קריסה של התוכנה‪ ,‬משהו שמפריע לתפקוד של התוכנה‬ ‫והחשיבות שלה היא מיידית‪.‬‬ ‫‪( Priority‬תיעדוף תיקון)‪:‬‬ ‫‪‬‬ ‫‪-Low‬חשיבות נמוכה‬ ‫‪-Medium‬חשיבות בינונית‬ ‫‪-High‬חשיבות גבוהה‬ ‫מי מצא את הבג‪.‬‬ ‫‪‬‬ ‫תאריך מציאת הבג‬ ‫‪‬‬ ‫מי עובד על הבאג‬ ‫‪‬‬ ‫באיזה גירסה הבאג נמצא‬ ‫‪‬‬ ‫באיזה סבב בדיקות הבאג נמצא‪.‬‬ ‫‪‬‬ ‫‪ – ETF‬זמן הערכה כדי לפתור את הבעיה (לא נמצא בכל ‪)test case‬‬ ‫‪‬‬ ‫הגדרת הבעיה (מה?‪ ,‬איך?‪ ,‬איפה?)‬ ‫‪‬‬ ‫האם הבאג משתחזר? (האם הוא יכול להופיע ולהעלם ולחזור)‬ ‫‪‬‬ ‫באיזה מודל נמצא הבאג? לדוגמא‪ :‬מכירות או ‪GUI‬‬ ‫‪‬‬ ‫איפה נמצאה הבעיה (באיזה גירסת ווינדוס לדוגמא)‬ ‫‪‬‬ ‫חייב בהוספת תמונה או וידאו כדי להראות את הבאג‬ ‫‪‬‬ ‫כתיבה נוספת שנותנת יותר מידע על הבאג על הבאג או על מציאתו‪.‬‬ ‫‪‬‬ ‫תהליך שלם (החלק המודגש זה מי אחראי על אותו תהליך)‪:‬‬ ‫הסטטוס הכי לא טוב למתכנת הוא ה‪ REOPEN-‬כיוון שהבאג לא נפתר במלואו‪.‬‬  ‫סיכום תהליך מציאת באג‪(Bug Lifecycle):‬‬ ‫‪NEW‬‬ ‫דיווח ראשוני על התקלה‬ ‫‪‬‬ ‫מקורות‪ :‬משתמשים ‪, Help Desk,‬מערכת אוטומטית‬ ‫‪‬‬ ‫משם נעבור לתהליך הבא הרלוונטי‪:‬‬ ‫‪DELAY‬‬ ‫עיכוב בטיפול‬ ‫‪‬‬ ‫סיבות‪ :‬חוסר משאבים‪ ,‬קושי באבחון‬ ‫‪‬‬ ‫‪OPEN‬‬ ‫זיהוי התקלה‬ ‫‪‬‬ ‫הפניה לגורם המקצועי המתאים‬ ‫‪‬‬ ‫‪REJECT‬‬ ‫דחיית הבאג כלא רלוונטי‬ ‫‪‬‬ ‫החלטה של צוות תמיכה‪/‬מנהל מערכות‬ ‫‪‬‬ ‫בתהליך ה‪ Open-‬אלה השלבים הבאים בתהליך‪:‬‬ ‫‪IN PROCESS‬‬ ‫טיפול פעיל בבאג‬ ‫‪‬‬ ‫מעורבים‪ :‬מפתחים‪ ,‬צוות טכני‪, QA‬‬ ‫‪‬‬ ‫לאחר מכן‪:‬‬ ‫‪FIXED.6‬‬ ‫תיקון התקלה‬ ‫‪‬‬ ‫אימות הפתרון ע"י ‪QA‬‬ ‫‪‬‬ ‫‪CLOSED‬‬ ‫סגירה סופית של הבאג‬ ‫‪‬‬ ‫תיעוד הפעולות שבוצעו‬ ‫‪‬‬ ‫או‪:‬‬ ‫‪REOPENED‬‬ ‫חזרת הבאג לטיפול‬ ‫‪‬‬ ‫במקרה של פתרון לא מלא‬ ‫‪‬‬ ‫במידה והסטטוס הוא ‪:FIXED‬‬ ‫‪‬‬  ‫בדיקות מונחות סיכון – שיטה שבוחנת את החלקים במערכת שבהם יש סבירות גבוהה יותר‬ ‫לתקלות או שהשפעתן תהיה משמעותית‪.‬בתהליך זה מזהים תחילה את החלקים הרגישים‪,‬‬ ‫מעריכים את רמת הסיכון שלהם על פי סבירות התקלה ועוצמת ההשפעה‪ ,‬ומתמקדים בבדיקות על‬ ‫החלקים הקריטיים ביותר‪.‬הגישה חוסכת זמן ומשאבים בכך שהיא מתעדפת בדיקות חשובות‬ ‫ומסייעת להבטיח שהמערכת תספק חוויית משתמש אמינה‪ ,‬תוך מניעת תקלות חמורות‪.‬‬ ‫בדיקות מבוססות סיכון –למעשה שם נוסף לבדיקות מונחות סיכון‪ ,‬ומשמעותן זהה‪.‬מדובר בגישה‬ ‫שבה מתמקדים בתכנון וביצוע הבדיקות על סמך זיהוי והערכת הסיכונים במערכת‪.‬המטרה היא‬ ‫לייעל את תהליך הבדיקה על ידי התמקדות בחלקים במערכת שבהם קיים סיכון גבוה יותר לתקלות‬ ‫או שהשפעתן תהיה קריטית‪.‬‬ ‫בדיקות ‪:WEB‬‬ ‫הסוגים העיקריים של בדיקות ‪ Web‬הם‪:‬‬ ‫‪.1‬בדיקות פונקציונליות‪(Functional Testing):‬‬ ‫בודקות שכל הפיצ'רים פועלים כמו שצריך (טפסים‪ ,‬כפתורים‪ ,‬קישורים ועוד)‪.‬‬ ‫‪.2‬בדיקות תאימות‪(Compatibility Testing):‬‬ ‫מוודאות שהאתר עובד בצורה תקינה בכל הדפדפנים ‪ (Chrome, Firefox, Safari‬וכו ‪'),‬‬ ‫מערכות הפעלה ומכשירים (נייד‪ ,‬טאבלט‪ ,‬שולחני)‪.‬‬ ‫‪.3‬בדיקות ביצועים‪(Performance Testing):‬‬ ‫בודקות את מהירות ועמידות האתר תחת עומסים‪ ,‬כמו מספר רב של משתמשים בו‪-‬זמנית‪.‬‬ ‫‪.4‬בדיקות אבטחה‪(Security Testing):‬‬ ‫מאמתות שהאתר מוגן מפני פרצות כמו )‪SQL Injection, Cross-Site Scripting (XSS‬‬ ‫והתקפות אחרות‪.‬‬ ‫‪.5‬בדיקות‪UI/UX (User Interface/Experience Testing):‬‬ ‫בודקות שהעיצוב ברור‪ ,‬אינטואיטיבי ושימושי עבור המשתמשים‪.‬‬ ‫‪.6‬בדיקות רספונסיביות‪(Responsive Testing):‬‬ ‫מוודאות שהאתר נראה ועובד היטב בכל גדלי המסכים (מובייל‪ ,‬טאבלט‪ ,‬מחשב שולחני)‪.‬‬ ‫‪.7‬בדיקות קישורים‪(Link Testing):‬‬ ‫בודקות שכל הקישורים באתר עובדים ואינם מובילים לעמודים שבורים‪(404).‬‬  ‫בדיקות למובייל‬ ‫בדיקות למובייל בודקות שהאפליקציה עובדת בצורה תקינה על טלפונים ניידים‪.‬הסוגים העיקריים‬ ‫הם‪:‬‬ ‫‪.1‬בדיקות פונקציונליות ‪:‬בודקות שכל הכפתורים‪ ,‬הפיצ’רים והתהליכים באפליקציה פועלים‬ ‫בצורה נכונה‪.‬‬ ‫‪.2‬בדיקות תאימות ‪:‬מוודאות שהאפליקציה עובדת טוב על מכשירים שונים‪ ,‬גרסאות מערכת‬ ‫הפעלה ורזולוציות מסך שונות‪.‬‬ ‫‪.3‬בדיקות ביצועים ‪:‬בודקות את מהירות ויציבות האפליקציה בתנאים שונים‪ ,‬כמו עומס‬ ‫משתמשים או רשת איטית‪.‬‬ ‫‪.4‬בדיקות חוויית משתמש ‪ (UI/UX):‬מוודאות שהאפליקציה נוחה לשימוש ומציעה עיצוב טוב‬ ‫וחוויית משתמש חיובית‪.‬‬ ‫‪.5‬בדיקות אבטחה ‪:‬בודקות שהמידע נשמר מאובטח ואין סכנה לפרצות אבטחה‪.‬‬ ‫‪.6‬בדיקות אינטראקציה עם חומרה ‪:‬בודקות את החיבור של האפליקציה עם מצלמה ‪, GPS,‬‬ ‫סוללה וחיישנים אחרים‪.‬‬ ‫שאלות שיכולות להיות במבחן‪:‬‬ ‫‪.1‬מהם הסעיפים המרכזיים במסמך ‪? STP‬‬ ‫מסמך תכנון הבדיקות‪ STP‬כולל את מטרות הבדיקות‪ ,‬טווחי הבדיקות‪ ,‬סוגי הבדיקות‪ ,‬כלים‪ ,‬צוותים‪,‬‬ ‫לוחות זמנים‪ ,‬קריטריונים לכניסה וליציאה‪ ,‬וניהול סיכונים‪.‬‬ ‫‪.2‬מה ההבדל בין ‪ RE-TEST‬ל‪?REGRESSION-‬‬ ‫‪RE-TEST‬בודק אם באג שתוקן נפתר‪ ,‬בעוד ‪ REGRESSION‬בודקת שהשינויים בקוד לא גרמו‬ ‫לבאגים חדשים‪.‬‬ ‫‪.3‬מי הם בעלי התפקידים במחזור חיי מוצר?)‪(ALM‬‬ ‫מנהל פרויקט‪ ,‬מנתח מערכות‪ ,‬מפתחים‪ ,‬בודקי תוכנה‪ ,‬מנהל תצורה ותומכי משתמשים‪.‬‬ ‫‪.4‬מה ההבדל בין בדיקות מסירה לבדיקות קבלה?‬ ‫בדיקות מסירה מבוצעות על ידי צוות הפיתוח‪/‬הבדיקות לפני מסירת המוצר‪ ,‬בעוד בדיקות קבלה‬ ‫מבוצעות על ידי הלקוח או משתמשי הקצה‪.‬‬ ‫‪.5‬מהי רוח הבדיקה השונה בין משתתפי בדיקות?‬ ‫בודקי ‪ QA‬מתמקדים באיתור בעיות‪ ,‬מפתחים מחפשים לוודא שהקוד עובד‪ ,‬והלקוח בודק שהתוצר‬ ‫עונה על צרכיו‪.‬‬  ‫‪.6‬מה החשיבות של תרחישי בדיקות סטנדרטי?‬ ‫תרחיש בדיקה סטנדרטי כולל מספר שדות מרכזיים‪ :‬שם התרחיש שמתאר מה נבדק‪ ,‬תנאי התחלה‬ ‫(‪ )Preconditions‬שמפרטים מה צריך להיות מוכן לפני הבדיקה‪ ,‬שלבים לביצוע (‪ )Steps‬עם‬ ‫הוראות מדויקות‪ ,‬תוצאה צפויה (‪ )Expected Result‬שמתארת מה אמור לקרות‪ ,‬תוצאה בפועל‬ ‫(‪ )Actual Result‬שמתעדת מה קרה בבדיקה בפועל‪ ,‬וסטטוס (‪ )Status‬שמצביע האם הבדיקה‬ ‫עברה‪ ,‬נכשלה או עדיין בבדיקה‪.‬השדות הללו מבטיחים סדר‪ ,‬תיעוד ומעקב ברור‪.‬‬ ‫‪.7‬מה ההבדל בין בדיקות קופסה שחורה לקופסה לבנה?‬ ‫בדיקות קופסה שחורה מתמקדות בפונקציונליות ללא ידע על הקוד צריך לבדוק את כל הסיטואציות‬ ‫האפשריות‪ ,‬בעוד קופסה לבנה בודקת את מבנה הקוד עצמו‪.‬‬ ‫‪.8‬מה ההבדל בין תנאי כניסה ליציאה בבדיקות?‬ ‫תנאי כניסה מגדירים מה נדרש לפני התחלת הבדיקה‪ ,‬ותנאי יציאה מגדירים מתי ניתן לסיים שלב או‬ ‫מחזור בדיקות או מסמך הסיכום‪.‬‬ ‫‪.9‬מה הם ‪ 3‬סוגי העברות נתונים בין מערכות?‬ ‫תשובה‪:‬‬ ‫שלושת סוגי העברות נתונים בין מערכות הם‪:‬‬ ‫‪( As is‬העברת נתונים כמו שהם)‪ -‬העברת נתונים במתכונתם הנוכחית‪ ,‬ללא שינוי או התאמה‪.‬‬ ‫‪( Update‬עדכון כמות או תוכן)‪ -‬עדכון העברת נתונים הכוללת עדכונים או שינויים קלים במבנה או‬ ‫בתוכן הנתונים‪.‬‬ ‫‪( Transformation‬המרת הנתונים מבחינת כמות או אלגוריתם)‪ -‬העברת נתונים הכוללת שינוי‬ ‫משמעותי במבנה‪ ,‬בתוכן או בפורמט הנתונים‪ ,‬כדי להתאים אותם למערכת היעד‪.‬‬ ‫‪.10‬מהו היחס בין דרישה ל‪?test case‬‬ ‫תשובה‪ :‬היחס בין דרישות ל‪ test case‬הוא יחס של רבים לרבים‪.‬דרישה אחת יכולה להופיע בהרבה‬ ‫‪ test case‬ו‪ test case‬אחד יכול להכיל הרבה דרישות‪.‬‬  ‫מושגים חשובים לזכור‪:‬‬ ‫)‪ -ALM (Application Lifecycle Management‬תהליך ניהולי המקיף את כל שלבי מחזור‬ ‫החיים של יישום תוכנה‪ ,‬החל מתכנון ופיתוח‪ ,‬דרך בדיקות ופריסה‪ ,‬ועד לתחזוקה והוצאה משימוש‪.‬‬ ‫)‪-STP (Software Test Plan‬תכנית בדיקות‪ ,‬מסמך המפרט את אסטרטגיית הבדיקות‪ ,‬כולל מה‬ ‫ייבדק‪ ,‬איך‪ ,‬מתי ועל ידי מי‪.‬‬ ‫)‪ -STD (Software Test Description‬תיאור תרחישי בדיקה‪ ,‬מסמך המפרט את תרחישי‬ ‫הבדיקה הספציפיים‪ ,‬כולל תנאים מקדימים‪ ,‬שלבי ביצוע ותוצאות צפויות‪.‬‬ ‫)‪ - STR (Software Test Report‬דוח סיכום בדיקות‪ ,‬מסמך המסכם את תוצאות הבדיקות‬ ‫שבוצעו‪ ,‬כולל פירוט הממצאים‪ ,‬הבאגים והמלצות‪.‬‬ ‫)‪ - SLA (Service Level Agreement‬הסכם רמת שירות‪ ,‬הסכם המגדיר את רמת השירות‬ ‫המובטחת‪ ,‬כולל זמני תגובה‪ ,‬זמינות המערכת וזמני טיפול בתקלות‪.‬‬ ‫)‪ - UAT (User Acceptance Testing‬בדיקות קבלת משתמש‪ ,‬השלב האחרון בתהליך פיתוח‬ ‫התוכנה‪ ,‬שבו המשתמשים הסופיים או נציגיהם בודקים את המערכת בסביבת עבודה אמיתית כדי‬ ‫לוודא שהיא עונה על הדרישות והצרכים שלהם‪.‬מטרת ה ‪-UAT‬היא להבטיח שהתוכנה מתפקדת‬ ‫כמצופה בתנאים מציאותיים‪ ,‬לפני הפצתה הרשמית‪.‬‬ ‫)‪ - GUI (Graphical User Interface‬ממשק משתמש גרפי‪ ,‬ממשק המאפשר למשתמשים‬ ‫לתקשר עם המערכת באמצעות אלמנטים גרפיים כמו כפתורים‪ ,‬תפריטים ואייקונים‪ ,‬במקום שימוש‬ ‫בפקודות טקסטואליות‪ ,‬במטרה לשפר את חוויית המשתמש ולהפוך את התוכנה לנגישה‬ ‫ואינטואיטיבית יותר‪.‬‬ ‫בדיקה סטטית‪ -‬בדיקת קוד ללא הרצה‪ ,‬מתבצעת בשלבי פיתוח מוקדמים‪ ,‬סוקרת מבנה לוגי וסגנון‬ ‫כתיבה‪ ,‬המטרה שלה היא זיהוי באגים ותקלות פוטנציאליות לפני הרצה‪.‬‬ ‫בדיקה דינמית‪ -‬בדיקת תוכנה תוך הרצאה בפועל‪ ,‬מתבצעת בסביבת הרצה מלאה‪ ,‬בוחנת‬ ‫התנהגות בפעול ותגובות למצבים שונים‪ ,‬המטרה שלה היא למצוא בפועל באגים בביצוע של‬ ‫התוכנה‪.‬‬ ‫)‪ - UI (User Interface‬ממשק משתמש‪.‬‬ ‫)‪ - UX (User Experience‬חווית משתמש‪.‬‬ ‫‪( Agile‬זמישות) ‪ -‬מתודולוגיית פיתוח תוכנה אינטגרטיבית‪ ,‬גמישה ומהירה‪ ,‬המתמקדת בשיתוף‬ ‫פעולה בין הבודק והמתכנת‪.‬‬ ‫‪ -Waterfall‬מודל בדיקות שמתחיל ברגע שהמוצר מוכן‪.‬‬ ‫)‪ - TDD (Test Driven Development‬פיתוח מונחה בדיקות‪ ,‬שיטת פיתוח תוכנה שבה נכתבת‬ ‫בדיקת יחידה בטרם נכתב הקוד אותו היא בודקת‪.‬‬  ‫‪ – Interface‬ממשק‪ ,‬נקודת המפגש או התקשורת בין שני רכיבים או מערכות‪ ,‬המאפשרת להם‬ ‫לעבוד יחד‪.‬‬ ‫‪ – Integration‬אינטגרציה‪ ,‬התהליך של שילוב רכיבים או מערכות נפרדות למערכת אחת‬ ‫מתפקדת‪.‬‬ ‫‪ – Internationalization‬בינלאומיות‪ ,‬התאמת התוכנה לשפות שונות‪.‬‬ ‫‪ - Batch‬עיבוד אצווה‪ ,‬תהליך אוטומטי המבצע סדרת פעולות על קבוצת רשומות בו‪-‬זמנית‪ ,‬ללא‬ ‫התערבות משתמש (לדוגמה‪ :‬עדכון משכורות בסוף חודש) ‪.‬‬ ‫‪ - C.R.U.D‬ארבעת הפעולות הבסיסיות שניתן לבצע על נתונים במערכות מידע‪:‬‬ ‫‪ – Create‬יצירה‪.‬‬ ‫‪ – Read‬קריאה‪.‬‬ ‫‪ – Update‬עדכון מידע קיים‪.‬‬ ‫‪ – Delete‬מחיקת מידע קיים‪.‬‬ ‫‪ - Test Case‬תרחיש בדיקה‪.‬‬ ‫‪ - Test Suite‬אוסף תרחישי בדיקה‪.‬‬ ‫‪ – Integration testing‬בדיקת אינטגרציה‪ ,‬בדיקת שילוב רכיבים שונים במערכת ובחינת תפקודם‬ ‫המשותף‪.‬‬ ‫‪ – System testing‬בדיקת מערכת‪ ,‬בדיקה כוללת של כל מרכיבי המערכת מול מסמכי האפיון‪.‬‬ ‫‪ – Alpha testing‬בדיקות אלפא‪ ,‬בדיקות מערכת בסביבה דומה לייצור‪ ,‬על ידי משתמשים באתר‬ ‫הפיתוח‪ ,‬יש יותר שליטה על הבדיקה אך החיסרון הוא המחיר הגבוה שלהם‪.‬‬ ‫‪ – Beta testing‬בדיקות בטא‪ ,‬בדיקות מערכת על ידי משתמשים‪ ,‬שלא באתר הפיתוח‪ ,‬פשוט‬ ‫להפעלה וזול אבל לא דיסקרטי ומאפשר דליפת מידע‪.‬‬ ‫)‪ - MVP (Minimum Viable Product‬מוצר בר‪-‬קיימא מינימלי‪ ,‬גרסה של מוצר הכוללת את‬ ‫התכונות הבסיסיות הנדרשות כדי לספק ערך למשתמשים הראשונים ולאסוף משוב לשיפור עתידי‪.‬‬ ‫‪ - Smoke Testing‬בדיקות עשן (בדיקות בסיסיות)‪ ,‬בדיקות ראשוניות המתבצעות על גרסה חדשה‬ ‫של התוכנה‪ ,‬במטרה לוודא שהפונקציות המרכזיות פועלות כמצופה‪ ,‬וכי המערכת יציבה מספיק‬ ‫להמשך בדיקות מעמיקות יותר‪.‬בדיקות אלו מסייעות לזהות תקלות בסיסיות בשלב מוקדם‪.‬‬ ‫‪ – Accessibility‬נגישות‪ ,‬התאמת מערכות למשתמשים עם מוגבלויות‪.‬‬ ‫‪ -Usability‬בדיקת שמישות‪ ,‬ידידותיות למשתמש‪ ,‬קלות שימוש והבנה של ממשק‪.‬‬ ‫‪ -Functionality‬פונקציונליות‪ ,‬תהליך הבודק האם התוכנה או היישום פועלים בהתאם לדרישות‬ ‫המוגדרות‪ ,‬תוך התמקדות בפונקציות ובתכונות המערכת‪.‬‬ ‫‪ -Maintainability‬תחזוקה‪ ,‬תהליך המעריך את היכולת של המערכת לעבור שינויים‪ ,‬תיקונים או‬ ‫שדרוגים בצורה קלה ויעילה‪.‬‬  ‫‪ –Compatibility‬תאימות‪ ,‬תהליך הבודק את היכולת של התוכנה לפעול בסביבות שונות‪ ,‬כגון‬ ‫מערכות הפעלה‪ ,‬דפדפנים‪ ,‬חומרה או גרסאות שונות‪ ,‬ולהבטיח שהיא מתפקדת כראוי בכל אחת מהן‪.‬‬ ‫‪-Responsive testing‬בדיקת רספונסיביות‪ ,‬מוודאות שהאתר נראה ועובד היטב בכל גדלי‬ ‫המסכים (מובייל‪ ,‬טאבלט‪ ,‬מחשב שולחני)‪.‬‬ ‫‪ -Link testing‬בדיקת קישורים‪ ,‬בודקות שכל הקישורים באתר עובדים ואינם מובילים לעמודים‬ ‫שבורים ‪(404).‬‬ ‫‪ – Performance testing‬בדיקת ביצועים‪ ,‬בדיקת תפקוד המערכת במצבי פעילות מלאה ולאורך‬ ‫זמן‪.‬‬ ‫‪ – Regression Testing‬בדיקת נסיגה‪ ,‬בדיקת השפעת תיקונים ושינויים על המערכת הקיימת‪.‬‬ ‫‪ - Sanity Testing‬בדיקות שפיות‪ ,‬בדיקות ממוקדות המתבצעות לאחר שינוי או תיקון בקוד‪,‬‬ ‫במטרה לו ודא שהפונקציונליות החדשה או המתוקנת פועלת כמצופה‪ ,‬וכי לא נגרמו תקלות נוספות‪.‬‬ ‫‪ - Load Testing‬בדיקות עומס‪ ,‬בדיקות המיועדות להעריך את ביצועי המערכת תחת עומסים‬ ‫שונים‪ ,‬על ידי סימולציה של מספר משתמשים או תהליכים במקביל‪ ,‬במטרה לזהות צווארי בקבוק‬ ‫ולוודא שהמערכת עומדת בדרישות הביצועים‪.‬‬ ‫‪ - Stress Testing‬בדיקות לחץ‪ ,‬בדיקה למציאת נקודת השבירה של המערכת בעומס גבוה‪.‬‬ ‫‪ - Performance Testing‬בדיקות ביצועים‪ ,‬בדיקות שמטרתן להעריך את מהירות‪ ,‬תגובתיות‬ ‫ויציבות המערכת תחת עומסים שונים‪ ,‬כולל בדיקות עומס‪ ,‬בדיקות עומס קיצון ובדיקות יציבות‪ ,‬כדי‬ ‫להבטיח שהמערכת פועלת ביעילות בתנאים מגוונים‪.‬‬ ‫‪ -Security Testing‬בדיקות אבטחה‪ ,‬בדיקת המערכת לאיתור כשלים בהגנה על המערכת‪.‬‬ ‫‪ – Authorization testing‬בדיקות הרשאות‪ ,‬בדיקת רמות גישה והרשאות של משתמשים שונים‬ ‫לפונקציות ומידע במערכת‪.‬‬ ‫‪ - Authentication testing‬בדיקות אימות זהות‪ ,‬בדיקת תהליכי הזדהות משתמשים במערכת‬ ‫(למשל‪ :‬כניסה עם שם משתמש וסיסמה)‬ ‫‪ -Survival and recovery testing‬בדיקת שרידות והתאוששות‪ ,‬בדיקת מערך הגיבויים‬ ‫והשחזור‪ ,‬מנגנון ההתאוששות מכשל ושיבה לפעילות‪.‬‬ ‫‪ – Black box testing‬בדיקת קופסה שחורה‪ ,‬בדיקות המתייחסות לקלט ולפלט של המערכת‪,‬‬ ‫ללא התייחסות למבנה הפנימי שלה‪.‬‬ ‫‪ – White box testing‬בדיקת קופסה לבנה‪ ,‬בדיקות תוכנה (קוד) המתייחסות למבנה הפנימי של‬ ‫הרכיב או המערכת‪.‬‬ ‫‪ – Grey box testing‬בדיקת קופסה אפורה‪ ,‬בדיקות המשתמשות בידע על המבנה הפנימי של‬ ‫המערכת אך מבצעות בדיקות בסגנון קופסה שחורה‪.‬‬ ‫)‪ - STT (State Transition Testing‬בדיקות מעברי מצבים‪ ,‬היא טכניקת בדיקות בתוכנה‬ ‫המתמקדת בבדיקת התנהגות המערכת כאשר היא עוברת בין מצבים שונים בתגובה לאירועים או‬ ‫קלטים מסוימים‪.‬‬  ‫)‪ – DTT (Decision Table Testing‬טבלת החלטה‪ ,‬טכניקת בדיקות בתוכנה המשתמשת‬ ‫בטבלאות החלטה כדי לייצג שילובים שונים של תנאים ופעולות‪.‬‬ ‫)‪ - UCT (Use Case Testing‬בדיקות מקרי שימוש‪ ,‬בדיקות המבוססות על תרחישי שימוש‬ ‫אמיתיים של המשתמשים במערכת‪.‬‬ ‫‪( Checklist‬רשימת בדיקות) ‪ -‬מסמך מובנה המכיל סדרת משימות או קריטריונים סטנדרטיים‬ ‫לבדיקה שיטתית ומלאה של תוכנה או תהליך‪ ,‬המאפשר בדיקה מקיפה ומובטחת ללא השמטת‬ ‫שלבים חיוניים‪.‬‬ ‫‪ - Equivalence partitioning‬טכניקת בדיקות המאפשרת לצמצם את מספר מקרי הבדיקה‬ ‫הנדרשים‪ ,‬תוך שמירה על כיסוי יעיל של פונקציונליות המערכת‪.‬‬ ‫‪ – Boundary value testing‬ניתוח ערכי קצה‪ ,‬טכניקה לבדיקת ערכי קצה וגבולות של קבוצות‬ ‫שקילות‪.‬‬ ‫‪ – Risk based testing‬בדיקות מונחות סיכון‪ ,‬גישה בה הבדיקות מתמקדות באזורים בעלי סיכון‬ ‫גבוה יותר‪ ,‬נועד כדי לתעדף בעיות בסיכון גבוה יותר על פני כאלה שלא‪.‬‬ ‫בדיקות מבוססות ניסיון ‪ - (Experience-Based Testing) -‬טכניקת בדיקות המתבססת על‬ ‫הידע והניסיון של הבודק לזיהוי תקלות פוטנציאליות‪.‬כוללת שלושה סוגים עיקריים‪:‬‬ ‫‪ -Error Guessing‬השערת בעיות שעלולות להופיע‬ ‫‪‬‬ ‫‪ -Fault Attack‬יצירת רשימה של תקלות אפשריות על סמך ניסיון קודם‪.‬‬ ‫‪‬‬ ‫‪ --Exploratory Testing‬גישה שבה תכנון הבדיקות‪ ,‬ביצוען ולמידת המערכת מתבצעים בו‪-‬‬