Menü

Wie entscheiden Sie, welche Fehler für die Inbetriebnahme der Software akzeptabel sind?

how do you decide which defects are acceptable

Versuchen Sie Unser Instrument, Um Probleme Zu Beseitigen

Software Go-Live ist für jedes Softwareprodukt immer ein großes Ereignis. Es ist wichtig sicherzustellen, dass alles funktioniert und dass wir es sind Bereitstellung hochwertiger Software für die Benutzer .

Ein schlechtes oder verfrühtes oder instabiles oder schwer zu verwendendes Produkt kann finanziell viele Verluste verursachen und den Benutzer das Vertrauen in die Marke selbst verlieren lassen.

Oft hören wir, dass Tests durchgeführt werden sollten, bis wir die Ausstiegskriterien erfüllen. Wir hören auch, dass Mängel auf einem akzeptablen Niveau behoben werden müssen.

Dies sind zwar gut klingende Richtlinien, aber sie sind vage.

Software-Go-Live-Kriterien

Um genauer zu sein:

  • Wie viel Prozent der Fehler sind für die Inbetriebnahme von Software akzeptabel?
  • Wie entscheiden Sie sich für die offenen Mängel, mit denen die Software live gehen kann?
  • Was Arten von Mängeln sind ernster als die anderen?

Empfohlene Lektüre => Wann sollte der Test beendet werden?

Haben Sie diese Fragen jemals gehabt? Dann hilft Ihnen dieser Artikel bei der Beantwortung. Weiter lesen…

Komplexe Software ist nicht fehlerfrei und es handelt sich um eine Henne-Ei-Geschichte zum Schließen von Fehlern gegenüber funktionierender Software.

Je mehr Sie Fehler beheben, desto wahrscheinlicher ist es, dass beim Schließen des Fehlers ein neuer Fehler injiziert wurde. So,

  • Wie entscheiden Sie über das Ausmaß der Mängel und die Art der Mängel, mit denen Sie live gehen können?
  • Wie können Sie die Software für die Inbetriebnahme als Basis festlegen?
  • Wie rufen UAT-Koordinatoren zum Go-Live an oder nicht?
  • An welchen Parametern sollte Software gemessen werden?
  • Wie antworten wir? Ist die Software einsatzbereit und bringt sie den Stakeholdern einen Mehrwert?

Die Inbetriebnahme der Produktion ist sowohl für den Kunden als auch für den Verkäufer ein wichtiger Meilenstein, da er normalerweise mit Zahlungsmeilensteinen verbunden ist. Beide tragen die gleiche Verantwortung dafür, dass die großen Transformationsprojekte erfolgreich sind.

Meine Erfahrung zeigt, dass Kunden ihr Preis-Leistungsverhältnis wollen und ein haben Ausstiegskriterium für UAT zum Go-Live mit.

Die genannten Ausstiegskriterien würden mehr oder weniger das akzeptable Ausmaß der Probleme in allen Bereichen der Anwendung definieren, wie z.

  1. Funktionell
  2. Leistung und Last
  3. Benutzerfreundlichkeit
  4. Sicherheit
  5. Integration mit externen Systemen
  6. Berichte
  7. Datenmigration

Ich glaube, jeder einzelne dieser Arten von Fehlern muss weiter erklärt werden. Und genau das werden wir jetzt tun:

.net c # Interviewfragen

# 1. Funktionsstörungen:

Wenn die Software gemäß den vom Kunden angegebenen Spezifikationen erstellt wird, muss sie die Anforderungen erfüllen. Abweichungen werden als Funktionsfehler erfasst.

Funktionsstörungen werden dann nach klassifiziert Schweregrad und Priorität .

Folgendes sind wichtige Überlegungen:

  • Fehler mit hohem Schweregrad und hoher Priorität wirken sich normalerweise auf die tägliche Nutzung der Software aus. Diese Arten von Fehlern müssen behoben werden, bevor wir live gehen. Keine Ausnahmen.
  • Manchmal werden Funktionsstörungen als Änderungsanforderungen klassifiziert, da sie nicht Teil der ursprünglich angegebenen Anforderungen waren. Solche CRs, die ein Muss für Unternehmen sind, um nach dem Go-Live zu arbeiten, müssen ebenfalls implementiert werden.
  • Die Klassifizierung von Fehlern und die Priorisierung von Funktionsfehlern erfolgt durch die UAT-Koordinatoren in Zusammenarbeit mit Geschäftsbenutzern und Geschäftsanalysten. Normalerweise hat der Kunde ein Ausstiegskriterium dafür, wie viel Prozent der Fehler für die Inbetriebnahme offen sein können.

# 2. Leistungs- und Lastfehler:

Leistungsmängel sind wichtig für die Inbetriebnahme und insbesondere, wenn die Software von externen Benutzern verwendet werden soll.

