Software Testing in Agile Developmentsoftware development process is agile. It's the philosophy adhering to Agile Manifesto or its core principles. The agile manifesto does not say about any particular methodology or process which should be followed to be called as agile. Rather it's the definition or end goal of your process. It defines agile but doesn't say what or how to be agile.
So different organizations or individuals advocate different ways of agile development. In general it's an evolutionary approach of continuous, iterative and incremental integration of code where all the stake holders, i.e. Developer, QA and business (or customer) work very closely producing a very qualitative product in a short development life cycle.
One of the most popular agile methodologies is Test Driven Development (TDD). In TDD greater importance is given to white box testing than black box testing (in my personal opinion both white box and black box is equally important to certify the quality of the product), but don't confuse white box testing with unit testing. In Whitebox testing tests precede the development, a test approach and test case is developed before the development starts. Unit testing and white box testing are as different as apple and orange even though both deals with internal code and logic of the software.
Unit testing is done by developer whereas white testing should be done by QA. A unit test can be white box or black box as well. Unit test is focused on a single piece of code or a function but white box looks into the whole logic or flow of the software. Unit test cases or scripts can be a good reference for preparing the white box test plan but not the other way a round. At last but not the least unit testing is bottom up approach and white box is top down.
In Agile, normally the development life cycle is very short. So it's not always advisable for QA to test the software at the very end of development life cycle. Also for incremental integration to happen successfully the code should be tested thoroughly and just unit testing does not suffice for this purpose. Different white box techniques can be considered at this stage ,which are method coverage, branch coverage, statement coverage, condition coverage etc.
The names it self are self explanatory, the tester need to develop a script which covers the specific piece of code and validates what percentage of the branches or conditional expressions or statements its covers. If the software involves a set of APIs, those should also be included as part of white box testing. Even code review is also considered as static white box testing and helps in preventing some of the common errors like memory leakage, stack over flow etc before the system testing starts.
Then at the end of the development, the right approach should be a combination of white box and black box testing or in other words grey box testing. Both white box and black box techniques have their own advantages and disadvantages. Black box technique validates the breadth where as white box the depth of the code. Cost and effort wise black box testing has the obvious advantage. But the hybrid approach compliments each other and gives the best result.
Black box testing confirms to the customer requirement from end user point of view. White box testing confirms a robust and efficient code and logic. The usual white box techniques used to ensure code quality are basic path or independent path testing, data flow analysis, code coverage etc.
In agile project schedule is always very tight and teams have to deliver the working product at the earliest. The agile principle welcomes requirement change even at the later stage of development.
So testing in limited time is most important to provide a risk based quantitative feedback on the quality of the product so the customer/product manager can take an informed decision on its release. Hence the project team should focus on automating the white box scripts as much as possible for optimum utilization of resources and time.