Qualitätsbewusstsein

[Namenloser]

Ich finde Unit-Tests vor allem am Anfang hilfreich, wenn das Programm noch nicht so weit fortgeschritten ist, dass man es als ganzes testen kann.

Und später können die Tests gegen Regressionen helfen.

[jaenicke]

Zitat:

Zitat von Nersgatt (Beitrag 1251824)

Unittests sind sicher nicht das Allheilmittel in der Softwareentwicklung/Qualitätssicherung. Sie sind nur ein kleiner, hilfreicher Baustein.

Deshalb macht es ja auch vor allem Sinn damit häufig benutzte Programmteile zu testen, eben z.B. Hilfsklassen wie bei uns. Denn Änderungen daran könnten sich sonst katastrophal auswirken ohne dass das bemerkt wird.

[Phoenix]

Zitat:

Zitat von Namenloser (Beitrag 1251821)

Ich hab für meinen Code am Anfang noch Tests geschrieben, aber später hab ich es dann selber auch nicht mehr gemacht, weil die Zeit besser darin investiert ist, den Code von den anderen zu überarbeiten...

Achja und ich glaube, das hat mit der Ausbildung gar nicht so viel zu tun. Scheint mir eher eine Mentalitätssache zu sein.

Naja, da beisst sich die Katze in den Schwanz. UnitTests sind ja eigentlich genau dafür da, das man Code überarbeiten / refaktorieren kann ohne das einem die Änderungen irgendwo anders auf den Fuss fallen.

Wenn das Unternehmen ein wirkliches Interesse an Code Qualität hat, dann kann man das auch recht einfach hinbekommen.
1.) Code Coverage automatisieren und die Reports regelmäßig nach den Checkins ausführen.
2.) Jedem Entwickler in die Zielvereinbarung schreiben, dass sich die prozentuale Testabdeckung permanent erhöhen muss.

Das sorgt für: Jeder neue Code ohne Tests verringert die Testabdeckung. Das senkt die Prämie des Entwicklers und geht direkt ans Geld. Der Entwickler wird im Umkehrschluss Unit Tests schreiben um seine Prämie zu sichern. Damit sichert er seinen Code auch ab. Win-Win :)

[OlafSt]

Ich gestehe, das ich auch mal solchen Mist gebaut habe. Allerdings hatte ich damals 13 Projekte gleichzeitig abzuwickeln, drei davon der >5Mio-Zeilen-Klasse. Es gab Tage, da bin ich durch 8 der 13 Projekte gehüpft, um irgendwas zu testen, einen Bedienungsfehler des Kunden wasserdicht nachzuweisen (unsere QA war der Meinung, das müsse so sein), evtl. Bugs fixen. Ein Alptraum.

Ich hab das eineinhalb Jahre durchgehalten... als ich nach vier Monaten aus der Reha wegen BurnOut zurückkam, wurde nach Ursachen geforscht und das ganze Zeit- und Projektmanagement komplett umstrukturiert. Schade, das der Laden dann 8 Monate später von den Chinesen geschluckt wurde.
Seither produziere ich wieder brauchbaren Code, allerdings noch immer ein Stück weit entfernt von Bugfrei. Hier ist es aber wieder wie mit dem Korrekturlesen: Das sollte nie derjenige machen, der es erstellt hat, egal ob Programm oder Textdokument.

[BUG]

Zitat:

Zitat von Phoenix (Beitrag 1251945)

UnitTests sind ja eigentlich genau dafür da, das man Code überarbeiten / refaktorieren kann ohne das einem die Änderungen irgendwo anders auf den Fuss fallen.

Allerdings ist das schwerer umzusetzten, wenn der entsprechende Code nicht funktioniert und schlecht testbar geschrieben ist :mrgreen:

[Furtbichler]

Zitat:

Zitat von Nersgatt (Beitrag 1251824)

Außerdem, wenn eine Software alle Tests besteht, heißt das noch lange nicht, dass die Software das macht, was der Kunde erwartet.

Doch. Genau dafür sind Unittests gemacht: Sie implementieren die Spezifikation und prüfen anhand der Assertions, ob diese eingehalten wird. Es ist Sache der Spec, die Erwartungen der Kunden korrekt zu formulieren.

Zitat:

Zitat von Phoenix (Beitrag 1251945)

Wenn das Unternehmen ein wirkliches Interesse an Code Qualität hat, dann kann man das auch recht einfach hinbekommen.
1.) Code Coverage automatisieren und die Reports regelmäßig nach den Checkins ausführen.
2.) Jedem Entwickler in die Zielvereinbarung schreiben, dass sich die prozentuale Testabdeckung permanent erhöhen muss.

