Testing in Scrum

This is never a new topic. Probably it is one of most discussed topics in Scrum community. But according to our practices we have to highlight it again.

In Scrum training, when the team members were asked what would be definition of done in a sprint most of the members would say all test tasks tasks if they have enough resources and time. But in contrast, in the practices, people would talk a lot of impediments of doing performance test, regression test, exploratory test bala bala. If the team were asked further what the impediments preventing they get these test activities done would be. They may talk about tight schedule, no automation test tools, less competences ... if you ask the team did you guys speak it out in the sprint planning meeting, you probably could hear a short silence.

Something are missing in such Scrum teams.

A classical test team (in waterfall world) were asked to test something they never have a thumb on software design and coding rather focus and limited in "testing" with a delivery from developers. In Scrum, there is no boundary between design/code and test so the test engineers are often get confused and lost. As a member of Scrum team, a test engineer suppose to be having more competences in test activities than others and she/he supposed could evaluate the item of a product backlog with his/her professionalism and experiences (in test). For instance, in the first sprint if the team could not complete the regression test or performance within the sprint if the PO or team thought it was necessary somebody (especially test engineer) should point it out during the review and increase the estimated size of similar items in the product backlog reasonably.

The situation would get worse when there were a "system test team", so called, along with Scrum teams. In most case I met, the Scrum teams there will have a couple of "agile testers" who would do sort of verification of new features committed by the team. The system level testing, performance, exploratory test will be done in "system test team". But unfortunately, most of "system test team" do not follow Scrum and have no influences in the Scrum teams' planning. On one hand, "system test team" do not give their commitments (since they were asked to test the releases from the Scrum team with no idea how many efforts need to complete all test of the commitments made by the Scrum team), on the other hand, the Scrum teams do not count the efforts of the "system teat team" when they make commitments. The predictable results would be have a long "stabilization" sprint and bug explosion within that sprint. Finally the teams have to release buggy software.

I'll discuss about how to avoid this later...