זה נושא למלחמות דת לא מעטות
אישית, אני מאוד מתחבר לגישה של Alan Page שמגדיר את תפקיד הבדיקות כמשהו שנועד להאיץ את תהליך הפיתוח (או, במילים שלו - Accelerate the achievement of shippable quality) -וכן, חשוב לשים לב שהוא אומר "בדיקות" ולא "בודקים".
אבל, זה נושא למתקדמים, ודורש אנשים עם לא מעט ניסיון, וגם ארגונים שבשלים למעבר כזה.
ארגונים ששוכרים בודקי תוכנה ייעודיים, בדרך כלל לא נמצאים במקום הזה (ולמעשה, מעט מאוד ארגונים נמצאים שם), אבל גם כאן, יש רמות בגרות שונות של ארגונים -
בארגונים הגרועים יותר, הכישורים שתידרשי להראות יהיו "לעשות מה שאומרים לך" - למלא דו"חות הרצה ולכתוב תוכניות בדיקות ברמת פירוט משתנה, לקבל פיצ'רים ולייצר מהם דיווחי באגים שטחיים.
כישורים רלוונטיים: הנכונות לקבל שכר נמוך, מוכנות לבצע את המשימות שלאף אחד אחר אין כוח לעשות, היכולת להוריד את הראש ולספוג הרבה שטויות מאנשים. (ורק למקרה שלא הייתי ברור - אני ממליץ בחום להימנע ממקומות כאלה).
 
בארגונים קצת יותר מתקדמים, תידרשי להבנה טובה של המערכת כדי שתוכלי לתרום גם במהלך תכנון המוצר ואיסוף הדרישות ולא רק "הנה פיצ'ר, תבדקי לי אותו"
כישורים נדרשים: הבנה טובה של מערכות ושל מערכות תוכנה בפרט. "למידה מהירה" (כלומר - היכולת ללמוד משהו בצורה שטחית ולהגיב, ואז מתוך התמונה הכללית הזו ללמוד את הפרטים) ויכולות תקשורת.
 
השלב הבא הוא שלב בו עבודה יחד עם המפתחים נפוצה - גם אם המשימות נפרדות, עדיין תבואו אחד לשני עם בקשות עזרה (וכן, אם את לא יודעת לקרוא קוד, עכשיו זה זמן לא רע להתחיל ללמוד - לא חייבים לדעת לתכנת, אבל חייבים לדעת לקרוא קוד).
כישורים נדרשים - היכרות עם "איך תוכנה עובדת", יכולת תקשורת אישית גבוהה, כישורי חניכה (כי גם כשאת מגיעה כבודקת תוכנה שעכשיו התחילה את הקריירה, את "מומחית הבדיקות" בצוות, אם אין בו בודקי תוכנה אחרים), ניהול סיכונים (או לפחות, לדעת לדבר בשפה הזו)
השלב האחרון הוא השלב בו אין בודקי תוכנה מתחילים, כי צוות הפיתוח מכיל את כל הידע הבסיסי הנדרש, והתועלת שלהם מבודקי תוכנה היא בהתמחויות ספציפיות (אבטחה, ביצועים, חווית משתמש) או ביכולת החניכה כדי לשמר את הרמה בצוות.