Wie Qualitätskontrolle?

[Jorg3000]

Moin!
Habt ihr Arbeitgeber oder Kunden, wo eure Programme zum Einsatz kommen?
Gibt es da Anfordungen bezüglich Qualitätskontrolle, und wie wird es überprüft?

Bei mir als One-Man-Show läuft es so ab: Wenn ich Änderungen im Quellcode vorgenommen habe, klicke ich im laufenden Programm lustlos in den geänderten Programmfenstern rum, mache widerwillig wenige Testeingaben, und wenn mir keine offensichtlichen Probleme ins Gesicht springen, erteile ich mir und meinem Werk selbstgefällig meinen Segen.
In den allermeisten Fällen geht es gut.

Nun fragt ein Neukunde, zufällig ein Industriebetrieb, in einem Standardformular ab, ob mit Qualitätskontrollplänen, Freigabebestätigungen, Konformitätserklärungen und Abnahmeprüfzeugnisse gearbeitet wird. Und ob regelmäßige Qualitätskontrollen (Produktionskontrollen, Endkontrollen) durchgeführt werden.
Puh, auch wenn sich der Fragebogen eigentlich auf Material bezieht ... Was antwortet man da am besten?

Wie handhabt ihr es selbst mit eurer Software-Qualitätskontrolle?

Grüße, Jörg

[m.fuchs]

Grundsätzlich Unittests auf Grundlage der Anforderungsdokumentation. Sprich beim Definieren der Aufgaben werden schon Beispiel- und Grenzwerte sowie die entsprechenden Ergebnisse vereinbart. Die werden in Unittests umgesetzt und die wiederum bei jedem Commit vom CI-Server geprüft.
Dazu kommen dann Integrationstest, Lasttest, Penetrationtests, etc. je nach Anforderung.

Ansonsten externe Prüfer, die einen Blick von außen drauf werfen. Das hilft meistens sehr. Sowas mache ich auch manchmal bei anderen Unternehmen.

Eine Zertifizierung nach bestimmten Normen ist hingegen eine ganz andere Aufgabe. Aber dazu braucht man meist sowieso entsprechende Experten.
Wobei ja beispielsweise das Wesentliche der ISO 9001 nur bedeutet: "Es darf alles schief gehen, Hauptsache es wurde das Schiefgehen dokumentiert." Naja, ein bisschen komplexer ist es schon noch

Zusammen mit einem definiertem Dokumentationsprozess reicht das meist aus. Überhaupt ist eigentlich das wichtigste dass viel dokumentiert wird. Bugs können immer vorkommen, da hilft keine noch so gute Qualitätskontrolle - aber der Umgang damit sollte klar sein.

Hängt natürlich alles davon ab um was für Software es sich handelt. Die Qualitätsanforderungen für eine Bilderverwaltung sind sicherlich anders als für die Steuerung von Flugabwehrraketen oder Fluglotsensoftware. Aber das dürfte ja jedem klar sein.

[Jorg3000]

Sehr professionell geantwortet Danke!

auf Grundlage der Anforderungsdokumentation

... aber in meinem Fall gibt es kein Lastenheft, da es sich um eine Standardsoftware/Shareware handelt, die sozusagen "wie sie ist" oder "gekauft wie gesehen" bestellt wird.

Deshalb gibt es keine Anforderungen des Kunden, die mir bekannt sind bzw. die ich im Speziellen erfüllen muss.
Somit kann ich keine spezielle Qualitätskontrolle gemäß (nicht vorhandener) Kundenanforderungen durchführen.

Trotzdem muss ich in dem allgemeinen Lieferantenformular irgendein Statement abgeben, im Sinne von "Die Software ist auf Funktionstüchtigkeit getestet".
Aber die abgefragten Verfahren wie Qualitätskontrollpläne, Freigabebestätigungen, Konformitätserklärungen und Abnahmeprüfzeugnisse kann ich nicht vorweisen.

[Socke]

Bei der Software, die wir hier entwicklen (ABAP), gibt es vor Produktivsetzung in der Regel einen manuellen Testlauf durch den Kunden. Dabei werden üblicherweise die geänderte/neue Funktion getestet. Einen Regressionstest gibt es eigentlich nur bei Releasewechseln der Standardsoftware. Abnahmeprotokolle sind je nach Kunden unterschiedlich ausgeprägt: von nicht vorhanden bis Feldern für Unterschriften in Word-Formularen gibt es da alles.

