[Software Testen] Algemeen topic

[Hydra]

Nnoitra schreef op woensdag 16 november 2016 @ 09:47:
Afhankelijk van wat je test, hoe je test en waarmee je test hoef je niet te kunnen programmeren.
Heel veel regressie zaken kun je prima automatiseren met behulp van tools, ook zonder een programmeer god te hoeven zijn.

Ja hoor. Ik heb in een project meegemaakt dat de testers dat door middel van Selenium IDE deden. Dat werk werd een bottleneck door de domme manier waarop dat opgezet was (als we de login veranderden braken ALLE tests) en dus hebben we het weggeautomatiseerd. De testers hoefden toen alleen nog maar scenario's te schrijven.

Sterker nog, er zijn zat voorbeelden van bedrijven waar de testers alleen de testscenario's en dergelijke bedenken en dan gaan de devvers het scripten/proggen.

Ja en? Dat heb ik al een paar keer beschreven.

ThomasG schreef op woensdag 16 november 2016 @ 09:55:

Volgens mij komt dat vooral door gebrek aan variatie.

Dat is volgens mij precies wat ik zeg. Repetitief = weinig variatie. Repetitief kun je beter automatiseren.

BarôZZa schreef op woensdag 16 november 2016 @ 10:44:
Het ligt heel erg aan wat voor producten/diensten er geleverd worden. Als je geautomatiseerd kan testen, dan is dat prachtig, maar er zijn meer dan genoeg situaties te bedenken waar dat niet of nauwelijks te doen is en dan zijn menselijke testers verrekte handig.

Ik ben bijvoorbeeld een webdeveloper en als je een of andere responsive web app bouwt met een berg Javascript, CSS en dergelijke, dan zal je dat gewoon op de Androidjes, iPhones, iPads, laptops etc moeten testen in verschillende browsers.

Dat kan je met selenium e.d. prima automatiseren. Je kunt, mits de flow redelijk identiek is, de meeste scenario's zelfs hergebruiken tussen platformen. Er is bijzonder weinig dat je niet kunt automatiseren. In de auto branche / bij NASA bijvoorbeeld heb je complete auto simulatie systemen die praten met echte hardware.

In een vorig project deden we dat ook. We hadden 3 interfaces (1 REST API en 2 web interfaces) en die werden afgedekt door dezelfde Gherkin scenario's. Er waren er maar een paar die interface-specifiek waren. De 'lijmlaag' (selenium in het geval van de web interfaces) werd onderhouden door de devs. De meeste scenario's werden door de business analyst onderhouden. Het tweetallige test team had in plaats van een bottleneck te zijn opeens genoeg tijd over om een "test plan" te schrijven.

Het probleem met zo'n setup is alleen dat mensen het te veel werk vinden. Da's puur korte termijn denken.

[ Voor 16% gewijzigd door Hydra op 16-11-2016 12:56 ]

[stefanass]

Hydra schreef op woensdag 16 november 2016 @ 12:51:
[...]


Ja hoor. Ik heb in een project meegemaakt dat de testers dat door middel van Selenium IDE deden. Dat werk werd een bottleneck door de domme manier waarop dat opgezet was (als we de login veranderden braken ALLE tests) en dus hebben we het weggeautomatiseerd. De testers hoefden toen alleen nog maar scenario's te schrijven.

Dat kan je met selenium e.d. prima automatiseren. Je kunt, mits de flow redelijk identiek is, de meeste scenario's zelfs hergebruiken tussen platformen. Er is bijzonder weinig dat je niet kunt automatiseren. In de auto branche / bij NASA bijvoorbeeld heb je complete auto simulatie systemen die praten met echte hardware.

In het eerste geval dat je beschrijft ligt het dus aan de manier waarop het testen was opgezet. Zoals je zelf al zegt in je tweede stukje kan dit prima met Selenium, mits je dit goed opzet. Als de login verandert, zou je m.i. dus maar 1 test aan hoeven passen - de test waar het stukje login in zit.

Dedicated testers hebben wat mij betreft absoluut een toegevoegde waarde. Het probleem is vaak de juiste mensen te vinden. Hetzelfde geldt ook voor testmanagers, waar jij zo te zien niet veel meerwaarde in ziet.

Helaas moet ik zeggen dat ik meerdere malen hetzelfde heb meegemaakt, en inderdaad dat waren dan testmanagers die niet van 'ons' waren, maar van de Cap's etc van deze wereld. Hetzelfde geldt w.m.b. overigens ook voor projectmanagers etc. die 'van buiten' komen. Die hebben vaak geen 'gevoel' voor de organisatie en zijn vaak niet geinteresseerd om de organisatie te leren kennen, wat vaak wel nodig is om zo'n functie goed uit te kunnen voeren. Meestal komt het neer op targets halen, en zoveel mogelijk eigen producten & mensen naar binnen proberen te fietsen.

Back on topic:
Dedicated testers moeten w.m.b. gewoon onderdeel zijn van het team. Samen met de Product owner en developers wordt bepaald wat er getest moet worden, wat er in unit-tests wordt afgedekt, wat er door de tester geautomatiseerd zal worden (met bv. Selenium of een andere tool) en welke zaken manueel afgetest moeten worden. Ja, testen kan soms een vervelend en saai werkje zijn. Maar de regressiestest wordt bv. volledig geautomatiseerd, en juist het automatiseren van tests is iets wat (de meeste) testers juist wel leuk vinden. In mijn ervaring is dat nu weer iets wat developers vaak niet leuk vinden. Ik moet de eerste developer in ieder geval nog tegenkomen die graag met Selenium aan de slag wil.

[roy-t]

Wij hebben op ons team van 6 programmeurs een dedicated tester. Alle interessante tickets en bugs die we oplossen slepen we na het fixen en mergen naar een speciale swimlane "in review". Dit betekend dat de tester bij de volgende automatische build (2x per dag, 12:00 en 20:00u) de feature of bugfix kan testen. De tester zet de ticket daarna op resolved of reopened.

Onze tester heeft geen programmeer achtergrond, en denkt daardoor vaak heel anders dan een developer. Hierdoor vind hij de meest bizarre bugs waar je als dev niet aan denkt. Ook test de tester altijd op een release build waar soms toch net andere bugs in zitten dan in debug.

Voor een tester is het ontzettend belangrijk dat er iets te testen is, het heeft bij ons vrij lang geduurd voordat we een goed ingestelde CI server hadden en voordat we die extra swimlane aan ons scrumboard toegevoegd hadden. Maar sindsdien is de productiviteit van de tester ontzettend gestegen. Een tester moet automatisch weten wat er getest moet worden en moet dat kunnen zonder dat een programmeur iets voor hem moet doen (zoals een build maken). Anders wordt het helemaal niks.

Unit tests doen we waar ik werk niet. We zijn er vorig jaar enthousiast mee begonnen, maar veel UI code en game code is niet altijd even goed te testen. Veel database code ook niet, en ik werk ook nog eens vaak met videoanalyse (Kinect) waar je meerdere gigabytes aan pre-recorded data nodig hebt om je test te draaien en er niet altijd een goed of fout antwoord mogelijk is.

Het viel mij eigenlijk heel erg tegen hoeveel nut unit tests in dit geval hadden. Ik denk dat voor zoiets als een math library het echt een eis is. Maar voor het product waar ik aan werk was het vooral een pijnlijk proces dat meer tijd kostte dan opbracht.

[ Voor 7% gewijzigd door roy-t op 17-11-2016 10:22 ]

[roy-t]

bwerg schreef op maandag 14 november 2016 @ 16:35:
Nu dit topic er trouwens toch is, zijn er hier mensen die naar de Nederlandse testdag gaan vrijdag?

Die site is goed getest zeg:

[goldcard]

Superleuk topic! Eindelijk eens wat discussie over kwaliteitszorg en testen!
Ik zit inmiddels al 10 jaar in het testvak (hi @ collega Smuggler) en heb daarin de meeste rollen vanaf junior tester tot nu sr test manager wel doorlopen.

Even een paar quote doorlopen

Hydra schreef op dinsdag 15 november 2016 @ 13:27:

Kijk maar naar het IND Indigo 'project'; dat heeft ik weet niet hoe veel gebruikers, heeft zich enorm lang voortgesleept en is door gebrekkige tests in grote problemen geraakt.

Het blijft me verbazen dat (eind)gebruikers, devvers, projectleiders, stuurgroepen etc dit soort statements bezigen. Een ontwikkeltraject wordt door testen nooit in de problemen gebracht. Testers 'testen' geen fouten de code in, die fouten worden in de requirements/design en of bouwfase ingebracht. Het enige dat je met het neerzetten van een goed (handmatig/geautomatiseerd) testtraject hoopt te bereiken is dat je de meest ernstige fouten vindt en kan laten herstellen binnen de gegeven tijd en budget.

