Fundamentales Problem beim Testen

Einführung

Guten Tag, Habr-Bewohner. Ich habe kürzlich eine Testaufgabe für die Position des QA Lead in einem Fintech-Unternehmen gelöst. Die erste Aufgabe, einen Testplan mit vollständiger Checkliste und Beispielen von Testfällen zur Überprüfung eines elektrischen Wasserkochers zu erstellen, ist trivial zu lösen:

• GOST 7400-81. Elektrische Wasserkocher und elektrische Samoware für den Hausgebrauch. Technische Bedingungen (mit Änderungen N 1-8)
• GOST IEC 60335-1-2015 Haushalts- und ähnliche elektrische Geräte. Sicherheit. Teil 1. Allgemeine Anforderungen
  Einen besseren Testplan mit vollständiger Checkliste zu entwerfen, ist schwierig.

Die zweite Frage war jedoch: „Gibt es Probleme, die alle Tester betreffen und die Effizienz der Arbeit beeinträchtigen?“

Das erste, was mir in den Sinn kam: Alle mehr oder weniger auffälligen Probleme aufzulisten, mit denen ich beim Testen konfrontiert wurde, Kleinigkeiten auszusondern und den Rest zu verallgemeinern. Ich erkannte jedoch schnell, dass die induktive Methode die Frage nicht für „alle“, sondern bestenfalls für „die Mehrheit“ der Tester beantworten würde. Deshalb beschloss ich, einen anderen, deduktiven Ansatz zu wählen, und hier ist das Ergebnis.

Definitionen

Das Erste, was ich normalerweise tue, wenn ich eine neue Aufgabe löse, ist, zu versuchen zu verstehen, worum es geht. Dafür muss ich den Sinn der Worte verstehen, mit denen sie formuliert wurde. Die Schlüsselwörter, die es zu klären gilt, sind folgende:

• Problem
• Tester
• Arbeit des Testers
• Effizienz der Arbeit des Testers

Lass uns Wikipedia und den gesunden Menschenverstand zurate ziehen:
Problem (altgriechisch πρόβλημα) bedeutet im weitesten Sinne eine komplexe theoretische oder praktische Frage, die untersucht und gelöst werden muss; in der Wissenschaft ist es eine widersprüchliche Situation, die in Form von gegensätzlichen Positionen zur Erklärung bestimmter Phänomene, Objekte, Prozesse auftritt und eine adäquate Theorie für ihre Lösung erfordert; im Leben wird das Problem verständlich formuliert als „ich weiß, was ich will, aber ich weiß nicht, wie“. Das heißt, es ist bekannt, dass etwas erreicht werden muss, aber unklar, wie es zu tun ist. Es stammt von spätlateinisch problēma, aus dem griechischen πρόβλημα „vorausgeworfen, nach vorn gestellt“; von προβάλλω „nach vorn werfen, vor sich darstellen; beschuldigen“.

Es gibt nicht viel Sinn, im Grunde genommen bedeutet „Problem“ = „alles, worum man sich kümmern muss“.
Tester — ein Spezialist (wir werden nicht zwischen den Arten unterscheiden, da uns alle Tester interessieren), der an der Testung eines Komponenten oder eines Systems beteiligt ist, dessen Ergebnis ist:
Arbeit des Testers — ein Komplex von Maßnahmen, die sich auf das Testen beziehen.
Effektivität (lat. effectivus) — das Verhältnis zwischen dem erreichten Ergebnis und den eingesetzten Ressourcen (ISO 9000:2015).
Ergebnis — die Folge einer Kette (Reihe) von Handlungen (Ergebnis) oder Ereignissen, die qualitativ oder quantitativ ausgedrückt wird. Mögliche Ergebnisse umfassen Vorteil, Unannehmlichkeit, Nutzen, Verlust, Wert und Sieg.
Wie bei dem "Problem" hat es wenig Sinn: etwas, das als Ergebnis der Arbeit entstanden ist.
Ressource — quantitativ messbare Fähigkeit, eine bestimmte Tätigkeit von Menschen oder Gruppen auszuführen; Bedingungen, die es ermöglichen, durch bestimmte Umwandlungen das gewünschte Ergebnis zu erzielen. Ein Tester ist eine Person, und gemäß der Theorie der Lebensressourcen besitzt jeder Mensch vier wirtschaftliche Vermögenswerte:
Geldmittel (Einkommen) — erneuerbare Ressource;
Energie (Lebenskraft) — teilweise erneuerbare Ressource;
Zeit — feste und prinzipiell nicht erneuerbare Ressource;
Wissen (Informationen) — erneuerbare Ressource, die Teil des Humankapitals ist, das sowohl wachsen als auch zerstört werden kann.[1].

