When we are talking about traditional testing, we are talking about the V-model which is used in waterfall projects. We do requirement engineering, we write down features for our software, then we break them down and then write stories which are then given to the developer to implement this story. The developer then codifies this and then writes unite tests and integration tests.
When he is done, he gives the story to testers who test it. After all the tests have been developed then the features are tested.
The problem with this traditional approach is that there is delayed feedback. After writing the features, it takes 3 months or more until we get feedback.
In agile testing, we shift the whole testing left. We use BDD (behaviour driven development) for defining the acceptance criteria when we are writing a feature. We break down the feature into user stories where again the acceptance criteria are written using BDD. By doing this we get executable specifications. The developer can then first use the tests specified as acceptance criteria in the user story before he/she starts implementing the functionality.
This way we have tests on the story and feature level from the beginning. In our continuous delivery pipeline, we can execute the tests which assure developers that nothing has beens broken. This leads to a faster time to market.