Hydra schreef:
"Test managers" e.d. zijn dood gewicht; helemaal als je voor hetzelfde geld twee junior devs aan kan nemen.

Ik zou willen dat dit waar was. Dat zou namelijk betekenen dat klanten software kunnen bestellen die vanaf het begin foutloos is en bij elke volgende iteratie foutloos blijft. Helaas is dat in de praktijk eigenlijk nooit het geval. Met de beweging naar steeds kleinere (ontwikkel)teams, agile/scrum en DevOps zie ik ook weinig toekomst voor het vak 'test manager' of 'testcoordinator', maar de rol zou altijd wel blijven bestaan.

Ik lees in dit topic veel opmerkingen over 'devvers zijn betere testers, want die zien zelf wel of ze fouten maken' of 'devvers zijn betere testers, want ze begrijpen beter hoe de code werkt'. Op zichzelf zouden beide statements niet eens onwaar hoeven zijn, ware het niet dat tegenwoordig applicaties bijna nooit 'stand-alone' meer zijn en altijd met andere applicaties ketens vormen. Een devver van applicatie 1 zal zich minder snel geroepen voelen om applicatie overstijgende / ketenbrede testen uit te voeren. Zie hier een van de meerwaarden van een dedicated test rol / team.

Uiteindelijk maakt het linksom of rechtsom niet uit bij wie je welke taken/rollen voor kwaliteitszorg belegd, als je er maar over nagedacht hebt en als de aanpak maar 'fit for purpose' is. Dan maakt het dus niet hoe groot of hoe klein de opdracht ook is, en welke vorm van ontwikkelaanpak (agile vs waterval) je gebruikt. Een website die alleen informatie weergeeft en géén interactie met bezoekers vraagt heeft een heel andere manier van testen nodig dan een back-end systeem voor mobiele telefonie waarop >100 interfaces aansluiten.

Hydra schreef:
Komt nog eens bij dat een gebruikerspanel een stuk goedkoper is dan een paar "test consultants".

Ook dit is wel een aardig statement. In veel gevallen zou je best nog wel eens gelijk kunnen hebben. Maar opnieuw is hier de vraag: in welke fase van je voortbrengingsproces ben je en welk type 'bevindingen' wil je dat er gedaan worden. Gebruikerspanels zijn uitermate goed geschikt om usability te testen, maar ook het eerder genoemde 'wat gebeurt er wanneer je buiten de gebaande paden van de workflow gaat' kunnen zij uitstekend. Vaak zie dat gebruikerspanels ook optreden als 'acceptant', waarmee ze eigenlijk geen test uitvoeren maar meer een 'confidence builder' beleven tijdens een 'gebruikers acceptatie test'. Wanneer je echter wil laten testen of twee systemen technisch correct berichten uitwisselen (interface test / integratie test) dan zou ik hier géén testpanel op inzetten.

Food for thought
Het is waanzinnig dat er zoveel bedrijven en zzp-ers zijn die hun geld verdienen met rollen op het gebied van testen en QA. Helaas is het zo dat foutloze software nog niet door mensen is ontwikkeld. Elke devver die vindt dat tester/testen 'waste' is heeft gelijk, maar dezelfde devvers zijn nog steeds niet in staat gebleken deze waste overbodig te maken. Pas wanneer het genereren van code/applicaties/ketens op basis van supercomputers met ver ontwikkelde AI gebeurt zal het testvak zoals we dat nu kennen uitsterven.... gaan wij alleen niet meer meemaken

[Giesber]

goldcard schreef op donderdag 17 november 2016 @ 14:28:

Een ontwikkeltraject wordt door testen nooit in de problemen gebracht.

Hoe eerder fouten gevonden worden, hoe gemakkelijker ze op te lossen zijn. Testen kost tijd, maar te laat in het proces testen kost ook tijd, alleen is die tijd minder zichtbaar. Vandaar dat Unit testen dikwijls als belangrijk worden gezien: ze geven direct bij het ontwikkelen feedback.

Integratie van code van verschillende developers is nog zo'n teer punt. Als je vlak na de integratie test, dan kan een fout meteen gelinkt worden aan de integratie, en meestal rap opgelost worden. Als je daar 4 weken later pas achter komt moeten de ontwikkelaars weer een volledige analyse doen, en de fouten die ontstaan bij een integratie zijn soms veel moeilijker te vinden dan een logische fout in 1 blok code.

[Hydra]

goldcard schreef op donderdag 17 november 2016 @ 14:28:
Het blijft me verbazen dat (eind)gebruikers, devvers, projectleiders, stuurgroepen etc dit soort statements bezigen. Een ontwikkeltraject wordt door testen nooit in de problemen gebracht.

Ik hoop dat je meer details in je test legt dan in je leeswerk. Ik zeg dat het door gebrekkige tests in de problemen gebracht is. Dit is wat anders dan zeggen dat het "door testen / tests" in problemen gebracht is. Slechte tests zijn op z'n best nutteloos en geven in het ergste geval een vals gevoel van zekerheid. En dat laatste was in dat project gewoon het geval. Goede geautomatiseerde tests in een CI chain waren vrijwel afwezig.

[goldcard]

Hydra schreef op donderdag 17 november 2016 @ 22:22:
[...]
Ik hoop dat je meer details in je test legt dan in je leeswerk.

Zullen we het even niet persoonlijk maken ajb?

Hydra schreef op donderdag 17 november 2016 @ 22:22:
[...]Ik zeg dat het door gebrekkige tests in de problemen gebracht is. Dit is wat anders dan zeggen dat het "door testen / tests" in problemen gebracht is. Slechte tests zijn op z'n best nutteloos en geven in het ergste geval een vals gevoel van zekerheid. En dat laatste was in dat project gewoon het geval. Goede geautomatiseerde tests in een CI chain waren vrijwel afwezig.

Het punt dat ik wil maken is dat in jouw voorbeeld het bouwtraject ervoor gezorgd heeft dat het project in de problemen kwam. Bouw foutloos en je kan testen tot je een ons weegt (relevante tests of niet) en je gaat probleemloos live! Als ik in mijn werk release op release afhankelijk zou zijn van een ander team om mij eigen werk te verbeteren zou ik me toch achter de oren gaan krabben... Dat MOET beter kunnen.

[jip_86]

Neemt weg dat je nog steeds fout kan testen, en daardoor denkt dat je probleemloos live kan

[Smuggler]

Al test je nog zo goed, je hebt nooit de "garantie" dat je probleemloos live kan gaan. Die garantie ga ik dus ook nooit afgeven.

Echter een goede tester heeft allerlei manieren om dit risico zoveel mogelijk af kan dekken.
Als tester heb je jezelf wel beschermd door al je testen te documenteren, zodat je kan laten zien wat, en wat er niet is test met de redenen erbij.
Goede communicatie is belang tussen tester en developer.
Als de Developer zegt aan X te hebben gewerkt, dan heb je als tester geen directe reden om Y te gaan testen.
Als de developer een link heeft aangelegd tussen X en Y vanuit X, dan dient dit gecommuniceerd te worden. Want in de commits ziet de tester ook niet dan Y is veranderd, en wellicht is wijziging te subtiel om de verwijzing naar Y te zien. Als de tester al echt in de commits naar de code gaat kijken.
Het is een samenspel tussen ontwikkelaars en testers.

Ik kan ook best fout testen, maar dit zou ik bijzonder vinden als dat niet eerder is opgemerkt. Ik communiceer van te voren duidelijk waar ik op ga testen en waar ik op ga letten en welke test techniek ik ga toepassen.
het plan van aanpak. Als we toch iets vinden dat niet gegarandeerd gevonden zou worden, dan pas je het plan aan zodat je alle soortgelijke fouten ook eruit kan halen. Of je communiceert dit als een risico.

Maar hydra schijnt een hekel te hebben aan testers door persoonlijke ervaringen hiermee. maar je bouwt in eerste instantie zelf de software die niet goed genoeg is voor release. en je zou zelf naar een tester kunnen communiceren wat je zelf wel checkt aan de hand van unit tests, en welke dingen dus niet zeker zijn. Het is geen schutting waar je het overheen gooit.

Testen is een fantastisch vak, en goede testers maken de software echt beter!
Jammer dat de testers het bij voorbaat al opgaven bij jouw software hydra .

[Hydra]

Smuggler schreef op vrijdag 18 november 2016 @ 16:45:
Maar hydra schijnt een hekel te hebben aan testers door persoonlijke ervaringen hiermee.

