Das Grundproblem des Testens

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:

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:
Problem (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.“
PrĂŒfer - 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:
Arbeit des Testers — eine Reihe von AktivitĂ€ten im Zusammenhang mit Tests.
Effizienz (lat. effectivus) – die Beziehung zwischen dem erzielten Ergebnis und den eingesetzten Ressourcen (ISO 9000 : 2015).
Ergebnis - 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.
Ressource - 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[1]..

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:

  1. Arbeiten mit Anforderungen
  2. Erstellung technischer Spezifikationen
  3. Entwicklung
  4. Testing
  5. Freigabe fĂŒr die Produktion
  6. 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:

  1. Entwicklung und Test sollten nahezu gleichzeitig beginnen und enden (dies erfolgt in der Regel durch die Abteilung). QA). 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 CI.
  2. 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 Regressionstests.
  3. 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

Kaufen Sie zuverlĂ€ssiges Hosting fĂŒr Websites mit DDoS-Schutz und VPS-VDS-Servern đŸ”„ Kaufen Sie zuverlĂ€ssiges Webhosting mit DDoS-Schutz, VPS- und VDS-Server | ProHoster