Is het redelijk om van een tester te verwachten dat hij een programma niet alleen evalueert op bugs, maar ook evalueert of het al dan niet goed aansluit bij de zakelijke behoeften? Zo nee, suggesties voor wat ik zoek?

Zeker is het redelijk. Maar ik zie een paar obstakels:

• Je beschrijft deze persoon als een "tester". De meeste testers testen gewoon. Een professionele QA Engineer kan echter worden betrokken bij alle aspecten van de ontwikkelingscyclus - van het herzien en verduidelijken van de vereisten tot het testen van iteraties van ontwikkelingswerk, tot het testen van het definitieve systeem, het afhandelen van een bètaperiode en zelfs het doorlopende testen in productie.
• U lijkt te anticiperen op een watervalbenadering waarbij een voltooid project of een voltooide cyclus wordt overgedragen aan deze tester voor een laatste controle net voordat u naar de productie gaat. Dat is mogelijk, maar het is ook extreem laat in het proces om te valideren tegen vereisten. Hoeveel moeite wilt u weggooien als uw ontwikkelaars onduidelijk waren over de zakelijke vereisten en de verkeerde oplossing ontwikkelden?
• U vermeldt dat "alles begint bij de eigenaar" en het is allemaal "zijn geesteskind". Misschien betekent dat ook dat er niets wordt opgeschreven? Als u verwacht dat deze tester zowel de vereisten als de eigenaar begrijpt, dan moeten de twee veel tijd samen doorbrengen, of een ander effectief mechanisme vinden om kennis van de vereisten over te dragen.
• Testers kunnen niet duur zijn. QA Engineers met diepgaande domeinkennis en vaardigheden zijn veel duurder.
• Elk bedrijf waar ik ooit heb gewerkt, definieert "agile ontwikkeling" anders. Zorg ervoor dat die van jou heel goed gedefinieerd is voordat je deze probeert te veranderen door een tester in het proces te plaatsen.

Mijn advies zou zijn om eerst een aannemer of twee in te huren om erachter te komen wat een tester eigenlijk kan voor jou doen. Het kan zijn dat u er verschillende moet doorlopen om de rol, verwachtingen en tijd die binnen uw ontwikkelingscycli is toegewezen, duidelijk te maken.

Het klinkt alsof je op zoek bent naar zowel een QA / Tester-rol als een producteigenaar / BA

Eén persoon kan je een deel van de weg daarheen helpen, maar ik betwijfel of het helemaal zal zijn wat je zoekt.

Een goede tester zal verrassende manieren bedenken om het systeem te doorbreken; dingen die geen normaal mens zou verzinnen. Ze kunnen een vlag hijsen als ze iets zien dat niet ideaal is voor het bedrijf.

Een goede PO / BA kan de bedrijfsprocessen omzetten in bruikbare vereisten voor het ontwikkelingsteam. Dat gezegd hebbende, testen ze het systeem meestal op problemen voordat ze zich afmelden.

Ik ben een tester. Uw vragen zijn legitiem. Uw vragen vormen de kern van mijn dagelijkse activiteiten.

1

Ja, elke competente QA-analist moet MOET de behoefte aan het product om te bestaan. Om te kunnen testen, moet ze ook begrijpen, in ieder geval op een hoog niveau, niet per se in details over de implementatie, HOE uw product zijn doel bereikt. Om dat te doen, kan ze een overvloed aan methoden gebruiken die deel uitmaken van haar vak. Ze kan gebruikerstypen profileren, use cases bouwen, scenario's testen, testcases afleiden uit blootgestelde functionaliteit, regressies automatiseren, enz. Maar dat is haar taak, niet die van jou.

Bovendien moet een QA-analist ook begrijpen wie de belanghebbenden van een product zijn en wat hun behoeften zijn. De eindgebruiker is niet altijd de enige gebruiker van een product. Een Project Manager zal andere wensen hebben dan een QA-persoon dan bijvoorbeeld de Front End developer. Een goede tester weet dit en bereidt procedures en artefacten voor om aan de meeste behoeften van de belangrijkste productbelanghebbenden te voldoen.

