Software testen

[Yogibeer]

Mijn vraag:
Ik probeer wat meer te leren over het fenomeen Testen. Op mijn werk worden er maandelijks diverse grote releases doorgevoerd, waarbij altijd heel erg veel tijd ingenomen wordt door het testen daarvan. Ik ben daar meestal niet bij betrokken en het lijkt mij allemaal helemaal niet zo ingewikkeld (je test gewoon de nieuwste functionaliteiten?). Ik heb ook vaak het idee dat mijn collega's (allemaal échte ITérs) zichzelf helemaal verliezen in het eindeloos testen van dingen die ze soms zelf gemaakt hebben.

Nu vraag ik wel eens om wat meer informatie en dat krijg ik een enorme shit load aan kreten over systeemtesten, integratietesten,etc etc.

Ik zou heel graag willen weten hoe ik kreten als systeemtesten, integratietesten, acceptatietesten, etc voor mij moet zien. Wanneer doe je deze testen en in welke fase? En wie voert ze uit?

Ik heb op het internet gezocht en ik vind allerlei verschillende modellen. Ik zie echter niets wat overeenkomt met hoe wij dit op onze werkvloer doen.

Relevante software en hardware die ik gebruik
n.v.t.

Wat ik al gevonden of geprobeerd heb
Youtube en Google geadviseerd.

PS: Wist niet in welke categorie van dit forum ik deze vraag moest stellen. Excuus als ik de verkeerde heb gepakt.

[celshof]

Je test je software om wat te kunnen zeggen over de kwaliteit. Afhankelijk van de kritiekheid van de software zul je meer of minder testen.

Ga er maar van uit dat geen enkel bedrijf exact een methode volgt. In Nederland zijn TMap en ISTQB de meest gevolgde methoden. Daarnaast zijn er maar kleine verschillen in de gebruikte termen. Een systeemtest of integratietest definitie kun je daardoor prima googlen met 1 van de 2 methoden.

En alleen nieuwe functionaliteit testen is altijd een goede route om de rest om te laten vallen in productie.

edit: je hebt het over je collega's als echte IT'ers. Wat is jouw functie, als ik vragen mag?

[ Voor 8% gewijzigd door celshof op 19-04-2020 10:10 ]

[Yogibeer]

celshof schreef op zondag 19 april 2020 @ 10:09:
Je test je software om wat te kunnen zeggen over de kwaliteit. Afhankelijk van de kritiekheid van de software zul je meer of minder testen.

Ga er maar van uit dat geen enkel bedrijf exact een methode volgt. In Nederland zijn TMap en ISTQB de meest gevolgde methoden. Daarnaast zijn er maar kleine verschillen in de gebruikte termen. Een systeemtest of integratietest definitie kun je daardoor prima googlen met 1 van de 2 methoden.

En alleen nieuwe functionaliteit testen is altijd een goede route om de rest om te laten vallen in productie.

edit: je hebt het over je collega's als echte IT'ers. Wat is jouw functie, als ik vragen mag?

Ik werk als een soort van informatie analist. Probeer de wensen van medewerkers uit ons bedrijf te vertalen naar IT oplossingen en vice versa.
Ben dus een kleine schakel tussen hetgeen onze IT afdeling voor ons doet en hoe we dat op de werkvloer in gebruik nemen. Met name de testfase zorgt altijd voor veel vertraging (mogelijk terecht).

Overigens bedoel ik 'echte IT'ers' niet als iets negatiefs. Dat ter verduidelijking

[hhoekstra]

(je test gewoon de nieuwste functionaliteiten?)

Ik ben geen tester maar deze zin kan ik wel ontkrachten. Je kan in module X iets nieuws inbouwen waardoor het in module Z niet meer werkt.
Dus alles doortesten is wel nodig.

[Yogibeer]

hhoekstra schreef op zondag 19 april 2020 @ 10:20:
[...]


Ik ben geen tester maar deze zin kan ik wel ontkrachten. Je kan in module X iets nieuws inbouwen waardoor het in module Z niet meer werkt.
Dus alles doortesten is wel nodig.

Ik ben me ook bewust van het feit dat ik te simpel denk.

