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
