Softwaretesters verenigt u 2: waar bugs nu features zijn

Je wilt echt geen watervalachtige trajecten na de sprint hebben waar het werk van meerdere teams gemerged, getest en gereleased wordt.

Op het moment dat er een verstoring in de pijplijn optreedt omdat een release langer loopt dan de sprint ben je fucked omdat een hele grote codebase staat te wachten om gereleased te worden (die nog niet stabiel is) en iedereen die vanaf dat moment iets nieuws wil bouwen moet hele oude code gebruiken (en later rebasen). Je krijgt dus ontzettend veel overhead en mergeconflicten.

Wat je wilt hebben is verregaande testautomatisering en het releasen van features zodra ze in-sprint getest en geaccepteerd zijn. In plaats van grote maar minder frequente releases ga je naar meer frequente maar kleinere releases, waarbij je per story een release doet (die relatief snel te testen is; zeker als je gebruik maakt van verregaande automatisering om te testen en te deployen).

Leuke reactie Vagere_Hein, dat is inderdaad wat zich soms voordoet. Bepaalde omgevingen moeten vrijgegeven worden rondom een in productie name maar dat kan nog niet omdat er ook nog 'werk voor nazorg' ligt.

Het antwoord wat je omschrijft, verregaande testautomatisering, en het releasen van features zodra ze in-sprint getest en geaccepteerd zijn is een hele goede. Ware het niet dat we hier te maken hebben met een offerte proces en contractaanvraag keten waar minimaal 4-6 dagen overheen gaat. Met name met nieuwe features die op bestaande keten ingrijpen. Je krijgt dus voor een minimale regressieset dus al 5-8 dagen doorlooptijd als je echt pech hebt.

Ik moet eerlijk bekennen dat we op dit moment druk aan het kijken zijn hoe we dit zo goed mogelijk kunnen laten landen, maar het enige alternatief waar ik aan denk is een compleet onafhankelijke ketenomgeving waarin een keten permanent staat. Zodra er dan sprints iets opleveren, plaats daar heen en laat ketentest lopen, blijf ondertussen lekker doorsprinten in de andere omgeving. Nadeel daarvan is nog steeds dubbel opslaan van code, wat enorm redundant is.

Ah jullie missen dus een van de letters in OTAP?

quote:

Op vrijdag 14 januari 2011 10:57 schreef Viking84 het volgende:
Er wordt niet zoveel gepost, zie ik, maar goed, ik zal dit topic ook even volgen.
Ben als een soort van plan B een carrière switch naar software tester aan het overwegen, maar wil me eerst goed oriënteren, onderzoeken of ik de benodigde competenties wel echt in huis heb etc (heb overigens neerlandistiek gestudeerd).

Je hebt WO-niveau. Je kan je goed concentreren schat ik, en ik denk dat je goed letterlijk kan lezen. Dat zijn pluspunten.

Lang geleden heb ik eens bij Sogeti gesolliciteerd, die namen destijds sollicitanten een grondige test af, met direct uitslag, en op basis van die uitslag bepaalden ze geschiktheid als tester. Kijk eens op de site, er stond een voorbeeldtestje en misschien staat er wel iets over de sollicitatieprocedure. _{Ik heb hun aanbod afgewezen .}

quote:

Op vrijdag 14 januari 2011 13:41 schreef Erlandil het volgende:
Toch nog een inhoudelijk discussie punt naar aanleiding van een wat oudere post omtrent scrummen.

Hoe zien jullie Scrum met meerdere teams in combinatie met een wat grotere applicatieketen?

Ik moet eerlijk bekennen dat sprints en een grote applicatieketen best wel grondig bijten. Om een goede ketentest uit te voeren ben ik soms even lang als een sprint bezig en dat werkt niet echt goed samen.

Ik vond het een ramp. De scrum functioneerde als een soort veredelde unittest, in de keten en als acceptatie werd gewoon niet getest. Maar er stond wel een goedkeuring van het testteam onder. Waardeloos.

Is het mogelijk als student een bijbaantje als software tester te vinden? Zo ja, weet iemand bedrijven die part time softwaretesters aannemen?

quote:

Op woensdag 19 januari 2011 19:07 schreef sigme het volgende:

[..]

