[Software Testen] Algemeen topic

[Coltrui]

Dag Vrinden!

Na 10 jaar dienst als devver en 5 jaar als soft development manager voor hetzelfde bedrijf, ben ik opgezadeld met de functie om een testbeleid te ontwikkelen.

Ik neem aan - nou ja, ik hoop - dat er om T.Net toch een aantal test engineers/managers ronddwalen om ervaringen en tips mee uit te wisselen. Volgens mij wordt daar - jaja, eerlijk gezegd heb ik er ook nooit stil bij gestaan, tot ik me nu in het kruipwereldje van de testers moet begeven - vreemd genoeg weinig aandacht aan besteed.

Wat testen betreft, is er een heleboel om over te palaveren, als u mij mijn Vlaams vergeeft. Doel van dit topic is een beetje meer ruchtbaarheid te geven aan het belang van testen en de manier waarop, en hoewel ik me in /14 in het hol van de leeuw bevindt wat dat betreft - ontwikkelaars komen van Mars, dedicated testers van Venus, wil ik hier wel een soort symbiose bereiken. Uitgangspunt is uiteindelijk toch om kwaliteitssoftware op te leveren toch?

Mijn bedoeling is dus niet dat jullie hier met z'n allen gaan zeggen hoe de ideale testomgeving er uitziet (daar ben ik zelf mee bezig, en ondertussen ben ik erachter dat dat van bedrijf tot bedrijf verschillend is), maar wel om een aantal zaken die wél common ground zijn voor software-houses.

Vandaar deze vragen:

- Wie test er bij jullie? Project manager? Gebruikers? De devver zelf? Een dedicated tester? Wat zijn daarbij de voordelen, wat zijn de kanttekeningen?

- Wanneer wordt er getest? Tussentijds of wanneer een module is afgewerkt? (Lees: werk je in een agile of waterfall omgeving - en heb je in beide situaties gewerkt - wat past wanneer?)

- Automated testen. Is dit enkel goed op product-based companies? Varen project-based companies hier ook bij? Wie schrijft die testen? De ontwikkelaar zelf, of een collega die niks van betreffende area afweet? Wat ga je automated testen en wat niet?

- Hoe wordt coverage van het testplan bepaald? En wie doet dat?

- Hebben jullie (of jullie testers) een vast stramien, of wordt er Context-Driven getest? Wat zijn de voor- en/of nadelen?

- Nog 800 andere vragen. Staat jullie vrij om aan te vullen.

Bedoeling van dit topic is eigenlijk om het belang van testen te bespreken, het hoe in welke situatie testen 'bepalen', welke test tools bruikbaar zijn in welke situatie, en wat wiens verantwoordelijkheid is in de ideale wereld van een ontwikkelingstraject. Wat loopt er mis, wat kan er beter.Eigen specifieke ervaringen en anecdotes zijn welkom - daar leert men uit of is tenminste toch altijd voer voor discussie.

Na de kilo's testliteratuur die ik figuurlijk verorberd heb, weet ik dat Nederland jarenlang het voortouw genomen heeft wat software testing betreft, maar ook dat ze na die verwezenlijking stil zijn blijven staan, waarbij gebrek aan productiviteit tov de huidige testtechnieken het grootste minpunt geworden is. En na diezelfde kilo's, ben ik ervan overtuigd dat testen belangrijk zijn. En ik weet uit ervaring dat het soms niet botert tussen ontwikkelaars en testers. De 'Ready for Retest' optie wordt door devvers veel minder aangeklikt dan de 'Deferred' of 'rejected'-optie. Ook dat mag ter sprake komen.

Kortom, een software test topic. Wat wel, wat niet? Brand los.

[Spoetnik385]

Testen is een kunst.

Mijn voorkeur heeft het om het te laten doen door een gespecialiseerde tester. Het belangrijkste argument daarvoor is dat een andere betrokkene bij de ontwikkeling (al dan niet onbewust) de neiging heeft om naar een resultaat toe te testen. Te snel wordt gedacht "als dit het goed doet, zal dat hiervoor ook wel gelden".

Een persoonlijke ervaring:

• [Tester] : "Als ik %^&$%#$ in het postcodeveld invul krijg ik geen foutmelding"
• [Spoetnik] : "Maar niemand vult %^&$%#$ in in een postcode veld, al helemaal geen automatische interface"
• [Tester] : "Weet je dat zeker? Kun je dat garanderen? Ook in de toekomst?"
• [[Spoetnik]:

En dit dus tig keer in het project.
Zou ik zelf getest hebben, of de betrokken developer, hadden we deze test zeker niet gedaan.

Was wel leerzaam....

[Coltrui]

Oe, je bent een geweldige getuige wat mij betreft

Testen is inderdaad een vak, daar ben ik als ex-ontwikkelaar en na kilo's literatuur hoe langer hoe meer van overtuigd. Ik heb jarenlang zelf dienst gedaan als devver. En ikzelf vind validators - want dat is toch wat je aanhaalt - érg belangrijk. Teslotte is je klant de belangrijkste stakeholder en mag die als eerste niet op de zenuwen gewerkt worden. Ik zeg niet dat wat jij nu aanhaalt het niveau aangeeft wat de klant ergert (hoewel er klanten zijn die in acceptatiemodus juist dit soort fratsen gaan uithalen), maar er zijn wel andere euvels die die richting ingaan.

Wat nu erg vaak voorkomt:

- De gebruiker een datum/tijd laten invullen mbv een edit veld ipv een datetimepicker
- Geen validatie op max/min length maar een crash van de applicatie.webpagina wanneer die boundary in overflow gaat
- Weinig of geen controle op het type veld dat aan de back end verwacht wordt

Dus ga ik hier even op inhaken, want dit is een goede. Hoe moeten testers hier mee omgaan? Moet dit mbv Unit Tests opgevangen worden? Is het de verantwoordelijkheid van de ontwikkelaar of die van de tester om dit soort zaken te voorkomen?
Hebben jullie GUI conventions?

[ Voor 19% gewijzigd door Coltrui op 11-11-2016 21:28 ]

[ThomasG]

Spoetnik385 schreef op vrijdag 11 november 2016 @ 21:14:
Testen is een kunst.

Mijn voorkeur heeft het om het te laten doen door een gespecialiseerde tester. Het belangrijkste argument daarvoor is dat een andere betrokkene bij de ontwikkeling (al dan niet onbewust) de neiging heeft om naar een resultaat toe te testen. Te snel wordt gedacht "als dit het goed doet, zal dat hiervoor ook wel gelden".

Een persoonlijke ervaring:

• [Tester] : "Als ik %^&$%#$ in het postcodeveld invul krijg ik geen foutmelding"
• [Spoetnik] : "Maar niemand vult %^&$%#$ in in een postcode veld, al helemaal geen automatische interface"
• [Tester] : "Weet je dat zeker? Kun je dat garanderen? Ook in de toekomst?"
• [[Spoetnik]:

En dit dus tig keer in het project.
Zou ik zelf getest hebben, of de betrokken developer, hadden we deze test zeker niet gedaan.

Was wel leerzaam....

Zulke dingen kun je voor een groot deel opvangen in een unit test. Daar test je natuurlijk niet alleen of het werkt bij correcte invoer (wat helaas teveel voor komt), maar ook het gedrag bij (opzettelijk) foutieve invoer.

[Coltrui]

ThomasG schreef op vrijdag 11 november 2016 @ 21:28:
[...]
Zulke dingen kun je voor een groot deel opvangen in een unit test. Daar test je natuurlijk niet alleen of het werkt bij correcte invoer (wat helaas teveel voor komt), maar ook het gedrag bij (opzettelijk) foutieve invoer.

Worden UT bij jullie geschreven door de ontwikkelaar zelf? Zo ja, is dat 'veilig'? Ik bedoel in mijn overtuiging (en nu ga ik iets stouts zeggen) dat ontwikkelaars de slechtste testers zijn van eigen source, kan je daarop vertrouwen?

[Ventieldopje]

Coltrui schreef op vrijdag 11 november 2016 @ 21:23:
Oe, je bent een geweldige getuige wat mij betreft

Testen is inderdaad een vak, daar ben ik als ex-ontwikkelaar en na kilo's literatuur hoe langer hoe meer van overtuigd. Ik heb jarenlang zelf dienst gedaan als devver. En ikzelf vind validators - want dat is toch wat je aanhaalt - érg belangrijk. Teslotte is je klant de belangrijkste stakeholder en mag die als eerste niet op de zenuwen gewerkt worden. Ik zeg niet dat wat jij nu aanhaalt het niveau aangeeft wat de klant ergert (hoewel er klanten zijn die in acceptatiemodus juist dit soort fratsen gaan uithalen), maar er zijn wel andere euvels die die richting ingaan.

Wat nu erg vaak voorkomt:

- De gebruiker een datum/tijd laten invullen mbv een edit veld ipv een datetimepicker
- Geen validatie op max/min length maar een crash van de applicatie.webpagina wanneer die boundary in overflow gaat
- Weinig of geen controle op het type veld dat aan de back end verwacht wordt

Dus ga ik hier even op inhaken, want dit is een goede. Hoe moeten testers hier mee omgaan? Moet dit mbv Unit Tests opgevangen worden? Is het de verantwoordelijkheid van de ontwikkelaar of die van de tester om dit soort zaken te voorkomen?
Hebben jullie GUI conventions?

De ontwikkelaar moet het voorkomen, de unit test moet garanderen dat dit ook gebeurt is

[Mercatres]

Bij ons* is testen een belangrijk aspect van onze "Definition of Done". Ten eerste moeten de acceptatie criteria van het ticket of de story duidelijk opgesteld zijn, de taak van de functioneel analist dus. Indien mogelijk mogen zelfs al de specificaties gelinkt zijn.
De volgende stap is dan dat de ontwikkelaar in kwestie aan de slag gaat. Afhankelijk van de voorkeur van de ontwikkelaar schrijft deze eerst de nodige unit tests, anders komen die achteraf. Bij het unit testen draait het niet om de code coverage want dat zegt amper iets, maar veel meer of het functioneel wel klopt. Deze moeten dan ook goed beschrijven wat er getest wordt, indien mogelijk met een referentie naar een spec.
Tijdens de code review wordt er uiteraard ook naar de unit testen gekeken. Pull requests worden bekeken door andere developers, vooral seniors of mensen met specifieke kennis van dat onderwerp. Een fout die we proberen te voorkomen is dat er aan de ontwikkelaar van het ticket om uitleg gevraagd wordt, in plaats van zelf proberen te begrijpen wat de bedoeling is en zelf tot een oplossing te komen. Dit klinkt in eerste instantie als dubbel werk, maar zorgt wel voor kwalitatief betere code.
Als de PR goedgekeurd is, wordt deze door de functioneel analisten bekeken en al dan niet afgesloten. Aan het einde van een sprint, gaat de ontwikkelde versie naar Test en zal daar nog eens door functioneel analisten en product owners getest worden. Ook QA kijkt daar dan nog eens naar. Indien dat dan ook in orde is, gaat dat naar Acceptatie, zodat het getest kan worden door klanten. Als er dan naar een release toe gaat worden er door ons QA systeem allerlei Test-runs klaar gezet, die al dan niet al eens uitgevoerd zijn in eerdere releases, maar die mogelijk wel impacted zijn.

*Ons = Cloud software bedrijf in de medische sector.

Coltrui schreef op zaterdag 12 november 2016 @ 11:43:
[...]


Worden UT bij jullie geschreven door de ontwikkelaar zelf? Zo ja, is dat 'veilig'? Ik bedoel in mijn overtuiging (en nu ga ik iets stouts zeggen) dat ontwikkelaars de slechtste testers zijn van eigen source, kan je daarop vertrouwen?

Om daar even op in te pikken: ja. Bij ons wel. We verwachten zelfs dat in elke PR (nu ja, tenzij het om een kleine lay-out wijziging gaat) UTs heeft.
Het grote voordeel van unit tests is dat bij een refactoring alles nog zou moeten werken. Als de spec verandert kan je dat ook zien in je UTs.

[ Voor 15% gewijzigd door Mercatres op 12-11-2016 14:07 ]

[Coltrui]

Code review, Unit Tests, 'dubbel werk' - klinkt als veel overhead

Ik ben zelf ondertussen heel erg overtuigd van het feit dat dit op lange termijn rendeert, mijn management echter niet. Hoe ga je daarmee om?


Een andere vraag waar ik mee zit - mijn job als tester is issues aankaarten. Het probleem dat ik daarbij (collegiaal gezien dan) ondervind is tweeledig:

- Ik ben een lul volgens de ontwikkelafdeling
- Ik word verantwoordelijk geacht wanneer er bugs optreden na release

Iemand daar een frisse kijk op? Ontwikkelaars die me kunnen duiden hoe iets 'voorzichtig' aangekaart moet worden? Liefst persoonlijk, of doe maar een bug report? Testers die datzelfde gevoel hebben - of hadden en daar een oplossing voor gevonden hebben?

[ Voor 28% gewijzigd door Coltrui op 11-01-2017 07:40 ]

[Mercatres]

Tja, het ligt natuurlijk ook een deel bij de mentaliteit van het team of het bedrijf in het algemeen. Ieder bedrijf maakt natuurlijk kritische software, maar wij moeten volgens bepaalde procedures werken (ook volgens het onlangs behaalde ISO-certificaat). Bij ons speelt ook wel mee dat we als start-up ook zo begonnen zijn, met de nodige aandacht voor validatie en testing. Het helpt ook wel dat de markt niet zo heel snel is, en zelf ook om die validatie vraagt.

[itons]

Leuk topic

Coltrui schreef op zaterdag 12 november 2016 @ 14:18:
Code review, Unit Tests, 'dubbel werk' - klinkt als veel overhead

Ik ben zelf ondertussen heel erg overtuigd van het feit dat dit op lange termijn rendeert, mijn management echter niet. Hoe ga je daarmee om?

Opvoeden, opvoeden, opvoeden. Dialoog aangaan, experiment starten en laten zien dat het werkt.

Coltrui schreef op zaterdag 12 november 2016 @ 14:18:
Een andere vraag waar ik mee zit - mijn job als tester is issues aankaarten. Het probleem dat ik daarbij (collegiaal gezien dan) ondervind is tweeledig:

- Ik ben een lul volgens de ontwikkelafdeling
- Ik word verantwoordelijk geacht wanneer er bugs optreden na release

Iemand daar een frisse kijk op? Ontwikkelaars die me kunnen duiden hoe iets 'voorzichtig' aangekaart moet worden? Liefst persoonlijk, of doe maar een bug report? Testers die datzelfde gevoel hebben - of hadden en daar een oplossing voor gevonden hebben?

1) Waarom vind je de ontwikkelafdeling je niet aardig?
Hoe komt dat? Kan me voorstellen dat het te maken heeft met de manier waarop je mensen benaderd? Er zijn veel mensen in de IT werkzaam met een 'handleiding', ik heb mijzelf aangeleerd om de manier waarop ik findings bij de ontwikkelaars aangeef aanpas op de persoon waar ik mee te maken heb. Daar zijn ruwweg verschillende types in te vinden:

Type persoon	Aanpak
Iemand waar je goed mee op kan schieten en graag feedback mondeling ontvangt	Ik spring op vanachter mijn scherm, roep heel hard "HAHA, sukkel, nu heb ik je!" en vertel hem dat ik een bug heb gevonden in een stuk dat hij heeft geschreven en dat ik verwacht dat er binnen 5 minuten een nieuwe build op de testomgeving staat.
Iemand waar je goed mee op kan schieten en die graag feedback op zijn gemakje doorneemt	Ik geef even mondeling aan dat ik iets gevonden heb wat ik niet kan verklaren en stuur een linkje naar het JIRA issue. Daarin staat netjes een reproductie pad, welke testdata ik heb gebruik en waar ik zelf denk dat het aan ligt
Iemand waar je goed mee op kan schieten en die graag overtuigt wordt van het feit dat hij een foutje heeft zitten in zijn code	Ik vraag de ontwikkelaar om even mee te kijken, want ik probeer zus-en-zo te doen met functionaliteit X, maar ik "kom er niet uit". Ik doorlopen samen met hem het reproductiepad en op het moment dat de bug optreedt zeg ik "Snap er echt niets van". Zo heeft hij het gevoel dat hij mij wat kan uitleggen en laten zien, zonder dat het kritiek is op zijn werk.

Met deze strategie in het achterhoofd kun je, zoals je ziet, goed met iedereen op schieten en help je de ontwikkelaar om effectief te zijn, met in achtname van zijn of haar beperkingen op sociaal vlak. Alternatieve variant is dat ik de code zelf fix en een merge request indien...

2) Verantwoordelijk voor bugs na release
De aard van bugs is juist dat ze verborgen zijn en dat het onmogelijk is om te zeggen dat een product geen bugs meer bevat.

