How to finish the testing in the same iteration/sprint?

Question

I am aware of the fact that agile testing is an ongoing process and should happen in parallel to development. But how is that actually achieved? Is it even possible to fix all found issues in the same sprint?

Current project status: The company uses Scrum several years now, so everyone is familiar with that. However, we haven't had dedicated testers yet, as the intent was to have self-organizing teams, where everybody is responsible for everything. Well, that did not work as expected ;) So, each team will get one dedicated tester.

My plan is to integrate the tester at the very beginning of the sprint (2 weeks): estimation, sprint planning meetings etc.

To prevent defects, Acceptance Criteria will be refined by the Three Amigos (Tester, Developer, Product Owner) into thin slices/steel threads. Thereby it should be possible for the Testers to verify functionality asap while the developers can go on with the development of the next slice. Level of automation for each slice will be defined together.

Still, I think testers should be able to go through the user stories manually and create bigger Test Cases or do Exploratory Testing in the same sprint. If that is done at the very end, how is it possible to fix defects in the same sprint; maybe it is not that important?

Would be very interesting how it works for you guys (Sprint length, type of Testing, the responsibility of the Testers etc.)

Answer 1

Achieving testing within a Sprint is mandatory for almost all teams. I cannot imagine a definition of done that would not include a requirement that work is tested.

Ensuring that you have minimum Work In Progress (WIP) will help to ensure that you can meet the requirement of fully testing completed work. That is, finish one Product Backlog Item (PBI) completely, including testing, before moving on to the next PBI. Also, even though you have a team member that specialises in testing, it is still a Scrum Team responsibility to ensure that all of the necessary work is "done". Don't load that responsibility on to the dedicated tester.

I'm intrigued as to why the Scrum Team were not able to test the work themselves and required dedicated testers? Also, are your dedicated testers able to write automated regression tests? (In my experience, these are often a mandatory requirement for Scrum Teams and are often written by software developers because the testers don't have the skill.)

Hope that helps.

Answer 2

I wrote something recently that might help you out concerning using QA resources in an agile team.

In essence, what you need to do is allow for your team to provide continuous feedback by making sure development is able to be continuously integrated and deployed to an environment where QA can run their test cases. You may have heard of a "Daily Build" site, and this process allows for QA to test during the iteration.

In fact, on our teams, we won't recognize the work is Done in an iteration unless it has been tested and all acceptance criteria have passed, whether that be via unit tests or a dedicated QA resource.

Answer 3

There are several factors that allow our testers to manually test effectively during a sprint cycle:

• Small, functionally testable stories
• Build/deployment automation: to me, this is the most important, builds need to be automated tested and deployed quickly if they are going to be manually tested quickly.
• Test automation: automating the checks supply fast feedback, so testers can explore.
• Great teamwork/estimations.
• Great testers.

We have 30+ teams with manual testing being done in two-week cycles and we have found team members focused on testing improve the overall quality of the product.

Answer 4

I think testers should be able to go through the user stories manually and create bigger Test Cases or do Exploratory Testing in the same sprint.

I would Suggest you to finish your user stories one sprint before the development and ask QA team to prepare test cases while developers are developing the feature. This will help in QAs to get those tested in the current sprint, as the test cases are ready one sprint before.

Hope this helps.