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.)

4 Answers 4


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.

  • Thanks for the answer. Developers are writing automated tests (Unit + Acceptance) already and those are used for regression. In my opinion, there should still be a tester for manual tests ("Big Picture" Test Cases,Exploratory Testing). How do you handle manual testing? Jan 11, 2013 at 10:07
  • Did you mean "Maximum WIP" ?
    – aclear16
    Jan 14, 2013 at 17:23
  • 1
    No he meant "Minimum WIP". With agile methodologies, you want to minimize WIP so the team can focus on getting individual units of work done instead of working on lots of tasks in parallel and not finishing any of them. This applies to scrum, kanban and all truly agile methodologies.
    – Jared
    Jan 23, 2013 at 14:40
  • The correct grammar would be "Ensuring that you have minimal Work In Progress" Dec 8, 2015 at 12:30

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.


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.


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.

  • 1
    What does "finish your user stories one spring before development" mean? To me this sounds like you are saying, "Finish testing before development starts" which is not possible.
    – Lee Jensen
    Mar 16, 2022 at 15:58
  • No, What I mean to say is that if you are planning to be working on a user story in the next sprint (example sprint 4) its user story should be completed by BAs in Sprint 3, while developer are working on its previous user story.
    – Qaisar
    Mar 19, 2022 at 9:39
  • Ok, so, this is where you can now edit your answer to provide this new clarification!
    – Lee Jensen
    Mar 19, 2022 at 19:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.