:thumb: Aber irgendwie blöd, wenn er schon bei 100% ist :stupid:
Ich schaffe locker 100% bei den meisten Klassen: 50-70% sind wirkliche Tests und der Rest blöde Tricks, um das Coverage Tool zufrieden zu stellen. Die 30-50% würde ich mir dann aufheben, um die Zielvereinbarung zu erfüllen: Immerhin, die wirklichen Tests hätte ich ja schon und die Win-Win-Situation bleibt.
Aber leider ist Code Coverage keine wirklich gute Maßzahl für Softwarequalität. Wie ich schon schrieb: (Imho) besser als nichts. Gibt es wirklich nichts Besseres?

[samso]

Zitat:

Zitat von Furtbichler (Beitrag 1251961)

Es ist Sache der Spec, die Erwartungen der Kunden korrekt zu formulieren.

Womit die Verantwortung für die Produktqualität erfolgreich zu einer anderen Abteilung verschoben wurde. Genau deshalb laufen die Großprojekte von Siemens, T-Systems usw. regelmäßig gegen die Wand. Die Indianer wissen zwar genau, dass das Produkt so nicht funktionieren wird, aber niemand traut sich den Häuptlingen das mal mitzuteilen. Alternativ wird es dem Häuptling zwar mitgeteilt, aber der kann oder will die Konsequenzen nicht ziehen - ich sage nur BER.

[Nersgatt]

Zitat:

Zitat von Furtbichler (Beitrag 1251961)

Es ist Sache der Spec, die Erwartungen der Kunden korrekt zu formulieren.

Das ist schon klar. Nur leider lehrt die Praxis, dass oftmals nicht mal die Kunden selbst in der Lage sind, ihre eigenen Erwartungen in Prosa zu formulieren.

[Bernhard Geyer]

Zitat:

Zitat von samso (Beitrag 1251963)

Zitat:

Zitat von Furtbichler (Beitrag 1251961)

Es ist Sache der Spec, die Erwartungen der Kunden korrekt zu formulieren.

Womit die Verantwortung für die Produktqualität erfolgreich zu einer anderen Abteilung verschoben wurde.

Sobald SW-Projekte etwas größer werden weiß der Kunde ja auch gar nicht was er ganau will. Ein bis ins Detail formulierte Spec ist etwas was man zwar aufwendig Erstellen kann, aber man weiß das es sich während des Projekts ändert. Es wurde also nur so Umfangreich erstellt um den Wasserfallprozess zu genügen.

Zitat:

Zitat von samso (Beitrag 1251963)

Genau deshalb laufen die Großprojekte von Siemens, T-Systems usw. regelmäßig gegen die Wand. Die Indianer wissen zwar genau, dass das Produkt so nicht funktionieren wird, aber niemand traut sich den Häuptlingen das mal mitzuteilen.
Alternativ wird es dem Häuptling zwar mitgeteilt, aber der kann oder will die Konsequenzen nicht ziehen

Für solche "Schwarzseher gibts doch die Phrasen "Das schaffen wir schon". "Machen sie mal. Die probleme lösen sich dann schon".
Man sollte dann in solchen Projekten rechtzeitig den Absprung schaffen das man nicht zum Schluss den Projektleiterposten bekommt um nur das Scheitern zu verkünden.

Zitat:

Zitat von samso (Beitrag 1251963)

- ich sage nur BER.

Ich glaube bei BER sind noch viel andere Probleme wie "Viele Köche verderben den Brei" vorhanden.

[Phoenix]

Zitat:

Zitat von Furtbichler (Beitrag 1251961)

Zitat:

Zitat von Nersgatt (Beitrag 1251824)

Außerdem, wenn eine Software alle Tests besteht, heißt das noch lange nicht, dass die Software das macht, was der Kunde erwartet.

Doch. Genau dafür sind Unittests gemacht: Sie implementieren die Spezifikation und prüfen anhand der Assertions, ob diese eingehalten wird. Es ist Sache der Spec, die Erwartungen der Kunden korrekt zu formulieren.

Ne. Nersgatt hat schon recht: Unit-Tests testen nur die kleinste Einheit.

Ich kann komplett Bugfreie Units schreiben, die 100% meines Codes abdecken.
Dann kann ich die aber so falsch zusammenstöpseln das kein einziger Integration-Test glückt.
Ich kann die aber auch korrekt zusammenstöpseln, das die Intgeration Tests funktionieren.
Das ich eine Zahl korrekt am UI eingebe, durch das Business Layer schiebe und in die DB bringe heisst aber auch noch lange nicht, das das auch die Funktionalen Tests erfüllt.
Wenn die Funktionalen Tests erfolgreich sind, muss die komplett-Anwendung aber immer noch nicht laufen. Hier muss ich erst die Acceptance-Tests berücksichtigen und zum laufen bringen.

Wie man sieht ist Testing eine - im wortwörtlichen Sinne - vielschichtige Angelegenheit. ;-)