Timeline for Should QA report bugs on features before they are fully implemented?
Current License: CC BY-SA 3.0
38 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Mar 7 at 21:39 | answer | added | Jayowl | timeline score: 0 | |
Aug 22, 2020 at 12:59 | answer | added | Greg Wojcik | timeline score: 0 | |
Sep 22, 2016 at 8:49 | comment | added | Lightness Races in Orbit | @immibis: Either no or your stories are not atomic enough (that is, you actually have two features and one is ready for testing). Do some testing on your branch if you need to. | |
Sep 11, 2016 at 0:08 | comment | added | Edwin Jaime | The issue is not that QA take a look on not fully implemented features, actually it might come to be extremely helpful because it might help you identify uncover border use cases sooner. The problem you and your team has is a communication one. Talk with your QA and agree on a better workflow. Cheers. | |
Mar 10, 2016 at 0:28 | history | edited | user246 |
edited tags
|
|
Feb 10, 2016 at 10:35 | answer | added | Rohan Kalia | timeline score: 1 | |
Feb 4, 2016 at 11:49 | answer | added | Scott | timeline score: 1 | |
Feb 4, 2016 at 0:49 | answer | added | testerab | timeline score: 2 | |
Feb 3, 2016 at 20:32 | answer | added | Steve Barnes | timeline score: 2 | |
Feb 1, 2016 at 10:07 | answer | added | Ian Ringrose | timeline score: 3 | |
Feb 1, 2016 at 2:08 | comment | added | gregmac | The same bug filed multiple times means the others get closed as duplicates. Dupes from an in house qa team should be very rare, as it means they are overlapping work but but talking to each other. I usually try to choose the one with best description, or merge them together, but if I had more than a couple different bugs I'd likely just close all and leave a comment telling qa to get their stuff together and reopen the valid ones themselves, as it's not my job to clean up their mess. This would also be a big topic of discussion for the retrospective at the end of cycle. | |
Feb 1, 2016 at 1:52 | comment | added | Lightness Races in Orbit | "I generally check in partial implementations so that I don't have too much uncommited code at any time." Don't do this. Commit to branches but never to trunk until you're done... "When I get 20 bugs on any feature I feel as though I did a sloppy job" You did. Do a whole job or none at all. | |
Jan 31, 2016 at 3:07 | answer | added | Jesse Williams | timeline score: 2 | |
Jan 31, 2016 at 1:17 | comment | added | 18446744073709551615 | (Issue trackers usually can classify any issue as either bug or feature request, I would rather believe that this feature is not used than that it is missing. Maybe one should use tags.) | |
Jan 31, 2016 at 1:16 | comment | added | 18446744073709551615 | What you call bugs is also called issues, or change requests (CRs), or action items. 30 CRs for 30 things to do -- it is normal. You cannot always keep all 30 things in memory, and a sheet of paper will likely get lost in two weeks. 30 CRs does not mean a sloppy job, it means 30 action items to do before the task is complete, 30 working days if you can perform 1 CR a day. OTOH, you may ask your colleagues be politically correct and not to call all action items bugs. | |
Jan 30, 2016 at 14:23 | answer | added | Peter | timeline score: 4 | |
Jan 29, 2016 at 22:50 | answer | added | D.W. | timeline score: 5 | |
Jan 29, 2016 at 16:52 | history | tweeted | twitter.com/StackSQA/status/693114518235385857 | ||
Jan 29, 2016 at 15:18 | comment | added | Swagin9 | Are you co-located with the QA team? | |
Jan 29, 2016 at 15:05 | answer | added | Peter M. - stands for Monica | timeline score: 7 | |
Jan 29, 2016 at 14:55 | answer | added | Aye1 | timeline score: 2 | |
Jan 29, 2016 at 14:07 | history | edited | IAmMilinPatel |
edited tags
|
|
Jan 29, 2016 at 13:45 | answer | added | PeterJackson | timeline score: 26 | |
S Jan 29, 2016 at 13:27 | history | suggested | Joern Boegeholz | CC BY-SA 3.0 |
corrected formatting
|
Jan 29, 2016 at 13:13 | answer | added | Michael Durrant | timeline score: 8 | |
Jan 29, 2016 at 12:55 | answer | added | Joern Boegeholz | timeline score: 19 | |
Jan 29, 2016 at 12:49 | review | Suggested edits | |||
S Jan 29, 2016 at 13:27 | |||||
Jan 29, 2016 at 12:44 | answer | added | dzieciou | timeline score: 17 | |
Jan 29, 2016 at 12:22 | comment | added | SamSobers | Let us continue this discussion in chat. | |
Jan 29, 2016 at 12:19 | comment | added | SamSobers | Progress on the project, reason for why a change was made, how hard and well the SQA team is working - I am not sure. I am wondering if this is a normal practice? I am open to problems being reported informally when I am still working on something, but I don't like all these bugs for things that I know about and am working on | |
Jan 29, 2016 at 12:16 | comment | added | dzieciou | Traceability of what? What they are tracing? Progress? | |
Jan 29, 2016 at 12:14 | comment | added | SamSobers | To give an example we got new UI mockups - the changes were quite extensive and it took me 2 weeks to get most of the things implemented. Yesterday I had a review with the entire team where I walked them through what was done and listed out all the things (about 20) that needed tweaking and asked them to point out areas that I had missed - about 10 more were found. Today I find 30 bugs that have been assigned to me. | |
Jan 29, 2016 at 12:06 | comment | added | SamSobers | the bugs are formally reported in the bug tracking system. The reason I have been given so far is that this is for traceability | |
Jan 29, 2016 at 12:05 | comment | added | dzieciou | To me this sounds like testers are reporting invalid bugs, i.e., bugs for functionality that is not completed. What was the reason to start doing that? Someone, eventually, took that decision for a reason. | |
Jan 29, 2016 at 12:05 | history | edited | SamSobers | CC BY-SA 3.0 |
added 154 characters in body
|
Jan 29, 2016 at 12:04 | comment | added | dzieciou | Do testers report those bugs formally, i.e., in Bug Tracking System? Or they are just telling you about them? | |
Jan 29, 2016 at 12:03 | review | First posts | |||
Jan 29, 2016 at 14:04 | |||||
Jan 29, 2016 at 12:01 | history | asked | SamSobers | CC BY-SA 3.0 |