Wel weer typisch dat dit kennelijk zo persoonlijk genomen wordt. Ik heb de ervaring dat je zo veel mogelijk de menselijke herhaling uit het systeem moet halen. Nergens heb ik gezegd dat mensen die testscenario's opzetten om maar wat te noemen 'slecht' zijn. Mijn ervaring is alleen dat 1. manueel testen te foutgevoelig is (want fucking saai) en dat 2. veel 'test managers' te veel tijd steken in 'test plannen' en te weinig tijd in daadwerkelijk iets nuttigs (bijvoorbeeld test coverage).

Een tester die volle bak Gherkin scripts gaat schrijven is meer dan welkom. Helaas zijn dat er maar weinig. Goeie testers zijn net zo moeilijk te vinden als goeie developers.

Jammer dat de testers het bij voorbaat al opgaven bij jouw software hydra .

Als ik je werk kan wegautomatiseren zou ik toch eerst eens naar jezelf gaan kijken.

[ Voor 13% gewijzigd door Hydra op 19-11-2016 18:15 ]

[Coltrui]

Maar dat kan je niet, en dat kan je blijven beweren tot je een ons weegt. Een programmeur schrijft testen gericht op code die er is, maar nooit op code die ontbreekt - zou wel vreemd zijn. En dat zie ik elke dag.

En prima - laat ons aannemen dat jij alles dichtspijkert - nou, dan ben je een uitzondering. Ik vind het veel te kort door de bocht om te stellen dat je alles kan automatiseren, om van kosten dan maar te zwijgen - en dan nóg is een menselijk oog nodig.

Edit: overigens is er in dit topic maar eentje nogal erg persoonlijk bezig. Ik dacht, ik zeg het even

[ Voor 10% gewijzigd door Coltrui op 19-11-2016 20:49 ]

[Hydra]

Coltrui schreef op zaterdag 19 november 2016 @ 20:44:
Maar dat kan je niet, en dat kan je blijven beweren tot je een ons weegt. Een programmeur schrijft testen gericht op code die er is, maar nooit op code die ontbreekt - zou wel vreemd zijn. En dat zie ik elke dag.

Ik zeg volgens mij letterlijk dat testers die scenario's schrijven meer dan welkom zijn volgens mij? Als zij een scenario schrijven waarvoor de code mist heb je volgens mij gewoon een bug gevonden. Maar die scenario's runnen we wel automatisch; dus elke X minuten testen we opnieuw of die bug (of een andere) niet teruggekomen is.

En prima - laat ons aannemen dat jij alles dichtspijkert - nou, dan ben je een uitzondering. Ik vind het veel te kort door de bocht om te stellen dat je alles kan automatiseren, om van kosten dan maar te zwijgen - en dan nóg is een menselijk oog nodig.

Je blijft maar hameren op dat devs niet alles testen maar je mist het punt gewoon. Je automatische scenario's moeten dat afdekken. Het is helemaal prima als die door een tester (of business analyst of PO for all I care) geschreven worden. Maar het afwerken van al die scenario's moet automatisch gebeuren. Dit zorgt 1: dat al die scenario's altijd getest worden (want mensen gaan dat niet doen; het is saai kutwerk) en dat 2: de 'testers' (of wie dan ook) de tijd en ruimte hebben om meer scenario's te maken.

Het punt is hier alleen dat de meeste "testers" of uberhaupt test clubs zo helemaal niet werken. Want waar het om gaat is dat je scenario's schrijft als "As a user when I login with the wrong pincode 4 times I expect to see a warning message and be blocked for 10 minutes". Dus er zit een redelijk letterlijk 1-op-1 verband tussen de scrum stories die gemaakt worden en de test-scenario's. Maar gek genoeg zijn het nooit de testers die die stories schrijven; dat is meestal de PO of de business analyst.

Daarnaast neem ik niets persoonlijk. Ik ben het gewoon met een aantal opmerkingen van je oneens en aangezien dit mijn werk is en ik m'n werk gewoon serieus neem ga ik een discussie met je aan. Misschien moet je proberen gewoon eens serieus op die zaken in te gaan; leer je misschien nog eens iets

[stefanass]

Hydra schreef op maandag 21 november 2016 @ 09:04:
[...]
Het punt is hier alleen dat de meeste "testers" of uberhaupt test clubs zo helemaal niet werken. Want waar het om gaat is dat je scenario's schrijft als "As a user when I login with the wrong pincode 4 times I expect to see a warning message and be blocked for 10 minutes". Dus er zit een redelijk letterlijk 1-op-1 verband tussen de scrum stories die gemaakt worden en de test-scenario's. Maar gek genoeg zijn het nooit de testers die die stories schrijven; dat is meestal de PO of de business analyst.

Dat lijkt me dan een foute/niet-optimale implementatie van scrum. De stories horen niet alleen door een PO of Analist geschreven te worden, dat hoor je als scrum-team samen te doen tijdens je refinements. Op die manier heeft het dev-team (inclusief tester!) nl. ook nog invloed op de stories en kunnen zaken die getest moeten worden scherper gesteld worden, bv. door acceptatiecriteria op te nemen in de stories. En juist door het op die manier te doen heeft een (goede) tester meer toegevoegde waarde dan bij alleen het uitschrijven van testscenario's en uitvoeren van tests. Dit geld overigens ook voor devs; Betrek ze er eerder bij en stel samen de stories op, dan kunnen mensen meedenken en misschien wel met betere opties komen waar een PO / Analist zelf nog niet aan gedacht heeft.

[Nnoitra]

Hydra schreef op maandag 21 november 2016 @ 09:04:
Misschien moet je proberen gewoon eens serieus op die zaken in te gaan; leer je misschien nog eens iets

Misschien moet jij proberen om jou visie niet als de absolute waarheid te zien en open te staan voor meningen en ideeën van andere; leer zelfs jij misschien nog eens iets

[goldcard]

Exemplarisch hoe we binnen een paar posts meteen de traditionele 'wij vs zij' (dev vs test) stellingen hebben ingenomen en dat meteen ook naar een persoonlijk niveau weten te brengen. Daar zit sowieso nog veel winst te behalen in de samenwerking!

[Hydra]

stefanass schreef op maandag 21 november 2016 @ 09:52:
Dat lijkt me dan een foute/niet-optimale implementatie van scrum. De stories horen niet alleen door een PO of Analist geschreven te worden, dat hoor je als scrum-team samen te doen tijdens je refinements.

Zullen we het even bij het testen houden? Ik heb niet gezegd dat het alleen door de PO/BA gedaan wordt. Natuurlijk komt daar vanuit de devs enorm veel input op. Anders is zo'n story nooit ready. Ik heb echt de zin en tijd niet om een heel paper te schrijven over hoe de processen al dan niet werken/werkten in de projecten die ik de laatste jaren gedaan heb.

Wie die scenario's schrijft is m.i. niet relevant. Ik heb ook al aangegeven dat testers daar prima een meerwaarde in hebben. Ik zeg alleen, keer op keer, dat het aftesten van die scenario's niet manueel (word documenten met test scripts) maar automatisch (parsen van scenario teksten en deze tegen de applicatie draaien) gedaan moet worden.

Nnoitra schreef op maandag 21 november 2016 @ 10:57:
Misschien moet jij proberen om jou visie niet als de absolute waarheid te zien en open te staan voor meningen en ideeën van andere; leer zelfs jij misschien nog eens iets

Doe niet zo kinderachtig. Ik geef gewoon een onderbouwde mening. Mijn mening is niet "de waarheid". DIe van jou (en de anderen hier) ook niet. Als je niet inhoudelijk in kan gaan op zaken; blijf dan gewoon weg. Het is te treurig dat je net dat ene stukje er alleen uitplukt. Het was ook nog eens niet aan jou gericht.

goldcard schreef op maandag 21 november 2016 @ 11:26:
Exemplarisch hoe we binnen een paar posts meteen de traditionele 'wij vs zij' (dev vs test) stellingen hebben ingenomen en dat meteen ook naar een persoonlijk niveau weten te brengen. Daar zit sowieso nog veel winst te behalen in de samenwerking!

Wat ik erg exemplarisch vind is dat op het moment dat er stevig tegengas gegeven wordt op traditionele 'wijsheden' er meteen dit soort reacties komen die helemaal niet meer op de materie in gaan. Ik ben niet bepaald de eerste die roept dat manueel testen geen toekomst heeft. Wen d'r maar aan.

[ Voor 17% gewijzigd door Hydra op 21-11-2016 11:32 ]

[goldcard]

Hydra schreef op maandag 21 november 2016 @ 11:29:
Ik ben niet bepaald de eerste die roept dat manueel testen geen toekomst heeft.

