Fundamentales Problem des Testens

Einführung

Guten Tag, liebe Habr-Benutzer. Kürzlich habe ich eine Testaufgabe für die Stelle als QA Lead bei einem Fintech-Unternehmen bearbeitet. Die erste Aufgabe bestand darin, einen Testplan mit einer vollständigen Checkliste und Beispielen für Testfälle zur Überprüfung eines elektrischen Wasserkochers zu erstellen, was sich als recht trivial herausstellte:

• GOST 7400-81. Elektrische Wasserkocher und elektrische Samoware für den Haushaltsgebrauch. 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 einer vollständigen Checkliste zu entwickeln, ist kaum möglich.

Die zweite Frage lautete: "Gibt es Probleme, die allen Testern gemeinsam sind und die die Effizienz ihrer Arbeit beeinträchtigen?"

Das erste, was mir in den Sinn kam, war, alle mehr oder weniger bemerkenswerten Probleme aufzulisten, mit denen ich beim Testen konfrontiert wurde, unwichtige Punkte herauszufiltern und den Rest zu verallgemeinern. Doch schnell wurde mir klar, dass die induktive Methode die Frage nicht für "alle", sondern bestenfalls für "die meisten" Tester beantworten kann. Daher entschloss ich mich, die deduktive Herangehensweise zu wählen, und hier ist, was dabei herauskam.

Definitionen

Das Erste, was ich normalerweise tue, wenn ich eine neue Aufgabe angehe, ist, zu versuchen, zu verstehen, worum es dabei geht. Dazu muss ich die Bedeutung der Begriffe, mit denen sie formuliert ist, begreifen. Die Schlüsselbegriffe, die es zu klären gilt, sind:

• ein Problem
• Tester
• Arbeit eines Testers
• Effizienz der Arbeit eines Testers

Schauen wir in die Wikipedia und auf den gesunden Menschenverstand:
Problem (altgriechisch πρόβλημα) bedeutet im weitesten Sinne - eine komplexe theoretische oder praktische Frage, die Studium und Lösung erfordert; in der Wissenschaft - eine widersprüchliche Situation, die durch gegensätzliche Positionen in der Erklärung bestimmter Phänomene, Objekte und Prozesse gekennzeichnet ist und eine adäquate Theorie zu ihrer Lösung benötigt; im Leben wird das Problem in einer für die Menschen verständlichen Form formuliert: „Ich weiß, was ich will, aber ich weiß nicht, wie“. Das bedeutet, dass bekannt ist, was erreicht werden muss, aber unklar bleibt, wie man es erreichen kann. Der Begriff stammt aus dem späten Lateinischen problēma, aus dem Griechischen πρόβλημα „nach vorne geworfen, voran gestellt“; von προβάλλω „nach vorne werfen, sich präsentieren; anklagen“.

Im Grunde genommen bedeutet „Problem“ nicht viel, es ist einfach „irgendetwas, das geklärt werden muss“.
Tester — Fachkraft (wir unterscheiden nicht nach Arten, da uns alle Tester interessieren), die an der Prüfung eines Komponenten oder Systems beteiligt ist, deren Ergebnisse sind:
Die Arbeit des Testers — eine Reihe von Aktivitäten, 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 Konsequenz einer Reihe von Handlungen oder Ereignissen, die qualitativ oder quantitativ ausgedrückt werden. Mögliche Ergebnisse umfassen Vorteil, Unannehmlichkeit, Nutzen, Verlust, Wert und Sieg.
Wie bei dem "Problem" hat dies wenig Sinn: etwas, das am Ende der Arbeit herausgekommen ist.
Ressource — quantitativ messbare Fähigkeit, irgendeine Tätigkeit eines Menschen oder von Menschen auszuführen; Bedingungen, die es ermöglichen, durch bestimmte Transformationen das gewünschte Ergebnis zu erzielen. Ein Tester ist ein Mensch, und gemäß der Theorie der Vitalressourcen besitzt jeder Mensch vier wirtschaftliche Vermögenswerte:
Finanzen (Einkommen) — eine erneuerbare Ressource;
Energie (Lebensenergie) — eine teilweise erneuerbare Ressource;
Zeit ist eine feste und prinzipiell nicht erneuerbare Ressource;
Wissen (Information) ist eine erneuerbare Ressource, ein Teil des Humankapitals, das sowohl wachsen als auch abbauen kann.[1].