Testing shows the presence, not the absence of bugs. Dijkstra (1969) J.N. Buxton and B. Randell, eds, Software Engineering Techniques, April 1970, p. 16.

Om jou als tester verantwoordelijk te houden hiervoor is onterecht. Immers als tester bewaak je geen kwaliteit (QA), maar geef je inzicht in de kwaliteit doormiddel van de testen die je uitvoert. De beslissing of iets goed genoeg is om live mee te gaan is niet aan jou, jij adviseert hierin. Lees deze post van James Bach eens zou ik zeggen: http://www.satisfice.com/blog/archives/652

[Coltrui]

Ben jij tester of devver?

Lijkt me van belang - er heerst altijd een soort spanning tussen beide partijen en dit oplossen op onze werkvloer is een van mijn betrachtingen.

En over Bach gesproken: ik ben momenteel een van zijn boeken aan het lezen (nou ja, in co-auteurschap met andere testgrootheden) en ben hoe langer hoe meer fan van de context-driven approach.

[itons]

Coltrui schreef op zaterdag 12 november 2016 @ 15:04:
Ben jij tester of devver?

Lijkt me van belang - er heerst altijd een soort spanning tussen beide partijen en dit oplossen op onze werkvloer is een van mijn betrachtingen.

En over Bach gesproken: ik ben momenteel een van zijn boeken aan het lezen (nou ja, in co-auteurschap met andere testgrootheden) en ben hoe langer hoe meer fan van de context-driven approach.

Tester. Ik prijs mezelf gelukkig dat bij ons dit spanningsveld helemaal niet bestaat. We werken in Scrumteams en iedereen gaat er voor om samen een kwalitatief goede applicatie neer te zetten. Scrumteams krijgen bij ons veel vrijheid hoe ze hun applicatie willen bouwen, hoe hun proces eruit ziet en ik merk dat op het moment dat mensen die vrijheid krijgen ze bijna automatisch ook een verantwoordelijkheidsgevoel ontwikkelen en trots zijn op het werk dat ze doen. Dat komt de kwaliteit ten goede.

[Coltrui]

Heerlijk, een tester. Laat je horen, en ook devvers nodig ik uit om hetzelfde te doen. Nu ik zelf in deze positie geraakt ben, besef ik dat er op T.Net geen aandacht wordt besteed aan testen, terwijl deze job, IT-gewijs, toch belangrijk is

Bovenstaande sterkt me in mijn idee om het testen - waar bij ons nu weinig aandacht aan wordt besteed - te verdelen in twee delen. Enerzijds moet er awareness komen bij de ontwikkelaars (dan denk ik aan validators, GUI conventions, etc) en anderzijds zoek ik - afhankelijk van het soort opdracht - een soort Master Test Plan op te stellen om perfect in te spelen op de requirements. Geen keurslijf (vast template wat test reporting betreft, nooit vasthouden aan dezelfde tools) waar het project in moet passen, maar andersom: pas je testproduct aan aan waar het project/product nood aan heeft.

[ Voor 10% gewijzigd door Coltrui op 12-11-2016 15:22 ]

[Rmg]

Coltrui schreef op zaterdag 12 november 2016 @ 11:43:
[...]


Worden UT bij jullie geschreven door de ontwikkelaar zelf? Zo ja, is dat 'veilig'? Ik bedoel in mijn overtuiging (en nu ga ik iets stouts zeggen) dat ontwikkelaars de slechtste testers zijn van eigen source, kan je daarop vertrouwen?

Een unit test is naar mijn mening voor en door de Developer, ze zeggen ook niets over de werking van het complete systeem.


Aparte testers hebben zeker een voordeel bij whitebox testen alleen dan m.i. wel pas bij systeem en integratie testen.

Het postcode voorbeeld is imo ook iets wat je niet bij een tester pas had hoeven vinden, zeker met de spec "postcode, Nederlands" dan is input niet checken gewoon lui developen . Met een (gereviewde) UT had het niet eens een issue geweest. Je input niet checken is sowieso erg 2014

[Smuggler]

Ik ben ook tester.
Gespecialiseerd in de hightech / embedded hoek van software.
denk aan de volgende producten waar ik aan gewerkt heb:
Flow meters
Klimaat beheersingssystemen voor gebouwen en kassen
Vergader systemen

Het gaat dan vaak om producten met veel mogelijkheden en waar een software fout voor tonnen schade kan zorgen.
Geen meterstanden, een gebouw dat "uit" staat, of een vergadering die niet door kan gaan.
En in het geval van de flowmeters zijn updates zeer prijzig of onmogelijk.
Je wilt dus een zo goed mogelijk product in de markt hebben waar je achteraf geen kosten meer voor hebt.
Veel standaarden worden al afgevangen in elektrische standaarden, maar voor EMC zijn er ook software matige ingrepen nodig, zoals automatisch herstel als er toch interferentie is opgetreden.
Op veel afdelingen waar ik heb gezeten zie je een verhouding van 1:1 tot 1:3 van testers:Developers.
Naar mijn mening werkt 1:1 tot 1:2 het beste, met 1:3 ga je achter de feiten aanlopen.

Over het algemeen heb je het bij testen over een aantal dingen.
Unit tests. (developer, kan dedicated zijn)
Component tests (developer).
Functionals, (tester)
Non functionals. (tester)
User Experience (tester + buitenstaanden) of UX expert.


1 van de taken als tester is om een aantal zaken van de non-functionals continue te meten en te monitoren,
Opstart snelheid van het systeem.
Schaalbaarheid.
stabiliteit onder stress.
Security.

Dit zijn allemaal automatische testen die door de testers zijn ontwikkeld en zijn opgezet, en ze zijn er ook verantwoordelijk voor dat deze testen met regelmaat worden gedraaid. De ontwikkelaars horen vanzelf wanneer er iets begint af te wijken.

Verder worden alle functionele testen ook geautomatiseerd op het moment dat ze ontwikkeld worden, dit loopt synchroon, soms zijn de testen eerder klaar, soms is de software eerder klaar.
Wij als testteam proberen elk mogelijk pad te bedenken en dit te vangen in testcases.

maar automatische scripts vinden alleen dingen waar je van te voren op checkt.
Dus hebben we ook nog exploratory testen, waarbij we een onderdeel uitzoeken en daar met de hand van alles uitproberen, dit rouleren we door het team, iedereen werkt anders met een systeem en let op andere dingen, op die manier vangen we de belangrijkste dingen wel meteen, maar de moeilijkere dingen soms pas wat iteraties later, al is het maar omdat iemand een venster via een andere weg opent.

Ook komt de user nog erbij, deze moet snappen wat er gemaakt is, met een team ben je vaak een jaar bezig om iets te maken. en beginnen dingen heel logisch te lijken, maar dat hoeft het voor de buiten wereld dus totaal niet te zijn.

Een tester neemt dus al deze dingen mee. van te voren afgesproken via een testplan zodat duidelijk is wat er wel en niet wordt afgedekt,
Non functionals:
Duurtest maken: ja / nee : 3 dagen.
Duurtest draaien: ja / nee : elke week 2 uur.
Stresstest maken : ja / nee : 4 dagen
Stresstest draaien: ja / nee: elke week 1 uur.

Functional:
Framework opzetten voor automatische tests: ja/nee: 2 weken.
Framework onderhouden: ja/nee: 4 uur per week.

Functie 1:
Manuele test maken: 8 uur.
Test automatiseren: 8 uur.
Testen draaien: 30 minuten per week.


enz enz. op die manier zet je uiteen wat je allemaal kan gaan doen, en wat je uiteindelijk niet doet.
Het is niet erg om iets niet te doen, als er maar een duidelijke beslissing is genomen en de gevolgen duidelijk zijn. geen duurtest is een groter risico dat het ding vastloopt na X aantal draai uren. Dat kan best acceptabel zijn maar zet het op papier ondertekend.
Anders weten ze je als tester zo te vinden als het mis gaat.

Communicatie is het leukste van het vak, iedere ontwikkelaar moet je anders benaderen.
sommige kan ik benaderen met: hey dit is fout!, en dat wordt dan perfect opgepakt enzo.
Een andere gaat met zo'n opmerking totaal in de verdediging en voelt zich persoonlijk zwaar aangevallen, zo iemand kan je beter erbij betrekken en dan samen praten over de functionaliteit en laten zien hoe het op dit moment werkt.
En vele variaties alle kanten op.

De manier van testen agile/waterfall hangt vaak af van het process erom heen, zorg in elk geval ervoor dat testers / ontwikkelaars in dezelfde ruimte zitten zodat ze van elkaar weten waar ze mee bezig zijn en met elkaar gaan communiceren, aparte test afdelingen heb ik nooit echt efficiënt zien werken.

Automatische testen: Ja absoluut doen als je de mogelijkheid krijgt, op termijn levert dat zoveel op.
sowieso probeer een automatische test te maken voor de nonfunctionals, zodat je trends kan gaan volgen.

Test Coverage is altijd een dingetje: afhankelijk van hoe je elke test benaderd heb je altijd 0,001% coverage en 100% coverage.

Maar ook met 100% code coverage hoeft je functionaliteit nog niet de juiste te zijn.
Benoem vooral wat je wel en niet gaat doen en hoe je de testen aanpakt en welke test technieken je gaat gebruiken. Ja aan coverage kan je harde cijfers hangen, maar die cijfers moeten ook nog juist geïnterpreteerd worden.

Uiteindelijk heeft het ontwikkelteam gezamenlijk 1 doel, en dat is software op de markt te zetten om trots op te zijn. gedoe tussen ontwikkelaars en testers heb je dus niets aan.

En ontwikkelaars helpen de testers natuurlijk met het ontwikkelen van de juiste stubs en drivers om (automatisch) testen makkelijker te maken.


heb nu ongeveer 1% geschreven van wat ik wil delen, de andere 99% deel ik wel als het topic een beetje begint te lopen , en verhaal is niet in 1 stuk geschreven dus het loopt niet lekker door nu ik het terug las.

[Feanathiel]

Even hoe dat bij ons gebeurd, wellicht van toepassing, maar misschien ook wel totaal niet.