Ondanks wat generalistische benaderingen zoals ISTQB mensen leren, bouwen testers niet alleen testcases en voeren ze ze uit als gedachteloos automaten. We moeten samenwerken met verschillende teams om testomgevingen op te zetten, bedrijfslogica te begrijpen, gebruiksgegevens te verzamelen, monitoringprocessen op te zetten, risicogebaseerde analyses op ons te testen product op te bouwen, resultaten te verspreiden, feedback te verzamelen over onze acties, artefacten te archiveren en bewaar ze voor later gebruik.

2 Niet doen. Neem geen persoon in dienst uitsluitend op basis van hun vermeende technische eigenschappen of ervaring in uw branche. Uw beoordeling van haar testvaardigheden zal hoogstwaarschijnlijk gebrekkig zijn, aangezien u blijkbaar geen ervaring heeft met het evalueren van de competentie van een tester. Bovendien is domeinkennis geen kennis van testen, tenzij je iemand vindt die precies heeft gedaan wat je nodig hebt voor een ander bedrijf. En zelfs dan past die persoon misschien niet bij uw team. In plaats daarvan stel ik voor dat u een bekwame tester inhuurt die bereid is het vak van uw bedrijf te leren, ik kan hier alleen mijn eigen persoonlijke ervaring bieden. Ik ging van het testen van op Java gebaseerde games op telefoons, het testen van webhosting-verkoopsites, het testen van bluetooth-apparaten in auto's, het doen van beveiligingsaudits voor exotische besturingssystemen, het testen van de bluetooth-stack op Android Intel-telefoons, het testen van back-up- en herstelsystemen voor een enorme hosting bedrijf, het testen van de sorteermachine voor verse groenten en tot slot het testen van veilige routers. Testen is voor mij testen, het maakt gebruik van dezelfde mentale vermogens in elk bedrijf waar ik voor werkte. Technische vaardigheden kunnen worden aangeleerd, omgevingen kunnen worden gebouwd, kennis kan worden verzameld en benut, maar het nieuwsgierige en kritische denken dat nodig is om problemen te vinden, blijft overal hetzelfde.

3 IMO het probleem hier is uw vermeende gebrek aan competentie bij het evalueren van wat een "goede" tester zou zijn. Ik kan je hier geen advies geven, je perceptie is die van jou. Als ik jou was, zou ik proberen een tester te vinden die goed bij je team past, die enige domeinkennis heeft en bereid is om je vak te leren.

Het klinkt alsof de eigenaar een bijna-kloon van zichzelf wil om dit werk te doen. Ik betwijfel of de eigenaar zichzelf zou omschrijven als een tester. U bent dus echt op zoek naar iets dat verder gaat dan waarvoor een tester normaal gesproken verantwoordelijk zou zijn.

Een risico voor het bedrijf is dat alle waardevolle bedrijfskennis en -strategie in één persoon is geconcentreerd: de eigenaar. Dit is duidelijk niet ongebruikelijk in een klein bedrijfsscenario, maar door één persoon aan te nemen en op te leiden om deze rol te vervullen, draagt ​​u in wezen dat risico over en concentreert u het.

1. Is het "normaal" (ik weet het, gevaarlijke kwalificatie) om van een tester te verwachten dat hij ook de onderliggende zakelijke behoeften begrijpt, en daarom niet alleen de resultaten van de code op bugs test, maar test ook hoe geschikt de algemene resultaten zijn voor ons bedrijf?

Dit is niet normaal of wordt niet verwacht voor een "tester" -rol. Traditioneel vergelijkt een tester het werkelijke resultaat van gedrag met het verwachte resultaat zoals gedefinieerd in een bedrijfsvereiste of de acceptatiecriteria van een gebruikersverhaal.

Hierbij raadpleegt de tester materiedeskundigen van de technische en zakelijke kanten van de organisatie. Een goede tester kan, na enige tijd bij de organisatie, meer te weten komen over het product en de branche en hoeft minder vaak met experts te overleggen. Dit vereist echter toewijding en tijd, en is geen gegarandeerd resultaat.

2. Ik vraag me af of ik misschien gewoon moet adverteren voor een QA / tester job, maar specifiek screenen op kandidaten met ervaring in onze branche, of die aantonen dat ze meer kunnen dan alleen een testscript volgen?

