Softwaretesters verenigt u 2: waar bugs nu features zijn

Gelegenheids tester.. error guessing en dan niet weten wat je gedaan hebt om iets te produceren

Dan is exploratory testing toch een fijnere situatie, alles wat je doet documenteer je en daar valt in ieder geval wat uit op te maken.

In ieder geval, ik denk dat het wat mij betreft wel goed zit, klussen lopen langzamerhand weer op, zijn al weer aardig wat intake's geweest. Het lijkt erop dat de projecten langzaamaan weer opkomen, tis wel knokken maar voor wie goed werk levert is er best wat mogelijk.

Mooi dat de klussen weer komen.

90% van de tijd weet ik wel wat ik gedaan heb, alleen die 10% zijn vaak de meeste vreemde features...

Ik zie de headhunters de laatste tijd weer zeer actief worden.
Ineens vanuit het niets ben ik 6x benaderd in de afgelopen maand.

*meldt*

Tegenwoordig is 'agile' en 'scrummen' bij ons een hele hype. Alle projectteams stuntelen nu met die gele post-its overal

Heeft iemand ervaring met het testen in dit soort projecten? Merk nu al dat requirements toch vooral niet gefixeerd worden en erg wazig worden vastgelegd 'omdat ze kunnen wijzigen'. Maar dat schiet weinig op met het schrijven van testspecs. Of juist wel, want onze huidige reqs zijn zo globaal dat je ze in 1 minuut hebt weggetest

De meest efficiente methode voor mezelf van testen vind ik meestal gewoon exploratory met een logje erbij zodat je weet wat je getest hebt en welke cases je allemaal geprobeerd hebt. Maar nu we heel fanatiek voor het eerst in de geschiedenis van ons bedrijf begonnen zijn met echt grote hoeveelheden architectuur en requirement docs opstellen wil je wellicht toch een iets formelere aanpak. Iemand ideeen?

Enige testbasis in agile komt uit je sessies die je met de klanten etc houdt. Dat zijn dus gewoon 'notulen' met aandachtspunten waar je naar zou moeten kijken. Het invullen van testen is puur afhankelijk van de tester. Documenteren wat je doet is dan wel weer erg handig voor de toekomst.

Zodra je testbasis hebt zou ik die ook gestructureerd gaan testen. Dus met je testbasis reviewen, scripts opstellen (al dan niet met bepaalde technieken) en dan uitvoeren. Dat is algemeen gezien nog altijd de beste manier.

Tijd om dit topic weer eens te schoppen. Zo af en toe ontvang ik een PM over testwerk, en dan zit er meer kennis in dit topic dan in mijn hoofd .

Mijn huidige klus als testcoordinator is bij een project waarin data geconverteerd wordt en er geen software ontwikkeld wordt (behalve wat conversiesoftware, maar die is tijdelijk). Weer eens een andere belevenis. Het laatste deel van de conversie blijkt zo lastig dat deze handmatig uitgevoerd gaat worden, daarmee vervalt de meeste testnoodzaak wel. Ik ben gevraagd om niettemin nog even te blijven om dit proces (en vooral bijbehorende rapportage) op poten te zetten. Ook wel weer eens leuk - niet testen, haha.

Als ik het topic eens doorlees ik zie dat klusjes toch een beetje tricky zijn in deze branche. Ik werd laatst door een vriend van een recruitmentbureau benaderd voor testwerk omdat hij wist dat ik iets 'it-erigs' doe. Ik heb zelf geen interesse, maar als iemand nog iets zoekt in het zuiden des lands kun je een pbtje sturen en breng ik jullie met elkaar in contact.

quote:

Op zondag 5 december 2010 11:54 schreef sigme het volgende:
Tijd om dit topic weer eens te schoppen. Zo af en toe ontvang ik een PM over testwerk, en dan zit er meer kennis in dit topic dan in mijn hoofd .

Mijn huidige klus als testcoordinator is bij een project waarin data geconverteerd wordt en er geen software ontwikkeld wordt (behalve wat conversiesoftware, maar die is tijdelijk). Weer eens een andere belevenis. Het laatste deel van de conversie blijkt zo lastig dat deze handmatig uitgevoerd gaat worden, daarmee vervalt de meeste testnoodzaak wel. Ik ben gevraagd om niettemin nog even te blijven om dit proces (en vooral bijbehorende rapportage) op poten te zetten. Ook wel weer eens leuk - niet testen, haha.

Je zit nu zeker bij De Bank?

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

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

dus mierenneuken over taalgebruik kan je alvast,

Kan je FO's lezen?
Kan je gestructureerd werken?
Kan je duidelijk communiceren met business mensen en met ontwikkelaars?
Heb je een beetje kennis van IT?
Woon je niet heel erg afgelegen?
Trekt het je om veel achter een pc te zitten of in iets te lange vergaderingen plaats te nemen?

Zo ja,
goed plan.

Toch ook weer eens even hier posten gezien het feit dat het vorig jaar toch langzamerhand beetje verslofte.

Ik heb onderhand mijn vaste contract al sinds augustus/september en voorlopig blijft de opdracht waar ik zit druk lopen. Als ik zo de bedrijfsgeluiden hoor trekt de markt in ieder geval goed aan maar het onderscheidend vermogen is wel belangrijk. Ik weet in ieder geval dat het ambitieniveau van de werkgever waar ik nu zit in een groeifase zit en de bijbehorende opdrachten zijn er ook wel naar. Er komen in ieder geval wat mensen bij de laatste paar maanden en dat is toch een positief geluid.

