Development and Testing Tools at SUSE?
I'm currently doing a project seminar at Augsburg Uni on software re-engineering and have been talking about development and testing tools etc. We've covered UML development tools for doing the specifications, code generators and development environments and I'm currently going over testing techniques. I've covered the sort of tools that we used to use at Capgemini, but thought it would be interesting if the students got an insight into how a software house / open source project is run. What tools and methods are used at SUSE/Novell to capture requirements and produce the specifications? (We've covered the likes of Requisite Pro, Rational Rose, Rational Software Architect etc. which were used on large projects, but obviously as they run into 10's of thousands for licensing, I guess you'll use something different.) Do you use any code generators or is the code 100% hand rolled? If so, what tools do you use? What standards and tools do you use internally for testing SUSE before releasing it for public testing, I guess you use Bugzilla throughout for tracking problems? What testing suite do you use to automate the testing procedures internally. How thorough is your test documentation? The problem I find at the Uni is that most of the professors are very academic and expound about theoretical techniques etc. which aren't used in industry, and while I've been showing the students what is used on the consultancy side for producing bespoke applications for clients, I thought it would be interesting if I could give them a perspective inside a software house like SUSE and anyone in the community who wants to respond with what specification and testing tools they use, please feel free to chip in. Information also on the size of the testing lab etc would also be useful. Dave -- "I got to go figure," the tenant said. "We all got to figure. There's some way to stop this. It's not like lightning or earthquakes. We've got a bad thing made by men, and by God that's something we can change." - The Grapes of Wrath, by John Steinbeck
Let me first say that a distributor does a complete different job than
a traditional software house since the majority of our software comes
From the Open Source community and we integrate.
I can give you only a high level answer on some parts...
David Wright
I'm currently doing a project seminar at Augsburg Uni on software re-engineering and have been talking about development and testing tools etc.
We've covered UML development tools for doing the specifications, code generators and development environments and I'm currently going over testing techniques.
I've covered the sort of tools that we used to use at Capgemini, but thought it would be interesting if the students got an insight into how a software house / open source project is run.
What tools and methods are used at SUSE/Novell to capture requirements and produce the specifications? (We've covered the likes of Requisite Pro, Rational Rose, Rational Software Architect etc. which were used on large projects, but obviously as they run into 10's of thousands for licensing, I guess you'll use something different.)
We have our own tools for requirements specification - but those are on a much higher level than what the the tools you mention do. I'm more interested in e.g. a certain gcc version or a feature and leave the details to the developer than in a complete overview of gcc.
Do you use any code generators or is the code 100% hand rolled? If so, what tools do you use?
It really depends on the software that's written. Since our developers right code for different parts of the system, there are different requirements. You cannot use any code generator for GCC, kernel or glibc code - but can use it for graphical frontends...
What standards and tools do you use internally for testing SUSE before releasing it for public testing, I guess you use Bugzilla throughout for tracking problems?
We use bugzilla for tracking.
What testing suite do you use to automate the testing procedures internally.
Lots of different ones, depending on the purpose and where they are used * packages come with their own testsuites and those are executed during the build. Afterwards the QA team uses: * benchmarks * stress tests * LSB certification scripts * self-written code * ...
How thorough is your test documentation?
The problem I find at the Uni is that most of the professors are very academic and expound about theoretical techniques etc. which aren't used in industry, and while I've been showing the students what is used on the consultancy side for producing bespoke applications for clients, I thought it would be interesting if I could give them a perspective inside a software house like SUSE and anyone in the community who wants to respond with what specification and testing tools they use, please feel free to chip in.
Information also on the size of the testing lab etc would also be useful.
Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Am Freitag, 17. März 2006 12:09 schrieb Andreas Jaeger:
Let me first say that a distributor does a complete different job than a traditional software house since the majority of our software comes From the Open Source community and we integrate.
I can give you only a high level answer on some parts...
<snip> Thanks for the info Andreas. -- "I got to go figure," the tenant said. "We all got to figure. There's some way to stop this. It's not like lightning or earthquakes. We've got a bad thing made by men, and by God that's something we can change." - The Grapes of Wrath, by John Steinbeck
A few answers on the development front: On Friday 17 March 2006 11:53, David Wright wrote:
Do you use any code generators or is the code 100% hand rolled? If so, what tools do you use?
I use gSOAP to statically generate the SOAP bindings for GroupWise support in KDE. We use Qt Designer heavily for visually generating guis; the resulting XML generates C++ at build time. We use KDevelop for in house development - this does quite a lot for you including generating boilerplate code and build infrastructure which is otherwise quite tedious. It's a KDE tool but can be used for projects on other plaforms. For KDE development a fair amount of boring code is generated by the platform - this includes IPC stubs/skeletons, storage classes (generated at build time) and repetitive GUI elements (menus/toolbars and much of their handling code, generated at runtime from xml descriptions). KDE also has a web services code generator under development; I hope to switch to that from gSOAP in the near future. HTH Will Stephenson
participants (3)
-
Andreas Jaeger -
David Wright -
Will Stephenson