Mittwoch, 14. Januar 2015

Was ist Software Qualität? Ein Beispiel

Was ist Software Qualität? Die Frage ist gar nicht so leicht zu beantworten. Denn unter Qualität versteht jeder Mensch etwas Anderes, denn jeder hat andere eine andere Sicht auf das Produkt und andere Anforderungen (oder gleiche mit unterschiedlichen Prioritäten) an ein Produkt.

Sicherlich stehen oft die funktionalen Qualitätsfaktoren im Vordergrund:
Was kann die Software? Rechnet sie richtig? Zeigt sie die Ergebnisse richtig an? Sind die Daten korrekt und sicher abgelegt? Dort wird viel Aufwand in die Qualitätssicherung investiert. Diese Punkte stehen immer im Fokus.

Aber wie sieht es mit den nichtfunktionalen Qualitätsfaktoren aus?
Einheitliche Benutzungsoberflächen. Einfache Bedienung. Effiziente Umsetzung der Arbeitsprozesse in die Software. Das sind z. B. Faktoren die unter die Usability fallen.

Und es gibt noch eine Menge andere Faktoren, wie die Wartbarkeit der Software, die Testautomatisierbarkeit, die Skalierbarkeit uvm. Man muss sich immer fragen, welche QS-Maßnahmen werden in diesen Gebieten durchgeführt? Wie wird die Qualität in diesen Themen konstruiert?

Aus Kundensicht spielt auch die Laufzeit eine wesentliche Rolle. Ein Faktor dabei ist sicherlich auch, wieviele Daten über das Netz übertragen werden. In LANs ist das wichtig, im mobilen Netz noch viel wichtiger. Werden viele Daten übertragen, können die Apps auf dem Smartphone langsamer werden. Das Risiko von Verbindungsabbrüchen steigt. Und die Flatrates der Kunden (oft bieten die Provider 200 oder 300 MB an) können ggf. für den Monat nicht ausreichen, was dann erhebliche Geschwindigkeitseinbußen zur Folge hat.

Seit Mitte 2014 hat Google die Smartphone-Apps auf ein einheitliches Design umgestellt und dies mit Android 5.0 konsequent fortgeführt. Es ist prima über alle Apps und das System eine einheitliche und einfache Bedienung zu erhalten. Doch der Datenverbrauch der Apps und Hintergrunddienste erhöhte sich mit den neuen Apps und Android 5.0 deutlich. Wenn Kunden bei gleichem Nutzungsverhalten neue Mobilfunkverträge abschließen, damit am 20. eines Monats nicht die Drosselung zuschlägt, wurden Qualitätsfaktoren bei der Entwicklung vernachlässigt. Auch wenn dann durch minor Releases nachgebessert wird, hat man für einen gewissen Zeitraum Qualitätseinbußen.

Nur wenn alle Aspekte berücksichtigt werden, liefert man ein Produkt mit "guter Qualität" aus...

Dienstag, 25. November 2014

Fehlermanagement in mehreren Entwicklungslinien

In der Regel hat man ja verschiedene Versionen (Releases) einer Software. Eine beim Kunden verfügbare Version und mindestens eine Variante für die Weiterentwicklung. Nun tritt in einer Komponente (unterschiedliche Versionen) ein Fehler auf. Wie organisiert man nun das Bug-Tracking und den Ausbau? Dazu gibt es zwei prinzipielle Ansätze:
  1. Im Bug-Tracker wird für jeden Softwarestand ein Bug angelegt
  2. Im Bug-Tracker hat man einen Bug, der für alle Versionen gilt.
Was bedeutet dies nun, wenn man für jede Version einen Bug im System hat (1):
  • Für jede Version muss man einen Bug im System einstellen (Aufwand ist aber eher ein kleiner) und bearbeiten.
  • Transparenz, wie weit die Umsetzung für die jeweilige Version ist. Das ist gut für das Team, da beim Ausfall eines Kollegen (z. B. Krankheit) sofort offensichtlich wird, was noch offen ist.
  • Es wird offensichtlich, in welchen Versionen der Fehlerausbau zu testen ist (unabhängig ob dies automatisiert oder manuell geschieht).
