[Software Testen] Algemeen topic

[Mugwump]

Hydra schreef op woensdag 26 september 2018 @ 13:10:
En nu concreet? Want dit is wel een beetje wat overeenkomt met mijn beeld van testconsultants. Mooie 'praatplaatjes' maar als het puntje bij het paaltje komt, dus concreet de vraag hoe we nu end to end tests in gaan richten die we zowel op tegen een Android als een iOS app kunnen draaien, dan blijft het heel erg stil.

Dit is letterlijk waar we in een vorig project tegenaan liepen bij een aangenomen consultant. We hebben iemand nodig die met z'n voeten in de klei staat en zo iets op kan zetten. Niet iemand die aan de hand van wat boekjes een powerpoint kan maken; dat kan ik zelf ook wel.

Als je wil dat een dev team echt een schurfthekel aan je krijgt is tegen hun manager klagen dat "team nog niet in staat zijn een handmatig script op te leveren" zonder zelf concreet stappen te gaan maken hierin. Want negen van de tien keer is het het management die pushed op features, niet de devs die niet willen.

In mijn huidige project zijn inmiddels al drie testers versleten die allemaal automatisch testen zouden implementeren. Elke keer kwam er na behoorlijke tijd enkel een Worddocument uit met wat diagrammen uit. Ik heb uiteindelijk zelf maar weer de hele boel opgezet met een BDD opzet en stuur de testers wel weer aan op dit vlak in plaats van vice versa.
Ik heb met een aantal goede test automation engineers gewerkt, maar veelal zijn het toch documentproducenten.

[NielsTn]

Mugwump schreef op woensdag 26 september 2018 @ 14:02:
[...]


In mijn huidige project zijn inmiddels al drie testers versleten die allemaal automatisch testen zouden implementeren. Elke keer kwam er na behoorlijke tijd enkel een Worddocument uit met wat diagrammen uit. Ik heb uiteindelijk zelf maar weer de hele boel opgezet met een BDD opzet en stuur de testers wel weer aan op dit vlak in plaats van vice versa.
Ik heb met een aantal goede test automation engineers gewerkt, maar veelal zijn het toch documentproducenten.

Als BDD werkt voor jullie prima toch? Al vraag ik mij af hoe je bv. API's wilt testen met BDD. BDD is van oorsprong ontstaan om leesbare documentatie te bouwen voor de business, aangevuld met code voor ontwikkelaars toch?

Tegenwoordig zijn er in het oerwoud van tools vele oplossingen mogelijk... keuzes maken is lastig. Trainen en opleiden van verantwoordelijke engineers wordt ook zo makkelijk overgeslagen.

[Barbas]

In mijn ervaring zijn het ook twee aparte takken van sport. Testautomatisering staat in mijn ogen gelijk aan ontwikkeling. Het geautomatiseerde zou moeten voldoen aan de SOLID principes. Eigenlijk dus een ontwikkelaar die testen ook begrijpt, of een tester die ook goed kan programmeren.

Naar mijn mening zou je middels unit en integratietesten de logica geautomatiseerd willen testen. Die zijn het snelst uit te voeren en staan het dichtst bij de code. Via UI automatiseren heeft niet de voorkeur, tenzij het echt niet anders kan.

Een tester, zoals ik, moet je niet neerzetten op een automatiseringsklus. Mijn kracht ligt in het exploreren en onderzoeken. Gaandeweg scenario's verzinnen. Creatief zijn, vragen stellen, kritisch zijn, volhardend, etc.

Als ik hierboven lees dat het niet van de grond komt dan klopt de intake al niet (geen match), worden de juiste vragen gesteld tijdens de intake? Of zeggen de consultants zaken te beheersen die ze niet kunnen? Volgens mij val je in het laatste geval al snel door de mand.

[TK2803]

Some background information:
Momenteel zit ik gedetacheerd als software ontwikkelaar. Hierbij heb ik naast het ontwikkelen van de tool ook de verantwoordelijkheid om de Unit testen te maken. Ik werk in een team van 9 man, bestaande uit consultants(3), Software Architect, Product Owner, project lead en Software ontwikkelaars(2). De Product Owner probeert zijn idee in samenspraak met de consultants en software architect globaal op papier te zetten. De software architect is geheel verantwoordelijk om dit duidelijk en consistent op papier te zetten voor het team (Requirements Document). Stapsgewijs wordt dit document opgesteld en middels een iterative manier zijn wij als team bezig met het ontwikkelen van een tool en het document.

On topic:
Nadat een design (op papier) goedgekeurd wordt door het team, begin ik met het opstellen van test cases voor mijn 'yet to be implemented' functionality. Dit is momenteel de way of working. Wij ontwikkelen eerst de regressie test cases, Hierbij probeer ik alle "worst case scenario's" af te dekken. Dit laat ik vervolgens valideren door de software architect. .
Indien ik een goedkeuring ontvang wat betreft de test case scenario's, begin ik met het implementeren van de functionaliteiten. Tijdens en na het ontwikkelen van iedere (publieke) functie start ik opgestelde regressie test cases, (dit is een iteratief proces). Nadat de functionaliteiten zijn geimplementeerd wordt er een code review uitgevoerd.
Binnen ons team werken een aantal consultants, zij zijn verantwoordelijk voor de acceptance testen. Deze acceptance testen zijn voornamelijk voor de leesbaarheid van de (error) messages en 'look en feel' van de tooling.

Dit ons ongeveer onze way of working binnen het team.

Off topic:
Niet iedereen binnen ons team werkt aan de tooling, er lopen natuurlijk ook nog andere projecten.

[ Voor 4% gewijzigd door TK2803 op 26-09-2018 14:21 . Reden: minor updates ]

[NielsTn]

Barbas schreef op woensdag 26 september 2018 @ 14:14:
In mijn ervaring zijn het ook twee aparte takken van sport. Testautomatisering staat in mijn ogen gelijk aan ontwikkeling. Het geautomatiseerde zou moeten voldoen aan de SOLID principes. Eigenlijk dus een ontwikkelaar die testen ook begrijpt, of een tester die ook goed kan programmeren.

Naar mijn mening zou je middels unit en integratietesten de logica geautomatiseerd willen testen. Die zijn het snelst uit te voeren en staan het dichtst bij de code. Via UI automatiseren heeft niet de voorkeur, tenzij het echt niet anders kan.

Een tester, zoals ik, moet je niet neerzetten op een automatiseringsklus. Mijn kracht ligt in het exploreren en onderzoeken. Gaandeweg scenario's verzinnen. Creatief zijn, vragen stellen, kritisch zijn, volhardend, etc.

Als ik hierboven lees dat het niet van de grond komt dan klopt de intake al niet (geen match), worden de juiste vragen gesteld tijdens de intake? Of zeggen de consultants zaken te beheersen die ze niet kunnen? Volgens mij val je in het laatste geval al snel door de mand.