Wenn die Software für eine bestimmte Anzahl von Benutzern langsam ist, würden die Benutzer die Verwendung der Software vermeiden, da das Laden viel Zeit in Anspruch nimmt. Benutzer wechseln in der Regel zur Website des Mitbewerbers, wenn die Software sehr langsam ist und dadurch das Geschäft verliert.

Manchmal können sich auch Teile der Anwendung, die nicht dem Client zugewandt sind, auf die Leistung auswirken.

Zum Beispiel: Wenn am Ende eines jeden Tages ein Stapelverarbeitungsprozess ausgeführt wird und die Antwortzeit der Anwendung darunter leidet, ist auch die Leistung des Stapels ein zu berücksichtigender Faktor.

  • Die Leistung wird normalerweise anhand der Antwortzeit von Bildschirmen gemessen, die gerendert und den Benutzern zur Verfügung gestellt werden sollen, während sich eine bestimmte Anzahl von Benutzern gleichzeitig im System befindet.
  • Leistungstests werden mit Tools wie z LoadRunner , WebLoad , Neoload etc.
  • Die Leistung der Software bei einer bestimmten Last und bei einer zukünftig vorhergesagten Last wird normalerweise im Vertrag dokumentiert und muss vor der Inbetriebnahme nachgewiesen werden.
  • Die Bildschirme oder Teile der Anwendung, die von den Benutzern weniger verwendet werden, werden nach der Inbetriebnahme auf Auswertungen verschoben.
  • Die Leistung hängt auch von der Art der Hardware und den Netzwerkbedingungen ab, unter denen die Software bereitgestellt wird.
  • Leistungstests werden während der UAT in der angegebenen Hardware mit Leistungstools durchgeführt und ihre Fehler werden auf ähnliche Weise wie bei Funktionsfehlern verfolgt. Sie werden ebenfalls priorisiert und es wird ein Konsens darüber erzielt, ob die Ausstiegskriterien für die Inbetriebnahme erfüllt werden.
  • In der Regel werden Leistungs- und Lasttests in UAT durchgeführt, nachdem die funktionale UAT von den Geschäftsbenutzern abgeschlossen und ein akzeptables Ausstiegskriterium für Funktionsfehler erreicht wurde.

#3. Usability-Mängel:

Die Software erstellt sollte für die Endbenutzer leicht verwendbar sein Verwenden verschiedener Hotkeys, Verknüpfungen, Mindestanzahl an Bildschirmnavigation, Paginierung usw. Die Software muss intelligent und intuitiv sein.

Wenn die Seite zu viele Bewegungen aufweist, bevor Sie zum entsprechenden Bildschirm wechseln, zeigen die Benutzer normalerweise weniger Interesse an der Verwendung der Software.

  • Usability-Richtlinien werden erstellt, bevor die Software erstellt wird. Die Software muss diese Richtlinien einhalten.
  • Beim Erstellen der Software können auch Tool-Einschränkungen auftreten, die intelligent überwunden werden müssen, bevor die Software von den Endbenutzern verwendet werden kann.
  • Mit hoch verwendbarer Software kann ein Endbenutzer Daten bis zum Fünffachen der regulären Software eingeben.
  • Das Erscheinungsbild der Software muss klar sein und auch rechtliche Fragen müssen vor der Inbetriebnahme geklärt werden.
  • Oft wird ein Usability-Berater ernannt, um den Benutzern ein reibungsloses Usability-Erlebnis zu gewährleisten.
  • Die Dokumentation, die mit der Softwareanwendung veröffentlicht werden muss, muss außerdem strengen Usability-Richtlinien entsprechen, da sie legal verwendet werden können.
  • Die von UAT-Testern / externen Testern protokollierten Usability-Fehler werden ebenfalls als Funktions- und Leistungsfehler priorisiert und müssen die Ausstiegskriterien für die Inbetriebnahme erfüllen.

# 4. Sicherheitsmängel:

Sicherheit der Software ist ein heißes Problem, da die Softwareanwendung gehackt werden kann und kundensensible Daten innerhalb kürzester Zeit gestohlen werden können.

Daher sollte zuverlässige Software nicht einmal einem sehr kompetenten Hacker erlauben, ohne entsprechende Berechtigungen in die Anwendung zu gelangen.

  • Sicherheitstests werden in UAT mit bestimmten Eingaben in die Software durchgeführt, um sicherzustellen, dass sie nicht hackbar ist.
  • Sicherheitstests werden von legalen Hackern durchgeführt, die versuchen, die Software zu hacken, um zu überprüfen, ob sie anfällig ist.
  • Alle Sicherheitsmängel müssen geschlossen werden, bevor das System in Betrieb genommen wird.
  • Sicherheit bedeutet auch Anmeldung sowie Rollen und Berechtigungen für verschiedene Benutzer (extern und intern), um verschiedene Abschnitte der Anwendungen zu verwenden und Daten zu erstellen und zu genehmigen.

# 5. Integration mit externen Softwaresystemen:

