Scrum & Testing
There are a two schools of thought on scrum and how testing fits into the process.
There's one school that says because of the short timeframes in scrum, testing should be done by a separate team as a separate sprint. In other words, develop in one sprint and do some "nominal testing" and hand the product over to the test team for them to test through in their own sprint.
This is great - if you want to make your scrum process act like the waterfall process. In fact you could split your scrum teams into single discipline teams. Have one scrum for design, one for development, one for testing, one for writing documentation, etc. It could certainly give people the impression that you were running an agile process, whereas in reality it would just be waterfall in sheep's clothing.
At the end of each sprint teams are meant to deliver a potentially shippable version of the product. How can something be shippable if it hasn't been tested, let alone had the bugs fixed?
I obviously subscribe to the second school of thought where testing is an integral part of the development process and it is up to the team to ensure that all testing is done. For this reason I ensure that my teams have at least one BA, one developer and one tester. This does not imply that the tester is solely responsible for the testing; the team is. It does imply that a delivered piece of software has been designed, coded and tested.
It's tempting to follow the first school of thought and separate testing from coding, but this is a slippery slope to step on. It removes the responsibility for delivering working code from the developers (they can rely on the testers to test it later and get it back if it's wrong), code can be stuck in a loop between devs & testers for an unknown number of cycles, and you could potentially ship code that is untested and broken.
Keep testing and coding together - the team is responsible for delivering quality code first time, on time.
There's one school that says because of the short timeframes in scrum, testing should be done by a separate team as a separate sprint. In other words, develop in one sprint and do some "nominal testing" and hand the product over to the test team for them to test through in their own sprint.
This is great - if you want to make your scrum process act like the waterfall process. In fact you could split your scrum teams into single discipline teams. Have one scrum for design, one for development, one for testing, one for writing documentation, etc. It could certainly give people the impression that you were running an agile process, whereas in reality it would just be waterfall in sheep's clothing.
At the end of each sprint teams are meant to deliver a potentially shippable version of the product. How can something be shippable if it hasn't been tested, let alone had the bugs fixed?
I obviously subscribe to the second school of thought where testing is an integral part of the development process and it is up to the team to ensure that all testing is done. For this reason I ensure that my teams have at least one BA, one developer and one tester. This does not imply that the tester is solely responsible for the testing; the team is. It does imply that a delivered piece of software has been designed, coded and tested.
It's tempting to follow the first school of thought and separate testing from coding, but this is a slippery slope to step on. It removes the responsibility for delivering working code from the developers (they can rely on the testers to test it later and get it back if it's wrong), code can be stuck in a loop between devs & testers for an unknown number of cycles, and you could potentially ship code that is untested and broken.
Keep testing and coding together - the team is responsible for delivering quality code first time, on time.