Doch je früher die Schätzung vorliegt, desto angemessener kann auf eine gegebene Angebotslage reagiert werden. Wir alle kennen Projekte, in denen noch vor guten Anforderungen an das System Schätzungen (am Besten in 10 Minuten) abgegeben werden sollen. Skizzen, wage Ideen, bessere Konzepte und Phrasen wie “sollte halt so aussehen wie” sind typische Indikatoren für diesen Zeitpunkt. Die vom System verlangte Qualität lautet oft bestechend einfach: “Hauptsache es läuft bis zum Datum X.“

Jede Schätzung – und sei sie noch so ungenau – ist zu diesem Zeitpunkt besser als keine Schätzung. Dass zu einem frühen Termin die Informationsgrundlage (Anforderungen) oft nicht vorhanden bzw. sehr instabil sind, die Qualität der Schätzung somit ein hohes Risiko birgt, muss als Risiko betrachtet werden. Oft gilt fürs Management an dieser Stelle: geschätzter Abgabetermin in frühestens X Tagen = Abgabetermin in X Tagen („date driven estimates“). Das ist einfach, das ist positiv, aber leider auch eher unwahrscheinlich. Ausbaden muss dann diesen Trugschluss oftmals der Projektleiter.

Geben Sie zu jeder Schätzung deren Wahrscheinlichkeit an. Auch mit schlechten Anforderungen an das neue Projekt empfehlen wir als ersten Schritt “grobe Cluster” über den zu migrierenden/zu konvertierenden Daten und den neu zu entwickelnden Teilen in der Software zu bilden. Die identifizierten Cluster müssen für eine erste Schätzung getrennt betrachtet werden. So kann Migrationsaufwand etwa auf Stundenbasis bestimmt werden. Neu zu entwickelnde Bereiche hingegen können durch das “One File Model” der Funktionspunkt-Analyse geschätzt werden, indem identifizierte Software-Einheiten mit empirisch gewonnenen Werten multipliziert werden (erstaunlicherweise bringen uns diese Werte sehr nahe an die Projektwahrheit heran). In Bereichen, in denen die Funktionspunkt-Analyse nicht sinnvoll verwendet werden kann, könnten historische Werte, z.B. aus ISBSG (International Software Benchmarking Standard Group), einer Datenbank mit über 5000 Referenzdaten aus Softwareprojekten, herangezogen werden, um über einen Abgleich mit den bereits jetzt vorliegenden Indikatoren ein ähnliches Referenzprojekt mit belastbaren Werten zu finden. Aufwände hingegen für noch unklare “Nichtfunktionale Anforderungen” sollten über die vergangenen Jahre herangezogen werden können (ebenfalls etwa in Form von Funktionspunkten). Hier gilt außerdem: die Komplexität, die man auch hinter noch unklaren Nichtfunktionalen Anforderungen vermutet, kann kaum überschätzt werden (auf ein “Oh mein Gott, das ist ja viel einfacher als ich vermutet habe!” stoßen wir hier eher selten). Auch technische Besonderheiten sollten mit in die Schätzung einfließen, um gegenüber unerwarteten Überraschungen gewappnet zu sein.

Wir empfehlen (nachhaltig!) Annahmen, die über die kommenden und laufenden Projekte getroffen werden, zu dokumentieren. Wie gesagt: aus der vorhandenen Informationsgrundlage resultiert die Qualität einer Schätzung. Oftmals scheitert das Verfahren sonst bzw. verliert an seiner Qualität. Frühzeitige Schulungen zu Workshops über “Schätzverfahren mit Funktionspunkt-Analyse” bei Knowledge Department können die Qualität ihrer Schätzverfahren weiterhin deutlich verbessern. Außerdem möchten wir es an dieser Stelle nicht versäumen, auf die Ergebnisse zu Schätzungen in Software-Projekten von “Carol Dekkers” hinzuweisen.

Ihr Wissen können Sie auch ausbauen in den ISTQB Certified Tester-Tester- und in den Requirements Engineering-Kursen von Knowledge Department.

Diesen Artikel Bookmarken