Normalerweise muss eine Softwareanwendung, die beim Kunden bereitgestellt werden soll, mit vorhandener Software verbunden sein, die möglicherweise bereits dort vorhanden ist.

Zum Beispiel: Mit dem Drucksystem haben sie in Gebrauch oder es können externe Systeme wie eine Abrechnungsanwendung oder Datenbildschirmsysteme sein. Die bereitgestellte Softwareanwendung sollte sich nahtlos in diese externen Systeme integrieren lassen. Alle Ein- und Ausgänge dieser Systeme sollten synchron arbeiten. Die heutige Technologie umfasst mobile Apps und verschiedene Softwareplattformen, die die Anwendung sein muss kompatibel mit .

Die Überprüfung auf externe Systemschnittstellen sollte während der System- und UAT-Phasen ausführlich durchgeführt werden. Es sollte ein Muss für die Exit-Kriterien sein, die vor dem Go-Live erfüllt sein sollten.

# 6. Berichte:

Berichte aus der Softwareanwendung sind eine wichtige Methode, um zu zeigen, dass die Daten in der Anwendung übereinstimmen.

Zum Beispiel: Alle abrechnungsbezogenen Daten müssen in den Guthaben- und Debitguthaben übereinstimmen.

  • Alle Daten in der Software müssen abgeglichen werden. Diese Abstimmung der Daten innerhalb der Software wird durch Berichte angezeigt und sie müssen wie beabsichtigt funktionieren.
  • Dies gilt insbesondere dann, wenn die Datenmigration von einem alten System auf ein neues System die Hauptabsicht der aktuellen Version ist.

# 7. Datenmigration:

Wenn ein altes System durch ein neues ersetzt wird, werden Daten aus dem alten System in das neue System verschoben (nachdem mit dem neuen System ein Stichtag erreicht wurde). Die migrierten Daten sollten unterstützt werden durch das neue System, wie es beim Sammeln von Anforderungen definiert wurde.

Möglicherweise sind nicht alle alten Daten im neuen System verfügbar. Im neuen System kann jedoch eine Momentaufnahme der alten Daten verfügbar sein. Diese Daten sollten wie vereinbart verfügbar sein.

Hinweis : Die obige Liste ist nicht vollständig. Abhängig vom Typ der Anwendung müssen möglicherweise weitere Dinge überprüft werden, oder es ist möglicherweise nicht alles oben Genannte anwendbar. Ein gründliches Verständnis der Software, des Geschäftszwecks, der Benutzererwartungen sowie der Architektur- oder Hardwareabhängigkeiten ist daher ein Muss, um umfassende Exit-Kriterien zu entwickeln.

Ein Beispiel für ein Exit-Kriterium für die Inbetriebnahme:

Dies ist nur ein Beispiel. Es kann von Projekt zu Projekt variieren.

  • 100% der Fehler der Priorität 1 sind geschlossen (Schweregrad kritisch und Priorität 1)
  • 90% der Fehler der Priorität 2 sind geschlossen (Schweregrad hoch und Priorität 2), wobei für den Rest der 10% der Fehler eine logische Problemumgehung verfügbar ist. Außerdem steht ein Plan zur Verfügung, um die restlichen 10% der Mängel zu beheben.
  • Die Checkliste für Produktionsbereitstellung und Vernunft ist fertig.
  • Das Produktionsteam wurde gebildet und ist bereit, Tickets zu schließen.
  • 70% der Mängel der Priorität 3 sind geschlossen, und es ist ein Plan vorhanden, um die restlichen 30% der geringen Mängel zu schließen.

Einige Punkte zu beachten:

  • Alle Schweregrad- und Prioritätsdefinitionen werden während der Geschäftstreffen zwischen dem Kunden und dem Lieferanten zu Beginn des Programms festgelegt.
  • Nachdem alle UAT-Mängel protokolliert und alle anderen Mängel geschlossen wurden, treffen sich UAT-Koordinatoren und Geschäftssponsoren, um eine Bestandsaufnahme der anstehenden und offenen Mängel vorzunehmen. Wenn alle für die Inbetriebnahme von Tag 1 erforderlichen Mängel behoben sind, sehen die Geschäftssponsoren ihre Bereitschaft zur Inbetriebnahme und bringen die Software in Produktion.

Abschließend

Wir hoffen, dass dieser Artikel Ihnen einige Einblicke in einige der wichtigen Überlegungen gegeben hat, die bei der Erstellung grundlegender Ausstiegskriterien erforderlich sind, um die Software vor möglichen Fehlern bei Produktionen zu schützen.

Über den Autor: Dies ist ein Gastartikel von Krishnan Venkatraman. Er verfügt über fast 18 Jahre Erfahrung im Testen von Software. Er hat an vielen großen und komplexen Software-Testprojekten gearbeitet.

Fühlen Sie sich frei, Ihre Fragen / Kommentare unten zu posten.

Literatur-Empfehlungen

^