Begin bij A en doorloop alle stappen om tot Z te komen. Dan kijk je onderweg of je tegen fouten aan loopt, of dat je het gewenste eindresultaat krijgt.
Ik wil ook absoluut geen kritiek leveren op de werkzaamheden die anderen - met veel meer verstand van dit onderdeel - doen. Echter zou ik het wel graag wat beter willen begrijpen.

Ik begrijp de verschillende termen al niet zo goed.

Bij systeemtesten denk ik aan het testen van het systeem. Komt het overeen met de vooraf gestelde eisen?
Bij de integratietesten denk ik aan hoe de integratie met deel systemen verloopt. We hebben onderdeel A aangepast, maar werkt nu onderdeel B nog?
Bij acceptatietesten denk ik aan de fase waarbij eindgebruikers / applicatiebeheerders testen of e.e.a. naar wens is uitgevoerd.

Testers:
Systeemtest = programmeurs / ontwikkelaars
Integratietest = programmeurs / ontwikkelaars
Acceptatietest = applicatiebeheerders / eindgebruikers

Zo zie ik dat dus een beetje voor me.

[ Voor 28% gewijzigd door Yogibeer op 19-04-2020 10:29 ]

[Drardollan]

Voordat wij een echte tester hadden deden we een release en daarna minstens 10 hotfixes.
Nu hebben we een echte tester en hebben we na een release sporadisch een hotfix.

Testers kijken kritisch naar je software en controleren of alles werkt zoals beschreven in de stories, maar uiteraard ook het grotere geheel. Leuk dat feature X het doet volgens de story, als vervolgens ergens iets omvalt is je software niets waard.

[DarkSide]

Kan je niet vragen hoe het testproces precies werkt bij jullie.
Er zijn idd veel soorten testen. En verschillende manieren. Afhankelijk of het een LoB app is of niet bv.

Je kunt denken aan het volgende:
Systeemtest: eerste "simpele" test op een systeem. Gecontroleerd testen of de nieuwe software werkt, of onverwachte issues heeft. Dit aanpakken, verbeteren, oplossen etc.

Integratie test: Als je klaar bent met de eerste test ga je kijken hoe de software integreert met de overige ketens. Waarschijnlijk moet het praten met meerdere diensten etc. Hoe verloopt dat. Moeten een andere dienst ook aangepast worden om met de nieuwe software over weg te kunnen.

Acceptatie test: Nu test je je "Final" product veilig in een Test omgeving. bv. Of laat je gebruikers toe op een afgeschermde productie omgeving (ligt aan de impact die de update heeft hoe je dit aanpakt).
Daarmee krijg je feedback.
Mogelijk moet je terug naar eerdere Fases.

Als alles goed gaat ga je de changes implementeren in productie.

[weebl]

Verdiep je eens in regressie testen. Dat is waar de "echte ITers" zich elke keer in verliezen denk ik .

Zeker bij grote releases is dat vrij cruciaal. Je wil niet de hele release terug moeten rollen op een vrijdagmiddag omdat er toch een foutje ingeslopen is...

[sugarlevi01]

Yogibeer schreef op zondag 19 april 2020 @ 10:16:
[...]


Ik werk als een soort van informatie analist. Probeer de wensen van medewerkers uit ons bedrijf te vertalen naar IT oplossingen en vice versa.
Ben dus een kleine schakel tussen hetgeen onze IT afdeling voor ons doet en hoe we dat op de werkvloer in gebruik nemen. Met name de testfase zorgt altijd voor veel vertraging (mogelijk terecht).

Jij geeft een wens door aan het team.
Bijvoorbeeld de user wilt dat er een vakje met informatie toegevoegd wordt,en dat deze informatie, vervolgens op een ander plek in het systeem zichtbaar wordt.

Programmeur gaat dat vakje toevoegen, gaat de informatie uit het vakje weg laten schrijven, en vervolgens die informatie uit dat vakje op die andere plek in het systeem zichtbaar laten worden.

