Timeline for When should QA be testing during a sprint? (Agile)
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 18, 2019 at 10:24 | history | edited | Niels van Reijmersdal | CC BY-SA 4.0 |
added 184 characters in body
|
| Jan 12, 2016 at 15:13 | comment | added | Niels van Reijmersdal | 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. | |
| Jan 12, 2016 at 15:12 | vote | accept | Mercfh | ||
| Jan 12, 2016 at 15:12 | comment | added | Mercfh | The hardening does make a lot of sense, it's def. an adjustment getting used to the agile method haha | |
| Jan 12, 2016 at 15:06 | comment | added | Niels van Reijmersdal | 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. | |
| Jan 12, 2016 at 14:59 | comment | added | Mercfh | 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) | |
| Jan 12, 2016 at 8:47 | comment | added | gazzz0x2z | 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. | |
| Jan 12, 2016 at 8:40 | history | edited | Niels van Reijmersdal | CC BY-SA 3.0 |
added 437 characters in body
|
| Jan 12, 2016 at 8:34 | history | answered | Niels van Reijmersdal | CC BY-SA 3.0 |