Je hebt WO-niveau. Je kan je goed concentreren schat ik, en ik denk dat je goed letterlijk kan lezen. Dat zijn pluspunten.

Lang geleden heb ik eens bij Sogeti gesolliciteerd, die namen destijds sollicitanten een grondige test af, met direct uitslag, en op basis van die uitslag bepaalden ze geschiktheid als tester. Kijk eens op de site, er stond een voorbeeldtestje en misschien staat er wel iets over de sollicitatieprocedure. _{Ik heb hun aanbod afgewezen .}

Woensdag heb ik een test (niet bij Sogeti, maar elders). Ben benieuwd! Stiekem ben ik één van de weinige mensen die het leuk vinden om toetsen en examens te maken .

Viking mocht je echt op zoek zij, pm me maar. Wij nemen ook onervaren mensen aan die dan een 6 weken durende cursus krijgen ..en daarop dan ook feedback of je geschikt bent enzow

Beetje laat nog met reageren (dacht dat het topic niet meer bijgewerkt was ).

Nee, OTAP hebben we wel. O, ontwikkelomgeving, hierin zitten de ontwikkelaars om velerlei niveaus te werken, afhankelijk van het systeem hun eigen O omgeving of niet.
T: Testomgeving, hierin wordt een eerste oplevering gedaan voor ketentest.
A: acceptatieomgeving, productielike, hierin wordt eigenlijk een groot gedeelte van de FAT en GAT gedaan.
P: productie natuurlijk.

Waar wordt er nu gescrumd en opgeleverd? Antwoord: in O en T (mogelijk dat daar al de fout zit hoor). In ieder geval weet ik dat voor deelsystemen bepaalde testers in O druk aan het werk zijn. Voor specifieke services worden deze in een pre Test omgeving zelfs nog gezet, zodat ze al aan te roepen zijn vanuit O en T met een bestaande keten. Het probleem is echter, zodra er een release kalender gevolgd wordt, dan mag er voor ketentesten niets veranderen in T om deze succesvol naar A te zetten. En aangezien de A omgeving niet te lang mag afwijken van de P omgeving ivm productie incidenten...

Wat ik effectief doe is wachten tot ik een ons weeg voordat alle opleveringen naar T gedaan zijn, dan start de ketentest voor het totaal aan nieuwe features. Die test kost minimaal x aantal dagen afhankelijk van de functionaliteit. Aangezien er ook ingrijpen geweest zijn aan front office en backoffice kant ontkom ik er niet aan om alle onderdelen te moeten hertesten (plus, anders spreek je niet van end to end ketentest).

Vervolgens moet in A dan de boel nog eens dunnetjes over omdat die omgeving wel productielike is. Dat kost dus effectief 2-4 weken in T en dan nog eens 2-4 weken in A. Dat zijn dus 8 weken waarin de scrumteams ondertussen enkel in O bezig zijn, maar er kan daar blijkbaar geen volledige integratie plaatsvinden.

Ik zou dus eigenlijk zeggen dat we na T een aparte ketenomgeving zouden moeten hebben zodat die onafhankelijk van het scrum gedeelte getest kan worden. Helaas, dit is kostentechnisch niet mogelijk, dus ik blijf met een dilemma zitten voor wat betreft scrum/ketentesten.

quote:

Op woensdag 19 januari 2011 20:02 schreef MoneyTalks het volgende:
Is het mogelijk als student een bijbaantje als software tester te vinden? Zo ja, weet iemand bedrijven die part time softwaretesters aannemen?

Hmm.. ik moet eerlijk bekennen dat ik persoonlijk vind dat het vak tester een vak apart is. Sommige baantjes waarin je relatief weinig kunde nodig hebt kun je als bijbaantje doen, andere wat minder. Parttime werken als software tester is wel mogelijk, maar ook daar moet je blijven bijscholen en kennis opdoen. Verder moet je daar ook eigenlijk een eerste leertraject in hebben voordat je het 'goed kan'. In dat kader denk ik dat je als bijbaantje niet veel verder zult komen dan het niveau 'amateurtester'. En ik betwijfel of organisaties daar erg mee geholpen zijn.

TVP. Ik krijg binnenkort ook met software-testers te maken dus een extra inzicht is nooit weg.

Nee dat absoluut niet, maar ook niet op dag niveau, en zelfs niet op week niveau en soms zelfs niet op sprint niveau (mijns inziens).