Dat moet dan al functioneel getest gaan worden, is dat vakje er, kan ik informatie invullen, welk type informatie kan ingevuld worden. En wordt deze informatie zichtbaar op de andere plek in het systeem.
Programmeurs zullen dit al snel heel functioneel testen. Terwijl testers allerlei soorten informatie gaan invullen om te kijken of ze het stuk kunnen maken.

Vervolgens wil je gaan kijken of het hele proces nog wel goed verloopt, je hebt op nu in stap C. dat vakje toegevoegd, en bij E. wordt die zichtbaar. Dus je gaat nu de integratie testen, het hele proces van A-Z.
En de processen die daar aan gerelateerd zijn. Dat is dan een integratie test.
En eigenlijk ook meteen een regressietest, omdat je daarbij ook controleert of eerdere gebouwde onderdelen nog werken. Wat dat betreft kunnen verschillende soorten testen door elkaar heen lopen, en overlap hebben.

Vervolgens ga je het hele systeem testen, alle processen en onderdelen, ook in combinatie met zijdelings gebruikte software, en bijvoorbeeld in verschillende omgevingen. Om te kijken of alles naar behoren werkt.

En daarna vinden er acceptatietesten plaats, dit kan door verschillende groepen zijn. Dan gaan jij, gebruikers, of andere mensen testen of dit is wat ze willen hebben en kunnen gebruiken.

Het zal heel erg afhankelijk van het bedrijf zijn, hoe, wanneer en door wie deze stappen worden uitgevoerd. En in hoeverre het ook daadwerkelijke afzonderlijke verschillende fases in een testtraject zijn.

[SmurfLink]

weebl schreef op zondag 19 april 2020 @ 10:32:
Verdiep je eens in regressie testen. Dat is waar de "echte ITers" zich elke keer in verliezen denk ik .

Zeker bij grote releases is dat vrij cruciaal. Je wil niet de hele release terug moeten rollen op een vrijdagmiddag omdat er toch een foutje ingeslopen is...

Yep, deze miste ik nog in het lijstje en is toch wel de belangrijkste.

Je kan een nieuwe feature toevoegen, maar dan moet je dus zeker weten dat ALLE andere features het nog steeds doen in die versie. Daarom 'verliezen' de TS z'n testers zich waarschijnlijk, omdat ze een regressietest doen.

[Yogibeer]

Dank voor de reacties allen!

Het wordt me al een stuk helderder.

Regelmatig hoor ik mijn IT collega's ook over programmatesten en systeemtesten. Wat is nu het wezenlijke verschil tussen deze twee?

Nu e.e.a gelezen te hebben over Tmap zie ik het volgende voor me:

Je begint met het maken van een mastertestplan.
Daaronder vallen verschillende activiteiten zoals het maken van een strategie en het bepalen van een planning.

Vervolgens kent Tmap de voorbereiding, specificatie, uitvoering en afrondings fases.
Elk van deze fases heeft ook verschillende activiteiten, waarbij ik me wel een voorstelling kan maken.

Echter zie ik dan nog niet de link tussen de verschillende testvormen: systeemtesten, integratietesten,etc.

Misschien denk ik wel veel te moeilijk, maar mijn inziens best ingewikkelde stof.

[ Voor 60% gewijzigd door Yogibeer op 19-04-2020 11:57 ]

[kemphaas]

Als ik je één tip mag geven, google eens op het "v model". Dat geeft in een plaatje weer waarom er verschillende soorten testen zijn.

En kijk eens naar deze animatie:
https://twitter.com/thepr...status/687672086152753152

Testen zul je op alle niveaus van het v model moeten doen om te kunnen garanderen dat een systeem werkt.

Ontwikkelaars schrijven zelf unit testen, om hun eigen stukjes code te kunnen testen.
Het liefst worden alle overige testen door andere personen geschreven en gemaakt.

Bij integratietesten wordt het werk van verschillende onderdelen samengevoegd. Dit doe je het liefst geautomatiseerd en is nog behoorlijk technisch.

Bij systeemtesten gaat het echt om het geheel. Dit zou gedaan kunnen worden door mensen zonder technische kennis van het product (eindgebruikers), maar liefst wel met kennis van testen, om zo gestructureerd een systeem te kunnen testen.