idd SOLID is een van de items bij TAE training (en ook een relatie naar de test automation pyramid).
Anderzijds: als de klant de zaken volwassenere/rooskleuriger voorspiegelt, ook na doorvragen/doorzagen, tja dan moet je eens de 'leap of faith' wagen
Mocht eea inderdaad rooskleuriger zijn besproken: dan geef ik aan dat onze afgesproken inzet-opdracht in gevaar komt, en wat we kunnen gaan doen.

Ikzelf heb een attitude: ik beheers het als ik het naast een voorbeeld ook on-site kan demonstreren en uitleggen. Bij twijfels: dan geef ik dat ook aan en vraag door waar mogelijkheden wel/niet kunnen liggen

[Hydra]

@NielsTn Volgens mij heb je als developer niks aan boekjes; geef ze tools. Beginnen met unit testen, dat is zoals je weet de fundering van de test pyramide.

Barbas schreef op woensdag 26 september 2018 @ 14:14:
In mijn ervaring zijn het ook twee aparte takken van sport. Testautomatisering staat in mijn ogen gelijk aan ontwikkeling. Het geautomatiseerde zou moeten voldoen aan de SOLID principes. Eigenlijk dus een ontwikkelaar die testen ook begrijpt, of een tester die ook goed kan programmeren.

Naar mijn mening zou je middels unit en integratietesten de logica geautomatiseerd willen testen. Die zijn het snelst uit te voeren en staan het dichtst bij de code. Via UI automatiseren heeft niet de voorkeur, tenzij het echt niet anders kan.

Een tester, zoals ik, moet je niet neerzetten op een automatiseringsklus. Mijn kracht ligt in het exploreren en onderzoeken. Gaandeweg scenario's verzinnen. Creatief zijn, vragen stellen, kritisch zijn, volhardend, etc.

Okay. Maar dat is dan dus manual testen. Want Unit en Integration tests worden door de software engineers gemaakt. En prima dat je scenario's bedenkt; maar die moeten uiteindelijk geautomatiseerd worden. Keer op keer handmatig door scenario's heenlopen gaat uiteindelijk altijd fout. Mensen zijn daar niet geschikt voor; het is veel te saai.

ik hierboven lees dat het niet van de grond komt dan klopt de intake al niet (geen match), worden de juiste vragen gesteld tijdens de intake? Of zeggen de consultants zaken te beheersen die ze niet kunnen? Volgens mij val je in het laatste geval al snel door de mand.

Dat laatste was helaas bij ons het probleem. Ik neem het mezelf ook kwalijk; ik heb hem in z'n interview letterlijk dit probleem voorgelegd (E2E testen van phone apps) en hij zij dat 'ie dat ging regelen. Zijn laatste actie was dat hij, zonder overleg met de developers, aan management een document overlegd had met een plan waarin stond dat de 'test coverage' te laag was, zijn eigenlijk de devs praktisch in opstand gekomen (test coverage was extreem hoog, gemiddeld rond de 90%). Hij zat aan de dingen die wij juist wel prima geregeld hadden, en deed niet waarvoor 'ie aangenomen was.

Diezelfde week is z'n contract opgezegd en zat 'ie nog de rest van de maand te zeuren over hoe het management hem tegen hield. Ik vermoed dat 'ie ditzelfde kunstje weer ergens anders gaat doen.

[ Voor 109% gewijzigd door Hydra op 26-09-2018 15:04 ]

[Barbas]

Hydra schreef op woensdag 26 september 2018 @ 14:52:
@NielsTn Volgens mij heb je als developer niks aan boekjes; geef ze tools. Beginnen met unit testen, dat is zoals je weet de fundering van de test pyramide.


[...]


Okay. Maar dat is dan dus manual testen. Want Unit en Integration tests worden door de software engineers gemaakt. En prima dat je scenario's bedenkt; maar die moeten uiteindelijk geautomatiseerd worden. Keer op keer handmatig door scenario's heenlopen gaat uiteindelijk altijd fout. Mensen zijn daar niet geschikt voor; het is veel te saai.


[...]


Dat laatste was helaas bij ons het probleem. Ik neem het mezelf ook kwalijk; ik heb hem in z'n interview letterlijk dit probleem voorgelegd (E2E testen van phone apps) en hij zij dat 'ie dat ging regelen. Zijn laatste actie was dat hij, zonder overleg met de developers, aan management een document overlegd had met een plan waarin stond dat de 'test coverage' te laag was, zijn eigenlijk de devs praktisch in opstand gekomen (test coverage was extreem hoog, gemiddeld rond de 90%). Hij zat aan de dingen die wij juist wel prima geregeld hadden, en deed niet waarvoor 'ie aangenomen was.

Diezelfde week is z'n contract opgezegd en zat 'ie nog de rest van de maand te zeuren over hoe het management hem tegen hield. Ik vermoed dat 'ie ditzelfde kunstje weer ergens anders gaat doen.

Eens, keer op keer hetzelfde moet je automatiseren. Regressietesten dus. Maar ik denk dat je niet wegkomt zonder handmatig getest te hebben. Er zijn altijd aspecten die je moet zien of moet ervaren, denk ik, om er een oordeel over te kunnen vellen.

Maar exploratory testing is overigens niet telkens dezelfde scenario's herhalen. Bij exploratory testing ga je telkens nieuwe gebieden verkennen. Iets meer context.

Dat is wel balen! Gewoon een rotte appel dus. Tijdens intakes kan je om concrete praktijkvoorbeelden vragen. Leg het maar uit of laat het maar zien. Of dmv een casus bijvoorbeeld. Snap ook niet dat een consultant zich anders voordoet. Daar bereik je uiteindelijk niks mee en wordt je dood ongelukkig van. Ik tenminste wel. Je wilt juist meerwaarde bieden aan een vraagstuk/probleemsituatie bij een klant.

[NielsTn]

Ik zou idd manueel testen met bv aanpakken zoals RST, gezond verstand etc.

voor integratietesten, ook daar wil ik mijn ding in doen, dus ik houd de developers verantwoordelijk voor unit testen schrijven/onderhouden.

[Mugwump]

NielsTn schreef op woensdag 26 september 2018 @ 14:13:
[...]


Als BDD werkt voor jullie prima toch? Al vraag ik mij af hoe je bv. API's wilt testen met BDD. BDD is van oorsprong ontstaan om leesbare documentatie te bouwen voor de business, aangevuld met code voor ontwikkelaars toch?

Tegenwoordig zijn er in het oerwoud van tools vele oplossingen mogelijk... keuzes maken is lastig. Trainen en opleiden van verantwoordelijke engineers wordt ook zo makkelijk overgeslagen.