Coltrui schreef op zaterdag 12 november 2016 @ 14:18:
Code review, Unit Tests, 'dubbel werk' - klinkt als veel overhead

Ik ben zelf ondertussen heel erg overtuigd van het feit dat dit op lange termijn rendeert, mijn management echter niet. Hoe ga je daarmee om?

Wat helpt is het inzichtelijk te maken. Dit kun je bijvoorbeeld doen door aan te geven hoeveel tijd je nodig hebt om 'eenmalig' de (unit)tests te schrijven, en wat het kost om het systeem telkens opnieuw door te kammen bij elke wijziging die je doet.

Coltrui schreef op zaterdag 12 november 2016 @ 14:18:

Een andere vraag waar ik mee zit - mijn job als tester is issues aankaarten. Het probleem dat ik daarbij (collegiaal gezien dan) ondervind is tweeledig:

- Ik ben een lul volgens de ontwikkelafdeling
- Ik word verantwoordelijk geacht wanneer er bugs optreden na release

Iemand daar een frisse kijk op?

Fouten worden overal gemaakt, de kracht zit 'm in wanneer je ze vind. Probeer eens samen te gaan zitten als je de feature ontwikkeld of liever nog wat eerder, vast van te voren samen bepalen welke delen er stuk zouden kunnen gaan door de wijziging die dev probeert te doen. Samen verantwoordelijk zijn voor het deel, want ook hij/zij had deze fout kunnen zien komen toen deze persoon een wijziging deed. Probeer geen muurtjes op te trekken tussen de disciplines, houdt elkaar op de hoogte. Laat ze eventueel ook testen als het blijkt dat je de sprint (?) niet probeert te halen. Dan heb je alsnog stukken gewoon afgerond, en blijft niet alles zomaar open staan.

[bwerg]

Smuggler schreef op zaterdag 12 november 2016 @ 21:38:
Test Coverage is altijd een dingetje: afhankelijk van hoe je elke test benaderd heb je altijd 0,001% coverage en 100% coverage.

Maar ook met 100% code coverage hoeft je functionaliteit nog niet de juiste te zijn.
Benoem vooral wat je wel en niet gaat doen en hoe je de testen aanpakt en welke test technieken je gaat gebruiken. Ja aan coverage kan je harde cijfers hangen, maar die cijfers moeten ook nog juist geïnterpreteerd worden.

Ik zag laatst een praatje van iemand die onderzoek deed naar het verband tussen code coverage en daadwerkelijke kwaliteitsgarantie. Hij had wat opensourceprojecten met unit tests genomen, en gekeken hoeveel coverage ze haalden. Allemaal 80+%, heel mooi. Daarna voor elke methode in het project de method body leeggegooid (eventueel return null om de compiler blij te maken) en gekeken of de tests daarover klaagden: bij sommige projecten werden alle aanpassingen gevonden, bij één project werd helemaal niks gevonden. De test suite was blij te maken met compleet lege code. Die unit tests werden puur geschreven om door code heen te lopen maar er werd niks aan output gecontroleerd, het zou alleen exceptions vinden. Wel een mooie eye-opener: 80% code coverage, en je test bijna helemaal niks.

Dat was trouwens een introductie op mutation based testing, waarbij je juist kijkt naar wat voor soort fouten je nou eigenlijk vindt. Wel nog puur academisch, maar de ideëen en onderbouwing geven wel aan dat hersenloos blij zijn als je 100% code coverage hebt gehaald ook totaal nog niet is wat je wil.

En andersom, klagen dat je geen 100% coverage hebt: wil je echt per sé een unit test schrijven voor elke getter?

[ Voor 18% gewijzigd door bwerg op 13-11-2016 16:05 ]

[Coltrui]

Rmg schreef op zaterdag 12 november 2016 @ 15:58:
[...]


Een unit test is naar mijn mening voor en door de Developer, ze zeggen ook niets over de werking van het complete systeem.


Aparte testers hebben zeker een voordeel bij whitebox testen alleen dan m.i. wel pas bij systeem en integratie testen.

Het postcode voorbeeld is imo ook iets wat je niet bij een tester pas had hoeven vinden, zeker met de spec "postcode, Nederlands" dan is input niet checken gewoon lui developen . Met een (gereviewde) UT had het niet eens een issue geweest. Je input niet checken is sowieso erg 2014

Loop je dan niet het gevaar dat de devver dezelfde fouten gaat maken of dezelfde zaken over het hoofd gaat zien dan dingen die in de code tot bugs leiden? Maw: is het niet moeilijk om zelf politieagent te gaan spelen van je eigen doen en laten?


---


Ik sprak dan wel van unit tests, maar ik bedoel automated testen tout court. Klinkt misschien vreemd, misschien ook niet, maar de meest vervelende zaken die ik als prille tester tegenkom, zijn (mijns inziens!) te wijten an luiheid/onervarenheid/vergetelheid van de ontwikkelaar. Dat er bugs naar voor komen wanneer stukken, ontwikkeld door verschillende mensen, bij elkaar komen voor een test, dat snap ik en dat wil ik graag testen. Maar dan is er ook nog dit, en dat is mijn eerste zorg om dat er wat uit te krijgen - ik wil graag stapje per stapje werken:

- Validatiecontrole (veldtype/lengte, verplichte velden check etc…)
- Component converties – wanneer een edit, wanneer een datetimpepicker, wat laten we standaard toe bij grids (sorteren/filteren/groeperen,...)
- Inconsequentie in GUI conventies: huisstijl, taborders, universele sneltoetsen, icoongebruik…
- ...

Zaken als deze wil ik als tester gewoon niet zien - ik denk dat die zich met wat minder triviaals moeten gaan bezighouden. En zaken zoals punt 1 zijn toch te automatisch te testen, lijkt me? De andere twee punten moeten gedrilld en gedocumenteerd worden, dat begrijp ik wel. Of stel ik me nu aan en is dat nu juist wel de taak van de tester?

Ander veel voorkomende probleem is dat er na een bugfix ergens in het proces - op het eerste gezicht ogenschijnlijk op een plaats waar de ontwikkelaar niet eens is aangeweest - iets in de prak draait. Regression fails, zeg maar. Moet je die niet automatiseren? Zo ja, hoe en vooral wanneer in het proces ga je die beschrijven en implementeren? Na de eerste fail, of ineens meenemen tijdens de technisch conceptbepaling?

[ Voor 21% gewijzigd door Coltrui op 13-11-2016 17:27 ]

[Smuggler]

Coltrui schreef op zondag 13 november 2016 @ 17:25:
[...]
Zaken als deze wil ik als tester gewoon niet zien - ik denk dat die zich met wat minder triviaals moeten gaan bezighouden. En zaken zoals punt 1 zijn toch te automatisch te testen, lijkt me? De andere twee punten moeten gedrilld en gedocumenteerd worden, dat begrijp ik wel. Of stel ik me nu aan en is dat nu juist wel de taak van de tester?

Het is maar net waar je je test capaciteit wilt inzetten.
Vaak gaat het bij zulke dingen toch fout, ontwikkelaars denken dat je het alleen intypt, maar wat nu als je de tekst erin plakt: ctrl-v
Overload, signed/unsigned getallen, wat als je een chinese naam wilt invoeren etc etc.
Het is prima om een tester daarop te zetten om al die uitzonderingen en grenzen op te zoeken.

Zie ook de eerste reactie in dit topic ongeveer.
Je kan ook besluiten je hier niet op te richten. en wees daar duidelijk over en communiceer dit ook naar de ontwikkelaars .
Mijn advies, check juist op dat soort dingen, kosten vegeleken met de logica die er vaak achter zit relatief weinig tijd, en je kan er eigenlijk altijd wel iets vinden als tester. Bij ons zijn dit handmatige tests, aangezien we van mening zijn dat daar geen regressie optreed door onze opzet in de huidige software.
En veel testen we hiervan impliciet door dit mee te nemen tijdens andere testen waar we toch al iets moesten invoeren in die velden.

Ander veel voorkomende probleem is dat er na een bugfix ergens in het proces - op het eerste gezicht ogenschijnlijk op een plaats waar de ontwikkelaar niet eens is aangeweest - iets in de prak draait. Regression fails, zeg maar. Moet je die niet automatiseren? Zo ja, hoe en vooral wanneer in het proces ga je die beschrijven en implementeren? Na de eerste fail, of ineens meenemen tijdens de technisch conceptbepaling?

Wij maken alles tijdens het maken van elke feature meteen over dat onderwerp automatische tests,
Doordat dit vanaf het begin gedaan is zijn er heel veel automatische testen die de regressie bewaken.
Als we een bug vinden achteraf, wordt er terplekke besloten om er een automatische test voor te maken. we doen een kleine analyse, hebben we een heel gebied niet afgedekt? dan maken we een automatische test. is dit toevallig 1 pad dat we gemist hebben, dan gaan we daar geen automatische test voor schrijven. tenzij dit echt 5 minuten werk is .


Heb je al gedacht aan een test framework, waar je testen kan aftrappen, aan en achter elkaar kan hangen?
En waar je een mooi dagelijks overzicht krijgt van de statussen.

Kan je eens delen aan wat voor soort product/project je werkt?

[Coltrui]

Smuggler schreef op zondag 13 november 2016 @ 18:34:
[...]

Het is maar net waar je je test capaciteit wilt inzetten.
Vaak gaat het bij zulke dingen toch fout, ontwikkelaars denken dat je het alleen intypt, maar wat nu als je de tekst erin plakt: ctrl-v
Overload, signed/unsigned getallen, wat als je een chinese naam wilt invoeren etc etc.
Het is prima om een tester daarop te zetten om al die uitzonderingen en grenzen op te zoeken.

Weet je wat het is? Het komt al-tijd terug. Al-tijd dezelfde bugs. Er moet nu onderhand een standaard pakket zijn dat dit automatisch test en dan zonder hard coded values (max length, max lenght + 1, min length, min length - 1, etc) maar op basis van de metadata die je uit je back end kan halen?
Automated testen moet je enkel doen als het nut heeft, en mijns inziens heeft dit voor ons bedrijf erg veel nut. Maar als ik elders de meningen zo lees, zit dit soort testen inderdaad bij een manuele tester - ik stel het hier maar in vraag

Zie ook de eerste reactie in dit topic ongeveer.
Je kan ook besluiten je hier niet op te richten. en wees daar duidelijk over en communiceer dit ook naar de ontwikkelaars .
Mijn advies, check juist op dat soort dingen, kosten vegeleken met de logica die er vaak achter zit relatief weinig tijd, en je kan er eigenlijk altijd wel iets vinden als tester. Bij ons zijn dit handmatige tests, aangezien we van mening zijn dat daar geen regressie optreed door onze opzet in de huidige software.
En veel testen we hiervan impliciet door dit mee te nemen tijdens andere testen waar we toch al iets moesten invoeren in die velden.

Kan ik inkomen. Maar ze zijn zo testrovend en volgens mij (zelfs dynamisch, op basis van metadata) te automatiseren, eenmalig en herbruikbaar voor elk ander project dus.

Wij maken alles tijdens het maken van elke feature meteen over dat onderwerp automatische tests,
Doordat dit vanaf het begin gedaan is zijn er heel veel automatische testen die de regressie bewaken.
Als we een bug vinden achteraf, wordt er terplekke besloten om er een automatische test voor te maken. we doen een kleine analyse, hebben we een heel gebied niet afgedekt? dan maken we een automatische test. is dit toevallig 1 pad dat we gemist hebben, dan gaan we daar geen automatische test voor schrijven. tenzij dit echt 5 minuten werk is .

Ik neem aan dat hier de ervaring/kennis van de tester aan bod komt. Er moet uiteraard nog een uitdaging zijn

Heb je al gedacht aan een test framework, waar je testen kan aftrappen, aan en achter elkaar kan hangen?
En waar je een mooi dagelijks overzicht krijgt van de statussen.

Tuurlijk. Maar ik ben (voorlopig) wel zinnens om projecten niet in een testkeurslijf te proppen, maar wel andersom, de testaanpak aan te passen aan het project. Heb jij het overigens over een ALM zoals VS TFS, of bedoel je wat anders?

Kan je eens delen aan wat voor soort product/project je werkt?

Ik werk momenteel nog aan niks specifieks. Ik moet de lijnen wat uitzetten wat testen betreft. Maar onze projecten zijn erg veelzijdig, veelal client/server applicaties. Client side kan web based zijn, WPF op Win CE of Android (Xamarin) voor mobile devices. Server side services (WCF) op MSSQL. Ook hebben we een aantal 'black boxes', producten dus, waar ontwikkelaars dedicated aan werken en GUI niet van belang is. Ook daar zouden we een en ander moeten doen qua testen, maar dit dan meer gericht op stress- en performancegebied.

[Smuggler]

Coltrui schreef op zondag 13 november 2016 @ 19:16:
[...]


Weet je wat het is? Het komt al-tijd terug. Al-tijd dezelfde bugs. Er moet nu onderhand een standaard pakket zijn dat dit automatisch test en dan zonder hard coded values (max length, max lenght + 1, min length, min length - 1, etc) maar op basis van de metadata die je uit je back end kan halen?
Automated testen moet je enkel doen als het nut heeft, en mijns inziens heeft dit voor ons bedrijf erg veel nut. Maar als ik elders de meningen zo lees, zit dit soort testen inderdaad bij een manuele tester - ik stel het hier maar in vraag