Alles wat u wenselijk vindt in een kandidaat, moet in de functieomschrijving worden vermeld. Hoe specifieker u kunt zijn over wat u zoekt, hoe hoger de kwaliteit van de kandidaten die u zult vinden. Er zullen altijd kandidaten zijn die de functiebeschrijving niet lezen, maar het kan zijn dat sollicitanten zelf zullen selecteren op basis van wat u nodig heeft, en zich dichter bij wat u hoopt te vinden presenteren.

3. Het komt bij me op dat ik het slachtoffer zou kunnen worden van het XY-probleem, en wat we nodig hebben is iets heel anders dan waar mij om werd gevraagd. We hebben geen officiële "Product Owner". Dat is zo ongeveer wat de ondernemer heeft gedaan. Misschien hebben we er een nodig en een tester? Of misschien een ander proces?

Ja, ik denk dat dit perfect is - het klinkt alsof de definitie van de eigenaar van Tester anders is dan die van de branche. Om het risico voor één persoon dat ik hierboven noemde te verkleinen, wil je dit op teambasis aanpakken.

Huur iemand in die het praktische werk van testen kan doen, maar verspreid de kennis en kunde van de eigenaar over het hele team.

Is het "normaal" (ik weet het, gevaarlijke kwalificatie) om van een tester te verwachten dat hij ook de onderliggende zakelijke behoeften begrijpt, en daarom niet alleen de resultaten van de code op bugs test, maar ook hoe geschikt de algemene resultaten zijn voor ons bedrijf?

Tot op zekere hoogte - ja. Wat is tenslotte een bug? Wanneer de software niet de juiste / bedoelde / verwachte resultaten oplevert. Wat is in elk geval het juiste resultaat? Om daarop te antwoorden is domeinkennis vereist.

Er zijn natuurlijk grenzen aan die verwachting. Als software bijvoorbeeld in de financiële sector moet worden gebruikt en van uw testers wordt verwacht dat ze alle vaardigheden en kwalificaties hebben die nodig zijn om de wet- en regelgeving op het gebied van financiën te kennen - waarom zijn het überhaupt testers, op 1 / 10e van het inkomen? ze zouden kunnen zijn als ze gewoon in de financiële wereld werkten? In dat geval moet je accepteren dat je testers niet alles kunnen en willen dekken, of je hebt iemand nodig met de relevante kwalificaties die bereid is om te testen (en dienovereenkomstig te betalen).

Ik vraag me af of ik misschien gewoon moet adverteren voor een QA / tester-baan, maar specifiek moet screenen op kandidaten met ervaring in onze branche, of die aantonen dat ze meer kunnen dan alleen een testscript volgen?

Het klinkt alsof je een ervaren senior tester nodig hebt - zeker met meer vaardigheden dan "alleen maar een testscript volgen". Ze hebben ervaring nodig in de branche zelf, of met het verzamelen van vereisten en software-ontwerp.

Over een filosofische kanttekening: ik geloof dat testers die "gewoon een testscript volgen" over een paar jaar niet meer zullen bestaan. Een "testscript" is slechts een verkapte automatiseringstest; waarom iemand betalen om een ​​script handmatig te volgen als de automatiseringstest gratis, automatisch, elke nacht of na elke check-in kan worden uitgevoerd? Testers hebben ofwel domein- en / of ontwerpkennis nodig, zoals hierboven vermeld, of de mogelijkheid om automatiseringstests te schrijven (of beide).

Het komt bij me op dat ik misschien het slachtoffer word van de XY probleem, en wat we nodig hebben is iets heel anders dan waar mij om werd gevraagd.

Mogelijk. Misschien heb je een Product Owner / Business Analist / iets anders nodig, nu of in de toekomst.

Van wat je beschrijft, zou een testfunctie echter nuttig kunnen zijn en een groot positief punt kunnen zijn van het bedrijf. Ik vermoed echter dat "een tester" momenteel misschien niet voldoende is om die testfunctie te vervullen. Zie het meer als een "QA Lead" - het begin van een afdeling - iemand die niet alleen bugs gaat vinden, maar de hele toekomst van QA in uw bedrijf bepaalt. Dit kan inhouden (op een bepaald moment) meer mensen inhuren om onder hen te werken, de QA-functie rechtvaardigen voor de rest van het bedrijf, inclusief de eigenaar, input hebben voor het ontwerp, een automatiseringstestsuite introduceren, enz. Ik wil iemand met ervaring en anciënniteit. Leg de situatie aan het begin van het wervingsproces aan hen uit - en probeer niet goedkoop te zijn. ;-)

