Originally posted by zinc ster:
[QB]how can I ensure that I reasonably test such that I can find all/most of the bugs that exist? ... I'm just wondering if there are some tips to make sure that I don't miss cases when I test.
[QB]
Originally posted by Lasse Koskela:
[QB]JUnit tests are unit tests. That means that each of your JUnit classes (classes that extend junit.framework.TestCase) is generally responsible for testing one class and one class only.
QB]
Originally posted by Tirthankar Dutta Chaudhuri:
hi ,
i have a class which contains many private functions which are called from a public function . The job that those functions fo is to get a xml file over http . Parse the data apply the business rules . The public fuction returns a list . How do write a junit test for that . The xml file is very big 20000 lines so to get a list formed manually is not possible . Can anyone suggest me some methodology to test it .
Thanks,
Tirthankar
Originally posted by Peter Sin:
To conclude: What are the benefits of "Process" ? Please refers to "Ship It! A Practical Guide to Successful Software Projects". I just want to test the author debate technique.![]()
![]()
![]()
![]()
![]()
Originally posted by Tony William:
Jared,
For my team, we have use a spreadsheet for logging all bugs and major events / comments. The log will have a no. assigned. We also have document for each problem fix (w/ ref. to the log no.), problem desc, details, changes and revised source files are included in the doc.
Is this good enough? Any other approaches that you can shared?
quote:
--------------------------------------------------------------------------------
I'm in a company that supports products for years and decades... I wonder how something like 3x5s would attempt to handle that situation?
--------------------------------------------------------------------------------
Remember that the cards are just planning tokens. Once a feature is implemented, it is specified in much more detail by the customers Acceptance Tests. The cards aren't needed any longer.
By the way, there are some interesting discussions at http://c2.com/cgi/wiki?CthreeProjectTerminated
I guess our experience is just significantly different. That's what makes this discussion so interesting, I guess...
"RJ" = "Ron Jeffries"?
What about http://www.scissor.com/resources/teamroom/ and http://www.xp123.com/xplor/room-gallery/index.shtml ?
As far as I know, the 3C project (where XP was invented) used index cards for 4 years.
There is still debate as to whether or not C3, as it relates to XP, was a success or failure. While it is true that C3 never met its goals, XP did make a doomed system work. The project was incrementally working at the pace it set. The first goal of printing a check in three weeks was met. The next goal of paying 10,000 employees within a year was met. The project was cancelled after four years of using XP, but before XP was threatened with cancellation after just one year. A few questions that are unanswered are "How many user stories were left?" and "How long would those user stories have taken to implement?" It is possible that management simply didn't want to wait that long. It's also possible that XP just couldn't handle the project at all and was going to fail sooner or later. Since the project was cancelled, we'll never know.
DaimlerChrysler is now working on yet another payroll system. They are using traditional methods and software practices. They are even using PeopleSoft. I need to get fresh details but the reports I have now (7/31/04) indicate that they have a big team, the biggest and fastest servers, have worked on it for about two years, and have not paid a single person yet. Compare that to a thin team, obsolete mini computers, and 11 months to actually start paying people with C3. Payroll at a very old, very large company is not as easy as you think which is why C3 was considered a success. --DonWells
The authors also examine C3, the first XP project, whose team (most of whom went on to get XP book deals shortly before C3�s cancellation) described themselves as "the best team on the face of the Earth".
Or they could have a big sheet of paper on the wall listing the current issues, with developers striking out the ones they just fixed.
The practical disadvantages I feel in this approach are:
- Analyzer and Designer are included in whole life cycle (3 Month). In any company they are less in number and also take more salary than developer.
- In iteration 1, developer may be free for some days and in later iteration i.e. 4, analyzer and designer may be free for some days...
Please comment..