Je kunt met BDD prima API's testen. Sterker nog, dat doe ik ook heel vaak. In de basis heb je unit tests die snel uit te voeren zijn, werken zonder enige vorm van deployment en zonder afhankelijkheid van externe data(sources). Daarin test je vaak allerhande invariants in je domein zoals bijvoorbeeld 'er kan geen geld van een rekening worden afgeschreven indien daardoor het saldo onder nul komt'.
Veelal heb ik dan ook integratietests draaien waarbij de hele applicatie opgespind wordt. Dat is vaak op basis van scenario's in BDD formaat die weer afgeleiden zijn van de opgestelde requirements. Je hebt precondities die het systeem in een bepaalde staat brengen (dat kan via API calls, maar ook rechtstreeks in databronnen indien dat vanwege performance wenselijk is), stappen die je uitvoert (API calls) en postcondities (ook weer het opvragen van staat via API calls of desnoods rechtstreeks in een database.
De hele connectie tussen 'stappen' in je scenario's en de daadwerkelijk uitgevoerde handelingen (API calls, database loads / queries) bepaal je daarin zelf.

[TheNephilim]

Leuk om dit allemaal te lezen, geeft mij ook weer een beetje inzicht in hoe iets zou moeten/kunnen werken!

Wij missen op dit moment vooral de stappen die vooraf genomen moeten worden. Bijv. het goed op papier zetten van features en dergelijke. Simpel gezegd wordt er pas bij het maken van een feature nagedacht over het testen. Dus als ik (simpel voorbeeld) een winkelmandje in elkaar moet zetten, dan weet ik dat je producten moet kunnen toevoegen aan het winkelmandje. Dan begin ik met het schrijven van een feature test die bewijst dat je, na het maken van een POST request naar de cart endpoint, een product in je winkelmandje hebt. Daarna ga ik pas de feature daadwerkelijk ontwikkelen om zo de test op groen te krijgen.

[Hydra]

NielsTn schreef op woensdag 26 september 2018 @ 15:33:
voor integratietesten, ook daar wil ik mijn ding in doen, dus ik houd de developers verantwoordelijk voor unit testen schrijven/onderhouden.

Je bent gewoon een teamlid. Je bent niet hun manager.

Sorry voor de ietwat allergische reactie maar ik heb nogal veel ervaring met "test managers" van o.a. Cap Gemini.

Mugwump schreef op woensdag 26 september 2018 @ 15:53:
Je kunt met BDD prima API's testen.

Kan. In twee vorige projecten ook BDD frameworks gebruikt zien worden. Uiteindelijk is het vaak overkill; het zijn toch niet de gebruikers of PO's die die scenario's schrijven in mijn ervaring, dus komt het bij de devs terecht, dus kun je het net zo goed met een test framework + iets als rest assured doen.

Ben dus niet zo'n fan van de omslachtige manier van werken met vaak erg veel code om gewoon een paar REST API's te testen.

[ Voor 40% gewijzigd door Hydra op 27-09-2018 00:16 ]

[Mugwump]

Hydra schreef op donderdag 27 september 2018 @ 00:14:

[...]


Kan. In twee vorige projecten ook BDD frameworks gebruikt zien worden. Uiteindelijk is het vaak overkill; het zijn toch niet de gebruikers of PO's die die scenario's schrijven in mijn ervaring, dus komt het bij de devs terecht, dus kun je het net zo goed met een test framework + iets als rest assured doen.

Ben dus niet zo'n fan van de omslachtige manier van werken met vaak erg veel code om gewoon een paar REST API's te testen.

Ik zou het ook zeker niet 'een paar REST APIs testen' willen noemen. Je test allerhande functionele scenario's en daarmee de werking van je systeem. Het maakt rigoreuze refactoring van de interne werking van je systeem mogelijk. Dat hoeft niet per se via BDD, maar heel veel extra werk voegt het niet toe aangezien je gewoon herbruikbare stappen produceert. Of je nou 'gewone unit tests' of bdd scenarios schrijft, de code voor de API aanroepen en dergelijke moet je toch schrijven, tenzij je tooling gebruikt, maar dan zou ik gewoon weer eens kijken of je daar een tester voor kunt aanhaken.
Belangrijk voordeel is dat het ook automatisch een vorm van documentatie oplevert. Je krijgt een rapportage ingedeeld naar feature met allerhande taggingmogelijkheden waarin het gedrag van je systeem beschreven staat.
Vooral dat laatste mis je wel als je met iets als REST-assured werkt. Daarmee test je toch vooral de werking van specifieke REST calls en veel minder het gedrag van je systeem, waardoor je de tests ook geen documentatie op dat niveau kunt laten genereren.

[rvankruistum]

Mijn duit in het testautomatiserings-zakje (gebaseerd op 4 a 5 jaar ervaring met testautomatisering):

Er is steeds meer vraag naar geautomatiseerd testen, omdat bedrijven steeds vaker willen releasen en (zoals ook al eerder besproken) je geen zin hebt elke keer je regressietest handmatig uit te voeren. IT bedrijven springen natuurlijk in op die vraag, door trainingen aan te bieden en testers om te scholen naar "test engineer" (of zoiets). Als ik zo naar die ISTQB training kijk dan mis ik 1 nogal belangrijk onderdeel, namelijk "Hoe kan ik daadwerkelijk een test automatiseren". Je kan praten over welke tool het beste is, en wat je testplanning is etc. etc. Maar in de praktijk moet je vaak eerst maar gewoon wat shit gaan bouwen en kom je er vervolgens gaandeweg wel achter wat het beste werkt (agile ofzo toch?).

Het is ook best logisch dat er geen training is waar je leert automatiseren, want er zijn honderden verschillende soorten applicaties/api's/etc. die allemaal net een andere aanpak nodig hebben dus de enige manier om het echt te leren is door praktijkervaring. Als ik bij een nieuwe klant aan kom zetten en ze gebruiken bijvoorbeeld cosmosdb terwijl ik alleen maar gewend ben om met SQL te werken, dan kan ik moeilijk zeggen "ik moet eerst ff een cursusje doen". Wat ik daarom collega's die geïnteresseerd zijn in testautomatisering aanraad is om eerst een basis ontwikkelaars cursus te doen (MS 98-361 bijvoorbeeld) en vervolgens java of C# te leren.

Oh, nog 1 laatste ding over BDD: Heeft iemand al een keer meegemaakt dat een bedrijf daadwerkelijk BDD doet zoals het bedoeld is? Ik doe alweer een tijdje specflow impleteren voor bedrijven, maar in de praktijk schrijf ik de scenario's vaak zelf, waardoor het eigenlijk niet meer dan een fancy schilletje om de daadwerkelijke testcode is. Het voelt voor mij als een beetje een buzzwordy ding wat in theorie heel mooi lijkt, maar in de praktijk nooit echt van de grond komt. Benieuwd of andere mensen hier ervaring mee hebben.

[Smuggler]

rvankruistum schreef op donderdag 27 september 2018 @ 09:17:
Oh, nog 1 laatste ding over BDD: Heeft iemand al een keer meegemaakt dat een bedrijf daadwerkelijk BDD doet zoals het bedoeld is? Ik doe alweer een tijdje specflow impleteren voor bedrijven, maar in de praktijk schrijf ik de scenario's vaak zelf, waardoor het eigenlijk niet meer dan een fancy schilletje om de daadwerkelijke testcode is. Het voelt voor mij als een beetje een buzzwordy ding wat in theorie heel mooi lijkt, maar in de praktijk nooit echt van de grond komt. Benieuwd of andere mensen hier ervaring mee hebben.