Und wie sieht es beim Ansatz (2) aus:
  • Haben die Entwickler ihre Aufgaben wirklich gut im Griff (keine Ablenkung durch neue Prioritäten, neue Probleme etc.) reicht nur ein Eintrag im Bug-Tracker. Bei kleinen Teams ist dies ggf. eine praktikable Vorgehensweise.
  • Es ist allerdings zu klären für welche Version der Bug im System angelegt wird (das wird vor allem schwer, wenn verschiedene Releases beim Kunden verfügbar sind).
  • Die Transparenz über den Fortschritt bei Fehlerausbau und Test in den verschiedenen Versionen hat man natürlich nicht. Und wenn der Entwickler mal krank wird, ist nicht so einfach erkennbar, was bereits erledigt wurde.
Gerade in größeren Teams und Organisationen und bei Verfügbarkeit von drei (Freigabe-Release, Pilot-Release, aktuelles Release in der Entwicklung) oder mehreren Releases tendiere ich wegen der Übersichtlichkeit zur Lösung (1). Auch weil jeder Bug gleichzeitig ein Requirement für ein Release ist und damit deutlich wird was alles für das Release zu tun ist. Aber letztendlich muss jeder für sich entscheiden, welche Vorgehensweise für die eigene Organisation besser geeignet ist.

Dienstag, 10. Dezember 2013

Testing Zeitschriften im Web

In den letzten zwei Jahren hat sich bei den Zeitschriften zum Testen doch einiges getan. Vor allem gibt es recht neues deutsches Test Magazin. Nachfolgend ein Update zum Artikel von vor zwei Jahren. Kostenlos verfügbare Zeitschriften:

Montag, 2. Dezember 2013

Der Change von klassischen Vorgehensweisen zum Agilen

Warum ändert man die Vorgehensweise in der Softwareentwicklung? Warum wird man agil, wenn man vorher klassisch Software erstellt hat? Na klar. Man möchte die Qualität erhöhen. Bezüglich der Kundenanforderungen. Bezüglich der Stabilität. Und auch bei den weiteren Qualitätsfaktoren.
Doch die agilen Projekte liefern in der Regel keine besseren Ergebnisse als klassische Vorgehensweisen, wie die Umfrage Softwaretest ermittelt hat.


Doch was sind die Ursachen? Die Diskussionen mit Experten im letzten Seminar haben dabei folgende mögliche Gründe zu Tage gebracht:

  • Alle Beteiligten benötigen einen Mindshift von klassisch zu agil. Teilweise geht nicht.
  • "no test - no code"
    Wer den Code nicht richtig gut getestet hat, darf diesen nicht einchecken. Sonst läuft es niemals.
  • "Agilität ohne Test Driven Development geht gar nicht" (Zitat Prof. Dr. Mario Winter)
  • Ohne testgetriebene Ansätze (TDD, XP, Pairing etc.) sind agile Vorgehensweisen absolut fragwürdig. Das ist dann nur "Hacken".
  • Ohne eine Definition of Done wird auch keine Qualität herauskommen
  • Planning Poker ohne Berücksichtigung der Testing Tasks (oder der jeweiligen Testaufwände in den user stories) ist nur Selbstbetrug
Halbe Sachen gehen also gar nicht. Ein Change-Prozess braucht viele Coaches und eine Basis, die für Veränderung bereit ist. Sonst wird aus einem Wasserfall nur ein "agiler Wasserfall"...

Samstag, 30. November 2013

Neue Sicht zum explorativen Testen

Das explorative Testen ist den letzten Jahren immer mehr ins Gespräch gekommen. Vor allem im agilen Umfeld hat man immer wieder vom Einsatz gehört. Was ich bisher darüber gehört hatte, hatte mich jedoch nicht überzeugt:
Wer keine systemtischen Testverfahren verwendet, wer keine Requirements definiert und wer keine richtige Vorgehensweise hat, der macht eben exploratives Testen. Unstrukturiert und chaotisch...
So habe ich bisher gedacht. Doch eine Veranstaltung mit Prof. Dr. Mario Winter (Link FH Köln) hat mir eine neue Perspektive gegeben (natürlich liegt an seinem Aufbau und Inhalten dieser Methode).

Exploratives Testen

  • ist eine zielgerichtete Vorgehensweise um Fehler zu finden (Test-Chartas)
  • ist eine strukurierte und kreative Methode (Testing-Touren und Session-basiert)
  • ist für die Tester sehr motivierend
  • dient als Ergänzung zu systematischen Testverfahren
  • ist natürlich auch eine Methode, die man nutzen kann, wenn kaum (oder keine) Konzepte vorhanden sind 