Als je zou willen zou ik je best eens wat meer kunnen vertellen, maar dan niet in tekst, liever een keer "telefonisch/teams/skype" achtig.

Ik heb zelf kennis en ervaring met ISTQB (soort Tmap tegenhanger).

[Lixis]

Yogibeer schreef op zondag 19 april 2020 @ 11:50:
Dank voor de reacties allen!

Het wordt me al een stuk helderder.

Regelmatig hoor ik mijn IT collega's ook over programmatesten en systeemtesten. Wat is nu het wezenlijke verschil tussen deze twee?

Nu e.e.a gelezen te hebben over Tmap zie ik het volgende voor me:

Je begint met het maken van een mastertestplan.
Daaronder vallen verschillende activiteiten zoals het maken van een strategie en het bepalen van een planning.

Vervolgens kent Tmap de voorbereiding, specificatie, uitvoering en afrondings fases.
Elk van deze fases heeft ook verschillende activiteiten, waarbij ik me wel een voorstelling kan maken.

Echter zie ik dan nog niet de link tussen de verschillende testvormen: systeemtesten, integratietesten,etc.

Misschien denk ik wel veel te moeilijk, maar mijn inziens best ingewikkelde stof.

Het hoeft allemaal niet zo moeilijk te zijn, maar ik merk in de praktijk wel dat allerlei termen door elkaar heen gebruikt worden. Eigenlijk bestaat testen altijd uit de volgende vier testen (TMAp noemt dit testsoorten):

• unit testen - testen van de code op het laagste niveau
• integratietesten - testen van koppelingen tussen (sub)modules. Bv. zorgt een actie op de front-end voor een reactie in de back-end, of praat microservice A op de juiste manier met microservice B. Vaak gaat het hier om het testen van (versimpelde) functionaliteit, bv. de vraag of een nieuw stukje code op de juiste manier interacteert met de bestaande applicatie.
• systeemtesten - testen van het systeem als geheel, dus alle (sub)modules bij elkaar. Indien relevant ook geïnstallleerd op de beoogde hardware e.d. Naast functionaliteit gaat het ook om de non-functionals: performance, security, etc.
• acceptatie testen - het testen van het systeem door de ogen van de eindgebruiker/klant of die persoon zelf het systeem laten testen

Soms zie je dan ook nog end-to-end testen of ketentesten. Meestal wordt hiermee bedoeld dat koppelingen tussen systemen getest worden. Denk dan aan ketens tussen applicaties die organisatie-overstijgend zijn.

In waterval projecten en bij zeer complexe systemen zie je al deze testsoorten nog wel terugkomen. Bij de kleinere/agile projecten zie je vaak een mengelmoesje van al deze testsoorten die min-of-meer tegelijkertijd uitgevoerd worden.

[chielsen]

Systeemtesten zijn vaak vergelijkbaar met integratietesten, eigenlijk gewoon een andere naam voor hetzelfd beestje.
Als je met unit testen werkt, wil je ook weten of de units samen (=systeem of integratie) ook naar wens werken.Ik ken eigenlijk geen gevallen waar er naast een systeem test ook een integratie test is.
Een systeem test kan namelijk niet in 1x het hele systeem testen, Dat zijn gewoon testen (vaak UI interacties) die een hoop units raken, en zo dus in feite (een gedeelte van) het systeem testen.

[Yorinn]

Dit is meer een onderwerp voor PFSL, daarom ook een schopje die kant op.

[Jealgu]

Als je agile werkt wil je wel voorkomen dat je met allerlei lange fasen te maken hebt. Je wil zoveel mogelijk zo vroeg mogelijk in het process testen, en repeterende taken, zoals regressietesten, automatiseren.

[Napo]

Yogibeer schreef op zondag 19 april 2020 @ 10:16:
Met name de testfase zorgt altijd voor veel vertraging (mogelijk terecht).

Testen zorgt zeker niet voor vertraging, je moet er wel zorg voor dragen dat je het juiste test en hetgeen automatisch kan ook automatisch gebeurd. Testen is een cruciaal onderdeel van het ontwikkelproces en er zorg voor draagt dat enkel goedwerkende code op de productieomgeving komt.

