Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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 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, responsibility of the Testers etc.)

share|improve this question
add comment

migrated from stackoverflow.com Jan 14 '13 at 17:37

This question came from our site for professional and enthusiast programmers.

3 Answers

up vote 4 down vote accepted

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

share|improve this answer
    
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? –  Roland Tiefenbrunner Jan 11 '13 at 10:07
    
Did you mean "Maximum WIP" ? –  aclear16 Jan 14 '13 at 17:23
    
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 '13 at 14:40
add comment

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.

share|improve this answer
add comment

There are several factors that allows 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 team work/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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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