Auflistung nach Autor:in "Seidl, Richard"
1 - 2 von 2
Treffer pro Seite
Sortieroptionen
- ZeitschriftenartikelSoftware Testdokumentation nach den IEEE und ISO Standards(Softwaretechnik-Trends Band 37, Heft 1, 2017) Sneed, Harry; Seidl, RichardTest documentation is needed not only to assess the extent and quality of a test but also to assess the productivity of testers and to tie the test to the software architecture. Decision makers and auditors need test documentation to decide whether to release a version or not. Maintainers need test documentation to see how changes can be tested. Testers need test documents to help them identify the causes of errors. Finally auditors require a documentation of the test to confirm that the product has been adequately tested. Test documents are prescribed by prevailing IEEE and ISO standards. Originally they were prepared by hand. Today they are most often generated automatically as a byproduct of the test automation. The demand for test documentation goes back to the early days of testing when the US military was testing the ballistic missile defense system. The tool RXVP – Research and Evaluation Package – instrumented the Fortran code to trace execution paths through the system and to measure the degree of test coverage. Branch coverage was considered at that time to be an important criteria for determining how well the software was tested [Miller, 1979]. It was also important to register the paths that were taken through the network of code modules in order to be able to reconstruct the tests. Shortly thereafter the IEEE published the Standard ANSI/IEEE-829 for Software Test Documentation. The first version appeared in 1983. It was later revised in 1998 [ANSI/IEEE, 1998]. It is interesting to note that this first general test standard was entitled test documentation and not just system testing. It emphasized what should come out of a system test – the results. Later in 1987 another corresponding standard for unit testing – ANSI/IEEE Std. 1008 – was published. That standard put much less emphasis on documentation, i.e. what should be delivered, and instead emphasized the process, i.e. how software units should be tested [ANSI/IEEE, 1993].
- KonferenzbeitragUnser Weg zur agilen Entwicklung – Eine Retrospektive(INFORMATIK 2013 – Informatik angepasst an Mensch, Organisation und Umwelt, 2013) Seidl, RichardVor zwei Jahren begann für die beiden größten Entwicklungsprojekte der GETEMED AG der Übergang von einem klassischen zu einem agilen Entwicklungsvorgehen. Eine große Herausforderung, denn ein effizienter, agiler Entwicklungsprozess in der Medizintechnik muss sowohl die geforderten Regulatorien erfüllen, aber auch - und das ist genauso wichtig - den Entwicklern und Testern die Freiheit geben ihren Job zu machen: ein Produkt zu entwickeln, das höchsten Qualitätsansprüchen gerecht wird und den Anwendern einen großen Nutzen bringt. Während der Umstellung stießen wir immer wieder auf neue Situationen: "traditionelle" Entwickler und Tester, die ihre Arbeitsweise nicht mehr ändern mochten; neue Entwicklungsteams; neue Technologien; wenig Erfahrung und hohe Erwartungen. So stellte sich bald die Erkenntnis ein: Es geht hier nicht um einen neuen Prozess, sondern um einen Kulturwandel in den Entwicklungsteams und im Unternehmen. Dieser Vortrag im Rahmen des Workshops „SAG WAS - Studentische AusbildunG und berufliche Weiterbildung in Agiler Softwareentwicklung“ beschreibt einige unsere größten Probleme, Fehler und Erfolgsfaktoren bei der Einführung eines agilen Entwicklungs- und Testvorgehens. Zudem wird gezeigt, welche agilen Praktiken uns am meisten geholfen haben die Entwicklung effizient und nutzbringend zu gestalten.