Het grote dilemma alleen is wel dat indien je echt agile wilt gaan, dat je dan alle systemen waar mee gemoeid is wel staande moet houden. Er mag dus niet in het volgende systeem iets omdonderen. Dit gaat binnen een systeem dus nog wel goed, maar zodra je over systemen heen gaat wordt het ingewikkelder.

Programmeertaal.. goede vraag. Heb ik weinig mee te maken. Ik maak enkel gebruik van XML om services mee te checken. Er zit zowieso stukken JAVA in, binnen de services wordt spul van IBM gebruikt. Cordys is een onderdeel (geen idee in welke taal die werkt).

Eigenlijk bedenk ik me net hoe een continuous buildproces zich verhoudt tot een businessproces wat meerdere dagen overstijgt of zelfs tot aan een week of wat gaat. Zonder mogelijkheid tot tijdreizen per systeem of systemen gaat dit sowieso conflicten geven.

quote:

Op vrijdag 21 januari 2011 15:29 schreef Citizen.Erased het volgende:
TVP. Ik krijg binnenkort ook met software-testers te maken dus een extra inzicht is nooit weg.

Mag ik vragen op welk gebied je te maken krijgt met software testers? Misschien kunnen we dan ook al vragen beantwoorden die je mogelijk hebt?

quote:

Op vrijdag 21 januari 2011 15:28 schreef Captain_Fabulous het volgende:

[..]

Nee. Nee.
Part time softwaretesters bestaan wel, maar dat zijn dan mensen van de afdeling die het product gebruiken, en uitgeleend worden om te testen.

Euh, er bestaan ook wel echte softwaretesters die deeltijd werken .
Vorige klus als freelance testcoördinator was 16 uur/week. Daarvoor in vaste dienst 32uur/week.

Maar bijbaantjessoftwaretesters ben ik nog nooit tegengekomen, en het lijkt me er ook niet geschikt voor.

quote:

Op vrijdag 21 januari 2011 15:35 schreef Captain_Fabulous het volgende:
1 van de dingen die echt moeten als je gaat scrummen, is dat je requirements gaat opknippen in hapklare brokken. Idealiter, worden alle changes zo klein opgeknipt dat een programeur ze in 1 dag af krijgt. Dat lijkt me bij jou al een probleem, als ik het zo hoor.

Ja, dat is absoluut wel een probleem. Ik zal eerlijk bekennen dat wat dat betreft het requirementsproces uberhaupt een ramp is. Maar dat neemt niet weg dat je, zelfs al heb je het zo klein opgeknipt dat je dan alsnog een probleem hebt. Als je op dag 1 iets wijzigt in programmatuurcode a kan dit op systeem niveau prima werken. Maar zodra je dan over een hele lange keten heen gaat kijken waarin een offerte van aanbod naar contract en financiele verwerking moet dan is een wijziging halverwege zo'n looptijd dus funest. Met name tijdtechnisch gaan we dan vaak nat (ook het uitrollen van een nieuw stukje code kan precies op moment T vallen waardoor die keten onderbroken is).

Vandaar ook mijn eerste vraag zo. Eigenlijk moet ik de vraag dus nog beter stellen, hoe verhoudt scrum zich tot een hele lange keten met afhankelijkheden van ook legacy systemen. (in dit geval een mainframe wat niet 24/7 open is maar van 10-17) en een doorlooptijd van meerdere dagen.

quote:

Op vrijdag 21 januari 2011 15:32 schreef Erlandil het volgende:

[..]

Mag ik vragen op welk gebied je te maken krijgt met software testers? Misschien kunnen we dan ook al vragen beantwoorden die je mogelijk hebt?

Ik kom terecht in een projectmanagement-team. Het ontwikkelen en vervolgens testen van bepaalde software is een onderdeel van dat project. Ontdekte dat er op dit moment nog niet echt gestructureerd getest wordt en dat daar dus nog wel enige verbetering in aan te brengen is.

quote:

Op vrijdag 21 januari 2011 15:52 schreef Citizen.Erased het volgende:

[..]

Ik kom terecht in een projectmanagement-team. Het ontwikkelen en vervolgens testen van bepaalde software is een onderdeel van dat project. Ontdekte dat er op dit moment nog niet echt gestructureerd getest wordt en dat daar dus nog wel enige verbetering in aan te brengen is.

