Introductie
Goedemiddag, inwoners van Khabrovsk. Zojuist was ik een testtaak aan het oplossen voor een QA Lead vacature voor een fintech bedrijf. De eerste taak, het maken van een testplan met een volledige checklist en voorbeelden van testgevallen voor het testen van een waterkoker, kan triviaal worden opgelost:
Het is moeilijk om een beter testplan te bedenken met een volledige checklist.
Maar het tweede deel bleek een vraag te zijn: “Zijn er problemen die alle testers gemeen hebben en die hen ervan weerhouden efficiënter te werken?”
Het eerste dat in me opkwam, was het opsommen van alle min of meer opvallende problemen die ik tijdens het testen tegenkwam, de kleine dingen eruit halen en de rest samenvatten. Maar ik besefte al snel dat de inductieve methode een vraag zou beantwoorden die niet op ‘alle’ van toepassing was, maar op zijn best alleen op ‘de meerderheid’ van de testers. Daarom besloot ik het vanaf de andere kant te benaderen, deductief, en dit is wat er gebeurde.
definiëren
Het eerste wat ik gewoonlijk doe als ik een nieuw probleem oplos, is proberen te begrijpen waar het allemaal om draait, en om dit te doen moet ik de betekenis begrijpen van de woorden die het probleem vormen. De sleutelwoorden om te begrijpen zijn de volgende:
- проблема
- tester
- tester baan
- efficiëntie van testers
Laten we naar Wikipedia en gezond verstand gaan:
(oudgrieks πρόβλημα) in brede zin - een complexe theoretische of praktische kwestie die studie en oplossing vereist; in de wetenschap - een tegenstrijdige situatie die verschijnt in de vorm van tegengestelde standpunten bij de verklaring van verschijnselen, objecten, processen en die een adequate theorie vereist om deze op te lossen; in het leven wordt het probleem geformuleerd in een vorm die voor mensen begrijpelijk is: "Ik weet wat, ik weet niet hoe", dat wil zeggen, het is bekend wat er moet worden verkregen, maar het is niet bekend hoe het moet worden gedaan . Komt van laat. lat. probleem, uit het Grieks. πρόβλημα “naar voren gegooid, vooraan geplaatst”; van προβάλλω “naar voren gooien, voor je zetten; schuld".
Het heeft eigenlijk niet veel zin: ‘probleem’ = ‘alles dat moet worden aangepakt’.
- een specialist (we zullen niet in typen indelen, omdat we geïnteresseerd zijn in alle testers) die deelneemt aan het testen van een component of systeem, met als resultaat:
— een reeks activiteiten met betrekking tot testen.
(lat. effectivus) - de relatie tussen het behaalde resultaat en de gebruikte middelen (: 2015).
- een gevolg van een keten (reeks) van acties (resultaat) of gebeurtenissen, kwalitatief of kwantitatief uitgedrukt. Mogelijke uitkomsten zijn voordeel, nadeel, winst, verlies, waarde en overwinning.
Net als bij het ‘probleem’ heeft het weinig betekenis: iets dat naar voren is gekomen als gevolg van werk.
- de kwantitatief meetbare mogelijkheid om welke activiteit dan ook van een persoon of mensen uit te voeren; voorwaarden die het mogelijk maken bepaalde transformaties te gebruiken om het gewenste resultaat te verkrijgen. De tester is een persoon, en in overeenstemming met de theorie van vitale hulpbronnen is elke persoon de eigenaar van vier economische activa:
contant geld (inkomen) is een hernieuwbare hulpbron;
energie (levenskracht) is een gedeeltelijk hernieuwbare hulpbron;
tijd is een vaste en fundamenteel niet-hernieuwbare hulpbron;
kennis (informatie) is een hernieuwbare hulpbron, het maakt deel uit van het menselijk kapitaal dat kan groeien en vernietigd kan worden.
Ik zou willen opmerken dat de definitie van efficiëntie in ons geval niet helemaal correct is, aangezien hoe meer kennis we gebruiken, hoe lager de efficiëntie. Daarom zou ik efficiëntie opnieuw definiëren als ‘de verhouding tussen de bereikte resultaten en de bestede middelen’. Dan klopt alles: kennis wordt niet verspild tijdens het werk, maar het verlaagt de kosten van de enige fundamenteel niet-hernieuwbare hulpbron van de tester: zijn tijd.
beslissing
We zijn dus op zoek naar mondiale problemen van testers die de effectiviteit van hun werk belemmeren.
De belangrijkste hulpbron die aan het werk van een tester wordt besteed, is zijn tijd (de rest kan er op de een of andere manier toe worden teruggebracht), en om te kunnen praten over de juiste berekening van efficiëntie, moet het resultaat ook worden teruggebracht tot tijd .
Om dit te doen, moet u een systeem overwegen waarvan de tester de levensvatbaarheid door zijn werk garandeert. Zo'n systeem is een project waarvan het team ook een tester omvat. De projectlevenscyclus kan grofweg worden weergegeven door het volgende algoritme:
- Werken met vereisten
- Vorming van technische specificaties
- ontwerp
- Testen
- Vrijgeven in productie
- Ondersteuning (ga naar item 1)
In dit geval kan het gehele project recursief worden opgedeeld in deelprojecten (features), met dezelfde levenscyclus.
Vanuit het oogpunt van het project geldt: hoe minder tijd eraan wordt besteed, hoe effectiever de implementatie ervan is.
Zo komen we tot de definitie van de maximaal mogelijke efficiëntie van een tester vanuit het perspectief van het project - dit is de toestand van het project wanneer de testtijd nul is. Een veel voorkomend probleem voor alle testers is het onvermogen om deze tijd te bereiken.
Hoe ermee om te gaan?
De conclusies liggen voor de hand en worden al lange tijd door velen gebruikt:
- Ontwikkeling en testen moeten vrijwel gelijktijdig beginnen en eindigen (dit gebeurt meestal door de afdeling). ). De ideale optie is wanneer alle functionaliteit die wordt ontwikkeld al wordt gedekt door autotests tegen de tijd dat deze klaar is, georganiseerd in regressietesten (en, indien mogelijk, pre-committests) met behulp van een soort van .
- Hoe meer functies een project heeft (hoe complexer het is), des te meer tijd zal moeten worden besteed aan het controleren of de nieuwe functionaliteit de oude niet verbreekt. Hoe complexer het project, hoe meer automatisering er dus nodig is .
- Elke keer dat we een bug in de productie missen 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 gebruikers). Omdat de redenen voor het missen van een bug over het algemeen onbekend zijn, blijft er slechts één optimalisatiepad over: elke bug die door gebruikers wordt gevonden, moet worden opgenomen in regressietests om er zeker van te zijn dat deze niet opnieuw zal verschijnen.
Bron: www.habr.com