In der Praxis fehlen uns Testern hier oftmals ganz grundlegende Parameter. Anforderungen von minderwertiger Qualität (oder deren vollkommene Abwesenheit) ist eher die Regel als eine Ausnahme. Eine „Testbarkeit“ der Anforderungen, was einem Qualitätskriterium an Anforderungen entspricht, ist dann natürlich auch nicht gegeben. Das ist unsere Herausforderung.

Test-Analysten sind die fachlichen Systemtester. Nur durch „kennen“ und „können“ geeigneter Techniken wird es ihnen möglich, die fachliche Funktionalität durch einen systematischen Test umfassend zu prüfen. Eine Technik, die wir unsere Teilnehmer im Advanced-Kurs „Technical Test Analyst“ schulen, die sowohl die Testbarkeit der Anforderungen fördert als auch für den späteren Black-Box-Test verwendet werden kann, ist die „Entscheidungstabelle“.

Stellen wir uns folgendes Szenario vor:
Wir befinden uns in einer frühen Entwicklungsphase, der Anforderungsdefinitionsphase. Tester und Entwickler arbeiten bereits hier eng zusammen. Bevor die Anforderungen tatsächlich ausgeschrieben werden, soll der Test Analyst sicherstellen, dass die Anforderungen später (Systemtest, Abnahmetest) auch testbar sind. Hierbei trifft er auf die folgende Anforderung:
„Falls der der Wartungsserver ein Update (A) oder falls das KM-System ein Deliverable anbietet (B) und unter der Bedingung, dass kein Mitarbeiter am Server angemeldet ist (C), muss das System selbständig in den Modus „Wartung“ wechseln.“
Hier leicht irritiert sein wäre vollkommen normal, denn rein logisch betrachtet ist diese Anforderung an das „Soll“ des Systems weitgehend unklar – der fachliche Test wäre damit auch „nicht testbar“. Es stellen sich hier die folgenden Fragen:
• Kann zeitgleich ein Update und ein Deliverable angeboten werden? Falls ja – brauchen wir Prioritäten? Welche wäre das? Falls nein – wie soll sich das System verhalten?
• Welcher Operator wird zuerst betrachtet? „Und“? „Oder“?
• Darf ausschließlich bei einem Update kein Mitarbeiter am Server angemeldet sein oder wird hier auf das Deliverable Bezug genommen? Bezieht sich der Relativsatz auf beides?
Unklarheiten in der Spezifikation führen zu Unklarheiten beim späteren Test. Durch das frühe Einbinden des Test Analysten können aus der Not getroffene und dann auch sehr wahrscheinlich „falsche“ Entscheidungen vermieden werden. „Sehr wahrscheinlich“ deswegen, weil die Wahrscheinlichkeit des Programmierers hier die richtige Entscheidung zu treffen, bei knapp über 10% liegt, denn logisch möglich wären:
1) (A ^ C) v B
2) A v (B ^ C)
3) (A ^ C) v (B ^ C)
4) (A ^ C) v B
5) A v (B ^ C)
6) (A ^ C) v (B ^ C)
7) (A v B) ^ C
8 ) (A v B) ^ C

Hier kommen „Entscheidungstabellen“ zum Einsatz. Sie helfen dem Test-Analyst einerseits dabei logische Abläufe systematisch zu verifizieren, als auch anderseits später das System gegen die fachlichen Anforderungen zu validieren. Bringen wir die Anforderung also in eine Entscheidungstabelle, indem Bedingungen und deren Aktionen spaltenweise betrachtet werden. Eine enge Zusammenarbeit zwischen Test und Analyse führt, z.B. im Rahmen eines statischen Tests, zur folgenden Tabelle:

B1: Update angeboten                    Y,N   Y   Y   Y   Y   N   N   N   N

B2: Deliverable angeboten            Y,N   Y   Y   N  N   Y    Y   N   N

B3: Mitarbeiter angemeldet            Y,N   Y   N   Y   N   Y   N   Y   N

A1:„Wartungsmodus“ wechseln             –    X   –    X    -    X    -    -