Ja ik heb bij een bedrijf gezetten waar we dit zeker deden:
PO maakte de requirements,
Tester schreef dit om naar gherkin scenario's,
Dit werd gereviewed door de PO en de test automation engineer. (PO op correctheid, de test engineer toetst of het goed implementeerbaar is).
Test Automation engineer automatiseert de testen in overleg met de developers (je hebt soms wat API calls of inputs nodig). En de software engineers schrijft daar zijn software tegenaan.
Meestal worden de testen en de software tegelijk opgeleverd, soms de software een week eerder, de andere keer weer de testen een week eerder.
dat lag er maar net aan waar de complexiteit zat.

[Mugwump]

rvankruistum schreef op donderdag 27 september 2018 @ 09:17:
Mijn duit in het testautomatiserings-zakje (gebaseerd op 4 a 5 jaar ervaring met testautomatisering):

Er is steeds meer vraag naar geautomatiseerd testen, omdat bedrijven steeds vaker willen releasen en (zoals ook al eerder besproken) je geen zin hebt elke keer je regressietest handmatig uit te voeren. IT bedrijven springen natuurlijk in op die vraag, door trainingen aan te bieden en testers om te scholen naar "test engineer" (of zoiets). Als ik zo naar die ISTQB training kijk dan mis ik 1 nogal belangrijk onderdeel, namelijk "Hoe kan ik daadwerkelijk een test automatiseren". Je kan praten over welke tool het beste is, en wat je testplanning is etc. etc. Maar in de praktijk moet je vaak eerst maar gewoon wat shit gaan bouwen en kom je er vervolgens gaandeweg wel achter wat het beste werkt (agile ofzo toch?).

Het is ook best logisch dat er geen training is waar je leert automatiseren, want er zijn honderden verschillende soorten applicaties/api's/etc. die allemaal net een andere aanpak nodig hebben dus de enige manier om het echt te leren is door praktijkervaring. Als ik bij een nieuwe klant aan kom zetten en ze gebruiken bijvoorbeeld cosmosdb terwijl ik alleen maar gewend ben om met SQL te werken, dan kan ik moeilijk zeggen "ik moet eerst ff een cursusje doen". Wat ik daarom collega's die geïnteresseerd zijn in testautomatisering aanraad is om eerst een basis ontwikkelaars cursus te doen (MS 98-361 bijvoorbeeld) en vervolgens java of C# te leren.

Inderdaad, je moet als developer tegenwoordig veelal zo flexibel als een elastiekje zijn als het op concrete technologieën aankomt, dus helaas moet je dat vervolgens als 'test automation engineer' dan ook zijn. Al spelen daarin in mijn ogen developers ook gewoon een rol. Je hoeft een tester ook niet per se in Cosmos te laten wroeten. Sterker nog, ik heb ze vaak liever niet in een data store. Hoe meer je ze in de interne werking van je software laat wroeten, hoe groter de kans dat een hele testsuite omvalt bij refactoring omdat die op de 'inner workings' van je software gebaseerd zijn.

Oh, nog 1 laatste ding over BDD: Heeft iemand al een keer meegemaakt dat een bedrijf daadwerkelijk BDD doet zoals het bedoeld is? Ik doe alweer een tijdje specflow impleteren voor bedrijven, maar in de praktijk schrijf ik de scenario's vaak zelf, waardoor het eigenlijk niet meer dan een fancy schilletje om de daadwerkelijke testcode is. Het voelt voor mij als een beetje een buzzwordy ding wat in theorie heel mooi lijkt, maar in de praktijk nooit echt van de grond komt. Benieuwd of andere mensen hier ervaring mee hebben.

De ideale situatie omtrent BDD zie je inderdaad niet heel vaak, maar zelfs in de 'ik doe het zelf'-situatie zie ik nog wel een aantal voordelen. Automatische rapportage over testcases in leesbaar formaat is een duidelijk voordeel. Ik kwam op een gegeven moment op een project waarbij echt een leverancier-klant relatie was en alle change requests werden verantwoord door echt letterlijk handmatig te testen en in Word beschrijvingen van stappen die werden uitgevoerd, screenshots van databases en meer van die ongein. Dan heb je dus geen regressie en het is enorm arbeidsintensief. Dan geef ik echt de voorkeur aan BDD scenario's schrijven.
Ik heb ook wel situaties gehad waar ze denken dat ze 3 lagen vertalers tussen business en developers moesten stoppen. In de praktijk leidde dat gewoon tot een totaal vertekend beeld van wat er moest gebeuren. Uiteindelijk ben ik zelf maar eens om tafel gegaan met de verantwoordelijke procesmanager (betrof wat financiële / administratieve processen). Op basis daarvan heb ik de scenario's opgesteld in voor hem begrijpelijke taal en dat als uitgangspunt gehanteerd voor conversatie omtrent de software. Dat was echt cruciaal voor het acceptabel werkend krijgen van het systeem.

[Hydra]

Mugwump schreef op donderdag 27 september 2018 @ 08:52:
Ik zou het ook zeker niet 'een paar REST APIs testen' willen noemen. Je test allerhande functionele scenario's en daarmee de werking van je systeem. Het maakt rigoreuze refactoring van de interne werking van je systeem mogelijk. Dat hoeft niet per se via BDD, maar heel veel extra werk voegt het niet toe aangezien je gewoon herbruikbare stappen produceert. Of je nou 'gewone unit tests' of bdd scenarios schrijft, de code voor de API aanroepen en dergelijke moet je toch schrijven, tenzij je tooling gebruikt, maar dan zou ik gewoon weer eens kijken of je daar een tester voor kunt aanhaken.
Belangrijk voordeel is dat het ook automatisch een vorm van documentatie oplevert. Je krijgt een rapportage ingedeeld naar feature met allerhande taggingmogelijkheden waarin het gedrag van je systeem beschreven staat.
Vooral dat laatste mis je wel als je met iets als REST-assured werkt. Daarmee test je toch vooral de werking van specifieke REST calls en veel minder het gedrag van je systeem, waardoor je de tests ook geen documentatie op dat niveau kunt laten genereren.

ALs het goed geimplementeerd wordt kan een BDD framework zeker meerwaarde bieden hoor, vooral als de scenario's ook door niet al te technische mensen gelezen of geschreven worden. Ik heb dat ook in een project geimplementeerd waar we eigenlijk vanuit de software-engineers de test inrichting overgenomen hebben van de testers. Die waren zelf met Selenium IDE zooi in elkaar aan het klikken en dat hebben we toen via een BDD framework + Selenium WebDriver overgenomen. Wat wel leuk was, was dat we dezelfde scenario's konden afspelen tegen verschillende interfaces (2 Web, 1 REST).