I know, en ik ben het op veel gebieden helemaal met je eens. De manier waarop die 'uitfasering' plaats gaat vinden is nog lang niet duidelijk.

Wat ik wel vind: zolang het nog noodzakelijk is om manueel testen uit te voeren (omdat het gewoonweg nog niet mogelijk of gewenst (!) is) dan verwacht ik van zowel de developers als van de testende organisatie (professionals / test panels / eindgebruikers) dat zij elkaar aanvullen en versterken in de testen. De testdoelen en -dekking die beide groepen halen moet aanvullend zijn. Daarnaast zou elk van de groepen serieus werk moeten maken om hun eigen activiteiten zo efficient mogelijk uit te voeren. Test automation is daarbij voor herhalende testen de meest voor de hand liggende stap. Voor acceptatietesten / test panels kan je zoeken naar andere optimaliserende maatregelen, maar ook test automation kan daarbij nog zeker een optie zijn.

[Reteip]

Volgens mij zijn we hier bezig met de discussie testen versus checken. Waarbij Checking uitermate geschikt is om te vervangen door geautomatiseerde 'tests'. In tegenstelling tot testen, in onderstaande definitie. In die definitie is testen lastig, of op dit moment nog vrijwel onmogelijk om te automatiseren. Of in ieder geval uiterst inefficiënt.

Checking Is Confirmation

Checking is something that we do with the motivation of confirming existing beliefs. Checking is a process of confirmation, verification, and validation. When we already believe something to be true, we verify our belief by checking. We check when we’ve made a change to the code and we want to make sure that everything that worked before still works. When we have an assumption that’s important, we check to make sure the assumption holds. Excellent programmers do a lot of checking as they write and modify their code, creating automated routines that they run frequently to check to make sure that the code hasn’t broken. Checking is focused on making sure that the program doesn’t fail.

Testing Is Exploration and Learning

Testing is something that we do with the motivation of finding new information. Testing is a process of exploration, discovery, investigation, and learning. When we configure, operate, and observe a product with the intention of evaluating it, or with the intention of recognizing a problem that we hadn’t anticipated, we’re testing. We’re testing when we’re trying to find out about the extents and limitations of the product and its design, and when we’re largely driven by questions that haven’t been answered or even asked before. As James Bach and I say in our Rapid Software Testing classes, testing is focused on “learning sufficiently everything that matters about how the program works and about how it might not work.”

Bron: http://www.developsense.c...9/08/testing-vs-checking/

[Hydra]

Reteip schreef op woensdag 23 november 2016 @ 11:36:
In tegenstelling tot testen, in onderstaande definitie.

Het is leuk er een compleet andere definitie bij te slepen maar dit is gewoon niet de definitie van testen die over 't algemeen in de industrie gebruikt wordt. Maar als je er blij van wordt wil ik het best gewoon Check Driven Design gaan noemen hoor

[Tjolk]

Mooi topic. Zelf zijn we hier intern ook zoekende mee.

Onze situatie: webapplicatie voor een specifieke branche waar klanten een abonnement op kunnen afsluiten. Behelst nu 4 modules, dat wordt uitgebreid naar ± 10 in de komende jaren. Allemaal nieuwe functionaliteiten die ook over modules heen effect hebben. Devver 1 is nu 2,5 jaar aan het werk, devver 2 (ik) 1,5 jaar. Er is behoefte aan nog 2 devvers. We werken sinds kort eindelijk via volledig OTAP, waar voorheen TA in één stap gedaan werd.

Testen gebeurd nu puur handmatig. Per issue wordt op de T server getest of het werkt zoals beschreven en bedoeld door de projectleider. Die projectleider is een voormalig consultant uit de branche wiens werk we nu bot gezegd aan het "wegautomatiseren" zijn.
Als alles voor een bepaalde versie door T heen is gekomen gaat die versie door naar A en wordt de gehele applicatie doorlopen. Echter is dat ook handmatig en wordt nog steeds met name gekeken "of het werkt". En dat is natuurlijk niet ideaal, immers worden niet structureel de punten getest waar het fout zou kunnen gaan als iemand een onverwachte actie uitvoert.

We hebben wel eens gekeken naar unit tests, maar het probleem daarvan is wat eerder ook is aangegeven in dit topic: het schrijven en bijhouden van de tests an sich gaat gewoon veel tijd kosten, vooral ook omdat bij iedere versie wel weer punten aangepast worden die ook de test zullen veranderen.

Dus hoewel we nu wel graag het testen ten dele zouden willen automatiseren zou het ook zonde zijn als dit een hoop capaciteit bij de devvers wegneemt. Anderzijds is betrouwbaarheid en kwaliteit van de software één van de (zoniet de) belangrijkste peilers waarop we leunen. De bestaande klanten kunnen het niet gebruiken als er significante fouten optreden die verder gaan dan een stukje UI wat niet reageert zoals verwacht. Daardoor wordt er steeds uitvoeriger getest, maar dat blijft handmatig en zeker op den duur repetitief met kans op verslapte aandacht tijdens het testen.


Tot zover mijn huidige 2 centjes. Ik blijf dit topic volgen met interesse!

[Hydra]

Ger schreef op woensdag 23 november 2016 @ 13:53:
We hebben wel eens gekeken naar unit tests, maar het probleem daarvan is wat eerder ook is aangegeven in dit topic: het schrijven en bijhouden van de tests an sich gaat gewoon veel tijd kosten, vooral ook omdat bij iedere versie wel weer punten aangepast worden die ook de test zullen veranderen.

Da's ook een van de punten van unit tests. Als je een test aan moet passen betekent dat dat de kans nogal groot is dat er iets 'stuk' is. Vaak moet je unit tests aanpassen die je niet verwacht had. Wat denk je dat er gebeurd was als je die test niet had gehad?

Goeie software maken kost tijd. Hoe dan ook. Door tests gewoon domweg te skippen bespaar je niet op die tijd; je bouwt technical debt op en dat gaat je enorm in je kont bijten. Op een gegeven moment is de applicatie te groot en te complex om in onze hersenen te passen, je raakt 't overzicht kwijt, en er zit de ene na de andere bug in productie.

Om even een idee te geven van een willekeurige REST microservice service hier: src/main bevat 3281 regels code. src/test bevat 4933 regels code. Dus wij hebben dik anderhalf keer zoveel test code als 'prod' code.

Dus hoewel we nu wel graag het testen ten dele zouden willen automatiseren zou het ook zonde zijn als dit een hoop capaciteit bij de devvers wegneemt.

Ik krijg als devver nogal jeuk als ik een andere dev dat soort dingen hoor zeggen. Die tijd ben je nu allemaal kwijt omdat je het eerder niet gedaan hebt.

Anderzijds is betrouwbaarheid en kwaliteit van de software één van de (zoniet de) belangrijkste peilers waarop we leunen. De bestaande klanten kunnen het niet gebruiken als er significante fouten optreden die verder gaan dan een stukje UI wat niet reageert zoals verwacht. Daardoor wordt er steeds uitvoeriger getest, maar dat blijft handmatig en zeker op den duur repetitief met kans op verslapte aandacht tijdens het testen.

Ik vind het een kwestie van je werk serieus nemen. Je (ik heb het niet over jou, maar in het algemeen) een pruts-developer als je geen testen schrijft voor je software. Ik heb hier op m'n blog een tijdje geleden een opiniestuk/rant over geschreven omdat het zo vaak misgaat omdat managers lopen te pushen op het niet schrijven van tests. Dat doet mijn PO ook. Hoorde 'em onlangs nog zeggen dat we ook wel voor 60% coverage kunnen gaan i.p.v. onze ongeveer 90%. De andere back-enders en ik negeren dat gewoon. Software engineering is een vak en ik zie mijzelf en m'n collega's als vakmensen. Je gaat een timmerman ook niet vertellen dat het huis met 30% minder hout gebouwd kan worden.

[Tjolk]

Hydra schreef op woensdag 23 november 2016 @ 14:06:
[...]


Ik krijg als devver nogal jeuk als ik een andere dev dat soort dingen hoor zeggen.

Het was niet mijn bedoeling om jou te kriebelen

offtopic:
Was jij niet overigens degene die in de devschuur een tijdje terug schreef dat je ook jeuk kreeg van belerende betweters?