Automatisieurng findet man hier üblicherweise nur wenig. Die Frameworks sind zwar alle da, aber die Kosten für Einrichtung und Schulung werden wohl höher als der Nutzen eingeschätzt.

Auch als One-Man-Show kannst du mit FPTest oder fpcunit sehr schnell einzelne Testfälle absichern. Der Einstieg ist wirklich nicht schwer!

Trotzdem muss ich in dem allgemeinen Lieferantenformular irgendein Statement abgeben, im Sinne von "Die Software ist auf Funktionstüchtigkeit getestet".
Aber die abgefragten Verfahren wie Qualitätskontrollpläne, Freigabebestätigungen, Konformitätserklärungen und Abnahmeprüfzeugnisse kann ich nicht vorweisen.

Dann darfst du dir deinen eigenen Releaseprozess ausdenken und dokumentieren. Alles andere gibt es nicht, da es Standardsoftware ist bzw. "werden für kundenspezifische Entwicklungen in Abstimmung mit dem Kunden definiert".

[Jorg3000]

Danke für die Verweise auf die TestUnits sowie das Stichwort "Releaseprozess dokumentieren".

Wenn ich so darüber nachdenke, ist meine Arbeitsweise nicht so furchtbar, wie ich sie im Einstiegspost extra ins Lächerliche gezogen habe.
Ich habe die Vorgehensweise, die ich mir (leider nur autodidaktisch) angeeignet/angewöhnt habe, nur noch nie aufgeschrieben oder in schöne Worte gepackt.

Ein paar Stichworte, die mir gerade einfallen:
- Vor jeder Änderung überlege ich, welche Seiteneffekte es haben könnte - und schaue es vorab im Source nach.
- Bei jeder Ansicht von Quellcode schaue ich, ob er noch meinem aktuellen Kenntnisstand von "good practice" entspricht.
- Änderungen werden dokumentiert: im Detail im Source selbst, und grob in einem ChangeLog.
- Von früheren Versionsständen habe ich Kopien.
- Neue Methoden statte ich mit Plausibilitätsprüfungen und Fehlermeldungen aus.
- Nach Änderungen teste ich alle abhängigen Programmteile einzeln.
- Freigabe erst, nachdem ich mir (Tage später) sicher bin, nichts übersehen zu haben.

Wahrscheinlich lassen sich dafür mehrere schöne Fachbegriffe finden, die ich einfach nur nicht kenne. Ich muss mir über das Thema mal Gedanken machen und es gescheit dokumentieren. Man wächst schließlich mit seinen Aufgaben.

[m.fuchs]

auf Grundlage der Anforderungsdokumentation

... aber in meinem Fall gibt es kein Lastenheft, da es sich um eine Standardsoftware/Shareware handelt, die sozusagen "wie sie ist" oder "gekauft wie gesehen" bestellt wird.

Hast du einen Bugtracker in dem die Bugs und neue Features einpflegst? Das reicht ja schon um eine Anforderungsdokumentation vorzuweisen.

Deshalb gibt es keine Anforderungen des Kunden, die mir bekannt sind bzw. die ich im Speziellen erfüllen muss.
Somit kann ich keine spezielle Qualitätskontrolle gemäß (nicht vorhandener) Kundenanforderungen durchführen.

Dann bist du selber der Kunde der die Anforderungen vorgibt. Du musst nur aufschreiben welche Features du einpflegen willst, welche Bugs zu beseitigen sind und nach welchen Kriterien du testest.

Trotzdem muss ich in dem allgemeinen Lieferantenformular irgendein Statement abgeben, im Sinne von "Die Software ist auf Funktionstüchtigkeit getestet".
Aber die abgefragten Verfahren wie Qualitätskontrollpläne, Freigabebestätigungen, Konformitätserklärungen und Abnahmeprüfzeugnisse kann ich nicht vorweisen.

Wenn du Unittests einsetzt, könntest du einen schönen Report anhängen der dann zeigt:

• Anzahl der Unittests
• Anzahl der erfolgreichen Testfälle (sollte 100% sein)
• Prozentangabe zur Testabdeckung des Quellcodes
• weitere schöne Grafiken...

Dazu noch ein dokumentierter Releaseprozess wie von Socke vorgeschlagen und du bist auf dem richtigen Weg,

[kupferstecher]

Trotzdem muss ich in dem allgemeinen Lieferantenformular irgendein Statement abgeben, im Sinne von "Die Software ist auf Funktionstüchtigkeit getestet".

Aber nicht, dass du dir je nach Formulierung noch Haftungen einhandelst.

[af0815]

Es ist kundenspezifisch bei uns.

Allgemeine Basis ist, das ein Softwareverwaltungstool als erstes eingesetzt wird. In diesen werden die Änderung des Quellcodes hinterlegt, aber zugleich auch die Projektdokumentation. Auch mit den Listen, was wurde wann besprochen bzw. wie soll es umgesetzt werden. Wenn es sinn macht werden hier auch Hanschriftliche Notizen als Scan hinterlegt. Damit ist auch das wachsen der Doku bzw. der Anforderungen dokumentiert.

Unittests für die Grundfunktionen, ohne GUI. Sprich, es wird in Absprache mit dem Kunden die Verarbeitung der Daten getestet, allerdings wird die GUI nur in Abnahmeläufen getestet um Aufwand (=Kosten) zu sparen. Das geht auch deswegen, weil es meistens nur Anzeigebildschirme sind und keine intensive Schnittstelle Mensch-Maschine gibt. Das wird so von unseren Kunden aktzeptiert.

Das wichtigste ist das Softwareverwaltungstool, damit kann man auch genau sagen, wann wurde eine Änderung gemacht (und warum) die etwas ausgelöst hat.

[hum4n0id3]

- Vor jeder Änderung überlege ich, welche Seiteneffekte es haben könnte - und schaue es vorab im Source nach.

Hier hilft sauberes Arbeiten und das einhalten von bestimmten Design-Pattern.

- Bei jeder Ansicht von Quellcode schaue ich, ob er noch meinem aktuellen Kenntnisstand von "good practice" entspricht.

Genau. Nach Allgemeinen und speziell für Lazarus Code Conventionen suchen. Ordentlliche Variablen, kein vermischen von Logiken usw.

- Änderungen werden dokumentiert: im Detail im Source selbst, und grob in einem ChangeLog.
- Von früheren Versionsständen habe ich Kopien.

Dafür gibt es Versionsverwaltungstools wie Git, SVN usw. Der neueste Schrei, wenn man sowas überhaupt noch nicht gemacht hat, ist Git. Hier siehst du deine Änderungen und kannst auch auf frühere Versionen einfach springen. Änderungen zurück nehmen und schauen, wer was gemacht hat. Aus Git, SVN lassen sich dann auch Changelogs erstellen.

- Neue Methoden statte ich mit Plausibilitätsprüfungen und Fehlermeldungen aus.
- Nach Änderungen teste ich alle abhängigen Programmteile einzeln.

UnitTests und wenn ein neues Projekt gleich mit TDD (Test Driven Development) anfangen. Hier schreibst du deinen Code der gleich getestet wird. Ich weiß nicht wie es unter Lazarus ist, aber in der Webentwicklung gibt es schon zahlreiche Tools die deine Entwicklung mit überwachen. Überwachen nicht im Sinne von Spionieren. Für gängige Sprachen wird es sicherlich ähnlich aussehen.

- Freigabe erst, nachdem ich mir (Tage später) sicher bin, nichts übersehen zu haben.