Mijn ervaring is alleen dat het helaas vaak gebeurt dat al deze verantwoordelijkheden gewoon bij de software engineers komen te liggen. En dan heeft functionele scenario's uitdrukken in text versus dit gewoon in code te doen niet zoveel toevoegde waarde meer.

Automatische rapportage over testcases in leesbaar formaat is een duidelijk voordeel.

Dat heb je met JUnit bijvoorbeeld ook he. Sterker nog; Cucumber bijvoorbeeld gebruikt onder water de rapportagemogelijkheden van JUnit.

Het enige wat die BDD frameworks eigenlijk toevoegen is de laag die de vertaling van die tekstuele Given-When-Then scenario's naar code toevoegt. En die heeft niet perse altijd zin.

Op basis daarvan heb ik de scenario's opgesteld in voor hem begrijpelijke taal en dat als uitgangspunt gehanteerd voor conversatie omtrent de software. Dat was echt cruciaal voor het acceptabel werkend krijgen van het systeem.

Daarvoor is een BDD framework perfect.

[ Voor 14% gewijzigd door Hydra op 27-09-2018 13:47 ]

[Mugwump]

Hydra schreef op donderdag 27 september 2018 @ 13:44:
[...]


ALs het goed geimplementeerd wordt kan een BDD framework zeker meerwaarde bieden hoor, vooral als de scenario's ook door niet al te technische mensen gelezen of geschreven worden. Ik heb dat ook in een project geimplementeerd waar we eigenlijk vanuit de software-engineers de test inrichting overgenomen hebben van de testers. Die waren zelf met Selenium IDE zooi in elkaar aan het klikken en dat hebben we toen via een BDD framework + Selenium WebDriver overgenomen. Wat wel leuk was, was dat we dezelfde scenario's konden afspelen tegen verschillende interfaces (2 Web, 1 REST).

Mijn ervaring is alleen dat het helaas vaak gebeurt dat al deze verantwoordelijkheden gewoon bij de software engineers komen te liggen. En dan heeft functionele scenario's uitdrukken in text versus dit gewoon in code te doen niet zoveel toevoegde waarde meer.

Zelfs in dat laatste geval zie ik er nog wel voordeel in. Het is een handig overzichtsmiddel dat aangeeft wat je software doet. Menig developer verzuipt nogal eens als ze geconfronteerd worden met een nieuwe codebase. Juist zo'n stuk 'functionele documentatie' helpt dan.

[...]


Dat heb je met JUnit bijvoorbeeld ook he. Sterker nog; Cucumber bijvoorbeeld gebruikt onder water de rapportagemogelijkheden van JUnit.

Het enige wat die BDD frameworks eigenlijk toevoegen is de laag die de vertaling van die tekstuele Given-When-Then scenario's naar code toevoegt. En die heeft niet perse altijd zin.

Het gaat niet om rapportage an sich, het gaat om wat er in rapportage staat. Elk fatsoenlijk testframework heeft wel op een bepaalde manier automatische documentatie / rapportage.

[Lixis]

Per 1 december start ik - na 7 jaar in het onderwijs - een traineeship als junior test consultant bij Capgemini. Waarschijnlijk ga ik in het traineeship genoeg kennis opdoen, maar ik vind het ook wel prettig voor die tijd al wat kennis/vaardigheden op te doen.

Hebben jullie tips voor online cursussen / literatuur waarmee ik me al kan gaan verdiepen in dit vakgebied? Ik ben al bezig met een cursus Java via Udemy.

[Loev]

Lixis schreef op donderdag 18 oktober 2018 @ 14:39:
Per 1 december start ik - na 7 jaar in het onderwijs - een traineeship als junior test consultant bij Capgemini. Waarschijnlijk ga ik in het traineeship genoeg kennis opdoen, maar ik vind het ook wel prettig voor die tijd al wat kennis/vaardigheden op te doen.

Hebben jullie tips voor online cursussen / literatuur waarmee ik me al kan gaan verdiepen in dit vakgebied? Ik ben al bezig met een cursus Java via Udemy.

Welkom bij de club, ik gok dat je begint met TMAP of ISTQB (of heeft Cap zijn eigen framework?) Ik weet niet hoezeer je de basis onder de knie hebt van IT. Anders kan je kijken naar HTML, SQL, XML, JSON voordat je aan de slag gaat met programmeertalen. Wel zo handig als je al een stuk basis IT kennis hebt. Ow, en Excel gebruik je toch net vaker dan je eigenlijk wil

Verder eigen automatisering kennis is vooral SoapUI incl. DDT, maar ik begin de limieten wel te merken qua sturing van de inhoud in een Soap-bericht. Vorig jaar Java cursus voor testers gevolgd, maar ik doe er te weinig mee daarom blijft het niet plakken. (te druk met functioneel testen, automatiseren schiet er dan bij in ) Ik heb een aantal Java ontwikkelaars hier op kantoor en dat scheelt enorm. Ik wil mij nu meer richten op het zelf bouwen van tests op unit niveau, heb ik even meer sturing op de data en de uitvoering is een stuk sneller. Alleen twijfel ik of de dekking hetzelfde is, een functie aanroepen in code is natuurlijk wat anders dan daadwerkelijk een Soap-call uitvoeren. Tweakers hier ervaring mee?

[ Voor 28% gewijzigd door Loev op 18-10-2018 15:05 ]

[itons]

Lixis schreef op donderdag 18 oktober 2018 @ 14:39:
Per 1 december start ik - na 7 jaar in het onderwijs - een traineeship als junior test consultant bij Capgemini. Waarschijnlijk ga ik in het traineeship genoeg kennis opdoen, maar ik vind het ook wel prettig voor die tijd al wat kennis/vaardigheden op te doen.

Hebben jullie tips voor online cursussen / literatuur waarmee ik me al kan gaan verdiepen in dit vakgebied? Ik ben al bezig met een cursus Java via Udemy.

Voor het "testen testen":
TMap
ISTQB
Context Driven Testing
RST
Modern Testing
http://www.huibschoots.nl/wordpress/?page_id=441

Op Meetup.com ook veel leuke groepen met mooie avonden:
https://www.meetup.com/Test-Masters-Series/events/
https://www.meetup.com/FAT-NL/events/

[NielsTn]

itons schreef op donderdag 18 oktober 2018 @ 14:52:
[...]


Voor het "testen testen":
TMap
ISTQB
Context Driven Testing
RST
Modern Testing
http://www.huibschoots.nl/wordpress/?page_id=441

Op Meetup.com ook veel leuke groepen met mooie avonden:
https://www.meetup.com/Test-Masters-Series/events/
https://www.meetup.com/FAT-NL/events/

https://dewt.wordpress.com/
http://www.developsense.com/blog/
https://www.satisfice.com/blog/

[NielsTn]