Als jij de metadata daarvoor kan gebruiken is dat handig!, maar wat nu als jouw programma deze metadata gebruikt om te controleren wat er wel en niet doorgelaten mag worden. Test je dan of de metadata juist wordt gebruikt, of dat de metadata juist is?
Ja er zijn genoeg tools die dit kunnen checken.
Zoek even rond op internet . maar denk erover na of je het de juiste test .

Kan ik inkomen. Maar ze zijn zo testrovend en volgens mij (zelfs dynamisch, op basis van metadata) te automatiseren, eenmalig en herbruikbaar voor elk ander project dus.

Gebruik een test framework .

Ik neem aan dat hier de ervaring/kennis van de tester aan bod komt. Er moet uiteraard nog een uitdaging zijn

Tuurlijk. Maar ik ben (voorlopig) wel zinnens om projecten niet in een testkeurslijf te proppen, maar wel andersom, de testaanpak aan te passen aan het project. Heb jij het overigens over een ALM zoals VS TFS, of bedoel je wat anders?

Met een framework heb ik het letterlijk over een tool waar je de testen in schrijft / opslaat.
Wat bedoel je met een testkeurslijf?.
ik denk dat je me niet helemaal snapt.

Je kan een hoop test dingetjes doen met kleine programma's als je die opdeelt in kleine bruikbare stukken kan je heel makkelijk veel testen.

Voorbeeld:

Losse Programma's:

Startprogramma.
Login -username -password
Loguit
pressbutton -button
readfield -field -expected_answer
Selectfield -field
Putvalue -value

In een goed framework kan je het volgende doen.
Test_inschrijven_goodflow1
- Start_Programma
- Login -admin -wachtwoord
- readfield -username -admin
- Selectfield -adres
- Putvalue -adress -hier al mijn adress gegevens om het kort te houden
- pressbutton -profiel_opslaan.
- read_field -main -"uw profiel admin is met succes opgeslagen"

Test_Programma_printen
- "Test_inschrijven_goodflow1"
- pressbutton -printen

Echt een framework waar je alles in kan hangen, als je op een moment niet alles van zo'n test kan automatiseren dan kan je makkelijk manuele dingen ertussen hangen
- manuele_check -"kijk of er iets uit de printer is gerold met deze gegevens....."

En daar maak je een automatische pop-up van op je scherm. De test voert alle stappen uit, enkel de visuele check op de printer doe je dan nog zelf.

Als je gewoon met testen wilt beginnen is een simpel bug tracking systeem prima om mee te beginnen, zo krijg je snel in beeld waar er echt behoefte aan is.
Heb zelf goede ervaring met "mantis" om een bug tracking systeem te introduceren.
Maar er zijn vele soorten.
http://www.thegeekstuff.com/2010/08/bug-tracking-system

Als je al een ALM achtige tool hebt in huis kan je dit natuurlijk prima gebruiken voor je test tracking.
Ik heb nooit met VS TFS gewerkt tot nu toe.

De tools die ik voor test registeratie heb gebruikt tot nu toe zijn:
Mantis (alleen test registratie), Fitnesse (test registratie + automation), Jira (ALM). Polairion (ALM) en Excel (Geen aanrader tenzij er echt niets anders beschikbaar is in de eerste week )
Zoek hier een tool die bij je organisatie past, het is een hulpmiddel geen doel!. heb je al iets draaien waar je het in kwijt kan, gebruik dat dan en neem tijd om het in te richten.

Als je het niet weet durf ik mantis wel aan te raden, dan heb je binnen een dag draaien en iedereen kan daar makkelijk zijn ei kwijt. Het helpt je in alle basisbehoefte voor test registratie en laat je duidelijk zien na een half jaartje waar er echt behoefte aan is.

Ik werk momenteel nog aan niks specifieks. Ik moet de lijnen wat uitzetten wat testen betreft. Maar onze projecten zijn erg veelzijdig, veelal client/server applicaties. Client side kan web based zijn, WPF op Win CE of Android (Xamarin) voor mobile devices. Server side services (WCF) op MSSQL. Ook hebben we een aantal 'black boxes', producten dus, waar ontwikkelaars dedicated aan werken en GUI niet van belang is. Ook daar zouden we een en ander moeten doen qua testen, maar dit dan meer gericht op stress- en performancegebied.

Dit geeft een stuk meer context aan je vragen . allemaal niet echt mijn specaliteiten.
Robotium voor android testen. .
website testen zijn te veel tools voor , en ik heb het nooit hoeven doen dus ik ga je niets aanbevelen, misschien anderen in dit topic?
een GUI is natuurlijk niet vereist om te willen testen.
Zonder Gui is testen vaak makkelijker omdat je al direct met de backoffice kan praten omdat er geen GUI tussen zit , en je hoeft de GUI niet te checken. betekent niet dat je zonder GUI geen input hoeft te controleren voordat je het verwerkt.