Möglichkeit 7 wäre also die „implizite“ Anforderung des Kunden entlarvt. Durch das frühe Einbinden des Test-Analysten in den Entwicklungsprozess wurde diese Anforderung „testbar“ gemacht (denn natürlich ist die Entscheidungstabelle eine Anforderung) und der Test-Analyst kann zum späteren Systemtest bzw. Abnahmetest das System „spaltenweise“ gegenüber den fachlichen Anforderungen testen.

Wie arbeitet man in der Praxis mit „Entscheidungstabellen“ und wann kommen sie zum Einsatz? Müssen Bedingungen immer mit „Ja“/“Nein“ belegt werden? Wie kann eine Tabelle übersichtlich dargestellt werden, wenn viele Bedingungen getestet werden („kombinatorische Explosion“)? Nach welchem Vorgehen sollten dabei Tests priorisiert werden? Und welche Technik hilft mir „unsinnige“ Tests von vornherein zu vermeiden?

Test-Analysten testen Systeme aus fachlicher Sicht. Verbessern Sie die Qualität ihrer Anforderungen und schaffen Sie ein korrektes System in einer prüfbaren Qualität. Holen Sie sich den „Test-Analyst” ins ihr Team. Unsere ISTQB Certified Tester Advanced Level Test Analyst-Kurse mit optionaler Zertifizierung helfen bei der Aus- und Weiterbildung: http://knowledge-department.de/certified-tester/advanced-level.html

Diesen Artikel Bookmarken

Schlagen wir in den ISO-Standards nach (genauer ist es die ISO 9000), finden wir dort die folgende Definition: „Qualität ist der Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt.”

Wenn sich bei Ihnen bei dieser Definition ein „Wie bitte?“ ins Bewusstsein drängt, dann geht es Ihnen hier ähnlich wie vielen unserer Seminarteilnehmer. Zerlegen wir den Satz daher in überschaubare Einheiten.

Die Definition besagt, dass
1) es mehrere Facetten gibt („Merkmale”),
2) die in einer Software enthalten sind („inhärent”),
3) welche Forderungen gegenübergestellt werden („Anforderungen”)
4) um dann die Qualität dieser Software bewerten zu können („Grad”).

Schon etwas besser. Damit lässt sich doch etwas anfangen.Wagen wir ein kleines Experiment und denken wir uns ein Szenario aus, indem wir etwas an dem Parameter „Anforderung“ “herumspielen”. Wie würde sich das auf die Qualität auswirken?

Sagen wir, in unserem fiktiven Szenario konstruieren wir ein Softwareentwicklungsprojekt, in dem die Anforderungen an die Software unklar bleiben. Die gut gemeinten Vorgaben des Kunden laufen in Richtung „Machen Sie mir das Beste daraus” – ab dann werden die Entwickler auf sich alleine gestellt. Scheinbar ist doch klar, was mit „das Beste“ gemeint ist: technische Kniffeleien professionell lösen. Das Beste für Entwickler ist eine hoch-performante, effiziente Software! Die Entwicklung ist sich einig. Guten Gewissens werden Aufwände gebucht, in denen Bit um Bit geschubst wird. Kryptische Ausdrücke, wildeste Zeigerarithmetik: Algorithmen in Assembler, die jede Millisekunde aus dem System holen. – Und trotzdem: die Abnahme wird zur einzigen Katastrophe! „Verschwendung von Ressourcen”, „reines Gold-Plating” und „Suboptimizing“ ruft der Kunde. Es stellt sich heraus, dass „das Beste“ für den Kunden nichts mit „dem Besten“ für die Entwickler zu tun hatte. Langlebig sollte die Software sein, Änderungsauswirkungen leicht zu bewerten, auf eine sich ändernde Umgebung anpassbar: „Performanz“ bedeutet ihm nichts. Der Kunde hatte gänzlich andere Anforderungen an die Software.

In unserem Experiment scheint jeder „Qualität“ für etwas anderes zu halten. Und wie lässt sich ein gemeinsames Verständnis für „Qualität“ erreichen?