Lixis schreef op donderdag 18 oktober 2018 @ 14:39:
Per 1 december start ik - na 7 jaar in het onderwijs - een traineeship als junior test consultant bij Capgemini. Waarschijnlijk ga ik in het traineeship genoeg kennis opdoen, maar ik vind het ook wel prettig voor die tijd al wat kennis/vaardigheden op te doen.

Hebben jullie tips voor online cursussen / literatuur waarmee ik me al kan gaan verdiepen in dit vakgebied? Ik ben al bezig met een cursus Java via Udemy.

voor istqb zou je kunnen starten op de website met downloaden en doorlezen van de syllabi die daar per level te vinden zijn, schoot mij te binnen.

intussen is ook ISTQB Advanced level TAE in de pocket. en per 1-dec vaste aanstelling Hoe gaat het met jou @Lixis

[ Voor 8% gewijzigd door NielsTn op 01-12-2018 15:21 ]

[alienfruit]

Heeft iemand hier ervaring met Cypress of TestCafe om websites te testen? Ik heb ook een Gherkin syntax plugin gevonden voor Cypress. Cypress werkt alleen in Chrome terwijl TestCafe ook met andere browsers werkt. Cypress is blijkbaar wel bezig met ondersteuning van andere browsers zoals IE11

[NielsTn]

alienfruit schreef op woensdag 5 december 2018 @ 00:44:
Heeft iemand hier ervaring met Cypress of TestCafe om websites te testen? Ik heb ook een Gherkin syntax plugin gevonden voor Cypress. Cypress werkt alleen in Chrome terwijl TestCafe ook met andere browsers werkt. Cypress is blijkbaar wel bezig met ondersteuning van andere browsers zoals IE11

WAT wil je precies testen op een website?

[alienfruit]

Ik wil de stappen die en gebruiker doorloopt testen en dat het werkt als verwacht
Verder sommige bugs die zijn gerapporteerd en opgelost ter voorkoming van regressie

[stefanass]

alienfruit schreef op woensdag 5 december 2018 @ 00:44:
Heeft iemand hier ervaring met Cypress of TestCafe om websites te testen? Ik heb ook een Gherkin syntax plugin gevonden voor Cypress. Cypress werkt alleen in Chrome terwijl TestCafe ook met andere browsers werkt. Cypress is blijkbaar wel bezig met ondersteuning van andere browsers zoals IE11

Wij gebruiken hier (op een project dat ik zelf niet doe) ook cypress; Daar zitten wel beperkingen aan begreep ik. Alleen statische websites kunnen daarmee gechecked worden, om echte gebruikers-scenario's te doorlopen gebruiken we selenium.

[NielsTn]

alienfruit schreef op woensdag 5 december 2018 @ 02:52:
Ik wil de stappen die en gebruiker doorloopt testen en dat het werkt als verwacht
Verder sommige bugs die zijn gerapporteerd en opgelost ter voorkoming van regressie

Okay, GUI only dus, geen Api’s.
Selenium wordt vaak gebruikt, maar er zijn meer mogelijkheden zoals bv ook Katalon.

[alienfruit]

Mijn ervaringen Selenium is dat het erg onstabiel en redelijk langzaam is.
Nou ja, de API's worden indirekt getest door de web apps/UI te testen.

@stefanass Wat bedoel je met statische websites? Ik zou het gebruiken voor een CRA/React app in combinatie van Cucumber plugin [1] en/of cypress-testing-library [2]. Ik zie zelf niet het nut van de Ghering syntax scripts omdat je toch eerst de step definities moet implementeren.

[1] https://github.com/TheBra...ess-cucumber-preprocessor
[2] https://github.com/kentcd.../blob/master/src/index.js

[NielsTn]

alienfruit schreef op woensdag 5 december 2018 @ 11:52:
Mijn ervaringen Selenium is dat het erg onstabiel en redelijk langzaam is.
Nou ja, de API's worden indirekt getest door de web apps/UI te testen.

@stefanass Wat bedoel je met statische websites? Ik zou het gebruiken voor een CRA/React app in combinatie van Cucumber plugin [1] en/of cypress-testing-library [2]. Ik zie zelf niet het nut van de Ghering syntax scripts omdat je toch eerst de step definities moet implementeren.

[1] https://github.com/TheBra...ess-cucumber-preprocessor
[2] https://github.com/kentcd.../blob/master/src/index.js

Oneens mbt api via Gui. Je bent afhankelijkvan wat de gui je toe laat. Zit er een gui filter op bv een datumveld dan sluit je eea uit, maar weet je nog niet hoe de onderliggende api reageert op bv invalid waarden....

[stefanass]

alienfruit schreef op woensdag 5 december 2018 @ 11:52:
Mijn ervaringen Selenium is dat het erg onstabiel en redelijk langzaam is.
Nou ja, de API's worden indirekt getest door de web apps/UI te testen.

@stefanass Wat bedoel je met statische websites? Ik zou het gebruiken voor een CRA/React app in combinatie van Cucumber plugin [1] en/of cypress-testing-library [2]. Ik zie zelf niet het nut van de Ghering syntax scripts omdat je toch eerst de step definities moet implementeren.

[1] https://github.com/TheBra...ess-cucumber-preprocessor
[2] https://github.com/kentcd.../blob/master/src/index.js

Zoals gezegd gebruik ik cypress zelf niet, mar zoals ik het begreep van mijn collega kan cypress alleen een webpagina "statisch" controleren of er staat wat er verwacht wordt; Moet je bv op die webpagina iets doen en ga je naar een volgende / andere pagina, dan zou dat met cypress dus niet gaan. Misschien wel in combinatie met andere tools, dat weet ik niet.

Maar zoals gezegd, ik gebruik het zelf niet dus of deze info klopt weet ik niet.

Mijn persoonlijke voorkeur is vooralsnog Selenium (icm fitnesse), vooral omdat het in mijn project belangrijk is dat de applicatie in alle browsers werkt; Katalon werd hier eerder ook al genoemd, dit is een optie die ik zelf ook binnenkort ga bekijken ter vervanging van Selenium.

[itons]

stefanass schreef op woensdag 5 december 2018 @ 12:35:
[...]
Maar zoals gezegd, ik gebruik het zelf niet dus of deze info klopt weet ik niet.

- Cypress kan prima flows/opeenvolgende schermen testen
- Katalon is geen vervanging voor Selenium

[Hydra]

alienfruit schreef op woensdag 5 december 2018 @ 11:52:
Mijn ervaringen Selenium is dat het erg onstabiel en redelijk langzaam is.

Vrijwel alles wat een 'echte' browser gebruikt heeft dat probleem. Maar de onstabiliteit is vaak omdat er niet netjes gewacht wordt tot de DOM gerendered is. Als je daar eest op wacht, valt het meestal wel mee. Mensen realiseren zich meestal niet dat als je binnen 10 ms na 't laden van een pagina iets gaat doen je meestal in een soort in-between state zit.

Heb zelf meerdere test systemen ingericht met Selenium Webdriver aangestuurd vanuit Cucumber en dit werkte eigenlijk altijd wel prima.

