Logging defects in an Agile methodology
I believe that whatever SDLC you follow the fact of life is we would open defects when QA finds that a functionality is not working as expected (based on a user story or a requirement or whatever).
Did anyone of you come across or follow a process (in agile) the testers dont open defects for the functionality that is not working but just "re assign" the "task/user story" back to the developer. Basically, put some comments in the user story or the task (for the user story) and attach some screen shots saying whats NOT working as part of that user story instead of opening a defect.
I came across this in a place where I work and I felt its strange for obvious reasons.
My reasons:So basically we dont have any repository of issues that find, nothing to refer to if we have a production issue to go back and see if that issue ever occurred during sprint testing and was fixed, (if fixed why did it re occur) , at least feel the pulse of our qa team efforts as to how we are doing, see what quality of code that is coming through etc.
What I am looking for?
1) Did you ever come across this type of practice of not opening defects in agile?
2) What did you do to change it? (besides the reasons I mentioned above).
Last edited by anvs; 03-20-2015 at 05:18 PM.
I've certainly come across the practice (and disliked it). The version of it that I encountered was probably even worse: the user story was never actually assigned to the tester (or the developer) but remained assigned to the project lead throughout development.
When I found problems in this situation, I'd discuss with the developer initially. If it was possible to get a fix in immediately, that was as far as things went. If not, I maintained a list (usually a spreadsheet) within the project attachments that contained all the issues that hadn't been addressed yet. That list was reported on as part of the daily standup, the sprint reviews, and on occasion the project completion report.
I wasn't able to change the practice at that employer, but the project leads quickly discovered that when our team listed issues that weren't addressed, those issues almost always proved to be problems for customers after release (the record in my case was two days after being told "the customer will never do that" having to talk the customer through fixing their test data because they were alpha-testing our project and had "done that". I refrained from saying "I told you so", but I was tempted!). Most of them wound up treating the list of issues as backlog items and scheduling them accordingly (It's worth mentioning that this organization used the forms of agile, but was actually working a kind of waterfall-agile hybrid with the worst qualities of both).
The other thing I started doing in this situation was to provide a simple Red/Yellow/Green status of projects I was working on.
Unfortunately, if the management of the organization resists the practice of opening defects for problems in a project, there isn't much else that can be done beyond doing your own documentation and making it available to the rest of the team.
I believe that you find something that is not working, you need to distinguish if what you found is part of the scope of the story you are testing or not. If if belongs to the scope of the story, then what this really means is that this story is not DONE, the acceptance criteria for this story has not been met yet (i.e. this is not a defect). Therefore, this story should not be accepted until this functionality that still doesn't work is fixed. As this is not a defect, this is remaining work in the story, the best way to handle it is through creating a new Task inside the story (as a way to track that there is still work remaining for this story).
If what you find is not working does not belong to the scope of the story (or any of the stories you are working on in the sprint) then this clearly is a defect, something that was missed during the previous sprints or was introduced in later sprints over some functionality that was working. In this case, it is really important to log a defect which must be handled to the Product Owner for him to prioritize. Yes, it is really important for the Product Owner to prioritize a defect because it may be something that really needs to be fixed before the release or it may be something that the PO is willing to live with.
You shouldn't be afraid of not logging defects. The objective of the QA team is not log defects. The objective is to construct a product that meets the needs of the customer and has the expected quality.
In my current role, we have attempted this practice however it has caused confusion as to whether the task should be created under the original user story or the user story currently under test.
Originally Posted by Sanjay Zalavadia
Tags for this Thread