Inleiding
Goedendag, Habr-leden. Onlangs werkte ik aan een testtaak voor de functie van QA Lead bij een fintechbedrijf. De eerste taak, een testplan opstellen met een volledige checklist en voorbeelden van testcases voor het testen van een elektrische waterkoker, is triviaal op te lossen:
Het is moeilijk om een beter testplan met een volledige checklist te bedenken.
Maar het tweede deel bleek de vraag te zijn: “Zijn er problemen die voor alle testers gemeenschappelijk zijn en die het werken minder efficiënt maken?”.
Het eerste wat in me opkwam: opsommen alle meer of minder zichtbare problemen waarmee ik bij het testen te maken heb gehad, de kleinigheden filteren, en de rest generaliseren. Maar ik begreep snel dat de inductieve methode de vraag niet beantwoordt die betrekking heeft op “iedereen”, maar in het beste geval alleen op “de meeste” testers. Daarom besloot ik het vanuit een andere hoek, deductief, te benaderen, en dit is wat eruit kwam.
Definities
Het eerste wat ik doorgaans doe wanneer ik een nieuwe taak oppak, is proberen te begrijpen waar het eigenlijk om gaat, en daarvoor moet ik de betekenis begrijpen van de woorden waarmee de taak is geformuleerd. De sleutelwoorden waarmee ik me moet bezighouden zijn de volgende:
- een probleem
- tester
- werk van een tester
- effectiviteit van het werk van een tester
Laten we eens kijken naar de Wikipedia en gezond verstand:
(oudgrieks πρόβλημα) in brede zin — een complex theoretisch of praktisch vraagstuk dat studie en oplossing vereist; in de wetenschap — een tegenstrijdige situatie die zich voordoet in de vorm van tegenovergestelde posities in de uitleg van bepaalde fenomenen, objecten, processen en die een adequate theorie vereist voor de oplossing; in het leven wordt een probleem geformuleerd in een voor mensen begrijpelijke vorm 'ik weet wat ik moet krijgen, maar ik weet niet hoe', dat wil zeggen, het is bekend wat moet worden verkregen, maar het is niet bekend hoe dat te doen. Het komt van laatlatijns problēma, uit het Grieks πρόβλημα ‘vooruitgeworpen, gepresenteerd’; van προβάλλω ‘vooruit werpen, voor zichzelf plaatsen; beschuldigen’.
Er is niet veel zinvols, in feite is “probleem” = “alles waar je mee moet omgaan”.
— een specialist (we zullen niet splitsen in soorten, aangezien we geïnteresseerd zijn in alle testers), die deelneemt aan het testen van een component of systeem, waarvan het resultaat is:
— een complex van activiteiten die betrekking heeft op testen.
(Lat. effectivus) — de verhouding tussen het behaalde resultaat en de gebruikte middelen (:2015).
— het gevolg van een reeks (keten) van acties (uitkomst) of gebeurtenissen, uitgedrukt in kwalitatieve of kwantitatieve termen. Mogelijke resultaten omvatten voordelen, ongemakken, winst, verlies, waarde en overwinning.
Net als bij het begrip “probleem” heeft de betekenis weinig waarde: iets wat voortkomt uit het werk.
— een kwantitatief meetbare mogelijkheid voor de uitvoering van een activiteit door een persoon of mensen; de voorwaarden die het mogelijk maken om door bepaalde veranderingen het gewenste resultaat te bereiken. Een tester is een persoon, en volgens de theorie van vitale middelen, heeft elke persoon vier economische activa:
financiën (inkomen) — een hernieuwbare middelen;
energie (levenskracht) — een gedeeltelijk hernieuwbare middelen;
tijd — een vaste en intrinsiek niet-hernieuwbare middelen;
kennis (informatie) — een hernieuwbare middelen, dit is een deel van het menselijk kapitaal, dat kan toenemen en afnemen..
Ik wil opmerken dat de definitie van effectiviteit in ons geval niet helemaal correct is, omdat hoe meer kennis we gebruiken, hoe lager de effectiviteit blijkt te zijn. Daarom zou ik effectiviteit herdefiniëren als “de verhouding tussen het behaalde resultaat en de bestede middelen”. Dan is alles correct: kennis wordt niet verbruikt in het werk, maar verlaagt de kosten van de enige intrinsiek niet-hernieuwbare middelen van de tester — zijn tijd.
Oplossing
Dus, laten we de wereldwijde problemen van testers zoeken die de effectiviteit van hun werk verslechteren.
De meest significante hulpbron die wordt besteed aan het werk van de tester is zijn tijd (de andere kunnen op de een of andere manier aan hem worden gekoppeld), en om te kunnen spreken over een correcte berekening van effectiviteit, moet het resultaat ook aan de tijd worden gekoppeld.
Laten we een systeem bekijken waarvan de levensvatbaarheid door de tester wordt gewaarborgd. Zo'n systeem is een project waarvan de teamleden een tester omvatten. De levenscyclus van een project kan grofweg worden voorgesteld via het volgende algoritme:
- Werken met vereisten
- Opstellen van de technische specificatie
- Ontwikkeling
- Testen
- Uitbrengen in productie
- Ondersteuning (ga naar p.1)
Het project kan bovendien recursief worden onderverdeeld in subprocessen (features), met dezelfde levenscyclus.
Vanuit het perspectief van het project, is de effectiviteit van de uitvoering ervan groter naarmate er minder tijd aan wordt besteed.
Daarom komen we tot de definitie van de maximaal mogelijke effectiviteit van de tester vanuit het perspectief van het project — dit is een staat van het project waarbij de tijd voor testwerk gelijk is aan nul. Een gemeenschappelijk probleem voor alle testers is dat het onmogelijk is om deze tijd te bereiken.
Hoe gaan we hiermee om?
De conclusies zijn vrij voor de hand liggend en worden door velen al lang gebruikt:
- Ontwikkeling en testen moeten vrijwel gelijktijdig beginnen en eindigen (dit wordt meestal gedaan door de afdeling ). Ideaal is wanneer alle ontwikkelde functionaliteit op het moment van gereedheid al is gedekt door geautomatiseerde tests, georganiseerd in regressietests (en indien mogelijk in pre-commit tests) met behulp van een of andere .
- Naarmate er meer features in het project zijn (hoe complexer het is), moet er meer tijd worden besteed aan het controleren of de nieuwe functionaliteit de oude niet heeft beschadigd. Dus hoe complexer het project, hoe meer automatisering nodig is voor .
- Elke keer dat we een bug in productie doorlaten en een gebruiker deze vindt, moeten we extra tijd besteden aan het doorlopen van de levenscyclus van het project, beginnend bij punt 1 (werken met vereisten, in dit geval, van de gebruikers). Aangezien de redenen voor het doorlaten van een bug in het algemeen onbekend zijn, blijft er maar één pad voor optimalisatie over — elke bug die door gebruikers wordt gevonden, moet worden opgenomen in de regressietests, zodat we zeker weten dat deze niet opnieuw verschijnt.
Bron: habr.com