[alienfruit]

Ja, Selenium Webdriver is een stuk beter dan de oude variant van Selenium. Het wachten op de DOM rendering heb je ook al als je in unit tests een component test.

Maar je kan de API toch testen op de manier de website er gebruik van maakt? Is dit niet het belangrijkste als dit de enigste gebruiker is van de API? Hoe zou je Selenium hiervoor gebruiken? Beetje op dezelfde manier als: https://github.com/cypress-io/cypress-example-api-testing ?

Er is blijkbaar ook TestCafe wat vergelijkbaar is.

[ Voor 22% gewijzigd door alienfruit op 05-12-2018 15:14 ]

[LinkinTED]

Hallo,

Ik wil een iOs app ontwikkelen en deze kunnen testen op een iPhone.
Welk type iPhone raden jullie aan om dat op te doen?

[alienfruit]

Ik zou voor een iPhone gaan waar je iOS 12 op kunt draaien. Verder maakt het qua ontwikkeling niet zoveel uit om mee te beginnen. Het liefst heb je natuurlijk elke mogelijke variant maar dat is wat lastig. Ik heb zelf een iPhone 4S, iPhone 5, iPhone 6S en iPhone XS, iPad mini, iPad 2018. Maar dus ook niet alle mogelijke Apple devices. Ik gebruik veel de simulator voor de verschillende screen sizes.

