Agile testing is getting more and more practiced due to the increasing demands to software and web development and this causes many testing issues that still have to be dealt with as well.
One of such issues is that test-driven development widely experienced in terms of the traditional development approach cannot be applied in every project under conditions of modern agile development tendencies. Since many testers are still trying to implement TDD traits in agile environment, the article seeks to reveal why it is sometimes inconsistent.
With the increase of the project, the time spent for running tests increases accordingly. This issue may be addressed by means of partitioning the project, tests or one of them. Whatever option you choose, it will result in running tests at different frequencies based on the relevance to the coding effort at hand.
This approach poses the demand for planning tests and managing test execution. To achieve them efficiently, there are several testing types to think of besides white-box testing.
Here are some of them.
Integration testing is required to decide what tests to run in order to ensure that the new code seamlessly runs with the surrounding.
System testing is called to check if the functionality that is supported by new code corresponds to any functionality in the system or other systems in the flow of the process.
The main issue of regression testing is to find out how often you should run regression tests to make sure the new code hasn’t made some unforeseen impacts. Agile development techniques are affirmed by a safety net that automated regression testing offers.
TDD along with business users are to confirm that some specific function works correctly, but there is a risk that business users don’t accept the combined impact of changes. To address this issue user acceptance testing is performed.
However, you cannot take these stages a series of discrete activities in an agile environment. As we get some new piece of code, these tests often need to be performed in parallel. With increase of the project team, it’s getting harder to consider tests “self-documenting” as well. Once the participants’ number enlarges, they also tend to misinterpret the project’s risks and requirements. In the result the terms of the project success can be misunderstood either.
With increase of the project size the test code’s amount also needs development. Subsequently, developed test code needs application’s support for life doubling the current maintenance effort.
In the course of testing workload accumulation the need for adding test automation arises in order to minimize elapsed times and human intervention for each testing cycle.
Given these circumstances, it’s difficult to imply TDD to every agile project.