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