Ik vind het een kwestie van je werk serieus nemen. Je (ik heb het niet over jou, maar in het algemeen) een pruts-developer als je geen testen schrijft voor je software. Ik heb hier op m'n blog een tijdje geleden een opiniestuk/rant over geschreven omdat het zo vaak misgaat omdat managers lopen te pushen op het niet schrijven van tests. Dat doet mijn PO ook. Hoorde 'em onlangs nog zeggen dat we ook wel voor 60% coverage kunnen gaan i.p.v. onze ongeveer 90%. De andere back-enders en ik negeren dat gewoon. Software engineering is een vak en ik zie mijzelf en m'n collega's als vakmensen. Je gaat een timmerman ook niet vertellen dat het huis met 30% minder hout gebouwd kan worden.

Jep, I know. We zijn er ook niet voor niets mee bezig, maar eigenlijk vanaf dag 1 (iig dat ik erbij betrokken ben) zitten we al met teveel technical debt, die alleen maar groeit en een CEO die alleen maar pushed om sneller functies uit te rollen. Wat dat betreft zitten we gewoon in een spagaat. Komt bij dat capaciteit hier (zuiden) lastig te vinden is; op de vacatures die we hebben is tot nu toe 1 sollicitant gekomen die gewoon niet geschikt was.

Vandaar ook dat voor nu het handmatige testen is uitgebreid. Voorheen was onze projectleider ook degene die sales en demos deed en ook degene die in zijn eentje testte. Sales is inmiddels aangenomen en na de kerst komt er iemand die een deel van het testen en beschrijven van features en flow op zich gaat nemen. Dat vergroot de totale capaciteit van ons team ook en geeft ook meer tijd voor zowel het ontwikkelen als voor het testen.

Ideaal: nope. Maar IMO beter dan niets en we leunen zeker niet achterover op dit vlak.

PS: we zijn ook de eerste stappen aan het maken met Selenium. Dat kan voor veel basishandelingen ook veel schelen volgens mij.

[goldcard]

Hydra schreef op woensdag 23 november 2016 @ 13:15:
[...]


Het is leuk er een compleet andere definitie bij te slepen maar dit is gewoon niet de definitie van testen die over 't algemeen in de industrie gebruikt wordt. Maar als je er blij van wordt wil ik het best gewoon Check Driven Design gaan noemen hoor

Wanneer je bij het testen géén verwacht resultaat hebt, dan heet het (in mijn woordenboek) geen testen meer maar proberen!

[Hydra]

Ger schreef op woensdag 23 november 2016 @ 14:29:
Jep, I know. We zijn er ook niet voor niets mee bezig, maar eigenlijk vanaf dag 1 (iig dat ik erbij betrokken ben) zitten we al met teveel technical debt, die alleen maar groeit en een CEO die alleen maar pushed om sneller functies uit te rollen. Wat dat betreft zitten we gewoon in een spagaat. Komt bij dat capaciteit hier (zuiden) lastig te vinden is; op de vacatures die we hebben is tot nu toe 1 sollicitant gekomen die gewoon niet geschikt was.

Ik werk bij een kleine consulting club en we hebben wel een paar keer dit soort klussen gehad. Als dit de status is en blijft gaan we daar gewoon weg. We hebben bepaalde standaarden qua kwaliteit en dit is gewoon onacceptabel. En als ze nu al problemen hebben wat denk je dat er gaat gebeuren als de zooi echt in elkaar klapt?

Kleine voorspelling: over een jaar of zo zijn de meest senior mensen bij jullie het wel een beetje zat en gaan weg naar een andere klus. Daarvoor in de plaats kunnen niet op redelijke termijn ervaren mensen aangenomen worden dus wordt het capaciteitsprobleem groter. Er worden te junior mensen aangenomen die klakkeloos de CEO volgen en er nog een grotere puinzooi van maken. Goeie mensen aannemen kun je dan helemaal wel vergeten; die bedanken in hun proefperiode.

Hop. Je duikt over de "technical debt event horizon" heen en je bent als bedrijf reddeloos verloren.

Vandaar ook dat voor nu het handmatige testen is uitgebreid. Voorheen was onze projectleider ook degene die sales en demos deed en ook degene die in zijn eentje testte. Sales is inmiddels aangenomen en na de kerst komt er iemand die een deel van het testen en beschrijven van features en flow op zich gaat nemen. Dat vergroot de totale capaciteit van ons team ook en geeft ook meer tijd voor zowel het ontwikkelen als voor het testen.

Tja. Maar dit schaalt natuurlijk voor geen meter. Om nog maar niet te spreken over dat meneer de sales natuurlijk na 3 keer de registratie getest te hebben daar ook wel een beetje klaar mee is en er dus maar vanuit gaat dat 't wel goed zit.

PS: we zijn ook de eerste stappen aan het maken met Selenium. Dat kan voor veel basishandelingen ook veel schelen volgens mij.

Tip: bouw je tests op door middel van een BDD framework (heb zelf Cucumber en JBehave gebruikt) dat dan weer selenium webdriver aanstuurt. Dan kun je gewoon tekstuele scenario's schrijven en het is ook een stuk makkelijker herbruikbare test code te maken.

Als je Selenium IDE gaat gebruiken, wat op bases van XPath en CSS selectors werkt, dan gaan al je test scenario's shit stuk als je een kleine wijziging ergens maakt.

[BarôZZa]

Hydra schreef op woensdag 23 november 2016 @ 14:06:
[...]

Ik krijg als devver nogal jeuk als ik een andere dev dat soort dingen hoor zeggen. Die tijd ben je nu allemaal kwijt omdat je het eerder niet gedaan hebt.


[...]

Ik vind het een kwestie van je werk serieus nemen. Je (ik heb het niet over jou, maar in het algemeen) een pruts-developer als je geen testen schrijft voor je software. Ik heb hier op m'n blog een tijdje geleden een opiniestuk/rant over geschreven omdat het zo vaak misgaat omdat managers lopen te pushen op het niet schrijven van tests. Dat doet mijn PO ook. Hoorde 'em onlangs nog zeggen dat we ook wel voor 60% coverage kunnen gaan i.p.v. onze ongeveer 90%. De andere back-enders en ik negeren dat gewoon. Software engineering is een vak en ik zie mijzelf en m'n collega's als vakmensen. Je gaat een timmerman ook niet vertellen dat het huis met 30% minder hout gebouwd kan worden.

Ik zou me juist niet serieus genomen voelen als ik meer tijd kwijt was aan het saaie geestdodende werk van tests schrijven dan aan het daadwerkelijke programmeren/ontwerpen. Neemt niet weg dat ik geen enkel probleem heb dat mijn werk ten alle tijden aan alle kanten mag worden getest, ik vind het alleen zonde van de dev uren als daar testers voor zijn.

Of managers onzin verkondigen is geheel afhankelijk van de situatie. Tests zijn een goed middel dat heel nuttig kan zijn, maar het is geen doel op zich en niet in alle gevallen inzetbaar. Het meest voor de hand liggende voorbeeld zijn projecten waarvoor een vast budget gerealiseerd moeten worden en waarvoor daarna een SLA loopt of bugs uurtje factuurtje worden opgelost. In dat geval kan het zo zijn dat je uiteindelijk een dief bent van je eigen portemonnee als de devvers veel te enthousiast tests gaan schrijven. Ik heb zelfs klanten tijdens onderhandelingen gehoord die zeiden dat ze het zelf wel zouden testen als daarmee de prijs omlaag ging. En zelfs dat kan prima als er geen enorm kritieke zaken van afhankelijk zijn. Je merkt ook dat er stevig wordt onderhandeld op de projectkosten (want zichtbaar), terwijl ze een stuk minder agressief zijn als het op SLA's en uren aankomt. Dat zien ze vaak als noodzakelijk kwaad ipv onderhandelingsmogelijkheid. Het is vaak moeilijk uit te leggen en vaak zijn klanten weer niet de meest technische/wiskundige mensen. Dan maar korte termijn waarbij je verzekerd bent van lange termijn knaken, uiteindelijk zijn het toch de euro's die bepalen.

Hydra schreef op woensdag 23 november 2016 @ 17:24:
[...]

Kleine voorspelling: over een jaar of zo zijn de meest senior mensen bij jullie het wel een beetje zat en gaan weg naar een andere klus. Daarvoor in de plaats kunnen niet op redelijke termijn ervaren mensen aangenomen worden dus wordt het capaciteitsprobleem groter. Er worden te junior mensen aangenomen die klakkeloos de CEO volgen en er nog een grotere puinzooi van maken. Goeie mensen aannemen kun je dan helemaal wel vergeten; die bedanken in hun proefperiode.

Hop. Je duikt over de "technical debt event horizon" heen en je bent als bedrijf reddeloos verloren.

