در توسعه اجایل، تست در سراسر چرخه توسعه یکپارچه است، شما باید نرم افزار را در طول توسعه، تست کنید.

توسعه اجایل، چیزی به عنوان مرحله تست جداگانه ندارد. توسعه دهندگان، بیشتر درگیر تست کردن هستند، آنها آزمون تست خودکار را می نویسند تا با استفاده از آن کد خود را تست کنند.

تست کردن جدا از اینکه موجب بهتر شدن کیفیت نرم افزار می شود، همچنین مهم است که از اصل های کوچک، تکراری و افزایشی حمایت کنند.

با تست های خودکار، تست به عنوان بخشی از ساخت نرم افزار انجام می شود، و تضمین می کند هر بار که ساختار نرم افزار تولید می شود تمام ویژگی های آن به درستی کار می کنند، و این تولید ساختار باید به طور منظم روزانه انجام شود، حداقل روزانه. بنابراین همان طور که توسعه پیش می رود یکپارچه سازی انجام می شود.

هدف این اصول اجایل این است که توسعه نرم افزار را در شرایط معقولی حفظ کند، بنابراین هر وقت که نرم افزار مناسب باشد، می تواند منتشر شود.

XP (Extreme Programming) ، یکی از روش های اجایل، بیشتر پیشروی کرده است. XP، توسعه آزمون محور را توصیه می کند، به این صورت که قبل از نوشتن نرم افزار، تست ها را بنویسند.

اما در طول توسعه نرم افزار، تست کردن نباید فقط توسط توسعه دهندگان ، انجام شود. هنوز هم برای تست کننده های حرفه ای نقش مهمی وجود دارد. همان طور که همه ما می دانیم " توسعه دهندگان نمی توانند آب نبات تست کنند! ":)   

نقش یک تست کننده می تواند به طور قابل توجهی، در توسعه اجایل تغییر  یابد، می تواند نقشی بسیار شبیه به تضمین کننده کیفیت داشته باشد نه صرفا تست. تست کننده هایی که از ابتدا حضور داشتند مزایای قابل توجهی برایشان وجود دارد.

این بیشتر با رویکرد lightweight نیازمندی ها در توسعه اجایل ترکیب شده است، و تایید بر گفتگو و همکاری در تشخیص نیازمندی ها، بیشتر از رویکرد سنتی مشخصات و اسناد و مدارک می باشد.

اگر چه نیازمندی ها می تواند در برخی از جزئیات توسعه نرم افزار مشخص شود ( تا زمانی که به موقع انجام شوند) کاملا ممکن است که این کار منجر به برخی ابهامات یا موارد دیگر شود، جایی که دیگر تمام اعضای تیم درک یکسانی از نیازمندی ها نداشته باشند.

بنابراین، این موضوع برای یک تست کننده اجایل، چه معنی می دهد؟ یکی از نگرانی های مشترک تست کننده ها به رویکرد توسعه اجایل انتقال می یابد، مخصوصا از کسانی که از محیط خیلی رسمی انتقال می یابند، اینجاست که آنها واقعا نمی دانند دقیقا برای چه چیزی تست می کنند. آنها شرح دقیق کار را برای تست کردن ندارند، پس چگونه آنها می توانند آن را تست کنند؟

حتی در یک محیط توسعه سنتی، من همیشه بیان می کنم که تست کننده ها می توانند نرم افزار را در دارا بودن شرح دقیق کار تست کنند، و در عین حال محصول می تواند کیفیت ضعیفی داشته باشد. شاید به این دلیل است که نیازمندی ها کاملا مشخص نشده اند یا اینکه به طور واضح نوشته شده اند اما در وهله اول ایده بسیار خوبی به نظر نمی رسیده. شرح دقیق کار لزوما باعث خوب بودن یک محصول نمی شود.

در توسعه اجایل، یک باور وجود دارد که گاهی اوقات، وحتی شاید اغلب اوقات، این موارد فقط زمانی کامل آشکار می شوند که نرم افزار راه اندازی شود. با ارائه نسخه های کوچک افزایشی و با اندازه گیری پیشرفت فقط از طریق کار کردن با نرم افزار، نتیجه تست نرم افزار را می بینید و تنها آن زمان شما واقعا می توانید با اطمینان قضاوت کنید که آیا نرم افزار کیفیت خوبی دارد یا خیر.

تست اجایل، از یک تست کننده قضاوت های بیشتری می خواهد، استفاده از تجربه و تخصص بیشتر در مورد اینکه چه چیزی خوب و چه چیزی بد است، توانایی انعطاف پذیری بیشتر و داشتن اعتماد به نفس بیشتر برای به کار گیری بیشتر دانش خود در آنچه به نظر می رسد خوب است. این قطعا تنها یک مورد پیگیری متن تست نیست، مطمئن شوید نرم افزار آنچه که در شرح دقیق کار گفته شده است را انجام می دهد.

و به این دلیل تست اجایل برای آدمک ها نیست.