Aus meiner Erfahrung heraus. Ich hatte am Anfang, wo ich gelernt habe wie man Programmiert, hatte ich viele Schwierigkeiten. Ich habe in einer Firma gearbeitet, wo der Code nichts sagend war, technisch (HTML, JS, CSS, SQL und PHP) total vermischt und Spaghetticode. Keiner hat sich da mehr sonderlich ausgekannt. Meine Projekte habe ich versucht technisch immer zu trennen und bestimmte Regeln zu befolgen. Was mich zu allgemeinen DesignPattern (MVC, etc.) gebracht hatte. Das hat mein Entwicklerleben enorm erleichtert. Mit Einsatz von Git, in der Firma hatten wir SVN, ist meine nächste Hürde gefallen. Ich hatte verschiedene Versionen auf der HDD, oder DVD oder USB-Stick. Nachdem ich Anfänglich mich mit Git beschäftigt habe und mir mehrere GitHub-Accounts angelegt hatte, ist diese selbst gebastelte aus verschiedenen Medien dann gestorben. Ich mache kein Projekt mehr ohne Git. Anbieter gibt es verschiedene und einen Git-Server kann man auch selbst betreiben. Schon hier ist mir viel an Verwaltung weg gefallen. Später habe ich mit UnitTests und TDD angefangen. Ich verstehe sicherlich nicht alles und kann noch nicht alles Testen, weil Verständnis fehlt, aber diese Hürde fällt auch nach und nach. Ich erstelle mir automatisiert eine Code-Coverage und sehe dann was nicht gestestet wurde, was getestet wurde usw. Und dass alles fast nebenher, wenn du deinen Code schreibst Das ist einfach Toll!

Wahrscheinlich lassen sich dafür mehrere schöne Fachbegriffe finden, die ich einfach nur nicht kenne. Ich muss mir über das Thema mal Gedanken machen und es gescheit dokumentieren. Man wächst schließlich mit seinen Aufgaben.

Einfach nach Begriffen wie TDD, Software testen usw. suchen und du solltest schon vieles finden. Auch von Bezahlten Kursen zu diesem wichtigen Thema nicht zurück schrecken. Meiner Erfahrung nach entsteht eine gescheite Dokumentation, während der Planungsphase. Wenn du deine Software bereits schreibst, bevor du dir da ordentlich Gedanken darüber gemacht hast, läuft schon einiges Schief Programmierung ist schließlich die Umsetzung aus der Plannung heraus und für die Kommentare aus dem Code, gibt es wiederum Tools die eine daraus automatisch eine technische Dokumentation bauen.

Edit: Siehe, Anhang. Weil ich jetzt mehrere ältere Projekte zu einem großen Webprojekt zusammen schweiße, übernehme ich den alten Code und teilweilse refactore ich das. Weil hier zumindest teilweise auch alte Tests existieren, kann ich diese Tests auch nutzen um zu sehen ob alles in Ordnung ist.

Ich weiß sowieso das es knallen wird und auch wo, weil ich noch nicht alles übernommen habe. Aber bei diesen Tests weiß ich, das ich mich darauf verlassen kann. Ist das alles gemacht und es findet später eine Codeänderung statt, finde ich das auch schnell heraus

[hum4n0id3]

So kann es dann aussehen wenn alle Tests wieder angepasst sind.

Also mit gewissen Werkzeugen lässt sich die Arbeit und die Code-Qualität enorm erleichtern. Und das kann man dem Kunden dann auch mit gutem Gewissen weiter geben.

[siro]

Softwaredokumentation kann wirklich sehr komplex werden wie ich in den letzten Jahren feststellen musste.
2017 habe ich einen Lehrgang IEC 62304 besucht (life cycle requirements for the development of medical software)
danach wusste ich (nach 35 Jahren Elektronik/Software Entwicklung), dass ich meinen Beruf verfehlt habe....

Aber zum Thema Integratioss/Unittests habe ich mal eine kurzes Dokument erstellt, was ich euch, geringfügig geändert, mit anhänge.
Einfach mal um zu zeigen was trotz ausgiebiger Tests schief gehen kann.

[af0815]

- Vor jeder Änderung überlege ich, welche Seiteneffekte es haben könnte - und schaue es vorab im Source nach.

Hier hilft sauberes Arbeiten und das einhalten von bestimmten Design-Pattern.

Zu dem Thema sage ich nur Kapseln und mit Schnittstellen arbeiten. Nur dort eine Vererbung, wo es Sinn macht, aber nicht die Vererbung als Schnittstelle verwenden.
Wenn Code gekapselt ist und mit Schnittstellen versehen, so lässt er sich auch besser testen. Und diese Tests können mit dem Code ausgelagert werden. Damit hat man im Laufe der Zeit eine Art stabilen Baukasten, der ohne große Überraschung ist und vor allen keine Seiteneffekte mehr hervorrufen kann.