Ich möchte anmerken, dass die Definition von Effektivität in unserem Fall nicht ganz korrekt ist, da je mehr Wissen wir nutzen, desto geringer die Effektivität wird. Deshalb würde ich die Effektivität als "Verhältnis zwischen dem erzielten Ergebnis und den aufgewendeten Ressourcen" neu definieren. Dann ist alles korrekt: Wissen wird bei der Arbeit nicht verbraucht, verringert jedoch die Ausgaben der einzigen prinzipiell nicht erneuerbaren Ressource des Testers — seiner Zeit.

Lösung

Also suchen wir globale Probleme der Tester, die die Effektivität ihrer Arbeit verschlechtern.
Die wichtigste Ressource, die für die Arbeit eines Testers aufgebracht wird, ist seine Zeit (alle anderen können irgendwie dorthin gebracht werden), und damit wir von einer korrekten Berechnung der Effektivität sprechen können, muss auch das Ergebnis in die Zeit umgerechnet werden.
Betrachten wir dafür ein System, dessen Lebensfähigkeit der Tester durch seine Arbeit sichert. Ein solches System ist ein Projekt, in dessen Team ein Tester integriert ist. Der Lebenszyklus des Projekts lässt sich grob durch folgenden Algorithmus darstellen:

1. Arbeiten mit Anforderungen
2. Erstellung der technischen Spezifikation
3. Entwicklung
4. Tests
5. Überführung in die Produktion
6. Unterstützung (goto Punkt 1)

Dabei kann das gesamte Projekt rekursiv in Teilprojekte (Features) mit demselben Lebenszyklus unterteilt werden.
Aus Projektsicht ist die Effizienz seiner Umsetzung umso höher, je weniger Zeit dafür aufgewendet wird.
Somit kommen wir zu der Definition der maximal möglichen Effizienz eines Testers aus Sicht des Projekts – dies ist der Zustand des Projekts, bei dem die Zeit für das Testen gleich null ist. Ein allgemeines Problem für alle Tester ist, dass dieses Zeitziel nicht erreicht werden kann.

Wie damit umgehen?

Die Schlussfolgerungen sind ziemlich offensichtlich und werden bereits von vielen genutzt:

1. Entwicklung und Testen sollten nahezu zeitgleich beginnen und enden (dies wird normalerweise von der Abteilung QA). Die ideale Lösung ist, dass alle zu entwickelnden Funktionalitäten zum Zeitpunkt der Fertigstellung bereits durch automatisierte Tests abgedeckt sind, die in Regressionstests (und wenn möglich, auch in Pre-Commit-Tests) organisiert sind mit Hilfe von irgendeinem CI.
2. Je mehr Features im Projekt vorhanden sind (je komplexer es ist), desto mehr Zeit muss für die Überprüfung aufgewendet werden, dass die neue Funktionalität die alte nicht beeinträchtigt hat. Daher gilt: Je komplexer das Projekt, desto mehr Automatisierung ist erforderlich für Regressionstests..
3. Jedes Mal, wenn wir einen Bug in die Produktion lassen und der Benutzer diesen findet, müssen wir zusätzliche Zeit aufwenden, um den Lebenszyklus des Projekts ab Punkt 1 (Arbeiten mit Anforderungen, in diesem Fall mit den Anforderungen der Benutzer) zu durchlaufen. Da die Gründe für das Übersehen eines Bugs im Allgemeinen unbekannt sind, bleibt uns nur der Weg der Optimierung – jeder von Benutzern gefundene Bug muss in die Regressionstests aufgenommen werden, um sicherzustellen, dass er nicht erneut auftritt.

Quelle: habr.com