Let's say we are part of an Agile team, running sprints to develop a software product where developers, testers, product owners and scrum masters are collaborating to deliver new features or functionalities in each sprint. One the classic discussions are around testing within sprint or testing after the sprint, but let's have a quick look to both approaches.
Testing within the sprint could mean that developers write Unit Tests and Code as first thing in the sprint and deliver the new code to QA Team some days before the sprint ends to let run testing plan and see if new code is bugs free.
In the other hand, testing after Sprint ends could mean developers are focused in write the new functions and features while running the sprint and the code is released to QA Team once sprint ends, letting developers to run a new sprint.
My thought came to my mind when running running sprints following the first approach (testing within sprint) developers were always delivering new features to QA Team with a very tight time to run the testing plan. We made the decision to run testing plan at the beginning of the next sprint, which means developers would prepare a new release ready to test when Sprint ends and move to the next Sprint. This helped to let the Developers understand the release ready to test should be under proper testing (developer testing) as they are the owners of the work delivered, letting QA Team to be focused on ensuring the software works as the Product Owner defined.
With QA is not testing we say Developers proceed with the testing of the new code written, following TDD they test their code runs properly and put in the output the expectations for the given inputs. With this Development Testing in place, he QA Team will run testing plan rounds being focused in the functionalities, ensuring the quality of the product meet expectations.
Of course this is not a must, each team should find their path at any moment and look always to the results to see if they should tune their current process, an specific approach could work for a particular moment developing a particular product with particular team members, a change in the equation could produce a change in the approach followed, just keep looking yourself to keep moving to the great success.
After read the article and thinking only about what would be best for the functionalities that are schedule for an sprint, there is no doubt about what's best for the software quality. Developers should follow TDD and this would let QA to focus as you explained.
How much time per sprint do you think the development of the test should take?
For the question above I know agilele methodologies are flexible and it will depend on the team but i would say it shouldn't take more than 20% of the sprint. What will you say?
After read the article and thinking only about what would be best for the functionalities that are schedule for an sprint, there is no doubt about what's best for the software quality. Developers should follow TDD and this would let QA to focus as you explained.
How much time per sprint do you think the development of the test should take?
For the question above I know agilele methodologies are flexible and it will depend on the team but i would say it shouldn't take more than 20% of the sprint. What will you say?