Tijd besparen op testen kan problemen opleveren die op den duur meer tijd kosten dan dat de bezuiniging oplevert.

[Hahn]

Napo schreef op maandag 27 april 2020 @ 16:04:
[...]


Testen zorgt zeker niet voor vertraging, je moet er wel zorg voor dragen dat je het juiste test en hetgeen automatisch kan ook automatisch gebeurd. Testen is een cruciaal onderdeel van het ontwikkelproces en er zorg voor draagt dat enkel goedwerkende code op de productieomgeving komt.

Tijd besparen op testen kan problemen opleveren die op den duur meer tijd kosten dan dat de bezuiniging oplevert.

Testen zorgt zeker wel voor vertraging op de korte duur, alleen is niet testen vaak veel duurder op de lange duur

[Croga]

Lixis schreef op maandag 27 april 2020 @ 10:56:

• unit testen - testen van de code op het laagste niveau
• integratietesten - testen van koppelingen tussen (sub)modules. Bv. zorgt een actie op de front-end voor een reactie in de back-end, of praat microservice A op de juiste manier met microservice B. Vaak gaat het hier om het testen van (versimpelde) functionaliteit, bv. de vraag of een nieuw stukje code op de juiste manier interacteert met de bestaande applicatie.
• systeemtesten - testen van het systeem als geheel, dus alle (sub)modules bij elkaar. Indien relevant ook geïnstallleerd op de beoogde hardware e.d. Naast functionaliteit gaat het ook om de non-functionals: performance, security, etc.
• acceptatie testen - het testen van het systeem door de ogen van de eindgebruiker/klant of die persoon zelf het systeem laten testen

Soms zie je dan ook nog end-to-end testen of ketentesten. Meestal wordt hiermee bedoeld dat koppelingen tussen systemen getest worden. Denk dan aan ketens tussen applicaties die organisatie-overstijgend zijn.

