Qualitätssicherungsprüfer - Welche Schritte unternehmen Sie, um die Software zu "brechen"?

Question

Verwenden Sie die Software, da sie nicht beabsichtigt war? Wie brechen Sie Ihre Software?

Answer 1

Ich denke, ist die falsche Frage. Ich habe große Testteams geleitet. Die Tester, die alle kleinen Käfer finden, stürzen das System ab, wenn du "dies und das, bla, bla" machst.

Die Fehler wurden aufgezeichnet und normalerweise nicht korrigiert. Alle waren sich einig, dass dies ein ganz besonderer Fall ist und wir keine Zeit haben und die Wahrscheinlichkeit, dass es in der Produktion passieren wird, ist zu gering.

Der echte Fehler wird manchmal einfach übersehen. Das System beabsichtigt, dass der Programmierer das Programm ausführt, aber es ist nicht das, was der Client benötigt. Ein Fehler, der eigentlich schon ein Anforderungsfehler ist.

Neben dieser Bemerkung normalerweise die Fehler sind in Dinge wie

• Keine Dateneingabevalidierung
• Grenzen nicht überprüft (sehr große Werte, sehr kleine Werte)
• Fehlerbehandlung fehlt (was das System lose Verbindung). Datenträger voll usw.
• Schnittstelle Fehler erkannt nur, wenn das System Ende getestet
• Probleme mit ungültigen Zeichen
• Probleme mit Strings zu lange
• Probleme mit leeren Werten
• Probleme mit Datenkombinationen beenden nicht offensichtlich

So systematische Testen Ausprobieren aller möglichen Kombinationen ist notwendig, wenn Sie bis zu brechen, ein System

sind

Answer 2

Es gibt selten eine 100% Garantie, dass das System nur wie vorgesehen verwendet wird. Es ist wichtig für das Team zu verstehen, wie sich das System verhält, wenn schlechte Daten "irgendwie" in das System gelangen. Diese Art von Problemen können sehr wichtig sein, wie zum Beispiel Sicherheitsprobleme, die dazu führen können, dass private Kundendaten aufgedeckt werden, weil no one intended for SQL statements to be entered into that field; es sollte nur für Studentennamen sein. Also, ja, ich prüfe absolut, was passiert, wenn das System nicht wie beabsichtigt benutzt wird. Systeme sollten ordnungsgemäß fehlschlagen, und nicht schwerwiegende Fehler sind Fehler. Nicht protokollierte Fehler oder Fehler, die schwer zu untersuchen sind, können ebenfalls Fehler sein.

Die genauen Schritte, die ich unternehme, um die Software zu brechen, hängen von dem Ding ab, das geprüft wird. Im Allgemeinen teilt unser Team funktionale Testfälle bei der Erstellung von Schätzungen in drei Gruppen ein: Happy-Path-Tests, die jedes Feature einmal durchlaufen, mit dem grundlegendsten Anwendungsfall, den der Tester einschlagen kann. "Seltsame" Tests, bei denen es sich um gründlichere Durchläufe handelt, die alle winzigen Logikelemente abdecken, sowie ungewöhnliche gültige Fälle, an die die Programmierer möglicherweise nicht gedacht haben (in erster Linie Grenztests und Äquivalenzklassen-Tests). Schließlich "Error" -Tests, bei denen es darum geht, schlechte und unerwartete Eingaben zu machen, um den Code zu zerschlagen und zu versuchen, und häufig werden Tests für Protokollierung, Überwachung und Fehlerbehebung durchgeführt. Im Allgemeinen ist das Testen von glücklichen Pfaden ziemlich schnell, aber "seltsame" und "Fehler" -Tests sind beide ziemlich zeitintensiv. Dies ist nur ein Funktionstest und schließt keine anderen Arten von Tests wie Integration oder Leistungstests ein.

Wir versuchen im Allgemeinen auch, Live-Daten für Tests zu erhalten, wenn sie verfügbar sind. Tester können eine große Liste von möglichen unbeabsichtigten Verwendungen erstellen und verpassen trotzdem die unbeabsichtigten Verwendungen, die der Kunde erwartet.

Answer 3

Big Story kurz - Exploratory Testing Sitzungen zusammen mit Charter