Durch hochwertige Anforderungen. Wer prinzipiell eine „beste” Qualität fordert, hat es nicht verstanden. Qualität liegt immer in einem „richtigen” Maß vor. Hier muss sich der Kunde festlegen, ob es ihm um Änderbarkeit oder Zuverlässigkeit, Interoperabilität, Benutzbarkeit oder – wie in unserem Experiment – um Wartbarkeit geht. Qualität ist eine Entscheidung, die in Form von Anforderungen für die Projektbeteiligten transparent, im Sinne von „sichtbar machen“, wird. Das Requirements Engineering analysiert Anforderungen an die Software, dokumentiert diese nach bestimmten Kriterien („spezifizieren”) und unterstützt den Kunden nicht nur das zu bekommen, was er will, sondern auch das, was er tatsächlich braucht. Anforderungen sind die Grundlage der Qualität. Von Qualität zu sprechen ohne die Anforderungen zu kennen ist undenkbar.

Welche Methoden und Techniken kann der Requirements Engineer hierfür einsetzen? Wie steuert man als Requirements Engineering die Erhebung, Analyse, Spezifikation und Qualitätssicherung der Anforderungen über die gesamte Entwicklungs- und Wartungszeit? Wie lassen sich Reifegradmodelle für ein Prozessassessment bzw. -optimizing des Requirements Engineerings-Prozess nutzen? Welche Möglichkeiten gibt es vorzugehen – und wie läuft das bei „agilen“ Projekten? Wie schätzt man Aufwände im Requirements Engineering?

Diese Themen sind Teil unserer neuen REQB Certified Professional for Requirements Engineering Advanced Level-Trainings. Die Wichtigkeit des Requirements Engineerings für Projekterfolg war unser Ansporn, einen weitergehenden Kurs mit optionaler, international anerkannter Zertifizierung, in unser Angebot aufzunehmen und das notwendige Material, passend zum Lehrplan, zu entwickeln und akkreditieren zu lassen!

Diesen Artikel Bookmarken

Hier gibt es technische und psychologische Faktoren. Zuerst die psychologischen: Wer keine Fehler finden will, findet auch keine. Der Entwickler beispielsweise ist vor allem daran interessiert zu zeigen, dass sein Produkt funktioniert. Er erwartet einfach, dass es in Ordnung ist. Damit ist jeder Fehler unerwartet. Wenn alle einfach sichtbaren Ausgaben so in etwa richtig aussehen, schließt der Entwickler, dass wohl alles in schönster Ordnung ist. (“Also schloss er messerscharf, dass nicht sein kann, was nicht sein darf.”) Dass da zum Beispiel eine Datei offen bleibt, etwas Speicherplatz vergessen wurde, ein Puffer noch immer besetzt ist oder ein Server noch immer auf eine Antwort wartet, wird nicht gesehen. Hier wäre es besser, man hätte eine motivierte Person, eben den Tester!

Als Tester weiß er, dass es wichtig ist, so viele Fehler wie möglich zu finden. Er weiss auch, aus Erfahrung, dass Fehler of an schlecht zu beobachtenden Stellen lauern. Und schließlich: Als Tester ist man professioneller Pessimist! Das kann man lernen, man muss es aber auch wollen – und als Projektleiter muss man es so organisieren, dass die Tester auch wissen, dass sie dafür bezahlt werden, Fehler zu identifizieren.

Der zweite Faktor ist Ausbildung. Als Tester muss man wissen, wie man Testfälle auswählt. Im Prinzip man man ja alles testen. Es gibt eine astronomische Anzahl möglicher Testfälle. Hier gibt es Kriterien und Methoden zur systematischen Auswahl. Jede Methode übersieht Fehler, ist sozusagen auf einem Auge blind. Aber sie findet auch Fehler, die durch andere Methoden übersehen werden. Deshalb braucht der Tester Kenntnis der verschiedenen Methoden, ihrer Stärken und Schwächen, um dann die besten Testfälle auszusuchen. Zusätzlich sollte der Tester auch wissen, was bei der Entwicklung schief gehen kann – also die Risiken in der Entwicklung. Und schließlich braucht der Tester auch Kenntnis der Applikation, der Benutzung des Systems, um dort die Risiken sehen zu können. also kann wohl doch nicht jede(r) testen …

Diesen Artikel Bookmarken