Prachtig overzicht! Wellicht nog mogelijk aan toe te voegen:
- Functionele tests. In feite "acceptatie tests" op kleinere schaal
- Monitoring (ook een soort testen maar dan op productie systemen en op heel laag niveau
- Monkey test; Er is geen test zo slim of er is wel een gebruiker die het kapot gaat krijgen. Er is nogsteeds geen automatisering mogelijk van een gek die op de verkeerde knoppen duwt

In waterval projecten en bij zeer complexe systemen zie je al deze testsoorten nog wel terugkomen. Bij de kleinere/agile projecten zie je vaak een mengelmoesje van al deze testsoorten die min-of-meer tegelijkertijd uitgevoerd worden.

De grote vooruitgang in Agile zit hem voornamelijk is de mogelijkheid om alles te automatiseren. Op die manier kun je alle tests die "vroeger" gedaan werden nogsteeds blijven doen maar dan met een veel kleinere inspanning.

@Verwijderd kijk eens naar:
- Unit tests met behulp van TDD
- Functionele tests met behulp van BDD
- Continuous Integration om te zorgen dat beiden continu uitgevoerd worden.

Als analist denk ik dat jij heel veel baat kunt hebben bij BDD, als concept. BDD gaat er van uit dat iedere specificatie uit te schrijven is als een test. En door dat te doen kun jij, als analist, zorgen dat het ontwikkelproces eenvoudiger en sneller wordt.

Realiseer je overigens ook dat testen vooral gaat over software kwaliteit maar dat er veel meer factoren zijn die de kwaliteit van de software bepalen. Staar je dus niet blind op testen maar kijk vooral ook naar zaken als duidelijke specificaties (door interactief specificeren), market fit, onderhoudbaarheid van de code en de specificaties, performance, en nog veel meer.....

Oh, en vergeet alsjeblieft niet dat testen (of eigenlijk: Risico minimalisering) een vak apart is. Mensen die zich alles in deze categorie eigen maken kijken echt op een andere manier naar het product.

[ Voor 3% gewijzigd door Croga op 27-04-2020 16:21 ]

[Muta]

Ik ben inmiddels drie jaar tester in agile teams en help je graag op weg. Ik werk/heb gewerkt bij MKB en grote organisaties. Durf wel te zeggen dat ik het agile testproces aardig onder de knie heb. Ben trouwens ook TMap en CAT gecertificeerd.

Yogibeer schreef op zondag 19 april 2020 @ 09:39:
Ik zou heel graag willen weten hoe ik kreten als systeemtesten, integratietesten, acceptatietesten, etc voor mij moet zien. Wanneer doe je deze testen en in welke fase? En wie voert ze uit?

Ik gebruik de term systeemtesten nooit eigenlijk. Ik test een user story. Systeemtesten is wat mij betreft een achterhaalde term die niet meer nodig is. Al deze termen hebben zoveel verschillende interpretaties en verwachtingen opgeleverd in de hele IT-wereld. Ik heb in mijn werkzaamheden nog nooit de term systeemtest moeten gebruiken om duidelijk te maken wat ik doe.

Integratietesten (IT) is een lastige term want ik merk verschillende interpretaties op de werkvloer en op internet. Je kunt kijken naar de integratie van verschillende stukken code (of functionaliteit, als dat makkelijker praat) met elkaar. Werkt de backend wel met de front-end? Hoe integreert deze US op de bestaande functionaliteit? Maar de term IT wordt ook vaak gebruikt om te bevestigen dat communicatie tussen twee verschillende systemen (applicaties) werkt.

Acceptatietesten is wederom een lastige term. Wat mij betreft zegt het woord acceptie genoeg. Wie accepteert het systeem? De PO? De klant? Een acceptant? Whoever it is, ik ben het niet! Want ik accepteer het systeem niet, ik test het; ik maak duidelijk waar eventuele risico's liggen; ik geef een advies uit aan de opdrachtgever; ik leer hoe de applicatie werkt; ik leer wat de klant wilt; voordat een regel code wordt geschreven heb ik al een kwaliteitsslag gemaakt, zodat mijn developers minder fouten maken; ik test de opgeleverde code (of beter gezegd user story (of een deel daarvan) z.s.m.; ik zorg dat het systeem testbaar wordt opgeleverd. En zo kan ik nog wel even doorgaan.

Yogibeer schreef op zondag 19 april 2020 @ 10:16:
[...] Met name de testfase zorgt altijd voor veel vertraging (mogelijk terecht)

Als je een goed softwareontwikkelingsproces hebt, dan is testen onderdeel daarvan. Testen na bouwen is al te laat. Aparte testteams zijn ook niet meer van deze tijd. Testers zouden onderdeel van het scrumteam moeten zijn.

[pieter.a]

Muta schreef op dinsdag 28 april 2020 @ 00:18:
Ik gebruik de term systeemtesten nooit eigenlijk. Ik test een user story. Systeemtesten is wat mij betreft een achterhaalde term die niet meer nodig is. Al deze termen hebben zoveel verschillende interpretaties en verwachtingen opgeleverd in de hele IT-wereld. Ik heb in mijn werkzaamheden nog nooit de term systeemtest moeten gebruiken om duidelijk te maken wat ik doe.

Dat de term in jouw context niet relevant is maakt de term niet achterhaald.

Waar het om gaat is dat je in de context waar je werkt termen gebruikt die:
- enigzins aansluiten op normaal vak jargon en
- in de specifieke context zo goed mogelijk verwoordt wat er gebeurt en dat
- iedereen in die context een eenduidige definitie hanteert

Het woord systeemtest kan je prima gebruiken op een plaats waar meerdere losstaande systemen/applicaties bestaan. Bij een voormalige werkgever integreerden we meerdere applicaties tot een product voor een externe klant. Hierbij zou je de volgende test levels kunnen defiinieren:
- Systeem test, functionele tests uitgevoerd door de tester van onze leverancier (bv de website zonder externe koppelingen)
- Systeem integratie test, functionele test door tester van de integrator, met focus op integratie tussen alle systemen
- Acceptatie test, functionele test door vertegenwoordigers van onze opdrachtgever voor sign off van het project naar ons toe

Op alle drie niveau's kan natuurlijk sprake zijn van het testen van user stories.