Verder, voor Viking84 (ik zag je andere topic net ook voorbijkomen met een link hier) Carriereswitch is altijd mogelijk. Om een indicatie te geven, een groot gedeelte van mijn directe collega's komen uit van allerhande vakgebieden. Biologen, chemici, bedrijfskundigen, docenten, rechten, ontwikkelaars noem maar op. Al deze mensen zijn nu uiteindelijk kwaliteitsanalist wat zich voornamelijk focused op Software Testen. Echter, het vakgebied is natuurlijk veelomvattender dan enkel dat.

Dat wat Soohr aangeeft is al een eerste lijstje, wat overige punten die mijns inziens ook erg van belang is:
-Kun je logisch nadenken, cq een analytische blik ergens op loslaten zonder dat je de inhoud kent?
-Kun je een vertaalslag maken van zaken die door de ene partij verteld worden naar 'taal' die door een andere partij gesproken wordt? Dit uit zich voornamelijk in de discussies tussen business en ict.
-Heb je een overtuiging om zaken kwalitatief beter te willen maken/zien? Een heel simpel voorbeeld wat ik vaak gebruik: bij een huis huur je een architect in om iets voor je te ontwerpen, daarna een bouwer en gaandeweg de bouw controleer je zelf of het inderdaad wordt wat je wilde. Bij een IT landschap is dat hetzelfde, alleen de controle of het inderdaad wordt wat je wilde uit zich in vele vormen van testen.

Verder zag ik in je topic ook nog een vraag omtrent specialisatiemogelijkheden. Die zijn er altijd, sommige mensen zijn heel sterk in bepaalde testsoorten, sommige vinden het leuk om generalist te zijn. Ik zit persoonlijk op dit moment met een dubbelrol in systeemtest en gebruikersacceptatietest. Aan de ene kant probeer ik aan te tonen dat wat IT oplevert voldoet aan hoe het gespecificeerd was, en aan de andere kant probeer ik aan te tonen dat het ook te accepteren valt door de business. Dat wil ook zeggen dat ik zaken constateer zoals 'verkeerde' wensen aan het begin. Veranderende wensen bijvoorbeeld.

Voor de overige lui: hoe gaat het nu met mensen in het gebied? nog druk met opdrachten? Expertise vraagstukken oid

"Ik probeer aan te tonen dat"
bedoel je niet
"Ik probeer aan te tonen of" ?

Dank voor je uitgebreide reactie, Erlandil.
Ik kan een heleboel , maar deze specifieke context is nieuw voor mij en dat maakt me een tikkeltje onzeker. Ik vrees dat het nemen van de gok de enige manier is om erachter te komen of dit iets voor me is .

Maak je geen zorgen VIking84, ik denk dat iedereen wel kan testen. Het belangrijkste is dat je het werk leuk vindt.

quote:

Op vrijdag 14 januari 2011 13:29 schreef Maanvis het volgende:
Maak je geen zorgen VIking84, ik denk dat iedereen wel kan testen. Het belangrijkste is dat je het werk leuk vindt.

Gelukkig is het iets waar ik wel vrij snel achter kan komen, dat werkt wel drempelverlagend. Het zou zonde zijn om weer in een opleiding van jaren te moeten investeren.

Ben ik niet helemaal met je eens Maanvis op zich is de stelling wel correct: iedereen kan testen, echter, 'goed' testen is toch echt een vak apart. Komt een beetje in de trant van: iedereen kan een hamer vast houden dus iedereen kan timmerman zijn. En ik ga er een beetje vanuit dat we het vak timmerman toch ook wel als specialisme zien (iig tot op zekere hoogte)

(oh zie net de taaltechnische in correctheid: maakt weinig uit volgens mij, maar 'of' is misschien beter idd)

Voor Viking84 weer, een heleboel kunnen zegt mij dan weer niets Ik weet enkel dat voor het bedrijf waar ik werk er een analytische en persoonlijkheids test aan ten grondslag ligt. Die test heeft het vaak wel bij het rechte eind voor wat betreft de serie eigenschappen waaraan waarde gehecht wordt. De focus op diploma's wordt hierdoor minder. Ik moet eerlijk bekennen dat de context van software tester eigenlijk ook zo onzeker kan zijn. Je hebt de traditionele manier van testen (dwz iemand bouwt wat, iemand test het, en akkoord, in productie nemen erbij) maar de laatste tijd lijkt het vakgebied zich ook verder te ontwikkelen naar meer testen als kwaliteitsmaatregel. Hierbij moet je denken aan requirementsmanagement, reviews, inspecties/audits. Hierbij gaan ook de nodige gedachten over wat je met je IT landschap wil bereiken als organisatie in mee.

In dat opzicht is de functie van software tester zo klein en zo groot als je maar kan bedenken. Ik zie veel mogelijkheden weggelegd voor taken die zich aan het randje van simpel testen bevinden en daarmee vaak onder mijn vakgebied komen.

In dat opzicht zie ik ook een continue ontwikkeling voor mijzelf trouwens. Het vakgebied groeit, en ik daarin ook. Ik heb aan de ene kant een hoop certificaten voor testen al gehaald, aan de andere kant zijn sommige al misschien achterhaald. Je blijft continu bij leren om het beter te doen.

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.

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.

Moet je een ketentest wel onderdeel willen laten zijn van een sprint?
Lijkt mij niet.

nee, dat is het in feite ook niet. Alleen er wordt na elke sprint iets 'opgeleverd' echter, zodra er een keten test van start gaat mag er niet meer opgeleverd worden. Dus je krijgt eigenlijk een dilemma dat je na een x aantal sprints niet meer effectief verder kan scrummen en weer een soort van waterval idee krijgt. Wordt alleen nog niet zo volledig gezien door het project.

En vanuit testoogpunt zou ik eigenlijk argumenteren dat het ook zo ingesteld moet worden. Scrummsprints om software op te leveren in een periode en daarna een waterval om de keten en gat uit te voeren.

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.