|
The addition of the "...because" in the No case is erroneous. There are other reasons testers may affect debugging time than 'number of bugs found'.
The mere act of dealing with them is a time sink (regardless of their generally positive influence on the dev process overall.)
Didn't vote.
|
|
|
|
|
Dedicated Tester only needed in large scale projects, and most projects are small to medium so this case is rare. With time developer get used to common errors and more time spent with the tester the less error will be generated.
|
|
|
|
|
Well - It Depends Upon how big an idiot they hire to do the debugging.
Could that actually find people who will maintain their user-level competence indefinitely?
(Perhaps - people still talk/text and drive)
Really - after being on the job for a while there's a danger they'll become software literate and not find the bugs. As for falling back on the idea that experience would make them more efficient, that responsibility should fall on the developer.
Just unleash it upon the rabble - and let those million monkeys have at it.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I don't see how your "total debugging time" as a function of whether or not you use separate testers matters. You use separate testers if they're available and it's appropriate to the project. The effect they have on total debugging time is more a reflection on the level of crappines of the code than anything else. If the code is sh*t, the debugging time goes way up because they find a lot of issues.
In my experience, testers help in a couple ways. First, they're more likely to bang on the application like a user would. They don't have the built-in expectations you do from having developed the thing. Second, they are less likely than you to gloss over minor issues that are symptomatic of more serious defects.
Fortunately, I have Marcia the Test Terrier™ to help review my stuff before I release it to QA. Thanks, Marcia  .
Software Zen: delete this;
|
|
|
|
|
Testers are there to increase the quality of a release, and not to make a release faster.
Faster release depends upon the planning from the manager and then capability of the developers, it is not the testers job.
And there are no bugs that can be ignored, either you find the bug or not. But if you find a bug and then ignore it until your users/customers find it - this is bad practice (Don't be a Micro$o... ah forget it. ).
|
|
|
|
|
How much efficient tester you have... 
Life is all about share and care...
public class Life : ICareable,IShareable
{
// implements yours...
}
|
|
|
|
|
Dedicated developers are more important.
|
|
|
|
|
And to think when I sicked it on 'em I thought it was ready 
|
|
|
|
|
One of the problems with certain complex webpage "forms" shows up in the case where the user uses it in a certain way and the developer codes it to work that way and puts in reasonable cross referencing checks to make sure values are properly validated, etc.
The developer tests it - there are no "bugs". The user uses it, there are no "bugs". Everyone is happy... until Q/A tests it and finds a whole bunch of weird combinations that will never happen in the real world but cause anomalous operations and weird effects - often cosmetic or transitory.
"Bugs! Bugs! Bugs!", is the cry and the developer is dragged off the next stage of development to fix all these complete waste of time issues. This can get especially sticky when many user controls have been utilised (code re-use, yeah!) and the page may end up being effectively the result of a huge team effort where things don't interact perfectly in every case - but it doesn't matter because we don't do those cases!
What I am saying is that dedicated testers are often too dedicated to finding bugs for the sake of finding bugs rather than checking for correct normal operation of complex pages and this can really impact a team with a lot of things to do and deadlines to meet. I am not saying to allow code out with actual line of business bugs in it but sometimes it is ridiculous to check for every combination of factors which could amount to thousands of combinations when only a few are actually used.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
That's where you need someone with the authority to say those bugs are priority Z and a fix will be scheduled for implementation on the 32nd of never.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Haha that sounds like me, I used to do QA before I moved into development.
I was told quite a bit that the bug I found was not a prority, although I often disagreed lol
|
|
|
|
|
I feel, that if a bug can be ignored, then it should be addressed in another ticket. Also, your Project Manager should be able to understand the necessity for those extreme edge case bugs to be dealt with at a later date.
Your QA should have a general idea of what's important for testing, and what the acceptance criteria is. If they don't, then that should be addressed as well.
|
|
|
|
|
I feel like the answers are answering a different question...
Quote: The sooner you find a bug after writing the code, the easier it is to fix. Does this mean that dedicated testers get your bug count to zero faster?
Answers:Quote: Yes, total debugging time decreases with dedicated testers
True. Reason: You are still more or less familiar with the code that the QA is testing. However, they might also find many "bugs" that aren't really bugs, but expected behaviour etc. You have to track every bug down. Sure, the code is sooner without (lots) of bugs. However you have also probably to invest more time
Quote: No, debugging time increases because the dedicated testers find many more bugs than your customers
Also true. Reason: Customers will probably never find as many possible bugs as Q&A. Depending on the complexity you might never get any reports at all. Often customers also try something different or try again if it didn't work. However, if there is a bug it's often much more difficult to track down, as the customer often won't give you detailed steps what he did and the errors often come after quite some time when you have all but forgotten that piece of software.
There is no clear answer to that question, in my opinion.
Eventually it all comes down how good you, as a developer, are at testing your own code. Our mind is often set on how it should work and test it only in ways we'd expect users to use it. However, you have to test everything you wouldn't expect a user to do too. And if you're not good at coming up with such ideas dedicated testers might be better suited to find bugs in the code.
I guess there are some developers that are quite good at testing code, others might lack the imagination but on the other hand be exceptionally good at coding etc.
|
|
|
|
|
When the testers have finished testing, it's the customers turn. Hopefully the testers will have filtered out the more embarrassing bugs but the customer will always find more no matter how hard you try. If you're lucky these will be the sort that can be addressed in the next scheduled release.
I may not last forever but the mess I leave behind certainly will.
|
|
|
|
|
I don't understand the parallel between testers and time spent debugging code. debugging code is something we are going to do while working on solving bugs in the code regardless the number of testers or their dedicated role in a project.
plus this question leads one to believe that all bugs in a product are the result of bad code. can't forget that sometimes bugs are the result of poor requirements.
you want something inspirational??
|
|
|
|
|
I agree. There should be no correlation.
I suppose there are some lazy developers who know if there are testers they won't try as hard.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
If it weren't for our validation process I probably would not be programming still. Our testers find most of my D'oh![^] moments, luckily for me they are generally easily fixed.
Testers who know what they are doing can quickly weed out the bugs and document how to exploit the bug. This makes it easier for me to find and fix the issue. Testing also makes our product much more solid and reliable. In the medical devices, the testers can literally save someone's life.
Reviewing the code to fix a bug often forces me to revisit code I haven't looked at in some time. In doing so I have found and fixed other minor bugs.
Useful, but can be annoying, now I'm off to my next V&V meeting...
It was broke, so I fixed it.
|
|
|
|
|
Yes its much better to receive a documented bug and how it occurred.
The ever helpful user who just reports it doesn't work! is very helpful in finding the error in the code. It is also hard to self test as you know what the code is supposed to do.
Why is it when you are busy everyone whats it yesterday, But when your not no-one has any work for you?
|
|
|
|
|
S Houghtelin wrote: In the medical devices
Thankfully I only do LOB work, the worst that can happen is that I piss off the local dictatorships monetary authority. 
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: local dictatorship
Living in Singapore, aren't you? 
Hey, it is crean and gleen!
|
|
|
|
|
What a dedicated tester looks like?!
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is (V).
|
|
|
|
|
|
Me too!
Do they really exist
|
|
|
|
|
It usually doesn't matter who finds the bugs, the fixing time will be exactly the same.
Probably the time will be less if they are found earlier by a dedicated testing team but in average (and if you didn't really messed up) the fixing time will be the same.
A dedicated (and specially GOOD) tester team will most of all increase the quality and confidence of your deliverables.
|
|
|
|
|
A decent tester should at least be able to give you detailed information about how to replicate a bug or exactly what they were doing when they discovered it.
The reports should be far more helpful and timely than from a user, so should be easier to track down, if not necessarily to solve.
Although of course they should discover far more bugs so increase total time.
“I believe that there is an equality to all humanity. We all suck.” Bill Hicks
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