Oeh, dan wil ik graag een heel brutaal adviesje geven. Probeer gelijk te achterhalen of er iemand specifiek verantwoordelijk is voor het testen van de ontwikkelde software, zowel door de ontwikkelende partij als de accepterende. Liefst voor beide. Indien deze er niet is (en met name niet op projectmanagement niveau) dan aan de bel trekken. Dat gaat je waarschijnlijk een hoop kosten schelen als je daar nu al iemand voor hebt die het testproces voor je in kaart brengt.

En uiteraard, als dit niet mogelijk is, probeer dan te achterhalen wat de verantwoordelijkheden zijn van de software testers zelf. Hieruit kun je ook een hoop zaken afleiden waar je 'winst' mee kunt halen.

quote:

Op vrijdag 21 januari 2011 15:58 schreef Captain_Fabulous het volgende:

[..]

Niet. Ik kan me voorstellen dat je na een scrum periode, de changes van de verschillende teams samenvoegt, en die dan door die keten heen jaagt. Terwijl dat gebeurt, gaat het scrumteam gewoon verder met ontwikkelen. Een scrumteam is een klein softwarefabriekje, waar afgevaardigden in zitten van alle disciplines. Het moet niet veel groter zijn dan een man of 8.
Niet elke organisatie is er geschikt voor, het vergt wennen, leren en aanpassen.

Tja.. daar neig ik dus ook heel erg naar. Een aparte ketenomgeving waarin gewoon om de zoveel tijd (zeg maar release kalender) een boel nieuwe stukjes gehangen worden en afhankelijk daarvan de boel naar A en P knikkeren. Ik ben me ook wel goed bewust van het feit dat onze scrumteams van foutieve samenstelling zijn (business ontbreekt soms, test ontbreekt soms, er is een apart scrumteam voor ontwerp )

Ik ga met bovenstaande post helemaal mee
(en ook met het 'creatieve scrummen' , dit kwam ook reeds uit onze evaluatie van testteam)

quote:

Op vrijdag 21 januari 2011 15:22 schreef Captain_Fabulous het volgende:

[..]

Je vermoeden klopt als een bus. Als je echt Agile wil gaan, zul je eigenlijk ook een continuous build proces moeten hebben. DWZ, dat als een programmeur een nieuw stuk code maakt (of veranderd), deze wordt ingechecked. Op dat moment wordt er een aparte versie gebouwd, die op dat punt alleen toegankelijk is voor de betreffende programmeur. Over die versie wordt een eerste bak unittests gedraaid. Geven die geen fouten, dan wordt de versie automatisch gedeployed.
Dus je hebt eigenlijk meerdere releases per dag, als de programeurs een beetje doorpezen kan je elk uur een nieuwe release hebben.
Ik heb zo'n vermoeden dat julie daar nog niet helemaal zijn, qua proces.

Agile is gek, maar OTAP en agile kunnen elkaar ook redelijk bijten (als je echt snel als een madderfakker wil gaan doe je niet aan otap, gewoon alleen O en misschien A).

Bovendien hoeft Agile niet elke dag een oplevering te zijn, agile is meer een manier van werken dan wat anders. Iedereen valt een beetje over elkaar heen dat agile perse snel en kort moet zijn, maar dat is niet waar. Zelfde idee als dat requirements en ontwerpen niet nodig zijn bij agile (blabla geen tijd etc), maar dat heeft niets met agile te maken.

IMHO is agile niet meer dan een hele dynamische manier van werken, waarmee je in korte iteraties en met korte lijnen tussen ontwerp-bouw-test zo snel mogelijk resultaat wilt halen. Soort van prototyping on steriods.

De hele invulling van een agile werkmethode staat vrij los, hoewel er een aantal kenmerken als scrum en daily standups zijn die wel vereist zijn. Oja, en een team van mensen die goed met elkaar kunnen werken, flexibel en communicatief vaardig zijn is ook wel handig.

Hmm. ja, ergens is Agile en OTAP natuurlijk in beginsel conflicterend. Het ene gaat uit van alles in een keer en het andere gaat uit van een gefaseerd model.