Al overwogen om iemand tijdelijk (1 week tot 1 maand) in te huren om de situatie ter plekke te bekijken, zodat die persoon voor je op een rijtje kan zetten wat je denkt nodig te hebben en daar een juiste inschatting voor kan maken. (tools / automation / testplan / prioriteiten / risico's) krijg de indruk dat er veel op je af komt en dat je door de bomen het bos niet meer ziet .


Hebben jullie trouwens al een risico analyse gedaan op producten in ontwikkeling?
Dan kan een goede input zijn voor je testplan .

[ Voor 4% gewijzigd door Smuggler op 13-11-2016 21:45 ]

[Coltrui]

Smuggler schreef op zondag 13 november 2016 @ 21:41:
[...]

Als jij de metadata daarvoor kan gebruiken is dat handig!, maar wat nu als jouw programma deze metadata gebruikt om te controleren wat er wel en niet doorgelaten mag worden. Test je dan of de metadata juist wordt gebruikt, of dat de metadata juist is?
Ja er zijn genoeg tools die dit kunnen checken.
Zoek even rond op internet . maar denk erover na of je het de juiste test .

Nee, ik ga ervanuit dat de metadata klopt uiteraard. Want die kan veranderen na een RFC en dan moet de front end mee, toch?

Gebruik een test framework .

Met een framework heb ik het letterlijk over een tool waar je de testen in schrijft / opslaat.

Als we scripted testen opmaken gebeurt dat met Testuff. Niet zo wild over, wegens omslachtigheid waarmee je test cases moet opstellen. Wordt louter gebruiktomdat het een plugin heeft voor Youtrack, wat wij tijdens onwtikkeling gebruiken om bugs te registreren.

Wat bedoel je met een testkeurslijf?.
ik denk dat je me niet helemaal snapt.

Met keurslijf bedoel ik een vast stramien waarin het hele testgebeuren moet gebeuren. Waar je project - ongeacht de requirements - maar in moet passen omdat je juist die tools gebruikt. Dat werkt volgens mij niet. Misschien een link naar waar ik toe neig: Context driven testing approach. Nogmaals: ik zeg niet dat dat heilig is, maar het komt voor mij wel in de buurt.

Je kan een hoop test dingetjes doen met kleine programma's als je die opdeelt in kleine bruikbare stukken kan je heel makkelijk veel testen.

Voorbeeld:

Losse Programma's:

Startprogramma.
Login -username -password
Loguit
pressbutton -button
readfield -field -expected_answer
Selectfield -field
Putvalue -value

In een goed framework kan je het volgende doen.
Test_inschrijven_goodflow1
- Start_Programma
- Login -admin -wachtwoord
- readfield -username -admin
- Selectfield -adres
- Putvalue -adress -hier al mijn adress gegevens om het kort te houden
- pressbutton -profiel_opslaan.
- read_field -main -"uw profiel admin is met succes opgeslagen"

Test_Programma_printen
- "Test_inschrijven_goodflow1"
- pressbutton -printen

Echt een framework waar je alles in kan hangen, als je op een moment niet alles van zo'n test kan automatiseren dan kan je makkelijk manuele dingen ertussen hangen
- manuele_check -"kijk of er iets uit de printer is gerold met deze gegevens....."

En daar maak je een automatische pop-up van op je scherm. De test voert alle stappen uit, enkel de visuele check op de printer doe je dan nog zelf.

Als je gewoon met testen wilt beginnen is een simpel bug tracking systeem prima om mee te beginnen, zo krijg je snel in beeld waar er echt behoefte aan is.
Heb zelf goede ervaring met "mantis" om een bug tracking systeem te introduceren.
Maar er zijn vele soorten.
http://www.thegeekstuff.com/2010/08/bug-tracking-system

Als je al een ALM achtige tool hebt in huis kan je dit natuurlijk prima gebruiken voor je test tracking.
Ik heb nooit met VS TFS gewerkt tot nu toe.

De tools die ik voor test registeratie heb gebruikt tot nu toe zijn:
Mantis (alleen test registratie), Fitnesse (test registratie + automation), Jira (ALM). Polairion (ALM) en Excel (Geen aanrader tenzij er echt niets anders beschikbaar is in de eerste week )
Zoek hier een tool die bij je organisatie past, het is een hulpmiddel geen doel!. heb je al iets draaien waar je het in kwijt kan, gebruik dat dan en neem tijd om het in te richten.

Als je het niet weet durf ik mantis wel aan te raden, dan heb je binnen een dag draaien en iedereen kan daar makkelijk zijn ei kwijt. Het helpt je in alle basisbehoefte voor test registratie en laat je duidelijk zien na een half jaartje waar er echt behoefte aan is.

Daar ben ik me ondertussen van bewust - en ik heb geen of weinig ervaring wat testen betreft (alhoewel ik vind dat ik vroeger vrij bugvrije software opleverde, net omdat ik nogal analytisch ben en me altijd en overal afvroeg wat er waar mis kon gaan) - maar het zou kunnen helpen om voorbeelden te zien van welke tool voor welk soort tests nuttig kan zijn (zoals je hieronder Mantis vernoemt ) want daar heb ik minder kaas van gegeten. Ik lees me te pletter, maar hoop hier in detail te kunnen brainstormen over zulke zaken

Jira, Bug Trach, You Track, die systemen gebruiken we wel, maar dat zijn rapporteringssystemen. Een project/productgebonden aanpak is naar wat ik lees iets groter dan dat. Hoe je een project aanpakt, zou volgens kenners (oa Bach) afhangen van volgende vragen:

Wie test?

Dat kan een dedicated tester zijn, een PM, maar ook de klant. Duidelijk dat dit de testaanpak beïnvloedt.

Coverage: wat gaan we testen?

Performantie? GUI? Alles? (En ook: wat gaan we niet testen!)

Potentiële problemen/risico’s: waarom gaan we testen?

Waar hebben we schrik voor – waar denken we dat het fout kan lopen en op zo’n manier dat de KPI’s van de gebruiker in gevaar komen? Wat zijn de requirements waar de klant (of belangrijkste stakeholder) op hamert? Dat is eigenlijk de belangrijkste vraag – context driven testen is uitgaan van het feit dat alles testen onmogelijk is, en dat je je concentreert op de requirements/KPI’s.

Activities: Hoe testen?

Exploratory? Automated? Scripted? Scenario testing? Performance? Combinatie? Welke oracles gaan we gebruiken?

Evaluatie: Hoe gaan we bepalen of een test al dan niet geslaagd is? Hoe ziet het rapport/testproduct er uit?

Unit Tests? Oracle based? Manueel? Datadriven? En hoe gaan we rapporteren – moet het een testplan zijn of volstaat een bugrapport? Volstaan items in YT? Is dat resultaat voor intern gebruik, of wil de klant een rapport? In dat laatste geval kan een internationale standaard gekozen worden (IEEE 829 of TMap).

En afhankelijk van de antwoorden op deze vragen, ga je per project/testopdracht de aanpak bepalen. Dus niet gewoon zeggen 'we gebruiken Jira, punt', want dat prop je het testgebeuren in dat keurslijf dat ik eerder vernoemde

Om maar aan te geven op welk niveau ik hier als leek ondertussen op zoek ben naar een goede aapak - kan goed zijn dat ik te hard van stapel loop, maar het lijkt mij tot nu toe wel een erg zinnige way to go. En jullie moegen me uitlachen als ik er volledig naastzit - liever zo, dan dat ik in de verkeerde richting blijf zoeken

[Smuggler]

Elke vraag is bijna topic waardig.
En het zijn echt goede vragen.
Even de vergelijking met de auto trekken.
Je vraagt hier om van a naar b te komen.
Maar je weet nog niet eens of je dat lopend (jij zelf) fietsend (project manager) of met auto(1 dedicated tester) gaat afleggen
Stel je neemt de auto.
Dan heb je nog geen idee of je een smart of een audi rs8 nodig hebt om de klus te klaren.
Op het forum gaan wij ons richten op de bagage ruimte en de maandelijkse kosten. Terwijl jij luxe betrouwbaarheid en juist 7 zitplaatsen wilt inplaats van die bagage ruimte.

Ik zie jira niet als keurslijf. Elke tool kan je zo inrichten dat dit het project het beste past. (Zorg dat je deze rechten hebt in xd tool om dat aan te passen). En gebruik alleen wat nodig is.
Het keurslijf zit hem meer in de afspraken.
- wordt elke bug geregisteerd.
- spreek je af dat elk defect een flow volgt of vrijheid blijheid
Extreem voorbeeld:
New defect: tester
Ready for first analyse: tester
Eerste analyse bezig: tester
Eerste analyse afgerond: tester.
Beslissing doorgaan: ccb
Ready for analyse voor ontwikkelaar: ccb
Analyse ontwikkelaar: developer
Beslissing oplossing: architect
Ready for problem solving: architecht
Problem solving: ontwikkelaar
Problem solved: ontwikkelaar
Fix ready for review: ontwikkelaar.
Problem reviewed: andere ontwikkelaar.
Ready voor test: tester
Testing: tester
Tested: ontwikkelaar
Committed: tester
Done: tester.

Al deze stappen kan je vast leggen in elke tool. Met de rechten wie een defect mag doorzetten naar een volgende stap... dit werkt echt verschikkelijk.

Meestal gebruik je de volgende stappen en zijn die voor iedereen beschikbaar de tool als hulpmiddel gebruiken en niet als doel :
New
Analysed
Fixed
Tested


Heb beiden meegemaakt.
Maar een tool zorgt aan die kant vaak niet voor een keurslijf, maar de instellingen ervan wel.


Een testplan helpt je met rapporteren.
Maar wat wil je gaan rapporteren? Alle gevonden en opgeloste defects?
Alle openstaande defects?
Test coverage.

Voor een klant volstaat een release met openstaande defects en bug fixes.
Die hoeven niet te weten wat er geintroduceerd en meteen opgelost is tussen verschillende releases.
Engels/nederlands.

Een test slaagt bijna altijd. Het resultaat kan je een mening over hebben.
Je hebt meestal 2 assen. Technisch en businnes kant.
Bedrijfsnaam verkeerd gespelt: business catastrofaal maar technisch geen probleem.
Logfiles worden overschreven: technisch major impact. Business boeit het niet.

Voor ander dingen hebben we toch meer input nodig zodat we niet alle mogelijkheden hoeven door te spreken.
Wat is je belangrijkste vraag op dit moment? Dan kunnen we van daaruit uitbouwen en je verder helpen.


Dit soort berichten moet ik voortaan achter een laptop schrijven en niet op een 4 inch telefoon...
In de loop van de week meer antwoorden van mij, als er anderen niet met dezelfde antwoorden komen.

[ Voor 3% gewijzigd door Smuggler op 13-11-2016 22:55 ]

[Coltrui]

Ik ga bovenstaande, nu ik je eerste regels gelezen heb, morgen dieper tot me laten indringen. Ik wil nu al zeggen dat ik besef dat dit topic erg zwaar en chaotisch is en dat representeert mijn zoektocht. Chaotisch en niet weten waar beginnen.

Daarentegen wil ik dit topic niet om mijn zoektocht doen draaien en dus ruimte laten voor iedereen - testers, ontwikkelaars of eender welke stakeholder van welk product ook. Het is echter moeilijk om vraag en antwoord - ontsproten uit rechtstreekse conversaties - voor iedereen van nut te laten zijn. Ik ga daar hier wat op letten, want ik wil niemand afschrikken - wat mij betreft (egoïstisch standpuntalert!) vind ik dat er op T.NET weinig aandacht wordt besteed aan de kunst van het testen.

(Het kriebelt wel om er niet meteen op in te gaan, want ik vind alle input geweldig om lezen en erg leerrijk, zelfs na 16 jaar in het ontwikkelwereldje.)

[ Voor 13% gewijzigd door Coltrui op 13-11-2016 22:59 ]

[Smuggler]

Coltrui schreef op zondag 13 november 2016 @ 22:04:
Nee, ik ga ervanuit dat de metadata klopt uiteraard. Want die kan veranderen na een RFC en dan moet de front end mee, toch?

aannames , tijd dat jullie een tester aannemen tip: waar komt zo'n RFC vaak vandaan?

code:

functie:
int optellen(int een, int twee){
    return een + twee + 1;
}
aanroep:
antwoord = optellen(3, 4);

Test:
If (antwoord == optellen(3,4)){
     Test = "passed"
}

Ik geloof echt dat deze test gaat slagen .
Zelfs als ik optellen(3.1, 4) uitvoer, zal het in een aantal gevallen gewoon slagen.
Een test engineer moet kijken wat de echte uitkomst moet zijn.

code:

Test:
If (7 == optellen(3,4)){
    Test = "passed"
    }

en 
If(NULL == optellen(3.1,4){
    Test = "passed"
    }

Hoop dat de pseudocode je een beetje helpt om te begrijpen wat ik bedoel , verder is het maandag ochtend dus goede voorbeelden liggen nog achterin mijn hoofd te slapen.

Als we scripted testen opmaken gebeurt dat met Testuff. Niet zo wild over, wegens omslachtigheid waarmee je test cases moet opstellen. Wordt louter gebruiktomdat het een plugin heeft voor Youtrack, wat wij tijdens onwtikkeling gebruiken om bugs te registreren.

Ik ken Youtrack en Testuff niet. Maar het is handig dat er al dingen in place zijn, ga dat eerst gebruiken en kijk of dit genoeg is voor de testers of dat het ze echt tegenwerkt. Ga niet opnieuw het wiel uitvinden en na een jaar erachter komen dat je 10 verschillende tools moet onderhouden, maar pas de tools zo aan dat het past bij je test omgeving. Ga er in elk geval nu geen tijd aan besteden, richt je op het testplan en wat je straks allemaal wilt waarborgen met je testers?

Met keurslijf bedoel ik een vast stramien waarin het hele testgebeuren moet gebeuren. Waar je project - ongeacht de requirements - maar in moet passen omdat je juist die tools gebruikt. Dat werkt volgens mij niet. Misschien een link naar waar ik toe neig: Context driven testing approach. Nogmaals: ik zeg niet dat dat heilig is, maar het komt voor mij wel in de buurt.

ben ik helemaal met je eens

Jira, Bug Trach, You Track, die systemen gebruiken we wel, maar dat zijn rapporteringssystemen. Een project/productgebonden aanpak is naar wat ik lees iets groter dan dat. Hoe je een project aanpakt, zou volgens kenners (oa Bach) afhangen van volgende vragen:

Wie test?

Dat kan een dedicated tester zijn, een PM, maar ook de klant. Duidelijk dat dit de testaanpak beïnvloedt.

Coverage: wat gaan we testen?

Performantie? GUI? Alles? (En ook: wat gaan we niet testen!)

Potentiële problemen/risico’s: waarom gaan we testen?

Waar hebben we schrik voor – waar denken we dat het fout kan lopen en op zo’n manier dat de KPI’s van de gebruiker in gevaar komen? Wat zijn de requirements waar de klant (of belangrijkste stakeholder) op hamert? Dat is eigenlijk de belangrijkste vraag – context driven testen is uitgaan van het feit dat alles testen onmogelijk is, en dat je je concentreert op de requirements/KPI’s.

Activities: Hoe testen?

Exploratory? Automated? Scripted? Scenario testing? Performance? Combinatie? Welke oracles gaan we gebruiken?

Evaluatie: Hoe gaan we bepalen of een test al dan niet geslaagd is? Hoe ziet het rapport/testproduct er uit?

Echt de juiste vragen, maar deze vragen zijn zeer klant specifiek.
De vraag gaat steeds meer naar waar moet je beginnen.
Begin met een risico analyse. (de vraag voor testen komt immers ook ergens vandaan).
http://www.examenvragen.i...productrisicoanalyse.html
Wikipedia: Failure mode and effects analysis
Wikipedia: Fault tree analysis

verschillende mogelijkheden,
Misschien helpt dit je nog om je te laten kijken naar de verschillende onderdelen van het project:
Wikipedia: ISO 9126
Zodat je dan helder kan krijgen waar je naar opzoek bent en welke risico's je met het bedrijf wilt verkleinen.

Ik denk als je hier naar gaat kijken en dat gaat uitwerken je zelf een beeld krijgt wat er allemaal gedaan dient te worden, vervolgens ga je de dingen langzaam stuk voor stuk invullen

---

Waar komt de vraag voor tester eigenlijk opeens vandaan?
Heeft het management iets gehoord?
Klagen jullie klanten over de kwaliteit?
Willen de ontwikkelaars dat?
willen de aandeelhouders dat?
Iemand aangenomen die uit een omgeving met testers komt?
ziet het PM risico's?
is er opeens budget vrij?

ect ect

[ Voor 3% gewijzigd door Smuggler op 14-11-2016 07:45 ]

[bwerg]

Nu dit topic er trouwens toch is, zijn er hier mensen die naar de Nederlandse testdag gaan vrijdag?

[itons]

bwerg schreef op zondag 13 november 2016 @ 15:22:
[...]
Dat was trouwens een introductie op mutation based testing, waarbij je juist kijkt naar wat voor soort fouten je nou eigenlijk vindt. Wel nog puur academisch, maar de ideëen en onderbouwing geven wel aan dat hersenloos blij zijn als je 100% code coverage hebt gehaald ook totaal nog niet is wat je wil.

Er zijn heel veel frameworks die mutation based testing mogelijk maken, inderdaad, voorheen academisch, omdat er teveel permutaties mogelijk zijn, maar mocht je op de JVM werken dan is pitest.org een framework dat realistisch ingezet kan worden om mutation testing te doen, doordat ze allerlei slimmigheden hebben om het maken van mutations heel snel te maken (bytecode aanpassen i.p.v. hercompileren, als ik het goed herinner.)

[Coltrui]

Zijn er mensen wier werkgever hier geld voor over hebben gehad? https://dojo.ministryoftesting.com/
Ik heb de free 'sessions' bekeken en voor mij toch wel een schat van informatie. (Nog zo'n sites?)

[Hydra]

Coltrui schreef op vrijdag 11 november 2016 @ 17:02:
- Wie test er bij jullie? Project manager? Gebruikers? De devver zelf? Een dedicated tester? Wat zijn daarbij de voordelen, wat zijn de kanttekeningen?

Het schrijven van tests wordt door de devs gedaan. Het "doen" van tests wordt dus door software gedaan. Ik geloof niet in handmatig testen. Je ziet elke keer dat het, omdat het saai en repetitief is, omvalt omdat delen overgeslagen worden.

- Wanneer wordt er getest? Tussentijds of wanneer een module is afgewerkt? (Lees: werk je in een agile of waterfall omgeving - en heb je in beide situaties gewerkt - wat past wanneer?)

Continue. Het is een onderdeel van onze delivery pipeline. Ik kan niks op dev krijgen zonder tests te draaien, laat staat productie. Dit geldt overigens voor unit/integration tests. Onze volledige end-to-end tests draaien apart (omdat die werkende gedeployde software nodig hebben). Deze e2e tests werken ook als smoke-tests dus draaien continue.

Ter info: "waterfall" is een term die gegeven is aan het afwezig zijn van een proces. Het is dus geen proces. Helaas hebben veel waterfall consultants nooit het paper daadwerkelijk gelezen.

- Automated testen. Is dit enkel goed op product-based companies? Varen project-based companies hier ook bij? Wie schrijft die testen? De ontwikkelaar zelf, of een collega die niks van betreffende area afweet? Wat ga je automated testen en wat niet?

Ik snap het onderscheid tussen product/project based niet. Het is nog steeds software. En wat we automated testen: bij voorkeur alles.

- Hoe wordt coverage van het testplan bepaald? En wie doet dat?

Ik geloof niet in testplannen gegeven door "test managers". Deze mensen weten nooit genoeg over de inhoud om hier de juiste keuzes in te kunnen maken. De devs weten dit wel.

Na de kilo's testliteratuur die ik figuurlijk verorberd heb, weet ik dat Nederland jarenlang het voortouw genomen heeft wat software testing betreft, maar ook dat ze na die verwezenlijking stil zijn blijven staan, waarbij gebrek aan productiviteit tov de huidige testtechnieken het grootste minpunt geworden is. En na diezelfde kilo's, ben ik ervan overtuigd dat testen belangrijk zijn. En ik weet uit ervaring dat het soms niet botert tussen ontwikkelaars en testers. De 'Ready for Retest' optie wordt door devvers veel minder aangeklikt dan de 'Deferred' of 'rejected'-optie. Ook dat mag ter sprake komen.

Kun je dit statement onderbouwen?

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?

Ik ben SOA-vrij gelukkig.

[ Voor 78% gewijzigd door Hydra op 15-11-2016 11:43 ]

[Reteip]

Coltrui schreef op maandag 14 november 2016 @ 22:44:
Zijn er mensen wier werkgever hier geld voor over hebben gehad? https://dojo.ministryoftesting.com/
Ik heb de free 'sessions' bekeken en voor mij toch wel een schat van informatie. (Nog zo'n sites?)

Zeker, kijk eens op :
http://www.satisfice.com/
of https://www.improveqs.nl/kenniscentrum/

Benader testen zeker als een vak, waarin je skills moet gaan aanleren en trainen. Het stopt niet acceptatie / validatie of iets 'werkt', testen gaat een stuk verder. En geloof mij, dat is niet zo simpel als het lijkt.

Bij de meeste bedrijven waar ik kom worden testen uitgevoerd door 'validators'. In mijn ogen het wat traditionele testen, waarbij hele testcases worden geschreven om te valideren of het product doet wat het (volgens de tester/testmanager/testarchitect or whatever) zou moeten doen. Hoewel dergelijke checks nuttig zijn is deze manier van 'testen' in mijn ogen makkelijk vervangbaar door geautomatiseerde checks.

Testen is meer dan dat. Testen is in mijn ogen inzicht verkrijgen/geven in de status van het product onder test. Dat inzicht verkrijg je door een combinatie van verschillende technieken, methodes en benaderingen. Welke dat zijn bepaal je in je strategie. En die strategie wordt beïnvloed en bepaald door je context. Kijk bijvoorbeeld eens naar deze lijst van zaken die een test sessie en aanpak kunnen beïnvloeden:

the mission of the test project
the mission of this particular test session
the role of the tester
the tester (skills, talents, and preferences)
available tools and facilities
available time
available test data and materials
available help from other people
accountability requirements
what the tester’s clients care about
the current testing strategy
the status of other testing efforts on the same product
the product, itself
its user interface
its behavior
its present state of execution
its defects
its testability
its purpose
what the tester knows about the product
what just happened in the previous test
known problems with it
past problems with it
strengths and weaknesses
risk areas and magnitude of perceived risk
recent changes to it
direct observations of it
rumors about it
the nature of its users and user behavior
how it’s supposed to work
how it’s put together
how it’s similar to or different from other products
what the tester would like to know about the product
(bron : http://www.satisfice.com/articles/et-article.pdf)

Elk van bovenstaande items heeft weer een ton aan mogelijkheden waaruit een strategie wordt bepaald, en zo zijn er nog veel meer aandachtsgebieden waar je naar zou kunnen kijken.

[Coltrui]

Hydra schreef op dinsdag 15 november 2016 @ 11:36:
[...]


Het schrijven van tests wordt door de devs gedaan. Het "doen" van tests wordt dus door software gedaan. Ik geloof niet in handmatig testen. Je ziet elke keer dat het, omdat het saai en repetitief is, omvalt omdat delen overgeslagen worden.

Daar ben ik het niet mee eens. Er zijn volgens mij veel zaken die bij een je manuele test ontdekt, simpelweg omdat automated testen net automated en dus te beperkt (kunnen) zijn. Zo kan het manueel gebruiken van de software leiden tot nieuwe ideeën ('Hmm, dat zit dus zo - wat gebeurt er als ik het nu eens zo zou doen?') - het creëren van nieuwe inzichten dus die mijns inziens niet kan automatiseren. Ook heb je zaken als bijvoorbeeld progressieve performantiedaling tijdens gebruik.

Continue. Het is een onderdeel van onze delivery pipeline. Ik kan niks op dev krijgen zonder tests te draaien, laat staat productie. Dit geldt overigens voor unit/integration tests. Onze volledige end-to-end tests draaien apart (omdat die werkende gedeployde software nodig hebben). Deze e2e tests werken ook als smoke-tests dus draaien continue.

Ter info: "waterfall" is een term die gegeven is aan het afwezig zijn van een proces. Het is dus geen proces. Helaas hebben veel waterfall consultants nooit het paper daadwerkelijk gelezen.

Geen idee over welk paper je het hebt, maar eenieder die het niet gelezen heeft, bedoelt met de watervalmethode de strakke opeenvolging van afgelijnde projectstappen. Analyse - technisch ontwerp - implementatie - testen - inproductiename etc, toch?

Ik snap het onderscheid tussen product/project based niet. Het is nog steeds software. En wat we automated testen: bij voorkeur alles.

Dat is nochtans een groot verschil - ook naar testen toe. Ik kan me vorstellen dat het aantal automated testen bij productontwikkeling een veel groter aandeel heeft dan de manuele. Een product wordt namelijk aan meerdere klanten verkocht (dat is althans de bedoeling) zodat dit veel onderheviger is aan upgrades/extra features wegens veel meer gebruikers en dus noden. Een project is software op maat, die na oplevering veel minder upgrades zal vereisen, want het product is precies zoals de klant het gevraagd heeft. Kosten/baten gezien, is extensief automatiseren van testen minder interessant. Zo zijn er nog wel verschillen: deadlines voor oplevering van product, worden intern bepaald, wat meer tijd en ruimte kan scheppen voor het proces, mocht er iets mislopen. Bij een klant die maatwerk bestelt, is dat veel moeilijker en in geval van subsidie quasi onmogelijk. En als je deadline in het gedrang komt, ga je selectief te werk op elk niveau.

Ik geloof niet in testplannen gegeven door "test managers". Deze mensen weten nooit genoeg over de inhoud om hier de juiste keuzes in te kunnen maken. De devs weten dit wel.


[...]


Kun je dit statement onderbouwen?

Ik neem aan dat je mijn bewering over de Dutch School of testing bedoelt? Die ben ik een paar keer tegengekomen. Las oa ergens een artikel waarin een op andere hoge piet van Sysqa (niet met dedain bedoeld, weet zijn naam niet meer ) zelf tot die conclusie kwam, toen hij in Australië over testen sprak en één van de toehoorders hem een kleine sneer gaf - dat hij enkel 'scripted testen' kende, wat normaal was, want hij kwam uit Nederland. Hij zegt zelf dat zijn ogen zijn opengegaan toen hij het werk van oa Kaner en Bach ging bekijken. Maar maakt verder ook niet uit

[Hydra]

Coltrui schreef op dinsdag 15 november 2016 @ 12:27:
Daar ben ik het niet mee eens. Er zijn volgens mij veel zaken die bij een je manuele test ontdekt, simpelweg omdat automated testen net automated en dus te beperkt (kunnen) zijn. Zo kan het manueel gebruiken van de software leiden tot nieuwe ideeën ('Hmm, dat zit dus zo - wat gebeurt er als ik het nu eens zo zou doen?') - het creëren van nieuwe inzichten dus die mijns inziens niet kan automatiseren.

Dat is niet het doel van testen in de technische zin. Een "test panel", dus acceptatie tests, staan hier buiten. En dat is inderdaad logischerwijs manueel.

Ook heb je zaken als bijvoorbeeld progressieve performantiedaling tijdens gebruik.

Wat je prima kunt afdekken in geautomatiseerde tests.

Dat is nochtans een groot verschil - ook naar testen toe. Ik kan me vorstellen dat het aantal automated testen bij productontwikkeling een veel groter aandeel heeft dan de manuele. Een product wordt namelijk aan meerdere klanten verkocht (dat is althans de bedoeling) zodat dit veel onderheviger is aan upgrades/extra features wegens veel meer gebruikers en dus noden. Een project is software op maat, die na oplevering veel minder upgrades zal vereisen, want het product is precies zoals de klant het gevraagd heeft. Kosten/baten gezien, is extensief automatiseren van testen minder interessant. Zo zijn er nog wel verschillen: deadlines voor oplevering van product, worden intern bepaald, wat meer tijd en ruimte kan scheppen voor het proces, mocht er iets mislopen. Bij een klant die maatwerk bestelt, is dat veel moeilijker en in geval van subsidie quasi onmogelijk. En als je deadline in het gedrang komt, ga je selectief te werk op elk niveau.

Je creëert een volledig arbitrair onderscheid. Het product waar ik aan werk wordt ook niet 'hergebruikt'. En er zijn bijzonder weinig projecten waarbij er een echt definitief eindpunt is. En als dat er al is wordt dat meestal pas na vele jaren bereikt. Dus kwaliteit is daar net zo belangrijk. 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.

Een vorig project voor Philips was er een van 3 maanden. Relatief kort dus. Ook daar heb ik de end to end tests volledig geautomatiseerd (een combinatie van een BDD framework en Selenium Webdriver) omdat manueel testen van een applicatie saai is. En wij mensen zuigen in het herhaaldelijk uitvoeren van saai werk.

Ik neem aan dat je mijn bewering over de Dutch School of testing bedoelt? Die ben ik een paar keer tegengekomen. Las oa ergens een artikel waarin een op andere hoge piet van Sysqa (niet met dedain bedoeld, weet zijn naam niet meer ) zelf tot die conclusie kwam, toen hij in Australië over testen sprak en één van de toehoorders hem een kleine sneer gaf - dat hij enkel 'scripted testen' kende, wat normaal was, want hij kwam uit Nederland. Hij zegt zelf dat zijn ogen zijn opengegaan toen hij het werk van oa Kaner en Bach ging bekijken. Maar maakt verder ook niet uit

Dit is een beetje met namen smijten. Ik redeneer vanuit de praktijk. Ik heb genoeg test 'managers' (van o.a. Cap en Xebia) meegemaakt die in het beste geval niks nieuws kwamen vertellen en in het slechtste geval vooral hun eigen frameworks kwamen pushen.

Het bedenken van tests is een onderdeel van je design; dit zijn gewoon je user stories. Een user story kun je een op een vertalen naar een end to end test. Als het goed is heb je ook user stories voor uitzonderingsgevallen (wat doet de app als de verbinding weg is). Deze zaken bedenken is een taak van het hele team (inclusief Customer journey experts, designers en de PO's). Het technisch mogelijk maken van deze tests is de taak van de developers. "Test managers" e.d. zijn dood gewicht; helemaal als je voor hetzelfde geld twee junior devs aan kan nemen.

[Smuggler]

Hydra schreef op dinsdag 15 november 2016 @ 13:27:
"Test managers" e.d. zijn dood gewicht; helemaal als je voor hetzelfde geld twee junior devs aan kan nemen.

Ben ik het absoluut niet mee eens.
Natuurlijk zijn managers overbodig in een klein team. maar zodra je met 10 man zit te testen is een testmanager / testlead / testcoordinator, you name it, al zit er in de litarituur hier grote verschillen tussen. in dat soort omgevingen een must have.
Een aanspreek punt, voor boven af.
Iemand die het overzicht houdt tussen: alle verschillende soorten testen.
Iemand die zorgt dat het testplan wordt opgesteld en uitgevoerd.
enz enz enz.
Een full time job, zodat de testers zich enkel met het testen bezig hoeven te houden en niet met de politiek erom heen.

Ik heb het gevoel hydra dat je nog nooit met een tester hebt gewerkt bij je ontwikkeling, alleen een developer schrijft rot code, en je hebt meer ogen nodig om problemen in de software te vinden.
je eigen vlees keuren is nooit goed voor een product, met testen maak je dan EXACT dezelfde fouten als wat je tijdens de ontwikkeling gedaan hebt.

[Coltrui]

Hydra schreef op dinsdag 15 november 2016 @ 13:27:
[...]


Dat is niet het doel van testen in de technische zin. Een "test panel", dus acceptatie tests, staan hier buiten. En dat is inderdaad logischerwijs manueel.

Waar komt die beperking dat het enkel over testen in technische zin gaat plots vandaan? Ik reageerde op je opmerking dat je niet gelooft in handmatig testen, iets wat ik opvallend vind.

Je creëert een volledig arbitrair onderscheid. Het product waar ik aan werk wordt ook niet 'hergebruikt'. En er zijn bijzonder weinig projecten waarbij er een echt definitief eindpunt is. En als dat er al is wordt dat meestal pas na vele jaren bereikt. Dus kwaliteit is daar net zo belangrijk. 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.

Een vorig project voor Philips was er een van 3 maanden. Relatief kort dus. Ook daar heb ik de end to end tests volledig geautomatiseerd (een combinatie van een BDD framework en Selenium Webdriver) omdat manueel testen van een applicatie saai is. En wij mensen zuigen in het herhaaldelijk uitvoeren van saai werk.

Ja, dat kan jouw ervaring zijn, hier is dat dus anders. Maatwerk wordt minder geautomatiseerd getest dan pakweg de software van het schap of bouwstenen die we hergebruiken en wel om de redenen die ik opnoemde. Dat er bij jou geen verschil is, wil niet zeggen dat het verschillend kan zijn en wel op gegronde redenen.

Dit is een beetje met namen smijten. Ik redeneer vanuit de praktijk. Ik heb genoeg test 'managers' (van o.a. Cap en Xebia) meegemaakt die in het beste geval niks nieuws kwamen vertellen en in het slechtste geval vooral hun eigen frameworks kwamen pushen.

Ik smijt helemaal niet zomaar met namen hoor. Momenteel 'Lessons Learned in Software Testing' aan het lezen, waarvan twee van de drie auteurs de namen dragen die ik hier 'smeet'. Beste boek tot nog toe, waarin de auteurs (ontwikkelachtergrond en daar jaren ervaring in, nu meer aan het spelen met testmethodes) gewoon hun nieuwe/veranderende inzichten beschrijven uit hun praktijkervaring. (En wat jij zegt over test managers, komt daar ook in aan bod, maar iets genuanceerder.)

Het bedenken van tests is een onderdeel van je design; dit zijn gewoon je user stories. Een user story kun je een op een vertalen naar een end to end test. Als het goed is heb je ook user stories voor uitzonderingsgevallen (wat doet de app als de verbinding weg is). Deze zaken bedenken is een taak van het hele team (inclusief Customer journey experts, designers en de PO's). Het technisch mogelijk maken van deze tests is de taak van de developers. "Test managers" e.d. zijn dood gewicht; helemaal als je voor hetzelfde geld twee junior devs aan kan nemen.

Kan je wel testen gaan schrijven, maar als je er in de eerste plaats niet aan denkt om bepaalde functionaliteiten/uitzonderingen in je code te gaan zetten, gaat diezelfde persoon ze niet plots in z'n test case steken. Ik blijf erbij - dat is hier althans zo - dat ontwikkelaars de slechtste testers zijn wanneer het hun eigen code betreft.

[Hydra]

Smuggler schreef op dinsdag 15 november 2016 @ 13:57:
Ben ik het absoluut niet mee eens.
Natuurlijk zijn managers overbodig in een klein team. maar zodra je met 10 man zit te testen is een testmanager / testlead / testcoordinator, you name it, al zit er in de litarituur hier grote verschillen tussen. in dat soort omgevingen een must have.

Ik werk doorgaans op grote projecten en heb nog nooit de rol van "test coordinator" goed ingevuld zien worden door iemand met als job title "test coordinator". Ik hoop dat je begrijpt wat ik bedoel; testen is een vak en onderdeel van het zijn van software engineer. Die rol ligt dus doorgaans bij een dev lead. Het is geen rol waarbij je een op zichzelf staande coordinator nodig hebt. Sterker nog; door het gebrek aan kennis doen die types vaak afbreuk.

Ik heb het gevoel hydra dat je nog nooit met een tester hebt gewerkt bij je ontwikkeling,

Eerder het omgekeerde. Ik heb veel ervaring met "test managers" van o.a. Cap en die waren keer op keer waardeloos. Dus in die projecten was het vaak zo dat de devs de testers moeten gaan ondersteunen in plaats van andersom. Ik heb op een project gezeten waar we het werk van de "test managers" weggeautomatiseerd hadden totdat ze niks anders deden dan Cucumber scripts schrijven. Diezelfde mensen kwamen na maanden met een test plan dat linea recta de prullebak in kon.

Ik heb eerder teveel ervaring met dit soort mensen dan te weinig.

alleen een developer schrijft rot code, en je hebt meer ogen nodig om problemen in de software te vinden.
je eigen vlees keuren is nooit goed voor een product, met testen maak je dan EXACT dezelfde fouten als wat je tijdens de ontwikkeling gedaan hebt.

Dit is waar je peer reviews voor hebt. Nergens heb ik gezegd dat een developer alleen verantwoordelijk is voor al z'n code. Tests is een onderdeel van je deliverable en de verantwoordelijkheid van je team.

Coltrui schreef op dinsdag 15 november 2016 @ 14:02:
Waar komt die beperking dat het enkel over testen in technische zin gaat plots vandaan? Ik reageerde op je opmerking dat je niet gelooft in handmatig testen, iets wat ik opvallend vind.

Ik geloof niet in het handmatig testen als het gaat om het voorkomen van regressies. Dat staat los van "beta gebruikers".

op gegronde redenen.

Die je nog in een edit daadwerkelijk gaat noemen?

Kan je wel testen gaan schrijven, maar als je er in de eerste plaats niet aan denkt om bepaalde functionaliteiten/uitzonderingen in je code te gaan zetten, gaat diezelfde persoon ze niet plots in z'n test case steken. Ik blijf erbij - dat is hier althans zo - dat ontwikkelaars de slechtste testers zijn wanneer het hun eigen code betreft.

Wat je hier zegt is dat slechte developers slechte testers zijn, dat bestrijd ik ook zeker niet. Maar het vooruit denken en ook de uitzonderingssituaties afdekken is iets wat een onderdeel is van het niet-junior zijn van je devs.

Dus ik snap wel een beetje waar dit vandaan komt. Je hebt veel projectbedrijven die vooral laagopgeleid jong spul aannemen om de kosten te drukken. En de bagger die daaruit komt dan proberen te lijmen naderhand met een "test coordinator" die die juniors achter de broek gaat zitten om tests te schrijven, in plaats van te investeren in goed personeel.

[ Voor 26% gewijzigd door Hydra op 15-11-2016 14:22 ]

[Nnoitra]

Hydra schreef op dinsdag 15 november 2016 @ 14:16:

Wat je hier zegt is dat slechte developers slechte testers zijn, dat bestrijd ik ook zeker niet. Maar het vooruit denken en ook de uitzonderingssituaties afdekken is iets wat een onderdeel is van het niet-junior zijn van je devs.

Dus ik snap wel een beetje waar dit vandaan komt. Je hebt veel projectbedrijven die vooral laagopgeleid jong spul aannemen om de kosten te drukken. En de bagger die daaruit komt dan proberen te lijmen naderhand met een "test coordinator" die die juniors achter de broek gaat zitten om tests te schrijven, in plaats van te investeren in goed personeel.

Volgens mij is dat niet wat hij zegt, maar wat jij wil dat hij zegt

In mijn optiek zijn ook senior en écht goede devvers geen goede testers als het op hun eigen code aankomt.
Vaak zitten ze zo in hun eigen gedachtegang en patronen van de software dat ze alleen dat testen, al dan niet in hun unit testen. Ook weten ze vaak weinig tot niets af van externe componenten welke met hun software communiceert en wat voor impact dit zou kunnen hebben.
De toegevoegde waarde van een dedicated, technisch onderlegde en goed opgeleide tester is dat hij/zij niet alleen de beschreven paden meeneemt maar ook de niet beschreven en de niet voor de hand liggende situaties.

Als een niet-junior devver een goede tester zou zijn, dan was testen geen apart vak geworden en waren er geen dedicated testen nodig.

Dit alles gebaseerd op 9 jaar testervaring met icm zowel junior devvers en devvers met 10+ jaar ervaring .

[Reteip]

In mijn optiek zijn ook senior en écht goede devvers geen goede testers als het op hun eigen code aankomt.
Vaak zitten ze zo in hun eigen gedachtegang en patronen van de software dat ze alleen dat testen, al dan niet in hun unit testen. Ook weten ze vaak weinig tot niets af van externe componenten welke met hun software communiceert en wat voor impact dit zou kunnen hebben.
De toegevoegde waarde van een dedicated, technisch onderlegde en goed opgeleide tester is dat hij/zij niet alleen de beschreven paden meeneemt maar ook de niet beschreven en de niet voor de hand liggende situaties.

Wat je zegt lijkt waar. Echter ben ik er als ontwikkelaar en tester achter gekomen dat het een kwestie is van je mindset forceren.

Tijdens het ontwikkelen ben je bezig met design en implementatie. Dan is het lastig om ook breder te gaan denken, dat zorgt er alleen maar voor dat je trager gaat ontwikkelen en voegt niets toe. Dat is waar je gelijk hebt.

Maar, vóór het ontwikkel werk en erna is het heel goed mogelijk om als ontwikkelaar breder te gaan kijken en een brainstorm te doen welke aspecten het gemaakte of nog te maken product kunnen beïnvloeden. En daarbij te kijken wat er allemaal zou kunnen gebeuren en wat relevant is om te gaan testen. Heuristics kunnen daarbij helpen om in de brainstorm mindset te komen. Ontwikkelaars zijn dan vaak verbazend goede testers, of tenminste hele goede toevoegingen aan de testers.

Een andere techniek die ik vaar gebruik om als ontwikkelaar in de testmindset te komen zijn time based test sessies. Geef de ontwikkelaar een testtaak die bijvoorbeeld qua 'goedpaden/obvious dingen' 20 minuten duurt. Maar geef daarbij mee dat de sessie 60 moet minuten duren (+- 10 minuten). Na 20 minuten gaat degene zich vervelen en moet verder gaan kijken (wel binnen hetzelfde onderwerp). Vaak duurt dat een paar minuten, maar vervolgens worden de meeste toch echt wel creatief en gaan bijvoorbeeld kijken hoe het staat met de logging, of in combinatie met... etc..

[Smuggler]

Testen is echt een vak. als senior ontwikkelaars dat zo goed zelf zouden doen, dan was het test vak nooit van de grond gekomen. .
Ik heb met genoeg senior ontwikkelaars samen gewerkt, ook genoeg die eerst hun eigen vlees hebben gekeurd. en daarna heb ik met mijn inzicht altijd weer dingen eruit weten te halen.
Dat is niet omdat ze slecht programmeren, maar omdat foutloze code gewoon niet bestaat.
En iemand die getraint is om dat soort dingen te vinden, zal meer vinden dan iemand die daarnaast ook nog andere dingen doet en blind is voor bepaalde onderwerpen.

Er zullen altijd gebieden zijn die een ontwikkelaar wel vind en een tester niet, door gebrek aan code kennis. maar er zijn juist ook heel veel dingen die gevonden worden doordat je niet weet hoe de code werkt. en dus niet beperkt wordt door voorkennis.

Tevens neemt een tester ook gewoon werk uit handen voor een ontwikkelaar.
- Een ontwikkelaar hoeft voor de business niet meer te bewijzen dat de code echt klaar is voor een release, er wordt een gedegen verslag van de status gemaakt.
- Dingen zoals non-functionals worden continue bewaakt voor een ontwikkelaar.
- kunnen meedenken met de ontwikkelaar bij ingewikkelde problemen
- Het testen zelf wordt voor een "deel" uit handen genomen.
- Alle alternatieve scenario's zullen worden getakeld.


Maar ik snap ook waar de verhalen van slechte testers vandaan komen.
Ik heb zelf een achtergrond in de embedded system engineering: een opleiding van elektronica tot web design. en alle stappen ertussen om die 2 dingen met elkaar te laten communiceren en op elkaar te laten reageren.
Ik kan dus programmeren, heb kennis van assembly, weet hoe geheugen werkt en de elektronica eronder. maar heb ook nog een stukje UX mee gekregen.

Maar als ik zie dat mensen die kunst, pabo, rechten hebben gestudeerd en dan via testen de IT proberen binnen te komen. Ja dan wordt ik zeer droevig.
Als ik moet gaan uitleggen wat het verschil is tussen "if (a=5)" en "if (a==5)" (ja de compiler haalt dit er direct uit, maar het gaat om het niveau aan te geven).
dan vraag ik mij af wat je in dit vakgebied doet.

Een goede tester moet verstand hebben in mijn ogen van programmatuur, zodat als je iets vindt het meteen en zeer snel verder kan analyseren wat er nog meer mis gaat, zodat je dit als een pakketje aan de developer kan geven met: dit is het gedrag, heb een vermoeden dat regel 1337 de oorzaak hiervan is.
Aan een voormalige geschiedenis leraar heb je dan niets.

@hierboven.
Je weet nog niet hoever je bent na 60 minuten, ja het helpt wel. maar goed testen is veel meer dan random op knoppen drukken. en je vervelen en dan op nog meer knoppen drukken.

In die 60 minuten, schrijf ik een plannetje uit, (5 min). heb daarna 45 minuten om te testen. kan in die tijd alles dat ik in dat plan heb opgeschreven stuk voor stuk afvinken. en heb ik nog 10 minuten om gevonden bevindingen een reproductie scenario te minimaliseren (root course blootleggen) en kan ik dat daarna goed delen met een ontwikkelaar of in tickets schrijven.

Achteraf heb ik de volgende dingen opgeleverd.
Er is registratie waar er allemaal na gekeken is.
Er zijn reproductie scenario's die doeltreffent zijn voor de gevonden issue's.
Is dit bijgewerkt in het testplan / test rapport.
Kan een eventuele andere tester of ontwikkelaar beoordelen of ik geen dingen over het hoofd heb gezien.

Iedereen kan fietsen na wat oefening (meestal rond je 2e a 3e? levensjaar).
Maar de gemiddelde snelheid van een wielrenner haalt niet iedereen over een langere afstand, ook al fiets je elke dag naar werk. Daarvoor train je en heb je een ander doel dan op werk komen.
Dit betekend dus dat een goede fietser best beter kan zijn dan een slechte wielrenner .
Dit betekend dus dat een goede developer beter kan zijn dan een slechte tester.

Testen is een vak, en niet iedereen is daar geschikt voor, echter zie ik in het bedrijfsleven de grootste idioten tester worden. en als ze dat niet kunnen worden ze maar test manager .

[Coltrui]

Ik krijg zo langzamerhand het idee dat ontwikkelaars die het nut van dedicated testers niet inzien, zelf goede testers zouden zijn en niet vatten dat er devvers zijn - hoe senior ook - die daar niet voor geschikt zijn. En die laatsten zijn in mijn ervaring ook in de meerderheid.

[ Voor 13% gewijzigd door Coltrui op 15-11-2016 23:01 ]

[BarôZZa]

Als developer vind ik weinig dingen zo suf en saai als testen. Creatief zoeken naar lekken of exploits zint me nog wel, maar voor de zoveelste keer alle buttons en elementen etc nalopen is zonde van de dev-uren. Dedicated testers zijn helden en nemen je werk uit handen. Hetzelfde geldt voor managers/scrum masters.

De enige dingen die soms irritatie opwekken zijn:

- Je fixt een klein issue en die wordt teruggeknald omdat de tester een bug vindt die al in de module zat maar niks met het issue te maken had.
- Sommige testers draven wel eens een beetje door en doen alsof een gevonden bug meteen de hoogste prio moet hebben. Als het er al jaren in zit en niemand het heeft gemerkt (doordat ze bijvoorbeeld normale dingen in de velden stoppen aangezien veel mensen er vaak geen belang bij hebben om troepdata in te voeren), dan kan het meestal wel wachten.
- Het wordt vaak ook een beetje ongemakkelijk als een tester zich ook in de rol van systeemarchitect oid probeert te plaatsen en de technische/functionele oplossing erbij probeert te leveren.

Maar zo lang alles duidelijk en afgebakend is, is het meer dan prima. En developers moeten zich ook niet met van alles en nog wat willen bemoeien. Sure, technische mensen zijn vaak handig met een heleboel andere technische zaken, maar het is enorm zonde van de tijd.

Coltrui schreef op zondag 13 november 2016 @ 17:25:
[...]

- Validatiecontrole (veldtype/lengte, verplichte velden check etc…)
- Component converties – wanneer een edit, wanneer een datetimpepicker, wat laten we standaard toe bij grids (sorteren/filteren/groeperen,...)
- Inconsequentie in GUI conventies: huisstijl, taborders, universele sneltoetsen, icoongebruik…
- ...

Zaken als deze wil ik als tester gewoon niet zien - ik denk dat die zich met wat minder triviaals moeten gaan bezighouden. En zaken zoals punt 1 zijn toch te automatisch te testen, lijkt me? De andere twee punten moeten gedrilld en gedocumenteerd worden, dat begrijp ik wel. Of stel ik me nu aan en is dat nu juist wel de taak van de tester?

Met dit soort zaken moet je wel altijd goed rekening houden met hoe gebruikers er al die jaren mee werken.

Als klanten iets altijd op een bepaalde manier invulden en nu een foutmelding krijgen, dan zijn ze vaak niet blij. Hetzelfde kan gebeuren als je ineens filters gaat aanpassen. Of als klanten gewend zijn om de datum in te tikken en nu een trage date picker voor hun kiezen krijgen.

Inconsequentie in de GUI is ook lang niet altijd erg. Veel van die dingen vallen ook alleen maar op als je als tester alles één voor één gaat nalopen. Gebruikers hebben echt niet door dat er in de ene module 'Opslaan' bij de button staat en bij de andere 'Save'.

Als het een grote bende is, dan moet er uiteraard wel wat aan gedaan worden, maar je moet uitkijken dat je niet teveel waarde gaat hechten aan dingen die alleen jij ziet. Als iemand ergens een icoontje bijzet, dan gaat diegene vaak ook niet alle modules af om te kijken of er ergens al eentje staat.

Ook uitkijken dat je bij een GUI niet alles teveel wil straktrekken. Het is vaak niet erg als verschillende onderdelen er anders uitzien als het verschillende dingen zijn. Heb ook eens meegemaakt dat iemand dacht dat het een goed idee was om dezelfde stijl overal toe te passen. Zelfde fontgroottes, paddings, uitlijningen, button groottes, soortgelijke posities etc. Eindstand was dat gebruikers in de war raakten omdat ineens alle schermen sprekend op elkaar leken en ze goed moesten lezen wat er stond ipv dat ze het verschil meteen zagen. En de lelijke grote opslaan knop viel ineens een stuk minder op.

[Hydra]

BarôZZa schreef op dinsdag 15 november 2016 @ 23:53:
Als developer vind ik weinig dingen zo suf en saai als testen. Creatief zoeken naar lekken of exploits zint me nog wel, maar voor de zoveelste keer alle buttons en elementen etc nalopen is zonde van de dev-uren. Dedicated testers zijn helden en nemen je werk uit handen. Hetzelfde geldt voor managers/scrum masters.

Ik zeg ook niet dat dat testen niet moet gebeuren. Wat ik alleen zie is dat iedereen, wie dan ook, dat werk niet leuk vindt. Niemand houdt het vol om elke dag van de week niks anders te doen dan door die zaken heen klikken. Wat ik als dev wil is een 'tester' die gewoon na elke build van elke branch exact dezelfde sequence doorloopt. Geen enkele mens gaat dat doen. Kan jij het je voorstellen dat ik je kom vertellen dat er weer een feature branch gepushed is en dat jij weer je truukje mag doen?

User acceptance testing; gaat net zo. Hoe vaak ik wel niet meegemaakt hebt dat een product door acceptatie gekomen was en users naderhand gingen zeiken omdat een feature niet werkte zoals ze dat wouden. Waarom? Ze hebben het niet gebruikt.

Ik zie dan ook elke keer dat de meest suffe zaken (registratie, user input) geskipt gaat worden. Het maakt niet uit of het testen is of deployment, the enige manier om dit goed te doen en goed te blijven doen is het te automatiseren. Computers raken niet verveeld. Computers geven geen interpretatie aan 'test scripts'. Computers zoeken niet naar een maand een andere baan omdat 't fucking saai is. Daarom wil je zoveel mogelijk van je tests automatiseren. Hetzelfde geldt voor deployments; ik heb vaak genoeg meegemaakt dat deployments zo'n routine werden dat de beheerders de scripts niet meer lazen. En ja, dan gaat 't mis. Lang leve DevOps dus; wij maken als devs de deployment scripts. Onze Ops mensen zijn inhoudelijke experts; geen handjes.

En dat is nu net iets wat maar heel erg weinig testers ook echt kunnen, want je moet echt kunnen programmeren. Wat je dus binnenhaalt als je 'testers' inhuurt bij bijvoorbeeld Cap Gemini zijn mensen die vooral opgelegd wordt veel uren te verspillen aan "testplannen".

En ja ik weet dat ik nogal cynisch overkom hier, maar dat is gewoon mijn ervaring in de projecten die gedaan heb. Mensen falen constant. Computers doen netjes wat je ze opdraagt.

[ Voor 6% gewijzigd door Hydra op 16-11-2016 09:08 ]

[ThomasG]

Hydra schreef op woensdag 16 november 2016 @ 09:07:
[...]


Ik zeg ook niet dat dat testen niet moet gebeuren. Wat ik alleen zie is dat iedereen, wie dan ook, dat werk niet leuk vindt. Niemand houdt het vol om elke dag van de week niks anders te doen dan door die zaken heen klikken. Wat ik als dev wil is een 'tester' die gewoon na elke build van elke branch exact dezelfde sequence doorloopt. Geen enkele mens gaat dat doen. Kan jij het je voorstellen dat ik je kom vertellen dat er weer een feature branch gepushed is en dat jij weer je truukje mag doen?

Dat kun je voor een groot deel automatiseren. Waar testers vooral handig voor zijn, is om een applicatie 'monkey proof' te maken. Want werken zoals het moet, doen de meeste applicaties wel. Het afwijken van de door de developer bedachte workflow, levert vaak de meeste bugs en problemen op.

[Hydra]

ThomasG schreef op woensdag 16 november 2016 @ 09:35:
Dat kun je voor een groot deel automatiseren. Waar testers vooral handig voor zijn, is om een applicatie 'monkey proof' te maken. Want werken zoals het moet, doen de meeste applicaties wel. Het afwijken van de door de developer bedachte workflow, levert vaak de meeste bugs en problemen op.

Ik ben het er helemaal mee eens dat testers daar een toegevoegde waarde hebben. Maar de meeste rare dingen worden door een beta-gebruikerspanel gevonden. Testers krijgen exact dezelfde tunnelvisie als de devs in mijn ervaring. Komt nog eens bij dat een gebruikerspanel een stuk goedkoper is dan een paar "test consultants".

[Nnoitra]

Hydra schreef op woensdag 16 november 2016 @ 09:07:
[...]
Ik zeg ook niet dat dat testen niet moet gebeuren. Wat ik alleen zie is dat iedereen, wie dan ook, dat werk niet leuk vindt. Niemand houdt het vol om elke dag van de week niks anders te doen dan door die zaken heen klikken. Wat ik als dev wil is een 'tester' die gewoon na elke build van elke branch exact dezelfde sequence doorloopt. Geen enkele mens gaat dat doen. Kan jij het je voorstellen dat ik je kom vertellen dat er weer een feature branch gepushed is en dat jij weer je truukje mag doen?

User acceptance testing; gaat net zo. Hoe vaak ik wel niet meegemaakt hebt dat een product door acceptatie gekomen was en users naderhand gingen zeiken omdat een feature niet werkte zoals ze dat wouden. Waarom? Ze hebben het niet gebruikt.

Ik zie dan ook elke keer dat de meest suffe zaken (registratie, user input) geskipt gaat worden. Het maakt niet uit of het testen is of deployment, the enige manier om dit goed te doen en goed te blijven doen is het te automatiseren. Computers raken niet verveeld. Computers geven geen interpretatie aan 'test scripts'. Computers zoeken niet naar een maand een andere baan omdat 't fucking saai is. Daarom wil je zoveel mogelijk van je tests automatiseren. Hetzelfde geldt voor deployments; ik heb vaak genoeg meegemaakt dat deployments zo'n routine werden dat de beheerders de scripts niet meer lazen. En ja, dan gaat 't mis. Lang leve DevOps dus; wij maken als devs de deployment scripts. Onze Ops mensen zijn inhoudelijke experts; geen handjes.

En dat is nu net iets wat maar heel erg weinig testers ook echt kunnen, want je moet echt kunnen programmeren. Wat je dus binnenhaalt als je 'testers' inhuurt bij bijvoorbeeld Cap Gemini zijn mensen die vooral opgelegd wordt veel uren te verspillen aan "testplannen".

En ja ik weet dat ik nogal cynisch overkom hier, maar dat is gewoon mijn ervaring in de projecten die gedaan heb. Mensen falen constant. Computers doen netjes wat je ze opdraagt.

Ik ben het op zoveel vlakken niet met je eens..
En ik vind het jammer dat jij jouw ervaringen met betrekking tot testen en testers als de waarheid (en die ook nog eens zuigt) ziet

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.

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.

Dat je met ingehuurde 'testers' alleen maar een zooi testplannen-makers binnenhaalt, dan is dat meer een eigen falen of van je manager die ze binnenhaalt. Er zijn ZAT test professionals die écht een meerwaarde kunnen zijn; je moet ze er alleen wel tussenuit kunnen filteren.

En voor wat betreft die "Mensen falen constant. Computers doen netjes wat je ze opdraagt".
Hier is de mens nog steeds de SPOF. Als de mens faalt met de opdrachten invoeren, zal de computer ook netjes doen wat opgedragen is en dat kan dus ook falen.

[ThomasG]

Hydra schreef op woensdag 16 november 2016 @ 09:38:
[...]


Ik ben het er helemaal mee eens dat testers daar een toegevoegde waarde hebben. Maar de meeste rare dingen worden door een beta-gebruikerspanel gevonden. Testers krijgen exact dezelfde tunnelvisie als de devs in mijn ervaring. Komt nog eens bij dat een gebruikerspanel een stuk goedkoper is dan een paar "test consultants".

Volgens mij komt dat vooral door gebrek aan variatie. Dat is net zoals een buschauffeur die elke dag hetzelfde traject rijdt. Dan letten ze minder goed op, etc. Als een tester vaak de zelfde, of soortgelijke, software of onderdelen daarvan moet testen, kakken ze gewoon in. Daarbij hangt het natuurlijk ook af van de ontwikkelaars.

Ik test als ontwikkelaar wel eens stukjes software geschreven door collega's. Als ik dan steeds dezelfde simpele bugs tegen kom, heb ik er al geen zin meer in. Daar kan ik dan ook gewoon boos om worden dat ze dat zelf niet ontdekt hebben. Ik kan mij voorstellen dat dát voor testers ook geldt.

[BarôZZa]

Hydra schreef op woensdag 16 november 2016 @ 09:07:
[...]


Ik zeg ook niet dat dat testen niet moet gebeuren. Wat ik alleen zie is dat iedereen, wie dan ook, dat werk niet leuk vindt. Niemand houdt het vol om elke dag van de week niks anders te doen dan door die zaken heen klikken. Wat ik als dev wil is een 'tester' die gewoon na elke build van elke branch exact dezelfde sequence doorloopt. Geen enkele mens gaat dat doen. Kan jij het je voorstellen dat ik je kom vertellen dat er weer een feature branch gepushed is en dat jij weer je truukje mag doen?

User acceptance testing; gaat net zo. Hoe vaak ik wel niet meegemaakt hebt dat een product door acceptatie gekomen was en users naderhand gingen zeiken omdat een feature niet werkte zoals ze dat wouden. Waarom? Ze hebben het niet gebruikt.

Ik zie dan ook elke keer dat de meest suffe zaken (registratie, user input) geskipt gaat worden. Het maakt niet uit of het testen is of deployment, the enige manier om dit goed te doen en goed te blijven doen is het te automatiseren. Computers raken niet verveeld. Computers geven geen interpretatie aan 'test scripts'. Computers zoeken niet naar een maand een andere baan omdat 't fucking saai is. Daarom wil je zoveel mogelijk van je tests automatiseren. Hetzelfde geldt voor deployments; ik heb vaak genoeg meegemaakt dat deployments zo'n routine werden dat de beheerders de scripts niet meer lazen. En ja, dan gaat 't mis. Lang leve DevOps dus; wij maken als devs de deployment scripts. Onze Ops mensen zijn inhoudelijke experts; geen handjes.

En dat is nu net iets wat maar heel erg weinig testers ook echt kunnen, want je moet echt kunnen programmeren. Wat je dus binnenhaalt als je 'testers' inhuurt bij bijvoorbeeld Cap Gemini zijn mensen die vooral opgelegd wordt veel uren te verspillen aan "testplannen".

En ja ik weet dat ik nogal cynisch overkom hier, maar dat is gewoon mijn ervaring in de projecten die gedaan heb. Mensen falen constant. Computers doen netjes wat je ze opdraagt.

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. Eén computer zal ongetwijfeld doen wat je het opdraagt, maar als je tig apparaten, browsers en dergelijke hebt wordt het al een ander verhaal. Dito voor integraties met allerlei externe services/applicaties.

En dan zit je vaak ook nog met allemaal verschillende omgevingen en configuraties. Een bug is niet persé dat functie A niet de goede output geeft. Het kan ook zijn dat een element van het scherm verdwijnt omdat er andere data op de live-site staat. Of dat er een andere taal wordt gelanceerd en er gekeken moet worden of er geen onvertaalde dingen tussenstaan. Of optimalisaties aan een database.

De testers bij een eerdere baan waren ook niet heel de dag blind aan het klikken, maar leverden ook support aan de klanten. Als er iets mis was probeerden ze het op te lossen en anders duidelijk te krijgen of het een bug was. Daarna werd daar netjes een issue voor aangemaakt en een omgeving zo ingericht dat het probleem eenvoudig te reproduceren was en je als developer daar geen moeite in hoefde te steken.

User acceptance testing is verder natuurlijk een ander verhaaal. Die klikken er even snel doorheen om er vanaf te zijn.

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

[Anoniem: 785143]

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]

Anoniem: 785143 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]

Anoniem: 785143 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!)