משתמשת:יוני2023/it's mine/קורס QA

[ https://www.youtube.com/watch?v=4IFWUQjNSaE קורס בדיקות תוכנה - חינם !!! QA]: על יוני פלנר שהפך להיות מפתח אוטומציה. האתר שלו: https://atidcollege.co.il/qa-mistakes/ לימודים לבד הוא חסכון כסף. יש המון באינטרנט חומרים. הכל ברשת הבעיה שרב הסרטונים הם באנגלית ועל ידי מדרכים קשה לנו להבין את המבט. תרומה שלו לקהילה.

אודות הקורס:

1. מבוא לבדיקות תוכנה
   • בעלי תפיקדים בהייטק
   • מן הן בדיקות תוכנה
   • למה הן חשובות
   • מחזור חי פיתוח תוכנה.
2. מודלים לפיתוח תכנה
   • מודל המפל
   • מודל הV
   • מודל האג’ייל
3. סוגי בדיקות : בדיקות עשן, שפיות, נסיגה, קבלה, שמישות
4. השלבים בבדיקות תוכנה : יחידה, קומפוננטה, אינטגרציה, מערכת
5. כתיבת מסמכי בדיקות STP STD STR
6. דוגמות לכתיבת מקרה בדיקה – מערכת סיסמאות
7. ניהוול באגים – דיוו, מחזור חי הבאג, דוגמה לכתיבת באג, מדדי באגים, כלים לניהול באגים.
8. בדיקות תעשיה: WEB, מערכות בנקאיות, בריאות, תקשורת.
9. בדיקות מוביל – היכרות עם עולם מוביל, סביבות בדיקה, ניהול אפליקצות ובדיקות
10. בסיס נתונים – מבוא לבסיסי נתונים, שאילתות בSQL, ניהול בסיס נתונים.
11. שאלות מראיונות עבודה – בדיקת מעלית, מכונת שתיה, אפלקציות WEB מול מוביל
12. מבוא HTML /CSS. JS : מבוא לHTMK, התקנת הסביבה…
13. מבוא לאוטומציה ולסלניום.

מבוא לבדיקות תוכנה

בעלי תפקידים בעולם ההיטק

קורס בדיקות תוכנה: חלק 1, פרק 1 QA : מתחלק לשנים

1. תפקידים טכנים – יותר עובדים
   • מפתח תוכנה או חומר – מיצר המערכות של החברה
   • בודק QA של התוכנה -
2. תפקידים שאינם טכנים
   • תמיכה טכנית (IT/SUPPORT) – מבצעים התקנות ללקוחות, מטפלים בשאלות טכניות של לקוחות וטיפול בתקלות.
   • ארכיטקטים – תכנון הארכיטקטורה של המערכת: כיצד המוצר מחולק לתת מערכות ומה היא האינטראקציה של תת המערכות הללו.
   • מהנדסי מערכת - תכנון הצד הרב תחומי של המערכת והגדרת דרישות מרכיבי החומרה השונים. יותר חמרה מתוכנה חברה שמיצרים תוכנה בלבד אין מהנדסי מערכת אלא ארכיטיקטים.
   • מפתחי אלגוריתמים - עוסקים בתכנון אלגוריתמים חדשים או וריאציות על אלגוריתמים למוצרים.
   • מנהל מוצר – חצי טכני וחצי שיויק, הגדרת דרישות המוצר, חלוקת הדרישות על פני גרסאות שונות ותעדוף של הדרישות. האחראים אצל הלקוחות על הצרכים העתידים שלהם.
   • Professional services - תפקיד הכלל מגוון אנשים ממתקינים, התאמה, פגיות עם הלקוח והגדרה עמו את הפתרון שניתן להצלי לו. עבור תפקיד זה יש צורך בהכרות עם מגוון רחב של טכנולוגיות מרשתות תעבורת נתונים, אחסון נתונים, שדה נתונים, מערכת אחסון נתונים. שימוש בכל ידע הזה כדי לתת ללקוח מערכת שעונה על דרישות עסקיות תוך גזירה של הדרישות הטכניות.
3. תפקידים שאינם טכנים
   • מנהלים של אנשים (ראש קבוצה ומנהל מחלקה וראש צוות) – לבצע ניהול בחברה כלומר חלוקת משימות בין עובדים וקבוצות, גיוס עובדים, ניהול לוח זמנים, העלאת צרכים , ציוד שנחוץ לחברה. כמו גם, תיאום בין קבוצות ודהינו שקבוצתו מספקת את שצריכה לספק לקבוצות אחרות בזמן להפך, קבוצתו מקבלת בזמן את המידע שנדרש לה כדי להתנהל מקבוצה אחרת. יש מנהלים של אנשים יש אנשים של תהליכים. קבוצה זו כוללת מנהל פרויקט ומנהל תכניות. תפקידם כולל ניהול תקציב לפרויקט, אחראיות על זמנים (דיווח כלפי מעלה וזיהוי חריגות בתקציבים ומתן טיפול בהם) אם יש בעיות עליהם להציף מעלה.
   • אנשי שיווק – נחלקים למספר מקצועות. תפקידם ליצר את הסביבה הדרושה כדי לקבל מכירות למוצר: פרסום של המוצר, החברה וניהול נוכחות רשת (אתר אינטנרט, דחיפת אינטרנט, הודעות לעיתונות), פרסום ע"י השתתפות בכנסים. תפקידם שונה מחברה המוכרת ללקוחות פרטים שמגיעים בעצמם בשל הפרסום. בחברה שמוכרת לחברות - שם אנשי השיווק מנסים להשיג פרטי קשר לאנשי מפתח בחברות אחרות והעברת אנשי המכירות להמשך טיפול.
   • אנשי מכירות -
     • עוסקים במכירת המצר, נכנסים בשלב מאוחר יותר, תקשורת עם לקוחות פוטנציאלים ומתאמי פגישות ונסיעות
     • account manger - אחראים על שמירת הקשר עם הלקוח כדי לוודא שמקבל טיפול לבעיות ולזהות הזדמנויות למכירה חוזרת לאותו לקוח.
   • אנשי אדמיניסטרציה - נותנים מתן שירותי אדמיניסטרציה לארגון ולמשרדים המוטמעים בו (מחלקות/הנהלה)
   • משאבי אנוש - אחראים על רווחת העובדים בארגון (ימי גיבוש וכיוצב), חיפוש וגיוס עובדים חדשים, ניהול הערכות שנתיות.

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

מהן בדיקות תוכנה?

קורס בדיקות תוכנה: חלק 1, פרק 2 QA: בחלק הראשון של המצגת יוני מנסה פלנר מנסה להסביר את התהליך בקצרה של פיתוח תוכנה:

• מפתחי המוצר – תמונה של מספר חברי צוות בניהם דוד, חיים, אשר ומשה אשר הם מתכנתים דהינו כותבים את הקוד. דוד ראש הצוות. הקוד מטרתו לפתח מוצר, איזה אפליקציה למוביל. אף אחד לא בדק את המוצר עדין.
• צוות הQA – צוות בדיקת המוצר ואיכות (QA הוא קיצור של Quality assurance) של אותו מוצר שנכתב. מייקרוסופ וורד - כשאנו לוחצים על file-save אנו מצפים כי המוצר ישמר. דוגמה:
  • משהו צריך לבדוק שאכן המסמכים נשמרים. כאן נכנס QA. יש מדדים שונים להגדרת מוצר איכותי ומתי מפסיקה הבדיקה.
  • אנו מחפשים של זמרת אנחנו מצפים לקבל תוצאות של אותה זמרת לפי סדר רלוונטי: שירים של אותה זמרת, שיתופי פעולה עם אמנים אחרים וכן הלאה. אנחנו לא מצפים שQA ימצא שיר של זמר אחר שלא שיתף פעולה עם אותה זמרת. כלומר יש תקלה בחיפוש. הQA יפתח באג, יגיע למפתחים ומשם יעבור תהליך שנקרא life cycle שקשור אל תחום הבאג עליו נרחיב בהמשך.
• פרסום של האפלקציה בגוגל פליי וכו.

למה הן חשובות

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

מחזור חיי פיתוח תוכנה

קורס בדיקות תוכנה: חלק 1, פרק 4 QA

Soqfware deleopment life cycle – SLDC - מחזור החיים לפיתוח תוכנה בחברות הייטק שמטרתו לאפיין ולפתח ולבדוק מוצר תוכנה ברמה גבוהה לפי ציפיות הלקוח. זה הוא תהליך שכולל מספר שלבים.

• שלב התכנון – מבוצע על ידי חברה צוות הפיתוח עם ניסיון וותק. אנשי המכירות והביזננס יקחו חלק. כמובן ישבו עם הלקוח כדי לדעת מה הציפיות מהמוצר. הם יושבים יחד מה הציפיות ורושמים לתוך מסמך. הם מתכנים גישות לתכנון פרויקט. הם יתכנו איך לבצע את הפרויקט והחזר הוצאה והשקעה כלומר proof of concept. מתכנים את הדרישות ולזהות את החלקים הטריקים, הקשים עם התמודדות והבעיתים עם הפרויקט. לומדים אותם כדי לתת בשלבים הבאים את הגישות הטכניות לביצוע הפרויקט מבינון סיכון.
• שלב ההגדרות או הגדרת הדרישות – אחרי הגדרת היתכנות, שראינו מקודם שהגיע מהלקוח, מטרה של שלב זה הוא לפרט ולהגדיר באופן מפורש של דרישות המוצר ולבקש את אישור הלקוח עבור תחילת עבודה. המסמך נקרא גם Software Requirements Specification (SRS) – כל דרישות המוצר שיופתחו בהמשך
• עיצוב ארכיטקטורה – מסמך SRS הוא עם דרישות הלקוח עם דרישה עסקית. עתה מתרגמים אותו לדרישה טכנית שניתן לתכנת ולפתח כדי שמפתחים הבאים יפתחו את אותן הגדרות. המסמך נקרא design document specification DDS.
• בניית המוצר - מפתחי המוצר מקודדים את המוצר, החלקות, ממשים פונקציונליות כשכולם צריכים ללכת לפי הנחית כלומר לפי DDS. במקומות אחרים יתכן כי יקרא בשם אחר.
• בדיקות - יכיל את בדיקות המוצר, הקוד נכתב וצוותי QA עושים סקריפטים של בדיקות ומפעילים אותם. בודקים שהמוצר עומד לפי הקרטריונים במסמך האפיון. במחזורי חי פיתוח תוכנה הבדיקות מתבצעות כל הזמן עד שהמפתחים מסימים את עבודתם.
• שחרור המוצר - המוצר נכתב וכל הבדיקות התבצעו. אנו משחררים את גרסת המוצר ללקוח במלואו או סגמנטצים מסוימים כלומר יתכן כי חלקים מסוים לא יבדקו אלא על ידי הלקוח - user acceptance testing. לפי פידבק הבדיקות יהיה ניתן לדעת אם לקחת צעד אחורה ולתקן את המוצר או לשחרר את כל המוצר עצמו.
• maintenance - תחזוקה - תיקון באגים שנמצאו על ידי אנשי הבדיקות או חס ושלום על ידי הלקוחות. נוודא כי התיקונים לא פגעו בחלקים אחרים במוצר מה שמכונה רגרסיה.

מודלים של פיתוח תוכנה

מודל המפל מים (waterfall)

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

• דרישות – הגדרת פעולות שהמערכת צריכה לבצע. פעולות שדורשות קלט שאותו מאזין הלקוח והנפקת פלט או דרישות שאינן מצריכות קלט מהשתמש ובמקום המערכת מבצעת רצף פעולות שהוגדרו מראש.
• תכנון- הגדרת תהליכים, מסכים למערכת UI, ממש משתמש, הגדת פעולות של כל מיני מסכים. טרם המימוש המערכת מתוכנן עד שדה יחיד. השינוים מבוצעים על הנייר.
• מימוש – לאח התכנון, מסמך האפיון הוא מאוד מדויק ומוגש למפתחי המערכת, בשלב זה יש מימוש על ידי קידוד, יצירת נתונים ועיצוב גרפי. מימוש הוא תהליך קצר רובו מתבסס על התכנון המוקדם.
• בדיקות- אחרי שהמערכת נבדקת במלואה היא נבחנת על ידי הQA. בחינת פעילות (הזנת נתונים שגוים – NEGATIVE TEST), פעולה בעומס יתר LOW TESTING. בשלב זה מתגלה חולשות המערכת והיא עוברת שינוים כדי לצאת יציבה. השלב הרלוונטי לנו.
• תחזוקה (התשים מאתר ויקיפדיה) – אחרי הפקת המוצר ללקוח יש תחזוקה שוטפת ויש רק תיקון שגיאות אם קיים.

יש מודלים חדשים ופופלרים יותר.

מודל הV

קורס בדיקות תוכנה: חלק 2, פרק 2 QA מודל שלכל שלב בפיתוח התכנה קיים שלב מקביל של בדיקה. המודל מדגים איך פעילויות של בדיקות התכונה יכולות להשתלב במחזור חי הפיתוח של התוכנה. המודל מגדיר 4 רמות פיתוח כשלכל רמת פיתוח קיימת רמת בדיקות שמתאימה לה.

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

• requirement analysis מקביל לשלב התיכנון. ניתוח הדרישות מצד הפיתוח יהיה מקביל לבדיקות הקבלה acceptance testing
• system design מקביל להגדרת דרישות.בשלב זה יתבצעו בדיקות - System testing
• עיצוב ארכיטקטורה - architecture design . בשלב זה הבדיקה היא integrtion testing
• module design + coding - בנית מוצר - כאמור יש מודלים עם 4 שלבים ויש עם 5.שם הבדיקה הוא unit testing. ברב המקומות UNIT TESTING הם תחת אחריות של המפתחים.

כלומר צוות הQA יעבור את שלבי הבדיקה: acceptance testing, System testing , architecture design וunit testing.

מודל האג’ילי (Agile)

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

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

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

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

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

איך כל זה מתחבר לבדיקות? בדיקות הם חלק מפיתוח תוכנה בצוותי research and development (RAD). כמו שמפתחים תוכנה מהיר כך זה חל על הבדיקות. סבבי הבדיקות יהיו קצרים. לכן הטעמה של אטונציה בבדיקות יהיה חלק מרכזי של הQA. על כך יסביר בהמשך.

יתרונות למודל על המפל:

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

לכל צוות באינגל יש איש QA ולכן סנכרון בין שני צוותים יהיה יותר אינטואטיבי

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

בצוותים אג'ילי מעודדים רכישת יכולות מגוונות ושיתוף ידע בצוות לגבי כל משימות הפיתוח לכן QA יכול לדעת את דרישות הפיתוח של אותו איש מפתח בקדמת הבמה (front stage).

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

כמובן לטיפול מהיר בהן. קן שוובר (Ken Schwaber), ממציאי הסקראם, השכיל לומר: “שיטת הסקראם היא כמו חמותך, מדגישה את כל הפגמים שלך” (Scrum is like your mother in law it points out ALL your faults). המעבר לאיג'ל הצריך שינוי בתפקיד הQA. זה כבר לא אותו תפקיד מסורתי. כיום נדרש מאיש הQA להטמיע דברים מהירים יותר. בדיקות מהירות יותר מתבצעות על ידי אוטומציה, בדיקות אוטומטיות. לכן QA שלומד מודל מסורתי יהיה לו קשה למצוא עבודה אם אין לו אוטומציה. אוטומציה היא חשובה היום ולפני 7 שנים היה צורך באוטונציה ועד כמה שנים יהיה צורך יותר. יש דיון האם אוטומציה תשתלט על השוק ולא יהיה צורך בבדיקה ידינית. הוא לא רואה את תפקיד הQA נעלם אך כן יש יותר דרישה לאוטומציה על חשבון הQA. תפקיד הQA לדעתו יהיה אדם שישלב את שני ידיעות הן של אוטומציה והן הבדיקות הידנית המיושנת. אדם עם QA ללא יכולת קידוד יהיה לו קשה לתפקד.

מקורות מידע נוספים

• ארז מורביה, על היתרונות של שיטת הפיתוח אג’ייל ואיך תעשו את זה נכון

סוגי בדיקות

בדיקות עשן (smoke)

קורס בדיקות תוכנה: חלק 3, פרק 1 QA: בשלב זה נדון על בדיקות שונות אחרי שדנו באופן כללי על פיתוח תכנה והיטק. נושאים ששלא נוגעים ישירות לבדיקות. בפרק הראשון יהיה דיון על בדיקות עשן. בדיקות עשן הן בדיקות בסיסיות שמטרתן להעריך אם המערכת יכולה לבצע את התפקוד הבסיסי שלשמו מיועדת. בדיקות אלו יעשו לאחר בנית BULID ושחרורו לצוות הQA. יתכן כי הBULID יתבצע יותר מפעם ביום. עבור בדיקות אלו אנו בוחרים "מקרי בדיקות מכזיים שיש להם השפעה קריטית על הפונקציונליות של המערכת"

דוגמה: המערכת הנבדקת (AUT-Application under Test) היא אפלקצית WAZE. מאחורי הקלעים יש שרת של WAZE שמסתכרן מול בסיס הנתונים ודן עם הלקוח שמשתמש ונתמך בשני אמצעים או בדפדפנים או בסלולרים חכמים. באופן כזה כשנכנסים לסלולר ופתחנו את האפלקציה ואנו רוצים לנווט למיקום מסוים כמו מהבית לאילת אזי נזין בשדה החיפוש אילת והוא יביא אותנו לשם בנתיב לשם הכי מהיר. זה מה שנכניס אל בדיקת העשן. כי אם אפשרות זו לא תעבוד יהיה בעיה בתוכנה.

בדיקות שפיות (sanity)

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

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

בדיקות נסיגה (Regression)

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

בדיקות קבלה (Acceptance)

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

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

בדיקות שמישות (Usability)

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

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

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

כלים עמם ניתן לבצע בדיקות שמישות:

• סקרים ושאלונים
• כלים להקלטת תנועות עכבר
• כלים עוקבי הקלקות
• כלים אנליטיים
• נתונים סטטיסטים
• מעקב אחר תנועת העין

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

בדיקות חוקרות (exploratory)

קורס בדיקות תוכנה: חלק 3, פרק 6 QA לרב כשנבצע בדיקות אנו נבדוק מוצר ע"פ בדיקות מתוסרטות (scripted) כלומר על סמך מסמך איפיון.

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

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

יתרונות של הבדיקה: <ש>

• מניעת שחיקה QA בשל שינוי צורת העבודה. לדוגמה אנו יוצאים למשימה של QA. היום, מחר ומחרתים כל הזמן כל יום נעשה בדיקות מזמן העובדה. זה יביא לשחיקה...(ועוד דוגמות שחיקה). כאמור זה יותר FREE STYLE כלומר פחות מסמכי איפיון.
• יציאה מקיבעון כך שנותן לנו יציאה שנותנת תמונה נוספפת על אותו מוצר שלא שמנו לב להם קודם לכן שמשהו כתב קודם לכן
• בדיקות דינמיות ומשלבות שיקול דעת והתאמה למצב מה שמביא לתפוקות גבוהות עם הניסיון
• התמקצעות מצד הבודק על לוחות זמנים ותיעדוף בדיקות
• מביא לידי ביטוי את היכולות של הבודקים הוויתיקים עם הניסיון הרב שלהם

חסרונות:

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

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

בדיקות חודרות (penetration)

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

• הזדהות
• הרשאות
• בקרה וחיווי
• אבטחת תקשורת
• אבטחת תוכנה
• שרידות והתאוששות
• Audit trail

מאפיני הבדיקות של אבטחת מידע :

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

נניח דרך הWAZE ננסה להתחבר לשרת ונקבל מידע שאנו לא אומרים לראות אותו. נניח אנחנו כאקר נתחבר למערכת דרך השרת שיתן הגדרת "בית" של אדם אחר ולא שלנו כדי לדעת כתובת מגורים של אותו אדם.

בדיקות ביצועים (performance)

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

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

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

יש תפקיד של איש ביצועי.