Verder, volledig eens dat het een dynamische manier van werken is waarin vaak de misstap gemaakt wordt dat requirements en ontwerp er minder (of niet) toe doen.
Maar dan nog, het kenmerkt zich wel door relatief vaak en snel kleinere delen opleveren (wel werkend uiteraard). Dit is ook de reden dat het vaak naar management gecommuniceerd wordt als zijnde: ' kan snel iets opleveren' --> korte time to market producten. Maar dat is dus lang niet altijd waar als aan de grondbeginselen getornd wordt.

quote:

Op vrijdag 21 januari 2011 22:26 schreef Erlandil het volgende:
Hmm. ja, ergens is Agile en OTAP natuurlijk in beginsel conflicterend. Het ene gaat uit van alles in een keer en het andere gaat uit van een gefaseerd model.

Verder, volledig eens dat het een dynamische manier van werken is waarin vaak de misstap gemaakt wordt dat requirements en ontwerp er minder (of niet) toe doen.
Maar dan nog, het kenmerkt zich wel door relatief vaak en snel kleinere delen opleveren (wel werkend uiteraard). Dit is ook de reden dat het vaak naar management gecommuniceerd wordt als zijnde: ' kan snel iets opleveren' --> korte time to market producten. Maar dat is dus lang niet altijd waar als aan de grondbeginselen getornd wordt.

Het argument is inderdaad vaak; ja we gaan agile doen want dan hebben we snel resultaat.
Overigens kunnen agile en otap elkaar heel goed aanvullen, maar dan moet je je agile traject wel wat structureren. En structuur is op 1 of andere manier altijd een woord wat mensen die agile doen niet tof vinden, net zoals plannen

Hmm ja, dat is zeker waar. Ik moet wel eerlijk zeggen dat we hier zowel een documentatie probleem alsook wel een specifiek ontwerp team, dus die documentatie wordt er wel heel belangrijk van. Het is alleen nog wel zo, eerst ontwerpen, en dan verder scrummen voor de uitwerking. Wat natuurlijk ook al raar is. Komt ook nog eens bij dat mensen van ontwerp lang niet alle onderdelen helder voor ogen hebben.

Verder is het acceptatieproces nu ook ter discussie

Laten we hopen dat het voor komend jaar wat anders ingericht gaat worden (dan zijn we ook effectief in beheer.. dat is ook al wat apart )

Ik had me dit jaar voorgenomen om vooral niet te cynisch te beginnen.. Ik zondigde al gelijk na het eerste overleg

maar goed, voorlopig hebben we voor de komende release een hele zware No Go afgegeven, ons advies is om dit vooral niet in productie te nemen. Sterker nog, niet eens in acceptatie te zetten. Ik heb na 2 weken nog geen enkele succesvolle keten scenario gezien

quote:

Op vrijdag 21 januari 2011 15:59 schreef Erlandil het volgende:

[..]

Oeh, dan wil ik graag een heel brutaal adviesje geven. Probeer gelijk te achterhalen of er iemand specifiek verantwoordelijk is voor het testen van de ontwikkelde software, zowel door de ontwikkelende partij als de accepterende. Liefst voor beide. Indien deze er niet is (en met name niet op projectmanagement niveau) dan aan de bel trekken. Dat gaat je waarschijnlijk een hoop kosten schelen als je daar nu al iemand voor hebt die het testproces voor je in kaart brengt.

En uiteraard, als dit niet mogelijk is, probeer dan te achterhalen wat de verantwoordelijkheden zijn van de software testers zelf. Hieruit kun je ook een hoop zaken afleiden waar je 'winst' mee kunt halen.

Dat zijn ook zaken die ik zeker ga doen. Het daadwerkelijk gestructureerd testen van de ontwikkelde software staat daar nog in de kinderschoenen en zag daarin al een aantal verbeterpunten.

Lees hier even mee om te kijken wat er een beetje speelt bij het testen van software en wat voor technieken daarvoor gebruikt worden.

Tip van de dag, probeer ze zover te krijgen om een consult te krijgen van gespecialiseerd extern bedrijf. Advies van buitenaf wil vaak wel een beetje helpen

Advies is niet gratis, maar kan wel veel opleveren.

Jep, zeker voor eenmalig inzicht in je situaties zijn zaken als Quickscans zeer nuttig, bijvoorbeeld van TPI (next) of TMMI.