Welnee, in Nederland gaat zoveel geld rond dat brakke IT bedrijven gewoon eindeloos lang kunnen overleven. Helemaal in een niche als advocatuur, accountancy, apothekers, scholen, overheid oid waar de budgetten groot zijn en de concurrentie nihil. Van een brak klantenportal kan je eeuwig leven. De vele crappy software uit Nederland zijn het bewijs. Gewoon 10 jaar geld innen met een of andere Java applett en daarna een brief sturen dat ze hun browser niet mogen updaten

Ook veel seniors(qua leeftijd tov het dev team) gezien die maar al; te graag gewoon jaar in jaar uit hetzelfde blijven doen. Lang niet allemaal zijn ze zo ambitieus of avontuurlijk, sommige mensen willen gewoon vastigheid.

Het is vaak fascinerend om te zien hoe zo'n overduidelijk ongezonde omgeving zichzelf magistraal in balans houdt en probleemloos overleeft. De orgie van drammende managers, hackende prutsers en klanten.zonder kennis van IT blijft toch een hele vruchtbare. Een programmeur die bij een ander bedrijf wordt gezien als een gevaar voor de mensheid kan daar vaak ook uitgroeien tot ultieme held zijn 'pragmatische werkwijze'.

[Reteip]

Hmm, ik begin vanuit de discussie hier te begrijpen waarom de Devvers zo'n hekel hebben aan testen. Het schrijven van tests is saai en geestdodend werk, ik ken dat beeld.

Laten we eerlijk zijn. De meeste niet developers in je omgeving denken ook dat de software ontwikkeling die jij doet ontzettend saai en geestdodend werk is. Ik heb nogal wat fysio therapeuten, financieel controllers, managers en andere niet ICT'ers in mijn vriendengroep en die zijn allemaal overtuigd dat software ontwikkeling rete-saai werk is.

Het tegendeel is echter waar. Als software ontwikkelaar ben ik bezig met design en executie op hetzelfde moment. Heerlijk werk, waarin ik me volledig kan verliezen. Time flies, en ik werk aan geweldige producten waar ik enorm van kan genieten.
Maar een (goede) tester doet hetzelfde. Die is bezig met design en executie op hetzelfde moment. Ook daar kan ik me volledig in verliezen. Heerlijk werk, time flies. Creativiteit ten top, en absoluut genieten.

Toen ik 10 jaar geleden begon als software ontwikkelaar keek ik ook naar testen als een laag geschoolde achterlijke discipline. En eerlijkheidshalve, de testers die ik kende op dat moment hielpen ook niet mee in dat beeld.

Ik vermoed dat het voor een hoop developers (en wellicht ook testers) tijd wordt om eens te proeven en bezig te gaan met iets wat waarde toevoegt aan je team, je organisatie en het product: testen. En dan niet op de manier die ik tegenkwam 10 jaar geleden.

[Coltrui]

Kleine kick. Waar ik nu tegen aanloop als UAT'er is het gebrek aan hardware. We leveren totaalsystemen, waarbij minstens een viertal applicaties simultaan worden gebruikt en concurrent, dus elke applicatie een x aantal maal. Om wille van performantie/concurrencytests lijkt me dat dat toch ook geregeld moet worden.

Hoe is de testopstelling bij jullie hardwarematig geregeld voor UAT'ers? Virtueel? Echt een fysiek station voor elke 'tester'? Andere ideeën?

[Reteip]

Coltrui schreef op donderdag 8 december 2016 @ 22:29:
Kleine kick. Waar ik nu tegen aanloop als UAT'er is het gebrek aan hardware. We leveren totaalsystemen, waarbij minstens een viertal applicaties simultaan worden gebruikt en concurrent, dus elke applicatie een x aantal maal. Om wille van performantie/concurrencytests lijkt me dat dat toch ook geregeld moet worden.

Hoe is de testopstelling bij jullie hardwarematig geregeld voor UAT'ers? Virtueel? Echt een fysiek station voor elke 'tester'? Andere ideeën?

Uiteraard hangt dit heel erg van je context af. Mijn ervaring in de hightech industrie is dat hardware vaak duur is, en ook schaars. Projecten gaan vaak over het totale systeem of modules daarvan, en de eerste prototypes van de elektronica / mechanica komt zo ongeveer tegelijk met de eerste 'prototypes' van de software.

Vaak ontkomt je in dergelijke omgevingen niet aan simulatoren. Of in ieder geval een HAL (Hardware abstraction layer) waar je kunt stubben / mocken. Zeker als je als UATér ook betrokken wilt zijn tijdens de ontwikkeling, en niet als laatste in de rij wilt gaan staan.

Wederom is dit de vraag om Testability. Een vraag die helaas vaak wordt beantwoord in een projectorganisatie met een hoop budgetering en planning. Ik zou zeggen, loop eens naar de ontwikkelaars van het project. Die zijn namelijk ook niet gek en kunnen op een of andere manier wel hun eigen code testen. Wellicht is slim hergebruik daar mogelijk. Waarom niet hun testframework gebruiken om alvast vroeg inzicht te verkrijgen om te voorkomen dat als je het echte systeem tot je beschikking hebt dat je tegen honderden bugs aanloopt.

Ik lees nu dat je op zoek bent naar perfomance / concurrency test opstellingen. Als jij als tester het risico hebt aangegeven en de organisatie is het daar niet mee eens / geeft jou geen testability, dan is het in principe (heel zwart wit gesteld) klaar .. Even afgezien dat de organisatie waarschijnlijk een enorme fout begaat en een gigantisch risico loopt. Maar de impact daarvan aangeven ligt waarschijnlijk bij jou.
Ik zou als het risico groot is nog een paar keer extreem duidelijk aangeven wat het risico en de impact zou kunnen zijn bij een release. En daarin de verantwoordelijkheid expliciet leggen bij degene die verantwoordelijk is (vaak niet de tester).
Vervolgens is het een mooie uitdaging om het risico te mitigeren, of de keus bij de verantwoordelijke om dat niet te doen.
Heb je voor het mitigeren hardware nodig of kun je het goedkoper doen met software is iets waar je waarschijnlijk met wat ontwikkelaars naar zult moeten gaan kijken.

[Coltrui]

Grappig dat je simulators vermeldt.

Ben groot voorstander om hardware die je niet voorhanden hebt en voor input moeten zorgen in je applicaties (weegschalen, return/error codes van labelprinters, etc...) te fingeren met testsoftware. Maar dat kost geld. En voor een bedrijf dat nu eindelijk testen serieus wil nemen, blijkt dat moeilijk te vatten. Gevolg is dat bij indienstname zevenentwintig sirenes en zwaailichten afgaan, wat dan ook geld kost, maar dat wordt dan wel als normaal beschouwd. 't Is moeilijk om degenen die het budget bewaken te overtuigen dat die nieuwe postenkost eigenlijk kosten gaat besparen. Je gaat immers nooit één project tweemaal doen (een maal mét en eenmaal zonder dit soort testen) om de kosten tegenover elkaar te leggen.

En die kost legitimeren, is de muur waar ik nu constant tegenaanloop. Regressietesten? Kost te veel. Unit tests? Kost te veel. Simulators? Kost te veel. Performance/concurrency testen? 'Ja, hallo, we kunnen toch niet een hele firma even stillegen voor extra monkeys?'

Kortom: de gedachte blijft toch een beetje 'We hebben het nooit gedaan, en het is toch altijd goedgekomen.' Ja, tot grote onvrede van de ontwikkelaars die onsite overuren draaien én de onprofessionele indruk die je achterlaat bij de klant. Maar toon dat maar eens aan.

[Verwijderd]

Beste Testers

Met veel belasting heb ik dit draadje gelezen. Echter ben ik ook aan het twijfelen gebracht. Ik heb geen IT achtergrond, enkel wat simpele programmeerkennis (zelfstudie). Ik vind dit heel leuk om te doen, alleen was het lastig om met mijn achtergrond een programmeer traineeship aangeboden te krijgen. Voor detacheerders was een afgeronde technische opleiding een vereiste. Wat wel lukte, na een lange sollicitatieprocedure, is om als junior software tester een 2 jarig traineeship contract aangeboden te krijgen. Mijn vraag is nu; is een stap van software tester naar software ontwikkelaar na 2 of 3 jaar reëel? Heeft iemand ervaring met een soortgelijke stap?

[stefanass]

Verwijderd schreef op dinsdag 3 januari 2017 @ 17:29:
Beste Testers

Met veel belasting heb ik dit draadje gelezen. Echter ben ik ook aan het twijfelen gebracht. Ik heb geen IT achtergrond, enkel wat simpele programmeerkennis (zelfstudie). Ik vind dit heel leuk om te doen, alleen was het lastig om met mijn achtergrond een programmeer traineeship aangeboden te krijgen. Voor detacheerders was een afgeronde technische opleiding een vereiste. Wat wel lukte, na een lange sollicitatieprocedure, is om als junior software tester een 2 jarig traineeship contract aangeboden te krijgen. Mijn vraag is nu; is een stap van software tester naar software ontwikkelaar na 2 of 3 jaar reëel? Heeft iemand ervaring met een soortgelijke stap?

