Die hohen Summen, die große Firmen (Banken und Versicherungen etwa) für Software-Test ausgeben, wären mit Sicherheit deutlich besser angelegt, wenn man sämtliche Tester zwingen würde, weit detaillierter als bisher zu belegen,
Derzeit werden Tester viel zu sehr sich selbst überlassen: Ihre Effektivität zu messen und gezielt zu steigern wird kaum versucht (!).
Lese auch:
Wissenschaftliche Untersuchungen (z.B. eine der Carnegie Mellon University aus 2003) belegen, dass moderne Software, wenn sie in Betrieb genommen wird, i.A. immer noch bis zu fünf Fehler pro 1000 Lines of Code enthält; sprich: etwa 1 Fehler auf je 3 DIN A4 Seiten manuell erstellten Source Codes.
Selbst in den besten aller je untersuchten (größeren) Programme fand sich immer noch 1 Fehler in je 7500 Zeilen Code.
Wären mathematische Publikationen auch nur annähernd so fehlerhaft, wäre die Mathematik als Wissenschaft sicher längst in sich zusammen gebrochen (denn dort bauen neue Ergebnisse ja stets auf älteren auf).
Wir sehen: Die Informatik — wenigstens aber ihre Technik zur Qualitätssicherung — steckt heute wohl noch in Kinderschuhen, die vergleichbar sind mit denen, die die Mathematik zu Zeiten von Aristoteles, Pythagoras und Euklid trug.
Wissenschaftler aus München berichten (siehe Demystifying Maintainability):
"In 2003 we conducted a study on software maintenance practices in German software organizations. Interestingly, of the 47 respondents only 20% did specific checking for maintainability during quality assurance".
Frage: Liegt das daran, dass es Unternehmen, die Software für Kunden produzieren, völlig gleichgültig sein kann, wie teuer den Kunden später die Wartung dieser Software kommt?
Wenn ja: Kann dem Auftraggeber solche Haltung wirklich gleichgültig sein? Warum unternimmt er i.A. gar nichts, um sicherzustellen, dass er gut wartbare Software bekommt (solche also, bei der die Total Cost of Ownership gering ist)?
Gartner as well as Cutter Consortium tell us about more and more clients who realize that agile methods — if defined by XP, SCRUM, or the Agile Manifesto — let developers forget that they should also think about product features that are to guarantee maintainability of the software in the long run.
And indeed: So far the problem is that in contrast to a Software Owner (a CIO), the typical Product Owners in the sense of SCRUM do not think beyond the development phase of the software life cycle.
After trying out Agile for some years, CIOs more and more realize that teams doing agile software development left chaos: software that is neither well defined nor easy to maintain.
Evangelists of Agile should accept that Software Owners are stakeholders quite different from Product Owners and that therefore Agility as defined by the Agile Manifesto is far from being professional enough.
This is why we need
A process model for software development not ignoring CIO’s interest is Specify, Subcontract, Test (SST).
Der internationale Standard ISTQB will vollständige Sammlung all dessen sein, was Praktiker und Theoretiker bisher an Testmethodik erarbeitet und zusammengetragen haben.
Leider wird in den zur ISTQB-Zertifizierung führenden Kursen viel zu wenig unterschieden zwischen praktikabler Methodik einerseits und wenig praktikabler andererseits.
Der wirklich in jedem Testprojekt praktikable Teil ist beschrieben in
Wer darüber hinaus weitere praktische Anleitung sucht, dem empfehle ich zu lesen:
One fact is: The world around us is moving faster and faster, and so we must learn to become agile (in software development, but also in project management and everywhere else).
Fact is also: The still ongoing, now already more than 10 years old discussion about how to be agile (especially when developing software) so far did not generate much progress.
The reason for this sad fact clearly is that the Agile Manifesto is leading us into a wrong, less professional direction.
Why this is so and why, therefore, we need to focus on the goal of Agile rather than on the misleading way suggested by the Manifesto, is convincingly explained in the document The New (2011) Definitions of Agile.
To read that paper (2 pages only) is a MUST for everyone interested in Agile.
By far the best introduction to Agile is the short article Best Practice Agile.