Maarreh.. steken onder water? Ik vind het niet kunnen!
quote:Ik ook niet maar als het zo in de URS staat moet je het zo wel testenOp donderdag 18 juni 2009 13:48 schreef Erlandil het volgende:
Deeltje 2
Maarreh.. steken onder water? Ik vind het niet kunnen!
een aanname, dan gaat het fout
quote:Op donderdag 18 juni 2009 14:00 schreef Fugie het volgende:
steken onder water zijn moooi.
Ik mag wensen van de business doorvertalen naar aanbouw. En ik vind steken onder water niet kunnen. Bugs daarentegen... lekker laten zitten
.Nope, zit voornamelijk aan de FO kant van het verhaal en de daarbij gekoppelde testinspanning (Fat/Gat).
Maar omdat het tegelijkertijd 1e lijns support onder dezelfde groep valt loopt het wel eens door elkaar heen.
.De enige echt relevante was deze:
Maar die vind ik crappy getekend.
dilbert ftw
)[ Bericht 83% gewijzigd door LadyXochi op 19-06-2009 18:07:55 ]
quote:Uhmmm... Ik zou niet meer weten wat de fouten precies waren, maar als je aan een kopie van het examen kunt komen, wijs ik ze met alle plezier aanOp vrijdag 19 juni 2009 08:43 schreef Captain_Fabulous het volgende:
@LadyXochi : kun je mischien nog erugkomen op die spellingsfouten in het examen? Dan kan ik het doorgeven om ze eruit te halen....
Als je je eigen examen in wil zien, kost het ¤ 60,- en je moet ervoor naar Duitsland.
Maar ik kan me in ieder geval wel herinneren dat er minimaal 3 fouten in zaten.
(PS: Heb lerarenopleiding Engels gedaan, dus ik weet ze er meestal wel uit te halen
)quote:
quote:Van wat ik van Dilbert heb gezien zijn de grappen meestal ten koste van de testers. NOT the kind of comics I was looking for. Tenzij je een aantal specifieke hebt...Op vrijdag 19 juni 2009 16:40 schreef Erlandil het volgende:
[ur]http://madhusudhan.info/Comics/Dilbert/[/url]
dilbert ftw
(En controleer je tags... En link op z'n minst naar de officiële Dilbert site....)
Nog leuke bugs gevonden?
Of moet ik even kijken of ik een leuk discussiepunt kan verzinnen om de boel hier levend te houden...
Bijvoorbeeld... de zin en onzin van een MTP/DTP.
Iemand daar een mening over?
quote:
Dit plaatje is alleen van toepassing wanneer de testers en het testproces in orde zijn. Als dat niet in orde is wordt er ook niks gevonden en is de WTF/min score ook erg laag.
[ Bericht 12% gewijzigd door #ANONIEM op 09-07-2009 20:15:22 ]
Hoe is het momenteel op de markt?
Bij de financiele instellingen is het momenteel dramatisch ervaar ik.
de uitstel datum ook niet,
dus ben ik tot eind januari onder de panne.
Ik heb in elk geval tot mei/juni een opdracht. Helaas wel ongeveer 1,5 uur rijden.
quote:en weer uitstel,Op woensdag 11 november 2009 11:14 schreef Soohr het volgende:
zoals altijd is de geplande live datum niet gehaald,
de uitstel datum ook niet,
dus ben ik tot eind januari onder de panne.
tot eind maart onder de panne
quote:nog kans op verlenging of moet er nu een nieuwe opdracht komen?Op woensdag 3 februari 2010 09:02 schreef Captain_Fabulous het volgende:
Tot 1 april 'veilig'....en dan zien we wel weer.
Contract loopt tot juni en gezien het feit dat er sinds januari 4 nieuwe mensen begonnen zijn en er al weer sollicitanten lopen denk ik niet dat het nog zo'n vaart zal lopen. Maar goed, je weet het nooit, ik hoop toch wel dat er weer wat opdrachten aankomen. Bankzitten is niet alles ( wel genoeg tijd voor studie
).Ben op dit moment bezig met documentatie over RUP, stukje ervaringsdocumentatie.
Heerlijk dat error guessing... Helaas wordt de productontwikkeling af en toe goed gek van mij
en het dan niet meer weten te reproduceren.... Ja.. ik klikte hier 20 keer op... en toen kreeg ik dit...
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.
90% van de tijd weet ik wel wat ik gedaan heb, alleen die 10% zijn vaak de meeste vreemde features...
Ineens vanuit het niets ben ik 6x benaderd in de afgelopen maand.
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?
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.
.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?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.
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,quote:
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).
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.
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
bedoel je niet
"Ik probeer aan te tonen of" ?
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 
.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.quote:
Maak je geen zorgen VIking84, ik denk dat iedereen wel kan testen. Het belangrijkste is dat je het werk leuk vindt.
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.
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?quote:
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.
Lijkt mij niet.
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.
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).
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.
Je hebt WO-niveau. Je kan je goed concentreren schat ik, en ik denk dat je goed letterlijk kan lezen. Dat zijn pluspunten.quote:
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).
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
.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.quote:
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.
Woensdag heb ik een testquote: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
(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 .).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.
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.quote:
Is het mogelijk als student een bijbaantje als software tester te vinden? Zo ja, weet iemand bedrijven die part time softwaretesters aannemen?
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.quote:
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).
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.
Wat voor soort programeertaal/omgeving is het?quote:
Dat zijn dus 8 weken waarin de scrumteams ondertussen enkel in O bezig zijn, maar er kan daar blijkbaar geen volledige integratie plaatsvinden.
Nee. Nee.quote:
Is het mogelijk als student een bijbaantje als software tester te vinden? Zo ja, weet iemand bedrijven die part time softwaretesters aannemen?
Part time softwaretesters bestaan wel, maar dat zijn dan mensen van de afdeling die het product gebruiken, en uitgeleend worden om te testen.
Voor het uitvoeren van software tests worden soms wel uitzend krachten gebruikt, als het om vrij dom invulwerk gaat. Dan ben je geen software tester. Maar een uitvoerder, die gewoon een lijstje moet afwerken.
Testen is meer dan wat lukraak op knoppen drukken en door een applicatie heen wandelen.
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).
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:29 schreef Citizen.Erased het volgende:
TVP. Ik krijg binnenkort ook met software-testers te maken dus een extra inzicht is nooit weg.
Euh, er bestaan ook wel echte softwaretesters die deeltijd werkenquote:
[..]
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.
.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.
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).quote:
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.
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.
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:
[..]
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?
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.quote:
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.
Niet elke organisatie is er geschikt voor, het vergt wennen, leren en aanpassen.
ja, je kan deeltijd werken, maar dan ben je wel fulltime testerquote:Op vrijdag 21 januari 2011 15:37 schreef sigme het volgende:
[..]
Euh, er bestaan ook wel echte softwaretesters die deeltijd werken
Met alle kennis, training en ervaring die nodig 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.quote:
[..]
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.
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.
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 ontwerpquote:
[..]
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.
)Bedrijven geven vaak een eigen draai aan ontwikkelmethodes, maar dit klinkt heel, uh, aardig zeggen, 'creatief'
Nog brutaler, is er eigenlijk wel een goede acceptant? Die ook zich dusdanig gedraagd? Als de softwaretesters iemand nodig hebben die knopen kan doorhakken als het onzeker is of iets volgens specificatie is bijvoorbeeld, is die er dan?quote:
[..]
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.
Inderdaad...aan wie geven de testers input? Wat voor soort? Er zijn bedrijven waar projectmanagers een go/no go beslissing laten maken door de testafdeling. Lekker makkelijk, maar dus ook fout. Testers geven inzicht in risiko's en kwaliteit. De acceptant moet beslissen of je ermee live gaat. Als tester speel je een belangrijke riool in dat proces, maar je bent geen beslisser!quote: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.
(en ook met het 'creatieve scrummen' , dit kwam ook reeds uit onze evaluatie van testteam)
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).quote:
[..]
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.
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.
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.quote:
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.
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
Omdat je beter snapt wat je doet kun je de zaken beter, korter, gerichter documenteren. Maar sommige mensen noemen zodra ze Agile gaan alle documentatie 'waist' . Dat is best jammer.
En ja, je krijgt snel EEN resultaat. Maar acceptant en management zullen moeten accepteren dat ze soms functionaliteit in brokken opgeleverd krijgen. Uitgangspunt zal dan wel zijn dat elke opgeleverde componenten waarde heeft voor de business, maar het zal niet gelijk zijn wat ze willen. Als dat niet goed gesnapt wordt, kun je na een paar iteraties, halverwege het project (om zo te zeggen) last krijgen van management dat niet snapt dat het nog niet af is 'want je zou sneller gaan werken met dat Agile gedoe!'.
Je moet echt committent hebben van hoog in de boom om succes te 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
)Maar goed dat je de moed er in houdt, testers moeten altijd oppassen niet te cynisch te worden
We hebben best een leuk vak tenslotte.
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
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.quote:
[..]
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.
Lees hier even mee om te kijken wat er een beetje speelt bij het testen van software en wat voor technieken daarvoor gebruikt worden.
Advies is niet gratis, maar kan wel veel opleveren.
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.
Valt er nog wat te testen?
True, hier idem dito.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
Ben deze week begonnen aan een nieuwe baan. Als tester natuurlijk.quote:
Wat een rust hier
Valt er nog wat te testen?
.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
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 ]
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.
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.
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)
Kent iemand nog wat functies?
Bedoel je geen vacatures?
Zonder iets van een regio-aanduiding lijkt het me lastig om zelfs maar een tip te kunnen geven.quote:
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 zit in het noorden, en ik zou op dit moment niet iets weten voor een starter.
Wat is de going-rate ongeveer voor een windel adminstrator bij IBM met 2 jaar werkervaring
Nee verkeerde adres.quote:
Misschien zit ik hier aan het goede adres
Wat is de going-rate ongeveer voor een windel adminstrator bij IBM met 2 jaar werkervaring
Een idee waar ik het moet zoeken?quote:
2 keer de helftquote:
moet je gaan solliciteren, kom je er vanzelf achterquote:
Ik zal jullie verder niet meer storen
Best wel dom ja, om in het verkeerde topic een vraag te stellen en wanneer aangegeven wordt dat je verkeerd zit alsnog een antwoord te verwachten.quote:
Dom van mij omvan een stel autisten een serieuze reActie te krijgen
Ik zal jullie verder niet meer storen
Maar he.. dat is DAM he
Ik zou er bijna een defect voor aanmaken.
Een goede tester verdiend zat. Bij ons ligt er aan hoeveel werk ervaring je hebt.quote:
Dom van mij omvan een stel autisten een serieuze reActie te krijgen
Ik zal jullie verder niet meer storen
Maar een tester met 5 jaar werkervaring verdient minimaal ¤3250,-
Mag toch hopen dat mijn baas er dit jaar wat meer bij gaat doen :pquote:
[..]
Een goede tester verdiend zat. Bij ons ligt er aan hoeveel werk ervaring je hebt.
Maar een tester met 5 jaar werkervaring verdient minimaal ¤3250,-
Op alle plaatsen waar ik gewerkt heb werden de script in Word of (meestal) Excel gemaakt.quote:
Het maken van handmatige testscripts ... doen jullie dat gewoon in Word/Excel of zo of hebben jullie daar een apart programma voor? En hoe organiseren jullie al die testscripts?
En soms een deel in een testtool die de scripts automatisch uitvoert, maar ook dan lag daar (als het goed is) een eerst uitgedachte analyse - en dus ook een logisch script aan ten grondslag, wat dus weer gewoon in Excel gemaakt was.
De organisatie ervan is een hele goede vraag. Ik heb wel gewerkt onder coordinatoren die dat goddank voor me deden, dat was mooi.
Meestal is er -alweer in Excel- een lijst met de scripts en is dat de organisatie.
Waar ik nu zit gebruiken we TFS, wat een deel van organisatie doet, doordat scripts dan gekoppeld kunnen worden aan specificaties.
Ok.quote:Op dinsdag 30 april 2013 06:57 schreef sigme het volgende:
[..]
Op alle plaatsen waar ik gewerkt heb werden de script in Word of (meestal) Excel gemaakt.
En soms een deel in een testtool die de scripts automatisch uitvoert, maar ook dan lag daar (als het goed is) een eerst uitgedachte analyse - en dus ook een logisch script aan ten grondslag, wat dus weer gewoon in Excel gemaakt was.
De organisatie ervan is een hele goede vraag. Ik heb wel gewerkt onder coordinatoren die dat goddank voor me deden, dat was mooi.
Meestal is er -alweer in Excel- een lijst met de scripts en is dat de organisatie.
Waar ik nu zit gebruiken we TFS, wat een deel van organisatie doet, doordat scripts dan gekoppeld kunnen worden aan specificaties.
Ik ben namelijk ontwikkelaar in een Scrum team en als ik kan soms niet echt een structuur ontdekken in alle Word-documentjes van m'n tester.
Mijn bouwers zouden ook niet moeten proberen om mijn opzet te begrijpenquote:
[..]
Ok.
Ik ben namelijk ontwikkelaar in een Scrum team en als ik kan soms niet echt een structuur ontdekken in alle Word-documentjes van m'n tester.
. Ik test gestructureerd maar ik organiseer als een chaoot, ofzo.en aanhakend op hierboven, ik zit ook in een scrumteam en meestal gaan testscripts toch gewoon in excel, hele gezellige testscripttemplates
Volgens mij kan je dat via de site van pearson vue vinden. Je moet kijken bij het iSQI programma.quote:
weet iemand hier toevallig waar je ISTQB examen kan doen zonder zo'n training te volgen? want dat scheelt toch al snel 1000 euro...
en aanhakend op hierboven, ik zit ook in een scrumteam en meestal gaan testscripts toch gewoon in excel, hele gezellige testscripttemplates
Ikzelf zie tegenwoordig zowaar wel wat positiefs in testautomatisering. Cucumber dan.
Verder als programmeur?quote:
ik heb geprobeerd om 1 jaar tester te zijn.. niet echt mijn ding merk ik
Waarom is testen niet jouw ding?
En waar ik nu werk werken we echt volledig agile en daar heeft elk team zijn eigen tester en die zijn hard nodig en leveren toch veel meerwaarde.
Ik denk wel dat het functioneel testen veel meer naar de achtergrond gaat en dat automatisch testen wel veel groter gaat worden.