Zo'n overstap is zeker mogelijk, maar dat ligt wel voornamelijk aan jezelf (moeite er in stoppen) en aan de mogelijkheden die je eventueel door je werkgever aangeboden krijgt.

Krijg je van je werkgever bijvoorbeeld de mogelijkheid om jezelf bij te scholen, waardoor je binnen je team langzaam aan mee kan gaan werken als dev, dan is dat natuurlijk een ideaal scenario. Kan dat niet dan zul je vooral zelf aan de slag moeten om jezelf bij te scholen, certificaten te halen etc.

[Marialice]

Verwijderd schreef op dinsdag 3 januari 2017 @ 17:29:
Ik heb geen IT achtergrond, enkel wat simpele programmeerkennis (zelfstudie). Ik vind dit heel leuk om te doen, alleen was het lastig om met mijn achtergrond een programmeer traineeship aangeboden te krijgen. Voor detacheerders was een afgeronde technische opleiding een vereiste. Wat wel lukte, na een lange sollicitatieprocedure, is om als junior software tester een 2 jarig traineeship contract aangeboden te krijgen. Mijn vraag is nu; is een stap van software tester naar software ontwikkelaar na 2 of 3 jaar reëel? Heeft iemand ervaring met een soortgelijke stap?

Alles is mogelijk, maar het is even de vraag of je hiermee een makkelijke route kiest. Worst case kom je voor je eerste opdrachten terecht in een niet-technische opdracht, afhankelijk van hoeveel mensen er op de bank zitten heb je als junior soms niet zoveel te kiezen (en dat geeft ook niet, je moet érgens beginnen). Na 2 jaar heb je dan nog steeds geen technische opleiding, wel wat cursussen en certificaten maar dat is toch anders dan bv hbo informatica, en ben je duurder dan een junior die net van school afkomt. Wél met 2 jaar it-ervaring en goed zicht op kwaliteit, en dat is ook wat waard, maar voor een opdracht waar een hbo it-opleiding een harde eis is kom je dan nog steeds niet in aanmerking.

Dus als je testen echt niet leuk vindt en alleen ziet als tussenstap om daarna te gaan ontwikkelen: niet aan beginnen. Maar testen is gelukkig wél leuk , kwaliteit bewaken, inzicht geven in risico's, zorgen dat in één keer goed wordt gebouwd, etc. Er is ook veel vraag naar testautomatisering, en via die weg is de stap naar ontwikkelaar niet zo groot, ook als technisch tester of automatiseerder schrijf je code en draai je mee in het ontwikkelproces.

[Coltrui]

.

[ Voor 99% gewijzigd door Coltrui op 12-07-2017 07:26 ]

[Marruk]

Ik ben op het moment in de running om als software tester te beginnen. Ik heb al aardig wat informatie opgezocht en ingelezen maar ben eigenlijk op zoek naar iemand die bondige voorbeelden kan geven van logische testgevallen.

Wanneer ik hiernaar zoek kom ik niet echt uit op gewenste voorbeelden en blijft het vooral bij de theorie ipv praktijkvoorbeelden.

[NielsTn]

Marruk schreef op woensdag 26 juli 2017 @ 18:46:
Ik ben op het moment in de running om als software tester te beginnen. Ik heb al aardig wat informatie opgezocht en ingelezen maar ben eigenlijk op zoek naar iemand die bondige voorbeelden kan geven van logische testgevallen.

Wanneer ik hiernaar zoek kom ik niet echt uit op gewenste voorbeelden en blijft het vooral bij de theorie ipv praktijkvoorbeelden.

TMAP/ISTQB opleiding al gehad?

http://www.tmap.net/wiki/test-cases

[Marruk]

NielsTn schreef op woensdag 26 juli 2017 @ 19:04:
[...]

TMAP/ISTQB opleiding al gehad?

http://www.tmap.net/wiki/test-cases

Helemaal niks, thx voor de link

[NielsTn]

Marruk schreef op woensdag 26 juli 2017 @ 22:12:
[...]


Helemaal niks, thx voor de link

Graag gedaan. mocht je dan nog vragen hebben, feel free to ask... (inmiddels al 10+jaar in het testvak, ISTQB full advanced level in de pocket).

[NielsTn]

Recent (juli) een Rapid Software Testing training gevolgd. RST is een context gedreven testaanpak waarvan James Bach en Michael Bolton de inhoud hebben samengesteld.

indrukken:
* daadwerkelijk actief veel (zelf) testen is deel van deze training. Dus naast VEEL slides ook veel interactie.
* Na afloop blijft je zelfs als junior of ervaren tester je koppie gonzen naar meer....
* lekker pragmatisch dus prima in agile vormen in te zetten, incl rapportages (velen afgeleid van heuristics).

meer info:
https://rapid-software-testing.com/
http://www.satisfice.com/
http://www.developsense.com/

dus aanrader

[itons]

NielsTn schreef op donderdag 23 augustus 2018 @ 15:49:
Recent (juli) een Rapid Software Testing training gevolgd. RST is een context gedreven testaanpak waarvan James Bach en Michael Bolton de inhoud hebben samengesteld.

Welke trainer had je? Was dit al het 4.0 materiaal?

[NielsTn]

itons schreef op donderdag 23 augustus 2018 @ 18:43:
[...]


Welke trainer had je? Was dit al het 4.0 materiaal?

Ik had als trainer Huib Schoots. Het 4.0 materiaal zou pas per augustus gebruikt worden, maar is zover ik vernam marginaal bijgewerkt met enige extra info (meer revisie en actualisering).

[itons]

NielsTn schreef op donderdag 23 augustus 2018 @ 20:17:
[...]

Ik had als trainer Huib Schoots. Het 4.0 materiaal zou pas per augustus gebruikt worden, maar is zover ik vernam marginaal bijgewerkt met enige extra info (meer revisie en actualisering).

Ah cool Heb 2x RST gedaan, 1e keer met Huib en James, 2e keer alleen James. Erg leerzaam, maar sommige delen vond ik wat minder toepasbaar op DevOps omgevingen.

[NielsTn]

Binnenkort komen ze naar nederland, eea is in MeetUp te vinden

[NielsTn]

Morgen van start als cursist in ISTQB Advanced level - Test Automation Engineer, een module uit het ISTQB gamma wat redelijk nieuw/recent beschikbaar is gekomen.
Ik zal (als er interesse is) mijn ervaringen hierin dit topic delen. Examen staat overigens op 13 september gepland.

linkje/info naar ISTQB TAE:
Business outcomes

Learning objectives

Syllabus TAE

[ Voor 47% gewijzigd door NielsTn op 29-08-2018 13:44 ]

[NielsTn]

Vanochtend het examen afgelegd van de ISTQB Advanced module Test Automation Engineer.
In een paar kern-woorden:
pittig, lastig, uitgebreid.

Het examen is dit keer op een tablet afgenomen, dit werkte prima (goed wifi-signaal etc).
totaal kreeg ik 40 vragen, en konden maximaal 75 punten gescoord worden. Bij 65% en meer ben je geslaagd.

