Timeline for How to decrease errors before testing?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 20, 2011 at 16:09 | vote | accept | user674887 | ||
| Oct 19, 2011 at 23:39 | comment | added | Ethel Evans | @P. Brian, wanted to add that, actually, it sounds like the test team is doing pretty well . . . the problem isn't that it takes forever to find the bugs, it's that "the number of errors is to damn high" and "we get an interminable list of things that we have to repair". That's not a test problem - that's a code quality problem that is upstream of test. There might also be test problems that are resulting in slow turn-around, etc., but they weren't mentioned (although some of my suggestions were targeted at that scenario). | |
| Oct 19, 2011 at 23:29 | comment | added | Ethel Evans | @Bernard, Alan Page from Microsoft (author of "How We Test Software at Microsoft", which makes most "Top 5 Software QA Books" lists) wrote this paper on test code reviews: angryweasel.com/Articles/… | |
| Oct 19, 2011 at 23:21 | comment | added | Ethel Evans | @P. Brian Mackey, I wasn't trying to say the OP should do all of these. I'm saying these are all things that can help. The OP can pick options that will work for their group and level of influence. OP sounds like s/he is looking for ideas to bring to a brainstorming session, and not just one fix. | |
| Oct 19, 2011 at 20:06 | comment | added | P.Brian.Mackey | This is a great idealistic scenario. The question is, how advanced is the OP's team as a whole? Do they have formal testers that are also advanced enough to read and write code? If they did, I don't see how they could be failing so badly. That's why I believe this to be an impractical suggestion to improve by leaps and bounds rather than incrementally. Management won't buy into leaps and bounds. | |
| Oct 19, 2011 at 19:08 | comment | added | Bernard | +1 I agree with most of your points, especially automating tests so they can be run nightly. However, I feel that a non-developer should not be reading code, even if they could understand it. Code reviews should be left for developers to do as part of their team development process. | |
| Oct 19, 2011 at 18:50 | comment | added | joshin4colours | All of this, particularly using testers at all points of the SDLC. Great testers can find bugs in more than a finished GUI | |
| Oct 19, 2011 at 18:40 | comment | added | Thomas Owens♦ | The problem with using TDD without knowing where you defects come from are that it will only help with finding problems in the code. Testing the code doesn't do anything to verify or validate your requirements and design nor does it compare your implementation against the design. | |
| Oct 19, 2011 at 18:33 | history | answered | Ethel Evans | CC BY-SA 3.0 |