Dies ist eine maschinell übersetzte Version des englischen Originals Functional and Nonfunctional Testing – Stakeholder Management – da mein Deutsch eher rudimentär ist, denke ich, dass dies immer noch eine bessere Lösung ist. Wenn Sie einen eklatanten Übersetzungsfehler bemerken, wenden Sie sich bitte an mich und ich werde es wieder gutmachen. Ich danke Ihnen.
Ich beginne zu erkennen, dass das nichtfunktionale Testen vor allem unter Geschäftsleuten ein ziemlich undurchsichtiges Gebiet ist, über das es sich zu diskutieren lohnt. Selbst Testern fällt es oft schwer zu verstehen, warum wir viel Zeit und Mühe auf verschiedene Aspekte der Leistungstests verwenden müssen. Und mit den Interessenvertretern der Wirtschaft ist es doppelt schwer.
Hier sind also meine Erfahrungen mit einigen der Dinge, die Sie mit der Geschäftsleitung, den Produktverantwortlichen, den Mitarbeitern von Infrastruktur und Betrieb und Ihren eigenen Entwicklern besprechen müssen. Es dauert länger als erwartet. Sie werden wahrscheinlich mehr Widerstand gegen Ihre besten Absichten erfahren, aktiv und passiv, als Sie erwarten. Und Sie müssen die Menschen in Ihrem Umfeld schulen, damit sie die Auswirkungen des Verzichts auf Leistungstests besser und besser verstehen. Sie müssen sich über die Risiken im Klaren sein, die das Unternehmen eingeht, wenn es diesen Bereich vernachlässigt, und über die Schäden, die sich daraus für das Produkt ergeben können, sowie über die Auswirkungen auf die Gesamtbetriebskosten für den von Ihnen betriebenen Dienst. Dies ist ein langwieriger Prozess, daher sollten Sie frühzeitig damit beginnen und sich auf die langfristigen Ziele konzentrieren.
Es gibt zwei Szenarien, in denen Sie sich gerade befinden könnten:
Erstens, wenn das Produkt noch auf der Suche nach ein paar echten Kunden ist, ist es wirklich schwer zu sagen, was kaputt gehen wird. Zweitens: Ihr Produkt ist bereits im Umlauf, und es gibt Support-Tickets und Kundenbeschwerden, so dass die Notwendigkeit einer Leistungsoptimierung ganz offensichtlich ist. Wie gehen Sie also mit der ersten Situation um und wie gehen Sie mit der zweiten um, wenn Sie ein Tester sind, der nicht funktionale Ideen im Kopf hat. (Und das Szenario mit dem 1-Fehler-Szenario bedeutet, dass Sie all dies bereits hinter sich haben und ein Performance-Projekt auf den Weg gebracht haben. Wenn dem so ist, schreiben Sie mir eine E-Mail und lassen Sie uns Strategien vergleichen, um zu sehen, wo wir uns noch verbessern können).
Nichtfunktionale Tests für Softwareprodukte vor der Markteinführung (Das Warum, Was und Wie)
Das erste Szenario setzt voraus, dass eine ziemlich reife Organisation erkennt, dass die erste Version der Software wahrscheinlich nicht gut genug für den Markt ist. Das bedeutet, dass Sie Ihre Mitarbeiter daran erinnern müssen, dass auch nichtfunktionale Aspekte eines MVP ordnungsgemäß getestet werden müssen und nicht einfach angenommen werden darf, dass sie funktionieren.
Die meisten Leute gehen davon aus, dass das Produkt oder die Dienstleistung in Ordnung sein wird, vielleicht ein bisschen langsam, aber die Kunden werden es trotzdem lieben. Aber meistens ist nicht die Geschwindigkeit oder vielmehr die Langsamkeit das Problem. Stattdessen wird Ihre Software abstürzen. Allerdings nicht unter der hohen Last. Wenn Sie Glück haben, handelt es sich eher um betriebliche Probleme. Die Protokolle werden nicht rotiert, dem Knoten geht in der siebten Woche die Festplatte aus, und die ganze Sache kommt zum Stillstand, und weil es keine angemessene Überwachung gibt, merkt das niemand, bis der Kunde am Montag einen Blick darauf wirft.
Sie könnten sagen: “Nun, das ist eine betriebliche Angelegenheit, also geht es mich nichts an, ich leite hier ein Entwicklungsteam, kein Betriebsteam”. Aber das wäre falsch. Leistung ist eine betriebliche Angelegenheit. Ihre Software existiert in einem Ökosystem auf einer mehrschichtigen Plattform, so dass alles, was sich auf die Leistung auswirkt, Ihre Angelegenheit ist. Ihren Kunden ist es egal, warum die Software nicht funktioniert, für sie ist das Einzige, woran sie sich erinnern können, dass sie funktioniert.
Wenn Sie nicht so viel Glück haben und mit Java (oder Python oder C#) arbeiten, kann es passieren, dass Sie ein fieses Speicherleck haben, das nur bei Mondfinsternissen auftritt, wenn der Kunde einen Vor- und einen Mittelnamen hat, die beide mit X beginnen. Und es dauert Wochen, um herauszufinden, wo es auftritt. Und Wochen, um es zu beheben, zu testen und zu patchen.
Wie bereiten Sie sich also als Tester darauf vor?
Bevor Sie in die Produktion gehen, sollten Sie die folgenden drei Gruppen von Leistungstests durchführen. Aber bevor Sie diese Tests durchführen, sollten Sie mit vielen Leuten sprechen, um zu erklären, warum sie notwendig sind und welche Voraussetzungen Sie brauchen.
- Testen Sie Ihre Anwendung drei Wochen lang auf Herz und Nieren.
- Starten Sie alle Komponenten ein paar Mal neu.
- Geben Sie eine halbe Million Datensätze in Ihre DB ein und führen Sie einen Regressionstest unter mäßiger Last durch.
Warum all diese Dinge testen?
Warum sollten Sie sich all diese Mühe machen, wenn Sie bereits wissen, dass Ihre Funktionen richtig funktionieren? Weil Sie wissen, wie es funktioniert, aber Sie wissen nicht, wie es scheitert. Weil Sie noch nicht wissen, wie Ihre Software, Ihre gesamte Lösung und Ihre Infrastruktur versagt. Hier sind also zehn Gründe, warum Sie eine erste Reihe von Leistungstests für Ihr neues Produkt durchführen sollten.
Betrachten Sie die nachstehende Liste als wichtigen Tagesordnungspunkt in all Ihren Gesprächen mit allen Geschäftsleuten, vom Vertrieb bis zu den Teas-Leads und dem CEO.
Die 10 wichtigsten Gründe, um Ihren CEO/Produktleiter davon zu überzeugen, vor der Markteinführung Leistungstests durchzuführen
1. Ihr erster Kunde ist wirklich schwer zu bekommen. An dem Tag, an dem er den Vertrag unterschreibt, gibt es eine kleine Feier, und an einem anderen Tag geht er in den Vertrieb. Das Letzte, was Sie wollen, ist also ein paar Tage später ein größerer Zwischenfall, weil Sie Ihre eigene Software nie länger als ein paar Stunden betrieben haben. Sie wollen nicht innerhalb von 4 Tagen den guten Ruf verlieren, für den Sie monatelang gearbeitet haben, und das wegen einer dummen kleinen Panne. Das lässt sich durch keine noch so gute Erklärung aus der Welt schaffen.
2. Der Soak stellt sicher, dass es keine größeren Stabilitätsprobleme gibt. Er hilft Ihnen, Softwarefehler zu finden, von denen Sie nicht wussten, dass es sie gibt. So können Sie eine Software auf den Markt bringen, die gut genug ist – nicht in Ihren Augen, sondern in den Augen Ihres ersten Kunden.
3. Durch den Neustart aller Komponenten erfahren Sie, wie sich Ihr System erholt oder wie es sich aufhängt. Bei den Funktionstests lief Ihr System bereits reibungslos und tuckerte gemütlich vor sich hin. Für die Produktion müssen Sie wissen, wie lange es dauert, bis es nach einer Störung wieder anläuft. Es steht außer Frage, dass eine oder mehrere Ihrer Komponenten ausfallen werden. Die Frage ist nicht, warum sie ausfallen – dafür haben Sie später noch genug Zeit, um das herauszufinden. Die Frage ist jetzt, ob sie sich erholen können, ob wir die Wiederherstellung beschleunigen können, ob wir einige Selbstheilungsmechanismen einbauen können.
4. Eine halbe Million Datensätze in Ihrer DB klingt nach viel, aber das ist das absolute Minimum. Bis jetzt hast du diese Fahrt nur mit dir am Steuer gemacht. Und glaub mir, es fühlt sich ganz anders an, wenn meine Mutter auf dem Beifahrersitz sitzt, Mann, mein kleines Auto fühlt sich wie ein ganz anderes Auto an.
5. Sie müssen Ihr Team so schulen, dass es in der Lage ist, Ihr System an einem Feiertag um 2 Uhr morgens über ein Mobiltelefon zu starten. Wenn sie dies zum ersten Mal während eines Kundenvorfalls an einem Produktionssystem tun, wird es unnötig stressig und übermäßig lang und kompliziert sein. Wenn Sie mit der zweiten Übung fertig sind, verfügen Sie über die Wiki-Seiten, die für Notstarts und Neustarts benötigt werden.
6. Zu diesem Zeitpunkt haben Sie Annahmen darüber, welche Komponenten voneinander abhängen könnten. Viele dieser Abhängigkeiten sind jedoch unsichtbar, bis Sie absturzähnliche Szenarien simulieren. Tun Sie sich also selbst einen Gefallen, indem Sie einige Neustart-Experimente durchführen, um sicherzustellen, dass Sie wissen, wie Ihre Software laufen soll.
7. Wenn Ihre Software produktionsreif ist, ist es Ihr Betriebsteam noch nicht. Wenn Sie Ihre Software in Betrieb nehmen und einige Wochen lang laufen lassen, können Sie Ihr Team darin schulen, die Produktionsumgebung richtig einzurichten.
8. Wenn Ihre Datenbank optimiert werden muss, sollten Sie dies bei Ihrem regulären Funktionstest mit einer geladenen DB feststellen. Vielleicht brauchen Sie eine weitere Tabelle, eine Ansicht oder eine andere Änderung in der Struktur. Und das ist viel einfacher, schneller, billiger und sicherer zu machen, bevor Sie in die Produktion gehen als danach.
9. Die Durchführung von Regressionstests mit anderem Datenverkehr hilft Ihnen auch dabei, Race Conditions und Corner Cases aufzudecken, die Sie übersehen haben und die in der Produktivphase nur auftauchen würden, wenn bereits ein gewisser Datenverkehr im System herrscht.
10. Die Einführung von nichtfunktionalen Tests in Ihrem Unternehmen zu einem frühen Zeitpunkt im SDLC ist in vielerlei Hinsicht hilfreich.
- Es positioniert Sie als jemanden, der sich um die Gesamtqualität der Software kümmert. Sie sind der Qualitätsverfechter, nach dem in allen Stellenanzeigen gesucht wird.
- Es hilft den Leuten zu verstehen, dass die Einstellung des Kunden mehr ist als nur der Wunsch nach allen Funktionen und Merkmalen. Die Kunden haben ein unausgesprochenes Verständnis dafür, dass Ihre Software einfach funktioniert. Dass sie keine ständige Quelle von Schmerzen und Kopfschmerzen, Eskalationen und Enttäuschungen sein wird. Sie wollen einfach nur, dass die Software die meiste Zeit über reibungslos und ohne Störungen läuft, und es ist Ihre Aufgabe, dafür zu sorgen, dass dies der Fall ist.
- Außerdem ebnen Sie damit langfristig den Weg für weitere nichtfunktionale Dinge, von Volumen- und Lasttests bis hin zu Wiederherstellungstests und den technischen Aspekten der Notfallwiederherstellung.
+1 aka #11
Die Einrichtung und Durchführung dieser Tests ist auch relativ kostengünstig. Es würde den Liefertermin um etwa sechs Wochen verlängern. Es sind keine größeren Investitionen in Hardware oder Software erforderlich, die über das hinausgehen, was Sie ohnehin benötigen würden. Sie können Ihre Fähigkeiten nach und nach verbessern, selbst wenn es etwas Neues im Perf-Tooling gibt. Geringes Risiko, niedrige Kosten, vollständige Vorhersehbarkeit, und Sie können ein Produkt auf den Markt bringen, das sehr viel stabiler und belastbarer ist.
Im folgenden Abschnitt wird beschrieben, was Sie im Rahmen Ihrer Leistungstests vor der Markteinführung testen sollten, wie und warum, und es wird erläutert, wie die Ergebnisse Ihrer Leistungstests zu interpretieren sind.
