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 )