Einführung
Guten Tag, liebe Chabrowsk-Bewohner. Gerade habe ich eine Testaufgabe für eine offene Stelle als QA-Leiter für ein Fintech-Unternehmen gelöst. Die erste Aufgabe, einen Testplan mit einer vollständigen Checkliste und Beispielen für Testfälle zum Testen eines Wasserkochers zu erstellen, lässt sich trivial lösen:
Es gibt kaum einen besseren Testplan mit einer vollständigen Checkliste.
Doch der zweite Teil entpuppte sich als Frage: „Gibt es gemeinsame Probleme aller Tester, die sie daran hindern, effizienter zu arbeiten?“
Das erste, was mir in den Sinn kam, war, alle mehr oder weniger auffälligen Probleme aufzulisten, auf die ich beim Testen gestoßen bin, die kleinen Dinge auszusortieren und den Rest zusammenzufassen. Aber mir wurde schnell klar, dass die induktive Methode eine Frage beantworten würde, die nicht für „alle“, sondern bestenfalls nur für „die Mehrheit“ der Tester galt. Deshalb beschloss ich, es von der anderen Seite her anzugehen, deduktiv, und genau das ist passiert.
definieren
Wenn ich ein neues Problem löse, versuche ich normalerweise zunächst zu verstehen, worum es geht, und dazu muss ich die Bedeutung der Wörter verstehen, die es stellen. Die Schlüsselwörter, die es zu verstehen gilt, sind die folgenden:
- Problem
- Prüfer
- Job als Tester
- Effizienz des Testers
Wenden wir uns Wikipedia und dem gesunden Menschenverstand zu:
(altgriechisch πρόβλημα) im weitesten Sinne – ein komplexes theoretisches oder praktisches Problem, das untersucht und gelöst werden muss; in der Wissenschaft - eine widersprüchliche Situation, die in Form gegensätzlicher Positionen bei der Erklärung jeglicher Phänomene, Objekte, Prozesse auftritt und zu ihrer Lösung eine adäquate Theorie erfordert; Im Leben wird das Problem in einer für die Menschen verständlichen Form formuliert: „Ich weiß was, ich weiß nicht wie“, das heißt, es ist bekannt, was erreicht werden muss, aber es ist nicht bekannt, wie es geht . Kommt von spät. lat. Problem, aus dem Griechischen. πρόβλημα „nach vorne geworfen, vorn platziert“; von προβάλλω „nach vorne werfen, vor dich stellen; beschuldigen".
Tatsächlich macht es wenig Sinn: „Problem“ = „alles, was gelöst werden muss.“
- ein Spezialist (wir werden nicht in Typen einteilen, da wir an allen Testern interessiert sind), der an der Prüfung einer Komponente oder eines Systems teilnimmt, deren Ergebnis ist:
— eine Reihe von Aktivitäten im Zusammenhang mit Tests.
(lat. effectivus) – die Beziehung zwischen dem erzielten Ergebnis und den eingesetzten Ressourcen (: 2015).
- eine Folge einer Kette (Reihe) von Handlungen (Ergebnis) oder Ereignissen, qualitativ oder quantitativ ausgedrückt. Mögliche Ergebnisse sind Vorteil, Nachteil, Gewinn, Verlust, Wert und Sieg.
Wie beim „Problem“ gibt es wenig Bedeutung: etwas, das als Ergebnis der Arbeit entstanden ist.
- die quantitativ messbare Möglichkeit, eine Tätigkeit einer Person oder von Personen auszuüben; Bedingungen, die es ermöglichen, bestimmte Transformationen zu verwenden, um das gewünschte Ergebnis zu erzielen. Der Tester ist eine Person, und gemäß der Theorie der lebenswichtigen Ressourcen ist jede Person Eigentümer von vier Wirtschaftsgütern:
Bargeld (Einkommen) ist eine erneuerbare Ressource;
Energie (Lebenskraft) ist eine teilweise erneuerbare Ressource;
Zeit ist eine feste und grundsätzlich nicht erneuerbare Ressource;
Wissen (Informationen) ist eine erneuerbare Ressource, es ist Teil des Humankapitals, das wachsen und zerstört werden kann.
Ich möchte anmerken, dass die Definition von Effizienz in unserem Fall nicht ganz korrekt ist, denn je mehr Wissen wir nutzen, desto geringer ist die Effizienz. Daher würde ich Effizienz neu definieren als „das Verhältnis zwischen den erzielten Ergebnissen und den aufgewendeten Ressourcen“. Dann ist alles richtig: Wissen wird bei der Arbeit nicht verschwendet, aber es reduziert die Kosten für die einzige grundsätzlich nicht erneuerbare Ressource des Testers – seine Zeit.
Lösung
Wir suchen also nach globalen Problemen von Testern, die die Effektivität ihrer Arbeit beeinträchtigen.
Die bedeutendste Ressource, die für die Arbeit eines Testers aufgewendet wird, ist seine Zeit (der Rest kann auf die eine oder andere Weise darauf reduziert werden), und damit wir über die korrekte Berechnung der Effizienz sprechen können, muss das Ergebnis auch auf die Zeit reduziert werden .
Betrachten Sie dazu ein System, dessen Funktionsfähigkeit der Tester durch seine Arbeit sicherstellt. Ein solches System ist ein Projekt, zu dessen Team ein Tester gehört. Der Projektlebenszyklus kann grob durch den folgenden Algorithmus dargestellt werden:
- Arbeiten mit Anforderungen
- Erstellung technischer Spezifikationen
- Entwicklung
- Testing
- Freigabe für die Produktion
- Support (gehe zu Punkt 1)
In diesem Fall kann das gesamte Projekt rekursiv in Teilprojekte (Features) mit demselben Lebenszyklus unterteilt werden.
Aus Projektsicht gilt: Je weniger Zeit dafür aufgewendet wird, desto effektiver ist die Umsetzung.
Damit kommen wir zur Definition der maximal möglichen Effizienz eines Testers aus Sicht des Projekts – das ist der Zustand des Projekts, wenn die Zeit zum Testen Null ist. Ein gemeinsames Problem aller Tester ist die Unfähigkeit, diese Zeit einzuhalten.
Wie gehe ich damit um?
Die Schlussfolgerungen liegen auf der Hand und werden von vielen schon seit langem verwendet:
- Entwicklung und Test sollten nahezu gleichzeitig beginnen und enden (dies erfolgt in der Regel durch die Abteilung). ). Die ideale Option besteht darin, dass die gesamte zu entwickelnde Funktionalität zum Zeitpunkt ihrer Fertigstellung bereits durch Autotests abgedeckt ist, die in Regressionstests (und, wenn möglich, Pre-Commit-Tests) unter Verwendung einer Art von Autotests organisiert sind .
- Je mehr Funktionen ein Projekt hat (je komplexer es ist), desto mehr Zeit muss darauf verwendet werden, zu prüfen, ob die neue Funktionalität die alte nicht kaputt macht. Je komplexer das Projekt ist, desto mehr Automatisierung ist erforderlich .
- Jedes Mal, wenn wir einen Fehler in der Produktion übersehen und ein Benutzer ihn findet, müssen wir zusätzliche Zeit damit verbringen, den Projektlebenszyklus beginnend mit Punkt 1 (Arbeiten mit Anforderungen, in diesem Fall Benutzern) zu durchlaufen. Da die Gründe für das Übersehen eines Fehlers im Allgemeinen unbekannt sind, bleibt uns nur ein Optimierungspfad: Jeder von Benutzern gefundene Fehler muss in Regressionstests einbezogen werden, um sicherzustellen, dass er nicht erneut auftritt.
Source: habr.com