Ich möchte anmerken, dass die Definition von Effizienz in unserem Fall nicht ganz korrekt ist, da die Effizienz sinkt, je mehr Wissen wir nutzen. Daher würde ich Effizienz als "Verhältnis zwischen erzieltem Ergebnis und eingesetzten Ressourcen" neu definieren. Dann ist alles korrekt: Wissen wird bei der Arbeit nicht verbraucht, reduziert jedoch die Kosten der einzigen prinzipiell nicht erneuerbaren Ressource eines Testers – seiner Zeit.

Lösung

Lassen Sie uns also die globalen Probleme der Tester untersuchen, die die Effizienz ihrer Arbeit beeinträchtigen.
Die bedeutendste Ressource, die bei der Arbeit eines Testers aufgebraucht wird, ist seine Zeit (alle anderen können irgendwie darauf zurückgeführt werden), und damit wir von einer korrekten Berechnung der Effizienz sprechen können, muss auch das Ergebnis in Bezug auf die Zeit betrachtet werden.
Dazu betrachten wir ein System, dessen Lebensfähigkeit durch die Arbeit eines Testers gewährleistet wird. Ein solches System ist ein Projekt, in dem ein Tester Teil des Teams ist. Der Lebenszyklus des Projekts lässt sich grob in folgendem Algorithmus darstellen:

1. Arbeiten mit Anforderungen
2. Erstellung des Pflichtenhefts
3. Entwicklung
4. Testen
5. Produktionsfreigabe
6. Support (zurück zu Punkt 1)

Dabei kann das gesamte Projekt rekursiv in Teilprojekte (Features) untergliedert werden, die denselben Lebenszyklus aufweisen.
Aus Sicht des Projekts ist die Effizienz seiner Umsetzung umso größer, je weniger Zeit dafür aufgewendet wird.
Somit gelangen wir zu der Definition der maximal möglichen Effizienz eines Testers aus Projektsicht — dies ist der Zustand des Projekts, in dem die Testzeit gleich null ist. Das allgemeine Problem für alle Tester besteht darin, dass dieser Zustand nicht erreicht werden kann.

Wie sollte man damit umgehen?

Die Schlussfolgerungen sind durchaus offensichtlich und werden von vielen bereits lange genutzt:

1. Entwicklung und Test sollten praktisch zeitgleich beginnen und enden (in der Regel wird dies von der Abteilung QA). Eine ideale Lösung besteht darin, dass alle entwickelten Funktionen zum Zeitpunkt der Fertigstellung bereits durch automatisierte Tests abgedeckt sind, die in eine Regressionstestsuite (und wenn möglich, auch in Pre-Commit-Tests) organisiert sind, basierend auf einem bestimmten CI.
2. . Je mehr Funktionen ein Projekt hat (je komplexer es ist), desto mehr Zeit muss aufgewendet werden, um sicherzustellen, dass die neuen Funktionen die alten nicht beschädigen. Daher gilt: Je komplexer das Projekt, desto mehr Automatisierung ist erforderlich. regression testing.
3. . Jedes Mal, wenn wir einen Bug in die Produktion übersehen und ein Benutzer ihn findet, müssen wir zusätzliche Zeit aufwenden, um den Projektlebenszyklus ab Punkt 1 (Arbeit mit Anforderungen, in diesem Fall den Benutzern) zu durchlaufen. Da die Gründe für das Übersehen eines Bugs im allgemeinen unbekannt sind, bleibt uns nur ein Weg zur Optimierung: Jeder von Benutzern gefundene Bug sollte in die Regressionstests aufgenommen werden, um sicherzustellen, dass er nicht erneut auftritt.

Quelle: habr.com