Vor allem in agilen Projekten ist der Einsatz sehr spannend. Neben dem Seminar (extrem empfehlenswert) ist auch ein Buch von James Whittaker (Testing Evangelist) sehr zu empfehlen (Link zu Amazon

Später mehr zur Methodik...

Mittwoch, 20. November 2013

Fazit vom German Testing Day 2013

Viele Eindrücke und viele Gespräche gab es auf dem German Testing Day 2013. Doch welche Dinge sind bei uns hängen geblieben? Welche Statements haben uns beeindruckt? Und was lohnt es, umgesetzt zu werden?

  • Tester werden weiterhin eine wichtige Rolle in Softwareentwicklungs-Projekten haben, doch die Skills müssen erweitert werden (wenn nicht schon geschehen)

  • Test Engineers sind hochqualifizierte Personen, mit Fähigkeiten die über das reine Testen hinaus gehen - da muss man sich selber fragen, ob man die Anforderungen noch erfüllt...
  • Testautomatisierung hat durch die agilen Projekte stark an Bedeutung gewonnen
  • Manuelle Tests sind weiterhin notwendig. Aber nicht Alles muss/kann/soll automatisiert werden
  • Entscheidend für den Erfolg von agilen Projekten und agilem Test ist das Mindset. Ohne eine entsprechende Einstellung werden sich keine Erfolge einstellen
  • Qualitätssicherung und vor allem "Testing" sind endgültig in der agilen Welt angekommen und bilden dabei keinen Widerspruch, sondern waren schon immer implizit vorhanden
Beide Keynotes waren beeindruckend. Testing @ ebay von Michael Palotas  kann einem schon die Augen öffnen und wer die Chance hat, mal den ehemaligen Schiedsrichter Dr. Markus Merk live zu hören, sollte diese wahrnehmen. Diese Keynote zum Thema "Sicher entscheiden" wäre die Reise alleine schon wert gewesen.

Alles in allem hat sich der German Testing Day 2013, wie auch schon der in 2011, wirklich gelohnt. Am 02.07.2014 findet die dritte Auflage statt. Schauen wir mal...

Ach: Auch Location und Catering waren ziemlich gut. Dies sollte nicht unerwähnt bleiben.

Fazit von Alex und Frank

Montag, 18. November 2013

Vorträge am German Testing Day 2013

Nach der Keynote gab es einige weitere spannende Vorträge. Nachfolgend einige interessante Aussagen der Referenten zu den verschiedenen Themen:

Scrum-Projekte
  • Testing ist eine "gefühlt destruktive Aufgabe". Deshalb muss im Team der Wert dieser Aufgabe klar sein (bzw. gemacht werden)
  • Testing Aktivitäten sind nicht verhandelbar!
  • Die Notwendigkeit der Testautomatisierung wird systematisch unterschätzt.
  • Agile Methoden müssen geschult werden. Ein agiles Mindset muss entstehen. Agile Projekte mit Halbwissen gehen schief.
  • Scrum-Master ohne IT-Background tun sich sehr schwer.

Mobile Entwicklung
  • Testing im mobile Bereich ist bei den nicht-funktionalen Anforderungen nochmal komplexer (z. B. Netzverfügbarkeit, Bandbreite)
  • Die Hardwarevielfalt macht die Test-Planung und Testumgebung komplexer (welche Geräte und Betriebssysteme teste ich)
  • Der mobile Markt und damit die Anforderungen an die Software/den Test verändern sich sehr schnell

Tracability
  • In komplexen Entwicklungsumgebung kann zur Steuerung die werkzeuggestützte Verwaltung der Traceability zu deutlichen Fortschritten führen. Werkzeuge (u. a. OpenSource) gibt es auch dafür.
  • Damit können z. B. folgende Fragen schnell beantwortet werden:
    • Welchen Test muss ich durchführen, weil sich ein Feature geändert hat
    • Welcher Code ist durch geänderte Anforderungen betroffen
    • Der Kunde wünscht eine Änderung. Welche Anforderungen ändern sich? Welche Tests müssen nochmal durchgeführt werden?
    • ....
  • Aber: Die Dokumentation und Verwaltung muss vollständig gelebt werden. Sonst ist es nur Aufwand ohne den letztendlichen Nutzen.