Testpraxis, klassische Fehler

TestmanagementDie Welt verändern, ein Bug nach dem anderen…

Klassische Fehler beim Testen


In der nachfolgenden Zip-Liste sind mehr als 40 verschiedene wichtige Fehlersituationen aufgeführt, deren Kenntnis und Vermeidung wichtig sind. Sowohl die Anzahl der Fehlersituationen als auch die möglichen Lösungsansätze können nicht vollständig sein - sehr wohl jedoch die Basis für eine Analyse des Testgeschehens.
Die Ausarbeitung basiert auf einem Artikel (http://www.exampler.com/testing-com/writings/classic/mistakes.html) von Brian Marick in englischer Sprache, der die Fehlersituationen transparent und deutlich macht.
Einige wichtige Anmerkungen haben wir in deutscher Sprache hinzugefügt (GRÜN).
Die Liste enthält folgende Kapitel
  • Die Rolle beim Testen
  • Testplanung und Testfortschritt
  • Personalfragen
  • Tester bei der Arbeit
  • Testautomatisierung
  • Testabdeckung
Die Rolle beim Testen
  • Thinking the testing team is responsible for assuring quality.[+]
    Qualität kann nicht in ein Produkt hinein getestet werden.
  • Not reporting usability problems.[+]
    Auch Usability-Funktionalität ist wichtig. Stimmt das Design nicht, so tritt die nachgelagerte Funktionalität möglicherweise gar nicht in Erscheinung.
  • No focus on an estimate of quality (and on the quality of that estimate).[+]
    Vor dem Testdesign müssen die Qualitätskriterien bestimmt werden und ihre Wichtigkeit.
  • Thinking that the purpose of testing is to find bugs.[+]
    Vor dem Testdesign müssen die Qualitätskriterien bestimmt werden und ihre Wichtigkeit.
  • Reporting bug data without putting it into context.[+]
    Die Berichterstattung über Fehler darf nicht nur ein Zahlenwerk sein. Die Bugs sollten in Beziehung zu ihrem Kontext stehen.
  • Starting testing too late (bug detection, not bug reduction).[+]
    Startet der Test zu spät, bleibt möglicherweise zu wenig Zeit die Bugs zu fixen und die Abwesenheit der Bugs durch einen Regressionstest zu bestätigen.
Testplanung und Testfortschritt
  • A testing effort biased toward functional testing.[+]
    Beim funktionalen Testen im Detail ist es auch wichtig aufgaben-, szenario- und/oder usecaseorientiert zu testen. Typische Geschäftsprozesse bzw. Fachaufgaben sind zu berücksichtigen.
  • Underemphasizing configuration testing.[+]
    In der Testabteilung stehen meist nur idealtypische Testkonfigurationen zur Verfügung. Der Markt jedoch ist vielfältiger. Je mehr sinnvolle Kombinationen berücksichtigt werden, umso besser.
  • Putting stress and load testing off to the last minute.[+]
    Last- und Performancetests sind wichtig. Sie lassen Aussagen zu über das Verhalten eines Programmes bei Last/Stress. Programme müssen so ausgelegt sein, dass sie auch mit vielen Nutzern gewünschte Ergebnisse erzielen. Stehen beispielsweise bei grossen Datenmengen nur kleine Zeitfenster für die Batchverarbeitung zur Verfügung oder sind die Antwortzeiten größer als im SLA vereinbart, ist die Performance zu verbessern. Last- und Performancetests müssen deshalb möglichst frühzeitig durchgeführt werden.
  • Sticking stubbornly to the test plan.[+]
    Gut durchdachte Testpläne sind eine gute Basis. Da selbige nicht in Stein gemeißelt und damit leicht änderbar sind, ändern Sie sie, wenn es notwendig ist.
  • Not testing the documentation.[+]
    Softwaretests und Tests der Dokumentationen sind nicht voneinander zu trennen. So kann beispielsweise eine Programmänderung oder ein neues undokumentiertes Feature beim Kunden großes Erstaunen verursachen.
  • Not testing installation procedures.[+]
    Nach Programmänderungen sind ebenfalls die Installationsprozeduren zu testen. Was nützen die besten neuen Features, wenn sich das Programm nicht oder nur fehlerhaft installieren läßt?
  • An overreliance on beta testing.[+]
    Beta-Testing ist sehr nützlich. Jedoch schließen diese "Test-Eindrücke" einen ausführlichen Test mit professionellen Testern nicht aus.
  • Finishing one testing task before moving on to the next.[+]
    Bevor sich der Tester in einigen speziellen Testfällen "fest beißt", sollte er besser einen Überblick gewinnen, um herauszufinden wo die wirklichen Problemzonen liegen.
  • Failing to correctly identify risky areas.[+]
    Identifizieren Sie die risikobasierenden Bereiche und analysieren sie die Relevanz für Ihre Tests. Testen Sie diese zuerst.
Personalfragen
  • Using testing as a transitional job for new programmers.[+]
    Wenn ein Anfänger die Test durchführen soll, sind die Ergebnisse nicht professionell, wie man es von einer guten Testorganisation erwartet. Selbstverständlich kann man beim Test auch gute Erfahrungen sammlen, Verständnis für das Testen gewinnen und auf diesen Erfahrungen später aufsetzen.
  • Recruiting testers from the ranks of failed programmers.[+]
    Viele Tester können auch programmieren und umgekehrt können Entwickler auch testen. Meist jedoch sind die erforderliche Softskills zu unterschiedlich. Auf keinen Fall jedoch sollte man Entwicklern, die zu viele Bugs programmiert haben, im Testbereich eine neue "Spielwiese" bereitstellen.
  • Testers are not domain experts.[+]
    Tester, die zugleich das jeweilige Wissen der Fachabteilung mitbringen, sind schwierig zu finden. Finden Sie deshalb auch Tester, die sich kurzfristig in die Fachaufgaben hineinfinden können, soweit dies Testrelevanz hat.
  • Not seeking candidates from the customer service staff or technical writing staff.[+]
    Diese Spezies hat bereits einen gewünschten Teil der erforderlichen Skills. Allerdings fehlt diesen Kandidaten möglicherweise das technische Wissen eines Entwicklers. Deshalb ist im Testteam das Vorhandensein verschiedener Skill-Ausprägungen wünschenswert. Die Testfälle sind entsprechend zuzuweisen.
  • Insisting that testers be able to program.[+]
    Ein Tester muss kein Entwickler sein, ist aber vorteilhaft. Am aller wichtigsten ist die Teamkompetenz.
  • A testing team that lacks diversity.[+]
    Das Team muss die von ihm übernommenen Aufgaben umsetzen können. Eine gewisse Vielfalt von Menschen im Test kann durchaus sinnvoll sein.
  • A physical separation between developers and testers.[+]
    Kurze Wege bei der Realisierung einer gemeinsamen Aufgabenstellung sind besser als eine Separierung von Testern und Entwicklern in verschiedene Räume, Gebäude u.ä.
  • Believing that programmers can't test their own code.[+]
    Ein Entwickler kann sein Programm auch testen, sollte er aber nicht. Ein unabhängiger Kollege findet mehr Bugs.
  • Programmers are neither trained nor motivated to test.[+]
    Wenn das Programm geschrieben wurde und der Test beginnt, stehen oftmals die Entwickler für Testaufgaben zur Verfügung. Die Abarbeitung der vorliegenden Testfälle erscheint ihnen nicht kreativ genug. Hier fehlt es an Motivation.
Tester bei der Arbeit
  • Paying more attention to running tests than to designing them.[+]
    Qualität lässt sich bekanntermaßen nicht in Software hinein testen. Besser ist es im Design mehr Aktivität zu konzentrieren. Das Resultat einer schlampigen Programmierung ist eine Unzahl von Bugs, die zeitaufwendig und teuer beseitigt werden müssen.
  • Unreviewed test designs.[+]
    Für die meisten Phasen im Software-Lifecycle sind Reviews unerlässlich. Sie kosten Zeit, reduzieren aber letztlich Aufwand.
  • Being too specific about test inputs and procedures.[+]
    Zunächst einmal erscheint die Fragestellung nicht so wichtig, ob beispielsweise alle Masken und Buttons angezeigt werden, als die Fragen zu klären, welche Schrift in welcher Pixelgenauigkeit vorliegt. Also, auch hier ist der Blick für das Wesentliche nützlich.
  • Not noticing and exploring "irrelevant" oddities.[+]
    Ein guter Tester ist Meister darin "Merkwürdigkeiten" zu entdecken. Diesen Signalen ist nachzugehen.
  • Checking that the product does what it's supposed to do, but not that it doesn't do what it isn't supposed to do.[+]
    Testen Sie, ob das Produkt hält, was es tun soll.
  • Test suites that are understandable only by their owners.[+]
    Testfälle, die in der Form designed sind, dass sie nicht von einer anderen Person durchgeführt werden können, sind zurückzuweisen. Diese Testfälle hätten bereits beim Review auffallen können/müssen.
  • Testing only through the user-visible interface.[+]
    Programme nur an der Oberfläche zu testen, ist nicht ausreichend. Es gibt hinlänglich Funktionalität, die nicht an der Oberfläche liegt.
  • Poor bug reporting.[+]
    Fehler zu finden ist wichtig. Nicht minder wichtig ist es, die Bugs auch professionell zu beschreiben und nachvollziehbar zu dokumentieren.
  • Adding only regression tests when bugs are found.[+]
    Nur die Anzahl der Regressionstestfälle zu erhöhen bei gefundenen Bugs ist nicht ausreichend. Dort wo besonders viele Fehler gefunden wurden, ist die Testabdeckung zu verbessern.
  • Failing to take notes for the next testing effort.[+]
    Ignorieren Sie niemals, was Ihre Kunden Ihnen sagen wollten. Werten Sie die Support-Tickets aus. Tragen Sie alle wertvollen Informationen zusammen, um für den nächsten Test vorbereitet zu sein.
Testautomatisierung
  • Attempting to automate all tests.[+]
    Testfälle, die häufig durchgeführt werden sollen, sind geeignet, um sie zu automatisieren. Auch Tests für den Stress- und Lasttest sind geeignete Kandidaten, ebenfalls die Tests des Nightly-Builds. Auch bei Smoketests bietet sich die Automatisierung an.
    Aber eben nicht in allen Fällen. Finden Sie einen Kompromiss aus manuellen und automatisierten Tests.
  • Expecting to rerun manual tests.[+]
    Es wird voraussichtlich aus Zeit- und Kostengründen nicht gelingen alle manuellen Bugs wiederholt auszuführen. Treffen Sie deshalb immer eine geeignete Testfallauswahl für den jeweiligen Testplan. Überführen sie sukzessive manuelle Testfälle in die automatisierten Test, wenn dies sinnvoll ist.
  • Using GUI capture/replay tools to reduce test creation cost.[+]
    Capture und Replay Tools sind sehr hilfreich, um Oberflächen wiederholt zu testen. Deshalb ist jeweils zu überlegen, den Job besser durch Roboter ausführen zu lassen als dafür aufwendig manuelle Test zu schreiben. Allerdings ist bei allen Vorhaben zur Testautomatisierung eine Rückfallposition in der Hinterhand bereitzuhalten.
  • Expecting regression tests to find a high proportion of new bugs.[+]
    Regressionstests sind meist die "Abschlusstests" nachdem bereits alle Testfälle ausgeführt und alle Bugs beseitigt wurden. Durch Regressionstests lassen sich sogenannte Seiteneffekte aufdecken.
Testabdeckung
  • Embracing code coverage with the devotion that only simple numbers can inspire.[+]
    Eine Code-Abdeckung zu testen macht Sinn. Mit den quantitativen Ergebniszahlen zu glänzen ist schön. Das darf aber nicht den Blick für das Wesentliche verstellen: Finden von wichtigen Bugs.
  • Removing tests from a regression test suite just because they don't add coverage.[+]
    Entfernen Sie keine Testfälle aus der Suite der Regressionstestfälle, nur weil sie nicht Coverage-relevant sind.
  • Using coverage as a performance goal for testers.[+]
    Eine erreichbare vorgegebene Testgeschwindigkeit kann sinnvoll sein. Zählen Sie jedoch nicht die Anzahl Tastaturanschläge, Lines of Code oder einzelne Testschritte, um das Testergebnis zu bewerten. Wichtiger ist es, wichtige Bugs zu finden.
  • Abandoning coverage entirely.[+]
    Auch beim Test zählt Qualität vor Quantität. Aber die Frage nach dem "Wieviel" wird täglich immer wieder gern gestellt.
Hinweis: Wollen Sie alle Fragen und Antworten auf einmal ausgedruckt bekommen, verwenden Sie bitte die Druck-Funktionalität Ihres Browsers.
Viele Fehlersituationen wiederholen sich ständig. Man bezeichnet sie dann als klassisch. Das klingt zwar gut, ist es aber nicht. Wer die Fehlersituationen kennt, kann sie vermeiden. Wir sorgen dafür.
U
Testpraxis, klassische Fehler
© 2016 Holger Mayer Consulting HMC2