[TSchnuckenbock]

Unsere Software wird hauptsächlich intern im Betrieb eingesetzt und bei ein paar externen Kunden.

Ich bin auch eine One-Man-Show: Abteilungsleiter, Senior Software Developer etc.... alles in einer Person.

Wie hat sich der Prozess zur Qualitätssicherung bei uns entwickelt? Ich weiß nicht mehr, was zuerst da war, ob Subversion, Bugtracking-Software oder der ISO-Onkel bzw. die Dame, die vorher immer das interne Audit macht.

Mein Ablauf: Kollegen oder Kunden haben ein Wunsch-Feature, Verbesserungsvorschläge oder einen Fehler entdeckt. Das trage ich dann in den "Bugtracker" ein. Damit hat das Ding eine Nummer, z.B. "#7623".
Mache ich mich an die Arbeit, dann schreibe ich diese Nummer inkl. kleinem Text an den Stellen im Code als Kommentar mit rein, an denen ich Änderungen vornehme, inkl. dem codierten Datum.
Sobald ich der Meinung bin, alles ist fertig und läuft rund, checke ich das in SVN ein inkl. Text dazu, was geändert, ergänzt oder gefixed wurde. Die Tests mache ich manuell während der Entwicklung erstmal selber.
Im "Bugtracker-Tool" wird nach Fertigstellung der Ergänzung/Änderung ein Eintrag gemacht bzw. ein Haken hinter dem ToDo/Bug.
Hab ich genug zusammen für einen neuen "Release", dann gebe ich eine Testversion an einige ausgewählte interne Kollegen raus, die mit der Software täglich arbeiten. Dokumentation wieder im Bugtracker....Testversion rausgegeben an blablabla.
Dabei gebe ich Hinweise, was sich geändert hat und warauf sie zu achten haben. Das ganze noch in Schriftform als PDF, was sich dann "Release Notes" nennt. Diese Version hat dann auch eine fixe Versionsnummer.
Machmal bekommen die Kollegen ein komplettes Notebook, auf dem die Testverson installiert ist. Damit will ich verhindern, daß es zu Durcheinander kommt und die Testverison vor der Freigabe in die freie Wildbahn entfleucht.
Decken meine testenden Kollegen einen bösen Bug auf, dann blase ich die Testphase ab (einmal vorgekommen in den letzten 15 Jahren).
Läuft alles nach Wunsch und wurden alle (möglichst viele) Features der Software getestet, dann protokolliere ich das entsprechend im Bugtracker, wenn ich die Version dort zum Release erkläre. Alle Änderungen seit der letzten Release-Version werden dann auch nochmal dokumentiert.
Anschließend erhöhe die Versionsnummer für die dann zukünftige Entwicklung.
Ach ja, und ich checke jede Release-Version selber in ein Release-Verzeichnis auf meinem Rechner aus. Dadurch habe immer jede Release-Version zackzack verfügbar, falls mal ein Anruf kommt von wegen dies oder das geht nicht in Version XYZ.
Während der Entwicklung checke ich nur ins SVN ein, wenn ich eine Änderung vollständig umgesetzt habe. Zwischensicherungen mache ich auf externer USB-Festplatte.

Die Release-Notes zu jeder Version waren ein Wunsch vom ISO-Mann, was sich sehr bewährt hat. Da schreibe ich auch rein, wie z.B. ein neues Faeture zu bedienen ist. Das ganze ist natürlich mit im ganzen Projekt-Verzeichnis im SVN-System.
Bisher bin ich durch jedes Audit ohne Meckerei durchgekommen. Einige Auditoren haben sich sogar lobend in der Chef-Etage geäußert, wie toll ISO9001 ihn meiner Abteilung "gelebt" wird. Das ist ein Vorteil, wenn man Einzelperson in einer Abteilung ist. Da weiß man jede Sache, die nicht ganz safe bzgl. ISO ist......und kann das umschiffen.

Was will ich an diesen Abläufen zukünftig ändern? Das Bugtracking-Ding ist nicht das feinste. Das will ich ersetzen durch was besseres, falls ich mal dazu komme bzw. auch weiß, was tauglicher ist.