I would agree with the general tenor of these responses, in that complicated apps are not as good for automation or for tracking down issues once they are found. However, they are much better than simple tests at actually discovering issues in the first place. If a complicated app was constructed by the Firebug team, and they simply just used the app for 15 minutes, they would probably discover multiple issues. Since they made the app, they would be in a position to debug it effectively. Also, i would like to make a counter-point to the following:
"Between a person who sees a problem and a person who does not, who is better positioned to document it?" I am saying that the FB developers will be the ones to find these problems, instead of us, and will therefore be in a much better position to document it than we, since not only do they know the app, but they also know FB, and where it might be failing. When you go to test the app, you don't attack it by trying to duplicate or find a specific issue. Instead, you just use the app and be aware of any issues that arise. I say all this from experience, as I am also a software developer. Whenever i take it upon myself to just 'use' a complicated app, such as a user might, then I invariably find bugs. Similarly, if a FB developer were to simply 'use' a complicated app, they would also experience problems, but would then be in a better position to fix them, since the whole duplication and simple test case steps would not be unnecessary. In conclusion, I am not suggesting that a complicated app testing procedure be a substitute for your current processes, but only a supplement to them. On Jul 29, 7:40 am, ColinFine <[email protected]> wrote: > On Jul 28, 7:20 pm, Prefontim <[email protected]> wrote: > > If the Firebug developers had some > > > kind of 'master complicated app', (e.g. - similar to google mail) > > simple test cases would become obsolete as this app could be used to > > duplicate all of the above issues. > > I'm sorry, but this is simply wrong, and if you go on believing it you > will continue to be disappointed. > > While it is indeed helpful to have some complicated tests as well as > simple ones, they serve only the limited purpose of exercising the > system and showing that it is generally robust (or not :-). > In the first place there is not just one dimension of 'complicated': > Your complicated app is likely to be utterly different from the next > person's complicated app, and will in general show different problems. > Secondly, if one does show a problem, this may be helpful in showing > that the problem occurs, but be little help in isolating it, or > sometimes even in repoducing it. As Bob Hassinger says, usually people > who understand what the complicated system is trying to do will be > better at 1) knowing what they did to make it happen, 2) what kind of > thing they might do that is like that, and 3) what is likely to be > irrelevant. (They won't necessarily know these, of course, but they > can usually do them at least as well as the people who are maintaining > a general tool). > Thirdly, such tests typically take a lot of time to run, and may be > difficult to automate. This is a problem even for expensive commercial > tools where there is a budget for machine and people time to run them. > For volunteer projects it is extremely difficult. > > Small, well-specified and controlled automatic tests are FAR more > effective than big amorphous ones (though again I say, there is a > place for the big ones). -- You received this message because you are subscribed to the Google Groups "Firebug" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/firebug?hl=en.