Als er wat fout gaat op een specifiek apparaat maak ik gebruik van AWS Device Farm (https://docs.aws.amazon.c...veloperguide/welcome.html) en ze ondersteunen een boel apparaten: http://awsdevicefarm.info


@NielsTn Klopt dat je afhankelijk bent van de GUI in zijn gebruik van de API. Misschien is er een monkey tester script die een Swagger JSON kan inlezen en dan zelf er op los gaat

[ Voor 53% gewijzigd door alienfruit op 05-12-2018 15:34 ]

[stefanass]

itons schreef op woensdag 5 december 2018 @ 12:49:
[...]


- Cypress kan prima flows/opeenvolgende schermen testen

Zou zeker kunnen, zoals gezegd heb ik er zelf geen ervaring mee, alleen "van horen zeggen".

- Katalon is geen vervanging voor Selenium

Interessant; Heb je zelf met Katalon gewerkt? Wat ontbreekt er in Katalon waardoor het geen vervanging van Selenium kan zijn? Of is het geen vervanging in de zin dat Katalon onderwater ook Selenium gebruikt, zoals veel andere testtools doen?

Katalon werd mij tijdens een cursus aangeraden en daar werd het genoemd als mogelijke vervanger van onze huidige Selenium suite. Ik heb er zelf nog niet naar kunnen kijken, staat op de planning voor Q1 2019 voor mij om eens te kijken wat er mee mogelijk is. Elke input die ik van te voren kan krijgen of pointers / ervaringen van anderen hiermee is uiteraard zeer welkom.

[ Voor 6% gewijzigd door stefanass op 06-12-2018 10:16 ]

[alienfruit]

Heeft er iemand hier ervaring met het automatisch testen van een seriele poort? Ik heb een sensor dat over deze poort sensor data verstuurt en ik wil dit graag testen. Hoe pak je zoiets aan?

[enira]

stefanass schreef op donderdag 6 december 2018 @ 10:15:
[...]

Zou zeker kunnen, zoals gezegd heb ik er zelf geen ervaring mee, alleen "van horen zeggen".


[...]

Interessant; Heb je zelf met Katalon gewerkt? Wat ontbreekt er in Katalon waardoor het geen vervanging van Selenium kan zijn? Of is het geen vervanging in de zin dat Katalon onderwater ook Selenium gebruikt, zoals veel andere testtools doen?

Katalon gebruikt inderdaad onderwater de selenium webdriver. Je hebt de keus om via manual mode de tests in elkaar te zetten, of via script mode. Dat gaat dan via groovy.

Katalon werd mij tijdens een cursus aangeraden en daar werd het genoemd als mogelijke vervanger van onze huidige Selenium suite. Ik heb er zelf nog niet naar kunnen kijken, staat op de planning voor Q1 2019 voor mij om eens te kijken wat er mee mogelijk is. Elke input die ik van te voren kan krijgen of pointers / ervaringen van anderen hiermee is uiteraard zeer welkom.

Heb het zelf nu een aantal maanden in gebruik. De grote plus is dat je 0,0 ervaring nodig hebt in het aanspreken van de webdriver, dit regelt Katalon zelf voor je met de aanwezige voorgedefinieerde acties.
Bijvoorbeeld een Click of een Set Text spreken voorzich, hieraan koppel je een object, en vervolgens een input. De limiet van Katalon is de limiet van de webdriver zelf.
Met name objecten aanmaken, het hieraan toevoegen van xpath's of het wijzigen van tags etc en deze vervolgens aansturen met variabelen in je tests is allemaal relatief simpel. Erg fijne GUI om doorheen te klikken.

[stefanass]

enira schreef op donderdag 6 december 2018 @ 11:41:
[...]

Katalon gebruikt inderdaad onderwater de selenium webdriver. Je hebt de keus om via manual mode de tests in elkaar te zetten, of via script mode. Dat gaat dan via groovy.

[...]


Heb het zelf nu een aantal maanden in gebruik. De grote plus is dat je 0,0 ervaring nodig hebt in het aanspreken van de webdriver, dit regelt Katalon zelf voor je met de aanwezige voorgedefinieerde acties.
Bijvoorbeeld een Click of een Set Text spreken voorzich, hieraan koppel je een object, en vervolgens een input. De limiet van Katalon is de limiet van de webdriver zelf.
Met name objecten aanmaken, het hieraan toevoegen van xpath's of het wijzigen van tags etc en deze vervolgens aansturen met variabelen in je tests is allemaal relatief simpel. Erg fijne GUI om doorheen te klikken.

Thanks voor de info!

De zaken die je noemt (bv gebruken variabelen etc) heb ik nu allemaal in mijn fitnesse implementatie zitten. Nadeel van mijn huidige suite is dat deze nog draait op de "oude" webdriver, waardoor bv de nieuwste FF versies niet testbaar zijn hiermee. Onze suite is ook end of life en wordt dus niet meer ondersteund, wat ook de reden is dat ik naar andere tooling op zoek ben.

Grootste nadeel van "overstappen" is natuurlijk dat ik grotendeels mijn oude tests opnieuw zal moeten bouwen, maar Katalon lijkt (op het eerste gezicht) wel een goede kandidaat.

Vooral ook omdat de andere testers niet heel technisch zijn maar echte functionele testers
Dan is een tool met een "makkelijke" GUI wel erg handig.

[Wes46]

enira schreef op donderdag 6 december 2018 @ 11:41:
[...]

Katalon gebruikt inderdaad onderwater de selenium webdriver. Je hebt de keus om via manual mode de tests in elkaar te zetten, of via script mode. Dat gaat dan via groovy.

[...]


Heb het zelf nu een aantal maanden in gebruik. De grote plus is dat je 0,0 ervaring nodig hebt in het aanspreken van de webdriver, dit regelt Katalon zelf voor je met de aanwezige voorgedefinieerde acties.
Bijvoorbeeld een Click of een Set Text spreken voorzich, hieraan koppel je een object, en vervolgens een input. De limiet van Katalon is de limiet van de webdriver zelf.
Met name objecten aanmaken, het hieraan toevoegen van xpath's of het wijzigen van tags etc en deze vervolgens aansturen met variabelen in je tests is allemaal relatief simpel. Erg fijne GUI om doorheen te klikken.

Helemaal mee eens. Iemand die geen code kan lezen kan nog 80% van de cases eenvoudig bouwen in Katalon. De scripting + keywords in Katalon geven je de mogelijkheid alles te kunnen doen wat je wilt.

Het eerder gestelde dat Katalon geen vervanging is voor Selenium is mijn inziens totale onzin.

[itons]

Wes46 schreef op donderdag 6 december 2018 @ 14:21:
[...]
Helemaal mee eens. Iemand die geen code kan lezen kan nog 80% van de cases eenvoudig bouwen in Katalon. De scripting + keywords in Katalon geven je de mogelijkheid alles te kunnen doen wat je wilt.

Gegarandeerd success inderdaad om niet-programmeurs programmeer taken uit te laten voeren! Zal een extreem makkelijk te onderhouden test suite opleveren met pure E2E focus, pure werkverschaffing voor de functionele testers tot Sint Juttemis

Wes46 schreef op donderdag 6 december 2018 @ 14:21:
[...]
Het eerder gestelde dat Katalon geen vervanging is voor Selenium is mijn inziens totale onzin.

Katalon is een IDE met een test framework, waarmee je bv. ook API tests kan maken. Selenium is een verzamelnaam voor Selenium IDE, Selenium Client API en Selenium WebDriver en wat er nog meer in het Selenium eco systeem zit. Dus ja, Katalon is geen vervanging voor Selenium, maar een project dat juist gebruik maakt van Selenium om frontend testen te doen. Als je Katalon gebruikt, gebruik je Selenium. Dus hoe kan Katalon Selenium vervangen?

[stefanass]

itons schreef op donderdag 6 december 2018 @ 14:50:
[...]


Gegarandeerd success inderdaad om niet-programmeurs programmeer taken uit te laten voeren! Zal een extreem makkelijk te onderhouden test suite opleveren met pure E2E focus, pure werkverschaffing voor de functionele testers tot Sint Juttemis


[...]


Katalon is een IDE met een test framework, waarmee je bv. ook API tests kan maken. Selenium is een verzamelnaam voor Selenium IDE, Selenium Client API en Selenium WebDriver en wat er nog meer in het Selenium eco systeem zit. Dus ja, Katalon is geen vervanging voor Selenium, maar een project dat juist gebruik maakt van Selenium om frontend testen te doen. Als je Katalon gebruikt, gebruik je Selenium. Dus hoe kan Katalon Selenium vervangen?

Het "werken met Katalon" kan dan toch prima het "werken met Selenium" vervangen lijkt me?
Dat er dan "onder de motorkap" nog steeds Selenium gebruikt wordt is duidelijk, het verschil zit hem dan juist in de IDE die gebruikt wordt in plaats van dat je bv. zelf Selenium tests in java (of andere taal) schrijft.

[Loev]

Je loopt al heel erg snel tegen de beperkingen aan van IDE, ik ken Katalon overigens niet. Ik zou investeren in Selenium Webdriver, tenzij er mooie framework is die de tekortkomingen van IDE oplossen.

[enira]

Loev schreef op vrijdag 7 december 2018 @ 08:59:
Je loopt al heel erg snel tegen de beperkingen aan van IDE, ik ken Katalon overigens niet.

Over welke beperkingen heb je het dan? Ik ben erg benieuwd Het is gewoon mogelijk om vanuit het script tab de selenium webdriver aan te roepen en zo rechtstreeks code daarvoor te typen.

itons schreef op donderdag 6 december 2018 @ 14:50:
Gegarandeerd success inderdaad om niet-programmeurs programmeer taken uit te laten voeren! Zal een extreem makkelijk te onderhouden test suite opleveren met pure E2E focus, pure werkverschaffing voor de functionele testers tot Sint Juttemis

Ik bespeur enige sarcasme in je post.. Maar daarom is juist Katalon geschikt; de stap naar een framework opzetten in taal x en vervolgens het implementeren van tests via selenium is voor een beginnende tester zonder programmeerervaring een helse klus. Katalon leent zich prima voor het opzetten van functionele tests.
Als je een testsuite op poten wil zetten door iemand zonder programmeerskills en hij/zij toch de ambitie heeft voor het automatic testing, dan is dit echt een prima begin.
We zijn het er allemaal wel mee eens dat iemand buiten het testvak hier minder of zelfs niet geschikt voor is, maar zeggen dat een non-coder(maar dus wel tester) met deze tool niets fatsoenlijks neer kan zetten wat niet te onderhouden is is niet waar.

[Nnoitra]

enira schreef op woensdag 12 december 2018 @ 10:00:
Als je een testsuite op poten wil zetten door iemand zonder programmeerskills en hij/zij toch de ambitie heeft voor het automatic testing, dan is dit echt een prima begin.

Naar mijn mening een prima begin om wat kennis op te doen; spelenderwijs leren als het ware.

We zijn het er allemaal wel mee eens dat iemand buiten het testvak hier minder of zelfs niet geschikt voor is,

Een programmeur de testen laten coderen is niets mis mee; ik zou dat zelfs adviseren als de tester zelf niet kan programmeren. De tester moet dan wél de testen schrijven en meekijken/meedenken tijdens het programmeren. Enerzijds om er van te leren en anderzijds om te controleren of er geen shortcuts gebruikt worden.

maar zeggen dat een non-coder(maar dus wel tester) met deze tool niets fatsoenlijks neer kan zetten wat niet te onderhouden is is niet waar.

Er zal misschien, initieel, wel iets fatsoenlijks neergezet worden, maar zonder programmeerkennis is de kans op spaghetti code nogal aanwezig. Dit maakt het een stuk lastiger om de boel te onderhouden, helemaal voor iemand die het tzt overgedragen krijgt.

Ik zou een tester die gaat automatiseren/coderen eerst een programmeer cursusje laten volgen. Daarna helpt het de overdraagbaarheid en de onderhoudbaarheid enorm als de manier van programmeren en de code structuur zoals bedrijf X dat gebruikt ook bij de tester bekend is.

[NielsTn]

*snip* Goed bedoeld, misschien, maar dan nóg hoeft er geen 6 jaar ouwe koe voor uit de sloot

[ Voor 78% gewijzigd door RobIII op 14-09-2024 10:46 ]