If you are getting build on alternative days then, once the sprint is started you can start preparing your testcases corresponding to the assigned user stories.

Once the build is deployed then you can start executing your testcases, if there is some change in build then you can execute your test suites.

Whenever new build is out, you should execute your sanity set of test suite.


Define a definition of done that includes testing. Define which testing effort is minimal needed to get the work done.

  • Time boxed exploratory testing session for each story, just after coding is done or even during the coding sessions, pair with developers to test their work
  • Good balance of UI-, Service- and unit-tests, read about the test pyramid
  • Continuous integration is important so that to full product is build on each check-in. So you can test, because the product works. Since Working software is the primary measure of progress.
  • Start each PBI with a Three Amigo's session, think about how you can start testing work in parallel with coding.

Focus on automating most if not all of the test-cases, since you wont have time todo a manual test regression each iteration. Quality should be build in the product and cycle.

Keep in mind that Agile does not have an official method as it goes for testing. Being Agile means doing what is needed to get the work done, iteration after iteration. If it works keep doing it, if you fail adapt. The XP practises are the closest as a best practise for Agile teams, which includes testing.

Suggested read is the Agile Testing book.

  • 4
    it's unfortunate I cannot upvote 10 times. "Define a definition of done that includes testing." would be very useful even on non-agile. And "Agile does not have an official method" is the key : agile means you shall use the method that works the best for your specific situation. – gazzz0x2z Jan 12 '16 at 8:47
  • The problem with automation (in my case) is that it's just me. I cannot (or do not have the time) to automate these types of things for all the projects I am on. I guess finding a definition of done is probably what I need to strive for. But from my understanding you are saying once a "Story" is tested and 'done' I really shouldn't be going back and retesting everytime I new build comes up (until regression at least). Because I think thats where Im having trouble (how much time do I spend on retesting "old" stuff) – Mercfh Jan 12 '16 at 14:59
  • 3
    In Agile the team is responsible for completing the definition of done. If the tester is a the bottle neck in automating test-cases that others in the team should help or else the team gets nothing done. Yes, I am saying you should prevent re-testing older features every iteration. Now I understand teams switching to Agile might not really have the culture to do everything that is needed to release this part of the software to production. Some teams introduce a hardening sprint, every 2-3 sprints. See: agilerecord.com/hardening-sprints Maybe this is the time for a full regression. – Niels van Reijmersdal Jan 12 '16 at 15:06
  • The hardening does make a lot of sense, it's def. an adjustment getting used to the agile method haha – Mercfh Jan 12 '16 at 15:12
  • Personally, I look into the code (with a developer) to check the impact of a change. With this knowledge I try to think which parts have low (automated) test coverage that are hit by this change. Then I add a bit of extra focus on these parts only. If the developers use SOLID patterns, then most of the code is decoupled and the impact should always be relative low and the impact is easy estimate. Add more tests for closely coupled components. If code changes break unexpected area's, then the code is to coupled. This is not a problem you want to solve with tests, but with better architecture. – Niels van Reijmersdal Jan 12 '16 at 15:13

My team struggles with a similar issue having multiple input streams, that are running on different iteration/sprint cycles into a common product. We tried testing in the dev int area for each team for a while and then marking items done at that point, but we quickly discovered that was too early in the process. We could verify that new functionality was working, but we couldn't test at the integration level which was where most of our defects actually occur. So we basically moved our definition of 'done' to be later in the next cycle, I guess you could call that a hardening sprint since it comes after the initial sprint where the dev work occurred or we call it the 'QA Offset'. Our management team really wanted 'testing' to be 'done' during the same section of time as dev, but this just wasn't practical based on the type of system we are testing. We have been attempting to add different layers of automation, to help us get to done earlier, but on a legacy product that can be challenging.

So to answer your original question, we generally monitor the build and whenever there is a large enough quantity of items in it, we will grab them and start testing. Since we build daily it is about every other day that we will restart testing, which includes the new functionality and a mini-smoke to verify that the older items continue to work.

  • This seems to be similar to what im doing, it's just me as QA right now so it's tough to juggle everything. But im generally watching our trello board stories, and when a decent amount get moved over and a new build created I will start testing – Mercfh Jan 12 '16 at 16:05
  • 1
    The juggle in Agile for QA seems to be the hardest part. A question for you, what interation is your testing task in? Right now I have PBI/Bug with tasks underneath for all the dev work and a testing task. I can't mark the PBI/Bug as done until all my tasks are done, but my testing task may not be in the same iteration as my dev tasks. So should I be in the next dev iteration or we have been having a separate QA iteration. Because we don't want to negatively impact devs burndown chart. Do you try to keep your testing task in the same iteration? – QA Prescott Jan 14 '16 at 15:03
  • Well we are still kinda getting used to the agile method so im typically testing as builds are made so im testing the same iteration as dev. – Mercfh Jan 14 '16 at 15:07

Testing of a particular feature which is being created in the sprint can be done, only if the developer has developed the feature upto some extent. Meanwhile, when the developer is busy in developing the feature, a QA should start working on the test plan / test cases on the basis of feature specification document or the user stories. If QA team is automating the test cases and using BDD tools like cucumber, then he must start writing the Cucumber for the test cases to save time. A QA should be in continous touch with the developers, so that he recieves atleast a piece of the feature which has been developed.

Once the developed module is recieved, now a QA has ample amount of work. He should first do a sanity of the module recieved, and quickly log the issues identified in a bug tracking tool. Also comminicate the developer regading the issue. Side by side he should also automate the test case. This cycle needs to pe processed quickly so that each module is tested and delivered without any bug on or before the sprint end date. Thus in other words, the work of a qa starts as soon as feature specs or user story is recieved in the sprint and the actual testing can be started as soon as the developer develops some module of the feature.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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