Initieel de eerste 5 vragen blanco gelaten (ik wist niet zeker wat te kiezen) en na eenmaal in een flow te geraken liep ik op tempo.
Uiteindelijk gemarkeerde en/of overgeslagen vragen alsnog voorzien.
Tactiek:
bij multiple choice op een kladblad een aantal keuzes wegstrepen, en focus op de vaak 2 overgebleven opties/antwoorden (it's all in the details).

uiteindelijk, met ca. 8-9 minuten resterend, maar op 'verzenden' gedrukt..... en na 15 seconden geduld kwam het tablet met de terugkoppeling: Geslaagd, score 75%. #inthepocket
Vrij direct daarna een email met de feedback in de mailbox. Helaas (nog) geen onderverdeling in hoofdgroepen of topics zodat je na afloop een bepaald deel nog eens nader kan bestuderen.
Wie weet, verandert dat nog in de (nabije) toekomst, als er meer examens voorhanden zijn (ISTQB TAE is ca. 5-6 maanden in de markt).

Note: om deel te kunnen nemen, is een ISTQB Foundation certificaat nodig, aangevuld met 36 maanden relevante ervaring (nee, geen type-fout, heb het nogmaals gecontroleerd). Die ervaring is echt nodig om e.e.a. soms in context te kunnen plaatsen/snappen.

update 14-sept: zojuist van iSQI (het examenorgaan) de finale uitslag ontvangen met splitsing naar leerdoelen van de training. Helaas niet de vraag/antwoord. Maar ik heb wel een idee waar de fouten specifiek zaten.

[ Voor 17% gewijzigd door NielsTn op 14-09-2018 13:14 . Reden: feedback exameninstituut toegevoegd. ]

[Mugwump]

NielsTn schreef op donderdag 13 september 2018 @ 15:28:
Vanochtend het examen afgelegd van de ISTQB Advanced module Test Automation Engineer.
In een paar kern-woorden:
pittig, lastig, uitgebreid.

Het examen is dit keer op een tablet afgenomen, dit werkte prima (goed wifi-signaal etc).
totaal kreeg ik 40 vragen, en konden maximaal 75 punten gescoord worden. Bij 65% en meer ben je geslaagd.

Initieel de eerste 5 vragen blanco gelaten (ik wist niet zeker wat te kiezen) en na eenmaal in een flow te geraken liep ik op tempo.
Uiteindelijk gemarkeerde en/of overgeslagen vragen alsnog voorzien.
Tactiek:
bij multiple choice op een kladblad een aantal keuzes wegstrepen, en focus op de vaak 2 overgebleven opties/antwoorden (it's all in the details).

uiteindelijk, met ca. 8-9 minuten resterend, maar op 'verzenden' gedrukt..... en na 15 seconden geduld kwam het tablet met de terugkoppeling: Geslaagd, score 75%. #inthepocket
Vrij direct daarna een email met de feedback in de mailbox. Helaas (nog) geen onderverdeling in hoofdgroepen of topics zodat je na afloop een bepaald deel nog eens nader kan bestuderen.
Wie weet, verandert dat nog in de (nabije) toekomst, als er meer examens voorhanden zijn (ISTQB TAE is ca. 5-6 maanden in de markt).

Note: om deel te kunnen nemen, is een ISTQB Foundation certificaat nodig, aangevuld met 36 maanden relevante ervaring (nee, geen type-fout, heb het nogmaals gecontroleerd). Die ervaring is echt nodig om e.e.a. soms in context te kunnen plaatsen/snappen.

update 14-sept: zojuist van iSQI (het examenorgaan) de finale uitslag ontvangen met splitsing naar leerdoelen van de training. Helaas niet de vraag/antwoord. Maar ik heb wel een idee waar de fouten specifiek zaten.

Ik ben wel benieuwd wat een "theoretisch examen" over automatisch testen je precies oplevert. In mijn ogen is het toch vooral iets wat je in de praktijk moet leren. In het gros van de projecten komt het automatisch testen ook niet van de grond als testers het moeten doen en komt het erop neer dat ik zelf de basis maar weer uit de grond stamp en de testers in ieder geval probeer verantwoordelijk te maken voor het op de juiste wijze aanleveren van de testcases.

[NielsTn]

Mugwump schreef op vrijdag 14 september 2018 @ 19:51:
[...]


Ik ben wel benieuwd wat een "theoretisch examen" over automatisch testen je precies oplevert. In mijn ogen is het toch vooral iets wat je in de praktijk moet leren. In het gros van de projecten komt het automatisch testen ook niet van de grond als testers het moeten doen en komt het erop neer dat ik zelf de basis maar weer uit de grond stamp en de testers in ieder geval probeer verantwoordelijk te maken voor het op de juiste wijze aanleveren van de testcases.

Voor je automatisch testen kan doen zijn er vele aandachtspunten die eerst ingeregeld moeten worden. Gebeurt dat niet dan is de oplossing duur, onbeheer(s)baar, etc.

Ook zaken als metrieken en analyses zijn er onderdeel van. Verder zie de business outcomes en learning goals op eerder gedeelde links.

[NielsTn]

Zijn er nog mensen verder lid van TestNet? Ondergetekende wel

Dinsdag 25 september a.s. wordt trouwens in Eindhoven (Hi tech campus) een avond rondom AI en testen georganiseerd. Meer informatie: https://www.testnet.org/c...plate=objects_agenda_item

Ook altijd leuk om te netwerken en je kennis uit te bouwen.

Ander event is EuroStar, dit jaar 12-15 november a.s. in Den Haag. https://conference.eurostarsoftwaretesting.com/

[ Voor 13% gewijzigd door NielsTn op 21-09-2018 10:01 ]

[TheNephilim]

Even praktisch gezien hè; wat moet ik me precies voorstellen bij wat je doet? Gewoon met iets als phpunit aan de slag, of een andere testsuite?

Zelf ben ik inmiddels aardig aan de slag met TDD zoals dat heet, maar ik merk dat het schrijven van goede tests net zo goed een uitdaging is.

[NielsTn]

TheNephilim schreef op vrijdag 21 september 2018 @ 10:08:
Even praktisch gezien hè; wat moet ik me precies voorstellen bij wat je doet? Gewoon met iets als phpunit aan de slag, of een andere testsuite?

Zelf ben ik inmiddels aardig aan de slag met TDD zoals dat heet, maar ik merk dat het schrijven van goede tests net zo goed een uitdaging is.

Aan wie vraag je dit?

[NielsTn]

Geen reactie vernomen, maar als ik de vraag van @TheNephilim op mij richt:

Momenteel ben ik als consultant ingezet in de rol als test architect voor een embedded automotive oplossing.
Hiervoor ben ik gevraagd een beter agile ontwikkelproces in kaart te brengen en voor te dragen, waarbij o.a. een controleerbare en regelmatige oplevering van features/packages mogelijk is.

Test automatisering is daarbij een key voor quick feedback naar het team developers, en de huidige invulling is verre van onderhoudbaar, beheer(s)baar, en kosten.

Met ISTQB TAE heb ik enkele modellen gebruikt om daar mijn verhaal als praatplaat omheen te hangen.

Welke tools/pakketten uiteindelijk geselecteerd gaan worden, is o.a. afhankelijk van kennis, kosten, fit, en wat men exact wenst te testen. Zolang de teams nog niet in staat zijn een handmatig test script op te leveren op basis van een risico analyse, is dat een van mijn eerste (benoemde) zorgpunten die eerst opgepakt moeten worden.

[Hydra]

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.

[TheNephilim]

NielsTn schreef op woensdag 26 september 2018 @ 12:51:
Geen reactie vernomen, maar als ik de vraag van @TheNephilim op mij richt...

Owh, sorry! Ik las dit 's avonds en dacht; daar reageer ik morgen even op. Maarja, notificatie al op 'gelezen', niet meer aan gedacht etc...

Hydra schreef op woensdag 26 september 2018 @ 13:10:
En nu concreet?

^ Dit! Ik ben vooral benieuwd naar de praktische zaken rondom testen.

[NielsTn]

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.

Grootste euvel is dat het bedrijf 'testers' aanneemt (letterlijk invliegt uit egypte, omdat hun CV tester noemt...) en dan basics niet kunnen uitvoeren/najagen. Ikzelf ben al maanden bezig voor informatie te verzamelen om hen hierin te ondersteunen, doch 'politiek' blockt eea.

Huidige opzet is ook afhankelijk van de interfaces, en de skills van developers om op basis van testbaarheid ons testers wat zaken makkelijker te maken (controllability, monitoring).

Mijn mond is recent 'gesnoerd', omdat de organisatie aangaf niets te willen wijzigen (ondanks dat men dus niet weet /wil weten hoe t testproces dus brak is en hierop anticiperen (en een verre van scrum methodiek respecteerd (wel sprints van een week en scrum master, maar geen DoD, DoR, regressie tactiek, en geen PO). Dus dat heeft impact op oa mijn inzet (ik weiger een seat heater te zijn voor 'op opdracht zitten voor geld te genereren'), en geef ook concreet aan wat rest en wat mijn vervolgstappen zijn (oa : einde opdracht, beschikbaar nieuwe opdracht).

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.

hun manager heeft van mij nadrukkelijk de manco's aangereikt gekregen, die buiten het team liggen. Sterker nog: het zijn meer ontwikkelaars, die verder geen test achtergrond hebben, of een degelijke start-up training hierin. Sterker nog, ik ben op basis van mijn kennis en mijn eigen (oude) cursusmaterialen workshopjes aan het houden (al maanden) om ze some basics bij te brengen. een enkeling is nu actief met boeken zijn ISTQB foundation aan het voorbereiden voor examen later in oktober a.s. Ikzelf wil gaan scripten, maar (gezien het spreekverbod met domain specialists) wordt dus (pro)actief geblocked. En niemand die er verder vanaf weet qua domeinkennis (ja anno nu bestaat dat nog!)

[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 ]