בדיקות תוכנה ממוכנות (מכונות לרוב "בדיקות אוטומטיות", באנגלית: "Test Automation") הן בדיקות תוכנה המבוצעות בדרך אוטומטית על ידי שימוש בתוכנת מחשב ייעודית (נפרדת מהתוכנה הנבדקת).

ניתן לממש בדיקות אוטומטיות כתחליף לתהליכי בדיקות ידניים, או בנוסף להן – עבור תרחישים שלאדם יהיה קשה מאוד (ולעיתים בלתי אפשרי) לבצע ללא מיכון.

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

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

אוטומציה של התהליך יכולה לפתור את הבעיות הללו מהסיבות הבאות:

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

ניתן לחלק בדיקות אוטומטיות לשני סוגים:

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

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

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

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

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

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

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

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

• אי תלות של פלטפורמות ומערכות הפעלה
• היכולת המונעת על ידי נתונים (קלט, פלט, נתוני-על)
• דיווח שניתן לאפיון (DB Access, ‏Crystal reports)
• ניפוי שגיאות ותיעוד יומן בצורה קלה
• שליטה ידידותית בגרסאות – קבצים בינאריים מינימליים
• בר הרחבה ובר התאמה (API חופשיים כדי שיהיה אפשר לשלב עם כלים אחרים)
• דרייבר נפוץ (לדוגמה IDE עבור JAVA). זה מאפשר ביצוע אינטגרציה בין בדיקות לזרימת העבודה של המפתחים.
• תמיכה בהרצת בדיקות לא-מטופלות לצורך אינטגרציה עם תהליכי build ואצווה. שרתים של אינטגרציה מתמשכת דורשים זאת.
• הודעות אימייל (הודעה אוטומטית במקרה של כישלון או השגת רף כלשהו). מריץ הבדיקות מבצע זאת.
• תמיכה בסביבת הרצה מחולקת.
• תמיכה באפליקציה מחולקת.

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

כלים מעוצבים באופן ייעודי לסביבת בדיקות מסוימת, כגון סוג מערכת ההפעלה וכלי אוטומציה וביים (אינטרנטיים), וכולי. כלים משמשים כ-driving agent^{[דרושה הבהרה]} עבור תהליך אוטומציה. אולם, מסגרת אוטומציה היא לא כלי לביצוע מטלה ספציפית, אלא תשתית שמספקת פתרון, היכן שכלים שונים יכולים לבצע את עבודתם בצורה אחודה. זה מספק פלטפורמה רווחת למהנדס האוטומציה.^{[דרושה הבהרה]}

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

1. בדיקות מונעות-נתונים
2. בדיקות מונעות-מודלוריות
3. בדיקות מונעות-מילות מפתח
4. בדיקות כלאיים
5. בדיקות מבוססות-מודל
6. בדיקות מונעות-קוד

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