חברות תוכנה ענקיות, כמו גוגל, מצליחות למרות באגים בעדיפות נמוכה בתוכנה שלהם, אבל חברות קטנות יותר ו startups אין את זה מותרות.
לקוחות מצפים למוצרים לעשות את מה שהם טוענים בדף המכירה, או בתיעוד. עם כל כך הרבה אפשרויות שם בחוץ, הם לא יחשבו פעמיים על קפיצה הספינה אם המוצר מבזבז את זמנם וכסף. לכן, התוכנה עוברת בדיקות קפדניות לפני השחרור על מנת:
להבליט הבדלים בין המושג המקורי לבין התפוקה הסופית
לוודא את התוכנה עובדת בדרך המתכננים מתוכנן
לאמת את המוצר הסופי - המוצר חייב לעמוד בדרישות הלקוח
להעריך תכונות ואיכות
בדיקה עוקבת אחר תכנית קפדנית. זה מייעל את השימוש במשאבים יקרי ערך - מיומנויות, זמן וכסף, תוך מתן מידע לבעלי העניין עם מידע חיוני כדי לקחת את המוצר קדימה. המטרה היא להקל על חוויית משתמש קצה טובה באמצעות תוכנית אבטחת איכות חזקה. עם ההימור גבוה כל כך, מנהלי QA הם חלק מן המפרנסים הגבוהים טק. בדיקה בדרך כלל בצעדים הבאים:
ניתוח הדרישה שבו מנהלים המתווה תוכנית לשים אסטרטגיית הבדיקה המתאימה במקום.
בדיקות להתחיל ותוצאות לעבור ניתוח.
כל פגמים מתוקנים, והתוכנה עוברת בדיקות רגרסיה - מערכת לבדיקת התוכנית עדיין עובדת לאחר שינויים.
דוח סגירת הבדיקה מפרט את התהליך כולו ואת התוצאות.
שיטות בדיקות תוכנה
הנה השיטות השונות המשמשות לשפוט התנהגות המוצר והביצועים.
תיבת שחור בדיקות קופסה לבנה הן שתי שיטות בסיסיות.
- בדיקות קופסה שחורה - המכונה גם בדיקה פונקציונלית או מפרט מבוסס, שיטה זו מתמקדת פלט. הבוחנים אינם עוסקים במנגנונים הפנימיים. הם רק לבדוק את התוכנה עושה מה שהיא אמורה לעשות. הידע של קידוד אינו הכרחי, בודקים לעבוד ברמת ממשק המשתמש.
- בדיקות קופסה לבנה - שיטה זו משתמשת בקידוד ידע כחלק מהליך הבדיקה. כאשר מוצר נכשל, בודקי ללכת עמוק לתוך הקוד לפי הצורך כדי למצוא את הסיבה. מפתחי התוכנה לעשות זאת בעצמם מאז הם קובעים כיצד המוצר צריך לעבוד. מבנה מבוסס זכוכית בדיקות זכוכית הם שמות אחרים עבור שיטה זו.
- בדיקות סטטיות - בודקים בודקים את קוד התוכנה ואת התיעוד אך אינם מבצעים את התוכנית. בדיקות סטטיות מתחילות בשלב מוקדם בפיתוח המוצר במהלך תהליך האימות.
- בדיקות דינמיות - התוכנה מבוצעת עם תשומות שונות, והבוחנים משווים את הפלט עם ההתנהגות הצפויה בשיטה זו.
- בדיקה GUI - זה בודק תכונות GUI - עיצוב טקסט, תיבות טקסט, לחצנים, רשימות, פריסה, צבעים, גופנים, גדלי גופנים, וכן הלאה. בדיקות GUI הוא זמן רב, וחברות צד שלישי לעיתים קרובות לקחת על עצמו את המשימה במקום מפתחים.
רמות הבדיקה
אלה נחוצים כדי לזהות תחומים של חולשה חפיפה בכל שלב של מחזור החיים בפיתוח תוכנה.
- בדיקות יחידה - מפתחים בודקים את החלקים הבסיסיים ביותר של קוד כמו מחלקות, ממשקים ופונקציות / פרוצדורות. הם יודעים איך הקוד שלהם צריך להגיב יכול לבצע התאמות בהתאם פלט.
- בדיקות רכיבים - שמות אחרים הם מודולים או בדיקות תוכנה. הדבר דומה לבדיקת יחידה, אך מכיל רמה גבוהה יותר של אינטגרציה. מודולים של התוכנה נבדקים עבור פגמים כדי לאמת את הפונקציה האישית שלהם.
- בדיקות שילוב - זה מזהה שגיאות כאשר מודולים משולבים. בדיקות אינטגרציה שונות הן מלמטה למעלה, למעלה ולמטה פונקציונלי.
- בדיקות מערכת - רכיבי הפרויקט נבדקים בכללותם בסביבות שונות בשיטה זו. הוא נופל תחת שיטת הקופסא השחורה והוא אחד המבחנים הסופיים בתהליך. היא קובעת אם המערכת פועלת כפי שהיא צריכה לענות על הצרכים העסקיים והמשתמשים.
- בדיקות אלפא - צוות פנימי בודק את התוכנה באתר היזם בסביבה מדומה או בפועל. לאחר מכן, מפתחים לתקן באגים ובעיות אחרות.
- בדיקות ביתא - המכונה בדיקות שדה, כמו גם, הלקוח בודק את המוצר באתר שלהם בתנאים אמיתיים. הלקוח עשוי להציע לקבוצה של משתמשי קצה את ההזדמנות לבדוק את התוכנה באמצעות גרסאות קדם-קדם או גירסאות ביטא. משוב על שיפורים אפשריים נשלח אל היזם.
- בדיקות קבלה - גם תחת היקף בדיקות קופסה שחורה, הלקוח בודק תוכנה כדי לברר אם היזם יצר את התוכנית לפי המפרט הרצוי.
סוגי בדיקה
בדיקות תוכנה אלה מתמקדות ביעדים ספציפיים.
- בדיקות התקנה - מהנדס בדיקות התוכנה ומנהל התצורה מבצעים בדיקה זו כדי להבטיח שהמשתמש הסופי יוכל להתקין ולהפעיל את התוכנית. הוא מכסה אזורים כמו קובצי התקנה, מיקומי התקנה וזכויות ניהול.
- בדיקות פיתוח - זה מיישם מגוון של אסטרטגיות מסונכרנות כדי לזהות ולמנוע פגמים. הוא כולל ניתוח קוד סטטי, סקירת קוד עמית, ניתוח עקיבות וערכים. המטרה היא לצמצם סיכונים ולחסוך בעלויות.
- בדיקות שמישות - חוויית המשתמש נמצאת תחת הזרקור במבחן זה. זה מודד כמה טוב GUI נועד וקלות השימוש. הבדיקה בודקת דיוק ויעילות של פונקציות ותגובות רגשיות של נבדקים הבדיקה.
- בדיקות שפיות - זה מציין אם התוכנה שווה את הזמן ועלות להמשיך בדיקות נוספות. יותר מדי פגמים ומבחנים אגרסיביים יותר אינם פועלים.
- בדיקות עשן - בדיקות עשן חושף כשלים בסיסיים כי הם רציניים מספיק כדי למנוע שחרור. כאשר זה מתבצע על לבנות חדש, זה נקרא מבחן אימות לבנות.
- בדיקות רגרסיה - כאשר המערכת עוברת שינוי, בדיקות רגרסיה עוקבות אחר התנהגות בלתי צפויה. זה מצביע על השפעות שליליות על מודולים או רכיבים.
- בדיקות הרסניות - בוחנים קלט ערכים חריגים ולבחון את היכולת של התוכנה לנהל קלט בלתי צפוי. זה מראה למפתחים כמה חזק התוכנית היא על ניהול השגיאה.
- בדיקות שחזור - כאשר חומרה או פונקציות אחרות נכשלים, בדיקה זו מראה עד כמה התוכנה יכולה לשחזר ולהמשיך בפעולה.
- בדיקה אוטומטית - פעולה זו מבצעת פעולות לביצוע באופן ידני. היא משתמשת בתוכנה ספציפית כדי להפעיל את הבדיקות ולספק נתונים על התוצאות בפועל לעומת הצפוי.
- בדיקות תאימות - התוכנה חייבת לפעול בסביבות מיחשוב שונות, ולכן זה בודק תאימות למערכות שונות. לדוגמה, האם התוכנה פועלת עם מערכות הפעלה ודפדפני אינטרנט שונים?
- בדיקות ביצועים - זהו מבחן מעמיק הבוחן את ביצועי התוכנה בתרחישים שונים. מידע על היענות, יציבות, הקצאת משאבים ומהירות נאסף. יתר על כן, בדיקות משנה כגון נפח, קיבולת, בדיקות ספייק לשחק חלק בתהליך זה.
- בדיקות אבטחה - מודד את יכולת התוכנה להגן על אבטחת המשתמשים. משמעות הדבר היא פונקציות אישור, אימות, סודיות, יושרה, זמינות, ולא דחייה.
- בדיקות נגישות - זה לא אותו דבר כמו בדיקות שמישות. זה קובע את המידה שבה משתמשים ביכולות שונות - למידה ונכויות פיזיות כלולות, יכולים להשתמש בתוכנה.
- בינאום ובדיקת לוקליזציה - התוצאות מראות כיצד התוכנה יכולה להסתגל לשפות שונות ולדרישות אזוריות. זה כולל הוספת רכיבים עבור מיקומים ספציפיים ותרגום טקסט.
בדיקות תוכנה היא חלק חיוני של הבאת המוצר לשוק. ובלי בודקים, מגוון רחב של תוכנות זמינות לא היה קיים. להיות בודק תוכנה מוסמך באמצעות ארגונים כגון BCS, המכון Chartered עבור IT, ISTQB ® (International Software Testing Qualifications Board), ו ASQ (לשעבר האגודה האמריקנית לאיכות).