בין אם אתה מקודד תוכנה עבור חברי החברה שלך או בסיס לקוחות רחב, קיים את שיטות הבדיקה והמסגרות הנכונות, בין אם ידניות, אוטומציה או היברידיות, מוביל לאיכות תוכנה עקבית, מוניטין משופר ויעילות.
בהתאם לחברה בה אתה עובד, הרבה בדיקות מגיעות בצורה של בדיקות ידניות.
למד עוד על מהי בדיקה ידנית, מה חברות בודקות עם בדיקות ידניות ועוד מגוון עובדות חשובות על תהליכי בדיקות תוכנה.
מהי בדיקה ידנית?
בדיקה ידנית היא סוג של בדיקות תוכנה שבהן מקרה בדיקה מבוצע באופן ידני על ידי הבוחן ללא סיוע של כלים אוטומטיים .
חברות משתמשות בבדיקות ידניות כשיטה לזיהוי באגים או בעיות בתוכנה שלהן. בעוד שיש המתארים זאת כצורה פשוטה או פרימיטיבית של בדיקה, היא בסופו של דבר מבססת את הפונקציונליות של תוכנית מבלי לדרוש שימוש בכלי בדיקה של צד שלישי .
לכל צורות בדיקות התוכנה יש כמה היבטים ידניים, שכן יש כמה תכונות של אפליקציה שפשוט בלתי אפשרי לבדוק ללא התערבות ידנית כלשהי.
1. מתי צריך לעשות בדיקה ידנית?
ישנם מספר שלבים שבהם מפתחים משתמשים בבדיקות ידניות, כאשר הראשון הוא לאורך שלב פיתוח הפונקציונליות הבסיסית.
כאשר הפונקציונליות הבסיסית של התוכנה נמצאת בפיתוח מפתחי תוכנה בודקים שכל אחד מחלקי התוכנה פועל באופן ידני, שכן הדבר מהיר יותר מיצירת מקרי בדיקה עבור חלקים פשוטים למדי בקוד.
בדיקות ידניות נפוצות גם בשלבים האחרונים של הפיתוח כאשר לתוכנית נוצר ממשק משתמש. בדיקת ממשק משתמש כוללת לראות כיצד משתמש בחיים האמיתיים מגיב לאופן שבו התפריטים מעוצבים ואיך המערכת פועלת.
מכיוון שהדבר כרוך בהרבה נתונים איכותיים ודעה אישית במקום מדדים כמותיים טהורים, בדיקה ידנית היא האפשרות האידיאלית לקבלת מידה רבה יותר של תובנה לגבי המוצר.
2. כאשר אין צורך לבצע בדיקות ידניות
ישנם כמה מקרים שבהם שימוש בבדיקה ידנית ייקח הרבה יותר זמן ומאמץ מהנדרש, הראשון שבהם הוא בבדיקת מסד נתונים.
מסדי נתונים מטפלים בכמויות עצומות של נתונים והזנה ידנית שלהם תיקח הרבה זמן ולא תהיה יעילה עבור ארגון.
במקרים אלה, שימוש במערכות אוטומטיות הוא אידיאלי שכן הן יכולות להתמודד עם חבילות נתונים גדולות בפרק זמן מוגבל.
בדיקה ידנית גם פחות שימושית בתחומים כמו בדיקות עומס , שבהם מפתח משלים בדיקות כדי לראות כיצד התוכנה שלו מטפלת בעומסים משמעותיים של משתמשים.
זה קורה לעתים קרובות עבור יישומים ותוכניות מקוונות עם שרתים הדורשים הערכה יסודית. השלמת בדיקות ידניות תדרוש מאנשים רבים לגשת לאפליקציה בבת אחת, וזה יכול להוביל לעלויות עבודה חמורות עבור שירות שניתן להשלים על ידי מערכת בדיקות תוכנה אוטומטית בעלות נמוכה בהרבה.
3. מי מעורב בבדיקה ידנית?
אנשי הצוות המעורבים בבדיקות ידניות תלויים באופי החברה בה אתה עובד.
חלק מהאנשים המעורבים בתהליך הבדיקה הידנית, בנוסף לסוג צוות הפיתוח בו אתה מוצא את התפקידים הבאים:
· מפתח:
מפתח מעורב בתהליך באופן רציף, בודק את הפונקציונליות הבסיסית של התוכנה ומבצע עדכונים לקוד בהתאם למשוב בודק QA.
מפתחים מסיימים הרבה בדיקות ידניות, מכיוון שהם אחראים על כך שהמודולים יעבדו ברמה גבוהה בשלבים המוקדמים ביותר של פיתוח תוכנה.
· בודק QA
נוכחים בצוותים גדולים יותר, בוחני QA משלימים באופן בלעדי בדיקות עבור חברה ומבטיחים שהאפליקציה פועלת כפי שהלקוח מצפה.
בודק QA חשוב בעיקר לקראת שלבי הבדיקה, האינטגרציה והתחזוקה של הפיתוח, ומשתלט על הבדיקות הידניות מהמפתחים עצמם הבודקים לאורך כל היישום.
· מנהל QA
עובד בחברות הפיתוח הגדולות ביותר, מנהלי QA מקצים בודקים למשימות ותחומים ספציפיים של הפרויקט.
הם גם אחראים ליצירת רשימה של דברים שיש להשלים ולקריאת דוחות מבחן. זה חשוב במיוחד בבדיקות ידניות, שכן שביעות רצון הצוות יכולה לספק תוצאות טובות בהרבה.
מה אנחנו בודקים עם בדיקות ידניות?
ישנם כמה היבטים שונים של התוכנה אותם בודקים בדיקות ידניות, שכל אחד מהם טוב יותר בעת שימוש בבדיקות ידניות הודות לאתגרים הספציפיים של הבדיקות.
כמה מהתכונות העיקריות שאתה נהנה משימוש בבדיקות ידניות עבורן, בנוסף לסיבות שהבדיקות הידניות משגשגות כאן, כוללות:
1. פונקציונליות בסיסית
אחד החלקים המוקדמים ביותר של תהליך בדיקת התוכנה בוחן את הפונקציונליות הבסיסית של תוכנה.
בשלב זה, מפתח או בודק מסתכל באחד מהמודולים הפונקציונליים של הקוד ומעריך אם הוא פועל כמצופה. בשל קנה המידה הקטן של המודולים הללו, כדאי להתמקד בבדיקות ידניות מכיוון שאוטומציה תימשך זמן רב מדי.
דוגמה לכך היא תוכנת מסד נתונים, כאשר בודקים מכניסים פיסת נתונים לפונקציה וכבר יודעים את הפלט הצפוי.
אם השניים תואמים, הבדיקה תצליח. בדיקה בשלב זה של התהליך מציבה בסיס חזק להמשך עבודת החברה.
2. עיצוב ממשק משתמש
ממשק המשתמש מתייחס לממשק המשתמש של תוכנה, או לתפריטים, הכפתורים והאינטראקטיביות הזמינים למשתמש.
בדיקת ממשק משתמש מתמקדת הן באופן שבו ממשק המשתמש פועל והן האם זוהי דרך עבודה נוחה עבור המשתמש, כולל אם המשתמש יכול לקיים אינטראקציה עם כל התכונות והאם התפריטים הם אסתטיים.
בדיקה ידנית היא הכרח בשלב זה, מכיוון שמידע איכותי כמו האם הממשקים נראים טוב אינו משהו שתוכנית אוטומטית מצטיינת בו.
3. בדיקת חדירה
בדיקת חדירה מתייחסת לבדיקת חבילת תוכנה כדי לראות את הקלות שבה גורם חיצוני יכול לגשת לתוכנה באמצעים לא לגיטימיים.
אוטומציה של תוכנה מתמקדת במעקב אחר כמה שלבים ספציפיים ובהשלמת התהליכים שהם כבר חלק מהאפליקציה במקום לחקור תחומים חדשים, חובה לבדיקות אבטחה.
לדוגמה, חברה עשויה לשכור האקר אתי כדי להעריך את התוכנה שלהם ולחפש כל הזדמנות שיכולה להיות לצד זדוני לגשת לנתוני משתמשים.
זה יותר ויותר חשוב בשנים שחלפו מאז חקיקת ה-GDPR כחלק מהחוק ברחבי אירופה.
4. בדיקות חקרניות
בדיקות חקר מתייחסות לבדיקה שצריך להשלים רק פעם או פעמיים, קבלת השם מכיוון שהיא חלק מ”חקירת” התוכנה עבור כל תכונות או באגים בלתי צפויים.
בדיקה ידנית מתאימה יותר למקרה זה מכיוון שלוקח זמן לכתוב את הקוד למקרה בדיקה ומישהו שנכנס ידנית לתוכנה ובוחן אותה ייקח פחות זמן.
דוגמה לכך היא כאשר מפתח רוצה לבדוק אם תכונה מסוימת משולבת כהלכה, עם בדיקה בודדת המוודאת שהנתונים עוברים בצורה נכונה בתוכנית.
מחזור חיים של בדיקות ידניות
ישנם כמה שלבים במחזור החיים של בדיקות ידניות, כאשר בדיקות ידניות משמשות לבחינת מגוון רחב של היבטים של חבילת תוכנה.
חלק מהשלבים במחזור החיים של בדיקות ידניות כוללים:
· תכנון
תכנן סבב בדיקות, הכולל הערכת דרישות האפליקציה, הבדיקות הספציפיות שיש להשלים והמבנה שבו אתה בודק את התוכנה.
שלב זה כולל כתיבת מקרי בדיקה עבור בודק ידני להשלמתו ויצירת סביבת בדיקה. היה יסודי כדי למנוע מבוחנים ידניים לבצע בטעות בדיקות בדרכים שונות.
· בדיקה:
השלם את הבדיקות. זה כרוך במעבר על מקרי הבדיקה מספר פעמים כדי לקבל נתונים עקביים ולרשום את כל המידע שאתה מקבל.
אם אתה בכלל שונה ממקרה המבחן, רשום איך ולמה. השונות היא הנפוצה ביותר במבחנים מקצה לקצה , אך כל הבדיקות הידניות יכולות לחוות הבדלים מסוימים באופן שבו בודק פועל.
· ניתוח:
נתח את כל התוצאות שקיבלת מהבדיקות. זה כולל מציאת מהן השגיאות בתוכנה והגורמים הפוטנציאליים לבעיות.
עברו מעבר לפונקציונליות פשוטה ושלבו מידע איכותי כגון התחשבות בעיצוב האפליקציה.
מידע איכותי משגשג במיוחד בבדיקות ידניות, כאשר בודקים מייצרים נתונים תיאוריים המודיעים למפתחים על התאמות דקות שמשפרות מאוד את החוויה של מישהו עם אפליקציה.
· יישום:
השתמש בדוחות הקודמים כדי ליישם מגוון של שינויים. זה יכול להיות תהליך ארוך בהתאם לשינויים, כאשר מפתחים מתנסים בקוד כדי לספק פתרון לבאגים שהיו קיימים בגרסאות קודמות.
כאשר משתמשים בבדיקות ידניות, מפתחים מקבלים יתרון נוסף מלדבר על כל השינויים עם בודק. זה עוזר לשני הצדדים להבין נכון מה צריך התאמה וכיצד ניתן להתאים אותו, בין אם מדובר בשינוי פונקציונלי או עיצובי.
· התחל תכנון מחדש:
בזמן שמפתחים יוצרים תיקון לבעיות בבדיקות הקודמות, תכנן את קבוצת הבדיקות הבאה. זה כולל בדיקת העדכונים האחרונים וניסיון ליצור מחדש את הבאגים שהיו בגרסה האחרונה.
מחזור הבדיקות הקבוע הזה אומר שהתוכנה תמיד משתפרת ולעולם לא סטטית. בדיקה ידנית עשויה להרגיש כאילו היא אורכת זמן רב, אבל יש החזר משמעותי על ההשקעה מהגמישות וההמשכיות שהיא מציעה עם בדיקות חוזרות.
היתרונות של בדיקה ידנית
ישנם יתרונות רבים בשימוש בבדיקות ידניות בחברת פיתוח תוכנה, החל מאיכות התוכנה עצמה ועד לאופן בו הפרויקט משפיע על הכספים של החברה.
חלק מהיתרונות של שימוש בבדיקות ידניות בחברה כוללים:
1. גמישות רבה יותר
על מנת להשלים אוטומציה של בדיקות, אתה צריך אנליסט QA כדי להיכנס לתוכנה ולקודד מקרה בדיקה, אשר משלים סט מדויק של שלבים בכל פעם.
למרות שלפעמים זה מועיל, בודק אנושי יכול לעבור תהליך ולהבחין במשהו לא במקום לפני חקירה וללא צורך לשנות שורת קוד.
זה מגביר באופן משמעותי את הגמישות של הבדיקות שלך ופירושו שאתה מוצא בעיות בתוכנית שלך שאחרת לא היו מורגשים, עם הזדמנות גדולה יותר לתקן את הבעיות.
2. מידע איכותי
מידע איכותי מתייחס למידע שמתאר משהו, וזה סוג של מידע שבודקים אנושיים יכולים להציע לצוות מפתחים.
בודק ידני יכול ליידע את החברה אם תפריט מסוים מרגיש “מסורבל” ולהסביר מדוע, בעוד שתוכנית אוטומציה לא תוכל להציע את התובנה הזו למפתח.
משמעות הדבר היא שעל ידי הטמעת בדיקות ידניות בתהליכי העבודה שלהן, חברות יכולות להגביר משמעותית את רמת האפליקציה באופן שבו הן יתקשו כשהן משתמשות אך ורק באוטומציה של בדיקות בתהליכים שלהן.
3. אין מגבלות על ידי הסביבה
בדיקות אוטומציה מסתמכות על שימוש בפלטפורמה קיימת, כאשר לחלקן יש מגבלות נוקשות יחסית.
מגבלות שעומדות בפני חלק מהפלטפורמות (אם כי לא כולן) כוללות אי יכולת לעבוד עם פלטפורמות כמו לינוקס , יכולת לעבוד רק עם שפת קידוד מסוימת, וטיפול רק במספר מוגדר של משימות.
כשאתה עובד עם אנשים בתהליכי הבדיקה שלך, המגבלות הללו נעלמות למעשה. אתה מוגבל רק על ידי המיומנות של הבודקים הידניים שלך ולא על ידי בעיות טכניות כלשהן.
זה עוזר לך ליצור אסטרטגיית בדיקה שבוחנת תוכנית בצורה יסודית יותר מבלי שתצטרך להתפשר.
4. מאפשר בדיקת שמישות
בדיקת שמישות היא סוג הבדיקה שמעריכה האם תוכנה היא “שמישה”, כולל האופן שבו היא נראית ומרגישה למשתמש הקצה.
סוג זה של בדיקות חורג מהערכה מילולית אם ניתן להשתמש בפונקציה, אך בוחן אם מישהו יבחר להשתמש בה על פני מוצרים מתחרים.
הטמעת בדיקות שמישות ידניות מספקת לחברות תובנה רבה יותר ועוזרת לבצע התאמות שהופכות את האפליקציה לתחרותית יותר, דבר שהאוטומציה לא יכולה להציע לצוותי הפיתוח.
אתגרים של בדיקה ידנית
כמו בכל סוג של תהליך כמפתח, ישנם כמה אתגרים הקשורים לשימוש בבדיקות ידניות ככלי לאבטחת איכות .
על ידי הכרת האתגרים הללו תוכל להתאים את הטכניקה שבה אתה משתמש בעת בדיקת תוכנה ידנית, למנוע מבעיות אלו לגרום לבעיות קשות ולהגביר את רמת התוכנית בסוף התהליך.
כמה מהאתגרים העיקריים שעומדים בפני חברות בעת שימוש בבדיקות ידניות כוללים:
1. רמות מיומנות בוחן
האתגר הגדול הראשון שיש להתמודד איתו הוא רמת המיומנות הנדרשת של כל הבודקים הידניים בצוות.
עם בודקים ידניים מוכשרים, חברות רואות יתרון ברור שכן הן מאתרות באגים מהר יותר ובטוחות בידיעה שהתוכנה שלהן פועלת כמצופה. החברות הטובות ביותר מחפשות תמיד בודקים ידניים שנמצאים בחזית התחום כדי להבטיח רמת ביצועים גבוהה יותר.
בתור בוחן בעצמך, חפש תמיד ללמוד ולפתח את המיומנויות הללו. מיומנויות משופרות אומרות שאתה מביא יותר ערך לחברה, עם בדיקה ידנית מאתרת באגים נוספים ומשפרת את חוויות המשתמש. המבחנים הידניים הטובים ביותר מגיעים מבוחנים שהשקיעו זמן בשיפור מלאכתם.
2. עלות בדיקה
בדיקה ידנית היא תהליך נפוץ לעסקים מכל הגדלים, אך בהתאם לדרך שבה אתה משתמש בבדיקה ידנית העלויות עלולות לצבור.
לדוגמה, חברה שיש לה מספר חברי צוות בדיקות מיומנים על הספרים יכולה להוציא הרבה כסף אם יתבצעו בדיקות חוזרות ונשנות, מכיוון שאתה משלם למעשה עבור כל הזמן של כל הנוכחים. זו פחות בעיה בתהליכי בדיקה אוטומטיים.
קונטרה אידיאלית לנושא זה היא תכנון קדימה, שכן ככל שאתה מקדיש יותר זמן לתכנון המבחנים שאתה מסיים והסדר שבו אתה מסיים אותם, כך יש סיכוי נמוך יותר שעלויות כוח האדם יעלו ככל שאנשים יבצעו בדיקות שהם עושים. לא צריך.
3. זמן רב
מחשבים מהירים יותר מאנשים בכל מיני דברים, מתכנון מהלך שחמט ועד להשקיע כסף בבורסה או אפילו פשוט לחיצה על כפתור לאחר שהוא משנה צבע. אותו רעיון חל על בדיקות, כאשר משתמשים לוקחים את הזמן שלהם לקרוא את כל המידע ולנווט את דרכם בתפריטים.
לכן, בדיקה ידנית יכולה לקחת הרבה יותר זמן מאשר שימוש באוטומציה של בדיקות. התמודד עם זה על ידי שימוש בשילוב של מבחנים ידניים ואוטומטיים, הוצאת משימות נמוכות מהבודקים הידניים, ובמקום זאת שימוש בהן היכן שהמומחיות נחוצה. פישוט התהליכים שלך הוא גם אידיאלי לבדיקה ידנית, מכיוון שהיא מוציאה כמה שיותר שלבים.
4. פוטנציאל לטעויות
אנשים עושים טעויות. זה טבעי, בין אם זה בא בצורה של השלמת שלבים בסדר לא נכון בבדיקה או רישום לא מדויק של התוצאות הודות לקליק שגוי. עם זאת, שגיאות אלו עלולות לגרום לבעיות חמורות עם הדיוק של משטר בדיקות תוכנה.
בודקים ידניים עייפים או עייפים יותר מלהשלים את אותה משימה פעם אחר פעם נוטים יותר לעשות טעויות מאחרים, לכן השתמש באוטומציה כדי להימנע מכך במידת האפשר, או תן לבודקים הפסקות קבועות מהמסך שלהם, מכיוון שזה שומר עליהם ערניים יותר ל מה קורה.
מנהלים יכולים גם לשקול ניהול עומס עבודה כדי למנוע מאנשים להישרף ולהיתקל בבעיות.
מאפיינים של בדיקות ידניות
יש כמה מאפיינים עיקריים שצריך לחפש בבדיקות ידניות. אלה מגדירים מהי בדיקה ידנית והם מאפיינים משמעותיים שתוכל לתכנן סביבם בעת תכנון הבדיקות שלך.
למד עוד על כמה מהמאפיינים העיקריים של בדיקות ידניות ומה משמעותן בסביבת בדיקה פעילה:
1. מקרי בדיקה אופטימליים
בבדיקות ידניות, מקרי בדיקה מותאמים מאוד. הכוונה היא להוראות שיש לבוחן ידני לקראת השלמת בדיקה, עם רמה גבוהה של אופטימיזציה המובילה לצוות בדיקות שחוסך זמן ומשאבים כשהוא מבצע פחות משימות.
חפש תמיד להגביל את גודלו של מקרה בדיקה בכל מקום אפשרי כדי להפיק את המרב מהמשאבים הזמינים.
2. מדדים מובנים יותר
לבדיקה הידנית הטובה ביותר יש מדדים מובנים יותר. כאשר אוטומציה של בדיקות מייצרת כל הזמן נתונים סטטיסטיים ומידע מורכבים, התובנה שמדדים אלה יכולים לספק אינה שווה את הזמן שייקח לבוחן ידני להשלים או לחשב.
כחלופה, בדיקות ידניות כוללות מדדים פשוטים הרבה יותר שקל להפיק ולוקח פחות זמן לנתח אותם בהמשך התהליך.
3. דיווח מושכל
בדיקה ידנית מובילה לדיווח חכם יותר מצוות הבדיקה. בדיקות אוטומטיות מייצרות דוחות משלהן בסוף התהליך, מה שנוטה להוביל לכך שכולם יהיו באותו פורמט.
בודקים אנושיים הם הרבה יותר גמישים ויכולים ליצור דוחות משלהם, ולהוסיף כל מידע שהם מחשיבים כמועיל לצוות הפיתוח בכל מקום שצריך.
4. הפעל מחדש אסטרטגיות
אסטרטגיות הפעלה מחדש מתייחסות לאופן שבו צוות בדיקות מריץ בדיקות שוב ושוב, אוסף נתונים ממקרים חוזרים של ביצוע המשימות.
בדיקה ידנית פירושה שאסטרטגיות הפעלה חוזרות הן הרבה יותר גמישות, כאשר בודקים יכולים להשלים יותר בדיקות אם הם חושבים שיש עוד משהו לחקור.
כמה בדיקות ידניות מעודדות באופן אקטיבי שונות בפעולות שמשתמש משלים, ומספקות נתונים ממגוון רחב יותר של התנהגות. זה מייצר יותר נתונים סביב התוכנה ומוביל לאסטרטגיות עדכון קוהרנטיות יותר קדימה.
סוגי בדיקות ידניות
ישנם שלושה סוגים שונים של בדיקות ידניות שחברות משתמשות בהן, כאשר ההבדל מוכתב על ידי רמת הגישה שיש לבודקים. כל סוג שימושי בהקשר הייחודי שלו.
הסוגים העיקריים של בדיקות ידניות כוללים:
1. בדיקת קופסה לבנה
בדיקת קופסה לבנה היא סוג של בדיקה הכוללת בודקים שיכולים לראות את כל קוד המקור ותיעוד העיצוב של תוכנה.
רמת גישה גבוהה יותר זו פירושה שהבודק מסוגל לראות את כל ההיבטים האישיים של הקוד וכיצד הם משפיעים על אופן פעולת התוכנה. זה אידיאלי לשלבים המוקדמים ביותר של תהליך הפיתוח, מכיוון שמפתחים יכולים להסתכל על הקוד שלהם באופן ידני, להשוות אותו עם מקרי בדיקה ולמצוא בקלות את האזור שגורם לבעיות משמעותיות כלשהן לפני תיקון של כל אחד מהבאגים הקיימים.
2. בדיקת קופסה שחורה
בדיקת קופסה שחורה מתייחסת לצורת בדיקה שבה הבודקים לא יכולים לראות שום דבר ממה שקורה מאחורי ממשק המשתמש. המשמעות היא שאין גישה לאף אחד מהקוד או לאף אחד מתיעוד העיצוב, כאשר בודקים ניגשים לתוכנה עם חוסר ידע מוחלט.
בודקים ידניים משתמשים בגישה זו בשלבים האחרונים של תהליך הפיתוח, שכן בדיקות קבלת המשתמש ובדיקות מקצה לקצה דורשות פרספקטיבה של משתמש קצה ולא של מישהו עם מעורבות כלשהי בתהליך הפיתוח.
3. בדיקת קופסה אפורה
בדיקת קופסה אפורה היא שילוב בין קופסה שחורה לבדיקת קופסה לבנה ודורשת בודק כדי לראות חלק מהתיעוד וקוד המקור. זה משלב את היתרון של היכולת לראות את הגורמים הפוטנציאליים לבעיות כלשהן, תוך הגבלת מידע, ומסייע בתכונות כגון טיפול בנתונים .
השתמש בבדיקת קופסה אפורה ידנית לאורך שלבי האמצע של תהליך הפיתוח, מספקים לבודקים מידע נוסף, אך עדיין גורם להם להסתמך על האינטואיציה שלהם עבור הרבה מהפונקציונליות כדי להבטיח שמשתמש קצה יוכל להבין את המערכות.
ניקוי בלבול מסוים – בדיקה ידנית לעומת בדיקות אוטומציה
ישנן שתי דיסציפלינות שונות המעורבות בבדיקות תוכנה, בדיקות ידניות ובדיקות אוטומציה. למרות שלשתיהן יש למעשה אותה פונקציה, הן דיסציפלינות נפרדות שחברות משתמשות בהן כדי לבחון את חבילות התוכנה שלהן.
המשך לקרוא למידע נוסף על מהי בדיקות אוטומציה, ההבדל בין בדיקות אוטומציה לבדיקות ידניות, ומתי להשתמש בכל אחד משני סוגי הבדיקות בתהליכי QA של התוכנה שלך.
1. מהי בדיקת אוטומציה?
בדיקת אוטומציה היא תהליך של בודק המשתמש בכלי של צד שלישי כדי להפוך תוכנה לאוטומטית, בוחן את התוכנה כשהיא משלימה שוב ושוב את אותו תהליך כדי להבטיח שהיא מתפקדת בסטנדרט גבוה מספיק עבור ארגון. היתרון העיקרי של אוטומציה של בדיקות הוא שזהו תהליך מהיר בהרבה, במיוחד בעת השלמת מטלות זנות כמו הזנת נתונים.
דוגמה לכך היא בדיקת מסד נתונים כדי לוודא שהוא מטפל בכל המידע כראוי, הזנת אלפי פיסות נתונים לתוכנה תוך מספר רגעים, והערכת התוצאות לאחר מכן.
חברות משתמשות בעיקר בבדיקות אוטומציה למשימות גדולות וחוזרות על עצמן. מכיוון שמערכת אוטומטית לא תעשה טעויות קלות, כגון הזנת פיסת מידע שגויה או לחיצה על הקישור הלא נכון.
חלק מחלקי התוכנה העיקריים שמשתמשים בכך הם שרתים חיים ומסדי נתונים, שכן אלו מטפלים במידע רב ובעומסי משתמשים גבוהים, ובכך דורשים סוג של בדיקה שיכולה להתאים לדרישות.
2. מה ההבדל בין בדיקות ידניות לבדיקות אוטומטיות?
ההבדל העיקרי בין בדיקות ידניות לאוטומטיות הוא שיטת ההשלמה.
בדיקה ידנית מסתמכת לחלוטין על בן אנוש כדי להשלים את הבדיקה, לעקוב אחר מקרה הבדיקה עד לסיומו ולאחר מכן לרשום מידע כלשהו.
עם בדיקות אוטומטיות, תוכנת מחשב אחראית להשלמת מקרי הבדיקה לאחר שנכתבו תחילה על ידי אנליסט QA.
חלק מפלטפורמות הבדיקה האוטומטיות גם מייצרות דוחות משלהן למשתמשים, ומגבילות את משך הזמן שמישהו צריך להשקיע באיסוף כל הנתונים מהניסוי. במקום זאת, הם יכולים להשקיע את זמנם ביצירת תיקון לבעיות שיש בחבילת התוכנה.
3. מסקנה: בדיקה ידנית לעומת בדיקה אוטומטית
ישנם כמה הבדלים מהותיים בין בדיקה ידנית ואוטומטית, כאשר שני המושגים מסתמכים על יסודות שונים לחלוטין כדי לעבוד כראוי.
עם זאת, הם יכולים לעבוד בצמוד להרבה פרויקטי פיתוח. על ידי שימוש בבדיקות אוטומטיות עבור כמה מהמשימות הכבדות יותר ויישום טכניקות בדיקה ידניות עבור אלה המסתמכות על גמישות רבה יותר, אתה יכול להאיץ את תהליכי הבדיקה שלך באופן משמעותי.
אחת התפיסות המוטעות הגדולות ביותר לגבי בדיקות היא שיש לך בחירה בינארית לעשות, אבל זה לא יכול להיות רחוק יותר מהאמת עבור כל צוות אבטחת איכות יעיל.
הפרת 5 מיתוסים של בדיקה ידנית
ישנם כמה מיתוסים שאנשים מאמינים סביב בדיקות ידניות, שכל אחד מהם מנחה אנשים ללכת לפי שיטות פחות אידיאליות והופך את קבלת התוצאות למסובכת יותר ממה שהיא צריכה להיות.
חמישה מיתוסים עיקריים סביב בדיקה ידנית כוללים:
1. בדיקות היא המחלקה היחידה האחראית על איכות המוצר
איכות המוצר היא התפקיד של החברה כולה, לא רק צוות אבטחת האיכות.
בדיקות תוכנה קיימות כדי להסיר באגים בכל מקום אפשרי, מה שאומר שהרבה אנשים רואים בתיקון ואיתור באגים באחריות הבלעדית של צוות QA. להיפך, המפתחים עצמם אחראים על כתיבת הקוד, בעוד שצוות הניהול אחראי על ארגון הפיתוח.
לכל אחד עם תפקיד בחברה יש אחריות כלשהי ליצירת מוצר ברמה גבוהה מספיק, במקום להסתמך על צוות בדיקות שימצא את כל הבעיות וישלח מוצר בהקדם האפשרי לאחר מכן.
2. בדיקה ידנית כבר לא משנה
עם עליית הבינה המלאכותית ואוטומציית תהליכים רובוטית נפוצה יותר ויותר, יש כאלה שמאמינים שבדיקות ידניות כבר לא חשובות בפיתוח תוכנה. חברות רואות את הזולות היחסית של אוטומציה ובוחרות ללכת בדרך זו בכל מקום אפשרי.
בדיקה ידנית נותרה אחד הכלים החשובים ביותר עבור חברה הודות לכלי הבדיקה E2E, הקופסה השחורה ו-GUI שלה. על ידי יישום בדיקות ידניות חברות מוצאות בעיות תוכנה שאחרת אוטומציה הייתה מחמיצה, ומשפרים את המוצר שלהן מעבר לכל רווח פוטנציאלי שהן יכולות לראות באמצעות אוטומציה בלבד.
3. זה מיועד לאנשים שלא יודעים לקודד
אחת ההנחות העיקריות שיש לחלק מהאנשים היא שאנשים שאינם יכולים לקודד בוחרים לבדוק במקום זאת.
עם זאת, זה רחוק מהאמת. אוריינות קוד היא חובה בהרבה תפקידי בדיקה, כאשר בדיקות קופסאות אפורות-לבן מסתמכות על קריאת קוד והבנה כיצד היא יכולה לתרום לבאגים שקיימים בחבילת התוכנה.
בהנחה שרק אנשים שאינם יודעים לקודד מעורבים בבדיקות, אתה עלול להגביל את עצמך לרמה נמוכה יותר של צוות בדיקות בצוות שלך. אם אתה בודק, שקול להשלים קורס קידוד כדי לשפר את הסטנדרטים שלך.
4. אתה יכול ליצור תוכנה נטולת באגים
יש אנשים שמגיעים לתעשיית הבדיקות הידניות מתוך הנחה שצוות אבטחת איכות יכול למצוא כל באג בתוכנה ולעזור לצוות הפיתוח לפתור אותו.
בתיאוריה, זה יוביל למוצר שאין בו באגים כלל ומספק את הלקוח לחלוטין. זוהי, כמובן, המטרה הסופית האידיאלית לבדיקות תוכנה, אך לעיתים רחוקות היא מתאפשרת.
אפילו חבילות התוכנה המכווננות ביותר של החברות הגדולות ביותר על פני כדור הארץ מגיעות עם באגים, ולמרות שהמטרה צריכה להיות לצמצם את מספר הבאגים ככל האפשר, אין נזק אמיתי בכמה בעיות קלות שמבצעות את המהדורה הסופית. בדיקה ופיתוח ידניים לאחר השחרור חשובים מסיבה זו.
5. אין שום ערך מוסף על ידי בדיקה
אחד המיתוסים הגדולים ביותר סביב כל צורה של בדיקות תוכנה הוא שזה לא מוסיף שום ערך לחבילת התוכנה. עם זאת, לקוחות תמיד מעריכים את האיכות כאחד ההיבטים החשובים ביותר של האפליקציה, כאשר תוכניות באגי או באיכות נמוכה מאבדות מיד את המשתמשים שלהם כשהם מחפשים חלופות.
מוצר מלוטש הרבה יותר יקר לחברה מאשר מוצר שאינו פועל כראוי, ובדיקות אפקטיביות עומדות בלב העבודה הזו. בדיקות ברמה גבוהה מובילות לתשואות משמעותיות כאשר חברות בוחרות להשקיע נכון.
בקצרה, אסטרטגיית בדיקות ידנית + אוטומציה היברידית תמיד תספק תוצאת בדיקה טובה יותר מאשר כל אחת מהאסטרטגיות הללו בשימוש בלעדי.
מה אתה צריך כדי להתחיל בדיקה ידנית?
יש כמה דברים שאתה צריך כדי להתחיל את תהליך הבדיקה הידנית, והיות שכל התכונות האלה זמינות לך הופכת את הבדיקה לא רק לקלה יותר אלא גם אפשרית מלכתחילה.
חלק מהדברים שאתה צריך כדי להתחיל בבדיקה ידנית כוללים:
1. התוכנה
הדבר הראשון שבודק דורש כדי להשלים בדיקות תוכנה הוא התוכנה עצמה. אחרי הכל, בדיקה ידנית היא למעשה בלתי אפשרית אם אין שום דבר זמין לבדיקה.
בדיקת תוכנה יעילה כוללת שימוש באיטרציה העדכנית ביותר של התוכנה, שכן יש בה את כל קוד המקור הרלוונטי לצרכי המשתמש ומהווה ייצוג הוגן יותר של המוצר כפי שהוא.
אם אפשר, הרכיב את האפליקציה רעננה לחלוטין כדי לקבל את התצוגה המדויקת ביותר של התוכנה.
2. דרישות תוכנה
לבודק צריכה להיות גישה לדרישות התוכנה. זה לא מתייחס לחומרה או למערכת ההפעלה שהחבילה צריכה, אלא לבריף של התוכנה שעליה עובד המפתח.
דרישות תוכנה מפורטות יותר בשלב הבדיקה פירושה שצוות ה-QA יחפש את כל התכונות החשובות מההתחלה, יציין היכן יש בעיות בתוכנה וממליץ על התאמות.
בלי זה, בודק עובד ללא כל הנחיה ואינו יודע אם המידע שהם מספקים אכן שימושי עבור צוות הפיתוח.
3. חומרה מתאימה
בדיקת תוכנה דורשת חומרה העונה על הצרכים של התוכנית שהיא מפעילה.
לדוגמה, אם בודק מחפש באגים או בעיות במשחק וידאו חדש שדורש חומרה מתקדמת ויש לו רק מחשב אישי ברמה נמוכה, הוא לא יוכל לבדוק את התוכנה כראוי.
זה פחות בעיה עבור אפליקציות קטנות או כלי אינטרנט. ודא שהחומרה שבה אתה משתמש תואמת את צרכי התוכנה לפני שתתחיל להשלים את הבדיקות, בחירת החומרה לאחר התייעצות עם צוות הפיתוח לגבי דרישות התוכנה.
תהליך בדיקה ידני
ישנם מספר שלבים שעליך לבצע כאשר עוברים את תהליך הבדיקה הידני, כאשר לכל אחד מהם יש חלק במתן מבט מדויק על התוכנית שלך.
שלבים אלה כוללים:
1. נתח דרישות
השלב הראשון בתהליך הבדיקה הידנית הוא ניתוח דרישות האפליקציה. זה כולל את הדרישות הספציפיות המפורטות בתקציר האפליקציה, חלק מהתכונות של מסמך העיצוב וכל חלק נוסף של התוכנית שאתה מצפה לראות (כגון דרישות משפטיות).
ניתוח אלה בתחילת התהליך אומר שאתה יודע מה אתה בודק בזמן שאתה בוחן את התוכנה.
2. צור תוכנית בדיקה
ברגע שאתה יודע מה צריך בדיקה, צור תוכנית בדיקה. זה כרוך לדעת אילו תכונות אתה בודק, איך בדיוק אתה בודק אותן, ומתי בתהליך אתה מסיים את הבדיקות הללו.
על ידי יצירת תוכנית בדיקה אתה מוודא שכל הבדיקות הנחוצות מוכנות מבעוד מועד ושלא תפספס שום תכונות בטעות.
זה גם עוזר לניהול כוח העבודה, מכיוון שאתה יודע כמה בודקים ידניים אתה צריך ומתי.
3. כתוב מקרי מבחן
התחל לכתוב כמה מקרי בדיקה עבור התוכנה. מקרה מבחן הוא קבוצה של אירועים שאתה משלים בעת בדיקת התוכנה, תוך מעקב אחר אלה בקפדנות בכל פעם כדי לוודא שמדובר בבדיקה הוגנת.
חשבו על הבדיקה הידנית הספציפית עליה אתם עובדים בכל מקרה וכלל פרטים רבים ככל האפשר, מכיוון שהדבר מקטין את הסיכוי שמישהו יחרוג מהתכנית המקורית.
4. סקור את המקרים שלך
לאחר כתיבת כל מקרי המבחן שלך, עברו תהליך בדיקה יסודי. זה כרוך במסירת מקרי הבדיקה לחבר מצוות ההנהלה, רצוי מנהל QA.
על ידי שיתוף של צד שלישי בתהליך ההגהה, אתה מגדיל את הסטנדרט של מקרי הבדיקה על ידי הסרת שגיאות שעלולות להיות קיימות. המנהל יכול להציע כל שיפורים שבסופו של דבר יהפכו את הבדיקה הידנית שלך ליעילה יותר ויעזרו לך למצוא בעיות באפליקציה.
ודא שכל מקרה בדיקה בודד מאומת לפני ביצוע הבדיקות.
5. בצע את הבדיקות הידניות
לאחר שמנהל מאשר מקרה מבחן, התחל לבצע את הבדיקות. עקוב אחריהם לפי הסדר שקבעת כבר בתחילת התהליך כדי לוודא שאתה מסיים כל מבחן ולוודא שאנשים מסיימים את המבחנים לאט ובזהירות.
ביצוע נכון של הבדיקות ב-100% מהזמן יחסוך לך הרבה זמן על ביצוע טעויות בביצועים מסוימים ועל הצורך לחזור ולוודא מחדש אם התוצאות מדויקות.
רשום מידע תוך כדי תנועה כדי להפחית את הסיכוי לשכוח מידע מפתח.
6. דווח על באגים
לאחר שתסיים את הבדיקות הידניות ותמצא באגים, השלם תהליך דיווח.
זה כרוך בכתיבת דוח לצוות הפיתוח המפרט את כל הבאגים, היכן מצאת אותם והצעדים שנקטת כדי ליצור אותם מחדש. כלול את כל הנתונים שאתה יוצר בבדיקה שלך.
במבחנים איכותיים יותר, דנו בפירוט בעיצוב האפליקציה, בכל בעיה שהייתה לכם וכמה תיקונים פוטנציאליים שהופכים את האפליקציה ליותר ידידותית למשתמש.
זכור שזה השלב שבו בדיקות ידניות באמת מצטיינות מול אוטומציה, שכן בודקים ידניים יכולים לספק מידע איכותי שלעתים קרובות אוטומציה לא יכולה.
שיטות עבודה מומלצות לבדיקה ידנית
שיטות עבודה מומלצות מתייחסות לכמה דברים הנפוצים בכל סוגי הבדיקות הידניות שעוזרות לשפר את הסטנדרט של תהליך בדיקה. ביצוע שיטות עבודה מומלצות אומר בסופו של דבר שאתה מוצא את עצמך עם מבחן באיכות גבוהה שיש לו תוצאות מדויקות ומהימנות.
כמה שיטות עבודה מומלצות שכדאי לזכור בעת ביצוע תהליך הבדיקה הידנית כוללות:
1. התמקד בבהירות
הדגשת הבהירות לאורך תהליך בדיקה ידנית היא חובה.
ברור ככל האפשר מפחית את האפשרות לתקשורת שגויה בין מחלקות ואנשי מקצוע, ועוזר לשמור על ריכוז אנשים בעבודה על האזורים הנכונים של התוכנה. זה חשוב במיוחד בבדיקה ידנית, שכן יש יותר מקום לפירוש הוראות.
זה כולל כתיבת מקרה מבחן ברור שהבודק יוכל לעקוב אחריו, רישום תוצאות בצורה פשוטה ומובנת, וסיוע לכל אחד בארגון להבין את דרישות האפליקציה.
2. השתמש בסקירה מתמשכת
סקור כל דבר בתהליך הבדיקה לעתים קרובות ככל שתוכל.
תהליך סקירה יעיל כולל תשומת לב לאופן שבו חברי הצוות פועלים, עיון במקרי בדיקה כדי לוודא שהם עדיין עובדים כפי שאתה מצפה, ובדיקת התוכנה עצמה כדי להבטיח שהתקדמות מתבצעת.
שמירה על עין אחת על האיכות של כל היבט בודד של התהליך מוודאת שהסטנדרטים לא יחליקו ושתקבלו רמת תפוקה גבוהה מספיק מההתחלה ועד הסוף.
3. אל תחפשו רק באגים
יש אנשים שחושבים שהמטרה העיקרית של בדיקות תוכנה היא למצוא באגים, אבל זה רחוק מלהיות המצב. התהליך כולל גם לוודא שהאפליקציה מתפקדת ברמה גבוהה, פועלת בצורה צפויה ונוחה למשתמש.
השימושיות הזו היא מוקד הליבה של בדיקות ידניות אחרי הכל, מכיוון שהיא כמעט “לא ניתנת לאוטומציה”.
אם אתה מוצא באגים כלשהם בעת מעקב אחר מקרה הבדיקה שלך, כלול אותם בדוח שלך, אך יציאה מגדרך כדי למצוא באגים שאינם רלוונטיים לבדיקה עלולה לבלבל את המפתחים ולשים את התהליך מאחורי מיקומו הצפוי.
סוגי פלטים מבדיקה ידנית
ישנם מספר סוגים שונים של פלט שתוכלו לקבל מבדיקה ידנית, כאשר כל אחד מהם מציע תובנה ייחודית לגבי ביצועי האפליקציה.
סוגי הפלטים שאתה יכול לקבל מבדיקות ידניות כוללים:
1. יומן ליקויים
יומן פגמים הוא רשימה או מסמך מלא של כל הבעיות שיש לתוכנה בבדיקה. ככל שיומן הפגמים ארוך יותר, כך יש יותר בעיות הדורשות תיקון בתוכנה.
אלה יכולים להיות אוטומטיים או כתובים ידנית על ידי בודק ידני, כאשר בודקים ידניים משלימים משימה זו בהיבטים איכותיים יותר של התוכנית, מכיוון שפלטפורמות אוטומציה אינן מסוגלות לגבש דעות על איכות תוכנה ופשוט ליצור מדדים.
2. נתונים איכותיים
הכוונה היא למשוב בעל פה ובכתב שבודק ידני מציג לצוות הפיתוח, בדרך כלל לאחר השלמת סדרת בדיקות כגון מבחן קבלת משתמשים.
UAT מתמקד בלהבטיח שהמשתמש הממוצע ייהנה מהתוכנה ויעסוק בה כצפוי, כלומר מיקוד שונה בהשוואה להיבטים כמו בדיקות תכונות.
נתונים איכותיים מגיעים בצורה של דיון עם המפתח או דוח כתוב ארוך.
3. הודעות שגיאה
הודעות שגיאה הן מחרוזות קצרות של טקסט המציינות האם אירעה שגיאה בחבילת תוכנה, ואם כן, מהות הבעיה.
רוב המפתחים כותבים מערכת יסודית שמתארת מהי בעיה ומדוע היא מתרחשת, תוך שימוש בקודי שגיאה כדי לצמצם את הבעיה. על ידי רישום הודעות שגיאה כלשהן בתוכנה, מפתח יודע מיד את הגורם לבעיה שנוצרה ומודע לצעדים אפשריים שיש לנקוט כדי לפתור אותה.
דוגמאות לבדיקות ידניות
ישנן מספר דוגמאות לבדיקות ידניות שכדאי לקחת בחשבון כאשר לומדים יותר על איך לעבור את תהליך הבדיקה הידנית. כל אחד מאלה הוא דיסציפלינת בדיקה ספציפית המתרחשת בנקודה מסוימת במחזור הפיתוח, ומציעה למפתחים יותר תובנה והדרכה כיצד לשפר את המוצר שלהם.
כמה דוגמאות לפורמטים של בדיקה ידנית כוללות:
1. בדיקת יחידות
בדיקת יחידות היא תהליך לוודא שכל יחידה בודדת בחבילת תוכנה פועלת כפי שניתן לצפות. יחידה, או מודול, מתייחסים לפונקציה בודדת המקודדת באופן עצמאי לפני הידור לחבילת תוכנה אחת גדולה יותר בסוף התהליך.
דוגמה לכך היא במסד נתונים, שבו מישהו עשוי לבדוק פונקציית “SORT” כדי לוודא שהיא מארגנת נתונים כראוי לפני שילובם בחבילה הרחבה יותר.
היתרון העיקרי של השלמת בדיקות יחידה הוא העובדה שאתה מבין שכל המערכות פועלות כהלכה בפני עצמן, כאשר כל בעיה שמתעוררת בשלבים מאוחרים יותר נובעת מהאופן שבו כל הפונקציות משתלבות זו בזו.
השלמת בדיקות אלו באופן ידני חשובה באותה מידה, מכיוון שהיא חוסכת זמן שיושקע בקידוד מקרי בדיקות אוטומציה מורכבים.
2. בדיקות מקצה לקצה
בדיקה מקצה לקצה היא תהליך של בדיקת אפליקציה שלמה, מהנקודה שבה אתה פותח את התוכנה לראשונה ועד להשלמת כל הפונקציות שבה.
דוגמה טובה לבדיקות מקצה לקצה היא אפליקציה לנייד שמחשבת כמה מס אתה מרוויח, שבה בודק מוריד את האפליקציה ועובר על כל הפונקציות כדי לקבל את החישוב הסופי. הבוחן מציין את כל הבעיות שהיו לו ומעביר אותן למפתחים.
מפתחים נהנים מכך שצורת בדיקה זו הושלמה בעיקר על ידי בודקים ידניים מכיוון שזו הזדמנות לראות כיצד כל יחידות התוכנה עובדות יחד, כאשר בדיקה בשלב מאוחר זו מבטיחה שהאפליקציה פועלת כראוי כאשר הכל ביחד.
בדיקות מקצה לקצה שונות מבדיקת קבלת משתמשים שכן מקצה לקצה הוא בעיקר תהליך פנימי, בניגוד לאופי הציבור החיצוני של תהליך בדיקת קבלת משתמשים.
3. בדיקת קבלת משתמשים
בדיקת קבלת משתמשים היא השלב האחרון בתהליך בדיקת התוכנה וכוללת לוודא שהמוצר מתאים לקהל הלקוחות המיועד של המוצר. זה כולל מתן גישה ללקוחות פוטנציאליים לאפליקציה כדי שיוכלו להשתמש בה ולספק משוב.
אחת הדוגמאות הנפוצות ביותר לבדיקות קבלת משתמשים בפיתוח תוכנה מודרנית היא זו של בדיקות אלפא וביטא של משחקי וידאו, שבה גיימרים זוכים לשחק במשחק ולדווח על כל בעיה שקיימת בו.
היתרון העיקרי של השלמת בדיקות קבלת משתמשים הוא שאתה מקבל פרספקטיבה חיצונית על המוצר שלך במקום להסתמך על נקודת המבט של אנשים שהיה להם תפקיד פעיל ביצירת המוצר, ומסיר כל פוטנציאל להטיה המשפיעה על הבדיקות. בדיקה ידנית היא הכרח מכיוון שמערכת אוטומציה אינה יכולה לשחזר במדויק את סנטימנט הלקוחות.
סוגי שגיאות ובאגים שזוהו באמצעות בדיקה ידנית שבדיקות אוטומטיות מחמיצות
בדיקה ידנית מוצאת כל מיני באגים, שגיאות ובעיות, וכך גם בדיקות אוטומטיות. עם זאת, יש כמה בעיות בתוכנה שבדיקה ידנית מצטיינת בגילוי היכן אוטומציה תחמיץ.
חלק מהסוגים העיקריים של שגיאות ובאגים בבדיקה ידנית כוללים:
1. זרימת עבודה לקויה
“זרימת עבודה” מתייחסת לנתיב שבו משתמש משתמש כדי להגיע לנקודה מסוימת באפליקציה ולהשלים תהליך. למרות שייתכן שאין שום דבר שגוי מבחינה טכנית בתהליכי עבודה מסוימים, הם עדיין עשויים להיות בעייתיים מכיוון שהנתיב עשוי להיות לא הגיוני להדיוט.
במקרים אלה, בודק ידני יודיע למפתח על הבעיות בעיצוב וימליץ על שינויים, ויעזור למשתמשים להיות נוחים יותר ולהכיר את האפליקציה באופן שמערכות אוטומטיות לא יבינו.
2. בעיות גרפיות
יישומי אינטרנט פועלים על מגוון מכשירים, עם רזולוציות וגדלים של צג משתנים ללא הרף בהתאם לטלפון, הטאבלט או המסך שיש למשתמש זמין.
באפליקציה שלא עברה אופטימיזציה, זה עלול להוביל לנכסים להימתח ולהיראות גרוע יותר במכשירים פחות נפוצים, כאשר כלי אוטומציה פשוט עוקבים אחר תפריטים ולא שמים לב לכך.
על ידי הטמעת מגוון מכשירים, בודקים ידניים יכולים למצוא פגמים גרפיים שכאשר הם מתוקנים, גורמים למשתמשים לחוות חוויה טובה יותר עם חבילת התוכנה.
3. קישורים לא מדויקים
כמה אתרים או יישומים מקושרים לאתרי מדיה חברתית באמצעות סדרה של לחצנים וקישורים משובצים. עם זאת, ייתכן שלא תמיד אלה יקשרו למקום הנכון כתוצאה משגיאת הקלדה או טעות בתהליך הפיתוח, וזה משהו שמערכת אוטומטית לא בהכרח תמצא.
קישורים המגיעים למקום הלא נכון עלולים לגרום לבלבול ולפגיעה משמעותית בשמירה. בודקים ידניים עוברים על כל הקישורים בתוכנית ומבטיחים שהם מובילים למקום הנכון, ועוזרים למשתמשי הקצה להגיע לאן שהם שואפים להגיע במקום להיות שולל על ידי בעיה.
מדדי בדיקה ידניים נפוצים
מדדים הם ערכים מספריים פשוטים ומדידים המעידים על משהו לאחר סיום מבחן. כל אלה הם כמותיים באופיים, מה שמקל על הערכתם מנקודת המבט של היזם.
כמה מדדי הבדיקה הידניים הנפוצים יותר שבהם משתמשים הבודקים כוללים:
1. פגמים
מדד הליקויים פשוט יחסית ומתייחס למספר השגיאות או הבאגים שיש בחבילת התוכנה. פגם הוא כל מקרה בו התוכנה אינה פועלת כמצופה, החל מפונקציונליות התוכנה ועד לאופן שבו הגרפיקה פועלת. ניתוח ליקויים כמדד הוא פשוט יחסית, כאשר יותר ליקויים הם בעיה גדולה יותר עבור החברה.
על ידי מעקב אחר האם מספר הפגמים גדל או יורד מאיטרציה לאיטרציה אתה יכול לקבל הבנה טובה יותר האם איכות התוכנה נעה בכיוון הנכון כשהיא ממשיכה לקבל עדכונים.
2. ליקויים לשעת בדיקה
פגמים לשעת בדיקה לוקחים את מדד הליקויים ומוסיפים עוד קצת פרטים, מחלקים את מספר הליקויים במספר השעות שהבודקים מבלים בתוכנה.
לדוגמה, כלי אינטרנט פשוט עם חמישה פגמים שלוקח שתי דקות לפעול ייראה טוב יותר מאשר כלי אינטרנט עם עשרה פגמים שבו אתה משתמש במשך שעה עם מדד הבסיס.
על ידי השלמת חישוב נוסף זה, בודקים ידניים מקבלים מושג טוב יותר על צפיפות הפגמים, מבינים באיזו תדירות משתמש צפוי להיתקל בפגם והאם זה משפיע באופן רציני על הזמן שלהם עם האפליקציה.
איזון פגמים מול גודל אפליקציה תמיד מועיל להקשר של הבעיות.
3. אחוז מקרי מבחן עבר
חלק ממקרי המבחן פועלים על בסיס עובר/נכשל פשוט, ומדד זה מספק אחוז ממקרי המבחן שעוברים. ככל שאחוז מקרי הבדיקה שעברו גבוה יותר, כך האפליקציה מתפקדת טוב יותר.
כאשר ניסיון אפשרי להשתמש באחוז מקרה המבחן שעבר על בסיס תכונה אחר תכונה ולא בעת בחינת האפליקציה כולה. זה מספק מידע מפורט יותר על מה עובד ומה לא, עוזר למפתחים לבצע שינויים בכל מקום בו הם נחוצים במקום להשלים חקירה נוספת כדי לראות בדיוק היכן הבעיה. ככל שתמצא מוקדם יותר את הסיבה לבעיה, כך ייטב.
7 טעויות ומלכודות ביישום בדיקות ידניות
ישנן מספר טעויות הנפוצות בכל תעשיית בדיקות התוכנה, שכל אחת מהן עלולה להוביל לאיתור באגים ובדיקות לארוך זמן רב מהצפוי בעלות גבוהה יותר.
כמה מהטעויות והמלכודות העיקריות שיש לשים לב אליהן ולהימנע מהן בעת יישום בדיקות ידניות בעבודה שלך כוללות:
1. תיקון הבאג בעצמך
בשלבים מסוימים של תהליך פיתוח, מפתח הוא אדם שאחראי הן לבדיקת הקוד והן לתיקון הבעיה. זה עלול להוביל לכך שהם ינסו לפתור את בעיות התוכנה בעצמם, למרות העובדה שהם אולי לא מבינים עד הסוף את הגורם לבעיה.
היכן שניתן, נסו לוודא שיש פיצול ברור בין הבוחן לבין האדם שמקודד את הפתרון. על ידי ביצוע ההבחנה הזו, אתה מפחית את הסיכוי להיות ממוקד מדי בתיקון השגיאה הספציפית שמצאת במקום להתייחס לשאר התוכנה.
הפיץ תמיד עבודה אם אפשר לקבל פיזור רחב יותר של מומחיות בנושא.
2. למהר במבחנים
לחלק מהתוכנות יש מועדים צפופים מאוד לשחרור, מה שעלול לגרום לבודקים להתמקד בלעבור את הבדיקות מהר יותר כדי להגיע לתאריך היעד. זוהי טעות חמורה, מכיוון שהיא מסכנת שבאגים משמעותיים יעברו. בדיקה ידנית יכולה להחמיר את הבעיה הזו, כאשר אנשים מרגישים את הלחץ וממהרים באופן פעיל דרך דברים.
נסו להקדיש זמן רב ככל האפשר בעת השלמת מקרי בדיקה, עברו בקפידה על כל שלב ורישום נתונים בצורה יסודית יותר. גם אם תצטרכו לדחות מעט את השחרור, עדיף לשלוח מוצר שלם מאשר כזה שהמשתמשים לא נהנים ממנו בגלל סטנדרטים גרועים.
3. תקשורת לקויה
תקשורת בתוך צוות היא חשיבות עליונה בכל פרויקט פיתוח תוכנה, כאשר אנשים מקבלים כמה שיותר תובנות מעמיתיהם לעבודה ומשתמשים במידע זה כדי לשפר את המוצר. זה חל על קיום שיחה מתמדת בין מחלקות וכן בתוך מחלקה בודדת.
ככל שצוות ה-QA מתקשר עם מפתחים בצורה יעילה יותר, כך יש להם הדרכה טובה יותר לגבי יצירת עדכונים, כאשר כולם נהנים ביחד מההוצאה של מוצר ברמה הגבוהה ביותר.
בדיקה ידנית מאפשרת תקשורת טובה יותר מכיוון שלבודק יש הבנה מלאה של החוויה, ומספקת יותר בהירות ופרטים.
4. בדיקה ללא הכנה
הכנה מולידה שלמות, וזה נכון בכל נוף בדיקות התוכנה. במקרה של בדיקה ידנית, זה אומר לקחת זמן להבין את התוכנה בנוסף ללימוד הבריף ויצירת מקרי בדיקה המאתגרים כראוי את כל המטרות הללו.
לקחת את הזמן שלך אומר שמקרי הבדיקה שלך מתאימים לצרכים שלך כמפתחים, ויש לך הרבה יותר סיכוי למצוא את כל הבאגים המשמעותיים ביותר במערכת. זה גם עוזר לבודקים לקרוא את מקרי הבדיקה בצורה ברורה יותר ולבצע אותם במידה רבה יותר של דיוק.
5. התעלמות מהאינסטינקטים שלך
כאשר חברה מתחילה לבדוק באופן ידני, היא עושה זאת מכמה סיבות, כולל העובדה שהם רוצים את יכולת ההסתגלות והאינסטינקטים של בודק אנושי. כאשר אתה בודק תוכנה, אתה עשוי להבחין שמשהו נראה מוזר למרות שאינו חלק באופן פעיל ממקרה בדיקה, מה שמנחה אותך לא לבצע שינויים או לחקור עוד. זו טעות.
תמיד לפנק את הסקרנות שלך ולהקשיב למה שהאינסטינקטים שלך אומרים לך, מכיוון שזה מסייע במציאת הבעיות שמקרה בדיקה אוטומטי לא יכול. בודקים ידניים נבחרים בשל האינטליגנציה והמומחיות שלהם, כך שפעולה על פי מאפיינים אלה מנצלת את הפוטנציאל של המבחן בצורה הטובה ביותר.
6. פחד מטעויות
כולם עושים טעויות, ללא קשר לעבודה שאתה משלים. עם זאת, עדיף להכיר בכך במקום להיכנס לתהליך מחשש לעובדה שאתה עלול לעשות שגיאה. זה גורם לך להיות יותר לחוץ ויש סיכוי גבוה יותר לגרום לבעיות בביצועי הבדיקות שלך. לאוטומציה אין בעיה זו, כאשר בודקים ידניים רגישים יותר ללחץ.
פנה למשימות שלך באופן טבעי ואם אתה עושה טעות, נסה לתקן אותה בהקדם האפשרי. בדיקת תוכנה היא השלב שבו אתה מגלה ומתקן בעיות, ובעיית בדיקה מדי פעם לא הולכת להרוס את התוכנה למשתמש הקצה כל עוד אתה מתקן אותה.
7. אי ביצוע הפסקות
בדיקה ידנית דורשת רמה גבוהה של תשומת לב לפרטים בכל בדיקה בודדת, מה שיכול להיות מעייף עבור בוחן. למרות זאת, חלק מהבודקים והחברות מתמקדים בשמירה על הבודקים לאורך כל היום ללא הפסקות נוספות לעייפות או ירידה בריכוז.
זו טעות משמעותית. ספק לצוות הבודקים הפסקות לאורך היום, מכיוון שהדבר מקטין את הסיכוי להתרחשות בעיות ושומר על הבדיקה מדויקת ככל האפשר. אם אתה בוחן בעצמך, נסה לעבוד עם צוות ההנהלה כדי לטפל באופן פעיל בבריאות הנפשית שלך ושל הסובבים אותך.
כלי הבדיקה הידניים הטובים ביותר
כאשר אתה מסיים בדיקה ידנית, אתה לא צריך להשלים כל חלק של העבודה לבד. במקרים מסוימים, שימוש בכלי יכול להיות מושלם לניהול הבדיקות שלך ולהפוך את התהליך לחלק ככל האפשר. אם אתה בודק שחושב על דרכים לשפר את הסטנדרטים שלך, התבוננות בכלים יכולה להיות ההתחלה האידיאלית.
5 כלי הבדיקה הידניים הטובים ביותר בחינם
כשאתה מתחיל עם כל כלי חדש בבדיקות תוכנה, אתה רוצה לוודא שאתה מקבל תמורה טובה להשקעה שלך. זה מתייחס לכמות הזמן שאתה משקיע בתוכנה ולכמות הכסף שאתה מוציא כדי לקבל את הרישיון.
עם כלי בדיקה ידניים בחינם, קבלת תמורה לכסף היא הרבה יותר פשוטה ואתה לא סובל מחרטה של הקונה אם זה לא מסתדר.
חלק מכלי הבדיקה הידניים הטובים ביותר הזמינים לצוותי אבטחת האיכות בחינם כוללים:
1. JIRA
JIRA הוא כלי תיעוד לבדיקות תוכנה המאפשר למפתחים ליצור כרטיסים לכל באג, בעיה או תיקונים הדורשים תמיכה. פלטפורמה זו מגיעה גם עם כלי תעדוף, כך שצוות פיתוח יכול לחפש קודם למיין את הנושאים החשובים ביותר בעת שיפור התוכנית שלו.
2. LoadRunner
תואם למגוון כלי פיתוח, LoadRunner מסייע בבדיקות ביצועים במגוון הגדרות, ומייצר נתוני בדיקות ביצועים בפירוט מורכב. הכלי גם עוזר לסווג כמה מהגורמים העיקריים לבעיות ביצועים עבור מפתח המעוניין להגביר את היעילות.
3. SonarQube
תומך במגוון רחב של שפות תכנות באמצעות עבודת בדיקה ידנית, מעקב אחר מדידות לאורך זמן כדי להפחית את כמות הדיווח שעל הבודקים הידניים להשלים בעצמם. בעל התאמה גבוהה ומשתלב ביעילות עם מגוון יישומי צד שלישי גדולים.
4. טראק
פותח ב-Python, Trac הוא כלי לניהול פרויקטים המספק לך את היסטוריית הצפיות, הקוד וכל השינויים שלך כדי לראות שינויים שבוצעו בין בדיקות. איתור באגים דרך Trac משתמש גם במערכת ניהול כרטיסים, מה שמפשט את התהליך של מציאת בעיה ותיקון שלה עבור משתמש.
5. יחידה
מבוסס על JUnit, NUnit הוא כלי קוד פתוח לחלוטין התומך בבדיקות מוכוונות נתונים ומשתלב ביעילות עם מגוון פלטפורמות. אתה ניגש לנתונים כמותיים גם לאחר השלמת בדיקות ידניות, מה שמספק תובנה רבה יותר למפתחים המעוניינים לתקן בעיות כלשהן.
5 כלי בדיקת האוטומציה הטובים ביותר בחינם
למרות שלבדיקות ידניות יש הרבה יתרונות, הטמעת אוטומציה בתהליכי הבדיקה שלך היא לפעמים דרך אידיאלית קדימה.
זה עוזר לך לבטל כמה מהחסרונות של התמקדות בלעדית בבדיקות ידניות תוך כדי קבלת סקירה טובה של התוכנה. אוטומציה דורשת כמה כלים כדי להתחיל, ומפתחים רבים מעדיפים להשתמש בכלים חינמיים כשהם מתחילים את עבודתם ומתחילים להתמודד עם הפלטפורמה.
חלק מכלי בדיקת האוטומציה הטובים ביותר הזמינים כוללים:
1. ZAPTEST FREE EDITION
ZAPTEST Free Edition נועדה לעזור לבודקים לשלב אוטומציה בעבודתם, תוך התמקדות בלהיות חוצה פלטפורמות ולגרום למשתמשים ליישם אוטומציה באופן התומך כראוי בבדיקות ידניות. אוטומציה של כל משימה היא המשיכה העיקרית, כאשר כל היבטי התוכנה ניתנים לאוטומטיות באמצעות המהדורה החינמית של ZAPTEST.
2. אפיום
מסגרת אוטומציה לבדיקות קוד פתוח, המתמקדת במיוחד באוטומציה של מכשירים ניידים עבור יישומים שעובדים בחנויות אינטרנט. Appium עובד עם מגוון ממשקי API ומערכות הפעלה כולל iOS , Windows , Mobile , Web , ו- Android .
3. פלטפורמת קטלון
פתרון ללא קוד, Katalon מסייעת לבודקים ללא ניסיון בקידוד כדי להשיג עבודת בדיקה אוטומטית טובה יותר. לפלטפורמה הזו יש חנות עם מגוון הרחבות, אבל זה אומר שכדי להפיק את המרב מתוכנת הבדיקה סביר להניח שתצטרך להשקיע זמן רב, ואולי גם כסף, בהתאמתה לצרכים שלך.
4. רובוטיום
כלי קוד פתוח המכוון במיוחד לבדיקות אנדרואיד תוך מתן אפשרות לקבל משתמשים ובדיקת קופסה אפורה. למרות שהאפליקציה הזו עובדת ברמה גבוהה, ישנם כמה סיכונים למשתמשים, מכיוון שאפליקציות חוצות-פלטפורמות עדיין ידרשו בדיקה בכל הפלטפורמות האחרות.
5. מעמיס
Loadster הוא כלי שנועד לעזור לחברות שעובדות עם אפליקציות שיש להן בסיסי משתמשים גדולים. השימוש בכלי זה עוזר למפתחים להתכונן לשיאים גדולים יותר בתעבורה ולקבל ביצועים אופטימליים גם עם לחץ משמעותי על שרתי החברה. בנוסף לעזרה בבדיקה ידנית, Loadster יכול להפוך חלק ממשימות של בודק לאוטומטיות כמו הנחת עומס .
סיכום
לסיכום, בדיקה ידנית היא נכס לכל ארגון. בודקים יכולים לגלות בעיות שלא נראו אחרת ולספק משוב מפורט על אפליקציה שאוטומציה פשוט לא יכולה.
למרות שיש כמה חסרונות לבדיקות ידניות, חברות אינטליגנטיות משתמשות יותר ויותר במערכת היברידית של בדיקות ידניות ואוטומטיות, ועוזרות לתת את הדעת על החולשות בכל אחת מהן תוך ניצול היתרונות של שתיהן.
בדיקה ידנית היא עמוד השדרה של פיתוח תוכנה טוב יותר ושימוש נכון בה עשוי לעשות הבדל גדול בתפוקה שלך.
שאלות נפוצות ומשאבים
בדיקה ידנית יכולה להיות נושא מסובך, אז מובן שאולי יש לך עוד כמה שאלות לגבי הדרך שבה זה עובד. ראה כמה שאלות נפוצות על בדיקה ידנית עם כמה משאבים שתוכל להפיק מהם תועלת כשאתה לומד להפוך לבוחן ידני טוב יותר עם הזמן.
1. הקורסים הטובים ביותר בנושא אוטומציה של בדיקות ידניות
· “יסודות אוטומציה לבדיקה” – Udemy
· “קורסי הכשרה לאוטומציה בדיקות” – NobleProg
· “הכשרת בדיקות ידניות – בריטניה” – האקדמיה לידע
· “בדיקות ידניות ואוטומציה” – IT Talent Hub
2. מהן 5 שאלות הראיון המובילות בנושא בדיקה ידנית?
· “יש לך ניסיון בבדיקות ידניות?” – קובע אם למועמד יש ניסיון רב בעבודה בסביבות בדיקה.
· “מה ההבדל בין בדיקה ידנית לאוטומציה של בדיקות?” – קובע אם למועמד יש ידע טכני בסיסי בתהליכי בדיקה.
· “איך התגברת על אתגרים בסביבת בדיקות תוכנה?” – מעריך את כישורי פתרון הבעיות שיש למועמד במרחב הבדיקות הידניות.
· “מהו הכלי האידיאלי לתמיכה בבדיקות ידניות?” – בונה מושג טוב יותר על זרימות העבודה בהן משתמש המועמד והאם זה מתאים לחברה.
· “האם נוח לך לעבוד בצוות?” – יידעו את המראיין האם המבקש מסוגל לעבוד בקבוצה גדולה יותר.
3. מדריכי YouTube הטובים ביותר על בדיקה ידנית
· “בדיקה ידנית (קורס מלא)” – SDET- QA Automation Techie
· “מדריך לבדיקת תוכנה – בדיקות תוכנה מאסטר ועבודת פיצוח בבדיקה” – מנטור בדיקות תוכנה
· “מהי בדיקה ידנית? | מדריך בדיקה ידנית למתחילים | אדורקה” – אדורקה!
· “קונספטים של בדיקה ידנית (פונקציונלית)” – Naveen AutomationLabs
· “הדרכות לבדיקה ידנית” – האקדמיה לבדיקות תוכנה
4. כיצד לשמור על בדיקות ידניות?
יש כמה דברים שאתה יכול לעשות כדי לשמור על בדיקות ידניות, הראשון שבהם הוא לטפל בבודקים. על ידי הצבת הרווחה במרכז תהליכי הבדיקה , אתה מוודא שכולם במצב כשיר לשים לב ולהתפקד בשיאם.
בנוסף לכך, התמקד בקיומם של מבני תמיכה טובים. משמעות הדבר היא פיקוח של מנהלים המוודאים שהבדיקות עקביות ומניבות תפוקות מדויקות בכל מקום אפשרי.
אין תחזוקה מכנית או אוטומטית קפדנית כשלעצמה, אבל טיפול באנשים הוא סוג של שמירה על הבדיקות שלך בפני עצמו.