Mijn antwoord verwijst naar geweldige testers en is niet van toepassing op gemiddelde testers. Ik heb meer dan 10 jaar in QA gewerkt bij 5 verschillende bedrijven (hoofdbanen en bijprojecten). Ik heb ook gewerkt aan gevestigde teams en anderen die ik vanaf nul heb moeten opbouwen.

Is het [realistisch] om van een tester te verwachten dat hij ook de onderliggende zakelijke behoeften begrijpt, en daarom niet testen alleen de resultaten van de code voor bugs, maar test ook hoe geschikt de algemene resultaten zijn voor ons bedrijf?

Ik heb "normaal" vervangen door "realistisch" omdat het minder subjectief is. Testers doen dit in veel verschillende soorten industrieën. Met videogames heb ik als tester problemen ingevoerd die ik als gebruiker niet leuk zou vinden; dus minder bugs en meer bruikbaarheid. Toen ik voor een bedrijf werkte dat voorraadtracering verzorgde, huurden ze intern testers in van de zakelijke kant. Als enige QA-persoon met eerdere ervaring, was het mijn taak om ze eraan te herinneren dat ze naar de zakelijke kant bleven kijken en ze ook hun testvaardigheden moesten laten ontwikkelen. Er zijn nog tal van andere voorbeelden.

Met de kleine omvang van het bedrijf klinkt het alsof u op zoek bent naar een ervaren QA-professional die snel leert. Mogelijk zitten ze al in de branche. De verwachting is dat ze zowel zakelijke problemen als de reguliere bugs moeten invoeren. Een ding om op te screenen is hun proces om ervoor te zorgen dat aan de zakelijke tests wordt voldaan. Onder andere zou ik een vermelding van UAT verwachten. Een uur van de tijd van de eigenaar reserveren voor een semi-begeleide walkthrough van nieuwe functies zou moeten gebeuren.

Ik vraag me af of ik misschien gewoon moet adverteren voor een QA / tester-baan, maar specifiek voor kandidaten met ervaring in onze branche ...?

U moet dit doen om de redenen die ik eerder noemde, maar u moet ook adverteren voor kandidaten met 'aanbevolen' ervaring in de branche. Tenzij het een zeer complexe branche is, zou ik er persoonlijk voor terugschrikken dat het een harde vereiste is. Ik heb veel eersteklas testers ontmoet die zonder eerdere ervaring konden binnenkomen en het oppikken. Er kan in dit geval echter een grotere leercurve zijn, met een grotere uitbetaling aan de achterkant.

... of wie demonstreren de vaardigheid om meer te doen dan alleen een testscript volgen?

Dit is een basisvereiste voor elke tester die ik wil inhuren. Zeker bij een klein bedrijf heb je veelzijdige medewerkers nodig. Geautomatiseerd testen volgt een script, dus een mens zou veel meer moeten kunnen doen.

Het komt bij me op dat ik misschien het slachtoffer word van het XY-probleem, en wat we nodig hebben is iets heel anders dan wat mij werd gevraagd. We hebben geen officiële "Product Owner". Dat is zo ongeveer wat de ondernemer heeft gedaan. Misschien hebben we er een nodig en een tester? Of misschien een ander proces?

Met de verstrekte informatie denk ik dat je een ervaren tester nodig hebt. Dat alles is onderhevig aan verandering op basis van bedrijfsfactoren. Zeer complexe en gespecialiseerde onderneming? Laag budget? Misschien huur je een PO / BA en een QA-lid in.

Om samen te vatten: is het redelijk om van een tester te verwachten dat hij niet alleen een programma evalueert op bugs, maar ook evalueert of het al dan niet een goede match is met de zakelijke behoeften? Zo nee, suggesties voor wat ik zoek?

Het is redelijk. Adverteer de positie gewoon nauwkeurig om precies te vinden wat u zoekt.