Geven vaak een heel grondig inzicht in de situatie en hoeft niet veel te kosten. Het kan je wel de punten geven die je kan oppakken ter verbetering.

Wat een rust hier
Valt er nog wat te testen?

Er valt altijd wat te testen, de vraag is alleen of er budget is

quote:

Op donderdag 18 augustus 2011 10:44 schreef Bla_Bla_Bla het volgende:
Er valt altijd wat te testen, de vraag is alleen of er budget is

True, hier idem dito.

quote:

Op donderdag 18 augustus 2011 09:54 schreef Kapt-Ruigbaard het volgende:
Wat een rust hier
Valt er nog wat te testen?

Ben deze week begonnen aan een nieuwe baan. Als tester natuurlijk.

Er valt veels te veel te testen. In de categorie van: in januari zaten we met 6 man.. nu met 18 .

Ik heb een lijstje met 21 musthave functionaliteiten, (waarbij een gemiddelde release niet meer dan 6-8 stuks heeft) en dan vinden ze het vreemd dat ik aangeef dat we het niet gaan halen met de huidige planning (1 normaal release window )

Maar verder.. ja hoor, ik vermaak me prima. Gedraag me af en toe als ontwerper, ontwikkelaar, projectleider, scrummaster, testmanager, functioneel beheerder en nog wat van diens soort.. en oh ja, soms test ik ook nog wat

Zo, hoe staat het eigenlijk in het softwaretesterswereldje?
Hier in het noorden is de markt slecht. Gelukkig vond ik toevallig een half jaar geleden een baan bij een bedrijf dat na een halfjaarcontract gewoon een vast dienstverband geeft, dus ik ben voorlopig onder de pannen. Na mij zijn er zelfs nog 3 (!) nieuwe testers bijgekomen, wat het testteam nu 6man sterk maakt, op zo'n 30 ontwikkelaars.

Bij dit bedrijf wordt druk geexperimenteerd met nieuwe ontwikkel- en testmethoden. Sinds kort de hele boel omgeturnd naar SCRUM, en ik verwacht dat in het komend kwartaal er stevig begonnen gaat worden met geautomatiseerd testen.

En jullie?

[ Bericht 0% gewijzigd door sigme op 28-02-2012 20:03:51 ]

Ik denk dat ik mee ga met Captain_Fabulous, maar dan wel met de kanttekening dat er voor goede testmanagers ook nog wel zat werk is. Maar dan wel de nadruk op goede. Het lijkt wel alsof met alle budgetdiscussies allover heel snel het kaf van het koren gescheiden raakt. Bij sommige clubs vliegen de testmanagers er met bakken uit en dat wat overblijft bakt er weinig van. Betekent dan wel dat degene die verlaten, ergens anders in ieder geval beter werk gaan leveren dus ergens moeten er wat bedrijven zijn die flink profiteren en de juiste mensen hebben.

Voor mezelf: ach, tblijft hetzelfde, een stukje omscholen en veel nieuwe dingen oppakken en breder inzetbaar zijn dan enkel tester maakt het aanzienlijk makkelijker om ergens te blijven plakken. Ik verwacht ook voorlopig niet dat ik zonder klus kom te zitten.

Bij ons wordt het ook steeds drukker. Recessie merken we helemaal niks van. Gaat het slecht met de consument gaat het goed met de overheid.

Scheelt dat we software maken. Wat in alle Branches gebruikt wordt.

Afgelopen 3 jaar 30 medewerkers erbij gekregen waarvan 4 testers op een bedrijf van 110 man. We zitten nu met 10 Testers.

Hier, hier is Amsterdam, is de markt wel kut voor de middelmatige tester.
Nu werk ik wel voor een grote detacheerder en ik zie duidelijk dat de tarieven enorm onder druk staan. Betalen willen voor een junior tester maar een senior test manager willen hebben. De markt waar wij het moeten van hebben, vooral de grote financials, zijn toch flink aan het bezuinigen. Net zoals het bedrijf waarvoor ik werk.

Maar een goede tester vind altijd wel werk (al duurt het vinden soms wat langer dan voorheen)

Als starter op de arbeidsmarkt is het enorm moeilijk op dit moment iets te vinden, ben al 2 maanden werkloos

Kent iemand nog wat functies?

Ik weet een hele hoop functies.
Bedoel je geen vacatures?