On 11/22/2011 12:59 AM, Per Jessen wrote:
Roger Luedecke wrote:
Part of the problem is people don't do early testing so we can catch bugs better before release. Everybody wants it stable, but few are willing to risk some instability to assure a better result for us all. I'm not sure we has any data to really substantiate that. At some point, I did sort of half-way propose we should be using a test-case tracking system, but given the size of this project, it's probably not a very good idea. 15 years ago I helped write and document about 1000 test-cases for a project I was managing. There was about 20 people involved in total, and even those 1000 cases were too much.
Well, back in my day on the mainframe, I wrote many, many "system" level utilities and short cuts for the operators all the way up to higher management. I used what is called a "devils advocate" approach. As I was writing the code, I would take a step back and try to think of all the possibilities of how and where it would break. As part of this approach, I would take the main task and break it down into subtasks and begin testing at that level, then start putting it together. So by the time I released it into production, it would be nearly 100% error free. The worst case was when my work wanted to take "line" mode (normal impact print data) and convert it to "page" mode a.k.a. AFP (Advanced Function Printing) data for the IBM 3800 Laser Printer. That meant building a HEX data stream to include actual print data, definition sequence numbers, font selection, X & Y coordinated, margins, page size definitions, a forms overlay stream (like adding a grid line - boxes with borders or line shading, etc.), adding an image hex stream (graphs, logos, etc) and, last but not least, handling multi-section pages. IF ANY PART of the data stream was wrong - the printer would either stop, print garbage or go completely nuts. BTW, my part was the easy part, because once my data stream definition were right, I would pass them to the application programmers who had to - convert - and - build - the data stream to run on an OCTAL mainframe (Bull / Honeywell) which in turn meant they had to use COBOL COMP-3 fields which turned it into BINARY data field. AND, if the application programs did not build the AFP data stream in the right sequence, it would do the same as above. Ahhhhhh..... Those Were The Days ........ Duaine -- Duaine Hechler Piano, Player Piano, Pump Organ Tuning, Servicing& Rebuilding Reed Organ Society Member Florissant, MO 63034 (314) 838-5587 dahechler@att.net www.hechlerpianoandorgan.com -- Home& Business user of Linux - 11 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org